Method and apparatus for setting bundle state after bundle transfer between devices - Patents.com

Abstract

The present invention relates to a communication technique and a system thereof for converging a 5G communication system with IoT technology to support a higher data transmission rate than that of the 4G system. The present invention may be applied to intelligent services (e.g., smart homes, smart buildings, smart cities, smart cars or connected cars, healthcare, digital education, retail, security and safety related services, etc.) based on 5G communication technology and IoT related technology. The present invention describes a method and a device for setting a bundle state after a bundle is transmitted between smart security media.

Description

[Technical field]

[0001] The present invention relates to smart security media, and more particularly to a method and apparatus for setting the state of a bundle after a bundle transfer between smart security media has occurred. The present invention also relates to a smart security medium, and more particularly to a method and apparatus for registering a bundle transfer result in a server after a bundle transfer between smart security media has been performed. [Background technology]

[0002] In order to meet the increasing demand for wireless data traffic since the commercialization of the 4G communication system, efforts are underway to develop an improved 5G communication system or pre-5G communication system. For this reason, 5G communication systems or pre-5G communication systems are also called Beyond 4G Network communication systems or Post LTE systems. To achieve high data transmission rates, 5G communication systems are being considered for implementation in ultra-high frequency (mmWave) bands (e.g., 60 GHz bands).

[0003] In order to mitigate path loss in propagation in ultra-high frequency bands and increase transmission distances, technologies such as beamforming, massive array multiple input / output (massive MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam forming, and largescale antenna are being discussed in 5G communication systems.

[0004] Furthermore, to improve the system's network, technologies being developed in the 5G communication system include advanced small cells, advanced small cells, cloud radio access networks (cloud RAN), ultra-dense networks, device to device communication, wireless backhaul, moving networks, cooperative communication, CoMP (Coordinated Multi-Points), and receive interference cancellation.

[0005] In addition, advanced coding modulation (ACM) methods such as FQAM (Hybrid FSK and QAM Modulation) and SWSC (Sliding Window Superposition Coding) and advanced connection technologies such as FBMC (Filter Bank Multi Carrier), NOMA (non orthogonal multiple access), and SCMA (sparse code multiple access) are being developed for 5G systems.

[0006] Meanwhile, the Internet, a human-centered connected network in which humans generate and consume information, is evolving into an IoT (Internet of Things) network that exchanges and processes information between distributed entities such as things. IoE (Internet of Everything) technology, which combines big data processing technology through connections to cloud servers and other devices with IoT technology, is also emerging. To realize IoT, technological elements such as sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology are required, and recently, technologies such as sensor networks for connecting things, M2M (Machine to Machine) communication, and MTC (Machine Type Communication) are being researched.

[0007] In an IoT environment, intelligent IT (Internet Technology) services can be provided that collect and analyze data generated by connected things to create new value in human life. Through the convergence and integration of existing IT (Internet Technology) and various industries, IoT can be applied to fields such as smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart home appliances, and advanced medical services.

[0008] As a result, various attempts have been made to apply 5G communication systems to IoT networks. For example, 5G communication technologies such as sensor networks, M2M (Machine to Machine) and MTC (Machine Type Communication) can be implemented using beamforming, MIMO and array antennas. In addition, the application of cloud radio access network (cloud RAN) as the aforementioned big data processing technology is also seen as an example of convergence between 5G technology and IoT technology. Summary of the Invention [Problem to be solved by the invention]

[0009] The present invention provides an apparatus and method for setting the state of a bundle after a bundle transfer when the bundle is moved between security modules contained in two electronic devices. Another object of the present invention is to provide an apparatus and method for registering a result of a bundle transmission in a server after a bundle is transmitted when the bundle is transferred between security modules included in two electronic devices. [Means for solving the problem]

[0010] According to one aspect of the present invention, a method for operating a first terminal includes: fart transmitting a bundle; and receiving from the second terminal a first certificate generated including bundle status information of the second terminal; Verify the verification of the bundle status information of the second terminal; The method includes: verifying the received first certificate; generating a second certificate including bundle status information of the first terminal after verifying the first certificate; and transmitting the second certificate to the second terminal. The bundle is a Secondary Platform Bundle (SPB) of the first terminal. It is characterized by:

[0011] In some examples, the bundle status information of the first terminal includes that the bundle status of the first terminal is set to at least one of "DELETE", "IN TRANSITION", and "SUSPENSION".

[0012] In some examples, when the bundle state of the first terminal is set to "IN TRANSITION", the method further includes the steps of receiving a third certificate from the second terminal, the third certificate being generated including information regarding a change in the bundle state of the second terminal, verifying the received third certificate, and deleting (DELETE) the bundle of the first terminal after verifying the third certificate.

[0013] In some examples, a fourth certificate including information regarding the verification result of the first certificate and the second certificate is generated by the second terminal, the fourth certificate is sent to a server, and the fourth certificate is verified by the server.

[0014] In some examples, a fifth certificate including an authentication result with the server is generated by the server, the fifth certificate is sent to the second terminal, and the fifth certificate is verified by the second terminal.

[0015] According to one aspect of the present invention, a method for operating a second terminal includes the steps of: receiving a bundle from a first terminal; installing the bundle; generating a first certificate including bundle status information of the second terminal; transmitting the first certificate to the first terminal; and receiving a second certificate from the first terminal, the second certificate including the bundle status information of the first terminal. Verifying the verification of the bundle status information of the first terminal; and changing bundle state setting information of the second terminal after verifying the received second certificate. The bundle is a Secondary Platform Bundle (SPB) of the first terminal. It is characterized by:

[0016] According to one aspect of the present invention, a first terminal includes a transceiver unit capable of transmitting and receiving at least one signal, and a control unit coupled to the transceiver unit, the control unit being configured to: fart Transmitting the bundle and receiving from the second terminal a first certificate generated including bundle status information of the second terminal; Verify the verification of the bundle status information of the second terminal; and verifying the received first certificate, generating a second certificate including bundle status information of the first terminal after verifying the first certificate, and transmitting the second certificate at the second terminal. The bundle is a Secondary Platform Bundle (SPB) of the first terminal. It is characterized by:

[0017] According to one aspect of the present invention, a second terminal includes a transceiver unit capable of transmitting and receiving at least one signal, and a control unit coupled to the transceiver unit, the control unit receiving a bundle from a first terminal, installing the bundle, generating a first certificate including bundle status information of the second terminal, transmitting the first certificate to the first terminal, receiving a second certificate from the first terminal, the second certificate including the bundle status information of the first terminal, Verifying the verification of the bundle status information of the first terminal; and verifying the received second certificate, and modifying bundle state setting information of the second terminal after verifying the second certificate. The bundle is a Secondary Platform Bundle (SPB) of the first terminal. It is characterized by: Effect of the Invention

[0018] According to the first and second terminals and their operating methods of the present invention, a bundle installed in one device can be transmitted and installed in another device in a safe and efficient manner, and the state of the bundle after transmission and installation can be set. In addition, a bundle installed on one device can be transmitted and installed on another device in a safe and efficient manner, and the results of the bundle transmission after transmission and installation can be registered on the server. [Brief description of the drawings]

[0019] [Figure 1] FIG. 1 illustrates the concept of SSP according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a diagram illustrating the concept of the internal structure of an SSP according to an embodiment of the present invention. [Diagram 3] FIG. 2 illustrates an example of components within a terminal used by the terminal to download and install a bundle at an SSP according to an embodiment of the present invention. [Figure 4] 2 illustrates an example of how two terminals interact to transmit bundles between them according to an embodiment of the present invention. FIG. [Diagram 5] FIG. 2 is a diagram showing the configuration of an "Attestation" according to one embodiment of the present invention. [Figure 6] FIG. 2 is a diagram conceptually illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present invention. [Figure 7] FIG. 7 is a diagram showing detailed procedures for preparing for bundle transmission among the procedures presented in FIG. 6. [Figure 8] FIG. 7 is a diagram showing detailed steps of the bundle transmission procedure among the procedures presented in FIG. 6. [Figure 9] FIG. 7 is a diagram showing detailed steps of the steps presented in FIG. 6 for completing the transmission of a bundle. [Figure 10] FIG. 7 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. 6. [Figure 11] FIG. 7 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. 6. [Figure 12] FIG. 7 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. 6. [Figure 13] FIG. 13 illustrates an example of a procedure for making a discontinued bundle available for further use. [Figure 14] FIG. 13 illustrates another example procedure for making a discontinued bundle available for further use. [Figure 15] FIG. 13 illustrates another example procedure for making a discontinued bundle available for further use. [Figure 16] 1 is a block diagram showing a schematic configuration of a terminal according to an embodiment of the present invention. [Figure 17] FIG. 7 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. 6. [Figure 18] FIG. 2 is a diagram showing the configuration of an "Attestation" according to one embodiment of the present invention. [Figure 19] FIG. 2 is a diagram conceptually illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present invention. [Figure 20] FIG. 20 is a diagram showing detailed procedures for preparing for bundle transmission among the procedures presented in FIG. 19. [Figure 21] FIG. 20 is a diagram showing detailed steps of the bundle transmission step shown in FIG. 19. [Figure 22] FIG. 20 is a diagram showing detailed steps for completing the transmission of a bundle among the steps presented in FIG. 19. [Diagram 23] FIG. 23 is a diagram showing a procedure in which the bundle transmission result is registered on the server after the procedure presented in FIG. 22. [Figure 24]FIG. 20 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. 19. [Diagram 25] FIG. 25 is a diagram showing the procedure in which the bundle transmission result is registered on the server after the procedure presented in FIG. 24. [Figure 26] FIG. 20 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. 19. [Figure 27] FIG. 27 is a diagram showing a procedure in which the bundle transmission result is registered on the server after the procedure presented in FIG. 26. [Figure 28] 1 is a block diagram showing a schematic configuration of a terminal according to an embodiment of the present invention. [Figure 29] FIG. 2 is a block diagram showing a schematic configuration of a server according to an embodiment of the present invention. [Diagram 30] 20 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. 19, and a procedure for registering the result of the transmission of the bundle on the server. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

[0021] In describing the embodiments, technical details that are well known in the technical field to which the present invention pertains and are not directly related to the present invention will not be described. This is for the purpose of conveying the gist of the present invention clearly and more clearly by omitting unnecessary explanations. For the same reason, in the accompanying drawings, some components are exaggerated, omitted or illustrated diagrammatically. Additionally, the size of each component does not necessarily reflect the actual size. In the various drawings, the same or corresponding components are given the same reference numbers.

[0022] The advantages and features of the present invention, as well as the methods for achieving them, will become more apparent from the following detailed description of the embodiments taken in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but may be embodied in various different forms, and the present embodiments are provided only to complete the disclosure of the present invention and to fully convey the scope of the disclosure to those skilled in the art to which the present invention pertains, and the present invention is defined only by the scope of the claims. Like reference numbers refer to like elements throughout the specification.

[0023] At this time, it will be understood that each block of the process flow chart and the combination of the figures in the flow chart can be implemented by computer program instructions. These computer program instructions can be loaded into a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, such that the instructions, when executed by the processor of the computer or other programmable data processing equipment, create means for performing the functions described in the flowchart blocks. These computer program instructions may be stored in a computer usable or computer readable memory that can direct a computer or other programmable data processing equipment to implement functions in a particular manner, such that the instructions stored in the computer usable or computer readable memory may produce an article of manufacture that includes instruction means that perform the functions described in the flowchart blocks. The computer program instructions may be embodied on a computer or other programmable data processing device such that a series of operational steps are performed on the computer or other programmable data processing device, and the instructions may generate a computer implemented process to cause the computer or other programmable data processing device to provide steps for performing the functions described in the flowchart blocks.

[0024] Furthermore, each block may represent a module, a segment, or a portion of code that includes one or more executable instructions for performing a specified logical function. It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of order. For example, two blocks shown in succession may in fact be performed substantially concurrently or the blocks may sometimes be performed in reverse order depending upon the functionality involved.

[0025] In this regard, the term "unit" used in the present embodiment means software or a hardware component such as an FPGA or an ASIC, and the "unit" performs any function. However, the term "part" is not intended to be limited to software or hardware. A "module" may be configured to reside in an addressable storage medium and to execute on one or more processors. Thus, by way of example, "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. Not only may the functionality provided in the components and "units" be combined into a smaller number of components and "units" or further separated into additional components and "units", but the components and "units" may also be embodied to replicate one or more CPUs within a device or security multimedia card.

[0026] Further, in the present invention, each embodiment will be described taking the SSP as an example of a security medium, but the scope of the rights of the present invention is not limited by the SSP. For example, it will be obvious to a person skilled in the art that the various embodiments described below can be applied in substantially the same or similar manner to other security media that perform substantially the same or similar functions as SSP. The specific terms used in the following description are provided to aid in understanding the present invention, and the use of such specific terms may be modified in other forms without departing from the technical spirit of the present invention.

[0027] "SE (Secure Element)" refers to a security module composed of a single chip that stores security information (e.g., a mobile communication network connection key, user identification information such as an ID card / passport, credit card information, encryption key, etc.) and can be equipped with and operated by a control module (e.g., a network connection control module such as a USIM, an encryption module, a key generation module, etc.) that uses the stored security information. SEs can be used in a variety of electronic devices (e.g., smartphones, tablets, wearable devices, automobiles, IoT devices, etc.) and can provide security services (e.g., mobile communication network connection, payment, user authentication, etc.) through security information and control modules.

[0028] SE can be divided into UICC (Universal Integrated Circuit Card), eSE (Embedded Secure Element), SSP (Smart Secure Platform) which is an integrated form of UICC and eSE, etc., and can be further divided into removable type, fixed type, and integrated type which is integrated into a specific element or SoC (system on chip) depending on the form in which it is connected or installed in an electronic device.

[0029] A "Universal Integrated Circuit Card (UICC)" is a smart card that is inserted into a mobile communication terminal and used, and can also be referred to as a UICC card. The UICC may include a connection control module for connecting to a mobile operator's network. Examples of connection control modules include a Universal Subscriber Identity Module (USIM), a Subscriber Identity Module (SIM), and an IP Multimedia Service Identity Module (ISIM). A UICC containing a USIM is also commonly called a USIM card. Similarly, a UICC that includes a SIM module is also commonly referred to as a SIM card. Meanwhile, the SIM module is installed at the time of manufacturing the UICC, or the SIM module of the mobile communication service to be used can be downloaded to the UICC card at the user's request.

[0030] The UICC card can further download and install a number of SIM modules, and can select at least one of the SIM modules for use. Such a UICC card may or may not be fixed to the terminal. A UICC that is fixed to a terminal is referred to as an eUICC (embedded UICC), and in particular, a UICC that is built into a "System-On-Chip" (SoC) that includes a terminal's communication processor, application processor, or a single processor structure that integrates these two processors can be referred to as an iUICC (Integrated UICC). Generally, eUICC and iUICC refer to UICC cards that are fixed to a terminal and can remotely download and select SIM modules. In the present invention, a UICC card that can remotely download and select a SIM module is commonly referred to as an eUICC or iUICC. That is, among UICC cards that can remotely download and select a SIM module, a UICC card that is either fixed to a terminal or not is commonly referred to as an eUICC or iUICC. Furthermore, the SIM module information to be downloaded is commonly referred to as an eUICC profile or an iUICC profile, or more simply as a profile.

[0031] In the present invention, the term "UICC" may be used interchangeably with SIM, and the term "eUICC" may be used interchangeably with eSIM. In addition, in the present invention, 'USIM Profile' may mean the same as a profile or may mean information contained in a USIM application in a profile packaged in software form.

[0032] "eSE (Embedded Secure Element)" refers to a fixed SE that is fixed to an electronic device. The eSE is typically custom-built at the request of the device manufacturer and may include an OS and framework. The eSE can be used for various security services such as electronic wallets, ticketing, electronic passports, and digital keys by remotely downloading and installing applet-type service control modules. In the present invention, a single chip type SE attached to an electronic device that can remotely download and install a service control module is referred to as an eSE.

[0033] The Smart Secure Platform (SSP) is a platform that can integrate and support the functions of UICC and eSE in a single chip. It can be categorized into removable SSP (rSSP), embedded SSP (eSSP), and integrated SSP (iSSP) built into the SoC. The SSP includes one Primary Platform (PP) and at least one Secondary Platform Bundle (SPB) that runs on the PP, where the Primary Platform includes at least one of a hardware platform and a "low level Operating System" (LLOS), and the Secondary Platform Bundle includes at least one of a "High-level Operating System" (HLOS) and an application that runs on the HLOS. The secondary platform bundle is also called an SPB or a bundle. A bundle accesses the PP's central processing unit, memory, and other resources via the "Primary Platform Interface" (PPI) provided by the PP, and runs on the PP via this. The bundle may be equipped with communication applications such as a Subscriber Identification Module (SIM), Universal SIM (USIM), and IP Multimedia SIM (ISIM), as well as a variety of application programs such as an electronic wallet, ticketing, an electronic passport, and a digital key. In the present invention, the SSP can also be named a smart security medium.

[0034] The SSP can be used for the aforementioned UICC or eSE purposes depending on the bundle that is downloaded and installed, and multiple bundles can be installed in a single SSP and operated simultaneously to mix UICC and eSE purposes. That is, when a bundle including the profile is in operation, the SSP can be used as a UICC for connecting to a mobile communication operator network. The UICC bundle allows at least one profile, such as an eUICC or iUICC, to be remotely downloaded into the bundle and selected for operation. In addition, when a bundle including a service control module equipped with an application capable of providing services such as an electronic wallet, ticketing, electronic passport, or digital key runs on the SSP, the SSP is used as an eSE. A plurality of service control modules can be installed and operated in an integrated manner as one bundle, or installed and operated in separate independent bundles.

[0035] The SSP can download and install bundles from an external bundle management server (Secondary Platform Bundle Manager: SPB Manager) using OTA (Over The Air) technology, and can also receive and install bundles from other devices. In the present invention, the method of installing a downloaded or transmitted bundle can be equally applied to a removable SSP (rSSP) that can be inserted and removed from a terminal, a fixed SSP (eSSP) installed in a terminal, and an integrated SSP (iSSP) included inside an SoC installed in a terminal.

[0036] The "SSP identifier (SSP ID)" may be referred to as sspID, which is a unique identifier of the SSP built into the terminal. Also, in the case where the terminal and the SSP chip are not separated as in the embodiment of the present invention, it may be the terminal ID. It can also refer to a specific bundle identifier (SPB ID) within an SSP. More specifically, it may refer to the bundle identifier of a management bundle or loader (Secondary Platform Bundle Loader: SPBL) that installs other bundles in the SSP and manages their activation, deactivation, and deletion. It can also refer to the Primary Platform Identifier within an SSP. An SSP may have multiple SSP identifiers, which may be derived values ​​from a single unique SSP identifier.

[0037] A "Secondary Platform Bundle (SPB)" is operated on the Primary Platform (PP) of an SSP using the resources of the PP. For example, a UICC bundle means that applications, file systems, authentication key values, etc. stored in an existing UICC, as well as the operating system (HLOS) on which they run, are packaged in software form. In the present invention, the SPB can be referred to as a bundle.

[0038] In the present invention, the "state" of a terminal is as follows. [enable] In the present invention, the operation of a terminal or an external server activating a bundle means an operation of changing the state of the corresponding SPB to an activated state (enabled) so that the terminal can receive services provided by the corresponding bundle (e.g., communication services, credit card payment services, user authentication services, etc., via a telecommunications carrier). A bundle in an activated state can be expressed as an "enabled bundle." The activation state bundle may be stored in encrypted form in a storage space inside or outside the SSP.

[0039] [Active] In the present invention, an activated bundle can change its operating state (Active) based on input from outside the bundle (e.g., user input, push, a request from an application in the terminal, an authentication request from a carrier, a PP management message, etc.) or an operation within the bundle (e.g., a timer, polling). A running state bundle is a bundle that is loaded into the running memory of the SSP from the internal or external storage space of the SSP, and processes security information using the security control device (Secure CPU) in the SSP to provide security services to the terminal.

[0040] [Disabled] In the present invention, the operation of a terminal or an external server disabling a bundle means an operation of changing the state of the bundle to a disabled state so that the terminal cannot receive the services provided by the bundle. An SPB in a deactivated state can be expressed as a "disabled bundle." The inactive bundle may be stored in an encrypted state in a storage space inside or outside the SSP.

[0041] Deleted In the present invention, the operation of a terminal or an external server deleting a bundle means an operation of changing the state of the bundle to a deleted state or deleting related data of the bundle including the bundle so that the terminal or the external server cannot drive, activate or deactivate the bundle any more. A bundle in a deleted state can be expressed as a "deleted Bundle."

[0042] "Bundle Image" or "Image" may be used interchangeably with "bundle" or may refer to a data object of a particular bundle, and may be named a Bundle TLV or Bundle Image TLV. When a bundle image is encrypted using encryption parameters, it can be named a Protected Bundle Image (PBI) or a Protected Bundle Image TLV (PBI TLV). When a bundled image is encrypted with encryption parameters that can only be decrypted by a specific SSP, it can be called a Bound Bundle Image (BBI) or Bound Bundle Image TLV (BBI TLV). A bundle image TLV may be a set of data representing the information that makes up a bundle in TLV (Tag, Length, Value) format.

[0043] A "bundle classifier" may be referred to as a factor that is matched with a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), a bundle family custodian object ID (SPB Family Custodian Object ID), a bundle matching ID, and an event identifier (Event ID). The bundle identifier (SPB ID) may refer to a unique identifier for each bundle. The bundle family identifier may refer to an identifier that distinguishes the type of bundle (eg, a telecom bundle for connection to a mobile carrier network). In the present invention, the bundle family identifier may be referred to as a "Famaily ID," Fid, or FID. The bundle family manager identifier may refer to an identifier that distinguishes an entity (eg, a telecommunications carrier, a terminal manufacturer, a specific organization, etc.) that manages the bundle family identifier. In the present invention, a bundle family manager identifier may be referred to as an OID or Oid. The bundle classifier can be used by a bundle management server or terminal with values ​​that can index bundles.

[0044] "Bundle metadata" is a term that refers to a set of information that can name or describe a bundle. The bundle metadata may include the bundle classifier described above. Additionally, the bundle metadata may further include information regarding attributes, characteristics, or settings of the bundle. The bundle metadata can be expressed as "metadata."

[0045] The "bundle management server" includes functionality for generating bundles upon request of a service provider or other bundle management server, encrypting the generated bundles, generating bundle remote management commands, or encrypting the generated bundle remote management commands. The bundle management server providing the above functions is represented by at least one of the following: SPBM (Secondary Platform Bundle Manager), RBM (Remote Bundle Manager), IDS (Image Delivery Server), "SM-DP" (Subscription Manager Data Preparation), "SM-DP+" (Subscription Manager Data Preparation plus), managing bundle server, "Managing SM-DP+" (Managing Subscription Manager Data Preparation plus), bundle encryption server, bundle generation server, bundle provider (Bundle Provisioner: BP), bundle provider, and BPC holder (Bundle Provisioning Credentials holder).

[0046] In the present invention, the bundle management server is responsible for managing the configuration of keys and certificates for downloading, installing or updating bundles in the SSP and remotely managing the status of the bundles. The bundle management server providing the above functions is represented by at least one of the following: SPBM (Secondary Platform Bundle Manager), RBM (Remote Bundle Manager), IDS (Image Delivery Server), "SM-SR" (Subscription Manager Secure Routing), "SM-SR+" (Subscription Manager Secure Routing Plus), "off-card entity of eUICC Profile Manager" or "PMC holder" (Profile Management Credentials holder), or EM (eUICC Manager).

[0047] In the present invention, the opening intermediation server receives an event registration request (Register Event Request, Event Register Request) from one or more bundle management servers or opening intermediation servers. Also, one or more opening intermediary servers can be used in combination, in which case the first opening intermediary server can receive event registration requests not only from the bundle management server but also from the second opening intermediary server. In the present invention, the function of the opening intermediary server can be integrated into the bundle management server. The activation intermediary server providing the above functions is represented by at least one of the following: SPBM (Secondary Platform Bundle Manager), RBM (Remote Bundle Manager), SPBDS (Secondary Platform Bundle Discovery Server), BDS (Bundle Discovery Server), "SM-DS" (Subscription Manager Discovery Service), DS (Discovery Service), Root SM-DS, Alternative SM-DS.

[0048] In the present invention, the bundle management server may be referred to as a server that combines a function of generating, encrypting and transmitting bundles or bundle remote management commands and a function of managing SSP settings and installed bundles. It may also be referred to as a service that includes the opening intermediary server function. Therefore, in various embodiments of the present invention, the bundle management server and the opening mediation server may be operated by a single bundle management server. Additionally, each function may be split among multiple bundle management servers that are separate from one another. In addition, in this specification, the bundle management server or the opening intermediary server may be referred to as a bundle server. The bundle server may be one of a bundle management server and an opening intermediary server, or may be a device including both the bundle management server and the opening intermediary server.

[0049] "Service Provider" refers to an entity that issues a request to a bundle management server to request bundle generation and provides a service to a terminal via the bundle. For example, it can refer to a mobile operator that provides network connection services through a bundle equipped with communication applications, and can also be used to refer to a mobile operator's Business Supporting System (BSS), Operational Support System (OSS), Point of Sale Terminal (POS terminal), and other IT systems.

[0050] Furthermore, in the present invention, the term "service provider" is not limited to referring to a single specific business entity, but may also be used to refer to a group or association or consortium of one or more business entities, or a representative representing the group or association. In addition, in the present invention, a service provider may be named as an operator (OP or Op.), bundle owner (BO), image owner (IO), etc., and each service provider may set or be assigned at least one name and / or unique identifier (Object Identifier: OID). If the service provider refers to a group or association of, or a representative of, one or more entities, the name or unique identifier of any group or association or representative may be a name or unique identifier shared by all entities affiliated with that group or association or all entities cooperating with that representative.

[0051] The term "Subscriber" is used to refer to either a service provider who has ownership rights to a terminal, or an end user who has ownership rights to a terminal. Generally, the former can be named an M2M device, and the latter a consumer device. In the case of an M2M terminal, there may be an end user who does not own the terminal but receives the terminal as a transfer or lease from a service provider, in which case the user may be different from or the same as the service provider.

[0052] "Subscriber intent" is a common term used to refer to a subscriber's intent to manage a bundle locally or remotely. In addition, in the case of local management, the subscriber intent can be used as a term that refers to the end user intent, and in the case of remote management, the subscriber intent can be used as a term that refers to the service provider intent.

[0053] "End User consent" is the term used to refer to whether a user consents to the performance of local and / or remote administration.

[0054] A "terminal" may be referred to as a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, subscriber unit, subscriber station (SS), wireless device, wireless communication device, wireless transmit / receive unit (WTRU), mobile node, mobile, or other terminology. Various embodiments of the terminal may include a cellular telephone, a smartphone with wireless communication capabilities, a personal digital assistant (PDA) with wireless communication capabilities, a wireless modem, a portable computer with wireless communication capabilities, a photographic device such as a digital camera with wireless communication capabilities, a gaming device with wireless communication capabilities, a music storage and playback appliance with wireless communication capabilities, an Internet appliance capable of wireless Internet access and browsing, as well as a portable unit or terminal that integrates a combination of such functions. Furthermore, the terminal may include, but is not limited to, a Machine to Machine (M2M) terminal and a Machine Type Communication (MTC) terminal / device. In the present invention, a terminal may also be referred to as an electronic device.

[0055] In the present invention, an electronic device may have an embedded SSP that allows bundles to be downloaded and installed. If the SSP is not built into the electronic device, the SSP, which is physically separate from the electronic device, can be inserted into the electronic device and connected with the electronic device. For example, the SSP may be in the form of a card that is inserted into the electronic device. The electronic device may include a terminal, where the terminal may be a terminal including an SSP capable of downloading and installing the bundle. The SSP can be built into the terminal, and when the terminal and the SSP are separated, the SSP can be inserted into the terminal and connected to the terminal when inserted into the terminal.

[0056] "Local Bundle Assistant (LBA)" refers to software or an application installed in a terminal or electronic device to control an SSP. This software or application may be referred to as the "Local Bundle Manager" (LBM).

[0057] "Loader (Secondary Platform Bundle Loader: SPBL)" refers to a management bundle that installs other bundles in the SSP and manages their activation, deactivation, and deletion. The terminal's LBA or a remote server can install, activate, deactivate, and remove specific bundles through the loader. In the present invention, the operation of a loader can also be described as the operation of the SSP that includes the loader.

[0058] An "Event" may be a common term for a Bundle Download, or Remote Bundle Management, or other bundle or SSP management / processing command. An event may be named as a remote bundle provisioning operation (RBP operation) or an event record, and each event may be referred to as data including a corresponding event identifier (Event ID, EventID) or matching identifier (Matching ID, MatchingID) and at least one of the address (FQDN, IP Address, or URL) or server identifier of the bundle management server or activation intermediary server where the event is stored. Bundle Download can be mixed with Bundle Installation. In addition, Event Type can be used as a term to indicate whether a particular event is a bundle download, remote bundle management (e.g., deletion, activation, deactivation, replacement, update, etc.), or other bundle or SSP management / processing command, and can be named as operation type (Operation Type or OperationType), operation class (Operation Class or OperationClass), event request type, event class, event request class, etc.

[0059] "Local Bundle Management (LBM)" can be named as Bundle Local Management, Local Management, Local Management Command, Local Command, Local Bundle Management Package (LBM Package), Bundle Local Management Package, Local Management Package, Local Management Command Package, Local Command Package. LBM is used to install any bundle via software installed on a terminal, change the state of a specific bundle (Enabled, Disabled, Deleted), or update the contents of a specific bundle (e.g., bundle nickname or bundle metadata). An LBM may also include one or more local management commands, where the bundles targeted by each local management command may be the same or different for each local management command.

[0060] "Remote Bundle Management (RBM)" can be named as Bundle Remote Management, Remote Management, Remote Management Command, Remote Command, Remote Bundle Management Package (RBM Package), Bundle Remote Management Package, Remote Management Package, Remote Management Command Package, Remote Command Package. The RBM can be used to install any bundle, change the state of a particular bundle (Enabled, Disabled, Deleted), or update the contents of a particular bundle (e.g., the bundle nickname or bundle metadata). An RBM may also contain one or more remote management commands, and the bundles targeted by each remote management command may be the same or different for each remote management command.

[0061] "Target Bundle" is the term used to refer to a bundle that is the target of a local or remote management command. "Bundle Rule" is used as a term to indicate information that a terminal must verify when performing local or remote management of a target bundle. Bundle rule may also be mixed up with terms such as bundle policy, rule, and policy.

[0062] "Certificate" or "Digital Certificate" refers to a digital certificate used for mutual authentication based on an asymmetric key consisting of a pair of a public key (PK) and a secret key (SK). Each certificate includes one or more public keys (PK), a public key identifier (PKID) corresponding to each public key, an identifier (Certificate Issuer ID) of the certificate issuer (CI) that issued the certificate, and a digital signature. In addition, a certificate issuer may be named a certification issuer, a certificate authority (CA), a certification authority, etc.

[0063] In the present invention, a public key (PK) and a public key identifier (PKID) may be used interchangeably to refer to a specific public key, or a certificate including the public key, or a part of a specific public key, or a part of a certificate including the public key, or a calculation result (e.g., hash) value of a specific public key, or a calculation result (e.g., hash) value of a certificate including the public key, or a calculation result (e.g., hash) value of a part of a specific public key, or a calculation result (e.g., hash) value of a part of a certificate including the public key, or a memory space in which data is stored.

[0064] "Certificate Chain" or "Certificate Hierarchy" may refer to the interrelationships of certificates when a certificate issued by a "Certificate Issuer" (primary certificate) is used to issue other certificates (secondary certificates) or when a secondary certificate is used to issue three or more certificates in a chain. At this time, the CI certificate used to issue the initial certificate can be named Root of Certificate, top-level certificate, Root CI, Root CI Certificate, Root CA, Root CA Certificate, etc.

[0065] Furthermore, in describing the present invention, if it is determined that a detailed description of related known functions or configurations may unnecessarily obscure the gist of the present invention, the detailed description will be omitted. Various embodiments of methods and apparatus for moving and installing bundles between terminals are described below.

[0066] FIG. 1 is a diagram illustrating the concept of SSP according to an embodiment of the present invention. According to one embodiment, as in the example of FIG. For example, the SSP 120 is embedded in the SoC 130 of the terminal 110 . In this case, the SoC 130 may be a communication processor, an application processor, or a processor in which these two processors are integrated. As another example, the SSP 120 may be a removable type 122 in the form of an independent chip that is not integrated into the SoC, or may be an internal type 124 that is built into the terminal 110 in advance.

[0067] According to one embodiment, the SSP 120 included in the terminal includes at least one of one or more telecom bundles, one or more payment bundles, or one or more electronic ID card bundles. For example, as shown in FIG. 1, when the SSP 120 includes a plurality of telecom bundles (140, 150), the terminal 110 uses the mobile communication network by operating the plurality of telecom bundles (140, 150) simultaneously or in a time-division manner depending on the settings. In addition, if the SSP 10 includes a payment bundle 170 and an electronic ID card bundle 180, the terminal 110 can use the payment bundle 170 to make online payments through a terminal app or offline payments through an external credit card PoS (Point of Sale) device, and can authenticate the identity of the terminal owner using the electronic ID card bundle 180.

[0068] FIG. 2 is a diagram showing the concept of the internal structure of a Smart Secure Platform (SSP) according to an embodiment of the present invention. According to one embodiment, as shown in the example of FIG. 2, the SSP 210 includes one Primary Platform (PP) 220 and at least one Secondary Platform Bundle (SPB) (230, 240) operating thereon.

[0069] According to one embodiment, primary platform 220 includes hardware (not shown) and at least one low level operating system (LLOS) 222 . According to one embodiment, the secondary platform bundle 230 includes a High-level Operating System (HLOS) 232 and at least one application 234 that runs on the HLOS.

[0070] According to one embodiment, each secondary platform bundle (230, 240) accesses resources such as the central processing unit and memory of the primary platform 220 using a Primary Platform Interface (PPI) 250 and is driven by the SSP 210 through the PPI.

[0071] FIG. 3 is a diagram illustrating an example of terminal internal components for a terminal to download and install a bundle at an SSP according to an embodiment of the present invention. According to one embodiment, as an example of FIG. 3, terminal 310 includes SSP 330 and / or LBA 312 for controlling SSP 330 . For example, the terminal 310 may be a terminal in which an SSP 330 is installed and an LBA 312 for controlling the SSP 330 is installed. For example, the SSP 330 may be internal to the terminal 310 or may be detachable.

[0072] According to one embodiment, SSP 330 includes at least one of a primary platform 331, a secondary platform bundle loader (SPBL) 333, and one or more secondary platform bundles (335, 337, 339). According to one embodiment, the secondary platform bundles (335, 337, 339) are not installed inside the SSP 330 at the time of shipment of the terminal, but can be downloaded and installed remotely after shipment.

[0073] According to one embodiment, as an example of FIG. 3, each bundle has a different bundle family identifier and / or bundle family manager identifier (341, 342, 343). Such bundle family identifier and bundle family manager identifier are used as information required for downloading and installing a bundle. That is, the SSP 330 or the SPBL 333 can allow or deny the download and installation of a particular bundle according to the bundle family identifier and the bundle family manager identifier.

[0074] FIG. 4 is a diagram illustrating an example of how two terminals interact to transmit bundles between them according to an embodiment of the present invention. According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, in the example of FIG. 4, a first terminal 400 includes an LBA 410 and an SSP 420, and a second terminal 450 includes an LBA 460 and an SSP 470.

[0075] According to one embodiment, a user sends commands to the terminal or receives information from the terminal that the user has to provide. For example, as in operations 4010 and 4060, the first user 440 and the second user 490 send commands to the LBAs (410, 460) of the first terminal 400 and the second terminal 450, or receive information from the LBAs (410, 460) that the users need to provide.

[0076] According to one embodiment, the above operations include a step in which the user selects the bundle to be transmitted. The above operation further includes a step of confirming information of the bundle that the user wishes to receive. Additionally, the above operations may further include an operation of approving whether or not the user is to transmit the bundle that he or she wishes to transmit. Additionally, the above operations may further include an operation of approving whether or not the user is to transmit the bundle that the user wishes to receive.

[0077] Additionally, according to one embodiment, the above operations may include a step in which the user selects a bundle to reactivate the discontinued bundle. Also, the above operation may further include a step of confirming information of the bundle for which the user has received a request to resume use. Additionally, the above operations may further include an operation of approving the bundle that the user creates upon resumption of use. The above operations may further include an operation in which the user approves resumption of use of the bundle for which a resumption of use request has been received.

[0078] The above-mentioned selection and approval operations may not be performed as independent operations, and one or more operations may be selected and performed independently of each other. In addition, in the 4020 and 4070 operations, the LBAs (410, 460) issue commands to the SSPs (420, 470) or transmit and receive data to and from the SSPs (420, 470). According to one embodiment, in the above operation, the LBA receives the user's command as described above and communicates the instruction to the SSP. In the above operation, when the LBA receives a command from the user and transmits the command to the SSP, the LBA receives the result sent by the SSP as a result.

[0079] According to another embodiment, in the above operations, the LBA transmits commands and data received from another terminal or an external server to the SSP. In the above operation, when the LBA transmits commands or data received from a different terminal or an external server to the SSP, the LBA receives the results sent by the SSP as a result.

[0080] According to one embodiment, in the above operations, the LBA defines new commands and data based on user commands or commands and data received from other terminals or external servers, and transmits them to the SSP. In the above operation, the LBA defines new commands and data based on user commands or commands and data received from other terminals or external servers, and transmits them to the SSP. The LBA then receives the results sent by the SSP as a result. According to one embodiment, in the above operations, the LBA and the SSP send and receive data to each other to set up the bundle.

[0081] According to one embodiment, in 4050 operation, two LBAs (410, 460) are connected to each other to give commands to each other or to send and receive data to each other. At this time, the connection in the operation of 4050 may be a connection between terminals and direct devices, or may be an indirect connection between devices in which an external entity (e.g., an external server) is connected between the two LBAs (410, 460) (not shown in the figure). A more detailed technique for the connection method between the two LBAs mentioned above will be described later with reference to the drawings.

[0082] According to one embodiment, in operations 4030 and 4080, the SSP (420, 470) generates, processes, or validates the necessary data within the SSP. According to one embodiment, in the above operation, the SSP checks the bundle migration settings. In addition, in the above operations, the SSP generates and utilizes bundle migration code. The above-mentioned bundle migration setting related operations and bundle migration code related operations are independent functions, and neither of the two functions may be executed, or only one of the two functions may be executed, or both of the two functions may be executed. In the event that either of the two functions is performed, the two functions can be performed as completely independent functions.

[0083] According to one embodiment, in the above operations, the SSP generates its own SSP information or verifies the SSP information received from the other terminal and / or server. In addition, through the above operations, the SSP can generate authentication data with which it can verify itself, and can also verify authentication data received from the other terminal.

[0084] According to one embodiment, in the above operations, the SSP generates a "certificate" as described in FIG. 5 and verifies the received "certificate." For examples of various "certificates" that the SSP can generate / verify, please refer to FIGS. 10 to 15 and 22 to 27, which will be described later. According to one embodiment, in the above operation, the SSP sets the state of the bundle. Various bundle states and setting conditions that the SSP can set are described below with reference to FIGS. 10 to 15 and 22 to 27. According to one embodiment, in the above operations, the SSP creates a bundle.

[0085] FIG. 5 is a diagram showing the configuration of an "Attestation" according to one embodiment of the present invention. According to one embodiment, the certificate optionally includes a "bundle classifier" (510). For example, the certificate may optionally include a bundle identifier (SPB ID) of one of the bundle classifiers as shown in FIG.

[0086] According to one embodiment, the certificate may also optionally further include other certificates (530). For various examples of other certificates included in the certificate, please refer to the description of FIGS. 10 to 15 below. According to one embodiment, the certificate may optionally further include an "SSP Identifier (SSP ID)" (540). According to one embodiment, the certificate may optionally further include information regarding actions taken by the SSP (reference numeral 550). For various examples of operations performed by the SSP, please refer to the explanations of FIGS. 10 to 15 below.

[0087] According to one embodiment, the certificate may optionally further include other data (reference number 520) than the information previously described (reference numbers 530, 540, 550) if necessary. For various examples of other data that may be included in the certificate, see the description of Figures 10-15 below. According to one embodiment, the certificate may include digital signature data for the information described above (reference number 560). This signature data may be a digital signature generated by a signing certificate of the SSP.

[0088] FIG. 6 is a diagram conceptually illustrating a procedure for a bundle to be transmitted from one terminal to another terminal according to an embodiment of the present invention. According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, in the example of FIG. 6, a first terminal 600 includes a first LBA 620 and a first SSP 610, and a second terminal 650 includes a second LBA 670 and a second SSP 660. For example, the first terminal 600 may be a terminal having a first SSP 610 installed and a first LBA 620 for controlling the first SSP 610, and the second terminal 650 may be a terminal having a second SSP 660 installed and a second LBA 670 for controlling the second SSP 660.

[0089] 6, in step 6000, the first SSP 610 and the first LBA 620 of the first terminal 600 and the second LBA 670 of the second terminal 650 perform a preparation procedure (bundle transmission preparation procedure) required for bundle transmission. For a more detailed explanation of the above procedure, please refer to the detailed explanation of FIG. 7 below. Referring to FIG. 6, in step 6005, a procedure (bundle transmission procedure) is performed in which a bundle is transmitted from a first terminal 600 to a second terminal 650. For a more detailed explanation of the above procedure, please refer to the detailed explanation of FIG. 8 below. Referring to FIG. 6, in step 6010, the first terminal 600 and the second terminal 660 perform a procedure for placing a transmitted bundle and a procedure for setting the state of the bundle (bundle transmission finalization procedure). For a detailed explanation of the above procedure, please refer to the detailed explanation of FIGS. 9 to 12 described later.

[0090] FIG. 7 is a diagram showing a detailed procedure of the procedure of preparing for bundle transmission among the procedures presented in FIG. More specifically, FIG. 7 is a diagram illustrating an exemplary procedure for a terminal to go through a preparation process required for transmitting a bundle to another terminal according to an embodiment of the present invention. The procedure of FIG. 7 may be referred to herein as a bundle transmission preparation procedure.

[0091] According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, in the example of FIG. 7, a first terminal 700 includes a first LBA 720 and a first SSP 710, and a second terminal 750 includes a second LBA 770 and a second SSP 760. For example, the first terminal 700 may be a terminal having a first SSP 710 installed and a first LBA 720 for controlling the first SSP 710, and the second terminal 750 may be a terminal having a second SSP 760 installed and a second LBA 770 for controlling the second SSP 760.

[0092] According to one embodiment, the first terminal 700 may have a bundle already installed and may further have metadata associated with the bundle. According to one embodiment, the first terminal 700 may have at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), or a bundle family custodian object identifier (SPB Family Custodian Object ID) associated with the bundle.

[0093] According to one embodiment, the first terminal 700 may have a "bundle transfer setting" associated with the bundle. The bundle transport settings may optionally include information related to whether transmission between devices of the bundle is possible. In addition, the bundle transfer setting may selectively further include information on whether the bundle can be used in multiple terminals. For example, if the bundle is "prohibited from being used simultaneously on multiple devices," i.e., "the bundle should only be used on one device at a time," information about this may be included.

[0094] Referring to FIG. 7, in step 7000, information on a bundle to be transmitted between devices is transmitted to a first LBA 720. This transmission process may be performed, for example, as shown in FIG. 7, through a process in which the user directly selects the bundle via a UI provided by the first terminal 700, or may be input to the first LBA 720 via push input from a remote server, or the first LBA 720 may connect to the remote server and read the information.

[0095] 7, in step 7005 , information related to the bundle selected in step 7000 is transmitted from the first LBA 720 to the first SSP 710 . For example, as shown in FIG. 7, information related to the selected bundle is communicated from the first LBA 720 to the first SSP 710 via a "Select SPB command." At this time, the information transmitted from the first LBA 720 to the first SSP 710 includes information for identifying the bundle selected in step 7000 .

[0096] Referring to FIG. 7, in step 7010, the first SSP 710 checks whether transmission is possible between devices of the bundle that has requested transmission. This process is performed by first identifying the bundle requested to be transmitted based on the information received in step 7005, and checking the "bundle transfer setting" associated with that bundle. During this process, if the 'bundle transfer setting' includes 'information on whether the bundle can be used in multiple terminals,' the first SSP 710 confirms this fact. Also, in step 7010, the first SSP 710 selectively sets a "bundle transfer code." The "bundle transfer code" must be a value that can identify the bundle as the code used to refer to the bundle during the process of transmitting the bundle between devices. The first SSP 710 binds the above-mentioned "bundle transfer code" with information on the bundle to be transmitted.

[0097] 7, in step 7015 , a response result to step 7005 is sent from the first SSP 710 to the first LBA 720 . For example, as shown in FIG. 7, a response to the "Select SPB command" is transmitted from the first SPB 710 to the first LBA 720 via a "Select SPB response." This response value contains the "bundle transfer code" described in step 7010.

[0098] 7, in step 7020, information required for bundle transmission between devices is transferred from a first LBA 720 of a first terminal 700 to a second LBA 770 of a second terminal 750. At this time, the information transmitted from the first LBA 720 to the second LBA 770 includes a "bundle transfer code." In addition, the information transmitted from the first LBA 820 to the second LBA 870 may further include information required for a connection to be established between the first LBA 720 and the second LBA 770 in step 7025 below. In addition, the information transmitted from the first LBA 720 to the second LBA 770 may selectively further include information notifying that a bundle transfer between devices is to be performed.

[0099] The information transmitted from the first LBA 720 to the second LBA 770 in step 7020 can be transmitted in various ways. For example, the first LBA 720 provides information that must be transmitted to the second LBA 770 to the user via the UI of the first terminal 700, and the user inputs the provided information into the second LBA 770 using the UI of the second terminal 750. Alternatively, the first LBA 720 creates the information that needs to be transmitted to the second LBA 770 in the form of an image (e.g., a QR code (registered trademark)) and displays it on the screen of the first terminal 700, and the user transmits the information to the second LBA 770 by scanning this image using the second terminal 750. However, the method of transmitting information from the first LBA 720 to the second LBA 770 is not limited to the above method.

[0100] Referring to FIG. 7, in step 7025, a connection is established (or configured) between the first LBA 720 and the second LBA 770. If the information required for connection is sent in step 7020, the first LBA 720 and the second LBA 770 can establish a connection using this information. The connection between the first LBA 820 and the second LBA 870 may be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE D2D (device-to-device), 5G D2D) or a long-distance connection with a remote server (e.g., a relay server) located between the first LBA 720 and the second LBA 770.

[0101] Referring to FIG. 7, although step 7025 is shown as the final step, this step is independent of the other steps previously described, i.e., steps 7000, 7005, 7010, 7015, and 7020, and can be performed regardless of the other steps and procedures. For example, step 7025 may occur between steps 7015 and 7020, in which case the information sent from the first LBA 720 to the second LBA 2 770 in step 7020 is sent over the connection established in step 7025.

[0102] FIG. 8 is a diagram showing a detailed procedure for transmitting a bundle among the procedures presented in FIG. More specifically, FIG. 8 is a diagram illustrating an exemplary procedure for one terminal to transmit a bundle to another terminal according to an embodiment of the present invention. In the present invention, the procedure of FIG. 8 may be referred to as a bundle transmission procedure.

[0103] According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, in the example of FIG. 8, a first terminal 800 includes a first LBA 820 and a first SSP 810, and a second terminal 850 includes a second LBA 870 and a second SSP 860. For example, the first terminal 800 may be a terminal having a first SSP 810 installed and a first LBA 820 for controlling the first SSP 810, and the second terminal 850 may be a terminal having a second SSP 860 installed and a second LBA 870 for controlling the second SSP 860.

[0104] 8, in step 8000, the second LBA 870 requests the second SSP 2860 for "SSP information (SspInfo)". When the second LBA 870 requests "SSP information (SspInfo)" from the second SSP 860 in step 8000, the second LBA 870 notifies the second SSP 860 that a bundle transfer between devices is to be performed. Also, step 8000 can be automatically performed immediately following the process shown in FIG. 8, or can be performed after receiving an external input. In this case, the "external input" can be performed through a process in which the user directly selects the bundle to be sent via a UI provided by the second terminal 850, or it can be input to the second LBA 870 via push input from a remote server, or the second LBA 870 can connect to a remote server and read the information.

[0105] Referring to FIG. 8, in step 8005, the second SSP 860 generates its own "SSP information (SspInfo)". "SSP information" includes information on the second SSP that must be provided for bundle transmission. At this time, the 'SSP information' includes information (certificate negotiation information) for a certificate negotiation process that the second SSP 860 must go through before receiving the bundle. This "certificate negotiation information" includes certificate information (SenderSpblVerification) that the second SSP 860 can use to verify other SSPs and certificate information (ReceiverSpblVerification) that other SSPs can use to verify itself. In addition, the “certificate negotiation information” may optionally further include a list of key agreement algorithms supported by the second SSP 860, and may optionally further include a list of encryption algorithms supported by the second SSP 860. In addition, the "SSP information" may selectively further include SSP version information including at least one of the version information of the primary platform included in the second SSP 960 and the standard supported by the loader.

[0106] 8, in step 8010, the second SSP 860 transmits the 'SSP information' generated in step 8005 to the first SSP 810 via the second LBA 870 and the first LBA 820. In the above described steps, according to step 8010, the second LBA 870 requests “SSP information (SspInfo)” from the second SSP 860, and after the second SSP 860 generates its own “SSP information”, the second SSP 860 transmits the “SSP information” to the first SSP 810 via the second LBA 870 and the first LBA 820. However, according to an embodiment, the process in which the second terminal 850 transmits the 'SSP information' to the first terminal 800 is as follows. For example, the second LBA 870 can generate “SSP information” by itself, and then transmit the “SSP information” to the first SSP 810 via the first LBA 820 .

[0107] Referring to FIG. 8, in step 8015, the first SSP 810 checks the received 'SSP information' and generates 'first terminal authentication information (Device 1.Auth)' that can authenticate itself based on the information. A more specific procedure for this process is as follows: The first SSP 810 checks the certificate information that can verify itself using the received “SenderSpblVerification” and selects at least one key agreement certificate (ssp1.Cert.KA). Alternatively, the first SSP 810 generates an asymmetric encryption key pair (key pair) public key "ssp1.ePK.KA" and private key "ssp1.ePK.KA" to be used for key agreement using the received "list of key agreement algorithms supported by the second SSP 860", and then selects the public key (ssp1.ePK.KA) of this key pair.

[0108] In addition, the first SSP 810 checks the certificate information that can verify itself using the received "SenderSpblVerification" and further selects at least one signing certificate (ssp1.Cert.DS). In addition, the first SSP 810 selects at least one piece of certificate information of the second SSP 860 to be verified using the received "ReceiverSpblVerification", and then sets the corresponding information as "CiPkIdToBeUsed". In addition, the first SSP 810 selects at least one encryption algorithm to be used in the future using the received "list of encryption algorithms supported by the second SSP 860", and then sets the corresponding information as "CryptoToBeUsed". The first SSP 810 also checks the received list of "version information of standards supported by the primary platform and loader contained in the second SSP 860" and determines whether there is a version of a standard that it also supports.

[0109] The "first terminal authentication information (Device1.Auth)" includes at least one of the above-mentioned "ssp1.Cert.KA", "ssp1.ePK.KA", "CiPkIdToBeUsed", and "CryptoToBeUsed". In addition, the "first terminal authentication information (Device 1.Auth)" may selectively further include the above-mentioned "ssp1.Cert.DS." In addition, the "first terminal authentication information (Device 1.Auth)" may selectively further include at least one of a bundle family identifier (SPB Family ID) and a bundle family custodian object ID (SPB Family Custodian Object ID) associated with a bundle to be transmitted in the future.

[0110] At this time, part or all of the "first terminal authentication information (Device 1.Auth)" mentioned above may be digitally signed so as to be verifiable using "ssp1.Cert.DS" to ensure the integrity of the information, and this digital signature data may be added as part of the "first terminal authentication information".

[0111] 8, in step 8020, the first SSP 810 transmits the first terminal authentication information (Device 1.Auth) generated in step 8015 to the second LBA 870 via the first LBA 820. Referring to FIG. 8, in step 8025, the second LBA 870 transmits the first terminal authentication information (Device 1.Auth) to the second SSP 860. Additionally, the second LBA 870 further transmits a “bundle transfer code” to the second SSP 860 .

[0112] Referring to FIG. 8, in step 8030, the second SSP 860 verifies the received "first terminal authentication information (Device 1.Auth)". If the second SSP 860 receives "ssp1.Cert.KA", it checks the signature on the certificate to verify the validity of the certificate. In addition, when the second SSP 860 receives "ssp1.ePK.KA" and its corresponding digital signature, it first checks the validity of "ssp1.Cert.DS", then uses this certificate to verify the digital signature and confirm the integrity of the received public key "ssp1.ePK.KA". The second SSP 860 also checks the received "CiPkIdToBeUsed" and selects at least one signing certificate (ssp2.Cert.DS) that can verify itself.

[0113] Also, although not shown in the figure, in step 8030, the second SSP 960 can generate a public key "ssp2.ePK.KA" and a private key "ssp2.eSK.KA" as an asymmetric encryption key pair to be used for key agreement, and then select the public key (ssp2.ePK.KA) of the key pair. In addition, the second SSP860 can select one of the key agreement public keys contained in "ssp1.Cert.KA" or "ssp1.ePK.KA", and then use this value and "ssp2.eSK.KA" to generate a session key (ShKey01) to be used for encryption during subsequent communications with terminal 1. ShKey01 must be the session key for the encryption algorithm contained in the received "CryptoToBeUsed".

[0114] In addition, in step 8030, the second SSP 860 generates "second terminal authentication information (Device 2.Auth)" that can authenticate itself. At this time, the "second terminal authentication information (Device 2.Auth)" may include "ssp2.Cert.DS". In addition, the "second terminal authentication information (Device 2.Auth)" may further include "ssp2.ePK.KA". In addition, the "second terminal authentication information (Device 2.Auth)" may further include a transaction ID that refers to the current session generated by the SSP2860. In addition, the "second terminal authentication information (Device 2.Auth)" may further include a "bundle transfer code." In addition, the “second terminal authentication information (Device 2.Auth)” may further include the SSP identifier of the second SSP 960. In addition, the "second terminal authentication information (Device 2.Auth)" may selectively further include at least one of a bundle family identifier (SPB Family ID) and a bundle family custodian object ID (SPB Family Custodian Object ID) associated with a bundle to be subsequently transmitted.

[0115] At this time, a part or all of the "second terminal authentication information (Device 2.Auth)" mentioned above is digitally signed so that it can be verified using "ssp2.Cert.DS" to ensure the integrity of the information, and this digital signature data can be added as part of the "second terminal authentication information". In addition, a part or the whole of the "second terminal authentication information (Device 2.Auth)" is encrypted using the session key (ShKey01) generated in advance.

[0116] 8, in step 8035, the second SSP 860 transmits the second terminal authentication information (Device 2.Auth) generated in step 8030 to the first SSP 810 via the second LBA 870 and the first LBA 820. At this time, a "bundle transfer code" may optionally also be transmitted.

[0117] Referring to FIG. 8, in step 8040, the first SSP 810 verifies the received "second terminal authentication information (Device 2.Auth)". The first SSP 810 verifies the signature of the received "ssp2.Cert.DS" to verify the validity of the certificate. The first SSP 810 also checks whether the received bundle family identifier (SPB Family ID) and / or bundle family custodian object ID (SPB Family Custodian Object ID) are correctly set values ​​associated with the bundle it is trying to send. The first SSP 810 also stores the received transaction ID and / or the SSP identifier of the second SSP 860. In addition, the first SSP 810 binds the received transaction ID or the SSP identifier of the second SSP 960 to the currently ongoing session or the bundle to be transmitted.

[0118] During this process, if the “second terminal authentication information (Device 2.Auth)” contains encrypted data, the first SSP 810 generates a session key (ShKey01) using the transmitted “ssp2.ePK.KA” and the private key corresponding to the key agreement public key contained in its own “ssp1.Cert.KA” or “ssp1.ePK.KA”, and then performs the verification process after decrypting the encrypted data using this session key. Also, during this process, if the "second terminal authentication information (Device 2.Auth)" includes a digital signature, the first SSP 810 verifies the validity of the received digital signature using "ssp2.Cert.DS".

[0119] Also, in step 8040, although not shown in FIG. 8, the first SSP 810 can generate an asymmetric encryption key pair, public key 'ssp1.bundle.ePK.KA' and private key 'ssp1.bundle.eSK.KA', used for key agreement. At this time, the key pair "ssp1.bundle.ePK.KA" and "ssp1.bundle.eSK.KA" can also be set to the same values ​​as the previously generated "ssp1.ePK.KA" and "ssp1.ePK.KA". Alternatively, the key pair "ssp1.bundle.ePK.KA" and "ssp1.bundle.eSK.KA" can be set to the same values ​​as the "public key contained in "ssp1.Cert.KA" and its corresponding private key" previously used. In addition, the first SSP 810 can generate a session key (ShKey02) using "ssp1.bundle.eSK.KA" and "ssp2.ePK.KA". If a private key corresponding to the public key contained in “ssp1.ePK.KA” or “ssp1.Cert.Ka” is reused for “ssp1.bundle.eSK.KA”, the value of the session key (ShKey02) can also be set to the previously generated value of ShKey01.

[0120] Also, at step 8040, the first SSP 810 configures a bundle and / or metadata associated with the bundle to be transmitted to the second terminal 850. At this time, the first SSP 810 uses the received "bundle transfer code" to identify the bundle it is about to transmit. The configured bundle may also include "ssp1.Cert.DS". The configured bundle may further include "ssp1.bundle.ePK.KA". The configured bundle may further include a transaction ID that identifies the session. In addition, the configured bundle may optionally further include at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), and a bundle family custodian object ID (SPB Family Custodian Object ID) associated with the bundle to be transmitted. According to one embodiment, a "bundle migration setting" may be included in the bundle (or metadata associated with the bundle) configured in step 8040.

[0121] According to one embodiment, at step 8040, the configured bundle is appended with digital signature data generated using "ssp1.Cert.DS". That is, digital signature data generated for some or all of the components of the bundle specified above is added as part of the bundle. In addition, some or all of the bundles that are configured are encrypted using ShKey02.

[0122] Referring to FIG. 8, in step 8045, the first SSP 810 transmits the bundle created (configured) in step 8040 to the second LBA 870 via the first LBA 820. At this time, metadata associated with the transmitted bundle may optionally also be transmitted. Additionally, a "bundle movement setting" associated with the bundle being transmitted may also be transmitted. For example, the "bundle transfer settings" may not be included in the bundle or metadata, but may be sent in a separate format (eg, a message).

[0123] FIG. 9 is a diagram showing detailed steps of the steps presented in FIG. 6 for completing the transmission of a bundle. More specifically, FIG. 9 is a diagram illustrating a possible example of a process in which a bundle is installed in a terminal and a bundle state is set after a bundle is transmitted according to an embodiment of the present invention. According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, in the example of FIG. 9, a first terminal 900 includes a first LBA 920 and a first SSP 910, and a second terminal 950 includes a second LBA 970 and a second SSP 960. For example, the first terminal 900 may be a terminal having a first SSP 910 installed and a first LBA 920 for controlling the first SSP 910, and the second terminal 950 may be a terminal having a second SSP 960 installed and a second LBA 970 for controlling the second SSP 960.

[0124] 1. [Bundle installation] 9, in step 9000, the second LBA 970 and the second SSP 960 cooperate with each other to install a bundle in the second terminal 950. In this process, the following steps are performed together: If metadata is sent, the second LBA 970 or the second SSP 960 verifies the contents included in the metadata. If the “Bundle Migration Setting” is sent, the second LBA 970 communicates this information to the second SSP 960 . If a transaction ID is sent, the second LBA 970 or the second SSP 960 checks whether this transaction ID is the same as the transaction ID used in the current session.

[0125] If at least one of the bundle identifier (SPB ID), bundle family identifier (SPB Family ID), and bundle family custodian object identifier (SPB Family Custodian Object ID) is sent, the second LBA 970 or the second SSP 960 checks whether this information matches the information of the bundle it is currently attempting to receive. If “ssp1.Cert.DS” is sent, the second SSP 960 verifies the validity of this certificate and authenticates the first SSP 910 . If the transmitted data contains encrypted data, the second SSP960 generates a session key (ShKey02) using the transmitted "ssp1.bundle.ePK.KA" and its own "ssp2.eSK.KA", and uses this session key to decrypt the encrypted data and then perform verification. If the received data includes a digital signature, the second SSP 960 verifies "ssp1.Cer.DS" and then uses this certificate to verify the validity of the digital signature.

[0126] 2. [Check whether the item can be used multiple times] Although not shown in the figure, the second LBA 970 and / or the second SSP 960 can selectively determine whether the bundle can be used in multiple terminals. Some possible ways to make this determination are as follows: As one possible example, if the bundle migration settings include whether the bundle can be used overlappingly on multiple terminals, the second LBA 970 and / or the second SSP 960 can make a determination by checking this information. As another possible example, the second LBA 970 and / or the second SSP 960 may use the received bundle family identifier (SPB Family ID) and / or bundle family custodian object ID (SPB Family Custodian Object ID) to determine whether the bundle can be used in multiple terminals. This process may be performed as part of step 9000, regardless of the order and sequence of steps performed in step 9000, or may be performed after step 9000.

[0127] 3. [Bundle status setting] If the bundle is determined to be a bundle that can be used in multiple terminals, the process of additionally setting the state of the bundle may not be necessary. Alternatively, even if the second LBA 970 and / or the second SSP 960 does not determine whether the bundle is used in duplicate, the process of additionally setting the state of the bundle by implementing the second LBA 970 and / or the second SSP 960 may not be necessary.

[0128] FIG. 10 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. More specifically, FIG. 10 is a diagram illustrating another example of a process in which a bundle is installed in a terminal and a bundle state is set after a bundle is transmitted according to an embodiment of the present invention. According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, as in the example of FIG. 10, a first terminal 1000 includes a first LBA 1020 and a first SSP 1010, and a second terminal 1050 includes a second LBA 1070 and a second SSP 1060. For example, the first terminal 1000 may be a terminal having a first SSP 1010 installed and a first LBA 1020 for controlling the first SSP 1010, and the second terminal 1050 may be a terminal having a second SSP 1060 installed and a second LBA 1070 for controlling the second SSP 1060.

[0129] 1. [Bundle installation] 10, in step 10000, the second LBA 1070 and the second SSP 1060 cooperate with each other to install a bundle in the second terminal 1050. For a detailed description of this, please refer to the "Install Bundle" process of FIG.

[0130] 2. [Check whether the item can be used multiple times] Although not shown in the figure, the second LBA 1070 and / or the second SSP 1060 can selectively determine whether the bundle can be used in multiple terminals. For a detailed description of this, please refer to the "check whether overlapping is possible" process in FIG.

[0131] 3. [Bundle status setting] If it is determined that the bundle cannot be used on multiple devices, the bundle status is additionally set as follows: Alternatively, even if the second LBA 1070 and / or the second SSP 1060 do not determine whether the bundle is to be used redundantly, the implementation of the second LBA 1070 and / or the second SSP 1060 may perform a process of additionally setting the state of the bundle as described below.

[0132] Referring to FIG. 10, in step 10005, the second SSP 1060 sets the state of the bundle as "IN TRANSITION." "IN TRANSITION" means that the bundle has been successfully installed but is not yet usable (and can only be changed to a usable state (Disabled, Enable, Active state) by additional actions such as "a request from another terminal (e.g., a request made by sending a "finalizationResponse" or "recoveryRequest")" and / or "a request from an external server (not described in this invention)").

[0133] Referring to FIG. 10, in step 10010, the second LBA 1070 requests a “certificate” from the second SSP 1060. Referring to FIG. 10, in step 10015, the second SSP 1060 generates a “certificate.” In Figure 10, this certificate is called "finalizationRequest." The structure of this certificate follows the structure disclosed in FIG.

[0134] At this time, one example of a possible certificate configuration is as follows: The "finalizationRequest" includes the "bundle classifier" of the bundle in reference numeral 510 (see FIG. 5 below). The "finalizationRequest" includes the "SSP Identifier" of the second SSP at 540. The "finalizationRequest" includes information at 550 indicating that the second SSP has set the state of the bundle to "IN TRANSITION". The "finalizationRequest" optionally includes at 520 the time when the second SSP changed the state of the bundle to "IN TRANSITION" state or the time when it generated the certificate. The "finalizationRequest" includes the signature information of the second SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0135] Referring to FIG. 10, in step 10020, the second SSP 1060 transmits a “finalizationRequest” to the first SSP 1010. For example, the second SSP 1060 transmits a "finalizationRequest" to the first SSP 1010 through the following process. That is, the second SSP 1060 transmits a 'finalizationRequest' to the second LBA 1070 in response to step 10010, and the second LBA transmits the 'finalizationRequest' to the first SSP via the first LBA 1020.

[0136] Referring to FIG. 10, in step 10025, the first SSP 1010 verifies the received "finalizationRequest." This verification process includes checking the validity of the signature of the second SSP included in the "finalizationRequest". This verification process also includes a process of checking whether the 'bundle classifier' included in the 'finalizationRequest' matches the bundle classifier of the bundle. This verification process also includes a process of checking whether the 'SSP identifier' included in the 'finalizationRequest' is a correct identifier of the second SSP. Also, this verification process further includes a process of checking whether command information included in the 'finalizationRequest' changes the state of the bundle to an 'IN TRANSITION' state.

[0137] Also, in step 10025, the first SSP 1010 deletes the bundle after verification. Also, in step 10025, the first SSP 1010 generates a "certificate." In Figure 10, this certificate is called "finalizationResponse." The structure of this certificate follows the structure disclosed in FIG.

[0138] At this time, an example of a possible certificate configuration is as follows: The "finalizationResponse" includes the "bundle classifier" of the bundle in reference number 510 (see FIG. 5 below). The "finalizationResponse" includes the "SSP Identifier" of the first SSP at 540. The "finalizationResponse" includes information at 550 indicating that the first SSP has deleted the bundle. The "finalizationResponse" optionally includes the time at which the first SSP deleted the bundle or created the certificate at 520. The "finalizationResponse" includes the signature information of the first SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with the signing certificate of the first SSP.

[0139] And other examples of possible certificate configurations are as follows: The 'finalizationResponse' contains the 'finalizationRequest' received at 530 . At this time, some information in the received 'finalizationRequest' may be omitted if necessary. For example, the signature information of the second SSP included in the "finalizationRequest" may be omitted in some cases. Also, for example, the time information included in the "finalizationRequest" may be omitted in some cases. The "finalizationResponse" includes the "SSP Identifier" of the first SSP at 540. The "finalizationResponse" includes information at 550 indicating that the first SSP has deleted the bundle. The "finalizationResponse" optionally includes the time at which the first SSP deleted the bundle or created the certificate at 520. The "finalizationResponse" includes the signature information of the first SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with the signing certificate of the first SSP.

[0140] Referring to FIG. 10, in step 10030, the first SSP 1010 transmits a “finalizationResponse” to the second SSP 1060. For example, the first SSP 1010 transmits a “finalizationResponse” to the second SSP 1060 via the first LBA 1020 and the second LBA 1070 .

[0141] Referring to FIG. 10, in step 10035, the second SSP 1060 verifies the received "finalizationResponse." This verification process may include checking the validity of the signature of the first SSP included in the "finalizationResponse". Also, this verification step may optionally further include a step of checking whether the 'bundle classifier' included in the 'finalizationResponse' matches the bundle classifier of the bundle. Also, this verification process may optionally further include a process of checking whether the 'finalizationRequest' included in the 'finalizationResponse' matches the information sent by the 'finalizationRequest'. This verification process may further include a process of checking the "SSP Identifier" included in the "finalizationResponse". Also, this verification process may further include a process of confirming whether the command information included in the 'finalizationResponse' is to delete the bundle.

[0142] In step 10035, the second SSP 1060 changes the state of the bundle after the verification to one of the available states (one of Disabled, Enable, and Active). For example, as shown, the second SSP 1060 changes the state of the bundle to a "Disabled" state. 10, in step 10040, the second SSP 1060 transmits a result (eg, success / failure) of the operation performed in step 10035 to the second LBA 1070.

[0143] FIG. 11 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. More specifically, FIG. 11 is a diagram illustrating another example of a process in which a bundle is installed in a terminal and a bundle state is set after a bundle is transmitted according to an embodiment of the present invention.

[0144] According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, as in the example of FIG. 11, a first terminal 1100 includes a first LBA 1120 and a first SSP 1110, and a second terminal 1150 includes a second LBA 1170 and a second SSP 1160. For example, the first terminal 1100 may be a terminal having a first SSP 1110 installed and a first LBA 1120 for controlling the first SSP 1110, and the second terminal 1150 may be a terminal having a second SSP 1160 installed and a second LBA 1170 for controlling the second SSP 1160.

[0145] 1. [Bundle installation] Referring to FIG. 11, in step 11000, the second LBA 1170 and the second SSP 1160 cooperate with each other to install a bundle in the second terminal 1150. For a detailed description of this, please refer to the "Install Bundle" process of FIG.

[0146] 2. [Check whether the item can be used multiple times] Also, although not shown in the figure, the second LBA 1170 and / or the second SSP 1160 can selectively determine whether the bundle can be used in multiple terminals, and for a detailed explanation of this, please refer to the ``Determine whether it can be used in multiple terminals'' process of Figure 9.

[0147] 3. [Bundle status setting] If it is determined that the bundle cannot be used on multiple devices, the bundle status is additionally set as follows: Alternatively, even if the second LBA 1170 and / or the second SSP 1160 do not determine whether the bundle is to be used in duplicate, the implementation of the second LBA 1170 and / or the second SSP 1160 performs a process of additionally setting the state of the bundle as described below.

[0148] Referring to FIG. 11, in step 11005, the second SSP 1160 sets the state of the bundle to "IN TRANSITION." For an explanation of the 'IN TRANSITION' state, please refer to the explanation of step 10005. Referring to FIG. 11, in step 11010, the second LBA 1170 requests a “certificate” from the second SSP 1160.

[0149] Referring to FIG. 11, in step 11015, the second SSP 1160 generates a “certificate.” In Figure 11, this certificate is called "finalizationRequest." The structure of this certificate is according to the structure disclosed in FIG.

[0150] At this time, an example of a possible certificate configuration is as follows: The "finalizationRequest" includes the "bundle classifier" of the bundle in reference numeral 510 (see FIG. 5 below). The "finalizationRequest" includes the "SSP Identifier" of the second SSP at 540. The "finalizationRequest" includes information at 550 indicating that the second SSP has set the state of the bundle as "IN TRANSITION". The 'finalizationRequest' optionally includes, at 520, the time when the second SSP changed the state of the bundle to 'IN TRANSITION' or the time when it created the certificate. The "finalizationRequest" includes the signature information of the second SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0151] Referring to FIG. 11, in step 11020, the second SSP 1160 transmits a "finalizationRequest" to the first SSP 1110. For example, the second SSP 1160 transmits a "finalizationRequest" to the first SSP 1110 through the following process. That is, the second SSP 1160 transmits a 'finalizationRequest' to the second LBA 1170 in response to step 11010, and the second LBA transmits the 'finalizationRequest' to the first SSP via the first LBA 1120.

[0152] Referring to FIG. 11, in step 11025, the first SSP 1110 verifies the received "finalizationRequest." This verification process may include checking the validity of the signature of the second SSP included in the "finalizationRequest." Also, this verification process may further include a process of checking whether the 'bundle classifier' included in the 'finalizationRequest' matches the bundle classifier of the bundle. Also, this verification process may further include a process of checking whether the 'SSP Identifier' included in the 'finalizationRequest' is a correct identifier of the second SSP. Also, this verification process may further include a process of confirming whether the command information included in the 'finalizationRequest' is to change the state of the bundle to an 'IN TRANSITION' state.

[0153] Also, in step 11025, the first SSP 1110 sets the state of the bundle after verification to the "IN TRANSITION" state. Also, in step 11025, the first SSP 1110 generates a "certificate." In Figure 11, this certificate is called "finalizationResponse." The structure of this certificate is according to the structure disclosed in FIG.

[0154] At this time, an example of a possible certificate configuration is as follows: The "finalizationResponse" includes the "bundle classifier" of the bundle in reference number 510 (see FIG. 5 below). The "finalizationResponse" includes the "SSP Identifier" of the first SSP at 540. The "finalizationResponse" includes information at 550 indicating that the first SSP has changed the state of the bundle to "IN TRANSITION". The "finalizationResponse" optionally includes the time at which the first SSP changed the state of the bundle or created the certificate at 520. The "finalizationResponse" includes the signature information of the first SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with the signing certificate of the first SSP.

[0155] And other examples of possible certificate configurations are as follows: The 'finalizationResponse' contains the 'finalizationRequest' received at 530 . At this time, some information in the received 'finalizationRequest' may be omitted if necessary. For example, the signature information of the second SSP included in the "finalizationRequest" may be omitted in some cases. Also, for example, the time information included in the "finalizationRequest" may be omitted in some cases. The "finalizationResponse" includes the "SSP Identifier" of the first SSP at 540. The "finalizationResponse" includes information at 550 indicating that the first SSP has changed the state of the bundle to "IN TRANSITION". The "finalizationResponse" optionally includes the time at which the first SSP changed the state of the bundle or created the certificate at 520. The "finalizationResponse" includes the signature information of the first SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with the signing certificate of the first SSP.

[0156] Referring to FIG. 11, in step 11030, the first SSP 1110 transmits a “finalizationResponse” to the second SSP 1160. For example, the first SSP 1110 transmits a “finalizationResponse” to the second SSP 1160 via the first LBA 1120 and the second LBA 1170 .

[0157] Referring to FIG. 11, in step 11035, the second SSP 1160 verifies the received "finalizationResponse." This verification process may include checking the validity of the signature of the first SSP included in the "finalizationResponse". Also, this verification step may optionally further include a step of checking whether the 'bundle classifier' included in the 'finalizationResponse' matches the bundle classifier of the bundle. Also, this verification process may optionally further include a process of checking whether the 'finalizationRequest' included in the 'finalizationResponse' matches the information sent by the 'finalizationRequest'. This verification process may further include a process of checking the "SSP Identifier" included in the "finalizationResponse". Also, this verification process may further include a process of verifying whether the command information included in the 'finalizationResponse' is correct.

[0158] In step 11035, the second SSP 1160 changes the state of the bundle after the verification to one of the available states (one of Disabled, Enable, and Active). For example, as shown, the second SSP 1160 transforms the state of the bundle to a "Disabled" state.

[0159] Also, in step 11035, the second SSP 1160 generates a “certificate”. In Figure 11, this certificate is called "spblAttestation." The structure of this certificate is according to the structure disclosed in FIG.

[0160] At this time, an example of a possible certificate configuration is as follows: "spblAttestation" includes the "bundle classifier" of the bundle in reference number 510 (see FIG. 5 below). "spblAttestation" contains the "SSP Identifier" of the second SSP at 540. "spblAttestation" contains information at 550 indicating that the second SSP has changed the state of the bundle to available. "spblAttestation" optionally contains the time the second SSP changed the state of the bundle or created the certificate at 520. "spblAttestation" contains the signature information of the second SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0161] And other examples of possible certificate configurations are as follows: "spblAttestation" contains the "finalizationResponse" received at 530. At this time, some information in the received 'finalizationResponse' may be omitted if necessary. For example, some of the signature information included in the "finalizationResponse" may be omitted in some cases. Also, for example, some of the time information included in the "finalizationResponse" may be omitted depending on the circumstances. "spblAttestation" contains the "SSP Identifier" of the second SSP at 540. "spblAttestation" contains information at 550 indicating that the second SSP has changed the state of the bundle to available. "spblAttestation" optionally contains the time the second SSP changed the state of the bundle or created the certificate at 520. "spblAttestation" contains the signature information of the second SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0162] Referring to FIG. 11, in step 11040, the second SSP 1160 transmits “spblAttestation” to the first SSP 1110. For example, the second SSP 1160 transmits “spblAttestation” to the first SSP via the second LBA 1170 and the first LBA 1120 .

[0163] Referring to FIG. 11, in step 11045, the first SSP 1110 verifies the received 'spblAttestation'. This verification process may include checking the validity of the signature of the second SSP contained in "spblAttestation." Also, this verification process may further include a process of checking whether the 'bundle classifier' included in 'spblAttestation' matches the bundle classifier of the bundle. Also, this verification process may optionally further include a process of checking whether the 'finalizationResponse' included in the 'spblAttestation' matches the information sent by the user. Also, this verification process may further include a process of checking whether the 'SSP Identifier' included in 'spblAttestation' is a correct identifier of the second SSP. Also, this verification process may further include a process of checking whether the command information included in 'spblAttestation' is to change the state of the bundle to an available state.

[0164] Also, in step 11045, the first SSP 1110 deletes the bundle after verification.

[0165] FIG. 12 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. More specifically, FIG. 12 is a diagram illustrating another example of a process in which a bundle is installed in a terminal and a bundle state is set after a bundle is transmitted according to an embodiment of the present invention.

[0166] According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, as in the example of FIG. 12, a first terminal 1200 includes a first LBA 1220 and a first SSP 1210, and a second terminal 1250 includes a second LBA 1270 and a second SSP 1260. For example, the first terminal 1200 may be a terminal having a first SSP 1210 installed and a first LBA 1220 for controlling the first SSP 1210, and the second terminal 1250 may be a terminal having a second SSP 1260 installed and a second LBA 1270 for controlling the second SSP 1260.

[0167] 1. [Bundle installation] Referring to FIG. 12, in step 12000, the second LBA 1270 and the second SSP 1260 cooperate with each other to install a bundle in the second terminal 1250. For a detailed description of this, please refer to the "Install Bundle" process of FIG.

[0168] 2. [Check whether the item can be used multiple times] Also, although not shown in the figure, the second LBA 1270 and / or the second SSP 1260 can selectively determine whether the bundle can be used in multiple terminals, and for a detailed explanation of this, please refer to the ``Determine whether it can be used in multiple terminals'' process of Figure 9.

[0169] 3. [Bundle status setting] If it is determined that the bundle cannot be used on multiple devices, the bundle status is additionally set as follows: Alternatively, even if the second LBA 1270 and / or the second SSP 1260 do not determine whether the bundle is to be used redundantly, the implementation of the second LBA 1270 and / or the second SSP 1260 performs a process of additionally setting the state of the bundle as described below.

[0170] Referring to FIG. 12, in step 12005, the second SSP 1260 sets the state of the bundle to "IN TRANSITION." For an explanation of the 'IN TRANSITION' state, please refer to the explanation of step 10005. Referring to FIG. 12, in step 12010, the second LBA 1270 requests a “certificate” from the second SSP 1260.

[0171] Referring to FIG. 12, in step 12015, the second SSP 1260 generates a “certificate.” In Figure 12, this certificate is called "finalizationRequest." The structure of this certificate is according to the structure disclosed in FIG.

[0172] At this time, an example of a possible certificate configuration is as follows: The "finalizationRequest" includes the "bundle classifier" of the bundle in reference numeral 510 (see FIG. 5 below). The "finalizationRequest" includes the "SSP Identifier" of the second SSP at 540. The "finalizationRequest" includes information at 550 indicating that the second SSP has set the state of the bundle to "IN TRANSITION". The "finalizationRequest" optionally includes at 520 the time when the second SSP changed the state of the bundle to "IN TRANSITION" state or the time when it generated the certificate. The "finalizationRequest" includes the signature information of the second SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0173] Referring to FIG. 12, in step 12020, the second SSP 1260 transmits a "finalizationRequest" to the first SSP 1210. For example, the second SSP 1260 transmits a "finalizationRequest" to the first SSP 1210 through the following process. That is, the second SSP 1260 transmits a 'finalizationRequest' to the second LBA 1270 in response to step 12010, and the second LBA transmits the 'finalizationRequest' to the first SSP via the first LBA 1220.

[0174] Referring to FIG. 12, in step 12025, the first SSP 1210 verifies the received "finalizationRequest." This verification process may include checking the validity of the signature of the second SSP included in the "finalizationRequest." Also, this verification process may further include a process of checking whether the 'bundle classifier' included in the 'finalizationRequest' matches the bundle classifier of the bundle. Also, this verification process may further include a process of checking whether the 'SSP identifier' included in the 'finalizationRequest' is a correct identifier of the second SSP. Also, this verification process may further include a process of confirming whether the command information included in the 'finalizationRequest' is to change the state of the bundle to an 'IN TRANSITION' state.

[0175] In step 12025, the first SSP 1210 sets the state of the bundle after the verification to the “SUSPENSION” state. "SUSPENSION" means a state in which the bundle cannot be used (and can be changed to a usable state (Disabled, Enable, Active state) only at the request of another terminal (e.g., a request made by sending a "recoveryRequest") and / or at the request of an external server (not described in this invention)). Although not shown in the figure, the above-mentioned "SUSPENSION" state can also be replaced with an "IN TRANSITION" state.

[0176] Also, in step 12025, the first SSP 1210 generates a "certificate." In Figure 12, this certificate is called "finalizationResponse." The structure of this certificate is according to the structure disclosed in FIG.

[0177] At this time, an example of a possible certificate configuration is as follows: The "finalizationResponse" includes the "bundle classifier" of the bundle in reference number 510 (see FIG. 5 below). The "finalizationResponse" includes the "SSP Identifier" of the first SSP at 540. The "finalizationResponse" includes information 550 indicating that the first SSP has changed the state of the bundle to "SUSPENSION" (or "IN TRANSITION"). The "finalizationResponse" optionally includes the time at which the first SSP changed the state of the bundle or created the certificate at 520. The "finalizationResponse" includes the signature information of the first SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with the signing certificate of the first SSP.

[0178] And other examples of possible certificate configurations are as follows: The 'finalizationResponse' contains the 'finalizationRequest' received at 530 . At this time, some information in the received 'finalizationRequest' may be omitted if necessary. For example, the signature information of the second SSP included in the "finalizationRequest" may be omitted in some cases. Also, for example, the time information included in the "finalizationRequest" may be omitted in some cases. The "finalizationResponse" includes the "SSP Identifier" of the first SSP at 540. The "finalizationResponse" includes information 550 indicating that the first SSP has changed the state of the bundle to "SUSPENSION" (or "IN TRANSITION"). The "finalizationResponse" optionally includes the time at which the first SSP changed the state of the bundle or created the certificate at 520. The "finalizationResponse" includes the signature information of the first SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with the signing certificate of the first SSP.

[0179] Referring to FIG. 12, in step 12030, the first SSP 1210 transmits a “finalizationResponse” to the second SSP 1260. For example, the first SSP 1210 transmits a “finalizationResponse” to the second SSP 1260 via the first LBA 1220 and the second LBA 1270 .

[0180] Referring to FIG. 12, in step 12035, the second SSP 1260 verifies the received "finalizationResponse." This verification process may include checking the validity of the signature of the first SSP included in the "finalizationResponse". Also, this verification step may optionally further include a step of checking whether the 'bundle classifier' included in the 'finalizationResponse' matches the bundle classifier of the bundle. Also, this verification process may optionally further include a process of checking whether the 'finalizationRequest' included in the 'finalizationResponse' matches the information sent by the 'finalizationRequest'. This verification process may further include a process of checking the "SSP Identifier" included in the "finalizationResponse". Also, this verification process may further include a process of verifying whether the command information included in the 'finalizationResponse' is correct.

[0181] In step 12035, the second SSP 1260 changes the state of the bundle after the verification to one of the available states (one of Disabled, Enable, and Active). For example, as shown, the second SSP 1260 changes the state of the bundle to a "Disabled" state.

[0182] 12, in step 12040, the second SSP 1260 transmits a result (eg, success / failure) of the operation performed in step 12035 to the second LBA 1270.

[0183] FIG. 13 is a diagram showing an example of a procedure for making a discontinued bundle available for further use. More specifically, this figure shows an example of a procedure for setting a bundle in the "IN TRANSITION" or "SUSPENSION" state to a more usable state.

[0184] According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, as in the example of FIG. 13, a first terminal 1300 includes a first LBA 1320 and a first SSP 1310, and a second terminal 1350 includes a second LBA 1370 and a second SSP 1360. For example, the first terminal 1300 may be a terminal having a first SSP 1310 installed and a first LBA 1320 for controlling the first SSP 1310, and the second terminal 1350 may be a terminal having a second SSP 1360 installed and a second LBA 1370 for controlling the second SSP 1360.

[0185] Possible examples of when the state of the bundle before the procedure disclosed in FIG. 13 is performed is set to "IN TRANSITION" or "SUSPENSION" are as follows: For example, when the transmission of the bundle disclosed in FIG. 11 is completed, if step 11025 is performed but step 11045 is not performed, the state of the bundle in the first terminal 1300 will be set to the “IN TRANSITION” state. In yet another example, when step 12025 is performed at the stage where the transmission of the bundle disclosed in FIG. 12 is completed, the state of the bundle in the first terminal 1300 may be set to the "IN TRANSITION" state or the "SUSPENSION" state.

[0186] Referring to FIG. 13, in step 13000, information on the bundle for which resumption of use is requested is transmitted to the second LBA 1370. This transmission process can be performed by the user directly selecting the bundle via a UI provided by the second terminal 1350, or it can be input to the second LBA 1370 via push input from a remote server, or the second LBA 1370 can connect to the remote server and read the information.

[0187] 13, in step 13005 , information on the bundle selected in step 13000 is transferred from the second LBA 1370 to the second SSP 1360 . At this time, the information transmitted from the second LBA 1370 to the second SSP 1360 includes information for identifying the bundle selected in step 13000 . Referring to FIG. 13, in step 13010, the second SSP 1360 deletes the bundle. The second SSP 1360 also generates a "certificate." In Figure 13, this certificate is called "recoveryRequest." The structure of this certificate is according to the structure disclosed in FIG.

[0188] At this time, an example of a possible certificate configuration is as follows: The 'recoveryRequest' includes the 'bundle classifier' of the bundle in reference number 510 (see FIG. 5 below). The "recoveryRequest" includes the "SSP Identifier" of the second SSP at 540. The "recoveryRequest" includes information at 550 indicating that the second SSP has deleted the bundle. The 'recoveryRequest' optionally includes at 520 the time the second SSP deleted the bundle or created the certificate. The "recoveryRequest" includes the signature information of the second SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0189] Referring to FIG. 13, in step 13015, the second SSP 1360 transmits a "recoveryRequest" to the first SSP 1310. For example, the second SSP 1360 transmits a "recoveryRequest" to the first SSP 1310 through the following process. That is, the second SSP 1360 transmits a 'recoveryRequest' to the second LBA 1370 in response to step 13005 , and the second LBA 1370 transmits the 'recoveryRequest' to the first SSP 1310 via the first LBA 1320 .

[0190] Referring to FIG. 13, in step 13020, the first SSP 1310 verifies the received 'recoveryRequest'. This verification process may include checking the validity of the signature of the second SSP 1360 included in the "recoveryRequest." This verification process may further include a process of confirming the 'bundle classifier' included in the 'recoveryRequest'. This verification process may further include checking the "SSP Identifier" included in the "recoveryRequest." Also, this verification process may further include a process of confirming whether the command information included in the 'recoveryRequest' is to delete the bundle.

[0191] In step 13020, the first SSP 1310 changes the state of the bundle after the verification to one of the available states (one of Disabled, Enable, and Active). For example, as shown in the figure, the first SSP 1310 changes the state of the bundle to a "Disabled" state. 13, in step 13025, the first SSP 1310 transmits a result (eg, success / failure) of the operation performed in step 13020 to the first LBA 1320.

[0192] FIG. 14 is a diagram showing an example of yet another procedure for making a discontinued bundle available for further use. According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, as in the example of FIG. 14, a first terminal 1400 includes a first LBA 1420 and a first SSP 1410, and a second terminal 1450 includes a second LBA 1470 and a second SSP 1460. For example, the first terminal 1400 may be a terminal having a first SSP 1410 installed and a first LBA 1420 for controlling the first SSP 1410, and the second terminal 1450 may be a terminal having a second SSP 1460 installed and a second LBA 1470 for controlling the second SSP 1460.

[0193] Possible examples of when the state of the bundle before the procedure disclosed in FIG. 14 is performed is set to "IN TRANSITION" or "SUSPENSION" are as follows: For example, when the transmission of the bundle disclosed in FIG. 11 is completed, if step 11025 is performed but step 11045 is not performed, the state of the bundle in the first terminal 1400 will be set to the “IN TRANSITION” state. In yet another example, when step 12025 is performed at the stage where the transmission of the bundle disclosed in FIG. 12 is completed, the state of the bundle in the first terminal 1400 may be set to the "IN TRANSITION" state or the "SUSPENSION" state.

[0194] Referring to FIG. 14, in step 14000, information on the bundle for which resumption of use is requested is transmitted to the second LBA 1470. This transmission process can be performed through a process in which the user directly selects the bundle via a UI provided by the second terminal 1450, or it can be input to the second LBA 1470 via push input from a remote server, or the second LBA 1470 can connect to the remote server and read the information.

[0195] 14, in steps 14005 to 14000, information on the bundle selected is transferred from the second LBA 1470 to the second SSP 1460. At this time, the information transferred from the second LBA 1470 to the second SSP 1460 includes information for identifying the bundle selected in step 14000 .

[0196] Referring to FIG. 14, in step 14010, the second SSP 1460 sets the state of the bundle to "IN TRANSITION". The second SSP 1460 also generates a "certificate" associated with the state change of the bundle. In Figure 14, this certificate is called "recoveryRequest." The structure of this certificate is according to the structure disclosed in FIG.

[0197] At this time, an example of a possible certificate configuration is as follows: The 'recoveryRequest' includes the 'bundle classifier' of the bundle in reference number 510 (see FIG. 5 below). The "recoveryRequest" includes the "SSP Identifier" of the second SSP at 540. The "recoveryRequest" includes information at 550 indicating that the second SSP has set the state of the bundle to "IN TRANSITION". The 'recoveryRequest' optionally includes at 520 the time the second SSP changed the state of the bundle or created the certificate. The "recoveryRequest" includes the signature information of the second SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0198] Referring to FIG. 14, in step 14015, the second SSP 1460 transmits a "recoveryRequest" to the first SSP 1410. For example, the second SSP 1460 transmits a "recoveryRequest" to the first SSP 1410 through the following process. That is, the second SSP 1460 transmits a 'recoveryRequest' to the second LBA 1470 in response to step 14005, and the second LBA 1470 transmits the 'recoveryRequest' to the first SSP 1410 via the first LBA 1420.

[0199] Referring to FIG. 14, in step 14020, the first SSP 1410 verifies the received 'recoveryRequest'. This verification process may include checking the validity of the signature of the second SSP 1460 included in the "recoveryRequest." This verification process may further include a process of confirming the 'bundle classifier' included in the 'recoveryRequest'. This verification process may further include a process of checking the "SSP Identifier" included in the "recoveryRequest". Also, this verification process may further include a process of checking whether command information included in the 'recoveryRequest' changes the state of the bundle to an 'IN TRANSITION' state.

[0200] In step 14020, the first SSP 1410 changes the state of the bundle after the verification to one of the available states (one of Disabled, Enable, and Active). For example, as shown, the first SSP 1410 transitions the state of the bundle to a "Disabled" state.

[0201] Also, in step 14020, the first SSP 1410 generates a "certificate." In Figure 14, this certificate is called "recoveryResponse." The structure of this certificate is according to the structure disclosed in FIG.

[0202] At this time, an example of a possible certificate configuration is as follows: The "recoveryResponse" includes the "bundle classifier" of the bundle in reference number 510 (see FIG. 5 below). The "recoveryResponse" includes the "SSP Identifier" of the first SSP at 540. The "recoveryResponse" includes information at 550 indicating that the first SSP has changed the state of the bundle to a usable state. The 'recoveryResponse' optionally includes the time at which the first SSP changed the state of the bundle or created the certificate at 520 . The "recoveryResponse" includes the signature information of the first SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with the signing certificate of the first SSP.

[0203] And other examples of possible certificate configurations are as follows: · 'recoveryResponse' contains the 'recoveryRequest' received at 530 . At this time, some information in the received 'recoveryRequest' may be omitted if necessary. For example, the signature information of the second SSP included in the "recoveryRequest" may be omitted in some cases. Also, for example, the time information included in the "recoveryRequest" may be omitted in some cases. The "recoveryResponse" includes the "SSP Identifier" of the first SSP at 540. The "recoveryResponse" includes information at 550 indicating that the first SSP has changed the state of the bundle to a usable state. The 'recoveryResponse' optionally includes the time at which the first SSP changed the state of the bundle or created the certificate at 520 . The "recoveryResponse" includes the signature information of the first SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with the signing certificate of the first SSP.

[0204] Referring to FIG. 14, in step 14025, the first SSP 1410 transmits a “recoveryResponse” to the second SSP 1460. For example, the first SSP 1410 transmits a “recoveryResponse” to the second SSP 1460 via the first LBA 1420 and the second LBA 1470 .

[0205] Referring to FIG. 14, in step 14030, the second SSP 1460 verifies the received 'recoveryResponse'. This verification process may include checking the validity of the signature of the first SSP 1460 included in the "recoveryResponse." Also, this verification step may optionally further include a step of checking whether the 'bundle classifier' included in the 'recoveryResponse' matches the bundle classifier of the bundle. Also, this verification process may optionally further include a process of checking whether the 'recoveryRequest' included in the 'recoveryResponse' matches the information sent by the device itself. This verification process may further include the step of checking the "SSP ID" included in the "recoveryResponse". Also, this verification process may further include a process of checking whether the command information included in the 'recoveryResponse' is correct command information.

[0206] Also, in step 14030, the second SSP 1460 deletes the bundle after verification. 14, in step 14035, the second SSP 1460 transmits a result (eg, success / failure) of the operation performed in step 14030 to the second LBA 1470.

[0207] FIG. 15 is a diagram showing an example of still another procedure for making a discontinued bundle available for further use. According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, as in the example of FIG. 15, a first terminal 1500 includes a first LBA 1520 and a first SSP 1510, and a second terminal 1550 includes a second LBA 1570 and a second SSP 1560. For example, the first terminal 1500 may be a terminal having a first SSP 1510 installed and a first LBA 1520 for controlling the first SSP 1510, and the second terminal 1550 may be a terminal having a second SSP 1560 installed and a second LBA 1570 for controlling the second SSP 1560.

[0208] Possible examples of when the state of the bundle before the procedure disclosed in FIG. 15 is performed is set to "IN TRANSITION" or "SUSPENSION" are as follows: For example, in the stage where the transmission of the bundle disclosed in FIG. 11 is completed, if step 11025 is performed but step 11045 is not performed, the state of the bundle in the first terminal 1500 will be set to the "IN TRANSITION" state. In yet another example, when step 12025 is performed at the stage where the transmission of the bundle disclosed in FIG. 12 is completed, the state of the bundle in the first terminal 1500 may be set to the "IN TRANSITION" state or the "SUSPENSION" state.

[0209] Referring to FIG. 15, in step 15000, information on the bundle for which resumption of use is requested is transmitted to the second LBA. This transmission process can be performed through a process in which the user directly selects the bundle via a UI provided by the second terminal 1550, or it can be input to the second LBA 1570 via push input from a remote server, or the second LBA 1570 can connect to the remote server and read the information.

[0210] 15, in step 15005 , information on the bundle selected in step 15000 is transferred from the second LBA 1570 to the second SSP 1560 . At this time, the information transmitted from the second LBA 1570 to the second SSP 1560 may include information for identifying the bundle selected in step 15000. Referring to FIG. 15, in step 15010, the second SSP 1560 changes the state of the bundle to "SUSPENSION." At this time, although not shown in the figure, the above-mentioned "SUSPENSION" state is replaced with an "IN TRANSITION" state.

[0211] The second SSP 1560 also generates a "certificate." In Figure 15, this certificate is called "recoveryRequest." The structure of this certificate is according to the structure disclosed in FIG.

[0212] At this time, an example of a possible certificate configuration is as follows: The 'recoveryRequest' includes the 'bundle classifier' of the bundle in reference number 510 (see FIG. 5 below). The "recoveryRequest" includes the "SSP Identifier" of the second SSP at 540. The "recoveryRequest" includes information 550 indicating that the second SSP has changed the state of the bundle to "SUSPENSION" or "IN TRANSITION". The 'recoveryRequest' optionally includes at 520 the time the second SSP changed the state of the bundle or created the certificate. The "recoveryRequest" includes the signature information of the second SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0213] Referring to FIG. 15, in step 15015, the second SSP 1560 transmits a 'recoveryRequest' to the first SSP 1510. For example, the second SSP 1560 transmits a "recoveryRequest" to the first SSP 1510 through the following process. That is, the second SSP 1560 transmits a 'recoveryRequest' to the second LBA 1570 in response to step 15005, and the second LBA 1570 transmits the 'recoveryRequest' to the first SSP 1510 via the first LBA 1520.

[0214] Referring to FIG. 15, in step 15020, the first SSP 1510 verifies the received "recoveryRequest." This verification process may include checking the validity of the signature of the second SSP 1560 included in the "recoveryRequest." This verification process may further include a process of confirming the 'bundle classifier' included in the 'recoveryRequest'. This verification process may further include a process of checking the "SSP Identifier" included in the "recoveryRequest". This verification process may further include a process of verifying whether the command information included in the 'recoveryRequest' properly changes the state of the bundle.

[0215] In step 15020, the first SSP 1510 changes the state of the bundle after the verification to one of the available states (one of Disabled, Enable, and Active). For example, as shown, the first SSP 1510 changes the state of the bundle to a "Disabled" state. 15, in step 15025, the first SSP 1510 transmits a result (eg, success / failure) of the operation performed in step 15020 to the first LBA 1520.

[0216] FIG. 16 is a block diagram showing a schematic configuration of a terminal according to an embodiment of the present invention. As shown in FIG. 16, the terminal includes a transceiver 1610 and at least one processor 1620. The terminal further includes an SSP1630.

[0217] For example, the SSP1630 can be inserted into a terminal or can be built into the terminal. At least one of the processors 1620 may also be referred to as a "controller." However, the configuration of the terminal is not limited to that of FIG. 16 and may include more or fewer components than those shown in FIG. According to one embodiment, the transceiver 1610, at least one processor 1620, and a memory (not shown) may be implemented in the form of a single chip. In addition, when the SSP1630 is built-in, the SSP1630 may be included in a single chip.

[0218] According to an embodiment, the transceiver 1610 transmits and receives signals, information, data, etc. to and from a transceiver of another terminal or an external server according to an embodiment of the present invention. The transceiver 1610 includes an RF transmitter that up-converts and amplifies the frequency of a signal to be transmitted, and an RF receiver that low-noise amplifies a received signal and down-converts the frequency. However, this is only one embodiment of the transceiver unit 1610, and the components of the transceiver unit 1610 are not limited to an RF transmitter and an RF receiver. In addition, the transceiver 1610 receives a signal via a wireless channel and outputs the signal to at least one processor 1620, and transmits the signal output from the at least one processor 1620 via a wireless channel.

[0219] According to one embodiment, the transceiver 1610 transmits or receives information about an SSP included in another terminal, authentication information capable of authenticating another terminal, authentication information capable of authenticating itself, a bundle transfer code, bundle transfer settings, a bundle, various certificates described in Figures 10 to 15, etc. from the transceiver of another terminal or an external server.

[0220] Meanwhile, at least one processor 1620 is a component for overall control of the terminal. At least one processor 1620 controls the overall operation of the terminal according to various embodiments of the present invention as described above. On the other hand, the SSP 1630 includes a processor or controller for installing and controlling the bundles or applications may be installed.

[0221] According to one embodiment, at least one processor or controller within SSP 1630 examines the bundle transfer settings to determine whether to transmit a particular bundle. Also, the bundle transfer setting is checked to see whether the bundle can be used on multiple terminals. Additionally, according to one embodiment, at least one processor or controller within the SSP generates a bundle transfer code to control the transmission process of a particular bundle.

[0222] Also, according to one embodiment, at least one processor or controller within an SSP generates its own SSP information and checks and verifies SSP information of other SSPs transmitted from outside. Also, according to one embodiment, at least one processor or controller within an SSP generates authentication information that can verify itself and verify authentication information of other SSPs sent from outside.

[0223] Additionally, according to one embodiment, SSP 1330 creates bundles and installs the bundles in conjunction with one or more processors 1620. The SSP 1630 also manages the bundles. Additionally, according to one embodiment, the SSP 1630 generates certificates in various formats as described in FIGS. 10-15 and verifies received certificates. Additionally, according to one embodiment, the SSP 1630 changes the state of the bundle based on the contents of the received certificate as described in FIGS. Additionally, according to one embodiment, SSP 1630 operates under the control of processor 1620. Alternatively, the SSP 1630 may include a processor or controller for installing and controlling the bundles or applications may be installed. Some or all of the applications may be located on the SSP 1630 or in memory (not shown).

[0224] Meanwhile, the terminal further includes a memory (not shown) for storing data such as basic programs, applications, and setting information for the operation of the terminal. The memory may also include at least one storage medium of a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), a magnetic memory, a magnetic disk, an optical disk, a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), a programmable read-only memory (PROM), or an electrically erasable programmable read-only memory (EEPROM). In addition, the processor 1620 performs various operations using various programs, contents, data, etc. stored in the memory.

[0225] FIG. 17 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. More specifically, FIG. 17 is a diagram illustrating another example of a process in which a bundle is installed in a terminal and a bundle status is set after a bundle is transmitted according to an embodiment of the present invention.

[0226] According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, in the example of FIG. 17, a first terminal 1700 includes a first LBA 1720 and a first SSP 1710, and a second terminal 1750 includes a second LBA 1770 and a second SSP 1760. For example, the first terminal 1700 may be a terminal having a first SSP 1710 installed and a first LBA 1720 for controlling the first SSP 1710, and the second terminal 1750 may be a terminal having a second SSP 1760 installed and a second LBA 1770 for controlling the second SSP 1760.

[0227] 1. [Bundle installation] 17, in step 17000, a second LBA 1770 and a second SSP 1760 cooperate with each other to install a bundle in a second terminal 1750. For a detailed description of this, please refer to the "Install Bundle" process of FIG.

[0228] 2. [Check whether the item can be used multiple times] Also, although not shown in the figure, the second LBA 1770 and / or the second SSP 1760 can selectively determine whether the bundle can be used in multiple terminals, and for a detailed explanation of this, please refer to the ``Determine whether it can be used in multiple terminals'' process of Figure 9.

[0229] 3. [Bundle status setting] If it is determined that the bundle cannot be used on multiple devices, the bundle status is additionally set as follows: Alternatively, even if the second LBA 1770 and / or the second SSP 1760 does not determine whether the bundle is used redundantly, the implementation of the second LBA 1770 and / or the second SSP 1760 performs a process of additionally setting the state of the bundle as described below.

[0230] Referring to FIG. 17, in step 17005, the second SSP 1760 sets the state of the bundle to “IN TRANSITION”. "IN TRANSITION" means that the bundle has been successfully installed but is not available for use (and can only be changed to a usable state (Disabled, Enable, Active state) by additional actions such as "a request from another terminal (e.g., a request made by sending "finalizationResponse" or "recoveryRequest")" and / or "a request from an external server").

[0231] Referring to FIG. 17, in step 17010, the second LBA 1770 requests a “certificate” from the second SSP 1760. Referring to FIG. 17, in step 17015, the second SSP 1760 generates a “certificate.” In Figure 17, this certificate is called "finalizationRequest." The structure of this certificate is according to the structure disclosed in FIG.

[0232] At this time, an example of a possible certificate configuration is as follows: The "finalizationRequest" includes the "bundle classifier" of the bundle in reference numeral 510 (see FIG. 5 below). The "finalizationRequest" includes the "SSP Identifier" of the second SSP at 540. The "finalizationRequest" includes information at 550 indicating that the second SSP has set the state of the bundle to "IN TRANSITION". The 'finalizationRequest' optionally includes, at 520, the time when the second SSP changed the state of the bundle to 'IN TRANSITION' or the time when it created the certificate. Alternatively, it may further selectively include information on a certificate to be used for a subsequent electronic signature. The "finalizationRequest" includes the signature information of the second SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0233] Referring to FIG. 17, in step 17020, the second SSP 1760 transmits a “finalizationRequest” to the first SSP 1710. For example, the second SSP 1760 transmits a "finalizationRequest" to the first SSP 1710 through the following process. That is, the second SSP 1760 transmits a “finalizationRequest” to the second LBA 1770 in response to step 17010 , and the second LBA transmits the “finalizationRequest” to the first SSP via the first LBA 1720 .

[0234] Referring to FIG. 17, in step 17025, the first SSP 1710 verifies the received "finalizationRequest." This verification process may include checking the validity of the signature of the second SSP included in the "finalizationRequest." Also, this verification process may further include a process of checking whether the 'bundle classifier' included in the 'finalizationRequest' matches the bundle classifier of the bundle. This verification process may further include a process of checking whether the "SSP Identifier" included in the "finalizationRequest" is a correct identifier of the second SSP. Also, this verification process may further include a process of confirming whether the command information included in the 'finalizationRequest' is to change the state of the bundle to an 'IN TRANSITION' state.

[0235] Also, in step 17025, the first SSP 1710 deletes the bundle.

[0236] Also, in step 17025, the first SSP 1710 generates a "certificate." In Figure 17, this certificate is called "finalizationResponse." The structure of this certificate is according to the structure disclosed in FIG.

[0237] At this time, an example of a possible certificate configuration is as follows: The "finalizationResponse" includes the "bundle classifier" of the bundle in reference number 510 (see FIG. 5 below). The "finalizationResponse" includes the "SSP Identifier" of the first SSP at 540. The "finalizationResponse" includes information at 550 indicating that the first SSP has deleted the bundle. The "finalizationResponse" optionally includes the time at which the first SSP deleted the bundle or created the certificate at 520. Alternatively, it may further selectively include information on a certificate to be used for a subsequent electronic signature. The "finalizationResponse" includes the signature information of the first SSP at 560. This signature may be signature information obtained by digitally signing the above-mentioned information with the signing certificate of the first SSP.

[0238] And other examples of possible certificate configurations are as follows: The "finalizationResponse" includes part and / or the entire data of the "finalizationRequest" at 530. The "finalizationResponse" includes the "SSP Identifier" of the first SSP at 540. The "finalizationResponse" includes information at 550 indicating that the first SSP has deleted the bundle. The "finalizationResponse" optionally includes the time at which the first SSP deleted the bundle or created the certificate at 520. Alternatively, it may further selectively include information on a certificate to be used for a subsequent electronic signature. The "finalizationResponse" includes the signature information of the first SSP at 560. This signature may be signature information obtained by digitally signing the above information with the signing certificate of the first SSP.

[0239] Referring to FIG. 17, in step 17030, the first SSP 1710 transmits a “finalizationResponse” to the second SSP 1760. For example, the first SSP 1710 transmits a “finalizationResponse” to the second SSP 1760 via the first LBA 1720 and the second LBA 1770 .

[0240] Referring to FIG. 17, in step 17035, the second SSP 1760 verifies the received "finalizationResponse." This verification process may include checking the validity of the signature of the first SSP included in the "finalizationResponse". Also, this verification step may optionally further include a step of checking whether the 'bundle classifier' included in the 'finalizationResponse' matches the bundle classifier of the bundle. Also, this verification process may optionally further include a process of checking whether some and / or all of the information in the 'finalizationRequest' included in the 'finalizationResponse' matches the information sent by the 'finalizationRequest'. This verification process may further include a process of checking the "SSP Identifier" included in the "finalizationResponse". Also, this verification process may further include a process of confirming whether the command information included in the 'finalizationResponse' is to delete the bundle.

[0241] Also, in step 17035, the second SSP 1760 changes the state of the bundle to one of the available states (one of Disabled, Enable, and Active). For example, as shown, the second SSP 1760 changes the state of the bundle to a "Disabled" state.

[0242] Also, in step 17035, the second SSP 1760 generates a “certificate”. In Figure 17, this certificate is called "spblAttestation." The structure of this certificate is according to the structure disclosed in FIG.

[0243] At this time, an example of a possible certificate configuration is as follows: "spblAttestation" includes the "bundle classifier" of the bundle in reference number 510 (see FIG. 5 below). "spblAttestation" contains the "SSP Identifier" of the second SSP at 540. "spblAttestation" contains information at 550 indicating that the second SSP has changed the state of the bundle to available. "spblAttestation" optionally contains the time the second SSP changed the state of the bundle or created the certificate at 520. Alternatively, it may further selectively include information on a certificate to be used for a subsequent electronic signature. "spblAttestation" contains the signature information of the second SSP at 560. This signature may be signature information obtained by digitally signing the above information with a signing certificate of the second SSP.

[0244] And other examples of possible certificate configurations are as follows: "spblAttestation" includes part and / or the entire data of "finalizationRequest" and / or "finalizationResponse" at 530. "spblAttestation" contains the "SSP Identifier" of the second SSP at 540. "spblAttestation" 550 contains information indicating that the second SSP has changed the state of the bundle to an available state. "spblAttestation" optionally contains the time the second SSP changed the state of the bundle or created the certificate at 520. Alternatively, it may further selectively include information on a certificate to be used for a subsequent electronic signature. "spblAttestation" contains the signature information of the second SSP at 560. This signature may be signature information obtained by digitally signing the above information with a signing certificate of the second SSP.

[0245] Referring to FIG. 17, in step 17040, the second SSP 1760 transmits “spblAttestation” to the first SSP 1710. For example, the second SSP 1760 transmits “spblAttestation” to the first SSP 1710 via the second LBA 1770 and the first LBA 1720 .

[0246] Referring to FIG. 17, in step 17045, the first SSP 1710 verifies the received 'spblAttestation'. This verification process may include checking the validity of the signature of the second SSP contained in "spblAttestation." Also, this verification process may further include a process of checking whether the 'bundle classifier' included in 'spblAttestation' matches the bundle classifier of the bundle. In addition, this verification process may optionally further include a process of checking whether partial and / or entire information of the 'finalizationRequest' and / or 'finalizationResponse' included in 'spblAttestation' matches the information sent by itself. Also, this verification process may further include a process of checking whether the 'SSP Identifier' included in 'spblAttestation' is a correct identifier of the second SSP. Also, this verification process may further include a process of checking whether the command information included in 'spblAttestation' is to change the state of the bundle to an available state.

[0247] Also, at step 17045, the first SSP 1710 deletes the "finalizationResponse".

[0248] In step 17035, the step of generating "spblAttestation" and / or steps 17040 and / or steps 17045 may be omitted, if necessary. In steps 17020 and / or 17030 and / or 17040, if the certificate transmission fails, the certificate may be resent to the counterpart device.

[0249] At this time, retransmission is attempted a preset maximum number of times. Or, the attempt is repeated until it is confirmed that the certificate was sent by the other terminal. Alternatively, the certificate may be repeatedly retransmitted until it is deleted by the terminal implementation. For example, in the case of 'finalizationResponse', the first terminal repeatedly attempts to resend 'finalizationResponse' until it is deleted in step 17045.

[0250] If the connection between the two devices is broken when attempting retransmission, the two devices will send and receive the certificate after forming a new connection. At this time, the two terminals use records of past communications to select and / or verify the target of the newly established connection, determine what data must be sent and received with the other terminal with which the newly established connection is made, and also verify the validity and / or content of the data received from the other terminal. At this time, the retransmission may be initiated automatically by an internal operation of the terminal, by a request from an external server, or by user input.

[0251] FIG. 18 is a diagram showing the configuration of an "Attestation" according to an embodiment of the present invention. According to one embodiment, the certificate optionally includes "Attestation Info" (1810). For various embodiments of data included in the certificate information, please refer to the description of FIGS. 22 to 27 described later.

[0252] According to one embodiment, the certificate optionally further includes an "Issuer ID" of the entity that issued the certificate (reference number 1830). For various embodiments of the entity issuing the certificate, please refer to the description of FIGS. 22 to 27 below. According to one embodiment, the certificate optionally further includes "information (command) for the action taken by the certificate issuer" (reference number 1850). For various embodiments of the operations performed by the certificate issuer, please refer to the description of FIGS. 22 to 27 below. According to one embodiment, the certificate optionally further includes other data in addition to the information discussed above (reference number 1870). For various embodiments of other data that can be included in the certificate, see the description of Figures 22 to 27 below. According to one embodiment, the certificate includes digital signature data 1890 for the information described above. This signature data may be a digital signature generated by the certificate issuer's signing certificate.

[0253] FIG. 19 is a diagram conceptually illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present invention. According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, in the example of FIG. 19, a first terminal 1900 includes a first LBA 1920 and a first SSP 1910, and a second terminal 1950 includes a second LBA 1970 and a second SSP 1960. For example, the first terminal 1900 may be a terminal having a first SSP 1910 installed and a first LBA 1920 for controlling the first SSP 1910, and the second terminal 1950 may be a terminal having a second SSP 1960 installed and a second LBA 1970 for controlling the second SSP 1960.

[0254] 19, in step 19000, a first SSP 1910 and a first LBA 1920 of a first terminal 1900 and a second LBA 1970 of a second terminal 1950 perform a preparation procedure (bundle transmission preparation procedure) required for bundle transmission. For a more detailed explanation of the above procedure, please refer to the detailed explanation of FIG. 20 below.

[0255] Referring to FIG. 19, in step 19005, a procedure (bundle transmission procedure) is performed in which a bundle is transmitted from a first terminal 1900 to a second terminal 1950. For a more detailed explanation of the above procedure, please refer to the detailed explanation of FIG. 21 below.

[0256] Referring to FIG. 19, in step 19010, a first terminal 1900 and a second terminal 1960 perform a procedure for installing a transmitted bundle and a procedure for setting the state of the bundle (bundle transmission finalization procedure). For a detailed description of the above procedures, please refer to the detailed descriptions of Figures 22, 24, and 26 described below.

[0257] FIG. 20 is a diagram showing detailed procedures for preparing for bundle transmission among the procedures presented in FIG. More specifically, FIG. 20 is a diagram illustrating an exemplary procedure for a terminal to go through a preparation process required for transmitting a bundle to another terminal according to an embodiment of the present invention. In this specification, the procedure of FIG. 20 is referred to as a bundle transmission preparation procedure.

[0258] According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, as in the example of FIG. 20, a first terminal 2000 includes a first LBA 2020 and a first SSP 2010, and a second terminal 2050 includes a second LBA 2070 and a second SSP 2060. For example, the first terminal 2000 may be a terminal having a first SSP 2010 installed and a first LBA 2020 for controlling the first SSP 2010, and the second terminal 2050 may be a terminal having a second SSP 2060 installed and a second LBA 2070 for controlling the second SSP 2060.

[0259] According to one embodiment, the first terminal 2000 may have a pre-installed bundle and may further have metadata associated with the bundle. According to one embodiment, the first terminal 2000 may have at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), or a bundle family custodian object identifier (SPB Family Custodian Object ID) associated with the bundle.

[0260] According to one embodiment, the first terminal 2000 may have a "bundle transfer setting" associated with the bundle. The bundle transport settings may optionally include information related to whether transmission is possible between devices of the bundle. Also, the bundle transfer setting may selectively further include a "registration setting" for a process of registering the results of transmission between devices of the bundle in a server. Various examples of possible "registration settings" are as follows:

[0261] · [Whether or not notification is necessary] This setting determines whether the results of bundle transmission between devices should be notified to the server. · [Whether pre-notification is necessary] A setting for whether the bundle must be notified to the server after it has been sent from one device to a new device before it can be used on the new device, or whether the bundle can be used on the new device before it is notified to the server. - [Whether the notification content needs to be encrypted] This setting determines whether data sent during the notification process should be encrypted so that only the server receiving the notification and the SSP making the notification can see the contents.

[0262] The "registration settings" may be set by the service provider, may be set by the bundle management server, or may be set by a collaboration between the service provider and the bundle management server. Additionally, the bundle movement settings may be contained in data internal to the bundle, may be contained within the bundle's metadata, or may exist as separate data. The bundle transfer configuration may also include a digital signature of the service provider and / or the bundle management server.

[0263] Referring to FIG. 20, in step 20000, information on a bundle to be transmitted between devices is transmitted to a first LBA 2020. This transmission process may be performed, for example, as shown in FIG. 20, through a process in which the user directly selects the bundle via a UI provided by the first terminal 2000, or may be input to the first LBA 2020 via push input from a remote server, or the first LBA 2020 may connect to the remote server and read the information.

[0264] 20, in step 20005 , information related to the bundle selected in step 20000 is transmitted from the first LBA 2020 to the first SSP 2010 . For example, as shown in FIG. 20, information related to the selected bundle is transmitted from the first LBA 2020 to the first SSP 2010 via a "Select SPB command." At this time, the information transmitted from the first LBA 2020 to the first SSP 2010 includes information for identifying the bundle selected in step 20000.

[0265] Referring to FIG. 20, in step 20010, the first SSP 2010 checks whether transmission is possible between devices of the bundle requested to be transmitted. This process is performed by first identifying the bundle requested for transmission based on the information received in step 20005, and checking the "bundle transfer setting" associated with that bundle. Also, in step 20010, the first SSP 2010 selectively sets a "bundle transfer code." The "bundle transfer code" must be a value that can identify the bundle as a code used to refer to the bundle during the process of transmitting the bundle between devices. The first SSP 2010 binds the above-mentioned "bundle transfer code" with information on the bundle to be transmitted.

[0266] 20, in step 20015 , a response result to step 20005 is sent from the first SSP 2010 to the first LBA 2020 . For example, as shown in FIG. 20, a response to the "Select SPB command" is transmitted from the first SPB 2010 to the first LBA 2020 via a "Select SPB response." This response value may include the "bundle transfer code" described in step 20010.

[0267] 20, in step 20020, information required for bundle transmission between devices is transferred from the first LBA 2020 of the first terminal 2000 to the second LBA 2070 of the second terminal 2050. At this time, the information transmitted from the first LBA 2020 to the second LBA 2070 may include a "bundle transfer code." In addition, the information transmitted from the first LBA 2020 to the second LBA 2070 may selectively further include information necessary for a connection to be established between the first LBA 720 and the second LBA 2070 in a future step 20025.

[0268] The information transferred from the first LBA 2020 to the second LBA 2070 in step 20020 can be transferred in various ways. For example, the first LBA provides information that needs to be transmitted to the second LBA to the user via the UI of the first terminal 2000, and the user inputs the provided information into the second LBA using the UI of the second terminal 2050. Alternatively, the first LBA creates the information to be transmitted to the second LBA in the form of an image (e.g., a QR code (registered trademark)) and displays it on the screen of the first terminal, and the user transmits the information to the second LBA 2070 by scanning this image using the second terminal 2050. However, the method of transmitting information from the first LBA 2020 to the second LBA 2070 is not limited to the above method.

[0269] Referring to FIG. 20, in step 20025, a connection is established (or configured) between the first LBA 2020 and the second LBA 2070. If the information required for connection is transmitted in step 20020, the first LBA 2020 and the second LBA 2070 can establish a connection using this information. The connection between the first LBA 2020 and the second LBA 2070 may be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, "LTE D2D" (device-to-device), "5G D2D") or a long-distance connection with a remote server (e.g., a relay server) located between the first LBA 2020 and the second LBA 2070.

[0270] Referring to FIG. 20, step 20025 is shown as the final step, but this step is independent of the other steps described above, i.e., steps 20000, 20005, 20010, 20015, and 20020, and can be performed regardless of the other steps and procedures. For example, step 20025 may be performed between steps 20015 and 20020, in which case the information sent from the first LBA 2020 to the second LBA 22070 in step 20020 is sent via the connection established in step 20025.

[0271] FIG. 21 is a diagram showing detailed steps of the bundle transmission steps shown in FIG. More specifically, FIG. 21 is a diagram illustrating an exemplary procedure for one terminal to transmit a bundle to another terminal according to an embodiment of the present invention. In the present invention, the procedure of FIG. 21 is referred to as a bundle transmission procedure.

[0272] According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, as in the example of FIG. 21, a first terminal 2100 includes a first LBA 2120 and a first SSP 2110, and a second terminal 2150 includes a second LBA 2170 and a second SSP 2160. For example, the first terminal 2100 may be a terminal having a first SSP 2110 installed and a first LBA 2120 for controlling the first SSP 2110, and the second terminal 2150 may be a terminal having a second SSP 2160 installed and a second LBA 2170 for controlling the second SSP 2160.

[0273] Referring to FIG. 21, in step 21000, the second LBA 2170 requests the second SSP 22160 for "SSP information (SspInfo)". When the second LBA 2170 requests 'SSP information (SspInfo)' from the second SSP 2160 in step 21000, the second LBA 2170 informs the second SSP 2160 that a bundle transfer between devices is to be performed.

[0274] Also, step 21000 can be automatically performed immediately following the process shown in FIG. 21, or can be performed after receiving an external input. In this case, the "external input" can be performed through a process in which the user directly selects the bundle to be sent via a UI provided by the second terminal 2150, or it can be input to the second LBA 2170 via push input from a remote server, or the second LBA 2170 can connect to a remote server and read the information.

[0275] Referring to FIG. 21, in step 21005, the second SSP 2160 generates its own "SSP information". "SSP information" includes information on the second SSP that must be provided for bundle transmission. At this time, the 'SSP information' includes information (certificate negotiation information) for the certificate negotiation process that the second SSP 2160 must go through before receiving the bundle. This "certificate negotiation information" includes certificate information (SenderSpblVerification) that the second SSP 2160 uses to verify a different SSP and certificate information (ReceiverSpblVerification) that the different SSP uses to verify itself. In addition, the “certificate negotiation information” may optionally further include a list of key agreement algorithms supported by the second SSP 2160, and may optionally further include a list of encryption algorithms supported by the second SSP 2160. In addition, the "SSP information" may selectively further include SSP version information including at least one of the version information of the primary platform included in the second SSP 2160 and the standard supported by the loader.

[0276] 21, in step 21010, the second SSP 2160 transmits the 'SSP information' generated in step 21005 to the first SSP 2110 via the second LBA 2170 and the first LBA 2120. According to steps 21000 and 21010 described above, the second LBA 2170 requests “SSP information (SspInfo)” from the second SSP 2160, and after the second SSP 2160 generates its own “SSP information”, the second SSP 2160 transmits the “SSP information” to the first SSP 2110 via the second LBA 2170 and the first LBA 2120. However, in some embodiments, the process in which the second terminal 2150 transmits the 'SSP information' to the first terminal 2100 is as follows. For example, the second LBA 2170 generates “SSP information” by itself, and then transmits the “SSP information” to the first SSP 2110 via the first LBA 2120 .

[0277] Referring to FIG. 21, in step 21015, the first SSP 2110 checks the received 'SSP information' and generates 'first terminal authentication information (Device 1.Auth)' that can authenticate itself based on the information. A more specific procedure for this process is as follows:

[0278] The first SSP 2110 checks the certificate information that can verify itself using the received “SenderSpblVerification” and selects at least one key agreement certificate (ssp1.Cert.KA). Alternatively, the first SSP 2110 uses the received "list of key agreement algorithms supported by the second SSP 2160" to generate an asymmetric encryption key pair (key pair) of public key "ssp1.ePK.KA" and private key "ssp1.ePK.KA" to be used for key agreement, and then selects the public key (ssp1.ePK.KA) of this key pair. In addition, the first SSP 2110 checks the certificate information that can verify itself using the received "SenderSpblVerification" and further selects at least one signing certificate (ssp1.Cert.DS).

[0279] In addition, the first SSP 2110 selects at least one piece of certificate information of the second SSP 2160 to be verified using the received "ReceiverSpblVerification", and then sets the corresponding information in "CiPkIdToBeUsed". In addition, the first SSP 2110 selects at least one encryption algorithm to be used in the future using the received "list of encryption algorithms supported by the second SSP 2160", and then sets the corresponding information in "CryptoToBeUsed". The first SSP 2110 also checks the received list of "version information of standards supported by the primary platform and loader contained in the second SSP 2160" to determine whether there is a version of a standard that it also supports.

[0280] The "first terminal authentication information (Device1.Auth)" includes at least one of the above-mentioned "ssp1.Cert.KA", "ssp1.ePK.KA", "CiPkIdToBeUsed", and "CryptoToBeUsed". In addition, the "first terminal authentication information (Device 1.Auth)" may selectively further include the above-mentioned "ssp1.Cert.DS." In addition, the "first terminal authentication information (Device1.Auth)" may selectively further include at least one of a bundle family identifier (SPB Family ID) and a bundle family custodian object ID (SPB Family Custodian Object ID) associated with a bundle to be transmitted in the future.

[0281] At this time, a part or all of the above-mentioned “first terminal authentication information (Device 1.Auth)” is digitally signed so that it can be verified using “ssp1.Cert.DS” to ensure the integrity of the information, and this digital signature data is added as part of the “first terminal authentication information”.

[0282] 21, in step 21020, the first SSP 2110 transmits the first terminal authentication information (Device 1.Auth) generated in step 21015 to the second LBA 2170 via the first LBA 2120. Referring to FIG. 21, in step 21025, the second LBA 2170 transmits the first terminal authentication information (Device 1.Auth) to the second SSP 2160. Additionally, the second LBA 2170 further transmits a “bundle transfer code” to the second SSP 2160 .

[0283] Referring to FIG. 21, in step 21030, the second SSP 2160 verifies the received "first terminal authentication information (Device 1.Auth)". If the second SSP 2160 receives "ssp1.Cert.KA", it checks the signature on the certificate to verify the validity of the certificate. In addition, when "ssp1.ePK.KA" and the corresponding digital signature are sent to the second SSP 2160, the validity of "ssp1.Cert.DS" is first checked, and then the digital signature is confirmed using this certificate to confirm the integrity of the received public key "ssp1.ePK.KA". The second SSP 2160 also checks the received "CiPkIdToBeUsed" and selects at least one signing certificate (ssp2.Cert.DS) that can verify itself.

[0284] Also, although not shown in the figure, in step 21030, the second SSP 2160 generates a public key “ssp2.ePK.KA” and a private key “ssp2.eSK.KA” in an asymmetric encryption key pair used for key agreement, and then selects the public key (ssp2.ePK.KA) of the key pair. The second SSP 2160 also selects one of the key agreement public keys contained in "ssp1.Cert.KA" or "ssp1.ePK.KA", and then uses this value and "ssp2.eSK.KA" to generate a session key "ShKey01" that will be used to encrypt future communications with terminal 1. "ShKey01" must be the session key for the encryption algorithm contained in the received "CryptoToBeUsed".

[0285] Also, in step 21030, the second SSP 2160 generates "second terminal authentication information (Device 2.Auth)" capable of authenticating itself. At this time, the "second terminal authentication information (Device 2.Auth)" includes "ssp2.Cert.DS". In addition, the "second terminal authentication information (Device 2.Auth)" may further include "ssp2.ePK.KA". In addition, the "second terminal authentication information (Device 2.Auth)" may further include a transaction ID that refers to the current session generated by the SSP22160. In addition, the "second terminal authentication information (Device 2.Auth)" may further include a "bundle transfer code." In addition, the “second terminal authentication information (Device 2.Auth)” may further include the SSP identifier of the second SSP 2160. In addition, the "second terminal authentication information (Device 2.Auth)" may selectively further include at least one of a bundle family identifier (SPB Family ID) and a bundle family custodian object ID (SPB Family Custodian Object ID) associated with a bundle to be transmitted in the future.

[0286] At this time, a part or all of the "second terminal authentication information (Device 2.Auth)" mentioned above is digitally signed so that it can be verified using "ssp2.Cert.DS" to ensure the integrity of the information, and this digital signature data is added as part of the "second terminal authentication information". In addition, a part or the whole of the "second terminal authentication information (Device 2.Auth)" is encrypted using the session key "ShKey01" generated in advance.

[0287] Referring to FIG. 21, in step 21035, the second SSP 2160 transmits the “second terminal authentication information (Device 2.Auth)” generated in step 21030 to the first SSP 2110 via the second LBA 2170 and the first LBA 2120. At this time, a "bundle transfer code" is optionally also transmitted.

[0288] Referring to FIG. 21, in step 21040, the first SSP 2110 verifies the received "second terminal authentication information (Device 2.Auth)". The first SSP 2110 verifies the signature of the received "ssp2.Cert.DS" to verify the validity of the certificate. The first SSP 2110 also checks whether the received bundle family identifier (SPB Family ID) and / or bundle family custodian object ID (SPB Family Custodian Object ID) are correctly set values ​​associated with the bundle it is trying to send. The first SSP 2110 also stores the received transaction ID and / or the SSP identifier of the second SSP 2160. In addition, the first SSP 2110 binds the received transaction ID or the SSP identifier of the second SSP 2160 to the currently ongoing session or the bundle to be transmitted.

[0289] During this process, if the “second terminal authentication information (Device 2.Auth)” contains encrypted data, the first SSP 2110 generates a session key “ShKey01” using the transmitted “ssp2.ePK.KA” and the private key corresponding to the key agreement public key contained in its own “ssp1.Cert.KA” or “ssp1.ePK.KA”, decrypts the encrypted data using this session key, and then performs the verification process. Also, during this process, if the "second terminal authentication information (Device 2.Auth)" includes a digital signature, the first SSP 2110 verifies the validity of the received digital signature using "ssp2.Cert.DS".

[0290] Also, in step 21040, although not shown in FIG. 21, the first SSP 2110 generates a key pair of asymmetric encryption keys used for key agreement, a public key "ssp1.bundle.ePK.KA" and a private key "ssp1.bundle.eSK.KA". At this time, the key pair “ssp1.bundle.ePK.KA” and “ssp1.bundle.eSK.KA” may be set to the same values ​​as the previously generated “ssp1.ePK.KA” and “ssp1.ePK.KA”. Alternatively, the key pair "ssp1.bundle.ePK.KA" and "ssp1.bundle.eSK.KA" can be configured with the same value for the public key and the corresponding private key contained in the previously used "ssp1.Cert.KA". In addition, the first SSP 2110 generates a session key "ShKey02" using "ssp1.bundle.eSK.KA" and "ssp2.ePK.KA". If the private key corresponding to the public key contained in "ssp1.ePK.KA" or "ssp1.Cert.Ka" for "ssp1.bundle.eSK.KA" is reused, the value of the session key "ShKey02" may also be set to the value of the previously generated "ShKey01".

[0291] Also, in step 21040, the first SSP 2110 configures a bundle and / or metadata associated with the bundle to be transmitted to the second terminal 2150. At this time, the first SSP 2110 uses the received "bundle transfer code" to identify the bundle it is attempting to transmit. The configured bundle also includes "ssp1.Cert.DS". The configured bundle also includes "ssp1.bundle.ePK.KA". The configured bundle may further include a transaction ID that identifies the session. In addition, the configured bundle may optionally further include at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), and a bundle family custodian object ID (SPB Family Custodian Object ID) associated with the bundle being transmitted. According to one embodiment, in step 21040, the configured bundle (or metadata associated with the bundle) includes a "bundle migration setting."

[0292] According to one embodiment, at step 21040, the configured bundle is appended with digital signature data generated using "ssp1.Cert.DS". That is, the generated digital signature data is added to some or all of the components of the bundle specified above as part of the bundle. In addition, a portion or the entirety of the configured bundle is encrypted using "ShKey02".

[0293] Referring to FIG. 21, in step 21045, the first SSP 2110 transmits the bundle generated (configured) in step 21040 to the second LBA 2170 via the first LBA 2120. At this time, metadata associated with the transmitted bundle is optionally also transmitted. Additionally, a "bundle movement setting" associated with the bundle being transmitted is also transmitted. For example, the "bundle transfer settings" may not be included in the bundle or metadata, but may be sent in a separate format (eg, a message).

[0294] FIG. 22 is a diagram showing detailed steps of the steps presented in FIG. 19 in which the transmission of a bundle is completed. Figure 22 shows the breakdown of transmissions between devices in a bundle. No need for pre-notification, - Whether or not encryption of the notification content is required; It may also be the procedure that is applied in that case.

[0295] According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, as in the example of FIG. 22, a first terminal 2200 includes a first LBA 2220 and a first SSP 2210, and a second terminal 2250 includes a second LBA 2270 and a second SSP 2260. For example, the first terminal 2200 may be a terminal in which a first SSP 2210 is installed and a first LBA 2220 is provided for controlling the first SSP 2210, and the second terminal 2250 may be a terminal in which a second SSP 2260 is installed and a second LBA 2270 is provided for controlling the second SSP 2260.

[0296] Referring to FIG. 22, the following steps are performed at step 22000: 1. [Bundle installation] Referring to FIG. 22, in step 22000, the second LBA 2270 and the second SSP 2260 cooperate with each other to install a bundle in the second terminal 2250. In this process, the following steps are performed together: If metadata is sent, the second LBA 2270 or the second SSP 2260 verifies the contents included in the metadata. If the “bundle migration setting” is sent, the second LBA 2270 transmits the above information to the second SSP 2260 . If a transaction ID is sent, the second LBA 2270 or the second SSP 2260 checks whether this transaction ID is the same as the transaction ID used in the current session. If at least one of the bundle identifier (SPB ID), bundle family identifier (SPB Family ID), and bundle family custodian object ID (SPB Family Custodian Object ID) is sent, the second LBA 2270 or the second SSP 2260 checks whether this information matches the information of the bundle it is currently attempting to receive. If “ssp1.Cert.DS” is sent, the second SSP 2260 verifies the validity of this certificate and authenticates the first SSP 2210. If the transmitted data contains encrypted data, the second SSP2260 generates a session key "ShKey02" using the transmitted "ssp1.bundle.ePK.KA" and its own "ssp2.eSK.KA", and uses this session key to decrypt the encrypted data and then performs verification. If the received data includes a digital signature, the second SSP 2260 verifies "ssp1.Cer.DS" and then uses this certificate to verify the validity of the digital signature.

[0297] 2. [Check "Registration Settings"] Also, although not shown in the figure, the second LBA 2270 and / or the second SSP 2260 uses the "registration settings" of the bundle to check "whether notification is necessary" and / or "whether advance notification is necessary" and / or "whether the notification content needs to be encrypted." This process may be performed independently of, and as part of, step 22000 and other steps performed in step 22000. Or it can be done after step 22000, but before step 22035 is completed, at the moment when a decision is needed. The procedure described below in this figure may be a procedure that is applied when, as a result of checking the "registration setting", it is not necessary to notify in advance the transmission details between devices of the bundle.

[0298] Referring to FIG. 22, in step 22005, the second SSP 2260 sets the state of the bundle to “IN TRANSITION”. "IN TRANSITION" means that the bundle has been successfully installed but is not yet usable (and can only be changed to a usable state (Disabled, Enable, Active state) by additional actions such as "additional actions described later in this figure" and / or "a request from an external server (not described in this invention)").

[0299] Referring to FIG. 22, in step 22010, the second LBA 2270 requests a “certificate” from the second SSP 2260. Referring to FIG. 22, in step 22015, the second SSP 2260 generates a “certificate.” In Figure 22, this certificate is called "finalizationRequest." The structure of this certificate is as disclosed in FIG.

[0300] At this time, an example of a possible certificate configuration is as follows: The "finalizationRequest" includes the "bundle classifier" of the bundle in question, reference numeral 1810 in FIG. The "finalizationRequest" includes the "SSP Identifier" of the second SSP at 1830 in FIG. The "finalizationRequest" includes information indicating that the second SSP has set the state of the bundle to "IN TRANSITION" as shown in FIG. The "finalizationRequest" optionally includes the time when the second SSP changed the state of the bundle to "IN TRANSITION" state or the time when it created the certificate at 1870 in FIG. Alternatively, it includes information on the signing certificate used in the electronic signature described below and information on the associated certificate chain. "finalizationRequest" includes the signature information of the second SSP in 1890 of FIG. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0301] Referring to FIG. 22, in step 22020, the second SSP 2260 transmits a "finalizationRequest" to the first SSP 2210. For example, the second SSP 2260 transmits a "finalizationRequest" to the first SSP 2210 through the following process. That is, the second SSP 2260 transmits a “finalizationRequest” to the second LBA 2270 in response to step 22010, and the second LBA 2270 transmits the “finalizationRequest” to the first SSP 2210 via the first LBA 2220.

[0302] Referring to FIG. 22, at step 22025, the first SSP 2210 verifies the received "finalizationRequest." This verification process may include checking the validity of the signature of the second SSP included in the "finalizationRequest." Also, this verification process may further include a process of checking whether the 'bundle classifier' included in the 'finalizationRequest' matches the bundle classifier of the bundle. This verification process may further include a process of checking whether the "SSP Identifier" included in the "finalizationRequest" is a correct identifier of the second SSP. Also, this verification process may further include a process of confirming whether the command information included in the 'finalizationRequest' is to change the state of the bundle to an 'IN TRANSITION' state.

[0303] Also, in step 22025, the first SSP 2210 deletes the bundle after verification.

[0304] Also, in step 22025, the first SSP 2210 generates a “certificate.” In Figure 22, this certificate is called "finalizationResponse." The structure of this certificate is as disclosed in FIG.

[0305] At this time, an example of a possible certificate configuration is as follows: The "finalizationResponse" includes the "bundle classifier" of the bundle in question, reference numeral 1810 in FIG. Or it may contain part and / or the entire data of the "finalizationRequest" received in a previous step. The "finalizationResponse" includes the "SSP Identifier" of the first SSP at 1830 in FIG. · The "finalizationResponse" contains information indicating that the first SSP has deleted the bundle, as shown at 1850 in FIG. The "finalizationResponse" optionally includes the time the first SSP deleted the bundle or created the certificate, as shown at 1870 in FIG. Alternatively, it includes information on the signing certificate used in the electronic signature described below and information on the associated certificate chain. · The "finalizationResponse" includes the signature information of the first SSP at 1890 in FIG. This signature may be signature information obtained by digitally signing the above information with the signing certificate of the first SSP.

[0306] Referring to FIG. 22, in step 22030, the first SSP 2210 transmits a “finalizationResponse” to the second SSP 2260. For example, the first SSP 2210 transmits a “finalizationResponse” to the second SSP 2260 via the first LBA 2220 and the second LBA 2270.

[0307] Referring to FIG. 22, at step 22035, the second SSP 2260 verifies the received "finalizationResponse." This verification process includes checking the validity of the signature of the first SSP included in the "finalizationResponse". Also, this verification step may optionally further include a step of checking whether the 'bundle classifier' included in the 'finalizationResponse' matches the bundle classifier of the bundle. This verification process may also include a process of checking whether a part or all of the data in the "finalizationRequest" included in the "finalizationResponse" matches the information sent by the user. This verification process may further include a process of checking the "SSP Identifier" included in the "finalizationResponse". Also, this verification process may further include a process of confirming whether the command information included in the 'finalizationResponse' is to delete the bundle.

[0308] In step 22035, the second SSP 2260 changes the state of the bundle after the verification to one of the available states (one of Disabled, Enable, and Active). For example, as shown, the second SSP 2260 transforms the state of the bundle to a "Disabled" state.

[0309] Also, in step 22035, the second SSP 2260 generates a “certificate.” In FIG. 22, this certificate is called "spblAttestation." The structure of this certificate is as disclosed in FIG.

[0310] At this time, an example of a possible certificate configuration is as follows: "spblAttestation" includes the "bundle classifier" of the bundle in question, reference numeral 1810 in FIG. Or it may include some and / or all of the data in the "finalizationRequest" and / or "finalizationResponse". "spblAttestation" contains the "SSP Identifier" of the second SSP at 1830 in FIG. "spblAttestation" contains information indicating that the second SSP has changed the bundle to one of the available states, as shown in FIG. 18 at 1850. · 'spblAttestation' optionally contains the time when the second SSP changed the state of the bundle to one of the available states or generated the certificate, FIG. 18 1870. Alternatively, it includes information on the signing certificate used in the electronic signature described below and information on the associated certificate chain. "spblAttestation" contains the signature information of the second SSP at 1890 in FIG. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0311] Also, in step 22035, the second SSP 2260 generates its own "selected SSP information (sspInforSelected)". The "selected SSP information" includes information of a second SSP that must be provided to inform the server of the bundle transmission result between devices.

[0312] At this time, the 'selected SSP information' includes information for the certificate negotiation process (certificate negotiation information). This "Certificate Negotiation Information" is Certificate information that the second SSP2260 can use to verify the server (spbmVerification), Certificate information that the server can use to verify the first SSP2210 (SenderSpblVerification), Certificate information that the server can use to verify the second SSP2260 (ReceiverSpblVerification), It may selectively include information such as:

[0313] In addition, the “certificate negotiation information” may optionally further include a list of key agreement algorithms supported by the second SSP 2260, and may optionally further include a list of encryption algorithms supported by the second SSP 2260. In addition, the "selected SSP information" may selectively further include SSP version information including at least one of the version information of the primary platform included in the second SSP 2260 and the standard supported by the loader.

[0314] Referring to FIG. 22, in step 22040, the second SSP 2260 transmits a result (eg, success / failure) of the operation performed in step 22035 to the second LBA 2270. In addition, the 'selected SSP information' generated in step 22035 may be transmitted together. The process of generating the “selected SSP information” in step 22035 and the process of transmitting the “selected SSP information” in step 22040 may be omitted.

[0315] FIG. 23 is a diagram showing a procedure in which the bundle transmission result is registered in the server after the procedure presented in FIG. According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, in the example of FIG. 23, a second terminal 2350 includes a second LBA 2370 and a second SSP 2360. For example, the second terminal 2350 may be a terminal in which a second SSP 2360 is mounted and a second LBA 2370 for controlling the second SSP 2360 is installed.

[0316] Additionally, according to one embodiment, server 2300 may be a server operated by a service provider, may be a bundle management server, may be a server operated in cooperation between a service provider and a bundle management server, or may be any server operated in conjunction with a service provider and / or a bundle management server. In the description of this figure, the term SPBM, which is one possible example of a server, may be used to refer to server 2300, but as mentioned above, the type of server is not limited to SPBM.

[0317] Referring to FIG. 23, in step 23000, a Transport Layer Security (TLS) connection is established between the SPBM 2300 and the LBA 2370. In this figure, step 23000 is described as being performed before steps 23005 to 23015, but step 23000 can be performed independently of steps 23005 to 23015 before step 23020 is performed. For example, step 23000 can be performed between steps 23015 and 23020.

[0318] Referring to FIG. 23, in step 23005, the second LBA 2370 requests the second SSP 22360 for “selected SSP information (SspInfoSelected)”. At this time, step 23005 can be performed automatically or after receiving an external input. At this time, the "external input" may be given by the user via a UI provided by the second terminal 2350, or may be given to the second terminal 2350 via a push input from a remote server.

[0319] Referring to FIG. 23, in step 23010, the second SSP 2360 generates its own "selected SSP information". For an explanation of "selected SSP information", please refer to the explanation given in FIG. Referring to FIG. 23, in step 23015 , the second SSP 2360 transmits the 'selected SSP information' generated in step 23010 to the second LBA 2370 . Steps 23005 to 23015 may be selectively not performed.

[0320] Referring to FIG. 23, in step 23020, the second LBA 2370 transmits the 'selected SSP information' to the server 2300. If the second LBA 2370 receives the “selected SSP information” via steps 22035 to 22040 of FIG. 22, or receives the “selected SSP information” via steps 23005 to 23015 of FIG. 23, the second LBA 2370 transmits the received “selected SSP information” to the server 2300. If the second LBA 2370 does not receive the “selected SSP information”, the second LBA 2370 generates the “selected SSP information” and sends it to the server 2300 .

[0321] Referring to FIG. 23, in step 23025, the server 2300 checks the received 'selected SSP information' and generates 'server authentication information (SPBM.Auth)' that can authenticate itself based on this information. A more specific procedure for this process is as follows:

[0322] The server 2300 checks the certificate information that can verify itself using the received 'spbmVerification' and selects at least one key agreement certificate (spbm.Cert.KA). Alternatively, the server 2300 generates an asymmetric encryption key pair (key pair), public key "spbm.ePK.KA" and private key "spbm.eSK.KA", to be used for key agreement using the received "list of key agreement algorithms supported by the second SSP 2360", and then selects the public key (spbm.ePK.KA) of the key pair. In addition, the server 2300 checks the certificate information that can verify itself using the received 'spbmVerification', and further selects at least one signing certificate (spbm.Cert.DS).

[0323] In addition, the server 2300 checks whether the certificate information of the first SSP 2210 to be verified using the received "senderSpblVerification" is something that the server 2300 can verify. This process may not be performed selectively. In addition, the server 2300 checks whether the certificate information of the second SSP 2360 that is to be verified using the received "ReceiverSpblVerification" is something that the server 2300 can verify. Alternatively, after selecting at least one piece of second SSP 2360 certificate information that the user can verify using "ReceiverSpblVerification", the corresponding information is set in "CiPkIdToBeUsed".

[0324] In addition, the server 2300 selects at least one encryption algorithm to be used in the future using the received "List of encryption algorithms supported by the second SSP 2360", and then sets the corresponding information to "CryptoToBeUsed". The server 2300 also checks the received list of "version information of standards supported by the primary platform and loader contained in the second SSP 2360" to see if there is a version of a standard that the server 2300 also supports.

[0325] The "Server authentication information (SPBM.Auth)" includes at least one of the above-mentioned "spbm.Cert.KA", "spbm.ePK.KA", "CiPkIdToBeUsed", and "CryptoToBeUsed". In addition, the "Server Authentication Information (SPBM.Auth)" may selectively further include the above-mentioned "spbm.Cert.DS". At this time, a part or all of the "Server Authentication Information (SPBM.Auth)" mentioned above is digitally signed so that it can be verified using "spbm.Cert.DS" to ensure the integrity of the information, and this digital signature data is added as part of the "Server Authentication Information".

[0326] Referring to FIG. 23, in step 23030, the server 2300 transmits the server authentication information (SPBM.Auth) generated in step 23025 to the second SSP 2360 via the second LBA 2370.

[0327] Referring to FIG. 23, in step 23035, the second SSP 2360 verifies the received 'Server Authentication Information (SPBM.Auth)'. If the second SSP 2360 receives "spbm.Cert.KA", it checks the signature of the certificate to verify the validity of the certificate. Furthermore, when the second SSP 2360 receives "spbm.Cert.DS", it checks the signature of the certificate to verify the validity of the certificate. In addition, when the second SSP 2360 receives "spbm.ePK.KA" and its corresponding digital signature, it verifies the digital signature using "spbm.Cert.DS" to confirm the integrity of the received public key "spbm.ePK.KA". Furthermore, when the second SSP 2360 receives "CiPkIdToBeUsed", it checks this and selects at least one signing certificate (ssp2.Cert.DS) that can verify itself.

[0328] Also, although not shown in the figure, in step 23035, the second SSP 2360 generates a public key “ssp2.ePK.KA” and a private key “ssp2.eSK.KA” for an asymmetric encryption key pair used for key agreement, and then selects the public key (ssp2.ePK.KA) of the key pair. The second SSP 2360 also selects one of the public key agreement keys contained in “spbm.Cert.KA” or “spbm.ePK.KA”, and then uses this value and “ssp2.eSK.KA” to generate a session key “ShKey03” that will be used to encrypt future communications with the server. "ShKey03" must be the session key for the encryption algorithm contained in the received "CryptoToBeUsed".

[0329] Also, in step 23035, the second SSP 2360 generates “terminal authentication information (Device.Auth)” that can authenticate itself. At this time, the "Device authentication information (Device.Auth)" includes "ssp2.Cert.DS". In addition, the "Device authentication information (Device.Auth)" may selectively further include "ssp1.Cert.DS". In addition, the 'Device.Auth' may further include certificate chain information associated with 'ssp2.Cert.DS' and / or 'ssp1.Cert.DS'. In addition, "Terminal authentication information (Device.Auth)" may include a part and / or the whole of "spblAttestation". In addition, the "terminal authentication information (Device.Auth)" may include a part and / or the entirety of the "finalizationRequest". In addition, the "terminal authentication information (Device.Auth)" may include a part and / or the entirety of the "finalizationResponse". In addition, the "terminal authentication information (Device.Auth)" may further include "ssp2.ePK.KA".

[0330] At this time, a part or all of the "Device.Auth" mentioned above is digitally signed so that it can be verified using "ssp2.Cert.DS" to ensure the integrity of the information, and this digital signature data is added as part of the "Device.Auth". In addition, a part or the whole of the "terminal authentication information (Device.Auth)" is encrypted using the session key "ShKey03" generated in advance.

[0331] Referring to FIG. 23, in step 23040, the second SSP 2360 transmits the “Device.Auth” generated in step 23035 to the server 2300 via the second LBA 2370.

[0332] Referring to FIG. 23, in step 23045, the server 2300 verifies the received 'Device.Auth'. The specific steps of the verification process are as follows: The server 2300 verifies the signature of the received "ssp1.Cert.DS" and / or "ssp2.Cert.DS" to verify the validity of the certificate. The server 2300 also verifies the signature of the received "spblAttestation" and / or "finalizationRequest" and / or "finalizationResponse". Additionally, the server 2300 verifies the contents of the received "spblAttestation" and / or "finalizationRequest" and / or "finalizationResponse". The server 2300 also updates the breakdown of bundles sent between the devices based on the verified content. For example, the server 2300 updates the mapping relationship that existed between the bundle and the first SSP 2210 to a mapping relationship between the bundle and the second SSP 2360. During this process, if the “Device.Auth” contains encrypted data, the server 2300 generates a session key “ShKey03” using the transmitted “ssp2.ePK.KA” and the private key corresponding to the key agreement public key contained in its own “spbm.Cert.KA” or “spbm.eSK.KA”, and then uses this session key to decrypt the encrypted data and then performs the verification process.

[0333] 23, in step 23050, the server 2300 transmits a result (eg, success / failure) of the operation performed in step 23045 to the second LBA 2370.

[0334] FIG. 24 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. Figure 24 shows the breakdown of transmissions between devices in a bundle. No need for pre-notification, If encryption of the notification content is not required, this may be the procedure that is applied.

[0335] According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, as in the example of FIG. 24, a first terminal 2400 includes a first LBA 2420 and a first SSP 2410, and a second terminal 2450 includes a second LBA 2470 and a second SSP 2460. For example, the first terminal 2400 may be a terminal having a first SSP 2410 installed and a first LBA 2420 for controlling the first SSP 2410, and the second terminal 2450 may be a terminal having a second SSP 2460 installed and a second LBA 2470 for controlling the second SSP 2460.

[0336] Referring to FIG. 24, the following steps are performed at step 24000: 1. [Bundle installation] Referring to FIG. 24, in step 24000, the second LBA 2470 and the second SSP 2460 cooperate with each other to install a bundle in the second terminal 2450. In this process, the following steps are performed together: If metadata is sent, the second LBA 2470 or the second SSP 2460 verifies the contents included in the metadata. If the “Bundle Migration Setting” is sent, the second LBA 2470 conveys this information to the second SSP 2460 . If a transaction ID is sent, the second LBA 2470 or the second SSP 2460 checks whether this transaction ID is the same as the transaction ID used in the current session. If at least one of the bundle identifier (SPB ID), bundle family identifier (SPB Family ID), and bundle family custodian object ID (SPB Family Custodian Object ID) is sent, the second LBA 2470 or the second SSP 2460 checks whether this information matches the information of the bundle it is currently attempting to receive. If “ssp1.Cert.DS” is sent, the second SSP 2460 verifies the validity of this certificate and authenticates the first SSP 2410 . If the transmitted data contains encrypted data, the second SSP 2460 generates a session key "ShKey02" using the transmitted "ssp1.bundle.ePK.KA" and its own "ssp2.eSK.KA", and uses this session key to decrypt the encrypted data and then performs verification. If the received data includes a digital signature, the second SSP 2460 verifies "ssp1.Cer.DS" and then uses this certificate to verify the validity of the digital signature.

[0337] 2. [Check "Registration Settings"] Also, although not shown in the figure, the second LBA 2470 and / or the second SSP 2460 uses the "registration settings" of the bundle to check "whether notification is necessary" and / or "whether advance notification is necessary" and / or "whether the notification content needs to be encrypted." This process may be performed independently of, or as part of, step 24000 and other steps performed in step 24000. Or it can be done at the moment when a decision is needed, after step 24,000 and before step 24,035 is completed. The procedure described below in this figure may be a procedure that is applied when, as a result of checking the "registration settings," the transmission details between the devices of the bundle do not need to be notified in advance and the notification contents do not need to be encrypted.

[0338] Referring to FIG. 24, in step 24005, the second SSP 2460 sets the state of the bundle to “IN TRANSITION”. "IN TRANSITION" means that the bundle has been successfully installed but is not yet usable (and can only be changed to a usable state (Disabled, Enable, Active state) by additional actions such as "additional actions described later in this figure" and / or "a request from an external server (not described in this invention)").

[0339] Referring to FIG. 24, in step 24010, the second LBA 2470 requests a “certificate” from the second SSP 2460. Referring to FIG. 24, at step 24015, the second SSP 2460 generates a “certificate.” In Figure 24, this certificate is called "finalizationRequest." The structure of this certificate is as disclosed in FIG.

[0340] At this time, an example of a possible certificate configuration is as follows: The "finalizationRequest" includes the "bundle classifier" of the bundle in question, reference numeral 1810 in FIG. The "finalizationRequest" includes the "SSP Identifier" of the second SSP at 1830 in FIG. The "finalizationRequest" includes information indicating that the second SSP has set the state of the bundle to "IN TRANSITION" as indicated by reference numeral 1850 in FIG. The "finalizationRequest" optionally includes the time when the second SSP changed the state of the bundle to "IN TRANSITION" or the time when it generated the certificate, 1870 in FIG. Alternatively, it includes information on the signing certificate used in the electronic signature described below and information on the associated certificate chain. · "finalizationRequest" includes the signature information of the second SSP at 1890 in FIG. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0341] Referring to FIG. 2, in step 24020, the second SSP 2460 transmits a "finalizationRequest" to the first SSP 2410. For example, the second SSP 2460 transmits a "finalizationRequest" to the first SSP 2410 through the following process. That is, the second SSP 2460 transmits a “finalizationRequest” to the second LBA 2470 in response to step 24010, and the second LBA 2470 transmits the “finalizationRequest” to the first SSP 2410 via the first LBA 2420.

[0342] Referring to FIG. 24, at step 24025, the first SSP 2410 verifies the received "finalizationRequest." This verification process includes checking the validity of the signature of the second SSP included in the "finalizationRequest". Also, this verification process may further include a process of checking whether the 'bundle classifier' included in the 'finalizationRequest' matches the bundle classifier of the bundle. This verification process may further include a process of checking whether the "SSP Identifier" included in the "finalizationRequest" is a correct identifier of the second SSP. Also, this verification process may further include a process of confirming whether the command information included in the 'finalizationRequest' is to change the state of the bundle to an 'IN TRANSITION' state.

[0343] Also, in step 24025, the first SSP 2410 deletes the bundle after verification.

[0344] Also, in step 24025, the first SSP 2410 generates a "certificate." In Figure 24, this certificate is called "finalizationResponse." The structure of this certificate is as disclosed in FIG.

[0345] At this time, an example of a possible certificate configuration is as follows: The "finalizationResponse" includes the "bundle classifier" of the bundle in question, reference numeral 1810 in FIG. Or it may contain part and / or the entire data of the "finalizationRequest" received in a previous step. The "finalizationResponse" includes the "SSP Identifier" of the first SSP at 1830 in FIG. · The "finalizationResponse" contains information indicating that the first SSP has deleted the bundle, as shown at 1850 in FIG. · The "finalizationResponse" optionally includes the time when the first SSP deleted the bundle or generated the certificate, 1870 in FIG. Alternatively, it includes information on the signing certificate used in the electronic signature described below and information on the associated certificate chain. · The "finalizationResponse" includes the signature information of the first SSP at 1890 in FIG. This signature may be signature information obtained by digitally signing the above-mentioned information with the signing certificate of the first SSP.

[0346] Referring to FIG. 24, in step 24030, the first SSP 2410 transmits a “finalizationResponse” to the second SSP 2460. For example, the first SSP 2410 transmits a “finalizationResponse” to the second SSP 2460 via the first LBA 2420 and the second LBA 2470.

[0347] Referring to FIG. 24, at step 24035, the second SSP 2460 verifies the received "finalizationResponse." This verification process includes checking the validity of the signature of the first SSP included in the "finalizationResponse". Also, this verification step may optionally further include a step of checking whether the 'bundle classifier' included in the 'finalizationResponse' matches the bundle classifier of the bundle. This verification process may also include a process of checking whether a part or all of the data in the "finalizationRequest" included in the "finalizationResponse" matches the information sent by the user. This verification process may further include a process of checking the "SSP Identifier" included in the "finalizationResponse". Also, this verification process may further include a process of confirming whether the command information included in the 'finalizationResponse' is to delete the bundle.

[0348] In step 24035, the second SSP 2460 changes the state of the bundle after the verification to one of the available states (one of Disabled, Enable, and Active). For example, as shown, the second SSP 2460 transitions the state of the bundle to a "Disabled" state.

[0349] Also, in step 24035, the second SSP 2460 generates a “certificate.” In Figure 24, this certificate is called "spblAttestation." The structure of this certificate is as disclosed in FIG.

[0350] At this time, an example of a possible certificate configuration is as follows: "spblAttestation" includes the "bundle classifier" of the bundle in question, reference numeral 1810 in FIG. Or it may include some and / or all of the data in the "finalizationRequest" and / or "finalizationResponse". "spblAttestation" contains the "SSP Identifier" of the second SSP at 1830 in FIG. "spblAttestation" contains information indicating that the second SSP has changed the bundle to one of the available states, as shown in FIG. · 'spblAttestation' optionally contains the time when the second SSP changed the state of the bundle to one of the available states or generated the certificate, 1870 in FIG. Alternatively, it includes information on the signing certificate used in the electronic signature described below and information on the associated certificate chain. "spblAttestation" contains the signature information of the second SSP at 1890 in FIG. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0351] Referring to FIG. 24, in step 24040, the second SSP 2460 transmits the 'spblAttestation' generated in step 24035.

[0352] FIG. 25 is a diagram showing a procedure in which the bundle transmission result is registered in the server after the procedure presented in FIG. According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, in the example of FIG. 25, a second terminal 2550 includes a second LBA 2570 and a second SSP 2560. For example, the second terminal 2550 may be a terminal to which a second SSP 2560 is attached and in which a second LBA 2570 for controlling the second SSP 2560 is installed.

[0353] Additionally, according to one embodiment, server 2500 may be a server operated by a service provider, may be a bundle management server, may be a server operated in cooperation between a service provider and a bundle management server, or may be any server operated in conjunction with a service provider and / or a bundle management server. In the description of this figure, the term SPBM may be used to refer to server 2500, which is any one of the possible examples of a server, although as noted above, the type of server is not limited to SPBM.

[0354] Referring to FIG. 25, in step 25000, a Transport Layer Security (TLS) connection is established between the SPBM 2500 and the LBA 2570.

[0355] Referring to FIG. 25, in step 25005, the second LBA 2570 transmits a part and / or the whole of the 'spblAttestation' and / or the 'finalizationRequest' and / or the 'finalizationResponse' to the server 2500. At this time, the second LBA 2570 may further send the “selected SSP information” to the server 2500 . For an explanation of "selected SSP information", please refer to the explanation of FIG. Additionally, the second LBA 2570 may selectively further transmit “ssp2.Cert.DS” to the server 2500 . Additionally, the second LBA 2570 may selectively further transmit “ssp1.Cert.DS” to the server 2500 . Additionally, the second LBA 2570 may further include certificate chain information associated with “ssp2.Cert.DS” and / or “ssp1.Cert.DS” on the server 2500 . The above information can be constructed and transmitted by the second LBA 2570 itself, or (not shown in this figure) the second LBA 2570 can request the information from the second SSP 2560 and then transmit the received information, or (not shown in this figure) the second LBA 2570 can request part of the information from the SSP 2560 and then transmit a combination of the received information and information it holds.

[0356] Referring to FIG. 25, in step 25010, the server 2500 verifies the information received in step 25005. The specific steps of the verification process are as follows: The server 2500 verifies the signature of the received "ssp1.Cert.DS" and / or "ssp2.Cert.DS" to verify the validity of the certificate. Server 2500 also verifies the signature of the received "spblAttestation" and / or "finalizationRequest" and / or "finalizationResponse". Server 2700 also verifies the contents of the received "spblAttestation" and / or "finalizationRequest" and / or "finalizationResponse". Server 2500 also updates the breakdown of bundles sent between devices based on the verified content. As an example, the server 2500 updates the mapping relationship that existed between the bundle and the first SSP 2410 to a mapping relationship between the bundle and the second SSP 2560.

[0357] 25, in step 25015 , the server 2500 transmits the result of the verification performed in step 25010 to the second LBA 2570 . For example, the server 2500 sends to the second LBA 2570 whether the verification is successful or unsuccessful.

[0358] FIG. 26 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. Figure 26 shows the breakdown of transmissions between devices in a bundle. -Pre-notification is required. -Whether encryption of the notification content is required or not; In this case, it may be the procedure that is applied.

[0359] According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, in the example of FIG. 26, a first terminal 2600 includes a first LBA 2620 and a first SSP 2610, and a second terminal 2650 includes a second LBA 2670 and a second SSP 2660. For example, the first terminal 2600 may be a terminal having a first SSP 2610 installed and a first LBA 2620 for controlling the first SSP 2610, and the second terminal 2650 may be a terminal having a second SSP 2660 installed and a second LBA 2670 for controlling the second SSP 2660.

[0360] Referring to FIG. 26, the following steps are performed at step 26000: 1. [Bundle installation] 26, in step 26000, the second LBA 2670 and the second SSP 2660 cooperate with each other to install a bundle in the second terminal 2650. In this process, the following steps are carried out together: If metadata is sent, the second LBA 2670 or the second SSP 2660 verifies the contents included in the metadata. If the “Bundle Migration Setting” is sent, the second LBA 2670 conveys this information to the second SSP 2660 . If a transaction ID is sent, the second LBA 2670 or the second SSP 2660 checks whether this transaction ID is the same as the transaction ID used in the current session. If at least one of the bundle identifier (SPB ID), bundle family identifier (SPB Family ID), and bundle family custodian object identifier (SPB Family Custodian Object ID) is sent, the second LBA 2670 or the second SSP 2660 checks whether this information matches the information of the bundle it is currently attempting to receive. If “ssp1.Cert.DS” is sent, the second SSP 2660 verifies the validity of this certificate and authenticates the first SSP 2610 . If the transmitted data contains encrypted data, the second SSP 2660 generates a session key "ShKey02" using the transmitted "ssp1.bundle.ePK.KA" and its own "ssp2.eSK.KA", and uses this session key to decrypt the encrypted data and then performs verification. If the received data includes a digital signature, the second SSP 2660 verifies "ssp1.Cer.DS" and then uses this certificate to verify the validity of the digital signature.

[0361] 2. [Check whether pre-registration is required] Also, although not shown in the figure, the second LBA 2670 and / or the second SSP 2660 uses the "registration settings" of the bundle to check "whether notification is necessary" and / or "whether advance notification is necessary" and / or "whether the notification content needs to be encrypted." This process may be performed independently of and as part of step 26000 and other steps performed in step 26000. Or it can be done at the moment when a decision is needed, after step 26,000 and before step 26,035 is completed. The procedure described below in this figure may be applied when, as a result of checking the "registration setting", it is necessary to pre-notify the transmission details between devices of the bundle.

[0362] Referring to FIG. 26, in step 26005, the second SSP 2660 sets the state of the bundle to “IN TRANSITION”. "IN TRANSITION" means that the bundle has been successfully installed but is not yet usable (and can only be changed to a usable state (Disabled, Enable, Active state) by additional actions such as "additional actions described later in this figure and additional actions described in FIG. 27" and / or "a request from an external server (not described in this invention)").

[0363] Referring to FIG. 26, in step 26010, the second LBA 2670 requests a “certificate” from the second SSP 2660.

[0364] Referring to FIG. 26, at step 26015, the second SSP 2660 generates a “certificate.” In Figure 26, this certificate is called "finalizationRequest." The structure of this certificate is as disclosed in FIG.

[0365] At this time, an example of a possible certificate configuration is as follows: The "finalizationRequest" includes the "bundle classifier" of the bundle in question, reference numeral 1810 in FIG. The "finalizationRequest" includes the "SSP Identifier" of the second SSP at 1830 in FIG. The "finalizationRequest" includes information indicating that the second SSP has set the state of the bundle to "IN TRANSITION" as indicated by reference numeral 1850 in FIG. The "finalizationRequest" optionally includes the time when the second SSP changed the state of the bundle to "IN TRANSITION" or the time when it generated the certificate, 1870 in FIG. Alternatively, it includes information on the signing certificate used in the electronic signature described below and information on the associated certificate chain. · "finalizationRequest" includes the signature information of the second SSP at 1890 in FIG. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0366] Referring to FIG. 26, in step 26020, the second SSP 2660 transmits a "finalizationRequest" to the first SSP 2610. For example, the second SSP 2660 transmits a "finalizationRequest" to the first SSP 2610 through the following process. That is, the second SSP 2660 transmits a “finalizationRequest” to the second LBA 2670 in response to step 26010, and the second LBA transmits the “finalizationRequest” to the first SSP via the first LBA 2620.

[0367] Referring to FIG. 26, at step 26025, the first SSP 2610 verifies the received "finalizationRequest." This verification process includes checking the validity of the signature of the second SSP included in the "finalizationRequest". Also, this verification process may further include a process of checking whether the 'bundle classifier' included in the 'finalizationRequest' matches the bundle classifier of the bundle. This verification process may further include a process of checking whether the "SSP Identifier" included in the "finalizationRequest" is a correct identifier of the second SSP. Also, this verification process may further include a process of confirming whether the command information included in the 'finalizationRequest' is to change the state of the bundle to an 'IN TRANSITION' state.

[0368] Also, in step 26025, the first SSP 2610 deletes the bundle after verification.

[0369] Also, in step 26025, the first SSP 2610 generates a “certificate.” In Figure 26, this certificate is called "finalizationResponse." The structure of this certificate is as disclosed in FIG.

[0370] At this time, an example of a possible certificate configuration is as follows: The "finalizationResponse" includes the "bundle classifier" of the bundle in question, reference numeral 1810 in FIG. Or it may contain part and / or the entire data of the "finalizationRequest" received in a previous step. The "finalizationResponse" includes the "SSP Identifier" of the first SSP at 1830 in FIG. · The "finalizationResponse" contains information indicating that the first SSP has deleted the bundle, as shown at 1850 in FIG. · The "finalizationResponse" optionally includes the time when the first SSP deleted the bundle or generated the certificate, 1870 in FIG. Alternatively, it includes information on the signing certificate used in the electronic signature described below and information on the associated certificate chain. · The "finalizationResponse" includes the signature information of the first SSP at 1890 in FIG. This signature may be signature information obtained by digitally signing the above-mentioned information with the signing certificate of the first SSP.

[0371] Referring to FIG. 26, in step 26030, the first SSP 2610 transmits a “finalizationResponse” to the second SSP 2660. For example, the first SSP 2610 transmits a “finalizationResponse” to the second SSP 2660 via the first LBA 2620 and the second LBA 2670.

[0372] Referring to FIG. 26, at step 26035, the second SSP 2660 verifies the received "finalizationResponse." This verification process includes checking the validity of the signature of the first SSP included in the "finalizationResponse". Also, this verification step may optionally further include a step of checking whether the 'bundle classifier' included in the 'finalizationResponse' matches the bundle classifier of the bundle. This verification process may also include a process of checking whether the data information or the entirety of the "finalizationRequest" included in the "finalizationResponse" matches the information sent by the "finalizationRequest". This verification process may further include a process of checking the "SSP Identifier" included in the "finalizationResponse". Also, this verification process may further include a process of confirming whether the command information included in the 'finalizationResponse' is to delete the bundle.

[0373] Also, in step 26035, the second SSP 2660 generates its own "selected SSP information (sspInforSelected)". The "selected SSP information" includes information of a second SSP that must be provided to inform the server of the bundle transmission result between devices.

[0374] At this time, the 'selected SSP information' includes information for the certificate negotiation process (certificate negotiation information). This "Certificate Negotiation Information" is - Certificate information that the second SSP2660 can use to verify the server (spbmVerification), Certificate information that the server can use to verify the first SSP2610 (SenderSpblVerification), Certificate information that the server can use to verify the second SSP2660 (ReceiverSpblVerification), It may selectively include information such as: In addition, the “certificate negotiation information” may optionally further include a list of key agreement algorithms supported by the second SSP 2660, and may optionally further include a list of encryption algorithms supported by the second SSP 2660. In addition, the "selected SSP information" may selectively further include SSP version information including at least one of the version information of the primary platform included in the second SSP 2660 and the standard supported by the loader.

[0375] Referring to FIG. 26, in step 26040, the second SSP 2660 transmits a result (eg, success / failure) of the operation performed in step 26035 to the second LBA 2670. In addition, the 'selected SSP information' generated in step 26035 may be transmitted together. The process of generating the “selected SSP information” in step 26035 and the process of transmitting the “selected SSP information” in step 26040 may be omitted.

[0376] FIG. 27 is a diagram showing a procedure in which the bundle transmission result is registered in the server after the procedure presented in FIG. According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, in the example of FIG. 27, a second terminal 2750 includes a second LBA 2770 and a second SSP 2760. As an example, the second terminal 2750 may be a terminal in which a second SSP 2760 is installed and a second LBA 2770 for controlling the second SSP 2760 is installed.

[0377] Additionally, according to one embodiment, server 2700 may be a server operated by a service provider, may be a bundle management server, may be a server operated in cooperation between a service provider and a bundle management server, or may be any server operated in conjunction with a service provider and / or a bundle management server. In the description of this figure, the term SPBM may be used to refer to server 2700, which is any one of the possible examples of a server, although as noted above, the type of server is not limited to SPBM.

[0378] Referring to FIG. 27, in step 27000, a Transport Layer Security (TLS) connection is established between the SPBM 2700 and the LBA 2770. Although step 27000 is shown to be performed before steps 27005 to 27015 in this figure, step 27000 may be performed independently of steps 27005 to 27015 before step 27020 is performed. For example, step 27000 may be performed between steps 27015 and 27020.

[0379] Referring to FIG. 27, in step 27005, the second LBA 2770 requests the second SSP 22760 for “selected SSP information (SspInfoSelected)”. At this time, step 27005 can be performed automatically or after receiving an external input. At this time, the "external input" can be provided by the user via a UI provided by the second terminal 2750, or can be provided to the second terminal 2750 via a push input from a remote server.

[0380] Referring to FIG. 27, in step 27010, the second SSP 2760 generates its own "selected SSP information." For an explanation of "selected SSP information", please refer to the explanation in FIG. 27, in step 27015, the second SSP 2760 transmits the 'selected SSP information' generated in step 27010 to the second LBA 2770. Steps 27005 to 27015 may be omitted in some cases.

[0381] Referring to FIG. 27, in step 27020, the second LBA 2770 transmits the “selected SSP information” to the server 2700. If the second LBA 2770 receives “selected SSP information” via steps 26035 to 26040 of FIG. 26, or receives “selected SSP information” via steps 27005 to 27015 of FIG. 27, the second LBA 2770 transmits the received “selected SSP information” to the server 2700. If the second LBA 2770 does not receive the “selected SSP information”, the second LBA 2770 generates the “selected SSP information” and sends it to the server 2700 .

[0382] Referring to FIG. 27, in step 27025, the server 2700 checks the received 'selected SSP information' and generates 'server authentication information (SPBM.Auth)' that can authenticate itself based on this information. A more specific procedure for this process is as follows:

[0383] The server 2700 checks the certificate information that can verify itself using the received 'spbmVerification' and selects at least one key agreement certificate (spbm.Cert.KA). Alternatively, the server 2700 generates an asymmetric encryption key pair (key pair), public key "spbm.ePK.KA" and private key "spbm.eSK.KA", to be used for key agreement using the received "list of key agreement algorithms supported by the second SSP 2760", and then selects the public key (spbm.ePK.KA) of the key pair. In addition, the server 2700 checks the certificate information that can verify itself using the received 'spbmVerification', and further selects at least one signing certificate (spbm.Cert.DS).

[0384] In addition, the server 2700 checks whether the certificate information of the first SSP 2610 to be verified using the received "senderSpblVerification" is something that the server 2700 can verify. In addition, the server 2700 checks whether the certificate information of the second SSP 2760 that is verified using the received "ReceiverSpblVerification" is something that the server 2700 can verify. Alternatively, after selecting at least one piece of second SSP 2760 certificate information that the user can verify using "ReceiverSpblVerification", the user sets the corresponding information in "CiPkIdToBeUsed".

[0385] In addition, the server 2700 selects at least one encryption algorithm to be used in the future using the received "list of encryption algorithms supported by the second SSP 2760", and then sets the corresponding information to "CryptoToBeUsed". The server 2700 also checks the received list of "version information of standards supported by the primary platform and loader contained in the second SSP 2760" to see if there is a version of a standard that the server 2700 also supports.

[0386] The "Server authentication information (SPBM.Auth)" includes at least one of the above-mentioned "spbm.Cert.KA", "spbm.ePK.KA", "spbm.Cert.DS", "CiPkIdToBeUsed", and "CryptoToBeUsed". At this time, a part or all of the "Server Authentication Information (SPBM.Auth)" mentioned above is digitally signed so that it can be verified using "spbm.Cert.DS" to ensure the integrity of the information, and this digital signature data is added as part of the "Server Authentication Information".

[0387] 27, in step 27030, the server 2700 transmits the server authentication information (SPBM.Auth) generated in step 27025 to the second SSP 2760 via the second LBA 2770.

[0388] Referring to FIG. 27, in step 27035, the second SSP 2760 verifies the received “server authentication information (SPBM.Auth)”. If the second SSP 2760 receives "spbm.Cert.KA", it checks the signature of the certificate to verify the validity of the certificate. Furthermore, when the second SSP 2760 receives "spbm.Cert.DS", it checks the signature of the certificate to verify the validity of the certificate. In addition, when the second SSP 2760 receives "spbm.ePK.KA" and its corresponding digital signature, it verifies the digital signature using "spbm.Cert.DS" to confirm the integrity of the received public key "spbm.ePK.KA". Furthermore, when the second SSP 2760 receives "CiPkIdToBeUsed", it checks this and selects at least one signing certificate (ssp2.Cert.DS) that can verify itself.

[0389] Also, although not shown in the figure, in step 27035, the second SSP 2760 generates a public key “ssp2.ePK.KA” and a private key “ssp2.eSK.KA” for an asymmetric encryption key pair used for key agreement, and then selects the public key (ssp2.ePK.KA) of the key pair. The second SSP 2760 also selects one of the key agreement public keys contained in “spbm.Cert.KA” or “spbm.ePK.KA”, and then uses this value and “ssp2.eSK.KA” to generate a session key “ShKey03” to be used for encryption in future communications with the server. "ShKey03" must be the session key for the encryption algorithm contained in the received "CryptoToBeUsed".

[0390] In addition, in step 27035, the second SSP 2760 generates “terminal authentication information (Device.Auth)” that can authenticate itself. At this time, the "Device authentication information (Device.Auth)" includes "ssp2.Cert.DS". In addition, the "terminal authentication information (Device.Auth)" may further include "ssp2.ePK.KA". In addition, the "Device authentication information (Device.Auth)" may selectively further include "ssp1.Cert.DS". In addition, the "terminal authentication information (Device.Auth)" may include a part and / or the entirety of the "finalizationRequest". In addition, the "terminal authentication information (Device.Auth)" may include a part and / or the entirety of the "finalizationResponse".

[0391] At this time, a part or all of the "Device.Auth" mentioned above is digitally signed so that it can be verified using "ssp2.Cert.DS" to ensure the integrity of the information, and this digital signature data is added as part of the "Device.Auth". In addition, a part or the whole of the "terminal authentication information (Device.Auth)" is encrypted using the session key "ShKey03" generated in advance.

[0392] Referring to FIG. 27, in step 27040, the second SSP 2760 transmits the “Device.Auth” generated in step 27035 to the server 2700 via the second LBA 2770.

[0393] Referring to FIG. 27, in step 27045, the server 2700 verifies the received 'Device.Auth'. The specific steps of the verification process are as follows: The server 2700 verifies the signature of the received "ssp1.Cert.DS" and / or "ssp2.Cert.DS" to verify the validity of the certificate. Server 2700 also verifies the signature of the received "finalizationRequest" and / or "finalizationResponse." The server 2700 also verifies the contents of the received "finalizationRequest" and / or "finalizationResponse." Server 2700 also updates the breakdown of bundles sent between devices based on the verified content. For example, the server 2700 updates the mapping relationship that existed between the bundle and the first SSP 2610 to a mapping relationship between the bundle and the second SSP 2760. During this process, if the “Device.Auth” contains encrypted data, the server 2700 generates a session key “ShKey03” using the transmitted “ssp2.ePK.KA” and the private key corresponding to the key agreement public key contained in its own “spbm.Cert.KA” or “spbm.eSK.KA”, and then uses this session key to decrypt the encrypted data and then performs the verification process.

[0394] Also, in step 27045, the server 2700 generates a "certificate." In FIG. 27, this certificate is called "spbmAttestation." The structure of this certificate is as disclosed in FIG.

[0395] At this time, an example of a possible certificate configuration is as follows: "spbmAttestation" includes the "bundle classifier" of the bundle in question, reference numeral 1810 in FIG. Or it may include partial and / or entire data of the "finalizationRequest" and / or "finalizationResponse" received in a previous stage. 'spbmAttestation' includes a server identifier (eg, a service provider identifier and / or a bundle management server identifier and / or a server address) in FIG. 18 at 1830. 'spbmAttestation' includes information indicating that the server has confirmed the details of the transfer of the bundle, as shown in FIG. 18 at 1850. 'spbmAttestation' selectively includes the time when the server confirmed the transfer details of the bundle or the time when the certificate was generated as shown in FIG. 18 at 1870. Alternatively, it includes information on the signing certificate used in the electronic signature described below and information on the associated certificate chain. "spbmAttestation" contains the server signature information at 1890 in FIG. This signature may be signature information obtained by digitally signing the above-mentioned information with the server's signing certificate.

[0396] Also, in step 27045, although not shown in FIG. 27, the server 2700 generates an asymmetric encryption key pair, a public key "spbm.attestation.ePK.KA" and a private key "spbm.attestation.eSK.KA", used for key agreement. At this time, the key pair "spbm.attestation.ePK.KA" and "spbm.attestation.eSK.KA" may be set to the same values ​​as the previously generated "spbm.ePK.KA" and "spbm.eSK.KA". Alternatively, the key pair "spbm.attestation.ePK.KA" and "spbm.attestation.eSK.KA" may be configured with the same values ​​as the public key and corresponding private key contained in the previously used "spbm.Cert.KA". Additionally, server 2700 generates a session key "ShKey04" using "spbm.attestation.eSK.KA" and "ssp2.ePK.KA". If the private key corresponding to the public key contained in "spbm.eSK.KA" or "spbm.Cert.Ka" for "spbm.attstation.eSK.KA" is reused, the value of the session key "ShKey04" may also be set to the value of the previously generated "ShKey03".

[0397] Also, in step 27045, although not shown in FIG. 27, the server 2700 configures “certificate validation materials”. "Certificate validation materials" includes "spbm.Cert.DS". Additionally, "spbm.attestation.ePK.KA" and / or the server's digital signature value for "spbm.attestation.ePK.KA" may also be included. According to one embodiment, the 'Certificate' and / or 'Certificate Validation Materials' generated in step 27045 are partially and / or entirely encrypted using 'ShKey04'.

[0398] Referring to FIG. 27, in step 27050, the server 2700 transmits the 'spbmAttestation' and the 'certificate verification data' generated in step 27045 to the second SSP 2760 via the second LBA 2770.

[0399] Referring to FIG. 27, in step 27055, the second SSP 2760 verifies the received 'spbmAttestation' and / or 'certificate validation material'. If the transmitted data contains encrypted data, the second SSP 2760 generates a session key "ShKey04" using the transmitted "spbm.attestation.ePK.KA" and its own "ssp2.eSK.KA", and uses this session key to decrypt the encrypted data and then performs verification. If the received data includes a digital signature, the second SSP 2760 verifies "spbm.Cert.DS" and then uses this certificate to verify the validity of the digital signature.

[0400] In step 27055, the second SSP 2760 changes the state of the bundle after the verification to one of the available states (one of Disabled, Enable, and Active). For example, as shown, the second SSP 2760 transitions the state of the bundle to a "Disabled" state.

[0401] 27, in step 27060, the second SSP 2760 transfers the execution result of step 27060 to the second LBA 2770. For example, the second SSP 2760 transmits the verification success or failure result of step 27060 to the second LBA 2770.

[0402] FIG. 28 is a block diagram showing a schematic configuration of a terminal according to an embodiment of the present invention. As shown in FIG. 28, the terminal includes a transceiver 2810 and at least one processor 2820. The terminal further includes an SSP2830. For example, the SSP2830 can be inserted into a terminal or can be built into the terminal.

[0403] At least one of the processors 2820 may also be referred to as a "controller." However, the configuration of the terminal is not limited to that of FIG. 28 and may include more or fewer components than those shown in FIG. According to one embodiment, the transceiver 2810, at least one processor 2820, and a memory (not shown) may be implemented in the form of a single chip. Also, when the SSP2830 is built-in, it may be embodied in the form of a single chip including the SSP2830.

[0404] According to an embodiment, the transceiver 2810 transmits and receives signals, information, data, etc. to and from a transceiver of another terminal or an external server according to an embodiment of the present invention. The transceiver 2810 includes an RF transmitter that up-converts and amplifies the frequency of a signal to be transmitted, and an RF receiver that low-noise amplifies a received signal and down-converts the frequency. However, this is only one embodiment of the transceiver unit 2810, and the components of the transceiver unit 2810 are not limited to an RF transmitter and an RF receiver. In addition, the transceiver 2810 receives a signal via a wireless channel and outputs it to at least one processor 2820, and transmits the signal output from the at least one processor 2820 via a wireless channel.

[0405] According to one embodiment, the transceiver 2810 transmits or receives information about an SSP included in another terminal, authentication information capable of authenticating another terminal, authentication information capable of authenticating a server, authentication information capable of authenticating itself, a bundle transfer code, bundle transfer settings, a bundle, various certificates described in Figures 22 to 27, etc. from the transceiver of another terminal or an external server.

[0406] Meanwhile, the at least one processor 2820 is a component for overall control of the terminal. At least one processor 2820 controls the overall operation of the terminal according to various embodiments of the present invention as described above.

[0407] On the other hand, the SSP2830 may include a processor or controller for installing and controlling bundles or applications may be installed. According to one embodiment, at least one processor or controller within SSP 2830 examines the bundle transfer settings to determine whether to transmit a particular bundle. Also, the bundle transfer setting is checked to determine whether the result of the bundle transfer between devices of the bundle should be registered in the server, and if registration is required, whether advance notice is required.

[0408] Additionally, according to one embodiment, at least one processor or controller within the SSP generates a bundle transfer code to control the transmission process of a particular bundle. Also, according to one embodiment, at least one processor or controller within an SSP generates its own SSP information and checks and verifies SSP information of other SSPs transmitted from outside. Also, according to one embodiment, at least one processor or controller within an SSP generates authentication information that can verify itself and verify authentication information of other SSPs sent from outside. Additionally, according to one embodiment, SSP 2830 creates bundles and installs the bundles alone or in cooperation with one or more processors 2820. The SSP2830 also manages the bundles.

[0409] Additionally, according to one embodiment, the SSP 2830 generates certificates in various formats as described in FIGS. 22-27 and verifies received certificates. Additionally, according to one embodiment, the SSP 2830 changes the state of the bundle based on the contents of the received certificate as described in Figures 22-27. Additionally, according to one embodiment, SSP 2830 operates under the control of processor 2820. Alternatively, the SSP 2830 may include a processor or controller for installing and controlling the bundles or applications may be installed. Some or all of the applications may be located in the SSP 2830 or in memory (not shown).

[0410] Meanwhile, the terminal further includes a memory (not shown) for storing data such as basic programs, applications, and setting information for the operation of the terminal. The memory may also include at least one storage medium of a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), a magnetic memory, a magnetic disk, an optical disk, a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), a programmable read-only memory (PROM), or an electrically erasable programmable read-only memory (EEPROM). In addition, the processor 2820 performs various operations using various programs, contents, data, etc. stored in the memory.

[0411] FIG. 29 is a block diagram showing a schematic configuration of a server according to an embodiment of the present invention. In this case, the server may be a server operated by a service provider, a bundle management server, a server operated in cooperation between the service provider and the bundle management server, or any server operated in conjunction with the service provider and / or the bundle management server. In the description of this figure, the term bundle management server is used to refer to the server as any one of the possible examples of the server, however, as previously mentioned, the type of server is not limited to a bundle management server.

[0412] According to one embodiment, the bundle management server includes a transceiver 2910 and at least one processor 2920 . However, the configuration of the bundle management server is not limited to that of FIG. 29 and may include more or fewer components than those shown in FIG. According to one embodiment, the transceiver 2910, at least one processor 2920, and a memory (not shown) may be implemented in the form of a single chip.

[0413] According to one embodiment, the transceiver 2910 transmits and receives signals, information, data, etc., to and from a terminal according to various embodiments of the present invention. The transceiver 2910 includes an RF transmitter that up-converts and amplifies the frequency of a signal to be transmitted, and an RF receiver that low-noise amplifies and down-converts the frequency of a received signal. However, this is only one embodiment of the transceiver unit 2910, and the components of the transceiver unit 2910 are not limited to an RF transmitter and an RF receiver. In addition, the transceiver unit 2910 receives a signal via a wireless channel and outputs the signal to at least one processor 2920, and transmits the signal output from the at least one processor 2920 via a wireless channel.

[0414] Meanwhile, at least one processor 2920 is a component for controlling the overall bundle management server. The processor 2920 controls the overall operation of the bundle management server in accordance with various embodiments of the present invention as previously described. At least one of the processors 2920 may be referred to as a controller.

[0415] Meanwhile, the bundle management server further includes a memory (not shown) for storing data such as basic programs, applications, and setting information for the operation of the bundle management server. The memory may also include at least one storage medium of a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (e.g., SD or XD memory, etc.), a magnetic memory, a magnetic disk, an optical disk, a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), a programmable read-only memory (PROM), or an electrically erasable programmable read-only memory (EEPROM). In addition, the processor 2920 performs various operations using various programs, contents, data, etc. stored in the memory.

[0416] FIG. 30 is a diagram showing another detailed procedure for completing the transmission of a bundle among the procedures presented in FIG. 19, and a procedure for registering the result of the transmission of the bundle in the server. According to one embodiment, a terminal includes at least one LBA and at least one SSP. For example, as in the example of FIG. 30, a first terminal 3000 includes a first LBA 3020 and a first SSP 3010, and a second terminal 3050 includes a second LBA 3070 and a second SSP 3060. For example, the first terminal 3000 may be a terminal having a first SSP 3010 installed and a first LBA 3020 for controlling the first SSP 3010, and the second terminal 3050 may be a terminal having a second SSP 3060 installed and a second LBA 3070 for controlling the second SSP 3060.

[0417] Referring to FIG. 30, the following steps are performed at step 30000: 1. [Bundle installation] 30, in step 30000, the second LBA 3070 and the second SSP 3060 cooperate with each other to install a bundle in the second terminal 3050. In this process, the following steps are performed together: If metadata is sent, the second LBA 3070 or the second SSP 3060 verifies the contents included in the metadata. If the “bundle migration setting” is sent, the second LBA 3070 transmits the above information to the second SSP 060 . If a transaction ID is sent, the second LBA 3070 or the second SSP 3060 checks whether this transaction ID is the same as the transaction ID used in the current session. If at least one of the bundle identifier (SPB ID), bundle family identifier (SPB Family ID), and bundle family custodian object ID (SPB Family Custodian Object ID) is sent, the second LBA 3070 or the second SSP 3060 checks whether this information matches the information of the bundle it is currently attempting to receive. If “sp1.Cert.DS” is sent, the second SSP 3060 verifies the validity of this certificate and authenticates the first SSP 3010 . If the transmitted data contains encrypted data, the second SSP3060 generates a session key "ShKey02" using the transmitted "ssp1.bundle.ePK.KA" and its own "ssp2.eSK.KA", and uses this session key to decrypt the encrypted data and then performs verification. If the received data includes a digital signature, the second SSP 3060 verifies "ssp1.Cer.DS" and then uses this certificate to verify the validity of the digital signature.

[0418] 2. [Check "Registration Settings"] Also, although not shown in the figure, the second LBA 3070 and / or the second SSP 3060 uses the "registration settings" of the bundle to check "whether notification is necessary" and / or "whether advance notification is necessary" and / or "whether the notification content needs to be encrypted." This process may be performed independently of, and as part of, step 30,000 and other steps performed in step 30,000. Alternatively, the decision can be made at the moment when a decision is required after step 30000 and before the notification is made at step 30040 or step 30050 by checking the "Registration Settings".

[0419] Referring to FIG. 30, in step 30005, the second SSP 3060 sets the state of the bundle to "IN TRANSITION." "IN TRANSITION" means a state in which the bundle has been successfully installed but is unavailable for use (and can only be changed to a usable state (Disabled, Enable, Active state) by actions such as a "request from the first terminal 3000" and / or a "request from an external server").

[0420] Referring to FIG. 30, in step 30010, the second LBA 3070 requests a “certificate” from the second SSP 3060.

[0421] Referring to FIG. 30, in step 30015, the second SSP 3060 generates a “certificate.” In Figure 30, this certificate is called "finalizationRequest." The structure of this certificate is as disclosed in FIG.

[0422] At this time, an example of a possible certificate configuration is as follows: The "finalizationRequest" includes the "bundle classifier" of the bundle in question, reference numeral 1810 in FIG. The "finalizationRequest" includes the "SSP Identifier" of the second SSP at 1830 in FIG. The "finalizationRequest" includes information indicating that the second SSP has set the state of the bundle to "IN TRANSITION" as indicated by reference numeral 1850 in FIG. The "finalizationRequest" optionally includes the time when the second SSP set the bundle state to "IN TRANSITION" or the time when the certificate was generated, as shown at 1870 in FIG. Alternatively, it includes information on the signing certificate used in the electronic signature described below and information on the associated certificate chain. · "finalizationRequest" includes the signature information of the second SSP at 1890 in FIG. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0423] Referring to FIG. 30, in step 30020, the second SSP 3060 transmits a "finalizationRequest" to the first SSP 3010. For example, the second SSP 3060 transmits a "finalizationRequest" to the first SSP 3010 through the following process. That is, the second SSP 3060 transmits a 'finalizationRequest' to the second LBA 3070 in response to step 30010 , and the second LBA 3070 transmits the 'finalizationRequest' to the first SSP 3010 via the first LBA 3020 .

[0424] Referring to FIG. 30, at step 30025, the first SSP 3010 verifies the received "finalizationRequest." This verification process may include checking the validity of the signature of the second SSP included in the "finalizationRequest." Also, this verification process may further include a process of checking whether the 'bundle classifier' included in the 'finalizationRequest' matches the bundle classifier of the bundle. This verification process may further include a process of checking whether the "SSP Identifier" included in the "finalizationRequest" is a correct identifier of the second SSP. Also, this verification process may further include a process of confirming whether the command information included in the 'finalizationRequest' is to change the state of the bundle to an 'IN TRANSITION' state.

[0425] Also, in step 30025, the first SSP 3010 sets the state of the bundle to "IN TRANSITION" after the verification is completed. "IN TRANSITION" means that the bundle has been successfully installed but is not available for use (and can only be changed to a usable state (Disabled, Enable, Active state) by additional actions such as a "request from the second terminal 3050" and / or a "request from an external server").

[0426] Also, in step 30025, the first SSP 3010 generates a "certificate." In Figure 30, this certificate is called "finalizationResponse." The structure of this certificate is as disclosed in FIG.

[0427] At this time, an example of a possible certificate configuration is as follows: The "finalizationResponse" includes the "bundle classifier" of the bundle in question, reference numeral 1810 in FIG. Or it may contain part and / or the entire data of the "finalizationRequest" received in a previous step. The "finalizationResponse" includes the "SSP Identifier" of the first SSP at 1830 in FIG. The "finalizationResponse" includes information indicating that the first SSP has set the bundle state to "IN TRANSITION" as indicated by reference numeral 1850 in FIG. · The "finalizationResponse" optionally includes the time when the first SSP set the bundle state to "IN TRANSITION" or the time when the certificate was generated, 1870 in FIG. Alternatively, it includes information on the signing certificate used in the electronic signature described below and information on the associated certificate chain. · The "finalizationResponse" includes the signature information of the first SSP at 1890 in FIG. This signature may be signature information obtained by digitally signing the above-mentioned information with the signing certificate of the first SSP.

[0428] Referring to FIG. 30, in step 30030, the first SSP 3010 transmits a “finalizationResponse” to the second SSP 3060. For example, the first SSP 3010 transmits a “finalizationResponse” to the second SSP 3060 via the first LBA 3020 and the second LBA 3070 .

[0429] Referring to FIG. 30, at step 30035, the second SSP 3060 verifies the received "finalizationResponse." This verification process includes checking the validity of the signature of the first SSP included in the "finalizationResponse". Also, this verification step may optionally further include a step of checking whether the 'bundle classifier' included in the 'finalizationResponse' matches the bundle classifier of the bundle. This verification process may also include a process of checking whether a part or all of the data in the "finalizationRequest" included in the "finalizationResponse" matches the information sent by the user. This verification process may further include a process of checking the "SSP Identifier" included in the "finalizationResponse". Also, this verification process may further include a process of checking whether the command information included in the 'finalizationResponse' is to set the state of the bundle to 'IN TRANSITION'.

[0430] Referring to FIG. 30, in step 30040, a pre-notification procedure is performed. This procedure may be applied if advance notice is set as required in the "Registration Settings". If an advance notice procedure is performed, the procedure is as follows.

[0431] First, the second SSP 3060 generates “sspInfoSelected” and sends this information via the second LBA 3070 . This step may be omitted if necessary. At this time, for the explanation of 'sspInfoSelected', please refer to the explanation of FIG. After this, the process up to step 27055 of the procedure shown in FIG. 27, ie, “the procedure for changing the bundle state to one of the available states (one of Disabled, Enable, and Active)”, is carried out.

[0432] Referring to FIG. 30, in step 30045, the second SSP 3060 changes the state of the bundle to one of the available states (one of Disabled, Enable, and Active). For example, as shown, the second SSP 3060 changes the state of the bundle to a "Disabled" state.

[0433] Also, in step 30045, the second SSP 3060 generates a "certificate." In Figure 30, this certificate is called "spblAttestation." The structure of this certificate is as disclosed in FIG.

[0434] At this time, an example of a possible certificate configuration is as follows: "spblAttestation" includes the "bundle classifier" of the bundle in question, reference numeral 1810 in FIG. Or it may include partial and / or entire data of "finalizationRequest" and / or "finalizationResponse" and / or "spbmAttestation". "spblAttestation" contains the "SSP Identifier" of the second SSP at 1830 in FIG. "spblAttestation" contains information indicating that the second SSP has changed the bundle to one of the available states, as shown in FIG. 18 at 1850. "spblAttestation" optionally includes the time when the second SSP changed the state of the bundle to one of the available states or generated the certificate, as shown at 1870 in FIG. Alternatively, it includes information on the signing certificate used in the electronic signature described below and information on the associated certificate chain. "spblAttestation" contains the signature information of the second SSP at 1890 in FIG. This signature may be signature information obtained by digitally signing the above-mentioned information with a signing certificate of the second SSP.

[0435] Referring to FIG. 30, in step 30050, a post-notification procedure is performed. This procedure may be applied if advance notice is set as required in the "Registration Settings". If a post-announcement procedure is performed, the procedure is as follows.

[0436] a. [If encryption of notification content is required in "Registration Settings"] First, the second SSP 3060 generates “sspInfoSelected” and sends this information via the second LBA 3070 . This step may be omitted if necessary. At this time, for the explanation of 'sspInfoSelected', please refer to the explanation of FIG. Thereafter, the procedure shown in FIG. 23 is carried out.

[0437] b. [If encryption of notification content is not required in the "Registration Settings"] First, the second SSP 3060 sends “spblAttestation” to the second LBA 3070 . Thereafter, the procedure shown in FIG. 25 is carried out.

[0438] Referring to FIG. 30, in step 30055, the second SSP 3060 transmits 'spblAttestation' to the first SSP 3010 via the second LBA 3070 and the first LBA 3020.

[0439] Referring to FIG. 30, in step 30060, the first SSP 3010 verifies the received 'spblAttestation'. This verification process involves checking the validity of the signature of the second SSP contained in "spblAttestation." Also, this verification process may further include a process of checking whether the 'bundle classifier' included in 'spblAttestation' matches the bundle classifier of the bundle. Also, this verification process may further include a process of checking whether the "SSP Identifier" included in "spblAttestation" is a correct identifier of the second SSP. Also, this verification step may further include a step of verifying whether the command information included in 'spblAttestation' is to set the state of the bundle to one of the available states.

[0440] Also, in step 30060, the first SSP 3010 deletes the bundle.

[0441] In step 30045, the procedure for generating "spblAttestation" and / or steps 30055 and / or 30060 may be omitted if necessary. If the notification process described in step 30040 or 30050 is not completed (eg, if a notification is sent to the server but a response thereto is not received), the second terminal repeatedly retransmits the notification to the notification server. The retransmission process may be repeated until a preset maximum number of retransmissions is reached, or may be repeated until a response is received from the server.

[0442] If advance notification is required according to the "Registration Setting" but step 30040 is not performed normally, and the bundle becomes unavailable on both the first terminal 3000 and the second terminal 3050, the state of the bundle installed on the first terminal 3000 and / or the second terminal 3050 is changed from "IN TRANSITION" to one of the available states (e.g., "Disabled" state) upon request from the server described in FIG. 29.

[0443] In the specific embodiments of the present invention described above, elements contained in the disclosure have been expressed in the singular or plural form according to the specific embodiments presented. However, the expressions singular or plural have been selected to suit the context presented for the convenience of explanation, and the present invention is not limited to singular or plural elements, and elements expressed in the plural may be comprised in the singular and elements expressed in the singular may be comprised in the plural.

[0444] Meanwhile, in the detailed description of the present invention, a specific embodiment has been described, but it is obvious that various modifications can be made within the scope of the present invention without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiment, but should be determined by not only the claims set forth below, but also equivalents thereto.

[0445] The various embodiments of the present invention and the terminology used herein are not intended to limit the technology described in the present invention to a particular embodiment, but should be understood to include various modifications, equivalents, and / or alternatives of the embodiment. In connection with the description of the drawings, like reference numerals have been used to refer to like elements. A singular expression can include a plural expression unless otherwise clearly indicated in the context. In the present invention, expressions such as "A or B," "at least one of A and / or B," "A, B or C," "at least one of A, B and / or C," etc. may include all possible combinations of the items listed together. Expressions such as "first," "second," "initial," or "second" may modify the relevant element regardless of order or importance, and are used only to distinguish one element from other elements, not to limit the relevant element. When a (e.g., first) component is referred to as being "functionally or communicatively coupled" or "connected" to another (e.g., second) component, the one component may be directly coupled to the other component or may be coupled through another component (e.g., a third component).

[0446] The term "module" used in the present invention includes a unit configured of hardware, software, or firmware, and is used interchangeably with terms such as logic, logic block, component, or circuit. A module is an integrally constructed part or the smallest unit or part thereof that performs one or more functions. For example, a module may be constructed from an application-specific integrated circuit (ASIC).

[0447] Various embodiments of the present specification may be embodied in software (e.g., a program) including commands stored on a storage medium (e.g., internal or external memory) readable by a machine (e.g., a computer). The device may include other terminals according to various embodiments as devices capable of calling commands stored in the storage medium and operating according to the called commands. When a command is executed by a processor, the processor performs the function corresponding to the command, either directly or by using other components under the control of the processor. The commands may include code that is generated or executed by a compiler or an interpreter.

[0448] The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, "non-transient" simply means that the storage medium does not contain a signal and is tangible, and does not distinguish between data being stored semi-permanently or temporarily on the storage medium.

[0449] Methods according to various embodiments disclosed herein may be provided in a computer program product. Computer program products are traded as commodities between sellers and buyers. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disc read only memory (CD-ROM)) or online via an application store (e.g., Play Store®). In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily generated on a storage medium, such as a memory of a manufacturer's server, an application store's server, or an intermediate server. Each component (e.g., a module or a program) according to one embodiment may be composed of one or more entities, and some of the subcomponents described above may be omitted, or other subcomponents may be further included in various embodiments. Generally or additionally, multiple components (e.g., modules or programs) may be integrated into a single entity and perform the same or similar functions as those performed by each of the components prior to the integration. According to various embodiments, operations performed by a module, program, or other component may be performed sequentially, in parallel, iteratively, or heuristically, at least some operations may be performed in a different order, omitted, or other operations may be added. [Explanation of symbols]

[0450] 110, 310 terminals 120, 210, 330, 1630, 2830 SSP 130 Terminal 1 140, 150 Telecom Bundle 170 Payment Bundle 180 Electronic ID Card Bundle 220 Primary Platform 222 Lower-level Operating Systems 230, 240, 335, 337, 339 Secondary Platform Bundles 232 Higher Layer Operating Systems 234 Applications 250 Primary Platform Interface 312 LBA 331 Primary Platform 333 Secondary Platform Bundle Loader 341, 342, 343 Bundle Family Administrator Identifier 1610, 2810, 2910 Transmitter / Receiver 1620, 2820, 2920 processors

Claims

1. A method of operating a first terminal, comprising: transmitting the bundle to a second terminal; receiving, from the second terminal, a first certificate generated including bundle status information of the second terminal; verifying the bundle status information of the second terminal and verifying the received first certificate; generating a second certificate including bundle status information of the first terminal after verifying the first certificate; transmitting the second certificate at the second terminal; The method for operating a first terminal, wherein the bundle is a Secondary Platform Bundle (SPB) of the first terminal.

2. The bundle status information of the first terminal includes that the bundle status of the first terminal is set to at least one of "DELETE", "IN TRANSITION", and "SUSPENSION", receiving, from the second terminal, a third certificate generated including information regarding a change in the bundle status of the second terminal when the bundle status of the first terminal is set to "IN TRANSITION"; verifying the received third certificate; The method of claim 1, further comprising: after verifying the third certificate, deleting the bundle of the first terminal.

3. A method of operating a second terminal, comprising: receiving a bundle from a first terminal; placing the bundle; generating a first certificate including bundle state information of a second terminal; transmitting the first certificate to the first terminal; receiving, from the first terminal, a second certificate generated including bundle status information of the first terminal; verifying the verification of the bundle status information of the first terminal and verifying the received second certificate; and modifying bundle status setting information of the second terminal after verifying the second certificate; The method for operating a second terminal, wherein the bundle is a Secondary Platform Bundle (SPB) of the first terminal.

4. The step of changing the bundle status setting information of the second terminal includes changing the bundle status of the second terminal to at least one of an enable, an active, and a disabled state; The bundle status information of the first terminal is set to at least one of "DELETE", "IN TRANSITION" and "SUSPENSION", and when the bundle status of the first terminal is set to "IN TRANSITION", generating a third certificate including information regarding a change in the bundle status of the second terminal; 4. The method of claim 3, further comprising the step of: transmitting the third certificate to the first terminal.

5. generating a fourth certificate including information regarding a result of verifying the first certificate and the second certificate; The method of claim 3, further comprising the step of transmitting the fourth certificate to a server.

6. receiving, from the server, a fifth certificate generated including a result of authentication with the server; verifying the received fifth certificate; The method of claim 3, further comprising: changing bundle state setting information of the second terminal after verifying the fifth certificate.

7. A first terminal, A transceiver unit capable of transmitting and receiving at least one signal; a controller coupled to the transceiver unit; the control unit is configured to transmit a bundle to a second terminal, receive from the second terminal a first certificate generated including bundle status information of the second terminal, verify verification of the bundle status information of the second terminal, verify the received first certificate, generate a second certificate including bundle status information of the first terminal after verifying the first certificate, and transmit the second certificate on the second terminal; The first terminal, wherein the bundle is a Secondary Platform Bundle (SPB) of the first terminal.

8. The control unit receives a third certificate from the second terminal, the third certificate being generated including information regarding a change in the bundle status of the second terminal when the bundle status of the first terminal is set to "IN TRANSITION"; Verifying the received third certificate; The method is further configured to delete the bundle of the first terminal after verifying the third certificate; The first terminal of claim 7, wherein the bundle status information of the first terminal includes that the bundle status of the first terminal is set to at least one of "DELETE", "IN TRANSITION", and "SUSPENSION".

9. A second terminal, A transceiver unit capable of transmitting and receiving at least one signal; a controller coupled to the transceiver unit; the control unit is configured to receive a bundle from a first terminal, install the bundle, generate a first certificate including bundle status information of a second terminal, transmit the first certificate to the first terminal, receive a second certificate generated including the bundle status information of the first terminal from the first terminal, verify verification of the bundle status information of the first terminal, verify the received second certificate, and change bundle status setting information of the second terminal after verifying the second certificate; The second terminal, wherein the bundle is a Secondary Platform Bundle (SPB) of the first terminal.

10. The control unit is configured to change a bundle state of the second terminal to at least one of an enable state, an active state, and a disabled state; When the bundle state of the first terminal is set to “IN TRANSITION”, the third certificate including information on the bundle state change of the second terminal is generated, and the third certificate is transmitted to the first terminal; The second terminal of claim 9, wherein the bundle status information of the first terminal is set to at least one of "DELETE", "IN TRANSITION", and "SUSPENSION".

11. The second terminal of claim 9, wherein the control unit is further configured to generate a fourth certificate including information regarding a verification result of the first certificate and the second certificate, and to transmit the fourth certificate to a server.

Images