阅读说明：本技术 用于提供捆绑包信息的方法和装置 (Method and apparatus for providing bundle information ) 是由 具宗会 李德基 尹江镇 林泰亨 于 2020-04-29 设计创作，主要内容包括：提供了一种提供捆绑包信息的方法。该方法包括获得智能安全平台(SSP)凭证,向服务器发送包括所获得的SSP凭证和针对捆绑包信息的请求类型的请求命令,并且当SSP凭证在服务器处被验证时,基于请求类型从服务器接收第一捆绑包信息或第二捆绑包信息。第一捆绑包信息包括与第二捆绑包信息相关的辅助平台捆绑包(SPB)元数据。(A method of providing bundle information is provided. The method includes obtaining an intelligent security platform (SSP) credential, sending a request command to a server including the obtained SSP credential and a request type for bundle information, and receiving first bundle information or second bundle information from the server based on the request type when the SSP credential is verified at the server. The first bundle information includes auxiliary platform bundle (SPB) metadata associated with the second bundle information.)

1. A method of providing bundle information by a terminal, the method comprising:

obtaining an intelligent security platform (SSP) certificate;

sending a request command to a server, the request command including the obtained SSP credentials and a request type for bundle information; and

receiving first bundle information or second bundle information from the server based on the request type if the SSP credential is verified at the server,

wherein the first bundle information comprises an auxiliary platform bundle SPB metadata associated with the second bundle information.

2. The method of claim 1, wherein the receiving comprises:

receiving the second bundle information from the server if the request type is determined to be a first type.

3. The method of claim 1, wherein the receiving comprises:

receiving the first bundle package information from the server in a case where the request type is determined to be a second type;

verifying the received first bundle package information;

transmitting a request command for the second bundle information to the server; and

receiving the second bundle information from the server if a request type of the request command for the second bundle information is determined to be a third type and the request command for the second bundle information is verified at the server based on the SSP credential.

4. The method of claim 1, wherein the SPB metadata comprises a set of specific custodian data corresponding to a family identifier.

5. A method of providing bundle information by a server, the method comprising:

receiving a request command from a terminal, wherein the request command comprises an intelligent security platform (SSP) certificate of the terminal and a request type aiming at bundle package information;

identifying the request type for the bundle information from the request command; and

in the event that the SSP credential is verified, transmitting first bundle information or second bundle information to the terminal based on the identified request type,

wherein the first bundle information comprises an auxiliary platform bundle SPB metadata associated with the second bundle information.

6. The method of claim 5, further comprising:

transmitting the second bundle information if the request type is determined to be a first type.

7. The method of claim 5, wherein the transmitting comprises:

transmitting the first bundle information to the terminal in case that the request type is determined to be a second type;

receiving a request command for the second bundle information from the terminal based on the transmitted first bundle information being authenticated at the terminal;

validating a request command for the second bundle information based on the SSP credential if the request type of the request command for the second bundle information is determined to be a third type; and

transmitting the second bundle information to the terminal in case the request command for the second bundle information is verified.

8. The method of claim 5, wherein the SPB metadata comprises a set of specific custodian data corresponding to a family identifier.

9. A terminal, comprising:

a transceiver; and

a processor configured to:

obtaining an intelligent security platform (SSP) certificate;

sending a request command to a server via the transceiver, the request command including the obtained SSP credentials and a request type for bundle information; and

receiving, via the transceiver, first bundle information or second bundle information from the server based on the request type when the SSP credential is verified at the server,

wherein the first bundle information comprises an auxiliary platform bundle SPB metadata associated with the second bundle information.

10. The terminal of claim 9, wherein the processor is further configured to:

receiving, via the transceiver, the second bundle information from the server if the request type is determined to be of a first type.

11. The terminal of claim 9, wherein the processor is further configured to:

receiving the first bundle package information from the server via the transceiver in case the request type is determined to be a second type;

verifying the received first bundle package information;

sending a request command for the second bundle information to the server via the transceiver; and

receiving, via the transceiver, the second bundle information from the server if a request type of the request command for the second bundle information is determined to be a third type and the request command for the second bundle information is verified at the server based on the SSP credential.

12. A terminal as recited in claim 9, wherein the SPB metadata includes a set of specific custodian data corresponding to a family identifier.

13. A server, comprising:

a transceiver; and

a processor configured to:

receiving a request command from a terminal via the transceiver, the request command comprising an intelligent security platform (SSP) credential of the terminal and a request type for bundle information;

identifying the request type for the bundle information from the request command; and

transmitting, via the transceiver, first bundle information or second bundle information to the terminal based on the identified request type if the SSP credential is verified,

wherein the first bundle information comprises an auxiliary platform bundle SPB metadata associated with the second bundle information.

14. The server of claim 13, wherein the processor is further configured to:

transmitting, via the transceiver, the second bundle information if the request type is determined to be of a first type.

15. The server of claim 13, wherein the processor is further configured to:

transmitting the first bundle package information to the terminal via the transceiver in case the request type is determined to be a second type, an

The method further comprises the following steps:

receiving, via the transceiver, a request command for the second bundle information from the terminal based on the transmitted first bundle information being authenticated at the terminal;

validating the request command for the second bundle information based on the SSP credential if the request type of the request command for the second bundle information is determined to be a third type;

transmitting the second bundle information to the terminal via the transceiver in case the request command for the second bundle information is verified.

Technical Field

The present invention relates to a wireless communication system. More particularly, the present invention relates to a method for processing a user plane in a dual connectivity operation of a wireless communication system.

Background

In order to meet the demand caused by the ever-increasing wireless data service after the commercialization of the fourth generation (4G) communication system, efforts have been made to develop an advanced fifth generation (5G) system or a first 5G communication system. For this reason, the 5G or first 5G communication system is also referred to as a super fourth generation (4G) network communication system or a post Long Term Evolution (LTE) system. A 5G communication system implemented using an ultra-frequency millimeter wave (mmWave) frequency band (e.g., 60GHz band) is considered to achieve a higher data rate. In order to reduce propagation loss of radio waves and increase transmission range of radio waves in an over-band, beamforming, massive Multiple Input Multiple Output (MIMO), full-dimensional MIMO (FD-MIMO), array antenna, analog beamforming, and massive antenna techniques are discussed. To improve system networks, techniques for advanced small cells, cloud Radio Access Networks (RANs), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, coordinated multipoint (CoMP), receiver-side interference cancellation, etc. have also been developed in 5G communication systems. Furthermore, in 5G systems, Advanced Coding Modulation (ACM), such as hybrid Frequency Shift Keying (FSK) and Quadrature Amplitude Modulation (QAM) modulation (FQAM), Sliding Window Superposition Coding (SWSC), and advanced access techniques, such as filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA), and Sparse Code Multiple Access (SCMA), are being developed.

Meanwhile, the internet is evolving into an internet of things (IoT) network, in which distributed entities, such as things, send, receive, and process information without human intervention. Among them, internet of everything (IoE) technology combined with, for example, IoT technology through a large data processing technology connected with a cloud server has emerged. In order to implement IoT, various technologies such as sensing technology, wired/wireless communication and network infrastructure, service interface technology, and security technology are required, and recently, technologies for sensor networks, machine-to-machine (M2M), Machine Type Communication (MTC) for connection between things are even being researched. Such an IoT environment can provide an intelligent internet technology service that creates new value for human life by collecting and analyzing data generated between connected things. IoT may be applied to various fields such as smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, health care, smart home appliances, and advanced medical services through fusion and combination between existing Information Technology (IT) and various industrial applications.

In this regard, various attempts are being made to apply the 5G communication system to the IoT network. For example, technologies related to sensor networks, M2M, MTC, etc. are implemented by 5G communication technologies (e.g., beamforming, MIMO, and array antenna schemes, etc.). Even the application of cloud RANs as the aforementioned big data processing technology may also be referred to as an example of the convergence of 5G and IoT technologies. With the development of the above-described technology and mobile communication system, various services can be provided, and a method of efficiently providing the services is required.

Disclosure of Invention

[ problem ] to

With the development of the above-described technology and mobile communication system, various services can be provided, and a method of efficiently providing the services is required.

[ solution ]

A method of providing bundle information is provided. The method includes obtaining an intelligent security platform (SSP) credential, sending a request command to a server including the obtained SSP credential and a request type for bundle information, and receiving first bundle information or second bundle information from the server based on the request type when the SSP credential is verified at the server. The first bundle information includes auxiliary platform bundle (SPB) metadata associated with the second bundle information.

Drawings

The above and other aspects, features and advantages of certain embodiments of the present disclosure will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a schematic diagram of interfaces between internal components of an SSP terminal, according to an embodiment;

FIG. 2 is a schematic diagram of internal and external components of an SSP terminal for downloading bundles, according to an embodiment;

FIG. 3 is a schematic diagram of the structure of first bundle information sent by the SPB manager to a local bundle helper (LBA), according to an embodiment;

fig. 4A is a sequence diagram illustrating a method of requesting first and second bundle information from an SPB manager by an SSP terminal according to an embodiment;

fig. 4B is a diagram illustrating a sequence diagram of a method for requesting second bundle information from an SPB manager by an SSP terminal without separately requesting first bundle information, according to an embodiment;

fig. 5 is a diagram illustrating a sequence diagram of a process of requesting second bundle information from the SPB manager by the SSP terminal after receiving the first bundle information, according to an embodiment;

fig. 6 is a diagram illustrating a sequence diagram of a process of requesting second bundle information from the SPB manager by the SSP terminal after receiving the first bundle information, according to an embodiment;

fig. 7 is a schematic diagram of a process by an SSP terminal to request second bundle information from an SPB manager after receiving first bundle information, according to an embodiment;

fig. 8 is a diagram illustrating a sequence diagram of a process of requesting second bundle information from the SPB manager by the SSP terminal after receiving the first bundle information, according to an embodiment;

fig. 9 is a diagram illustrating a sequence diagram of a process of requesting second bundle information from the SPB manager by the SSP terminal after receiving the first bundle information, according to an embodiment;

FIG. 10 is a flowchart of the operation of an SPB manager when the SPB manager receives a bundle information request function command during a bundle download process, according to an embodiment;

figure 11 is a flow diagram of the operation of an SSP terminal in accordance with an embodiment;

FIG. 12 is a flow diagram of the operation of an SPB server according to an embodiment;

figure 13 is a schematic diagram of an SSP terminal according to an embodiment; and

fig. 14 is a schematic diagram of an SPB server according to an embodiment.

Detailed Description

The present disclosure has been made to address at least the above disadvantages and to provide at least the advantages described below.

According to an aspect of the present disclosure, there is provided a method of providing bundle information by a terminal. The method includes obtaining an SSP credential, sending a request command to the server including the obtained SSP credential and a request type for bundle information, and receiving first bundle information or second bundle information from the server based on the request type when the SSP credential is verified at the server. The first bundle information includes SPB metadata regarding the second bundle information.

According to an aspect of the present disclosure, there is provided a method of providing bundle information by a server. The method includes receiving a request command including an SSP credential of the terminal and a request type for the bundle information from the terminal, identifying the request type for the bundle information from the request command, and transmitting the first bundle information or the second bundle information to the terminal based on the identified request type when the SSP credential is verified. The first bundle information includes SPB metadata associated with the second bundle information.

According to an aspect of the present disclosure, a terminal is provided. The terminal includes a transceiver and a processor configured to obtain an SSP credential, send a request command to the server via the transceiver, the request command including the obtained SSP credential and a request type for bundle information, receive, via the transceiver, the first bundle information or the second bundle information from the server based on the request type when the SSP credential is verified at the server. The first bundle information includes SPB metadata associated with the second bundle information.

According to an aspect of the present disclosure, a server is provided. The server includes a transceiver and a processor configured to receive, via the transceiver, a request command including an SSP credential of the terminal and a request type for the bundle information from the terminal, identify the request type of the bundle information from the request command, and transmit, via the transceiver, the first bundle information or the second bundle information to the terminal based on the identified request type when the SSP credential is verified. The first bundle information includes SPB metadata associated with the second bundle information.

[ modes for the invention ]

Embodiments of the present disclosure will be described below with reference to the accompanying drawings. However, embodiments of the disclosure are not limited to the particular embodiments, and should be construed to include all modifications, alterations, equivalent arrangements and methods, and/or alternative embodiments of the disclosure. In the description of the drawings, like reference numerals are used for like elements.

The terms "having," "may have," "including," and "may include" as used herein mean that a corresponding feature (e.g., an element such as a value, function, operation, or portion) is present, and do not preclude the presence of additional features.

The term "a or B", "at least one of a or/and B" or "one or more of a or/and B" as used herein includes all possible combinations of the items listed therewith. For example, "a or B," "at least one of a and B," or "at least one of a or B" means (1) including at least one a, (2) including at least one B, or (3) including at least one a and at least one B.

Terms such as "first" and "second" as used herein may use the respective components without regard to importance or order, and are used to distinguish one component from another without limiting the components. These terms may be used for the purpose of distinguishing one element from another. For example, the first user equipment and the second user equipment indicate different user equipment without regard to order or importance. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of the present disclosure.

It will be understood that when an element (e.g., a first element) is (operatively or communicatively) coupled or connected to another element (e.g., a second element), the element may be directly connected or connected to the other element and intervening elements (e.g., third elements) may be present between the element and the other element. In contrast, it will be understood that when an element (e.g., a first element) is directly coupled or connected to another element (e.g., a second element), there are no intervening elements (e.g., third elements) between the element and the other element.

As used herein, the expression "configured (or arranged)" may be used interchangeably with "adapted to", "having the capability", "designed to", "adapted to", "made" or "capable", depending on the context. The term "configured (set)" does not necessarily mean "specially designed" in the hardware level. Conversely, the expression "an apparatus is configured to" may mean that the apparatus is "capable" together with other devices or components in a particular context. For example, "a processor configured (arranged) to perform A, B and C" may mean a dedicated processor (e.g., an embedded processor) for performing the respective operations, or a general-purpose processor (e.g., a Central Processing Unit (CPU) or an Application Processor (AP)) capable of performing the respective operations by executing one or more software programs stored in a memory device.

The terminology used in describing the various embodiments of the disclosure is for the purpose of describing particular embodiments and is not intended to be limiting of the disclosure. As used herein, the singular forms are intended to include the plural forms as well, unless the context clearly indicates otherwise. Unless otherwise defined, all terms (including technical or scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the relevant art. Terms defined in commonly used dictionaries should be interpreted as having the same or similar meaning as the context of the related art, and should not be interpreted as having an ideal or exaggerated meaning unless the terms are clearly defined herein. According to circumstances, even terms defined in the present disclosure should not be construed to exclude embodiments of the present disclosure.

The term "module" as used herein may, for example, refer to a unit comprising one or a combination of two or more of hardware, software, and firmware. A "module" may be used interchangeably with the terms "unit," "logic block," "component," or "circuit," for example. A "module" may be the smallest unit of integrated component elements or parts thereof. A "module" may be a minimal unit for performing one or more functions or portions thereof. The "module" may be implemented mechanically or electronically. For example, a "module" according to the present disclosure may include at least one of an Application Specific Integrated Circuit (ASIC) chip, a Field Programmable Gate Array (FPGA), and a programmable logic device for performing operations that are known or that will be developed hereinafter.

An electronic device according to the present disclosure may include, for example, at least one of a smart phone, a tablet Personal Computer (PC), a mobile phone, a video phone, an electronic book reader (e-book reader), a desktop PC, a laptop PC, a web book computer, a workstation, a server, a Personal Digital Assistant (PDA), a Portable Multimedia Player (PMP), an MPEG-1 audio layer 3(MP3) player, a mobile medical device, a camera, and a wearable device. The wearable device may include at least one of an accessory type (e.g., watch, ring, bracelet, foot chain, necklace, glasses, contact lens, or Head Mounted Device (HMD)), a fabric or garment integration type (e.g., electronic garment), a body-mounted type (e.g., skin pad or tattoo), and a bio-implantable type (e.g., implantable circuitry).

The electronic device may be a household appliance. The home appliances may include, for example, a television, a Digital Video Disc (DVD) player, an audio, a refrigerator, an air conditioner, a vacuum cleaner, an oven, a microwave oven, a washing machine, an air cleaner, a set-top box, a home automation control panel, a security control panel, a television box (e.g., Samsung HomeSync, Apple TVTM, or Google TVTM), a game console (e.g., Xbox and PlayStation TM), an electronic dictionary, an electronic key, a camcorder, and an electronic photo frame.

The electronic devices may include various medical devices (e.g., various portable medical measurement devices (blood glucose monitoring device, heart rate monitoring device, blood pressure measuring device, body temperature measuring device, etc.), Magnetic Resonance Angiography (MRA), Magnetic Resonance Imaging (MRI), Computed Tomography (CT) machine, and ultrasound machine), navigation device, Global Positioning System (GPS) receiver, Event Data Recorder (EDR), Flight Data Recorder (FDR), vehicle infotainment device, electronic device for ship (e.g., navigation device and gyroscope for ship), avionic device, security device, car head unit, robot for home or industry, Automated Teller Machine (ATM) in bank, point of sale (POS) device in store, or internet of things (IoT) device (e.g., light bulb, various sensors, electric meter, or gas meter), Sprinkler devices, fire alarms, thermostats, street lights, ovens, sporting goods, hot water tanks, heaters, boilers, etc.).

The electronic device may include at least one of furniture or a part of a building/structure, an electronic board, an electronic signature receiving device, a projector, and various measuring instruments (e.g., a water meter, an electric meter, a gas meter, and a radio wave meter). The electronic device may be a combination of one or more of the above-described various devices. The electronic device may also be a flexible device. Further, the electronic device is not limited to the above-described devices, and may include electronic devices according to development of new technology.

Hereinafter, an electronic apparatus will be described with reference to the drawings. In the present disclosure, the term "user" denotes a person using an electronic device or a device (e.g., an artificial intelligence electronic device) using an electronic device.

The Secure Element (SE) refers to a security module constituted by a single chip storing security information (e.g., a mobile communication network access key, user identification information such as an Identity (ID) card/passport, credit card information, an encryption key, etc.), and the security module may be equipped with a control module and may operate the control module (e.g., a network access control module such as a Universal Subscriber Identity Module (USIM), an encryption module, a key generation module, etc.) to use the stored security information. The SE may be used in various electronic devices (e.g., smartphones, tablets, wearable devices, automobiles, IoT devices, etc.) and may provide security services (e.g., mobile communication network access, payment, user authentication, etc.) using security information and control modules.

The SE may be classified into a Universal Integrated Circuit Card (UICC), an embedded secure element (eSE), and an SSP, which is an integrated form of the UICC and the eSE, and may be subdivided into a removable type, an embedded type, and an integrated type integrated into a specific device or system on a chip (SOC) according to a form connected to or mounted on an electronic device.

The UICC is a smart card used when inserted into a mobile communication terminal, also referred to as a UICC card. The UICC may include an access control module to access a network of a mobile communications operator. Examples of the access control module may include a USIM, a Subscriber Identity Module (SIM), an IP multimedia services identity module (ISIM), and the like. A UICC including a USIM is generally called a USIM card. Also, the UICC including the SIM is called a SIM card.

Meanwhile, the SIM module may be equipped in the UICC card at the manufacturing stage, or the SIM module of the mobile communication service used at a time desired by the user may be downloaded onto the UICC card. The UICC card may also have a plurality of SIM modules downloaded and installed thereon, and one of the SIM modules may be selected and used. The UICC card may not be fixed or may be fixed to the terminal. UICCs fixed to terminals for use are referred to as embedded UICCs (euiccs), and in particular UICCs embedded in Communication Processors (CPs), APs, or socs having a single processor architecture in which CPs and APs are integrated are referred to as integrated UICCs (UICCs). euiccs and uiiccs may be generally used when fixed to a terminal, and may refer to UICC cards capable of remotely downloading and selecting a SIM module.

In the present disclosure, a UICC capable of remotely downloading and selecting a SIM module is generally referred to as an eUICC or an uiicc. In other words, a UICC card capable of remotely downloading and selecting a SIM module among UICC cards that are not fixed to a terminal or fixed to a terminal is generally called an eUICC or an uiicc. Also, the downloaded SIM module information is generally referred to as an eUICC profile, an uiicc profile, or more simply a profile.

eSE refers to a fixed type SE used when fixed to an electronic device. The eSE can be typically manufactured at the request of a manufacturer only for the manufacturer of the terminal, including the operating system and the framework. The eSE can remotely download and install service control modules in the form of applets and can be used for various security services, such as electronic purses, ticketing, electronic passports, digital keys, and the like. An SE in the form of a single chip attached to an electronic device capable of remotely downloading and installing a service control module is commonly referred to as an eSE.

The smart security platform may have the functionality of combining a supported UICC and an eSE in a single chip and may be referred to simply as an SSP. SSPs can be divided into mobile SSPs (rssp), embedded SSPs (essp), and integrated SSPs embedded in socs (inssp). An SSP may include a main platform (PP) and at least one auxiliary platform bundle (SPB). The PP may include at least one of a hardware platform or a Low Level Operating System (LLOS), and the auxiliary platform bundle may include at least one of a High Level Operating System (HLOS) or an application driven on the HLOS. The auxiliary platform bundle may also be referred to as an SPB or bundle.

The bundle may access a resource, such as a CPU or a memory of the PP, through a host platform interface (PPI) and thus be driven on the PP. The bundle package is equipped with communication applications such as SIM, USIM, ISIM, etc., and also with various applications such as electronic wallet, ticket, electronic passport, digital key, etc.

The SSP may be used for the aforementioned UICC or eSE usage according to a bundle downloaded and installed remotely, and multiple bundles may be installed in a single SSP and operated simultaneously for both UICC and eSE. In other words, when operating a bundle that includes a profile, the bundle may be used for the UICC to access the mobile communications operator's network. The UICC bundle can remotely download at least one profile, such as an eUICC or an uiicc, and can operate by selecting at least one of the profiles. Furthermore, when a bundle package including a service control module equipped with an application for providing, for example, an electronic wallet, a ticket, an electronic passport, or a digital key service operates on the SSP, the SSP may be used for the eSE. The plurality of service control modules may be installed and operated in an integrated manner or separately.

SSPs are chip-type security modules that can provide integrated support for UICC and eSE functions in a single chip, and can be divided into rsps, essps, and isps. The SSP may download and install bundles from an external bundle management server (i.e., SPB manager) using over-the-air (OTA) techniques.

The method of downloading and installing a bundle package using the OTA technology can be equally applied to an rSSP that can be detachably inserted into a terminal, an eSSP that can be fixedly installed on a terminal, and an iSSP that can be integrated in an SoC installed on a terminal.

The terms UICC and SIM can be used interchangeably, and the terms eUICC and eSIM can also be used interchangeably.

The SPB disclosed herein may be driven by using PP resources on the PP of the SSP, and for example, the UICC bundle may refer to a software type package of applications, file systems, authentication values, etc. stored in the existing UICC and an operating system through which the applications, file systems, and authentication values are operated, such as the HLOS. SPB may be referred to as a bundle.

The USIM configuration file as disclosed herein may have the same meaning as the configuration file or may refer to a software type package of information in the USIM application included in the configuration file.

In the present disclosure, the operation of the terminal or the external server for enabling the bundle package may refer to an operation of changing a state of a configuration file to an enabled state to configure the terminal to receive a service provided by the bundle package (e.g., a communication service by a communication carrier, a credit card payment service, a user authentication service, etc.). A bundle in an enabled state may be represented as an enabled bundle. The enabled bundle may be stored in an encrypted state in an internal or external memory space of the SSP.

An enabled bundle as disclosed herein may be changed to an active state based on external input of the bundle (e.g., user input, push, request by an application in a terminal, authentication request from a communications carrier, PP management message, etc.) or internal input of the bundle (e.g., timer, polling). The bundle package in an activated state may be loaded from an internal or external memory space of the SSP onto a driver memory in the SSP, and a security control device (i.e., a security CPU in the SSP) may be used to process and provide the security information to the terminal.

The operation of the terminal or the external server for disabling the bundle package may refer to an operation of changing the state of the bundle package into a disabled state to configure the terminal not to receive the service provided by the bundle package. A bundle in a disabled state may be denoted as a disabled bundle. The enabled bundle may be stored in an encrypted state in an internal or external memory space of the SSP.

The bundle management server disclosed herein may provide a function of generating a bundle according to a request of a service provider or another bundle management server, encrypting the generated bundle, creating an instruction for remote bundle management, or encrypting the instruction for remote bundle management. The bundle management server providing the function may be represented as at least one of an SPB manager, a Remote Bundle Manager (RBM), an Image Delivery Server (IDS), a subscription manager data preparation (SM-DP), an SM-DP plus (SM-DP +), a manager bundle server, a management SM-DP +, a bundle encryption server, a bundle generation server, a Bundle Provider (BP), a bundle provider, or a bundle provisioning credential holder (BPC holder).

The bundle management server may be used to manage keys and authentication settings, to download, install or update bundles onto the SSP, and to remotely manage the state of bundles. The bundle management server providing this functionality may be represented as at least one of an SPB manager, RBM, IDS, subscription manager secure routing (SM-SR), SM-SR plus (SM-SR +), an off-card entity of the eUICC profile manager, a profile management credential holder (PMC holder), or an EUICC Manager (EM).

The open service proxy server may be represented as at least one of an SPB manager, an RBM, an auxiliary platform bundle discovery server (SPBDS), a Bundle Discovery Server (BDS), a subscription manager discovery service (SM-DS), a Discovery Service (DS), a root SM-DS, or an alternative SM-DS. The open service proxy server may receive a registration event request (or an event registration request) from one or more bundle management servers or another open service proxy server. Further, one or more open service proxy servers may be used in combination, in which case the first open service proxy server may receive not only a registration event request from the bundle management server but also a registration event request from the second open service proxy server. The functions of the open service proxy server may be integrated into the bundle management server.

The term "terminal" as used herein may also be referred to as a Mobile Station (MS), User Equipment (UE), User Terminal (UT), wireless terminal, Access Terminal (AT), subscriber unit, Subscriber Station (SS), wireless device, wireless communication device, wireless transmit/receive unit (WTRU), mobile node, mobile station, or by other name. The terminal may include a cellular phone, a smart phone having a wireless communication function, a Personal Digital Assistant (PDA) having a wireless communication function, a wireless modem, a portable computer having a wireless communication function, an image capturing apparatus such as a camera having a wireless communication function, a game apparatus having a wireless communication function, a device for music storage and playing a wireless communication function, an internet device capable of wireless internet access and browsing, or a portable unit or terminal having a combined function. Further, the terminal may include an M2M terminal or an MTC terminal/device without being limited thereto. A terminal as used herein may also be referred to as an electronic device. SSPs capable of downloading and installing bundles can be embedded in electronic devices. When the SSP is not embedded in the electronic device, the SSP, which is physically separated from the electronic device, may be inserted and connected to the electronic device. The SSP may be inserted into the electronic device in the form of a card. The electronic device may include a terminal that may include an SSP capable of downloading and installing the bundle package. The SSP may be embedded in the terminal or separate from the terminal, in which case the SSP may be inserted and connected to the terminal.

The terminal or electronic device may include an LBA or Local Bundle Manager (LBM), which is software or an application installed in the terminal or electronic device to control the SSP. The LBA application may download the bundle package to the SSP or pass commands to the SSP to activate, deactivate, or delete the downloaded or installed bundle package.

The terminal or electronic device can include a Local Profile Assistant (LPA), which is a software or application installed in the terminal or electronic device to control the eUICC. The LPA may be implemented in the LBA or may exist in the terminal as an application separate from the LBA. The LPA may be software or an application that may control the eSIM bundle of the terminal embedded in the SSP.

The bundle identifier may also be referred to as a bundle family identifier (e.g., SPB family identifier), bundle match ID, a factor that matches an event ID. The bundle identifier (SPB ID) may indicate a unique identifier for each bundle. The bundle family identifier (SPB family identifier) may indicate an identifier that identifies the type of bundle (e.g., a telecommunications bundle for accessing a mobile carrier's network). The bundle identifier may be used with a value used by the bundle management server to index the bundle. The SSP ID may be a unique identifier of the SSP embedded in the terminal and may be referred to as sspID. Further, when the terminal and SSP chips are not separated as in the embodiments of the present disclosure, it may correspond to the terminal ID. It may also be referred to as a specific bundle id (spb id) in the SSP. In particular, it may be referred to as the bundle identifier of the manager bundle or loader (i.e., SPB loader (SPBL)) that installs another bundle on the SSP and manages activation, deactivation, or deletion of bundles. An SSP may also have multiple SSP identifiers, which may have values derived from a single unique SSP identifier. A PP in an SSP may have a unique identifier called a PP identifier. The SSP identifier may be a PP identifier.

The loader (e.g., SPBL) may be referred to as a manager bundle for installing another bundle and managing activation, deactivation, or deletion of bundles on the SSP. The LBA of the terminal or remote server may install, activate, deactivate, or delete a particular bundle through the loader. The loader used herein may also be referred to as an SSP.

In this disclosure, bundle download, remote bundle management, or other management/processing instructions for other bundles or SSPs may be collectively referred to as events. The event may be named a Remote Bundle Provisioning (RBP) operation or an event record, and each event may be called data including at least one of a corresponding event identifier (event ID or eventID), a matching identifier (matching ID or matchingID), an address (FQDN, IP address or URL) of a bundle management server or an open service proxy server storing the event, or an identifier of each server. Bundle download may be used interchangeably with bundle installation. Further, the event type may be used as a term indicating whether a specific event is a bundle download, remote bundle management (e.g., delete, activate, deactivate, replace, update, etc.), or a command to manage/process other bundles or SSPs, and may be named an operation type or OperationType, an operation class or OperationClass, an event request type, an event class, an event request class, etc.

The LBM may be named bundle local management, local management command, local command, LBM package, bundle local management package, local management command package, or local command package. The LBM may be used to change the status of a particular bundle (enable, disable, or delete status), or update the content of a particular bundle (e.g., bundle nickname, bundle metadata, etc.) through software installed on the terminal. The LBM may include one or more local management commands, in which case the target for each local management command may be the same or a different bundle.

The target bundle may refer to a bundle to be subjected to a local management command or a remote management command.

The service provider may refer to a business entity that requests generation of the bundle by issuing a demand to the bundle management server, and provides a service to the terminal through the bundle. IT may refer to a mobile operator providing a communication network access service through a bundle equipped with a communication application, and a Business Support System (BSS), an Operation Support System (OSS), a point of sale (POS) terminal, and other IT systems of the mobile operator may be collectively referred to as a service provider. Further, a service provider may refer to a particular business entity, may refer to a group of associations or associations of one or more business entities, or a representative on behalf of the group or associations without mutual exclusivity.

Further, the service providers may be named an operator (OP or OP), a Bundle Owner (BO), an Image Owner (IO), etc., and each service provider may be configured or assigned with at least one of a name or an Object Identifier (OID). When a service provider refers to a group or association or representative of one or more business entities, the name or OID of any group or association may be shared by partner business entities of all business entities or representatives belonging to the group or association.

A Network Access Application (NAA) is an application such as a USIM or ISIM stored in a UICC to access a network. The NAA may be a network access module.

The telecommunications bundle may be a bundle equipped with at least one NAA or with the functionality of remotely downloading and installing at least one NAA. The telecommunications bundle can include a telecommunications bundle identifier indicating the telecommunications bundle.

The eSIM bundle can be a bundle that functions like an eUICC in which an eUICC OS operates to allow a UE to receive a profile. The eSIM bundle can include a telecommunications bundle identifier that indicates the eSIM bundle.

The eSIM activation code is information for downloading a configuration file onto an eSIM terminal or an SSP terminal. The eSIM activation code may include an address of the SM-DP + to be accessed to download the configuration file, or may inform the address of the SM-DS of the address of the SM-DP +, and may include an activation code token value to be used as a matching identifier for a particular configuration file in the SM-DP +. When the eSIM activation code is input in the format of a QR code, "LPA" may be appended as a prefix to the data contained in the QR code.

The SSP activation code is information for downloading the bundle package to the SSP terminal. The end user can begin the bundle download process by entering an SSP activation code into the LBA application of the SSP terminal. The SSP activation code can include an eSIM activation code.

The SSP activate code and the eSIM activate code may be collectively referred to as the activate code. In general, an activation code, as used herein, may be any activation code that precedes the determination of whether the activation code is an SSP activation code or an eSIM activation code, and may be interpreted by the terminal as one of the SSP activation code or the eSIM activation code when entered into the terminal. When the eSIM activation code is included in the SSP activation code, the terminal can selectively execute the download bundle or the configuration file.

The function called by the LBA may be a function performed in the Si2 interface between the LBA and the SPB manager or the Si3 interface between the LBA and the SPB loader. The LBA may pass parameters to the SPB manager or SPB loader via a specific function. The parameters passed from the LBA by a particular function call may be referred to as a function instruction, function command, or command of the function. Upon receiving the function command, the SPB manager or SPB loader may perform a specific operation according to the function command and then respond to the function command. The response may include a parameter. The function commands and responses to function commands passed from the Si3 interface and related operations may include several function commands and related operations and responses to sub-function commands.

The function commands through Si2 may be communicated using hypertext transfer protocol (HTTP). In particular, the transfer of the function command through Si2 may be performed by an HTTP POST request message of HTTP, and in particular, the command may be transferred in a body portion of the HTTP POST request message.

The management organization object identifier may be an object identifier of an organization that manages the specific family identifier. There may be multiple organizations for a particular family identifier, each organization having an object identifier. The SSP terminal, service provider, and bundle management server can know which organization is the management entity for the bundle to manage (e.g., download) based on the management organization object identifier. Further, they can understand which management entity manages the services to be provided by the bundle based on the object identifier.

The first and second SSP information may be collectively referred to as SSP information. The first SSP information is associated with the SSP and may be non-encrypted data. The first SSP information can be interpreted by the LBA and SPB managers without requiring a specific decryption process. The second SSP information is data obtained by encrypting information related to the SSP.

The first bundle information may be metadata, or bundle metadata, metadata of the auxiliary platform bundle. The first bundle information may include non-encrypted information readable to the LBA of the SSP terminal for a bundle downloaded to the SSP terminal by a service provider or a bundle management server (or SPB manager). The LBA of the SSP terminal may receive permission from the user before receiving the second bundle information of the bundle, or determine whether the permission or meaning of the user is required for the operation/management of the bundle after installing the bundle. The first bundle information may be used for the LBA to display user basic information of the bundle. After the bundle is installed, the first bundle information may be managed by a loader (e.g., SPBL) and updated by a service provider, a bundle management server (e.g., SPB manager), and the like.

The encrypted second bundle may be a bound SPB video, a bound bundle or bound SPB, an encrypted SPB video, or an encrypted bundle or encrypted SPB. The second bundle information may include the first bundle information. The second bundle information contains information required to install the bundle, and the SSP may install the bundle onto the SSP by using the data extracted from the second bundle information. Portions of the second bundle information may be encrypted with session keys generated by the SSP and SPB manager.

The bundle information request function may be a function of requesting first bundle information and second bundle information of bundles to be installed by the SSP terminal. The operation of requesting the first and second bundle information of the bundle may be performed by transmitting a bundle information request function command to the SPB manager. The bundle information request function command may be passed by the SSP terminal to the SPB manager through the Si2 interface. The SSP terminal may request the first and second bundle information by passing the SSP's certificate, the SSP information, the SSP credentials including the SSP's capabilities, and the terminal information to the SPB manager. The bundle information request function can be distinguished by using a distinguisher or identifier included in the command. Further, the bundle information request function can be distinguished by defining different commands for the bundle information request function.

In the description of the present disclosure, when it is determined that a detailed description of a related function or configuration may unnecessarily obscure the subject matter of the present disclosure, the detailed description will be omitted.

The following examples are specifically included in the present disclosure: a method of an SPB manager constructing first bundle information of an SSP bundle, a method of an SPB manager constructing the first bundle information based on SSP information and terminal information delivered by an SSP terminal, a method of an SSP terminal constructing SSP information and terminal information to be used by the SPB manager to construct the first bundle information by including a family identifier and an object identifier of a management organization managing the family identifier, a method of an SSP terminal requesting the first bundle information of a bundle to be downloaded from the SPB manager, a method of an SSP terminal requesting second bundle information after requesting and receiving the first bundle information from the SSP manager, when a terminal requests the second bundle information after requesting and receiving the first bundle information from the SPB manager, the SPB manager determines whether the SSP terminal is an SSP terminal that previously received the first bundle information, determines whether the SSP terminal is an SSP terminal that previously received the first bundle information by verifying a signature of a challenge value delivered by the SPB manager when the SSP terminal requests the second bundle information after requesting and receiving the first bundle information from the SPB, and determines whether the SSP terminal is an SSP terminal that previously received the first bundle information by verifying a signature of a session identifier (or transaction identifier) generated by the SPB terminal when the SSP terminal requests the second bundle information after requesting and receiving the first bundle information from the SPB manager.

Figure 1 is a schematic diagram of interfaces between internal components of an SSP terminal, according to an embodiment.

Referring to fig. 1, the SSP terminal 101 may mainly include an LBA 111 and an SSP131 as terminal software. In addition, the SSP terminal 101 may include a transceiver for transmitting or receiving a signal to or from another terminal, a Base Station (BS), or a server, and a controller for controlling a general operation of the SSP terminal 101. The controller may control the operation of the SSP terminal. The controller may include at least one processor. The controller may control SSP131 via LBA 111.

SSP131 may include SPB (or bundle) 133, PP 135, and PPI 134. The SPB loader (or loader) 132 and the eSIM bundle package 133 are types of bundles. The LBA 111 and the loader 132 exchange packets through the first interface 122, and the LBA 111 may perform the following operations through the first interface 122. The first interface 122 may be referred to as a Si3 interface and may be configured to obtain first SSP information, obtain SSP credentials, and send server credentials, send bundle package data to be installed on the SSP131 to the loader 132, and manage (e.g., activate, deactivate, or delete) the bundle package installed on the SSP 131.

Figure 2 is a schematic diagram of internal and external components of an SSP terminal for downloading bundles, according to an embodiment.

The terminal 203 may correspond to the SSP terminal 101 of fig. 1. LBA204 may correspond to LBA 111 of fig. 1. SPB loader 206 may correspond to SPB loader 132 of fig. 1. The bundle package 207 may be an SPB. The terminal 203, the LBA204, and the SPB loader 206 are described in conjunction with fig. 1, and thus the description thereof will not be repeated.

Referring to fig. 2, a user 200 may select and subscribe to a service (e.g., a data service via a mobile communication network) provided by a service provider 201 in a service subscription process 210. In this case, the user 200 may optionally pass an identifier (SSP ID) of the SSP 205 to the service provider 201, install the SSP 205 on the terminal 203, and install a bundle package for using the service provided by the service provider 201 in the terminal 203. In the service subscription process 210, the user 200 may receive an SSP activation code in a QR code format to install a bundle package from the service provider 201 on the terminal of the user 200 after subscribing to the service. The SSP activation code received after the user 200 subscribes to the telecommunication service may include information for downloading the telecommunication bundle and an eSIM activation code for downloading an eSIM profile instead of the telecommunication bundle.

In the bundle configuration requirement delivery process 211, the service provider 201 and the SPB manager 202 may perform a bundle download preparation process. In the bundle configuration requirement transfer process 211, the service provider 201 may optionally transfer an identifier (SSP ID) of the SSP 205 in which the bundle is installed to the SPB manager 202, and at least one of specific bundle identifiers (SPB IDs) to the SPB manager 202 to provide a service or bundle family identifier (SPB family ID) selected by the user to the SPB manager 202. The SPB manager 202 may select one of a bundle with a particular bundle identifier or a bundle with a bundle family identifier that is passed to the SPB manager 202 in a bundle configuration requirements transfer process 211 and pass the identifier of the selected bundle to the service provider 201. In the bundle configuration requirement delivery process 211, the service provider 201 or SPB manager 202 may newly generate a bundle matching ID to distinguish the selected bundle. The bundle matching ID for distinguishing the bundles may be referred to as code _ M. In addition, the SPB manager 202 may manage the passed SSP ID by linking the SSP identifier to the selected bundle. In the bundle configuration requirement transfer process 211, the SPB manager 202 may transfer a bundle management server address (i.e., SPB manager address) from which to download the selected bundle to the service provider 201. The bundle management server address may be an address of a specific or any bundle management server in which the prepared bundle is stored, or may be an address of another bundle management server that stores and obtains download information (e.g., a server address) of the prepared bundle. In the bundle configuration requirement delivery process 211, the service provider 201 can also provide information about eSIM profiles that match the telecommunications bundle when requesting the SPB manager 202 to prepare the telecommunications bundle.

When the bundle configuration requires some of the delivery processes 211 to precede the service subscription process 210, the service provider 201 may deliver the prepared download information of the bundle to the user 200 in the service subscription process 210. At least one of a bundle management server address (e.g., SPB manager address) in which the bundle is prepared, a bundle matching ID of the prepared bundle, or a bundle family ID of the prepared bundle may be selectively transferred as the bundle download information.

Referring to fig. 2, in an input process 231 of a bundle to be downloaded, bundle download information may be transferred to the LBA204 of the terminal 203. The bundle download information may include at least one of an address of a bundle management server (SPB manager address) to be accessed by the LBA204, a bundle specifier of a bundle prepared in the bundle configuration requirement delivery process 211, or a bundle family identifier of the prepared bundle. The bundle specifier may include at least one of a bundle matching ID or a bundle event ID generated in the bundle configuration requirement delivery process 211. Further, the bundle specifier may include a bundle family identifier of the prepared bundle. The bundle event ID may include at least one of a bundle matching ID of the bundle prepared in the bundle configuration requirement transfer process 211 or an address of the bundle management server. User 200 may enter bundle download information into LBA204 by entering an SSP activation code (e.g., by QR code scanning, direct text entry, etc.). Further, bundle download information may be input to the LBA204 by push input via an information providing server (not shown). Further, the bundle download information can be received by LABs 204 accessing an information providing server pre-configured in the terminal 203.

The bundle download from the SPB manager 202 to the SSP 205 can be accomplished through functions and operations performed in the interface between the SPB manager 202 and the LBA204 and the interface 222 between the LBA204 and the SPB loader 206. The interface 222 between the LBA204 and the SPB loader 206 may correspond to the first interface 122 of fig. 1. The interface 222 between the LBA204 and the SPB loader 206 may be referred to as a Si3 interface.

Fig. 3 is a schematic diagram of the structure of first bundle information passed to LBAs by the SPB manager, according to an embodiment.

The first bundle information object 301 may include a first bundle information basic field 310, specific family metadata 320, and specific management organization metadata 331 and 332. The first bundle package information object 301 may include a plurality of specific management organization metadata items.

The first bundle information base field 310 may include a bundle identifier 311 and a bundle family identifier 312, a management organization object identifier 313. The bundle identifier 311 may be an SPB identifier corresponding to the first bundle information. The bundle family identifier 312 may be an identifier of a family to which the SPB corresponding to the first bundle information belongs. The specific management organization object identifier 313 may be an object identifier of an organization that manages a family identifier of an SPB corresponding to the first bundle package information. The first bundle information base field 310 may include a plurality of management organization object identifiers 313. When the first bundle information basic field 310 includes a plurality of management organization object identifiers 313, the plurality of management organization object identifiers 313 may be arranged based on preference or a most preferred one of the plurality of management organization object identifiers may be designated. The first bundle information base field 310 may be used to verify whether the loader's certificate used by the SSP terminal's SPB loader (or loader) 206 during bundle installation and the SPB manager's certificate have been used correctly.

In fig. 3, the particular family metadata 320 may include the bundle family identifier 312. The family-specific metadata 320 may include settings, parameters, and functions to be shared by bundles having a family-specific identifier.

The management-specific organization metadata 331 and 332 in fig. 3 may include management organization object identifiers. The management organization object identifier included in the specific management organization metadata may have a different value from the management organization object identifier 313 included in the first bundle information basic field 310. When the management organization object identifier 313 in the first bundle information 301 is a first management organization, the first bundle information 301 may include specific management organization metadata defined by a second management organization that manages the same family identifier as the first management organization. The first bundle information 301 may not include specific management organization metadata.

The first bundle information example 301a of fig. 3 is an example conforming to the structure of the first bundle information object 301. The first bundle information base field 310a of the first bundle information example 301a may include a bundle identifier 311a having a value of "1234-.

The first bundle information instance 301a may include particular family metadata 320a, and the particular family metadata 320a may include a value such as a bundle family identifier 312 a. The particular family metadata 320a may include settings, parameters, and functions to be shared by the bundle with the particular family identifier 312 a. In particular, the bundle family identifier 312a of the first bundle information instance 301a is a family identifier of a telecommunications family, and thus the particular family metadata 320a may include the family identifier of the telecommunications family and include settings, parameters, and functions to be shared by the telecommunications family bundle.

The first bundle information instance 301a may include specific administrative organization metadata 331a or 332a defined by the corresponding organization that manages the bundle family identifier 310 a. The management-specific metadata 331a or 332a may include an object identifier of the management organization and settings, parameters, and functions defined by the organization. Specific family metadata 320a needs to be defined for the bundle family identifier 312a of the first bundle information base field 310 a. Although specific management organization metadata 331a or 332a needs to be defined for the bundle family identifier 312a, it need not include the management organization object identifier 313a contained in the first bundle information base field 310 a.

The first bundle information may include a plurality of specific family metadata items 320 and 321 as in the first bundle information object 302. The first bundle information object 302 may also include a plurality of management organization specific metadata items 332. The first bundle information example 2302 a is an example of first bundle information including a plurality of specific family metadata items. Similar to the first bundle information example 301a, the first bundle information example 2302 a is a family identifier for a telecommunications family, and the administrative organization object identifier 313a includes an object identifier for organization 1. The first bundle information example 302a may include two particular family metadata items 320a and 321a, where the particular family metadata 1320 a may include the bundle family identifier 312a of the first bundle information base field 310a in the first bundle information example 2302 a. Further, the particular family metadata 1320 a may include data to be applied to the bundle family identifier 312 a. The particular family metadata 2321a may include a family identifier that is different from the bundle family identifier 312 a. The particular family metadata 321a may include a different value than the bundle family identifier 312a and include data for a different family identifier. The family-specific metadata 2321a is not data for the bundle family identifier 312a of the first bundle information instance 2302 a, but may be used by the SSP terminal and SSP as desired.

Fig. 4A is a diagram illustrating a sequence diagram of a method of requesting first and second bundle information from an SPB manager by an SSP terminal according to an embodiment.

At step 410, LBA402 of SSP terminal 400 sends a function to a loader in the SSP (i.e., SPB loader 401) requesting SSP information to install a bundle on the SSP. The SSP information request function command may include a family identifier of the bundle to be installed. The SSP information request function command may also include an object identifier of an organization that manages the family identifier of the bundle to be installed.

Upon receiving the SSP information request function command, the loader 401 may generate and send first SSP information to the LBA402 in step 411. The first SSP information may include a certificate CI information list to be used by the loader 401 and the SPB manager 403, an encryption algorithm identifier list to be used in a bundle download process, and a key exchange algorithm identifier list for generating a session key. The first SSP information may include a certificate CI information list, an encryption algorithm identifier list, and a key exchange algorithm identifier list used by the loader 401 and the SPB manager 403, such as a bundle with a specific family identifier and a specific management organization object identifier managing the specific family identifier. The first SSP information may include SSP version information.

Further, in fig. 4A, between steps 410 and 411, loader 401 may notify LBA402 that step 410 is complete and LBA402 may pass a command to request loader 401 to perform step 411.

At step 412, LBA402 may create a Transport Layer Security (TLS) session with SPB manager 403, LBA402 requesting a download bundle from SPB manager 403.

At step 413, LBA402 invokes the SPBM certificate request function from SPB manager 403. When the function is called, the LBA402 may transfer the first SSP information and the first terminal information received from the loader 401 in the SPBM certificate request function command to the SPB manager 403 in step 411. The terminal information may be configured to include one of version information of the LBA402, terminal information defined for each family identifier, and terminal information defined for each organization that manages a specific family identifier.

In step 413, the SPB manager 403 invoking the SPBM certificate request function may perform at least one of the following steps: (1) and (4) performing qualification checking: checking whether the SPB manager can support the SSP terminal by verifying the versions of the LBA and SPBL, (2) selecting a family identifier of the bundle, (3) selecting an object identifier of a management organization that manages the family identifier of the bundle, (4) selecting an SPBM key generation certificate (cert.spbm.ka) and a certificate chain to verify the SPBM key generation certificate, (5) selecting CI information of a certificate to be used by the SSP, and (6) selecting encryption algorithm information to be used by the SSP for data encryption.

At step 414, the SPB manager 403 may respond with the SPBM key to create at least one of a certificate and certificate chain, CI information for the certificate to be used by the SSP, encryption algorithm information to be used by the SSP, or a family identifier for the bundle. SPB manager 403 may also respond with an object identifier that manages the organization of the family identifier.

At step 415, the LBA 401 may invoke SSP credential request functionality from the loader 401 upon receiving a response from the SPB manager 403. When the SSP credential request function is invoked, the LBA402 may pass the server credential in a function command. The server credentials may include at least one of: (1) bundle CODE matching information (matching ID or CODE _ M), (2) bundle family identifier, (3) SPBM key generation certificate (cert. spbm.ka) and certificate chain for verifying SPBM key generation certificate, (4) CI information to be used by the SSP for signed certificates, or (5) encryption algorithm information to be used by the SSP.

Further, in addition to the above information, the server credential may optionally include bundle code matching supplemental information (challenge _ S).

Upon receiving the SSP credential request function command, the loader 401 may create an SSP credential based on the received server credential. The step of creating the SSP credential may include the steps of: (1) verifying the SPBM key creation certificate (cert.spbm.ka), (2) selecting a certificate for SPBL signature based on CI information of the certificate to be used by the SSP, (3) creating a SPBL temporary key pair, (4) creating an ID _ trans ac to be used as a session ID, (5) creating a first session key (session key 1) having a public key included in the SPBM key creation certificate and a private key of the SPBL temporary key, (6) creating a sspImageSessionToken including the SPBL temporary key, and creating sspImageSessionToken by signing the sspImageSessionToken with a secret key (sk.spbl.ds) corresponding to the SPBL certificate for signature (cert.spbl.ds), and (7) generating second SSP information.

The second SSP information may include a PP identifier. The second SSP information may include SSP information defined for the family identifier to be downloaded and SSP information defined for each organization that manages the family identifier. The second SSP information may include, for the family identifier of the bundle to be downloaded, specific management organization SSP information defined by an organization managing the bundle or service having the family identifier or a management organization (or custodian) managing the family identifier, respectively. The second SSP information may include a plurality of specific administrative organization SSP information. The second SSP information may include family-specific SSP information commonly available to the governing body for the family identifier of the bundle to be downloaded. The family-specific SSP information may include a family identifier and a list of management organizations for the family identifier supported by the SSP provisioned in the terminal. The list of management organizations supported by the SSP may be a list of object identifiers of the management organizations for the family identifiers supported by the SSP. The phrase "management organization supported SSP" may mean that the SSP is capable of interpreting the meaning of SSP settings, parameters, bundle operations/management, etc., as defined by the management organization, and determining whether the following is supported: (1) creating sspToken including bundle code matching information (matching ID, code _ M), bundle code matching supplemental information (challenge _ S), second SSP information generated as described above, and creating sspTokenSignature obtained by signing sspToken with a private key corresponding to a certificate for SPBL signature (cert.spbl.ds), (2) generating first encryption information (M-SSP) and first integrity check information (H-SSP) by encrypting the certificate for SPBL signature (cert.spbl.ds), sspToken, and sspTokenSignature with the first session key created as described above, and creating second encryption information (M-SSP2) and second integrity check information (H-SSP2) by encrypting the created sspToken and sspToken signature separately from the certificate for SPBL signature, and (3) creating a certificate by creating the SSP including signing a certificate for SPBL with a certificate management chain, verifying the SPB with a certificate for SPBL signature, sspImageSeesionToken, sspImageSessionTokenSignature, sspToken, sspTkenSignature, first encryption information (M-SSP), and first integrity check information (H-SSP). The SSP credential may include second encryption information (M-SSP2) and second integrity check information (H-SSP 2).

At step 416, the loader 401 may send the SSP credential to the LBA402 in response to the SSP credential request function. When an error occurs in a step during the SSP credential creation process, an error message may be responded to terminate the process.

Further, in fig. 4A, between steps 415 and 416, the loader 401 may notify the LBA402 that step 415 is complete, and the LBA402 may pass a command to request the loader 401 to perform step 416.

At step 418, the LBA402 may invoke the bundle information request function from the SPB manager 403 upon receiving the SSP credential from the loader 401. The LBA402 may pass a bundle information request function command to the SPB manager 403 when invoking the bundle information request function, including (1) SSP credentials received from the loader 401, (2) terminal information (the terminal information may include LBA version information, family-specific terminal information defined for the family identifier, and management-specific organization terminal information defined by the organization that manages the family-specific identifier (the family-specific terminal information may include the family identifier, representing itself as terminal information for the family identifier; the family-specific terminal information may include information, parameters, settings, and functions related to the family identifier Interpret the meanings of terminal information, terminal settings, parameters, and terminal functions defined by the management organization, and determine whether or not they are supported)), and (3) indicate an information requestType (request type) requested by the SSP terminal from the SPB manager 403.

The requestType may be represented by one of various types including a type a that requests the second bundle information from the SSP, a type B that requests only the first bundle information, and a type C that requests the second bundle information after requesting the first bundle information. In addition to the above steps, requestType can be used to define operations, and the step can be extended by using type D, type E, or the like. For the method of distinguishing types based on the requestType, the requestType may not be transmitted to indicate the most basic operation type. When the operation of type a is a basic operation, the SPB manager 403 may recognize type a when the requestType does not exist in the bundle information request function command, and may perform another operation according to a value corresponding to the requestType when the requestType exists in the bundle information request function command. Further, information related to the requestType may not be included in the bundle information request function command, and the type is distinguished by defining a specific bundle information request function command corresponding to the type.

The case when the requestType of the bundle information request function command includes one of type a (a type requesting second bundle information) or type B (a type requesting only first bundle information) and the LBA402 calls the bundle information request function may correspond to step 418. Further, even when the specific bundle information request command does not include information on the requestType but corresponds to type a and type B, it may correspond to step 418. Step 418 of fig. 4A shows a case when the requestType corresponds to type B (a type that requests only the first bundle information).

In step 419, upon receiving the SSP credential, the terminal information, and the request type having type a or type B, the SPB manager 403 may perform at least one of the following steps based on the received SSP credential and the terminal information. Further, in step 419, even when a specific bundle request function command that does not include a requestType but corresponds to type a or type B is received, at least one of the following steps may be performed: (1) determining whether the requestType is type a or type B, or whether the bundle request function command corresponds to type a or type B, (2) determining whether the bundle owned by the SPB manager 403 is compatible with the SSP terminal 400 based on the second SSP information, (3) creating a first session key using a public key of the SPBL temporary key (epk.spbm.ka) and a private key (esk.spbm.ka) paired with the public key of the SPBM key creation certificate (spk.spbm.ka), (4) decoding the M-SSP using the first session key, (5) verifying the SPBL signed certificate obtained by decoding the M-SSP and the SPBL certificate chain in the SPBM signed certificate and SPBM certificate chain (which can be verified by using the ssici information of the certificate used by the SSP sent in step 413), (6) verifying the sspten obtained by decoding the M-SSP and ssptekentuckenanthist (signature of the sspinkeysignpost) using the SPBL certificate, (7) verifying the sipekensionkeyboar signed certificate and the sessiontopign signed (sippagesignpost) using the spblkeslogan certificate, (8) storing a value of ID _ trans in sspImageSessionToken, (9) determining whether a bundle corresponding to CODE _ M existing in sspToken is stored, (10) determining whether it is possible to install the bundle corresponding to CODE _ M existing in sspToken on the SSP terminal (the determination may be performed based on the PP identifier included in the second SSP information, the specific family SSP information defined for the family identifier to be downloaded, and the specific management organization SSP information defined for each organization managing the family identifier), and (11) generating first bundle information of the bundle corresponding to CODE _ M, or may prepare the first bundle information already in place.

Generating the first bundle package information of the bundle package may include the following processes: (1) setting the bundle identifier 311 of fig. 3, (2) setting the bundle family identifier 312 of fig. 3 (the set family identifier may be equal to the family identifier included in the response from the SPB manager 403 in step 414), (3) setting the management organization object identifier 310 (the set management organization object identifier may include the management organization object identifier optionally included in the response by the SPB manager 403 in step 414), (4) adding the specific family metadata 320 of fig. 3 to the first bundle information (the specific family metadata may include the set bundle family identifier; the specific family metadata may include settings, parameters, information related to the bundle operation/management defined for the set bundle family identifier), and (5) adding the specific management organization metadata 331 of fig. 3 to the first bundle information.

The first bundle package information may include a plurality of specific management organization metadata items. The SPB manager 403 may add specific management organization metadata to the first bundle information based on the specific family SSP information and the specific management organization SSP information included in the second SSP information. The SPB manager 403 may add specific management organization metadata defined by the management organization to the first bundle information, the management organization included in a list of management organizations supported by the specific family of SSP information delivered by the SSP terminal. The SPB manager 403 may add specific management organization metadata defined by a management organization not supported by the SSP terminal to the first bundle information.

After generating the first bundle information, the SPB manager 403 may record the generation of the first bundle information and manage the first bundle information in step 419. SPB manager 403 may concatenate the first bundle information to all or part of the SSP credential passed by LBA402 and then manage the first bundle. The SPB manager 403 may concatenate the first bundle information to the entire SSP credential or some element of the SSP credential (e.g., transaction Id), and then manage the first bundle information. Such recording and management performed by the SPB manager 403 may be used in the method of checking whether the first bundle information is requested through the SSP credential of the bundle information request function command as part of the operation performed at step 429 when a bundle information request function command requesting the second bundle information is received from the same terminal in the future.

In step 421, the SPB manager 403 may respond to the bundle information request function of step 418 with the first bundle information. When the bundle information request function command corresponding to type a is received in step 418, step 421 may be skipped.

At step 425, upon receiving the first bundle information, the LBA402 may perform verification of the first bundle information. The operation for verifying the first bundle package information may include the following processes: (1) the LBA402 may verify whether the family identifier 311 of FIG. 3 included in the received first bundle information has a valid value (the method of verifying the family identifier may include a process of determining whether the family identifier included in the first bundle information is equal to the family identifier included in the input information when the LBA performs a bundle download based on the input information to the LBA in the bundle information input process 231 of FIG. 2 and the bundle family identifier exists in the input information. furthermore, the method of verifying the family identifier may include a process of determining whether the family identifier included in the response to the SPBM request function command is equal to the family identifier included in the first bundle information in step 414), (2) the LBA402 may verify whether the management organization object identifier 313 of FIG. 3 included in the received first bundle information has a valid value (the method of confirming the validity of the management organization object identifier may include a process of verifying whether the management organization object identifier 313 included in the received first bundle information has a valid value when based on the bundle information included in the received first bundle information The information input to the LBA in the bundle information input process 231 of fig. 2 performs bundle download and determines whether the management organization object identifier has the same value as the management organization object identifier of the received first bundle information when the management organization object identifier is included in the information input to the LBA. Further, the method of confirming the validity of the management organization object identifier may include a process of determining whether the management organization object identifier included in the response to the SPBM certificate request function command is equal to the management organization object identifier included in the first bundle package information in step 414, and (3) the LBA402 may check terminal settings, parameters, and functions included in the specific family metadata in the received first bundle package information.

At step 428, LBA402 may pass a bundle information function command to SPB manager 403 requesting type C (type that requests second bundle information after requesting first bundle information). Further, at step 428, LBA402 may pass a specific bundle request function command that does not include a requestType, but corresponds to type C, to SPB manager 403.

Upon receiving a bundle request function command requesting a type of type C (a type that requests second bundle information after requesting first bundle information) or a specific bundle request function command corresponding to type C, the SPB manager 403 may perform step 429. In step 429, the SPB manager 403 may perform the process of determining whether the first bundle information is requested and the operation of generating the second bundle information.

The process of determining whether to request the first bundle information may be a process of determining whether to request the first bundle information, which will be described later in step 529 of fig. 5, step 629 of fig. 6, step 729 of fig. 7, step 829 of fig. 8, and step 929 of fig. 9.

The operation of generating the second bundle information may include at least one of the following steps: (1) creating and encrypting the TIME _ STAMP using the first session key; (2) creating an SPBM temporary key pair (epk.spbm.ka, esk.spbm.ka) and creating a second session key using the SPBM temporary private key (esk.spbm.ka) and the epk.spbl.ka extracted from the SSP credential, (3) selecting the SPBM certificate for signature and preparing a certificate chain, (4) creating an SPBM token including the SPBM temporary public key (epk.spbm.ka) in the SSP credential and the ID _ trans ac value, (5) generating an SPBM token signature obtained by signing the SPBM token with a private key corresponding to the SPBM certificate for signature, (6) encrypting the image descriptor, the token ARP, the segment descriptor structure, and the like with the second session key, and (7) generating second bundle package information to be passed to the terminal. The second bundle information may include data encrypted with a second session key and second bundle information including the SPBM token, SPBM token signature, bundle segment.

At step 430, the SPB manager 403 may pass the second bundle information (e.g., the bound SPB picture) to the LBA402 in response to the bundle information request function command whose requestType is type C or a specific bundle information request function command corresponding to type C.

At step 418, the LBA402 may call a bundle information request function command whose requestType is type a (the type requesting the second bundle information) or whose specific bundle request function command corresponds to type a. Upon receiving a bundle information request function command whose requestType is type a or a specific bundle request function command corresponding to type a, the SPB manager 403 can perform the following steps: (1) execute step 419, (2) skip the process of determining whether the first bundle information is requested in step 429 and execute the step of generating the second bundle information, and (3) respond to the bundle information request function command whose request type is type a or the bundle request function command corresponding to type a with the SBP manager 430 by passing the second bundle information to the LBA402 in step 430.

Fig. 4B is a diagram illustrating a sequence diagram of a method for requesting second bundle information from an SPB manager by an SSP terminal without separately requesting first bundle information, according to an embodiment.

Fig. 4B illustrates a portion of the embodiment of fig. 4A. Specifically, fig. 4B shows a sequence diagram in which, when the SPB manager 402 receives a bundle information request function command whose requestType is type a or a specific bundle request function command corresponding to type a at step 418, the SPB manager 402 generates second bundle information and responds to the LBA402 with the second bundle information.

Steps 410 to 417 of fig. 4B may correspond to steps 410 to 417 of fig. 4A. Step 418B of fig. 4B is a partial embodiment of step 418 of fig. 4A, in which when the LBA402 calls the bundle information request function, the LBA402 adds a request type a requesting second bundle information to the bundle information request function command or the LBA402 transmits a specific function command corresponding to the second bundle information request including the type a. In step 418b, the SPB manager 403 may perform step 419 when receiving the second bundle information request function command corresponding to type a. Step 419 may correspond to step 419 of fig. 4A. After performing step 419, SPB manager 403 may perform step 429 b. Step 429b may be a step corresponding to step 429 of fig. 4 to generate second bundle information.

Fig. 5 is a diagram illustrating a sequence diagram of a procedure in which an SSP terminal requests a bundle from an SPB manager after receiving first bundle information according to an embodiment. In particular, as described above with reference to fig. 4A or 4B, fig. 5 relates to a process of determining whether first bundle information is requested based on the SSP credential value included in the bundle information request function command in step 429.

The previous steps including step 525 in fig. 5 may be performed as in the corresponding steps of fig. 4A or 4B.

At step 528, the LBA402 may send a bundle information request function command to the SPB manager 403. At step 528, LBA402 may include the SSP credential, terminal information, and requestType in the bundle information request function command. In step 528, the value of requestType indicates type C that requests the second bundle information after receiving the first bundle information.

Upon receiving the bundle information request function command in step 528, the SPB manager 403 may perform a process of determining whether the terminal transmitting the command is equal to the terminal transmitting the bundle information request function command in step 418 (a process of determining whether to request the first bundle information). In step 529, the process of determining whether to request the first bundle information may be performed by checking whether an SSP credential and terminal information equal to those included in the command transferred to request the first bundle information in step 518 are included in the command of step 528.

At step 529, the process of determining whether to request the first bundle information may be simplified to a process of determining whether the SSP credential passed at step 528 is equal to the SSP credential passed at step 518. The process of determining whether to request the first bundle information in step 529 may be a process of performing step 519 using the SSP credential and the terminal information and determining whether the first bundle information is successfully delivered to the terminal according to step 521.

When it is determined to be the same SSP terminal based on the process of determining whether to request the first bundle information in step 529, the SPB manager 403 may perform the above-described steps to generate the second bundle information with reference to step 429 of fig. 4. When the step of generating the second bundle information is successfully performed, the SPB manager 403 may transmit a response to the bundle information request function command to the LBA402 by including the second bundle information in the response of step 530.

Fig. 6 is a diagram illustrating a sequence diagram of a procedure in which an SSP terminal requests a bundle from an SPB manager after receiving first bundle information according to an embodiment. In particular, FIG. 6 relates to a process for determining whether to request first bundle information by verifying the loader's signature to obtain a challenge value passed by the SPB manager.

The previous steps, including step 619 of fig. 6, may be performed as in the corresponding steps of fig. 4.

When the steps of the SPB manager 403 are normally performed in step 619, the SPB manager 403 may transmit a response to the bundle information request function command by including the first bundle information and the server challenge value in the response in step 621. Upon receiving the response sent by SPB manager 403 at step 621, LBA402 may verify the first bundle package information at step 625. After performing step 625, the LBA402 passes the signature request function command to the loader 401 at step 626 b. The sign request function command may include a serverchange received from SPB manager 403 at step 621.

Upon receiving the signature request function command, the loader 401 generates a signedchaillenge (signed challenge) that can be verified with the loader's signature certificate included in the SSP credential based on the serverchaillenge value included in the signature request function command at step 416, and transmits the signedchaillenge to the LBA402 at step 627. The loader 401 may generate a signedchalnge by signing serverchange with a private key corresponding to the public key of the signed certificate for the loader.

In step 627, the loader 401 may pass the response to the signature request function command to the LBA402 by including serverchange and signedchange obtained by signing serverchange in the response.

Upon receiving the response from the loader 401 of step 627, the LBA402 may request second bundle information by passing a bundle information request function command to the SPB manager 403 at step 628. In this case, the bundle information request function command of step 627 may include the signedchalenge received from the loader 401 in step 627. As a way of including the signedchaillenge in the bundle information request function command, the signedchaillenge may be used for the value of the requestType. serverchange may be passed along with the signedchange in the bundle information request function command. The manner of using the signedchalingen for the value of the requestType may be used as a manner of indicating type C (the type of requesting the second bundle information after requesting the first bundle information).

At step 627, the LBA402 may not include SSP credentials and terminal information in the bundle information request function command. This is because the SSP terminal that can generate the signedchaillenge that can be verified by the SPB manager is an SSP terminal that receives the first bundle information and serverchangenge as a response to a previously transmitted bundle information request function command to request only the first bundle information.

At step 629, the SPB manager 403 receives the bundle information request function command and checks requestType included in the command. When the requestType value is type C (a type that requests second bundle information after requesting first bundle information), the SPB manager 403 may perform a process of determining whether to request the first bundle information. The process of determining whether to request the first bundle information may be a way of verifying the signedchaillenge included in the command received by the SPB manager 403. The signedchalenge may be included in the requestType. The SPB manager 403 can verify the signedchalnge included in the bundle information request function command using the public key included in the certificate of the SPBL (loader) verified in step 619. Verification of the signedchainge may be performed by SPB manager 403 determining whether the signedchainge is a signature of the serverchainge value passed to LBA 402. The signedchainge may be verified using a public key included in a certificate of the loader confirming that the loader 401 generating the SSP credential has signed serverchange transmitted by the SPB manager 403 to generate the signedchainge, so the SPB manager 403 may determine that a terminal transmitting the bundle information request function command is equal to a terminal requesting the first bundle information (in a process of determining whether to request the first bundle information) at step 618.

When it is determined as the same SSP terminal based on the signedchaillenge in step 629, the SPB manager 403 may perform the above-described steps to generate second bundle package information with reference to step 629 of fig. 4. When the step of generating the second bundle information is successfully performed, the SPB manager 403 can transmit a response to the bundle information request function command to the LBA402 by including the second bundle information in the response of step 630.

Fig. 7 is a diagram illustrating a sequence diagram of a procedure in which an SSP terminal requests a bundle from an SPB manager after receiving first bundle information according to an embodiment.

In particular, FIG. 7 relates to a process for determining whether to request first bundle information by verifying the loader's signature to obtain a challenge value passed by the SPB manager.

The previous steps including step 713 in fig. 7 may be performed as in the corresponding steps of fig. 4. Upon receiving the SPBM certificate request function command, the SPB manager 403 may perform the following operations in step 713: (1) and (4) performing qualification checking: determining whether the SSP terminal can be supported by checking versions of the LBA and SPBL, (2) settling a bundle family identifier, (3) optionally settling an object identifier of an organization that manages the bundle family identifier, (4) selecting an SPBM key generation certificate (cert.spbm.ka) and a certificate chain to validate the SPBM key generation certificate, (5) selecting CI information of a certificate to be used by the SSP, and (6) selecting encryption algorithm information to be used by the SSP for data encryption.

At step 713, after completing this step normally, the SPB manager 403 may respond with the SPBM key to create at least one of a certificate and a certificate chain, CI information for the certificate to be used by the SSP, cryptographic algorithm information to be used by the SSP, or a bundle family identifier. SPB manager 403 may also respond with an object identifier that manages the organization of the family identifier. Further, at step 714, the SPB manager 403 may generate and send a server challenge value to the LBA402 in the SPBM certificate request function response. The serverchange value may be an octet string that is typically 16 bytes long and may be randomly generated by SPB manager 403. Furthermore, serverchange can be used even with octet strings of different lengths.

Upon receiving the response from the SPB manager 403 at step 714, the LBA 715 may invoke the SSP credential request function at step 715 and send an SSP credential request function command to the loader 400. The SSP credential request function command may include a server credential. The server credential may be created as in step 415 of fig. 4.

Upon receiving the SSP credential request function command at step 716, the loader 401 may create an SSP credential based on the received server credential. The step of creating the SSP credential may correspond to the step of creating the SSP credential at step 416 of figure 4. At step 716, the loader 401 may create a signedchalnge by signing the serverchange included in the SSP credential request function command. The signedchalnge may be generated by signing serverchange with a private key corresponding to the public key of the SPBL signed certificate sent in the SSP credential. At step 716, the loader 401 may respond to the SSP credential request function command by including the created SSP credential and the signedchaillenge in the response.

In step 717, the LBA402 may store the signedchalnge value passed from the loader 401 in step 716. When LBA402 first requests and receives first bundle information and then requests second bundle information in an ongoing bundle download session, the signedchaillenge value may be used to confirm that it is the same SSP terminal.

Steps 718, 719 and 721 of fig. 4 may correspond to steps 418, 419 and 421 of fig. 4.

At step 721, upon receiving the first bundle information from the SPB manager 403, the LBA402 may perform the following steps at step 725: (1) verifies the first bundle information (which may refer to the step of verifying the first bundle information performed in step 425 of fig. 4), and (2) generates a bundle information request function command using the signedchaillenge stored in step 717.

At step 728, the LBA402 may pass a bundle information request function command to the SPB manager 403 to download the second bundle information from the SPB manager 403. The requestType of the bundle information request function command may indicate type C (a type that requests second bundle information after requesting first bundle information) at step 728. At step 728, LBA402 may use the signedChalnge stored at step 717 as the value indicating the requestType for type C. In step 728, the signedchalnge and serverchange may be included together in the bundle information request function command. The bundle information request function command may not include the SSP credential and the terminal information at step 728.

The SPB manager 403 may receive the bundle information request function command and check the requestType at step 729. When the requestType is type C, the SPB manager 403 may perform a process of determining whether to request the first bundle information. The process of determining whether to request the first bundle information may be a way of verifying the signedchaillenge included in the bundle information request function command. The signedchalenge may be used to indicate the value of requestType for type C. The signedchalenge is verified using the SPBL signed certificate verified at step 719. Verifying the signedchainge may be a process of verifying whether the signature of the SSP for serverchainge generated by SPB manager 403 at step 714 matches the signedchainge by using the SPBL signed certificate. After verifying whether the signedchalense is the signature for serverchange sent at step 714, SPB manager 403 generates second bundle information. The second bundle information may be generated by referring to the step of generating the second bundle information at step 429 of fig. 4. After completing the verification and generation of the second bundle information at step 729, SPB manager 403 may send a response to the bundle information request function command to LBA402 by including the second bundle information in the response at step 730.

Fig. 8 is a diagram illustrating a sequence diagram of a procedure in which an SSP terminal requests second bundle information from an SPB manager after receiving first bundle information according to an embodiment. In particular, fig. 8 relates to a process of determining whether to request the first bundle information by verifying the signature of the ID _ transit value to be used for the session ID included in the SSP credential.

The previous steps including step 815 in fig. 8 may be performed as in the corresponding steps of fig. 4A or 4B.

Upon receiving the SSP credential request function command from the LBA402 at step 816, the loader 401 may create an SSP credential based on the received server credential. In step 816, the loader 401 may create a signedTransac by signing the ID _ transit generated during the SSP credential creation. The signedTransac may be generated by signing the ID _ transit with a private key corresponding to the public key of the SPBL-signed certificate included in the SSP credential. At step 816, the loader 401 may respond to the SSP credential request function command by including the SSP credential and the signedtransac in the response.

In step 817, LBA402 may store signedtransac included in the response received from loader 401 in step 816. When LBA402 first requests and receives first bundle information and then requests second bundle information in an ongoing bundle download session, the signedtdransac value may be used to confirm that it is the same SSP terminal.

Steps 818, 819 and 821 of fig. 8 may correspond to steps 418, 419 and 421 of fig. 4.

At step 821, when first bundle information is received from SPB manager 403, LBA402 may perform the following at step 825: (1) verifies the first bundle information (which may refer to the step of verifying the first bundle information performed in operation 425 of fig. 4), and (2) generates a bundle information request function command using the signalidtransac stored in step 817.

At step 828, the LBA402 may pass a bundle information request function command to the SPB manager 403 to download the second bundle information from the SPB manager 403. The requestType of the bundle information request function command may indicate type C (a type that requests second bundle information after requesting first bundle information) at step 828. At step 828, LBA402 may use signedTranssac stored at step 817 as a value indicating the requestType for type C. In step 828, signedtransac may be included with the ID _ transit in the bundle information request function command. The bundle information request function command may not include the SSP credential and the terminal information at step 828.

In step 829, the SPB manager 403 may receive the bundle information request function command and check the requestType. When the requestType is type C, the SPB manager 403 may perform a process of determining whether to request the first bundle information. The process of determining whether to request the first bundle information may be a way of verifying signeddirancac included in the bundle information request function command. Signedtlransac may be used to indicate the value of requestType of type C. At step 819, signedtransac is verified with the certificate for SPBL signature. The verification of signeddtransac may be a process of verifying whether the signature of the SSP for ID _ transit included in the bundle information request function command received by the SPB manager 403 in step 818 matches signeddtransac by using the SPBL-signed certificate. After verifying whether signedtransac is a signature of ID _ transit received at step 818, the SPB manager 403 generates second bundle information. The step of generating the second bundle package information may correspond to the step of generating the second bundle package information at step 429 of fig. 4. After completing the verification of signedtlransac and generating the second bundle information in step 829, the SPB manager 403 may send a response to the bundle information request function command to the LBA402 by including the second bundle information in the response in step 830.

Fig. 9 is a diagram illustrating a sequence diagram of a procedure in which an SSP terminal requests second bundle information from an SPB manager after receiving first bundle information according to an embodiment. In particular, fig. 9 relates to an embodiment in which the first and second bundle information request function commands exist separately, and the second bundle information is generated after the first bundle information is generated.

The previous steps, including step 916 in fig. 9, may be performed as in the corresponding steps of fig. 4.

At step 918, the LBA402 may send a first bundle information request function command to the SPB manager 403. The first bundle information request function command may include SSP credentials and terminal information, and the command may be dedicated to requesting the first bundle information and may not include information related to a request type (requestType), unlike the previous embodiment of the present disclosure.

Steps 919, 921, and 925 may correspond to steps 419, 421, and 425 of fig. 4.

At step 928, the LBA402 may send a second bundle information request function command to the SPB manager 403. The second bundle information request function command may include SSP credentials and terminal information, and the command may be dedicated to requesting the second bundle information and may not include information related to a request type (requestType), unlike the previous embodiment of the present disclosure.

Upon receiving the second bundle information request function command at step 928, the SPB manager 403 can perform step 929. At step 929, the SPB manager 403 may perform a process of determining whether the SSP terminal has received the first bundle information based on the SSP credential and the terminal information included in the second bundle information request function command. At step 929, SPB manager 403 may again perform step 919.

Meanwhile, when the SSP terminal 400 transmits the second bundle request function command in step 918, the SPB manager 403 may skip step 921 and perform the step of generating the second bundle information (step 929). The bundle request function command not performing the step 921 may be defined differently from the second bundle information request function command transferred at the step 928.

Step 930 may correspond to step 430 of fig. 4A.

Fig. 10 is a flowchart of the operation of the SPB manager when the SPB manager receives a bundle information request function command during a bundle download process, according to an embodiment.

In fig. 10, the operation of the SPB manager is initiated by receiving a function command via the Si2 interface, which is an interface between the LBA and the SPB manager. In step 1001, when a function command is received through the Si2 interface, the SPB manager determines whether the received function command is a command requesting bundle information or first bundle information. The function command is referred to herein as a bundle information request function command, and may also be referred to as a Si2 getbackbeamimagecommand, a Si2 getbackbeammetadatacommand, or the like. The bundle information request function command may include an SSP credential, terminal information, and a requestType.

When the function command received in step 1001 is a bundle information request function command indicating type a (a type requesting second bundle information) or type B (a type requesting only first bundle information) as defined in step 418 of fig. 4, creating a first session key, verifying a certificate for SPBL signature, verifying an SSP credential, selecting a bundle, checking whether an SSP terminal having requested to download the bundle is capable of downloading the bundle, and creating metadata may be performed in step 1002. Step 1002 may correspond to the step performed by the SPB manager at step 419 of fig. 4.

After checking the normal execution of step 1002 at step 1003, the SPB manager may check whether the requestType included in the bundle information request command is type B (a type that requests only the first bundle information) at step 1004. When the requestType is type B (a type that requests only the first bundle information), a response including the first bundle information is transmitted to the LBA in step 1005. At step 1005, the SPB manager may include the serverchange in the response and the first bundle information. When all of steps 1002 are performed normally, the SPB manager may respond to the LBA with an error message at step 1010.

When the requestType included in the bundle information request command is type a (type requesting second bundle information) in step 1004, the SPB manager generates second bundle information and responds to the LBA with the second bundle information in step 1009. The step of generating the second bundle information may correspond to the step of generating the second bundle information at step 429 of fig. 4.

When the received function command includes the type C defined in step 418 of fig. 4 (the type of requesting the second bundle information after requesting the first bundle information) in step 1006, the SPB manager may perform an operation of confirming whether the terminal having transmitted the function command is a terminal that previously requested the first bundle information in step 1007. The confirmation performed at step 1007 may be performed by one of: (1) procedure for determining whether to request the first bundle information as in step 529 of fig. 5: at step 529, the process of determining whether to request the first bundle information may be simplified to a process of determining whether the SSP credential delivered at step 529 is equal to the SSP credential delivered at step 518, (2) a process of verifying the signedchalenge at step 629 of fig. 6: the SPB manager 403 verifies the signedchalenge included in the received command. The signedchalenge may be included in the requestType. The SPB manager 403 verifies the signedchalnge included in the bundle-information-request-function command using the public key included in the certificate of the SPBL (loader) verified in step 619. Verification of the signedchainge may be performed by SPB manager 403 determining whether the signedchainge is a signature of the serverchainge value passed to LBA402, (3) process to verify the signedchainge at step 729 of fig. 7: the signedchalenge is verified using the SPBL signed certificate verified at step 719. The verification of the signedchainge may be a process of verifying whether the signature of the SSP for serverchainge generated by the SPB manager 403 at step 714 matches the signedchainge by using the SPBL-signed certificate, and (4) a process of verifying signedldtransac at step 829 of fig. 8: the signeddtransac included in the bundle information request function command is verified. Signedtlransac may be used to indicate the value of requestType of type C. At step 819, signedtransac is verified with the certificate for SPBL signature. The verification of signeddtransac may be a process of verifying whether the signature of the SSP for ID _ transport included in the bundle information request function command received by the SPB manager 403 in step 818 matches signeddtransac by using the SPBL-signed certificate.

After step 1007 successfully performs verification, the SPB manager performs step 1009. When the verification fails at step 1007, an error message may be sent at step 1010.

Figure 11 is a flow diagram of the operation of an SSP terminal in accordance with an embodiment.

At step 1110, the SSP terminal may transmit a first bundle information request including a bundle identifier and metadata to the SPB server. Step 1110 may correspond to each of steps 418, 518, 618, 718, 818, and 918 of fig. 4-9.

In step 1120, the SSP terminal may check validity of the first bundle package information received from the SPB server at the request of the SSP terminal. Step 1120 may correspond to each of steps 425, 525, 625, 725, 825, and 925 of fig. 4-9.

When the first bundle information is verified as valid, the SSP terminal may transmit a second bundle information request including encrypted data related to the bundle to the SPB server at step 1130. Step 1130 may correspond to each of steps 428, 528, 628, 728, 828, and 928 of fig. 4.

In step 1140, when the SSP terminal has requested a terminal confirmed as requesting the first bundle information based on the second bundle information, the SSP terminal may receive the second bundle information from the SPB server. Step 1140 may correspond to each of steps 430, 530, 630, 730, 830, and 930 of fig. 4-9.

FIG. 12 is a flow diagram of the operation of an SPB server according to an embodiment.

At step 1210, the SPB server may receive a first bundle information request including a bundle identifier and metadata from the SSP terminal. Step 1110 may correspond to each of steps 418, 518, 618, 718, 818, and 918 of fig. 4-9.

The SPB server may transmit the first bundle information to the SSP terminal according to the request in step 1220. Step 1220 may correspond to each of steps 421, 521, 621, 721, 821 and 921 of fig. 4 to 9.

When the first bundle information is verified as valid, the SPB server may receive a second bundle information request including encrypted data related to the bundle from the SSP terminal in step 1230. Step 1130 may correspond to each of steps 428, 528, 628, 728, 828, and 928 of fig. 4-9.

In step 1240, the SPB server may transmit the second bundle information to the SSP terminal when the SSP terminal is confirmed as a terminal that has requested the first bundle information based on the second bundle information request. Step 1140 may correspond to each of steps 430, 530, 630, 730, 830, and 930 of fig. 4-9.

Figure 13 is a schematic diagram of an SSP terminal according to an embodiment.

The SSP terminal 1300 can include an LBA 1310, a processor 1320, a transceiver 1330, and a memory 1340.

The LBA 1310 and the processor 1320 may correspond to the LBA and SSP described above in connection with fig. 1-9. The block diagram of fig. 13 is merely an example, and LBA 1310 may be integrated in processor 1320.

The transceiver 1330 may transmit and receive signals to and from the SPB server. To this end, the transceiver 1330 may include an RF transmitter for up-converting a frequency of a signal to be transmitted and amplifying the signal, and an RF receiver for low-noise amplifying a received signal and down-converting a frequency of the received signal.

The memory 1340 may store signals transmitted/received by the SSP terminal and instructions necessary to perform the above-described steps.

Fig. 14 is a schematic diagram of an SPB server 1400 according to an embodiment.

SPB server 1400 can include a transceiver 1410, a processor 1420, and a memory 1430.

The transceiver 1410 may transmit signals to or receive signals from the SSP terminal. To this end, the transceiver 1410 may include an RF transmitter for up-converting a frequency of a signal to be transmitted and amplifying the signal, and an RF receiver for low-noise amplifying a received signal and down-converting a frequency of the received signal.

As described above in connection with fig. 1-9, processor 1420 may control SPB server 1400 to perform the steps of the SPB manager.

The memory 1430 may store signals transmitted/received by the SPB server 1400, as well as instructions necessary to perform the above-described steps.

The term "module" as used herein may refer to, for example, an element comprising one or more combinations of hardware, software, and firmware. The term "module" may be used interchangeably with the terms "logic," logic block, "" portion, "and" circuitry. A "module" may be the smallest unit of an integrated component or may be part thereof. A "module" may be a minimal unit for performing one or more functions or portions thereof. For example, a "module" may comprise an ASIC.

Various embodiments of the disclosure may be implemented by software including instructions stored in a machine (e.g., computer) readable storage medium. A machine may be a device that invokes instructions from a machine-readable storage medium and operates in accordance with the invoked instructions and may include electronic devices. When the instructions are executed by the processor, the processor may perform the functions corresponding to the instructions directly or using other components under the control of the processor. The instructions may include code generated or executed by a compiler or interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. As used herein, the term "non-transitory" is a limitation on the media itself (i.e., tangible, not a signal), and not a limitation on data storage persistence.

Methods according to various embodiments disclosed in the present disclosure may be provided as part of a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium, such as a compact disc read only memory (CD-ROM), or may be distributed only through an application Store, such as a Play Store. In case of online distribution, at least a part of the computer program product may be temporarily stored or generated in a storage medium, such as a memory of a server of a manufacturer, a server of an application store or a relay server.

Each component (e.g., module or program) according to various embodiments may include at least one of the above components, and a part of the above sub-components may be omitted, or additional other sub-components may be further included. Alternatively or additionally, some components may be integrated in one component, and the same or similar functions performed by each respective component may be performed prior to integration. Operations performed by modules, programming, or other components according to various embodiments of the present disclosure may be performed sequentially, in parallel, repeatedly, or in a heuristic approach. Further, at least some of the operations may be performed in a different order, omitted, or other operations may be added.

While the disclosure has been shown and described with reference to certain embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the disclosure. Therefore, the scope of the present disclosure should not be limited to the embodiments, but should be defined by the appended claims and equivalents thereof.