Apparatus, and methods for secure device to device bundle transfer

Abstract

The present disclosure relates to a communication technique and a system for integrating a 5G communication system with IoT technology to support higher data transmission rates than those of 4G systems. The present disclosure 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 disclosure discloses a method and apparatus for securely moving and managing bundles during bundle transfer between smart security media.

Description

Technology Field

[0001] The present disclosure relates to smart security media, and more specifically, to a method and apparatus for moving bundles between smart security media. Background Technology

[0002] Efforts are being made to develop improved 5G or pre-5G communication systems to meet the increasing demand for wireless data traffic since the commercialization of 4G communication systems. For this reason, 5G or pre-5G communication systems are referred to as Beyond 4G Network communication systems or Post-LTE systems. To achieve high data transmission rates, the implementation of 5G communication systems in the mmWave band (e.g., the 60 GHz band) is being considered. To mitigate path loss and increase transmission distance in the mmWave band, technologies such as beamforming, massive MIMO, full Dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and large-scale antennas are being discussed for 5G communication systems. In addition, to improve the network of the system, the development of technologies such as advanced small cell, advanced small cell, cloud radio access network (cloud RAN), ultra-dense network, Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, CoMP (Coordinated Multi-Points), and interference cancellation is taking place in 5G communication systems.In addition, advanced coding modulation (ACM) methods such as FQAM (Hybrid FSK and QAM Modulation) and SWSC (Sliding Window Superposition Coding), as well as advanced access technologies such as FBMC (Filter Bank Multi Carrier), NOMA (non-orthogonal multiple access), and SCMA (sparse code multiple access) are being developed in 5G systems.

[0003] Meanwhile, the Internet is evolving from a human-centered network where humans generate and consume information into an IoT (Internet of Things) network where distributed components, such as objects, exchange and process information. IoE (Internet of Everything) technology, which combines IoT with Big Data processing technologies through connections with cloud servers, is also emerging. To implement IoT, technological elements such as sensing technology, wired and wireless communication and network infrastructure, service interface technology, and security technology are required; consequently, technologies such as sensor networks, Machine-to-Machine (M2M) communication, and Machine-Type Communication (MTC) are currently being researched to facilitate the connection of objects. In an IoT environment, intelligent IT services that create new value for human life by collecting and analyzing data generated from connected objects can be provided. Through the convergence and integration of existing IT technologies with various industries, IoT can be applied to fields such as smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart home appliances, and advanced medical services.

[0004] Accordingly, various attempts are being made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, Machine to Machine (M2M), and Machine Type Communication (MTC) are being implemented using 5G communication techniques such as beamforming, MIMO, and array antennas. The application of cloud RAN as a big data processing technology, as previously described, can also be considered an example of the convergence of 5G and IoT technologies. The problem to be solved

[0005] The disclosed embodiment provides a device and method that enable a reliable bundle transfer service when a bundle is to be transferred between security modules included in two electronic devices. means of solving the problem

[0006] In order to solve the problem described above, the present disclosure may have the following means of solution.

[0007] A method of a first security medium according to one aspect of the present invention may include: identifying a bundle to be transmitted to a second security medium; determining whether transmission of the bundle is permitted based on bundle movement setting information associated with the bundle; and transmitting the bundle to the second security medium based on the determination.

[0008] According to various embodiments, the method may further include the step of identifying whether to generate a bundle transfer code to be used for the transmission of the bundle; and the step of generating the bundle transfer code based on the identification.

[0009] According to various embodiments, the method may further include the step of transmitting the bundle transfer code to the second security medium.

[0010] According to various embodiments, the step of generating the bundle transfer code includes: when it is identified that the bundle transfer code will be generated, the step of generating the bundle transfer code, wherein the bundle transfer code may be a unique ID of a preset bundle or a new ID for identifying the bundle.

[0011] According to various embodiments, the bundle transfer setting information may include at least one of bundle transfer policy information or bundle transfer history information.

[0012] According to various embodiments, the bundle transfer policy information may include an indication indicating whether the transfer of the bundle between devices is allowed.

[0013] According to various embodiments, the bundle movement history information may include at least one of information regarding the date and time when the bundle was moved or information regarding the number of times the bundle was moved.

[0014] According to various embodiments, the step of updating the bundle movement setting information may be further included.

[0015] A first security medium according to another aspect of the present invention comprises a transceiver; and at least one processor connected to the transceiver, wherein the at least one processor: identifies a bundle to be transmitted to a second security medium, determines whether transmission of the bundle is permitted based on bundle transfer setting information associated with the bundle, and transmits the bundle to the second security medium based on the determination.

[0016] According to various embodiments, the at least one processor may: identify whether to generate a bundle transfer code to be used for the transmission of the bundle, and generate the bundle transfer code based on the identification.

[0017] According to various embodiments, the at least one processor may: transmit the bundle transfer code to the second security medium.

[0018] According to various embodiments, generating the bundle transfer code includes: generating the bundle transfer code when it is identified that the bundle transfer code will be generated, and the bundle transfer code may be a unique ID of a preset bundle or a new ID for identifying the bundle.

[0019] According to various embodiments, the bundle transfer setting information may include at least one of bundle transfer policy information or bundle transfer history information.

[0020] According to various embodiments, the bundle transfer policy information may include an indication indicating whether the transfer of the bundle between devices is allowed.

[0021] According to various embodiments, the bundle movement history information may include at least one of information regarding the date and time when the bundle was moved or information regarding the number of times the bundle was moved.

[0022] According to various embodiments, the at least one processor can: update the bundle movement setting information.

[0023] A method of a second security medium according to one aspect of the present invention may include: receiving a bundle transfer code to be used for transmitting a bundle from a first security medium; transmitting information about the second security medium to the first security medium; receiving first authentication information for authenticating the first security medium from the first security medium; verifying the first authentication information; transmitting second authentication information and the bundle transfer code to authenticate the second security medium to the first security medium based on the result of the verification; and receiving the bundle from the first security medium.

[0024] According to various embodiments, the step of receiving the bundle may further include the step of receiving a bundle transfer setting associated with the bundle.

[0025] A second security medium according to another aspect of the present invention comprises a transceiver; and at least one processor connected to the transceiver, wherein the at least one processor: receives a bundle transfer code to be used for transferring a bundle from a first security medium, transmits information about the second security medium to the first security medium, receives first authentication information for authenticating the first security medium from the first security medium, verifies the first authentication information, transmits second authentication information and the bundle transfer code for authenticating the second security medium to the first security medium based on the result of the verification, and receives the bundle from the first security medium.

[0026] According to various embodiments, receiving the bundle may further include receiving a bundle transfer setting associated with the bundle.

[0027] According to some embodiments of the present disclosure, an electronic device for transmitting a bundle may include the steps of: selecting a bundle to be transmitted by a user or external input; checking whether the selected bundle is transmittable through a 'bundle transfer setting'; transmitting the 'bundle transfer setting' to an electronic device for receiving the bundle; and updating the 'bundle transfer setting' if necessary.

[0028] Additionally, according to some embodiments of the present disclosure, an electronic device that intends to receive a bundle may include the step of receiving a 'bundle transfer setting' and, if necessary, the step of updating the 'bundle transfer setting'.

[0029] According to some embodiments of the present disclosure, an electronic device to transmit a bundle may include the steps of: selecting a bundle to transmit by a user or external input; providing a ‘bundle transfer code’ and binding it to the bundle to transmit; transmitting the ‘bundle transfer code’ to an electronic device to receive the bundle; and when a request for bundle transmission is made from the electronic device to receive the bundle, if the ‘bundle transfer code’ is enclosed, checking whether the ‘bundle transfer code’ is valid or identifying the bundle to transmit using the ‘bundle transfer code’.

[0030] Additionally, according to some embodiments of the present disclosure, an electronic device that wishes to receive a bundle may include the steps of receiving a 'bundle transfer code' and enclosing the 'bundle transfer code' when requesting a bundle from an electronic device that wishes to transmit a bundle.

[0031] According to some embodiments of the present disclosure, two electronic devices may undergo a certificate negotiation process to be described later to verify information that can authenticate each other, generate authentication information that can verify oneself and transmit it to the other electronic device, and verify the other electronic device by verifying the received authentication information.

[0032] According to some embodiments of the present disclosure, an electronic device that intends to transmit a bundle may transmit the bundle to an electronic device that intends to receive the bundle, and the electronic device that intends to receive the bundle may install the transmitted bundle. Effects of the invention

[0033] According to various embodiments of the present disclosure, a bundle installed in one device can be transferred and installed in another device in a safe and efficient manner. Brief explanation of the drawing

[0034] FIG. 1 shows a conceptual diagram of an SSP according to an embodiment of the present disclosure. FIG. 2 shows a conceptual diagram of the internal structure of an SSP according to an embodiment of the present disclosure. FIG. 3 is a drawing illustrating an example of a component within a terminal used by a terminal according to an embodiment of the present disclosure to download and install a bundle as an SSP. FIG. 4 is a diagram illustrating an example of a method in which two terminals interact with each other to transmit a bundle between two terminals according to an embodiment of the present disclosure. FIG. 5 is a diagram conceptually illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present disclosure. Figure 6 is a diagram illustrating the detailed procedure for preparing for bundle transmission among the procedures presented in Figure 5. Figure 7 is a diagram illustrating the detailed procedure for the procedure in which the transmission of bundles takes place among the procedures presented in Figure 5. Figure 8 is a diagram illustrating the detailed procedure for the procedure in which the transmission process is completed after the bundle is transmitted among the procedures presented in Figure 5. FIG. 9 is a drawing illustrating the configuration of a terminal according to some embodiments of the present disclosure. FIG. 10 is a flowchart illustrating a bundle transmission method of a first security medium according to an embodiment of the present disclosure. FIG. 11 is a flowchart illustrating a method for receiving a bundle of a second security medium according to an embodiment of the present disclosure. FIG. 12 is a diagram illustrating an example of a method in which two terminals interact to transmit a profile between two terminals according to an embodiment of the present disclosure. FIG. 13 is a diagram illustrating a procedure for transmitting a profile from one terminal to another terminal according to an embodiment of the present disclosure. FIG. 14 is a diagram illustrating a procedure in which a terminal requests approval from an RSP server for profile transmission while performing the procedure presented in FIG. 13. FIG. 15 is a diagram conceptually illustrating a procedure for transmitting a profile from one terminal to another terminal according to an embodiment of the present disclosure. Figure 16 is a diagram illustrating the detailed procedure for preparing for profile transmission among the procedures presented in Figure 15. FIG. 17 is a diagram illustrating the detailed procedure for mutual authentication between two terminals among the procedures presented in FIG. 15. FIG. 18 is a diagram illustrating the detailed procedure in which a profile is transmitted from one terminal to another terminal and the transmitted profile is installed, among the procedures presented in FIG. 15. Specific details for implementing the invention

[0035] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings.

[0036] In describing the embodiments, technical details that are well known in the technical field to which this disclosure belongs and are not directly related to this disclosure are omitted. This is intended to convey the essence of this disclosure more clearly without obscuring it by omitting unnecessary explanations.

[0037] For the same reason, some components in the attached drawings have been exaggerated, omitted, or schematically depicted. Additionally, the size of each component does not entirely reflect its actual dimensions. Identical or corresponding components in each drawing have been assigned the same reference numbers.

[0038] The advantages and features of the present disclosure and the methods for achieving them will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms. The embodiments provided are merely to make the present disclosure complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components.

[0039] At this time, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement the function in a specific way, the instructions stored in computer-available or computer-readable memory can also produce a manufactured item containing instruction means to perform the function described in the flow diagram block(s). Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a process executed by the computer can also provide steps for executing the functions described in the flowchart block(s).

[0040] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specified logical function(s). It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For instance, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may be executed in reverse order according to their corresponding functions.

[0041] In this embodiment, the term "part" refers to a software or hardware component, such as an FPGA or ASIC, and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or configured to operate one or more processors. Accordingly, as an example, the "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. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." Furthermore, the components and "parts" may be implemented to operate one or more CPUs within a device or secure multimedia card.

[0043] Meanwhile, the importance of security media is increasingly being emphasized in order to safely store security information and provide secure security services using the stored security information.

[0044] In particular, security media referred to as Secure Elements are embedded in various electronic devices (smartphones, tablets, wearable devices, automobiles, IoT devices, etc.) due to their high level of security, and are utilized in various services including mobile network access, payment, and user authentication. Secure Elements can have various form factors, such as UICC (Universal Integrated Circuit Card), eSE (Embedded Secure Element), and SD Card.

[0045] In particular, the Smart Secure Platform (SSP), which integrates UICC and eSE, is gaining attention as a next-generation security medium due to its many advantages, such as efficiency in implementation space, enhanced computing power, and expanded storage space. Furthermore, as the SSP is a suitable security medium for implementing the security functions required by 5G and IoT terminals, its importance is increasingly being emphasized.

[0046] Various applications are loaded onto the SSP in the form of bundles and run. Therefore, the importance of methods for securely loading bundles onto the SSP and the devices involved is being emphasized. Methods for loading bundles onto an SSP can be broadly divided into receiving bundles from an external server and receiving bundles from other electronic devices.

[0047] In particular, the method of receiving bundles from other electronic devices—that is, the method of transferring bundles from one security medium to another—is attracting attention as a next-generation bundle transfer technology due to the advantages of being able to transfer user information stored or configured on one security medium to a new security medium and use it as is, as well as the advantage that assistance from an external entity may not be required during the bundle transfer process.

[0048] Therefore, there is a need for a method to safely move bundles from one secure medium to another, and the necessity of developing methods and devices for this purpose is being highlighted.

[0049] Various embodiments for this purpose are described below with reference to the drawings. Meanwhile, although the embodiments described below use an SSP as an example of a security medium, the scope of the present invention is not limited to the SSP. For example, it is obvious to those skilled in the art that the various embodiments described below can be applied substantially identically or similarly to other security media that perform substantially the same or similar functions as the SSP.

[0051] Specific terms used in the following description are provided to aid in understanding the present disclosure, and the use of such specific terms may be modified in other forms without departing from the technical spirit of the present disclosure.

[0053] "SE (Secure Element)" refers to a security module composed of a single chip capable of storing security information (e.g., mobile network access keys, user identity verification information such as ID cards / passports, credit card information, encryption keys, etc.) and operating a control module that utilizes the stored security information (e.g., network access control module such as USIM, encryption module, key generation module, etc.). SE can be used in various electronic devices (e.g., smartphones, tablets, wearable devices, automobiles, IoT devices, etc.) and can provide security services (e.g., mobile network access, payment, user authentication, etc.) through the security information and control module.

[0054] SE can be divided into UICC (Universal Integrated Circuit Card), eSE (Embedded Secure Element), and SSP (Smart Secure Platform), which is a form in which UICC and eSE are integrated. Depending on the form in which it is connected to or installed in an electronic device, it can be subdivided into removable, embedded, and integrated types that are integrated into a specific component or SoC (system on chip).

[0056] A "UICC (Universal Integrated Circuit Card)" is a smart card inserted into mobile communication terminals and is also referred to as a UICC card. A UICC may include a connection control module for connecting to a mobile carrier's network. Examples of connection control modules include USIM (Universal Subscriber Identity Module), SIM (Subscriber Identity Module), and ISIM (IP Multimedia Service Identity Module). A UICC containing a USIM is commonly referred to as a USIM card. Similarly, a UICC containing a SIM module is commonly referred to as a SIM card. Meanwhile, the SIM module may be installed during the manufacturing of the UICC, or the SIM module of the mobile communication service the user wishes to use can be downloaded to the UICC card at a time of their choice. A UICC card can also download and install multiple SIM modules, and select at least one of them for use. Such a UICC card may or may not be fixed to the terminal. A UICC that is fixed to a terminal is called an eUICC (embedded UICC), and a UICC embedded in a System-On-Chip (SoC) that includes a communication processor, an application processor, or a single processor structure in which these two processors are integrated is called an iUICC (Integrated UICC). Typically, eUICC and iUICC refer to UICC cards that are fixed to a terminal and allow a SIM module to be downloaded and selected remotely. In this disclosure, a UICC card that allows a SIM module to be downloaded and selected remotely is collectively referred to as an eUICC or an iUICC.In other words, among UICC cards that allow for remote SIM module download and selection, those that are fixed to the terminal or not are collectively referred to as eUICC or iUICC.

[0057] In this disclosure, the term UICC may be used interchangeably with SIM, and the term eUICC may be used interchangeably with eSIM.

[0059] The "eUICC identifier (eUICC ID)" may be a unique identifier of the eUICC embedded in the terminal and may be referred to as an EID. Additionally, if a provisioning profile is pre-loaded on the eUICC, the eUICC identifier (eUICC ID) may be the identifier of the provisioning profile (Provisioning Profile's Profile ID). Furthermore, in one embodiment of the present disclosure, if the terminal and the eUICC chip are not separated, the eUICC identifier (eUICC ID) may be the terminal ID. Additionally, the eUICC identifier (eUICC ID) may refer to a specific secure domain of the eUICC chip.

[0061] "eSE (Embedded Secure Element)" refers to a fixed SE used by being fixed to an electronic device. Typically, eSEs are manufactured exclusively for a manufacturer at the request of the terminal manufacturer and may be manufactured to include an operating system and a framework. eSEs can be used for various security service purposes, such as electronic wallets, ticketing, electronic passports, and digital keys, by remotely downloading and installing a service control module in the form of an applet. In this disclosure, a single-chip type SE attached to an electronic device capable of remotely downloading and installing a service control module is collectively referred to as an eSE.

[0063] A "Smart Secure Platform (SSP)" is capable of integrating and supporting the functions of UICC and eSE on a single chip, and can be classified into removable (rSSP), embedded (eSSP), and integrated (iSSP) types embedded in an SoC. An SSP may include a primary platform (PP) and at least one secondary platform bundle (SPB) operating on the PP; the primary platform may include at least one of a hardware platform and a low-level operating system (LLOS); and the secondary platform bundle may include at least one of a high-level operating system (HLOS) and an application running on the HLOS. The secondary platform bundle is also referred to as an SPB or a bundle. The bundle can access resources such as the PP's central processing unit and memory through the Primary Platform Interface (PPI) provided by the PP, and thereby run on the PP. The bundle may be equipped with communication applications such as SIM (Subscriber Identification Module), USIM (Universal SIM), and ISIM (IP Multimedia SIM), and may also be equipped with various application applications such as electronic wallets, ticketing, electronic passports, and digital keys. In this disclosure, the SSP may also be referred to as a smart security medium.

[0064] Depending on the bundles downloaded and installed, the SSP may be used for the UICC or eSE purposes described above, and multiple bundles can be installed on a single SSP and operated simultaneously to combine the uses of UICC and eSE. That is, when a bundle containing a profile is in operation, the SSP may be used as a UICC to connect to a mobile carrier's network. The UICC bundle can operate by remotely downloading at least one profile into the bundle and selecting it, such as the eUICC or iUICC mentioned above. Additionally, when a bundle containing a service control module equipped with an application capable of providing services such as electronic wallets, ticketing, electronic passports, or digital keys on the SSP is in operation, the SSP may be used for the eSE purposes mentioned above. Multiple service control modules may be installed and operated as a single bundle, or they may be installed and operated as independent bundles.

[0065] The SSP can download and install a bundle from an external bundle management server (Secondary Platform Bundle Manager, SPB Manager) using OTA (Over The Air) technology, or it can receive and install a bundle from another terminal. The method of installing a downloaded or received bundle in this disclosure can be equally applied to a removable SSP (rSSP) that can be inserted into and removed from a terminal, a fixed SSP (eSSP) installed in a terminal, and an integrated SSP (iSSP) included within an SoC installed in a terminal.

[0067] The "SSP identifier (SSP ID)" may be a unique identifier of the SSP embedded in the terminal and may be referred to as sspID. Additionally, as in the embodiments of the present disclosure, if the terminal and the SSP chip are not separated, it may be a terminal ID. It may also refer to a specific bundle identifier (SPB ID) within the SSP. More specifically, it may refer to a bundle identifier of a management bundle or loader (SPBL, Secondary Platform Bundle Loader) that manages the installation, activation, deactivation, and deletion of other bundles within the SSP. The SSP may have multiple SSP identifiers, and the multiple SSP identifiers may be values ​​derived from a single unique SSP identifier.

[0069] "SPB (Secondary Platform Bundle)" refers to a bundle that runs on the Primary Platform (PP) of an SSP using the resources of the PP. For example, a UICC bundle may refer to a package of applications, file systems, authentication key values, etc., stored within an existing UICC, and the operating system (HLOS) on which they operate, in the form of software. In this disclosure, an SPB may be referred to as a bundle.

[0071] In the present disclosure, the "state" of the bundle may be as follows.

[0072] [Enable]

[0073] In the present disclosure, the operation of a terminal or an external server enabling a bundle may mean an operation of changing the state of the corresponding SPB to an enabled state so that the terminal can receive the services provided by the bundle (e.g., communication services, credit card payment services, user authentication services, etc. through a telecommunications carrier). A bundle in an enabled state may be referred to as an "enabled bundle." A bundle in an enabled state may be stored in an encrypted state in storage space inside or outside the SSP.

[0074] [Operating Status (Active)]

[0075] In the present disclosure, an activated bundle may be changed to an active state based on external inputs (e.g., user input, push, request from an application within the terminal, authentication request from a carrier, PP management message, etc.) or internal operations (e.g., timer, polling). An active bundle may mean that it is loaded from storage space inside or outside the SSP into the active memory inside the SSP, processes security information using a security control unit (Secure CPU) inside the SSP, and provides security services to the terminal.

[0076] [Disabled]

[0077] In the present disclosure, the operation of a terminal or an external server disabling a bundle may mean 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 disabled state may be referred to as a "disabled Bundle." A bundle in a disabled state may be stored in an encrypted state in storage space inside or outside the SSP.

[0078] [Deleted]

[0079] In the present disclosure, the operation of a terminal or external server deleting a bundle may mean an operation of changing the state of the bundle to a deleted state or deleting the bundle and related data thereof so that the terminal or external server can no longer run, activate, or deactivate the bundle. A bundle in a deleted state may be referred to as a "deleted bundle."

[0081] "Bundle Image" (or "Image") may be used interchangeably with "bundle" or as a term representing a specific data object of a bundle, and may be named Bundle TLV (Tag, Length, Value) or Bundle Image TLV. If the Bundle Image is encrypted using encryption parameters, it may be named Protected Bundle Image (PBI) or Protected Bundle Image TLV (PBI TLV). If the Bundle Image is encrypted using encryption parameters that can be decrypted only by a specific SSP, it may be named Bound Bundle Image (BBI) or Bound Bundle Image TLV (BBI TLV). A Bundle Image TLV may be a data set representing information constituting the bundle in the TLV(Tag, Length, Value) format.

[0083] "Bundle separator" may be referred to as an argument matching the Bundle Identifier (SPB ID), Bundle Family Identifier (SPB Family ID), Bundle Family Custodian Object ID (SPB Family Custodian Object ID), Bundle Matching ID, and Event Identifier (Event ID). The Bundle Identifier (SPB ID) may represent a unique identifier for each bundle. The Bundle Family Identifier may represent an identifier distinguishing the type of bundle (e.g., a telecom bundle for mobile carrier network access). In this disclosure, the Bundle Family Identifier may be referred to as spbFamilyId. The Bundle Family Custodian Object ID may represent an identifier distinguishing the entity managing the Bundle Family Identifier (e.g., a telecommunications carrier, a terminal manufacturer, a specific organization, etc.). In this disclosure, the Bundle Family Custodian Object ID may be referred to as Oid. The Bundle separator may be used as a value capable of indexing bundles on a bundle management server or a terminal.

[0085] "Bundle metadata" is a term representing a set of information that can refer to or describe a bundle. Bundle metadata may include the bundle identifier described above. Additionally, bundle metadata may include further information regarding the attributes, characteristics, or settings of the bundle. Bundle metadata may be expressed as "metadata."

[0087] "Profile" may refer to data objects such as applications, file systems, and authentication key values ​​stored within the UICC.

[0088] In this disclosure, "profile package" may refer to the contents of a "profile" packaged in a software form that can be installed within a UICC. A "profile package" may be named a Profile Package TLV. If the profile package is encrypted using encryption parameters, it may be named a Protected Profile Package (PPP) or a Protected Profile Package TLV (PPP TLV). If the profile package is encrypted using encryption parameters that can be decrypted only by a specific eUICC, it may be named a Bound Profile Package (BPP) or a Bound Profile Package TLV (BPP TLV). A Profile Package TLV may be a data set representing information constituting a profile in the TLV (Tag, Length, Value) format. In this disclosure, "profile image" may refer to binary data in which the profile package is installed within a UICC. A "profile image" may be named a Profile TLV or a Profile Image TLV. If a profile image is encrypted using encryption parameters, it may be named a Protected Profile Image (PPI) or a Protected Profile Image TLV (PPI TLV). If a profile image is encrypted using encryption parameters that can be decrypted only by a specific eUICC, it may be named a Bound Profile Image (BPI) or a Bound Profile Image TLV (BPI TLV). A profile image TLV may be a data set representing information constituting a profile in the TLV (Tag, Length, Value) format. In this disclosure, the "state" of a profile may be as follows.

[0089] [Enable]

[0090] In the present disclosure, the operation of enabling a profile by a terminal may mean an operation of changing the state of the profile to an enabled state so that the terminal can receive communication services through the telecommunications carrier that provided the profile. A profile in an enabled state may be expressed as an "enabled profile."

[0091] [Disable]

[0092] In the present disclosure, the operation of a terminal disabling a profile may mean an operation of changing the state of the profile to a disabled state so that the terminal cannot receive communication services through the telecommunications carrier that provided the profile. A profile in a disabled state may be referred to as a "disabled profile."

[0093] [Delete]

[0094] In the present disclosure, the operation of a terminal deleting a profile may mean an operation of changing the status of the profile to a deleted state so that the terminal can no longer activate or deactivate the profile. A profile in a deleted state may be referred to as a "deleted profile."

[0095] In the present disclosure, the operation of enabling, disabling, or deleting a profile by a terminal may mean an operation of not immediately changing the state of each profile to enabled, disabled, or deleted, but first marking each profile as to be enabled, disabled, or deleted, and then changing each profile to enabled, disabled, or deleted after the terminal or the terminal’s UICC performs a specific operation (e.g., the execution of a refresh or reset command). The action of marking a specific profile as a scheduled state (i.e., to be enabled, to be disabled, or to be deleted) is not necessarily limited to marking one scheduled state for a single profile; it is also possible to mark one or more profiles as having the same or different scheduled states, to mark one profile as having one or more scheduled states, or to mark one or more profiles as having one or more scheduled states.

[0096] Additionally, if the terminal displays one or more scheduled states for any profile, the two scheduled state indications may be combined into one. For example, if any profile is displayed as "to be disabled" and "to be deleted," the profile may be displayed as a combined "to be disabled and deleted" state.

[0097] Additionally, the operation of the terminal displaying a scheduled state for one or more profiles may be performed sequentially or simultaneously. Additionally, the operation of the terminal displaying a scheduled state for one or more profiles and subsequently changing the state of the actual profile may be performed sequentially or simultaneously.

[0099] "Profile Separator" may be referred to as an argument matching a Profile Identifier (Profile ID), ICCID (Integrated Circuit Card ID), Matching ID, Event Identifier (Event ID), Activation Code, Activation Code Token, Command Code, Command Code Token, Signed Command Code, Unsigned Command Code, ISD-P, or Profile Domain (PD). The Profile Identifier (Profile ID) may represent a unique identifier for each profile. The Profile Separator may further include the address of a profile provider server (SM-DP+) capable of indexing profiles. Additionally, the Profile Separator may further include the signature of the profile provider server (SM-DP+).

[0101] A "Bundle Management Server" may include functions for creating a bundle, encrypting a created bundle, creating a bundle remote management command, or encrypting a created bundle remote management command at the request of a Service Provider or another Bundle Management Server. A Bundle Management Server providing the above functions may be represented as at least one of 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), Manager Bundle Server, Managing SM-DP+ (Managing Subscription Manager Data Preparation plus), Bundle Encryption Server, Bundle Creation Server, Bundle Provisioner (BP), Bundle Provider, and BPC holder (Bundle Provisioning Credentials holder).

[0102] In the present disclosure, the bundle management server may perform the role of managing the configuration of keys and certificates for downloading, installing, or updating bundles from an SSP and for remotely managing the status of bundles. The bundle management server providing the above functions may be represented as at least one of 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), and EM (eUICC Manager).

[0103] In the present disclosure, the activation intermediary server may receive an event registration request (Register Event Request, Event Register Request) from one or more bundle management servers or activation intermediary servers. Additionally, one or more activation intermediary servers may be used in combination, in which case the first activation intermediary server may receive an event registration request from not only the bundle management server but also the second activation intermediary server. In the present disclosure, the function of the activation intermediary server may be integrated into the bundle management server. The activation intermediary server providing the above function may be represented as at least one of 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 Activation Intermediary Server (Root SM-DS), and Alternative Activation Intermediary Server (Alternative SM-DS).

[0104] In this disclosure, the term "bundle management server" may collectively refer to a combination of functions that generate, encrypt, and transmit bundles or bundle remote management commands, and functions that manage SSP configuration and installed bundles. It may also collectively refer to a combination of functions that include the activation brokerage server. Accordingly, in the various embodiments of this disclosure below, the operation of the bundle management server and the activation brokerage server may be performed on a single bundle management server. Alternatively, each function may be divided and performed on multiple separate bundle management servers. Furthermore, in the specification of this disclosure, the bundle management server or the activation brokerage server may be referred to as a bundle server. The bundle server may be one of the bundle management server and the activation brokerage server, or it may be a device that includes both the bundle management server and the activation brokerage server.

[0106] “RSP Server (Remote SIM Provisioning Server)” may be used as a designation for the profile provision server and / or profile management server and / or activation intermediary server described below. The RSP Server may be represented as SM-XX (Subscription Manager XX).

[0107] In the present disclosure, the “profile providing server” may include functions for creating a profile, encrypting a created profile, creating a profile remote management command, or encrypting a created profile remote management command. The profile providing server may be represented as SM-DP (Subscription Manager Data Preparation), SM-DP+ (Subscription Manager Data Preparation plus), off-card entity of Profile Domain, profile encryption server, profile creation server, profile provider (Profile Provisioner, PP), profile provider (Profile Provider), and PPC holder (Profile Provisioning Credentials holder).

[0108] In the present disclosure, the “profile management server” may include a function for managing profiles. The profile management server may be represented as 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), EM (eUICC Manager), PP (Profile Manager), etc.

[0109] In the present disclosure, the profile providing server may refer to a combination of the functions of a profile management server. Accordingly, in various embodiments of the present disclosure, the operation of the profile providing server may be performed on the profile management server. Likewise, the operation of the profile management server or SM-SR may be performed on the profile providing server.

[0110] In the present disclosure, the "activation intermediary server" may be represented as SM-DS (Subscription Manager Discovery Service), DS (Discovery Service), Root activation intermediary server (Root SM-DS), and Alternative activation intermediary server (Alternative SM-DS). An activation intermediary server may receive an Event Register Request (Event Register Request) from one or more profile providing servers or activation intermediary servers. Additionally, one or more activation intermediary servers may be used in combination, in which case the first activation intermediary server may receive an Event Register Request from a second activation intermediary server as well as a profile providing server.

[0112] "Service Provider" may refer to a business entity that requests the creation of a bundle by issuing requirements to a bundle management server and provides services to terminals through said bundle. For example, it may refer to a mobile operator that provides network access services through a bundle equipped with a communication application, and may collectively refer to the mobile operator's Business Supporting System (BSS), Operational Supporting System (OSS), Point of Sale Terminal (POS) terminal, and other IT systems. Furthermore, in this disclosure, "Service Provider" is not limited to representing a single specific business entity but may also be used as a term referring to a group or association or consortium of one or more business entities, or an agency representing said group or consortium. Additionally, in the present disclosure, a service provider may be referred to as an operator (or OP or Op.), a bundle owner (BO), an image owner (IO), etc., and each service provider may have at least one name and / or unique identifier (Object Identifier, OID) set or assigned. If a service provider refers to a group or association or agency of one or more business entities, the name or unique identifier of any group or association or agency may be a name or unique identifier shared by all business entities belonging to said group or association or all business entities cooperating with said agency.

[0114] "Mobile operator" may refer to a business entity that provides telecommunication services to terminals, and may collectively refer to the mobile operator's business supporting system (BSS), operational supporting system (OSS), point of sale terminal, and other IT systems. Furthermore, in this disclosure, the mobile operator is not limited to representing a single specific business entity providing telecommunication services, but may also be used as a term referring to a group or association or consortium of one or more business entities, or an agent representing said group or consortium. Additionally, in this disclosure, the mobile operator may be named an operator (or OP or Op.), a mobile network operator (MNO), a mobile virtual network operator (MVNO), a service provider (or SP), a profile owner (PO), etc., and each mobile operator may set or be assigned at least one name and / or unique identifier (object identifier: OID). If a telecommunications business operator refers to a group or association of one or more business entities or an agency, the name or unique identifier of any group or association or agency may be a name or unique identifier shared by all business entities belonging to said group or association or all business entities cooperating with said agency.

[0116] The term "Subscriber" can be used to refer to a Service Provider that owns the terminal or an End User that owns the terminal. Generally, the former can be referred to as an M2M Device, and the latter as a Consumer Device. In the case of an M2M Device, there may be an End User who does not own the terminal but uses it after receiving it from the Service Provider via transfer or lease; in this case, the End User may be different from or the same as the Service Provider.

[0118] "Subscriber intent" can be used as a general term for a subscriber's intention to manage bundles locally or remotely. Additionally, in the case of local management, subscriber intent may refer to end-user intent, while in the case of remote management, subscriber intent may refer to service-provider intent.

[0120] "End User consent" may be used as a term to refer to whether the user consents to the performance of local or remote management.

[0122] The term "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 terms. Various embodiments of the terminal may include cellular telephones, smartphones with wireless communication capabilities, personal digital assistants (PDAs) with wireless communication capabilities, wireless modems, portable computers with wireless communication capabilities, imaging devices such as digital cameras with wireless communication capabilities, gaming devices with wireless communication capabilities, home appliances for music storage and playback with wireless communication capabilities, home appliances capable of wireless internet access and browsing, as well as portable units or terminals integrating combinations of such functions. Additionally, the terminal may include, but is not limited to, machine-to-machine (M2M) terminals and machine-type communication (MTC) terminals / devices. In the present disclosure, the terminal may also be referred to as an electronic device.

[0123] In the present disclosure, an electronic device may have an embedded SSP that can be installed by downloading a bundle. If the SSP is not embedded in the electronic device, the SSP, which is physically separated from the electronic device, may be inserted into the electronic device and connected to the electronic device. For example, the SSP may be inserted into the electronic device in the form of a card. The electronic device may include a terminal, wherein the terminal may be a terminal that includes an SSP that can be installed by downloading a bundle. The SSP may not only be embedded in the terminal, but if the terminal and the SSP are separated, the SSP may be inserted into the terminal and connected to the terminal.

[0124] In the present disclosure, an electronic device may have a UICC embedded therein that can be installed by downloading a profile. If the UICC is not embedded in the electronic device, a UICC that is physically separated from the electronic device may be inserted into the electronic device and connected to the electronic device. For example, the UICC may be inserted into the electronic device in the form of a card. The electronic device may include a terminal, wherein the terminal may be a terminal that includes a UICC that can be installed by downloading a profile. The UICC may not only be embedded in the terminal, but if the terminal and the UICC are separated, the UICC may be inserted into the terminal and connected to the terminal. A UICC that can be installed by downloading a profile may be referred to, for example, as an eUICC.

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

[0128] "Loader (SPBL, Secondary Platform Bundle Loader)" may refer to a management bundle that manages the installation, activation, deactivation, and deletion of other bundles in an SSP. An LBA of a terminal or a remote server may install, activate, deactivate, or delete a specific bundle through the loader. In this disclosure, the operation of the loader may also be described as the operation of an SSP including the loader.

[0130] “LPA (Local Profile Assistant)” may refer to software or an application installed within a terminal or electronic device to control a UICC or eUICC in the terminal or electronic device.

[0132] "Event" may be used for the following purposes in the present disclosure.

[0133] [When used in conjunction with bundles]

[0134] "Event" may be a collective term for Bundle Download, Remote Bundle Management, or other management / processing commands for Bundles or SSPs. An Event may be named a Remote Bundle Provisioning Operation (or RBP Operation) or an Event Record, and each Event may be referred to as data containing at least one of the corresponding Event Identifier (Event ID, EventID) or Matching Identifier (Matching ID, MatchingID), and the address (FQDN, IP Address, or URL) or server identifier of the Bundle Management Server or Activation Brokerage Server where the event is stored. "Bundle Download" may be used interchangeably with "Bundle Installation." Additionally, Event Type can be used as a term to indicate whether a specific event is a bundle download, remote bundle management (e.g., deletion, activation, deactivation, replacement, update, etc.), or other bundle or SSP management / processing commands, and may be named Operation Type (or OperationType), Operation Class (or OperationClass), Event Request Type, Event Class, Event Request Class, etc.

[0136] "Local Bundle Management (LBM)" may be referred to as Bundle Local Management, Local Management, Local Management Command, Local Command, Local Bundle Management Package, Bundle Local Management Package, Local Management Package, Local Management Command Package, or Local Command Package. LBM may be used to install any bundle, change the status (Enabled, Disabled, Deleted) of a specific bundle, or update the contents of a specific bundle (e.g., Bundle Nickname, Bundle Metadata, etc.) through software installed on the terminal. LBM may include one or more Local Management Commands, in which case the bundles targeted by each Local Management Command may be the same or different for each Local Management Command.

[0138] "Remote Bundle Management (RBM)" may be named Bundle Remote Management, Remote Management, Remote Management Command, Remote Command, Remote Bundle Management Package, Bundle Remote Management Package, Remote Management Package, Remote Management Command Package, or Remote Command Package. An RBM may be used to install any bundle, change the status (Enabled, Disabled, Deleted) of a specific bundle, or update the contents of a specific bundle (e.g., Bundle Nickname or Bundle Metadata). An RBM may include 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.

[0140] "Target Bundle" may be used as a term to refer to a bundle that is the target of a local or remote management command.

[0142] "Bundle Rule" can be used to refer to information that a terminal must verify when performing local or remote management on a target bundle. Additionally, "Bundle Rule" may be used interchangeably with terms such as "Bundle Policy," "Rule," and "Policy."

[0144] [When used in relation to a profile]

[0145] "Event" may be a collective term for Profile Download, Remote Profile Management, or other management / processing commands of a profile or eUICC. An Event may be named a Remote SIM Provisioning Operation (or RSP Operation) or an Event Record, and each Event may be referred to as data comprising at least one of the following: a corresponding Event Identifier (Event ID, EventID) or Matching Identifier (Matching ID, MatchingID), the address (FQDN, IP Address, or URL) of the Profile Provider Server (SM-DP+) or Activation Broker Server (SM-DS) where the event is stored, the signature of the Profile Provider Server (SM-DP+) or Activation Broker Server (SM-DS), and the digital certificate of the Profile Provider Server (SM-DP+) or Activation Broker Server (SM-DS).

[0146] Data corresponding to an Event may be referred to as a "Command Code." Part or all of the procedure utilizing the Command Code may be referred to as a "Command Code Processing Procedure," a "Command Code Procedure," or an "LPA API (Local Profile Assistant Application Programming Interface)." Profile Download may be used interchangeably with Profile Installation.

[0147] Additionally, "Event Type" may be used as a term indicating whether a specific event is a profile download, remote profile management (e.g., deletion, activation, deactivation, replacement, update, etc.), or other profile or eUICC management / processing commands, and may be named as Operation Type (or OperationType), Operation Class (or OperationClass), Event Request Type, Event Class, Event Request Class, etc. For any event identifier (EventID or MatchingID), the path through which the terminal obtained the event identifier (EventID or MatchingID) or the intended use (EventID Source or MatchingID Source) may be specified.

[0149] "Local Profile Management (LPM)" may be named Profile Local Management, Local Management, Local Management Command, Local Command, Local Profile Management Package, Profile Local Management Package, Local Management Package, Local Management Command Package, or Local Command Package. LPM may be used to change the status (Enabled, Disabled, Deleted) of a specific profile or to update the contents of a specific profile (e.g., Profile Nickname, Profile Metadata, etc.) through software installed on the terminal. LPM may include one or more local management commands, in which case the profiles targeted by each local management command may be the same or different for each local management command.

[0151] "Remote Profile Management (RPM)" may be referred to as Profile Remote Management, Remote Management, Remote Management Command, Remote Command, Remote Profile Management Package, Profile Remote Management Package, Remote Management Package, Remote Management Command Package, or Remote Command Package. An RPM may be used to change the status (Enabled, Disabled, Deleted) of a specific profile or to update the contents of a specific profile (e.g., Profile Nickname or Profile Metadata). An RPM may include one or more remote management commands; in this case, the profiles targeted by each remote management command may be the same or different for each command.

[0153] A "Certificate" or "Digital Certificate" may refer to a digital certificate used for asymmetric key-based mutual authentication consisting of a pair of a public key (PK) and a secret key (SK). Each certificate may include one or more public keys (PKs), a public key identifier (PKID) corresponding to each public key, a certificate issuer ID (Certificate Issuer ID) of the certificate issuer (CI) that issued the certificate, and a digital signature. Additionally, the certificate issuer may be referred to as a certification issuer, certificate authority (CA), certification authority, etc. In the present disclosure, Public Key (PK) and Public Key ID (PKID) may be used interchangeably with the same meaning to refer to a specific public key or a certificate containing the said public key, or a part of a specific public key or a part of a certificate containing the said public key, or a result of an operation (e.g., hash) of a specific public key or a result of an operation (e.g., hash) of a certificate containing the said public key, or a result of an operation (e.g., hash) of a part of a specific public key or a result of an operation (e.g., hash) of a part of a certificate containing the said public key, or a storage space where data is stored.

[0155] A "Certificate Chain" or "Certificate Hierarchy" can represent the correlation between certificates when certificates issued by a "Certificate Issuer" (primary certificates) are used to issue other certificates (secondary certificates), or when secondary certificates are used to issue tertiary or higher certificates in a linked manner. In this case, the CI certificate used for the initial certificate issuance may be named the Root of Certificate, top-level certificate, Root CI, Root CI Certificate, Root CA, Root CA Certificate, etc.

[0157] Furthermore, in describing the present disclosure, if it is determined that a detailed description of related known functions or configurations could unnecessarily obscure the essence of the present disclosure, such detailed description is omitted.

[0159] Hereinafter, various embodiments regarding a method and device for moving and installing bundles between terminals are described.

[0161] FIG. 1 shows a conceptual diagram of an SSP according to an embodiment of the present disclosure.

[0162] According to various embodiments, as in the example of FIG. 1, the terminal (110) may include an SSP (120). For example, the SSP (120) may be 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 that integrates both of these processors. As another example, the SSP (120) may be detachable (122) in the form of an independent chip that is not integrated into the SoC, or it may be embedded (124) that is pre-embedded in the terminal (110).

[0163] According to various embodiments, the SSP (120) included in the terminal may include at least one of one or more telecom bundles, one or more payment bundles, or one or more electronic identification bundles. For example, as shown in FIG. 1, when the SSP (120) includes a plurality of telecom bundles (140, 150), the terminal (110) may use a mobile communication network by operating the plurality of telecom bundles (140, 150) simultaneously or in time-sharing mode according to the settings. Additionally, when the SSP (120) includes a payment bundle (170) and an electronic identification bundle (180), the terminal (110) may 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 may use the electronic identification bundle (180) to authenticate the identity of the terminal owner.

[0165] FIG. 2 shows a conceptual diagram of the internal structure of a Smart Secure Platform (SSP) according to an embodiment of the present disclosure.

[0166] According to various embodiments, as in the example of FIG. 2, the SSP (210) may include one primary platform (PP) (220) and at least one secondary platform bundle (SPB) (230, 240) operating on it.

[0167] According to various embodiments, the primary platform (220) may include hardware (not disclosed) and at least one low-level operating system (LLOS) (222).

[0168] According to various embodiments, a secondary platform bundle (230) may include a High-level Operating System (HLOS) (232) and at least one application (234) running on it.

[0169] According to various embodiments, each secondary platform bundle (230, 240) can access resources such as a central processing unit and memory of the primary platform (220) using the Primary Platform Interface (PPI) (250) and run on the SSP (210) through this.

[0171] FIG. 3 is a drawing illustrating an example of an internal component of a terminal for a terminal to download and install a bundle as an SSP according to an embodiment of the present disclosure.

[0172] According to various embodiments, as in the example of FIG. 3, the terminal (310) may include an SSP (330) and / or an LBA (312) for controlling the SSP (330). For example, the terminal (310) may be a terminal equipped with an SSP (330) and an LBA (312) for controlling the SSP (330). For example, the SSP (330) may be built into the terminal (310) or be detachable.

[0173] According to various embodiments, the SSP (330) may include at least one of a primary platform (331), a secondary platform bundle loader (SPBL) (333), and one or more secondary platform bundles (335, 337, or 339).

[0174] According to various embodiments, the secondary platform bundle (335, 337, or 339) is not installed inside the SSP (330) at the time of terminal shipment, but can be downloaded and installed remotely after shipment.

[0175] According to various embodiments, as in the example of FIG. 3, each bundle may have a different bundle family identifier and / or bundle family manager identifier (341, 342, or 343). These bundle family identifiers and bundle family manager identifiers may be used as information necessary for downloading and installing bundles. That is, the SSP (330) or SPBL (333) may allow or deny the download and installation of a specific bundle based on the bundle family identifier and bundle family manager identifier.

[0177] FIG. 4 is a diagram illustrating an example of a method in which two terminals interact with each other to transmit a bundle between two terminals according to an embodiment of the present disclosure.

[0178] According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 4, the first terminal (400) may include an LBA (410) and an SSP (420), and the second terminal (450) may include an LBA (460) and an SSP (470).

[0179] According to various embodiments, a user may send a command to a terminal or receive information to be provided to the user from the terminal. For example, as in operations 4010 to 4060, a first / second user (440, 490) may send a command to an LBA (410, 460) of a first / second terminal (400, 450) or receive information to be provided to the user from the LBA (410, 460).

[0180] According to various embodiments, the above operation may include a process of a user selecting a bundle to be transmitted. Additionally, the above operation may further include a process of verifying information about a bundle to be received by the user. Additionally, the above operation may further include an operation of approving whether to transmit the bundle to be transmitted by the user. Additionally, the above operation may further include an operation of approving whether to transmit the bundle to be received by the user. The operations of selection and approval described above may not all be performed as independent operations, or one or more operations may be selected and performed independently of each other.

[0181] Additionally, in operations 4020 to 4070, the LBA (410, 460) can issue commands to the SSP (420, 470) or transmit and receive data with the SSP (420, 470).

[0182] According to one example, in the above operation, the LBA can receive the aforementioned user command and transmit this command to the SSP. In the above operation, if the LBA receives the user command and transmits this command to the SSP, the LBA can receive the result transmitted by the SSP as a result.

[0183] According to another example, in the above operation, the LBA can transmit commands or data received from another terminal or an external server to the SSP. In the above operation, if the LBA transmits commands or data received from another terminal or an external server to the SSP, the LBA can receive the result transmitted by the SSP as a result.

[0184] According to various embodiments, in the above operation, the LBA may define new commands and data based on a user's command or commands and data received from another terminal or external server, and transmit them to the SSP. In the above operation, when the LBA defines new commands and data based on a user's command or commands and data received from another terminal or external server and transmits them to the SSP, the LBA may receive the result transmitted by the SSP as a result.

[0185] According to various embodiments, in the above operation, the LBA and SSP can transmit and receive data to and from each other and install bundles.

[0186] According to various embodiments, in the 4050 operation, two LBAs (410, 460) may be connected to each other to issue commands to one another or to transmit and receive data with one another. At this time, the connection of 4050 may be a direct device-to-device connection between terminals, or, although not illustrated, an indirect device-to-device connection in which an external entity (e.g., an external server) is connected between the connections of the two LBAs.

[0187] A more detailed description of the connection method between the two LBAs described above will be referenced to the drawings described below.

[0188] According to various embodiments, in operations 4030 to 4080, the SSP (420, 470) can generate, process, or verify necessary data within the SSP.

[0189] According to various embodiments, in the above operation, the SSP may check or update the bundle move settings. Additionally, in the above operation, the SSP may generate and utilize bundle move code. The operation related to the bundle move settings and the operation related to the bundle move code described above are independent functions, and neither function may be executed, either one of the two functions may be executed, or both functions may be executed. Even when both functions are executed, the two functions may be performed as completely independent functions.

[0190] For more detailed methods of checking or updating the bundle transfer settings described above, and for more detailed methods of generating and utilizing bundle transfer codes, please refer to the drawings described below.

[0191] According to various embodiments, in the above operation, the SSP may generate its own SSP information or verify SSP information received from the counterpart terminal. Additionally, in the above operation, the SSP may generate authentication data capable of verifying itself or verify authentication data received from the counterpart terminal.

[0192] According to various embodiments, in the above operation, the SSP can generate a bundle.

[0193] FIG. 5 is a diagram conceptually illustrating a procedure for transmitting a bundle from one terminal to another terminal according to an embodiment of the present disclosure.

[0194] According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 5, the first terminal (500) may include a first LBA (510) and a first SSP (520), and the second terminal (550) may include a second LBA (560) and a second SSP (570). For example, the first terminal (500) may be a terminal equipped with a first SSP (510) and a first LBA (520) installed to control the first SSP (510), and the second terminal (550) may be a terminal equipped with a second SSP (560) and a second LBA (570) installed to control the second SSP (560).

[0195] Referring to FIG. 5, at step 5000, the first SSP (510) and first LBA (520) of the first terminal (500) and the second LBA (570) of the second terminal (550) can perform a preparation procedure (bundle transmission preparation procedure) necessary for bundle transmission. For a more detailed description of the procedure, refer to the detailed description of FIG. 6 to be described later.

[0196] Referring to FIG. 5, in step 5005, a procedure (bundle transmission procedure) for transmitting a bundle from a first terminal (500) to a second terminal (550) may be performed. For a more detailed description of the procedure, refer to the detailed description of FIG. 7 to be described later.

[0197] Referring to FIG. 5, a procedure (bundle installation procedure) in which a bundle transmitted to the second terminal (550) in step 5010 is installed on the second terminal (550) can be performed. For a more detailed description of the above procedure, refer to the detailed description of FIG. 8 to be described later.

[0199] FIG. 6 is a diagram illustrating a detailed procedure for preparing for bundle transmission among the procedures presented in FIG. 5. More specifically, FIG. 6 is a diagram exemplarily illustrating a procedure in which one terminal undergoes a preparation process necessary to transmit a bundle to another terminal according to an embodiment of the present disclosure. In this specification, the procedure of FIG. 6 may be referred to as a bundle transmission preparation procedure.

[0200] According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 6, the first terminal (600) may include a first LBA (610) and a first SSP (620), and the second terminal (650) may include a second LBA (660) and a second SSP (670). For example, the first terminal (600) may be a terminal equipped with a first SSP (610) and a first LBA (620) installed to control the first SSP (610), and the second terminal (650) may be a terminal equipped with a second SSP (660) and a second LBA (670) installed to control the second SSP (660).

[0201] According to various embodiments, the first terminal (600) may possess a pre-installed bundle. This bundle may be stored in the first SSP (610), may be stored in the first LBA (620), may be stored in memory other than the first SSP (610) and the first LBA (620) (not shown in FIG. 6), or may be stored redundantly in at least one of the first SSP (610), the first LBA (620), and external memory. Additionally, the bundle may be stored in a divided state in a combination of at least two of the first SSP (610), the second LBA (620), and external memory, and there may be overlapping information between the divided bundles. Furthermore, all or part of the stored bundle may be encrypted and may additionally include signature information.

[0202] According to various embodiments, the first terminal (600) may further possess metadata associated with the bundle mentioned above. This metadata may be stored in the first SSP (610), may be stored in the first LBA (620), may be stored in memory other than the first SSP (610) and the first LBA (620) (not shown in FIG. 6), or may be stored redundantly in at least one of the first SSP (610), the first LBA (620), and external memory. Additionally, the metadata may be stored in a divided state in a combination of at least two of the first SSP (610), the second LBA (620), and external memory, and there may be overlapping information between the divided information. Furthermore, all or part of the stored metadata may be encrypted and may additionally include signature information.

[0203] According to various embodiments, the first terminal (600) may have at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), or a bundle family manager identifier (SPB Family Custodian Object ID) associated with the bundle. The identifier information may exist within the bundle, within metadata, or in an area independent of the bundle and metadata, or it may be stored in duplicate or partitioned within the bundle, metadata, or an independent area. Additionally, the identifier information may be encrypted or may further include signature information.

[0204] According to various embodiments, the first terminal (600) may possess a 'bundle transfer setting' associated with the bundle. The bundle transfer setting may include a 'bundle transfer policy'. Additionally, the bundle transfer setting may further include a 'bundle transfer history'. The 'bundle transfer setting' may exist within the bundle, within metadata, or in an area independent of the bundle and metadata, or it may be stored in duplicate or divided within the bundle, metadata, or an independent area. Additionally, the bundle transfer setting may be encrypted or may further include signature information.

[0205] According to various embodiments, the 'bundle transfer settings' may be acquired at a necessary time without being previously stored within the terminal. In this case, the 'bundle transfer settings' may be generated by a service provider, a bundle management server, or through collaboration between the service provider and the bundle management server in response to a request from the terminal, and then transmitted to the terminal. Alternatively, at least one entity among the service provider and the bundle management server may collaborate with the terminal to generate the 'bundle transfer settings'.

[0206] According to various embodiments, the 'bundle transfer settings' within the terminal may be updated by a service provider, a bundle management server, or through collaboration between the service provider and the bundle management server. Alternatively, the terminal may update the 'bundle transfer settings' through collaboration between at least one of the service provider and the bundle management server. The timing and method of the update may be determined by policies of the service provider, the bundle management server, the terminal manufacturer, etc.

[0207] According to various embodiments, the 'bundle transfer policy' is a policy regarding whether a bundle can be transferred between devices, and may be generated by the service provider that is the original provider of the bundle, may be generated by the bundle management server, or may be generated through collaboration between the aforementioned service provider and the bundle management server. This 'bundle transfer policy' may optionally include an argument (or indication) indicating whether the transfer of the bundle between devices is allowed.

[0208] Additionally, this 'bundle transfer policy' may optionally include an additional parameter specifying the conditions under which transfer is permitted when the transfer of the bundle between devices is allowed.

[0209] Examples of factors specifying under the aforementioned conditions whether transmission is allowed include the maximum number of transmissions allowed between devices within the bundle, the period during which transmission between devices within the bundle is allowed, or the maximum number of transmissions allowed within a specific period of the bundle.

[0210] In addition, as another example of the aforementioned factor, a factor may be included that specifies whether permission from the service provider and / or bundle management server is required before the transfer of the bundle between devices. If permission from the service provider and / or bundle management server is required before the transfer of the bundle between devices, the process of obtaining permission may be performed as part of steps 6000 and / or 6010 and / or 7015 and / or 7040. A detailed procedure for this process will be referenced in the drawings described later. However, the process of obtaining permission from the service provider and / or bundle management server is not necessarily required to be performed as part of steps 6000 and / or 6010 and / or 7015 and / or 7040, but may be performed at any moment during the procedure presented in FIG. 6 and / or FIG. 7. Information regarding at what moment permission from the service provider and / or bundle management server must be obtained may also be included as part of the 'bundle transfer policy'.

[0211] Additionally, as another example of the aforementioned factors, a factor describing the allowed methods for moving bundles between devices may be included. For instance, a factor specifying whether online and / or offline transfer is permitted as a method for moving bundles between devices may be included. If both online and offline transfers are permitted, it may also include whether a preferred method of transfer between devices is preferred. Furthermore, if both online and offline transfers are permitted, it may include whether the other method can be automatically executed if one method fails. Additionally, if both are permitted, it may include whether user consent is required to perform the other method if one method fails. Furthermore, it may include whether re-provisioning is possible if the bundle transfer between devices fails. For instance, it may include whether re-provisioning is possible if the online or offline transfer between devices fails. In this case, it may also include whether re-provisioning can be executed automatically. Additionally, it may include whether user consent is required to execute re-provisioning. Additionally, settings regarding the execution order of each method when online movement, offline movement, and re-visioning are all permitted may also be included. For instance, it could be configured to attempt offline movement first, attempt online movement if that fails, and attempt re-visioning if that also fails. However, this is merely an example, and the execution order of online movement, offline movement, and re-visioning can be configured in various ways. Furthermore, it may include whether the linkage can be executed automatically when online movement, offline movement, and re-visioning are executed in an arbitrary order.Alternatively, it may also include whether user consent must be obtained whenever a linkage occurs when online movement, offline movement, and re-visioning are executed in any order.

[0212] In addition, as other examples of the aforementioned factors, the following items may be included. This may include whether a notification regarding bundle transfer must be sent to the service provider and / or bundle management server. It may also include whether the bundle is available on multiple terminals. Furthermore, it may include whether additional authentication is required using information received from the service provider and / or bundle management server when the terminal sending the bundle authenticates the terminal receiving the bundle. That is, the service provider and / or bundle management server may provide authentication information related to trusted terminals and / or SSPs, and the terminal sending the bundle may use this information to authenticate whether the terminal receiving the bundle is a terminal trusted by the service provider and / or bundle management server.

[0213] In addition, as other examples of the aforementioned factors, the following items may be included. This may include whether the terminal transmitting the bundle needs to receive additional information from the terminal receiving the bundle before transmitting it. In this case, the 'information of the terminal receiving the bundle' to be additionally received may be entered directly by the user, entered from an external server, or entered by the terminal receiving the bundle through communication between the two terminals. Furthermore, this may include whether additional KYC (Know Your Customer) authentication is required for the bundle to be set to a usable state on the terminal receiving the bundle. In this case, additional KYC authentication may be performed in various ways. For instance, it may be performed via telephone and / or ARS authentication and / or text messages. Alternatively, it may be performed by the user operating the terminal to communicate with the service provider and / or bundle management server. Or, authentication may be performed by the terminal receiving the bundle communicating with the service provider and / or bundle management server without user intervention.

[0214] According to various embodiments, the 'bundle transfer history' is information in which the history of past inter-device transfers of bundles is recorded. For example, the 'bundle transfer history' may optionally include the date and time when the bundle transfer occurred. Additionally, the 'bundle transfer history' may optionally include information on the number of times the bundle transfer occurred. Furthermore, the 'bundle transfer history' may optionally include at least one of the information of the terminal that transferred the bundle or the information of the terminal that received the bundle. If the bundle is initially installed on the first terminal (600) without having been transferred between devices in the past, the bundle transfer history may be set by the first terminal, may be set by the service provider that is the provider of the bundle, may be set by the bundle management server, or may be set by the collaboration of at least two of the aforementioned first terminal, service provider, and bundle management server. If this bundle has been transferred between devices in the past, this bundle transfer history may have been set by the first terminal, may have been set by the old terminal that transferred the bundle to the first terminal in the past, may have been set by the service provider who is the original provider of the bundle, may have been set by the bundle management server, or may have been set by the collaboration of at least two of the aforementioned first terminal, old terminal, service provider, and bundle management server.

[0215] Referring to FIG. 6, information regarding bundles to be transmitted between devices at step 6000 can be transmitted to the first LBA (620). This transmission process may be carried out, for example, through a process in which a user directly selects a bundle via a UI provided by the first terminal (600) as illustrated in FIG. 6, or it may be input to the first LBA (620) via a push input from a remote server, or the first LBA (620) may connect to a remote server to read the information. When the first terminal (600) provides a UI to the user, a list of all bundles installed on the terminal may be provided through this UI, or only a list of bundles that are currently movable may be provided. If a list of bundles that are not currently movable is provided, additional information indicating the movability of the bundles shown in the list may be provided. Furthermore, through the UI, information such as bundle information or bundle movement policies may be optionally provided in addition to the list of bundles described above.

[0216] At step 6000, the first LBA (620) can check whether the bundle can be transferred between devices using the 'bundle transfer settings'. Additionally, the first LBA (620) can check the allowed method of transferring the bundle between devices through the 'bundle transfer settings'. For example, it can check the type of connection that can be made between devices for the bundle transfer.

[0217] Additionally, the first LBA (620) can check whether the 'Bundle Transfer Settings' are configured to require approval from the service provider and / or the bundle management server before transferring the bundle. If this setting is configured, the first terminal (600) can access the 'server operated by the service provider and / or the bundle management server and / or the server operated in collaboration with the service provider and the bundle management server' (hereinafter referred to as the 'Server') to request approval for the transfer of the bundle between devices. At this time, the first terminal (600) can provide information related to the bundle to the 'Server' (e.g., bundle identifiers such as the bundle identifier (SPB ID), bundle family identifier (SPB Family ID), and bundle family manager identifier (SPB Family Custodian Object ID), or other information indicating the attributes of the bundle (e.g., the bundle's metadata or part of the metadata)). In this process, a mutual authentication process between the first terminal and the server may be further included. If the server does not approve the transfer of the bundle between devices, the bundle transfer process may be stopped.

[0218] Additionally, the first LBA (620) can check the 'bundle transfer setting' to determine whether the terminal sending the bundle needs to receive additional information about the terminal receiving the bundle before sending the bundle. If this setting is enabled, the first LBA (620) can receive information ssp2.info of the terminal receiving the bundle. Ssp2.info may be information that can identify the second terminal. Ssp2.info may be the SSP identifier of the second SSP (660). Ssp2.info may be a series of information bound to the SSP identifier of the second SSP (660). For example, Ssp2.info may be a series of strings and / or codes bound to the SSP identifier of the second SSP (660). The user can directly input ssp2.info through the first LBA (620). Other possible input methods for ssp2.info include inputting this information through a server or through communication between the second terminal (650) and the first terminal (600).

[0219] Additionally, the first LBA (620) may generate 'bundle transmission information'. The bundle transmission information may include bundle identifiers such as the bundle identifier (SPB ID), bundle family identifier (SPB Family ID), and bundle family manager identifier (SPB Family Custodian Object ID) of the bundle to be transmitted. Additionally, the bundle transmission information may include other information indicating the attributes of the bundle (e.g., bundle metadata or part of metadata). Additionally, the bundle transmission information may include the address (SPBM Addr) of the bundle management server associated with the bundle to be transmitted. The bundle transmission information may include information necessary for the connection between the two terminals to be made in step 6025. For example, it may include information necessary for the Wi-Fi connection between the two terminals (e.g., the SSID and / or BSSID of the second terminal (650), the Pre Shared Key to be used for authentication of the connection between the two terminals, the IP address of the second terminal (650), and the port number to be used for communication between the two terminals).

[0220] Referring to FIG. 6, information related to the bundle selected through step 6000 in step 6005 can be transmitted from the first LBA (620) to the first SSP (610). For example, as illustrated in FIG. 6, information related to the selected bundle can be transmitted from the first LBA (620) to the first SSP (610) via the Select SPB command. At this time, the information transmitted from the first LBA (620) to the first SSP (610) may include information for identifying the bundle selected in step 6000. The information for identifying the bundle may be a bundle identifier (SPB ID) or another identifier capable of identifying this bundle identifier. Additionally, the information transmitted from the first LBA (620) to the second SSP (610) may optionally further include a bundle identifier such as a bundle family identifier (SPB Family ID) or a bundle family manager identifier (SPB Family Custodian Object ID), or other information indicating the attributes of the bundle (e.g., bundle metadata or part of metadata).

[0221] Referring to FIG. 6, in step 6010, the first SSP (610) can check whether the bundle requested for transmission is transferable between devices. This process can be performed by first identifying the bundle requested for transmission based on the information received in step 6005, and by checking the 'bundle transfer settings' associated with the bundle. In this process, the first SSP (610) can use the 'bundle transfer policy' to check under what conditions the transfer of the bundle between devices is possible, and if necessary, compare the 'bundle transfer history' with the 'bundle transfer policy' to determine whether the transfer of the bundle between devices is currently possible.

[0222] Some examples of the procedure for determining whether the transfer of a bundle between devices is currently possible using the 'Bundle Transfer Settings' in the above steps are as follows. For example, if the 'Bundle Transfer Policy' includes a parameter indicating whether the transfer of the bundle between devices is allowed, SSP 1 (610) can check the value of this parameter. If the value written in this parameter indicates that the transfer of the bundle between devices is prohibited, the first SSP (610) can stop the transfer procedure of the bundle between devices and can transmit this result to the first LBA (620). As another example, if the 'Bundle Transfer Policy' includes information specifying under what conditions the transfer of the bundle between devices is allowed, the first SSP (610) can check the conditions and then compare these conditions with the information recorded in the 'Bundle Transfer History'. For example, if the 'Bundle Transfer Policy' specifies the maximum number of transfers allowed between devices for the bundle, the period during which transfers between devices are allowed, or the maximum number of transfers allowed within a specific period for the bundle, the first SSP (610) can check the 'Bundle Transfer History' to determine whether the bundle currently to be transferred can be transferred without violating the 'Bundle Transfer Policy'. At this time, if it is determined that transferring the current bundle violates the 'Bundle Transfer Policy', the first SSP (610) can stop the transfer procedure between devices for the bundle and can transmit this result to the first LBA (620). Additionally, if the 'Bundle Transfer Settings' are configured to require approval from the service provider and / or the bundle management server before transferring the bundle, a procedure to obtain approval can be performed. That is, the first terminal (600) can request approval for bundle transfer between devices by connecting to a ‘server operated by a service provider and / or a bundle management server and / or a server operated in collaboration with the service provider and the bundle management server’ (hereinafter referred to as ‘server’).At this time, the first terminal (600) may provide information related to the bundle (e.g., bundle identifiers such as a bundle identifier (SPB ID), bundle family identifier (SPB Family ID), bundle family manager identifier (SPB Family Custodian Object ID), or other information indicating the attributes of the bundle (e.g., metadata of the bundle or part of the metadata)) to the 'server'. In this process, a mutual authentication process between the first terminal and the server may be further included. If the server does not approve the transfer of the bundle between devices, the bundle transfer procedure may be stopped.

[0223] Additionally, in step 6010, the first SSP (610) may optionally generate a 'bundle move code'. As such, the bundle move code generation procedure in step 6010 of FIG. may be an optional procedure. In this case, the bundle move code generation procedure may be performed as needed or omitted. For example, if the bundle move code is not used for moving the bundle, or if the bundle move code is used for moving the bundle but a previously defined value (e.g., a bundle identifier) ​​is used as the bundle move code, the bundle move code generation procedure in step 6010 of FIG. may be omitted. Alternatively, if the bundle move code is used for moving the bundle and a new bundle move code needs to be defined, the bundle move code generation procedure in step 6010 of FIG. may be performed.

[0224] As previously mentioned, 'Bundle Move Codes' may not be used, and if used, they may be newly generated or one of the previously defined values ​​selected. To explain this in more detail, a more detailed explanation of 'Bundle Move Codes' is provided below.

[0225] According to various embodiments, the 'bundle transfer code' is a code used to refer to the bundle during the process of transferring the bundle between devices, and must be a value capable of identifying the bundle. This 'bundle transfer code' may be a value capable of identifying a bundle that is already defined (e.g., a bundle identifier (SPB ID) or a predefined value capable of identifying this bundle identifier), or a new value generated by the first SSP (610) after receiving a request for bundle transfer, or a value that is a combination of a predefined value and a newly generated value. Additionally, the 'bundle transfer code' may be a single value, or a set of values ​​containing one or more values. If the 'bundle transfer code' is a combination of one or more values, these values ​​may include at least one of the predefined bundle identifier, a predefined value capable of identifying the bundle identifier, or a value newly generated by the first SSP (610) after receiving a request. Accordingly, in the present disclosure, the bundle transfer code used for inter-device transfer of a bundle may be set to a value other than the unique identifier (Bundle Identifier (SPB ID)) of the bundle to be transferred. Through this, the procedure for inter-device transfer of a bundle can be performed without external exposure of the unique identifier of the bundle.

[0226] When a 'bundle transfer code' is used for bundle transfer, in step 6010, the first SSP (610) can bind the information of the bundle to be transferred with the previously described 'bundle transfer code'.

[0227] Referring to FIG. 6, in step 6015, the response result for step 6005 can be transmitted from the first SSP (610) to the first LBA (620). For example, as illustrated in FIG. 6, the response to the Select SPB command can be transmitted from the first SPB (610) to the first LBA (620) via the Select SPB response. This response value may include the 'bundle transfer code' described in step 6010. Additionally, the information transmitted from the first SSP (610) to the first LBA (620) may optionally further include bundle identifiers such as a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), and a bundle family manager identifier (SPB Family Custodian Object ID), or other information indicating the attributes of the bundle (e.g., bundle metadata or part of metadata). Additionally, the information transmitted from the first SSP (610) to the first LBA (620) may optionally include the address (SPBM Addr) of the bundle management server associated with the bundle to be transmitted.

[0228] Steps 6005 through 6015 may be omitted.

[0229] Referring to FIG. 6, in step 6020, information necessary for inter-device bundle transfer may be transferred from the first LBA (620) of the first terminal (600) to the second LBA (670) of the second terminal (650). At this time, the information transferred from the first LBA (620) to the second LBA (670) may include 'bundle transfer information'. Alternatively, the information transferred from the first LBA (620) to the second LBA (670) may include 'bundle transfer code'. Additionally, the information transferred from the first LBA (620) to the first LBA (670) may optionally include bundle identifiers such as a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), a bundle family manager identifier (SPB Family Custodian Object ID), or other information indicating attributes of the bundle (e.g., bundle metadata or part of metadata). Additionally, the information transmitted from the first LBA (620) to the second LBA (670) may optionally include additional information necessary for the connection to be established between the first LBA (620) and the second LBA (670) in step 6025. Additionally, the information transmitted from the first LBA (620) to the second LBA (670) may optionally include a shared secret value that will be shared between the first LBA (620) and the second LBA (670). Additionally, the information transmitted from the first LBA (620) to the second LBA (670) may optionally include the address (SPBM Addr) of the bundle management server associated with the bundle to be transmitted. Additionally, the information transmitted from the first LBA (620) to the second LBA (670) may optionally include information indicating that a bundle transfer between devices will be performed.

[0230] Information transmitted from the first LBA (620) to the second LBA (670) through the aforementioned 6020 step can be transmitted in various ways. For example, the first LBA can provide information to be transmitted to the second LBA to the user through the UI of the first terminal (600), and the user can input the received information into the second LBA using the UI of the second terminal (650). Alternatively, the first LBA can create information to be transmitted to the second LBA in the form of an image (e.g., a QR code) and display it on the screen of the first terminal, and the user can transmit the information to the second LBA (670) by scanning this image using the second terminal (650). However, the method of transmitting information from the first LBA (620) to the second LBA (670) is not limited to the above methods.

[0231] Referring to FIG. 6, a connection may be established (or configured) between the first LBA (620) and the second LBA (670) in step 6025. If information necessary for the connection is transmitted in step 6020, the first LBA (620) and the second LBA (670) may use this information to establish the connection. The connection between the first LBA (620) and the second LBA (670) may be a direct device-to-device connection (e.g., a wireless connection such as NFC, Bluetooth, UWB, WiFi-Direct, LTE D2D (device-to-device), 5G D2D, or a wired connection via cable) or a remote connection where a remote server (e.g., a relay server) is located between the first LBA (620) and the second LBA (670).

[0232] Referring to FIG. 6, step 6025 is depicted as the final step, but this step is independent of the other steps mentioned above, namely steps 6000, 6005, 6010, 6015, and 6020, and can be performed without regard to the order of the other steps. For example, step 6025 may be performed between steps 6015 and 6020, in which case the information transmitted from the first LBA (620) to the second LBA 2 (670) in step 6020 may be transmitted through the connection established in 6025.

[0234] FIG. 7 is a diagram illustrating a detailed procedure for the procedure of transmitting a bundle among the procedures presented in FIG. 5. More specifically, FIG. 7 is a diagram exemplarily illustrating a procedure for one terminal to transmit a bundle to another terminal according to an embodiment of the present disclosure. In the present disclosure, the procedure of FIG. 7 may be referred to as a bundle transmission procedure.

[0235] According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 7, the first terminal (700) may include a first LBA (710) and a first SSP (720), and the second terminal (750) may include a second LBA (760) and a second SSP (770). For example, the first terminal (700) may be a terminal equipped with a first SSP (710) and a first LBA (720) installed to control the first SSP (710), and the second terminal (750) may be a terminal equipped with a second SSP (760) and a second LBA (770) installed to control the second SSP (760).

[0236] Referring to FIG. 7, at step 7000, the second LBA (770) may request "SSP information (SspInfo)" from the second SSP 2 (760). When the second LBA (770) requests "SSP information (SspInfo)" from the second SSP (760) at step 7000, the second LBA (770) may inform the second SSP (760) that a bundle transfer between devices will be performed. Additionally, the second LBA (770) may optionally provide information about the bundle to be transferred to the second SSP (760). This information may optionally include at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), and a bundle family manager identifier (SPB Family Custodian Object ID).

[0237] Additionally, step 7000 may be performed automatically immediately following the process illustrated in FIG. 6, or it may be performed after receiving external input. In this case, the 'external input' may be achieved through a process in which the user directly selects a bundle to be transmitted via the UI provided by the second terminal (750), or it may be input to the second LBA (720) via push input from a remote server, or the second LBA (720) may connect to a remote server to read the information.

[0238] Referring to FIG. 7, in step 7005, the second SSP (760) may generate its "SSP information." The "SSP information" may include information of the second SSP that must be provided for bundle transmission. For example, the "SSP information" may include information for the certificate negotiation process that the second SSP (760) must undergo before receiving the bundle (certificate negotiation information). This "certificate negotiation information" may include certificate information (SenderSpblVerification) that the second SSP (760) can use to verify another SSP, and certificate information (ReceiverSpblVerification) that another SSP can use to verify itself. Additionally, the "certificate negotiation information" may optionally include a list of key consensus algorithms supported by the second SSP (760), and optionally include a list of encryption algorithms supported by the second SSP (760). Additionally, "certificate negotiation information" may be selected dependently on the value of the bundle family identifier or the bundle family manager identifier if the bundle family identifier (SPB Family ID) and the bundle family manager identifier (SPB Family Custodian Object ID) are provided in step 7000, and in this case, the "SSP information" may optionally include the bundle family identifier and the bundle family manager identifier along with the certificate negotiation information. Additionally, the "SSP information" may optionally include SSP version information including at least one of the version information of the standard specifications supported by the primary platform and loader included in the second SSP (760).

[0239] Referring to FIG. 7, in step 7010, the second SSP (760) can transmit the "SSP information" generated in step 7005 to the first SSP (710) via the second LBA (770) and the first LBA (720).

[0240] According to steps 7000 to 7010 described above, the second LBA (770) requests "SSP information (SspInfo)" from the second SSP (760), and after the second SSP (760) generates its own "SSP information," the second SSP (760) can transmit the "SSP information" to the first SSP (710) via the second LBA (770) and the first LBA (720). However, depending on the embodiment, the process of transmitting "SSP information" from the second terminal (750) to the first terminal (700) may be as follows. For example, the second LBA (770) can generate "SSP information" itself and then transmit the "SSP information" to the first SSP (710) via the first LBA (720). The above operation may be performed automatically immediately following the process illustrated in FIG. 6, or it may be performed after receiving external input. In this case, the 'external input' may be achieved through a process in which the user directly selects a bundle to be transmitted via the UI provided by the second terminal (750), may be input to the second LBA (720) via a push input from a remote server, or the second LBA (720) may connect to a remote server to read the information. For the details regarding the "SSP information" described above, please refer to the details described in step 7005.

[0241] Referring to Fig. 7, in step 7015, the first SSP (710) can check the received "SSP information".

[0242] Additionally, if the 'Bundle Transfer Policy' is configured to require approval from the service provider and / or the bundle management server before transferring the bundle, a procedure to obtain approval may be performed. That is, the first terminal (700) may request approval for the transfer of the bundle between devices by connecting to a 'server operated by the service provider and / or the bundle management server and / or a server operated in collaboration between the service provider and the bundle management server' (hereinafter referred to as the 'Server'). At this time, the first terminal (700) may provide the 'Server' with information related to the bundle (e.g., bundle identifiers such as a bundle identifier (SPB ID), bundle family identifier (SPB Family ID), and bundle family manager identifier (SPB Family Custodian Object ID), or other information indicating the attributes of the bundle (e.g., bundle metadata or part of metadata)) or part and / or all of the SSP information of the second terminal received in the previous step. In this process, a mutual authentication process between the first terminal and the server may be further included. However, the mutual authentication process between the first terminal and the server does not necessarily have to be performed at this stage and may have already been performed before step 7015. If the server does not approve the transfer of the bundle between devices, the bundle transfer procedure may be stopped.

[0243] In addition, at step 7015, the first SSP (710) can generate "first terminal authentication information (Device1.Auth)" that can authenticate itself.

[0244] A more specific procedure for this process is as follows. The first SSP (710) can verify certificate information that can verify itself using the received "SenderSpblVerification" and "list of key consensus algorithms supported by the second SSP (760)" and select at least one key consensus certificate (ssp1.Cert.KA). Alternatively, the first SSP (710) can generate a key pair for asymmetric encryption to be used for key consensus, a public key "ssp1.ePK.KA" and a private key "ssp1.eSK.KA", using the received "list of key consensus algorithms supported by the second SSP (760)", and then select the public key (ssp1.ePK.KA) from this key pair. Additionally, the first SSP (710) can verify certificate information that can verify itself using the received "SenderSpblVerification" and select at least one more signature certificate (ssp1.Cert.DS). Additionally, the first SSP (710) can use the received "ReceiverSpblVerification" to select at least one certificate of the second SSP (760) that it can verify, and then set the corresponding information as "CiPkIdToBeUsed". Additionally, the first SSP (710) can use the received "List of encryption algorithms supported by the second SSP (760)" to select at least one encryption algorithm to be used in the future, and then set the corresponding information as "CryptoToBeUsed". Additionally, the first SSP (710) can check the received "List of standard specification versions supported by the primary platform and loader included in the second SSP (760)" to see if there is a version of the standard specification that it also supports among them.

[0245] The aforementioned "first terminal authentication information (Device1.Auth)" may include at least one of "ssp1.Cert.KA", "ssp1.ePK.KA", "CiPkIdToBeUsed", and "CryptoToBeUsed" described above. Additionally, the "first terminal authentication information (Device1.Auth)" may optionally further include the "ssp1.Cert.DS" described above. Furthermore, the "first terminal authentication information (Device1.Auth)" may optionally further include at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), and a bundle family manager identifier (SPB Family Custodian Object ID) associated with a bundle to be transmitted in the future.

[0246] At this time, part or all of the "first terminal authentication information (Device1.Auth)" mentioned above may be digitally signed so that it can be verified using ssp1.Cert.DS to ensure the integrity of the information, and this digitally signed data may be added as part of the "first terminal authentication information".

[0247] Referring to FIG. 7, in step 7020, the first SSP (710) can transmit the "first terminal authentication information (Device1.Auth)" generated in step 7015 to the second LBA (770) via the first LBA (720).

[0248] Referring to FIG. 7, at step 7025, the second LBA (770) may transmit "first terminal authentication information (Device1.Auth)" to the second SSP (760). Additionally, the second LBA (770) may further transmit "bundle transfer code" to the second SSP (760). In particular, the second LBA (770) may transmit "bundle separator" (e.g., bundle identifier (SPB ID)) to the second SSP (760). According to an embodiment, the second LBA (770) may transmit the "bundle transfer code" to the second SSP (760) at a step other than step 7025. For example, the second LBA (770) may transmit the "bundle transfer code" to the second SSP (760) at step 7000.

[0249] Referring to FIG. 7, in step 7030, the second SSP (760) can verify the received "first terminal authentication information (Device1.Auth)". If the second SSP (760) receives "ssp1.Cert.KA", it can verify the validity of the certificate by checking the signature of the certificate. Additionally, if the second SSP (760) receives "ssp1.ePK.KA" and its corresponding digital signature, it can first verify the validity of ssp1.Cert.DS and then verify the integrity of the received public key ssp1.ePK.KA by using this certificate to check the digital signature. Additionally, the second SSP (760) can check the received "CiPkIdToBeUsed" and select at least one signature certificate (ssp2.Cert.DS) that can verify itself.

[0250] Additionally, although not illustrated in the drawing, in step 7030, the second SSP (760) may generate a public key "ssp2.ePK.KA" and a private key "ssp2.eSK.KA" as a key pair for asymmetric encryption to be used for key consensus, and then select the public key (ssp2.ePK.KA) from this key pair. Additionally, the second SSP (760) may select either the public key for key consensus included 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 future communication with terminal 1. ShKey01 must be a session key for the encryption algorithm included in the received "CryptoToBeUsed".

[0251] Additionally, in step 7030, the second SSP (760) may generate "second terminal authentication information (Device2.Auth)" capable of authenticating itself. At this time, "second terminal authentication information (Device2.Auth)" may include "ssp2.Cert.DS". Additionally, "second terminal authentication information (Device2.Auth)" may further include "ssp2.ePK.KA". Additionally, "second terminal authentication information (Device2.Auth)" may further include a transaction ID referring to the current session created by SSP 2 (760). Additionally, "second terminal authentication information (Device2.Auth)" may further include a "bundle transfer code". Additionally, "second terminal authentication information (Device2.Auth)" may further include a Primary Platform Identifier loaded on the second SSP (760). Additionally, "Device2.Auth" may further include a Part Number ID of the second SSP (760). The Part Number ID may be information that allows the manufacturer of the primary platform installed on the second SSP (760) and the model information of the primary platform to be inferred using this ID. Additionally, "Device2.Auth" 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 associated with a bundle to be transmitted in the future. Additionally, "Device2.Auth" may include ssp2.info. Ssp2.info may be information that can refer to the second terminal. Ssp2.info may be the SSP identifier of the second SSP (660). Ssp2.info may be a series of information bound to the SSP identifier of the second SSP (660). For example, Ssp2.info may be a series of strings and / or codes bound to the SSP identifier of the second SSP (660).

[0252] At this time, part or all of the "second terminal authentication information (Device2.Auth)" mentioned above may be digitally signed so that it can be verified using ssp2.Cert.DS to ensure the integrity of the information, and this digitally signed data may be added as part of the "second terminal authentication information." In addition, part or all of the "second terminal authentication information (Device2.Auth)" may be encrypted using the previously generated session key ShKey01.

[0253] Referring to FIG. 7, in step 7035, the second SSP (760) can transmit the "second terminal authentication information (Device2.Auth)" generated in step 7030 to the first SSP (710) via the second LBA (770) and the first LBA (720). At this time, the "bundle transfer code" may optionally be transmitted further. Additionally, the first LBA (720) can additionally transmit the ssp2.Info received in step 6000 to the first SSP (710).

[0254] Referring to FIG. 7, in step 7040, the first SSP (710) can verify the received "second terminal authentication information (Device2.Auth)". The first SSP (710) can verify the validity of the certificate by verifying the signature of the received "ssp2.Cert.DS". Additionally, the first SSP (710) can check whether the received bundle identifier (SPB ID), bundle family identifier (SPB Family ID), or bundle family manager identifier (SPB Family Custodian Object ID) is a value correctly set in association with the bundle to be transmitted. In particular, by checking the bundle transfer settings associated with the received bundle identifier, it can determine whether the bundle is a bundle that can be transmitted to the second terminal. Additionally, the first SSP (710) can store the received transaction ID or the Primary Platform Identifier installed on the second SSP (760). Additionally, the first SSP (710) can check whether the second SSP (760) is an SSP capable of installing the bundle using the received primary platform ID and / or part number ID (Eligibility Check). Additionally, the first SSP (710) can bind the received transaction ID or the primary platform ID loaded on the second SSP (760) to the currently ongoing session or the bundle to be transmitted. Additionally, the first SSP (710) can verify whether the value of ssp2.Info received from the first LBA (720) in step 7035 is the same as the value of ssp2.Info included in the "second terminal authentication information (Device2.Auth)".

[0255] In the process described above, if the "second terminal authentication information (Device2.Auth)" contains encrypted data, the first SSP (710) can generate a session key ShKey01 using the private key or ssp1.eSK.KA corresponding to the public key for key consensus included in the received ssp2.ePK.KA and its own ssp1.Cert.KA, and then decrypt the encrypted data using this session key and perform a verification process. Additionally, in this process, if the "second terminal authentication information (Device2.Auth)" contains a digital signature, the first SSP (710) can verify the validity of the received digital signature using "ssp2.Cert.DS".

[0256] Additionally, if the 'bundle transfer policy' is set to require approval from the service provider and / or bundle management server before transferring the bundle, a procedure to obtain approval may be performed. That is, the first terminal (700) may request approval for the transfer of bundles between devices by connecting to the 'server operated by the service provider and / or bundle management server and / or server operated in collaboration with the service provider and bundle management server' (hereinafter referred to as the 'server'). At this time, the first terminal (700) may provide the 'server' with information related to the bundle (e.g., bundle identifiers such as a bundle identifier (SPB ID), bundle family identifier (SPB Family ID), bundle family manager identifier (SPB Family Custodian Object ID), or other information indicating attributes of the bundle (e.g., metadata of the bundle or part of the metadata)), part and / or all of the SSP information received from the second terminal, or part and / or all of the 'second terminal authentication information' received from the second terminal (e.g., the primary platform ID and / or part number ID of the second SSP). In this process, a mutual authentication process between the first terminal and the server may be further included. However, the mutual authentication process between the first terminal and the server does not necessarily have to be performed at this stage and may have already been performed prior to step 7040. If the server does not approve the transfer of the bundle between devices, the bundle transfer procedure may be stopped.

[0257] Also, in step 7040, although not illustrated in FIG. 7, the first SSP (710) may generate a key pair for asymmetric encryption to be used for key consensus, 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 value as the previously generated "ssp1.ePK.KA and ssp1.eSK.KA". Alternatively, the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA" may be set to the same value as the previously used "public key contained in ssp1.Cert.KA and the corresponding private key". Additionally, the first SSP (710) can generate 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.eSK.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 value of the previously generated ShKey01.

[0258] Additionally, in step 7040, the first SSP (710) may configure a bundle to be transmitted to the second terminal (750) and / or metadata associated with the bundle. At this time, the first SSP (710) may identify the bundle to be transmitted using the received "bundle transfer code." Additionally, the bundle to be configured may include "ssp1.Cert.DS". Additionally, the bundle to be configured may further include "ssp1.bundle.ePK.KA". Additionally, the bundle to be configured may further include a transaction ID identifying the session. Additionally, the bundle to be configured may optionally further include a "bundle transfer code". Additionally, the bundle to be configured may optionally further include at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), and a bundle family manager identifier (SPB Family Custodian Object ID) associated with the bundle to be transmitted. Additionally, the bundle to be configured may optionally further include metadata of the bundle. Additionally, the bundle to be configured may optionally include the address of the bundle management server (SPBM Addr).

[0259] According to various embodiments, a "bundle move setting" may be included in the bundle (or metadata associated with the bundle) configured in step 7040. At this time, the first SSP (710) may update the "bundle move history" among the bundle move settings to be included in the bundle, taking into account the current transfer, and then include this content in the bundle. Possible examples of the "bundle move history" update performed at this time are as follows. For instance, the first SSP (710) may add date and time information on when the current bundle move is performed to the bundle move history. Additionally, the first SSP (710) may increase the information on the number of times a bundle move has been performed written in the bundle move history by 1. Additionally, the first SSP (710) may add at least one of the information of the first terminal (700), the first SSP (710), and the first LBA (720) as information of the terminal that transmitted the bundle to the bundle transfer history, or add at least one of the information of the second terminal (750), the second SSP (760), and the second LBA (770) as information of the terminal that received the bundle. Additionally, the first SSP (710) may add its own digital signature to ensure the integrity of the update history written above.

[0260] According to various embodiments, digital signature data generated using ssp1.Cert.DS may be added to the bundle to be configured in step 7040. That is, digital signature data generated for some or all of the components of the bundle specified above may be added as part of the bundle. Additionally, some or all of the bundle to be configured may be encrypted using ShKey02.

[0261] Referring to FIG. 7, in step 7045, the first SSP (710) can transmit the bundle created (configured) in step 7040 to the second LBA (770) via the first LBA (720). At this time, metadata associated with the transmitted bundle may optionally be transmitted. Additionally, a “bundle move code” associated with the transmitted bundle may optionally be transmitted. Additionally, a “bundle move setting” associated with the transmitted bundle may be transmitted. For example, the “bundle move setting” may not be included in the bundle or metadata, but may be transmitted in a separate format (e.g., a message). Also, at this time, the first SSP (710) may transmit without updating the bundle move setting it possesses. Alternatively, the first SSP (710) may update the bundle move setting before transmitting it. For example, SSP 1 (710) may add date and time information on when the current bundle move is performed to the bundle move history. Additionally, the first SSP (710) may increase the information on the number of times a bundle transfer has occurred, as written in the bundle transfer history, by 1. Additionally, the first SSP (710) may add at least one of the information of the first terminal (700), the first SSP (710), and the first LBA (720) as information of the terminal that transmitted the bundle to the bundle transfer history, or add at least one of the information of the second terminal (750), the second SSP (760), and the second LBA (770) as information of the terminal that received the bundle. Finally, the first SSP (710) may add its own digital signature to ensure the integrity of the history it transmits, whether it sends the bundle transfer settings with updates or sends them without updates. Meanwhile, according to the embodiment, as described above in step 7040, the bundle transfer settings may be included within the configured bundle, and in this case, the transmission of the bundle transfer settings in step 7045 may be omitted.

[0262] The second SSP (710) can delete the transmitted bundle. Or, it can set the transmitted bundle to an unusable state.

[0264] FIG. 8 is a diagram illustrating a detailed procedure for the procedure in which the transmission process is completed after a bundle is transmitted among the procedures presented in FIG. 5. More specifically, FIG. 8 is a diagram illustrating an example of a procedure in which a terminal installs a received bundle and updates related settings according to an embodiment of the present disclosure. In the present disclosure, the procedure of FIG. 8 may be referred to as a bundle installation procedure.

[0265] According to various embodiments, the terminal may include at least one LBA and at least one SSP. For example, as in the example of FIG. 8, the first terminal (800) may include a first LBA (810) and a first SSP (820), and the second terminal (850) may include a second LBA (860) and a second SSP (870). For example, the first terminal (800) may be a terminal equipped with a first SSP (810) and a first LBA (820) installed to control the first SSP (810), and the second terminal (850) may be a terminal equipped with a second SSP (860) and a second LBA (870) installed to control the second SSP (860).

[0266] Referring to FIG. 8, at step 8000, the second LBA (870) and the second SSP (860) can collaborate to install a bundle on the second terminal (850). If metadata is transmitted, the second LBA (870) or the second SSP (860) can verify the contents included in the metadata. If a “bundle transfer code” is transmitted, the second LBA (870) or the second SSP (860) can check whether the received bundle transfer code is the same as a bundle transfer code used in the same session in the past (e.g., step 7025 of FIG. 7). If a “bundle transfer setting” is transmitted, the second LBA (870) can transmit this information to the second SSP (860). If a transaction ID is transmitted, the second LBA (870) or the second SSP (860) can check 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 manager identifier (SPB Family Custodian Object ID) is transmitted, the second LBA (870) or the second SSP (860) can check whether this information matches the information of the bundle currently to be received. If ssp1.Cert.DS is transmitted, the second SSP (860) can verify the validity of this certificate and authenticate the first SSP (810). If the received data contains encrypted data, the second SSP (860) can generate a session key ShKey02 using the received ssp1.bundle.ePK.KA and its own ssp2.eSK.KA, and then decrypt the encrypted data using this session key and perform verification. If the received data contains a digital signature, the second SSP (860) can verify ssp1.Cer.DS and then use this certificate to verify the validity of the digital signature.

[0267] Additionally, at step 8000, if the “Bundle Move Settings” are configured to require additional Know Your Customer (KYC) authentication from the user to be set to a usable state, some or all of the following processes may be performed. The second terminal (850) may notify the service provider and / or bundle management server that the current bundle has been installed on its second SSP (860). This notification may include the identifier of the installed bundle and the identifier of the second SSP (860). The second terminal (850) may notify the user that additional KYC authentication is required to activate the bundle. The user may contact the service provider and / or bundle management server to perform KYC authentication. The service provider and / or bundle management server may activate the bundle installed on the second terminal (850) through a remote management command.

[0268] Referring to FIG. 8, in step 8005, the second SSP (860) may optionally update the received bundle transfer settings. As such, the bundle transfer setting update procedure in step 8005 of FIG. 8 may be an optional procedure. In this case, the bundle transfer setting update procedure may be performed as needed or omitted. For example, if the update of the bundle transfer settings itself is not needed, or if the update of the bundle transfer settings is needed but has already been updated by the first terminal and this updated setting has been transmitted to the second terminal, so there is no need to update it again by the second terminal, the bundle transfer setting update procedure in step 8005 of FIG. 8 may be omitted. Alternatively, if the update of the bundle transfer settings is needed and needs to be performed by the second terminal, the bundle transfer setting update procedure in step 8005 of FIG. 8 may be performed.

[0269] According to various embodiments, the second SSP (860) may add date and time information of the bundle movement just performed to the bundle movement history. Additionally, the second SSP (860) may increase the information on the number of times a bundle movement has been performed written in the bundle movement history by 1. Additionally, the second SSP (860) may add information of at least one of the first terminal (800), the first SSP (810), and the first LBA (820) as information of the terminal that transmitted the bundle to the bundle movement history, or add information of at least one of the second terminal (850), the second SSP (860), and the second LBA (870) as information of the terminal that received the bundle. Through this, the second SSP (860) may subsequently check whether the bundle can be moved based on the updated bundle movement settings (bundle movement history) and decide whether to perform a request procedure for the bundle movement.

[0270] FIG. 9 is a drawing illustrating the configuration of a terminal according to an embodiment of the present disclosure.

[0271] As illustrated in FIG. 9, the terminal may include a transceiver (910) and at least one processor (920). Additionally, the terminal may further include an SSP (930). For example, the SSP (930) may be inserted into the terminal or embedded in the terminal. The at least one processor (920) may be referred to as a control unit. However, the configuration of the terminal is not limited to FIG. 9 and may include more or fewer components than those shown in FIG. 9. According to some embodiments, the transceiver (910), at least one processor (920), and memory (not shown) may be implemented in the form of a single chip. Additionally, if the SSP (930) is embedded, it may be implemented in the form of a single chip including the SSP (930).

[0272] According to various embodiments, the transceiver (910) may transmit and receive signals, information, data, etc. according to various embodiments of the present disclosure with the transceiver of another terminal or an external server. The transceiver (910) may be composed of an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies a received signal and down-converts the frequency. However, this is merely one embodiment of the transceiver (910), and the components of the transceiver (910) are not limited to an RF transmitter and an RF receiver. Additionally, the transceiver (910) may receive a signal through a wireless channel and output it to at least one processor (920), and transmit the signal output from at least one processor (920) through a wireless channel.

[0273] According to various embodiments, the transmitting and receiving unit (910) may transmit or receive information of an SSP included in another terminal, authentication information capable of authenticating another terminal, a bundle transfer code, a bundle transfer setting, a bundle, etc. from the transmitting and receiving unit of another terminal or an external server.

[0274] Meanwhile, at least one processor (920) is a component for controlling the terminal overall. The at least one processor (920) can control the overall operation of the terminal according to various embodiments of the present disclosure as described above.

[0275] Meanwhile, the SSP (930) may include a processor or controller for installing and controlling bundles, or may have an application installed.

[0276] According to various embodiments, at least one processor or controller within the SSP (930) can determine whether to transfer a specific bundle by checking the bundle transfer settings. Additionally, the processor or controller can update the bundle transfer settings if necessary.

[0277] Additionally, according to various embodiments, at least one processor or controller within the SSP may generate a bundle transfer code to control the transfer process of a specific bundle. Furthermore, this bundle transfer code may be mapped to a specific bundle and used in the control process.

[0278] In addition, according to various embodiments, at least one processor or controller within the SSP can generate its own SSP information and can verify and confirm SSP information of another SSP received from the outside.

[0279] Additionally, according to various embodiments, at least one processor or controller within the SSP may generate authentication information to verify itself and may also verify authentication information of another SSP received from the outside.

[0280] Additionally, according to various embodiments, the SSP (930) can create a bundle and install the bundle either alone or in cooperation with one or more processors (920). Additionally, the SSP (930) can manage the bundle.

[0281] Additionally, according to various embodiments, the SSP (930) may operate under the control of the processor (920). Alternatively, the SSP (930) may include a processor or controller for installing and controlling bundles, or may have an application installed. Some or all of the application may be installed in the SSP (930) or in memory (not shown).

[0282] Meanwhile, the terminal may further include memory (not shown) and may store data such as basic programs, application programs, and setting information for the operation of the terminal. In addition, the memory may include at least one storage medium among Flash Memory Type, Hard Disk Type, Multimedia Card Micro Type, Card Type Memory (e.g., SD or XD memory, etc.), Magnetic Memory, Magnetic Disk, Optical Disk, Random Access Memory (RAM), Static Random Access Memory (SRAM), Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), and Electrically Erasable Programmable Read-Only Memory (EEPROM). In addition, the processor (920) may perform various operations using various programs, content, data, etc. stored in the memory.

[0284] FIG. 10 is a flowchart illustrating a bundle transmission method of a first security medium according to an embodiment of the present disclosure. In FIG. 10, descriptions that overlap with the descriptions above with reference to FIG. 1 to 9 are omitted.

[0285] Referring to FIG. 10, the first security medium can identify a bundle to be transmitted to the second security medium (S1010). This is as described above with reference to step 6010 of FIG. 6.

[0286] The first security medium can determine whether the transmission of the bundle is allowed based on bundle movement setting information associated with the bundle (S1020). This is as described above with reference to step 6010 of FIG. 6.

[0287] The first security medium may transmit the bundle to the second security medium based on the above decision (S1030). This is as described above with reference to FIGS. 5 to 7.

[0288] According to various embodiments, the first security medium may identify whether to generate a bundle transfer code to be used for the transmission of the bundle, and may generate the bundle transfer code based on the identification.

[0289] According to various embodiments, the step of transmitting the bundle transfer code to the second security medium may be further included.

[0290] According to various embodiments, generating the bundle transfer code may include generating the bundle transfer code when it is identified that the bundle transfer code will be generated. In this case, the bundle transfer code may be a unique ID of a pre-set bundle or a new ID for identifying the bundle.

[0291] According to various embodiments, the bundle transfer setting information may include at least one of bundle transfer policy information or bundle transfer history information.

[0292] According to various embodiments, the bundle transfer policy information may include an indication indicating whether the transfer of the bundle between devices is allowed.

[0293] According to various embodiments, the bundle movement history information may include at least one of information regarding the date and time when the bundle was moved or information regarding the number of times the bundle was moved.

[0294] According to various embodiments, the step of updating the bundle movement setting information may be further included.

[0296] FIG. 11 is a flowchart illustrating a method for receiving a bundle of a second security medium according to an embodiment of the present disclosure. In FIG. 11, descriptions that overlap with the descriptions above with reference to FIG. 1 to 10 are omitted.

[0297] Referring to FIG. 11, the second security medium can receive a bundle transfer code to be used for the transmission of the bundle from the first security medium (S1110). This is as described above with reference to step 7010 of FIG. 7.

[0298] The second security medium can transmit information about the second security medium to the first security medium (S1120). This is as described above with reference to step 7020 of FIG. 7.

[0299] The second security medium may receive first authentication information from the first security medium to authenticate the first security medium (S1130). This is as described above with reference to step 7020 of FIG. 7.

[0300] The second security medium can verify the first authentication information (S1140). This is as described above with reference to step 7030 of FIG. 7.

[0301] The second security medium may transmit second authentication information and the bundle transfer code to the first security medium to authenticate the second security medium based on the result of the verification above (S1150). This is as described above with reference to step 7035 of FIG. 7.

[0302] The second security medium may include the step of receiving the bundle from the first security medium (S1160). This is as described above with reference to step 7045 of FIG. 7.

[0304] FIG. 12 is a diagram illustrating an example of a method in which two terminals interact to transmit a profile between two terminals according to an embodiment of the present disclosure.

[0305] As illustrated in FIG. 12, an eSIM (1203, 1223) may be installed in a terminal (1200, 1220), and a profile (not shown) may be installed in the eSIM (1203, 1223). Additionally, an LPA (1201, 1221) may be installed in the terminal (1200, 1220). The eSIM (1203, 1223) may be controlled by the LPA (1201, 1221). A user (1205, 1225) may control the profile installed in the eSIM (1203, 1223) of each terminal through the LPA (1201, 1221). At this time, the first user (1205) and the second user (1225) may be the same. In addition, the first LPA (1201) and the second LPA (1221) can be connected to each other and communicate. In this case, the possible connection methods between the LPAs will be described by referring to the description of the drawings to be described later.

[0306] The telecommunications operator (1260) is connected to the first RSP server (1240) and the second RSP server (1280), and the LPA (1201) of the first terminal (1200) is connected to the first RSP server (1240), and the LPA (1221) of the second terminal (1220) is connected to the second RSP server (1280). At this time, the first RSP server (1240) and the second RSP server (1280) may be the same or different. In addition, if one or more operator servers are included in the configuration, each operator server may be connected to a separate RSP server, or at least one operator server may be connected to the same RSP server. Additionally, for convenience, FIG. 12 illustrates a case where each RSP server (1240, 1280) is configured as a single server; however, depending on the implementation and embodiment, one or more profile providing servers (SM-DP+) may be included in the server configuration, and one or more activation broker servers (SM-DS) that assist in creating a connection between a specific profile providing server and a terminal may also be included in the server configuration. It should be noted that such various server configurations may be briefly indicated as a single RSP server in the drawings below.

[0308] FIG. 13 is a diagram illustrating a procedure for transmitting a profile from one terminal to another terminal according to an embodiment of the present disclosure.

[0309] Although not shown in FIG. 13, the terminal (1300, 1350) may include an eUICC and an LPA internally as shown in FIG. 12.

[0310] Although not illustrated in FIG. 13, the first terminal (1300) may possess a 'profile transfer setting'. The 'profile transfer setting' may be included in the profile, may be included in the profile metadata, may exist in an independent area other than the profile and profile metadata, or may be stored in duplicate or divided among the profile, profile metadata, and an independent area. Additionally, the 'profile transfer setting' may further include at least one signature information generated based on the information. Each of the at least one signature information may be information generated, for example, by an RSP server, a telecommunications carrier, a terminal manufacturer, an eUICC, an eUICC manufacturer, etc. Additionally, at least one signature information may further include authentication information for, for example, an RSP server, a telecommunications carrier, a terminal manufacturer, an eUICC, an eUICC manufacturer.

[0311] According to various embodiments, the 'profile transfer setting' may be acquired at a necessary time without being previously stored within the terminal. In this case, the 'profile transfer setting' may be generated by a telecommunications carrier, an RSP server, or through collaboration between a telecommunications carrier and an RSP server at the request of the terminal and transmitted to the terminal. Alternatively, the terminal may generate the 'profile transfer setting' through collaboration with at least one of the telecommunications carrier and the RSP server.

[0312] According to various embodiments, the 'profile migration settings' within the terminal may be updated by a telecommunications carrier, an RSP server, or collaboration between a telecommunications carrier and an RSP server. Alternatively, the terminal may update the 'profile migration settings' through collaboration between at least one of the telecommunications carrier and the RSP server. The timing and method of the update may be determined by policies of the telecommunications carrier, the RSP server, the terminal manufacturer, etc.

[0313] According to various embodiments, the 'profile transfer setting' is a policy regarding whether a profile can be transferred between devices, and may be generated by a telecommunications carrier, may be generated by an RSP server, or may be generated through collaboration between the aforementioned telecommunications carrier and the RSP server.

[0314] The aforementioned 'profile transfer setting' may include a factor (or indication) indicating whether the transfer of the corresponding profile between devices is allowed.

[0315] Additionally, the above 'profile transfer setting' may optionally include an additional factor specifying under what conditions transfer is allowed when transfer between devices of the corresponding profile is permitted.

[0316] As an example of the aforementioned parameters, a parameter describing the method of moving an allowed profile between devices may be included. For instance, a parameter indicating whether online and / or offline movement is permitted as a method of moving a profile between devices may be included. If both online and offline movement are permitted, a parameter indicating which method of moving between devices is preferred may be included. Additionally, if both online and offline movement are permitted, a parameter indicating whether the other method can be automatically executed if one method fails may be included. Furthermore, if both online and offline movement are permitted, a parameter indicating whether user consent must be obtained to perform the other method if one method fails may be included. Additionally, a parameter indicating whether re-provisioning is possible when profile movement between devices fails may be included. For instance, a parameter indicating whether re-provisioning is possible if online or offline movement between devices fails may be included. In this case, a parameter indicating whether re-provisioning can be executed automatically may be included. Additionally, a parameter may be included specifying whether user consent is required to execute re-visioning. Furthermore, settings regarding the execution order of each method when online navigation, offline navigation, and re-visioning are all permitted may be included. For instance, it could be configured to attempt offline navigation first, attempt online navigation if that fails, and attempt re-visioning if that also fails. However, this is merely an example, and the execution order of online navigation, offline navigation, and re-visioning can be configured in various ways. Additionally, a parameter may be included indicating whether this linkage can be executed automatically when online navigation, offline navigation, and re-visioning are executed in any arbitrary order.Alternatively, it may include a factor including whether user consent must be obtained whenever a linkage occurs when online movement, offline movement, and re-visioning are executed in any order.

[0317] In addition, as another example of the aforementioned factor, a factor may be included regarding whether the terminal transmitting the profile must perform authentication using information received from the telecommunications carrier and / or RSP server when authenticating the terminal receiving the profile. That is, the telecommunications carrier and / or RSP server provide authentication information related to the terminal and / or eUICC that they can trust and / or verify, and the terminal transmitting the profile can use said information to authenticate whether the terminal and / or eUICC receiving the profile is a terminal and / or eUICC that the telecommunications carrier and / or RSP server can trust.

[0318] Referring to FIG. 13, a profile to be transmitted at step 13000 can be selected. This selection process may be achieved by the user directly selecting a profile through a User Interface (UI) provided by the first terminal (1300), or by inputting it to the first terminal (1300) via a push input from a remote server, or by the first terminal (1300) connecting to a remote server to read the information. When the first terminal (1300) provides a UI to the user, a list of all profiles installed on the terminal may be provided through this UI, or only a list of profiles that are currently movable may be provided. If a list of profiles that are not currently movable is provided, additional information indicating the movability of the profiles shown in the list may be provided. Furthermore, in addition to the list of profiles described above, information such as profile information or profile movement policies may be optionally provided through the UI.

[0319] At step 13000, the first terminal (1300) can check the 'profile transfer settings' to determine whether the profile can be transferred. Additionally, the first terminal (1300) can check the 'profile transfer settings' to select a method for transferring the profile. For example, the first terminal (1300) can select a direct connection between the first terminal (1300) and the second terminal (1350) as a method for transferring the profile. Examples of possible direct connections at this time may include Bluetooth, Wi-Fi, NFC, etc. Additionally, the first terminal (1300) can select a remote connection between the first terminal (1300) and the second terminal (1350) as a method for transferring the profile. For example, a relay server may exist between the first terminal (1300) and the second terminal (1350). At this time, the relay server may be a single and / or multiple RSP servers. Alternatively, the relay server may be any server used for single and / or multiple message delivery. Alternatively, the relay server may be a combination of single and / or multiple RSP servers and any server used for single and / or multiple message delivery.

[0320] Referring to FIG. 13, a connection may be established between the first terminal (1300) and the second terminal (1350) in step 13005. The connection between the first terminal (1300) and the second terminal (1350) may be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE D2D (device-to-device), 5G D2D) or a remote connection in which a remote server (e.g., a relay server) is located between the first terminal (1300) and the second terminal (1350).

[0321] Referring to FIG. 13, in step 13010, the second terminal (1350) may transmit its eUICC information (eUICC2.Info1). eUICC2.Info1 may include an arbitrary string (eUICC2.Challenge) generated by the eUICC of the second terminal. eUICC2.Info1 may include information(s) of the version supported by the eUICC of the second terminal. eUICC2.Info1 may include 'certificate information(s) that can be used to verify the eUICC of the second terminal.' eUICC2.Info1 may include 'certificate information(s) that can be used to verify the eUICC of another terminal.

[0322] Referring to FIG. 13, in step 13015, the first terminal (1300) can check the received eUICC2.Info1. The first terminal (1300) can use the received eUICC2.Info1 to check whether there is a version supported by itself among the eUICC versions supported by the second terminal. The first terminal (1300) can use the received eUICC2.Info1 to select a certificate eUICC1.Cert that can verify itself. The first terminal (1300) can use the received eUICC2.Info1 to select certificate information to be used by the second terminal (1350).

[0323] In step 13015, the first terminal (1300) may generate “first terminal authentication information (Device1.Auth).” “First terminal authentication information (Device1.Auth)” may include at least part or all of eUICC2.Info1. For example, it may include eUICC2.Challenge that was received. The first terminal authentication information (Device1.Auth) may include any string (eUICC1.Challenge) generated by the eUICC of the first terminal.

[0324] “First terminal authentication information (Device1.Auth)” may include certificate information to be used to verify the second terminal. “First terminal authentication information (Device1.Auth)” may include a certificate eUICC1.Cert capable of verifying itself and related certificate chain information.

[0325] Part and / or all of the “first terminal authentication information (Device1.Auth)” described above may be digitally signed using the certificate eUICC1.Cert of the first terminal, and this digitally signed data may be included as part of the “first terminal authentication information (Device1.Auth).”

[0326] Referring to FIG. 13, in step 13020, the first terminal (1300) can transmit “first terminal authentication information (Device1.Auth)” to the second terminal (1350).

[0327] Referring to FIG. 13, at step 13025, the second terminal (1350) can verify the received “first terminal authentication information (Device1.Auth).” The second terminal (1350) can check the validity of eUICC1.Cert included in the “first terminal authentication information (Device1.Auth)” and can further check the validity of the signature included in the “first terminal authentication information (Device1.Auth)” using eUICC1.Cert. The second terminal (1350) can check whether the value of eUICC2.Challenge included in the “first terminal authentication information (Device1.Auth)” is the same as the value of eUICC2.Challenge that it transmitted at step 13010.

[0328] The second terminal (1350) can generate “second terminal authentication information (Device2.Auth).” “Second terminal authentication information (Device2.Auth)” may include at least part or all of Device1.Auth. For example, it may include the received eUICC1.Challenge. “Second terminal authentication information (Device2.Auth)” may include eUICC2.Info2, which is information for checking the eligibility of the eUICC installed on the second terminal. eUICC2.Info2 may be information used to determine whether a profile to be received from the first terminal later can be properly installed and operated on the eUICC of the second terminal. For example, eUICC2.Info2 may include hardware and / or software information of the eUICC mounted on the second terminal.

[0329] “Device2.Auth” may include a certificate eUICC2.Cert capable of verifying itself and related certificate chain information.

[0330] Part and / or all of the previously described “Device2.Auth” may be digitally signed using the certificate eUICC2.Cert of the second terminal, and this digitally signed data may be included as part of the “Device2.Auth”.

[0331] Referring to FIG. 13, in step 13030, the second terminal (1350) can transmit “second terminal authentication information (Device2.Auth)” to the first terminal (1300).

[0332] Referring to FIG. 13, at step 13035, the first terminal (1300) can verify the received “second terminal authentication information (Device2.Auth).” The first terminal (1300) can check the validity of eUICC2.Cert included in the “second terminal authentication information (Device2.Auth)” and can use eUICC2.Cert to check the validity of the signature included in the “second terminal authentication information (Device2.Auth).” The first terminal (1300) can check whether the value of eUICC1.Challenge included in the “second terminal authentication information (Device2.Auth)” is the same as the value of eUICC1.Challenge that it transmitted at step 13020.

[0333] The first terminal (1300) can determine whether the profile to be transmitted can be properly installed and operated on the eUICC of the second terminal by checking the eUICC2.Info2 information for checking the eUICC's eligibility, which is included in the "second terminal authentication information (Device2.Auth)".

[0334] Referring to FIG. 13, in step 13040, the first terminal (1300) can transmit a profile package to the second terminal (1350). The second terminal (1350) can install the received profile package.

[0336] FIG. 14 is a diagram illustrating a procedure in which a terminal requests approval from an RSP server for profile transmission while performing the procedure presented in FIG. 13.

[0337] The terminal (1450) described in this drawing may be the first terminal (1300) described in FIG. 13.

[0338] The “profile transfer setting” described in FIG. 13 may include a parameter that determines whether permission from a telecommunications carrier and / or RSP server is required when transferring a profile between devices. If permission from a telecommunications carrier and / or RSP server is required for the transfer of a profile between devices, the process of obtaining permission may be performed as part of steps 13015 and / or 13035 of FIG. 13. However, the process of obtaining permission from the telecommunications carrier and / or RSP server does not necessarily have to be performed as part of steps 13015 and / or 13035, but may be performed at any moment during the procedure presented in FIG. 13. Information on at what moment permission from the telecommunications carrier and / or RSP server must be obtained may also be included as part of the “profile transfer setting.”

[0339] If approval from a telecommunications carrier and / or RSP server is required when the profile is transmitted between devices, the following process may be performed as part of steps 13000 and / or 13015 and / or 13035 of FIG. 13.

[0340] Referring to FIG. 14, a connection can be established between the RSP server (1400) and the terminal (1450) at step 14000.

[0341] Referring to FIG. 14, in step 14005, the terminal (1450) can send the information eUICC2.Info of the second terminal (1350) to receive the profile to the RSP server (1400).

[0342] If the process of FIG. 14 is carried out at step 13015 of FIG. 13, eUICC2.Info may contain some and / or all information of eUICC2.Info1 described in FIG. 13.

[0343] If the process of FIG. 14 is performed at step 13035 of FIG. 13, eUICC2.Info may include some and / or all information of eUICC2.Info1 described in FIG. 13. Additionally, it may further include some and / or all information of eUICC2.Info2 described in FIG. 13.

[0344] In step 14005, the terminal (1450) may optionally transmit additional information of the profile that it intends to transmit to the second terminal (1350) to the RSP server (1400). The information of the profile may include, for example, an identifier of the profile (ICCID) and / or profile summary information (Profile Metadata).

[0345] Referring to FIG. 14, in step 14010, the RSP server (1400) can check the received eUICC2.Info and perform the following process.

[0346] The RSP server (1400) can determine whether the second terminal (1350) is a target capable of mutual verification with itself by using the received eUICC2.Info. For example, the RSP server (1400) can determine whether mutual authentication with the second terminal (1350) is possible by using the information of eUICC2.Info1 included in eUICC2.Info.

[0347] The RSP server (1400) can determine whether the profile can be properly installed and operated on the second terminal (1350) using the received eUICC2.Info. For example, the RSP server (1400) can determine whether the profile can be properly installed and operated on the second terminal (1350) by using the information of eUICC2.Info2 included in eUICC2.Info and the information of the received profile.

[0348] Referring to FIG. 14, in step 14015, the RSP server (1400) can transmit an approval judgment result to the terminal (1450). For example, the RSP server (1400) can transmit a message to the terminal (1450) indicating that the profile transmission has been approved. As another example, the RSP server (1400) can transmit a message to the terminal (1450) indicating that the profile transmission has not been approved. At this time, the message sent from the RSP server (1400) to the terminal (1450) can be digitally signed using the RSP server's certificate, and this digitally signed value can be transmitted to the terminal (1450) together.

[0350] FIG. 15 is a diagram conceptually illustrating a procedure for transmitting a profile from one terminal to another terminal according to an embodiment of the present disclosure.

[0351] According to various embodiments, the terminal may include at least one LPA and at least one eSIM. For example, as in the example of FIG. 15, the first terminal (1510) may include a first LBA (1530) and a first eSIM (1520), and the second terminal (1560) may include a second LPA (1580) and a second eSIM (1570).

[0352] Referring to FIG. 15, at step 15000, the first LPA (1530) of the first terminal (1510) and the second LPA (1570) of the second terminal (1560) can perform a preparation procedure (profile transmission preparation procedure) necessary for profile transmission. For a more detailed description of the procedure, refer to the detailed description of FIG. 16 to be described later.

[0353] Referring to FIG. 15, a mutual authentication process may be performed between the first terminal (1510) and the second terminal (1560) in step 15005. For a more detailed description of the above procedure, refer to the detailed description of FIG. 17 to be described later.

[0354] Referring to FIG. 15, in step 15010, a procedure may be performed in which a profile is transmitted from a first terminal (1510) to a second terminal (1560) and the transmitted profile is installed on the second terminal. For a more detailed description of the above procedure, refer to the detailed description of FIG. 18 to be described later.

[0356] FIG. 16 is a drawing illustrating a detailed procedure for preparing for profile transmission among the procedures presented in FIG. 15 according to an embodiment of the present disclosure.

[0357] Referring to FIG. 16, the terminal may include at least one LPA and at least one eSIM. For example, the first terminal (1610) may include a first LPA (1630) and a first eSIM (1620), and the second terminal (1660) may include a second LPA (1680) and a second eSIM (1670).

[0358] According to various embodiments, the first terminal (1610) may possess a pre-installed profile and may additionally possess metadata associated with the pre-installed profile. According to various embodiments, the first terminal (1610) may possess a 'profile identifier' associated with the pre-installed profile.

[0359] According to various embodiments, the first terminal (1610) may possess a 'profile transfer setting' related to a pre-installed profile. According to various embodiments, the 'profile transfer setting' is a series of policies related to the transfer of the profile between devices, which may be generated by a telecommunications carrier, generated by an RSP server, or generated through collaboration between the aforementioned telecommunications carrier and the RSP server. According to various embodiments, the 'profile transfer setting' within the terminal may be updated by the telecommunications carrier, the RSP server, or through collaboration between the telecommunications carrier and the RSP server. Alternatively, the terminal may collaborate with at least one entity among the telecommunications carrier and the RSP server to update the 'profile transfer setting'. The timing and / or method of updating the 'profile transfer setting' may be determined by policies of the telecommunications carrier, the RSP server, the terminal manufacturer, etc.

[0360] The 'Profile Transfer Setting' may include a factor (or indication) indicating whether the transfer of the corresponding profile between devices is allowed. Additionally, the 'Profile Transfer Setting' may optionally include a factor specifying the conditions under which transfer is permitted if the transfer of the corresponding profile between devices is allowed.

[0361] For example, the form of a possible connection for device-to-device transmission may be included. In this case, the connection allowed for device-to-device transmission may be a direct device-to-device connection (e.g., a wireless connection such as NFC, Bluetooth, UWB, WiFi-Direct, LTE D2D (device-to-device), 5G D2D, or a wired connection via cable) or a remote connection in which a remote server (e.g., a relay server) is located between the first LPA (1630) and the second LPA (1690).

[0362] As another example, the format in which the profile can be transmitted may be configured. For instance, the profile may be transmitted in the form of a profile package or in the form of a profile image. The profile transfer settings may include information regarding which method(s) among the possible transmission forms of the aforementioned profile are permitted.

[0363] The aforementioned factors may be digitally signed by at least one entity among the RSP server, the telecommunications operator, the terminal manufacturer, the eUICC, and the eUICC manufacturer. The digitally signed value may be stored in the first terminal as part of the 'profile transfer setting' or together with the 'profile transfer setting'.

[0364] Referring to FIG. 16, at step 16000, the first LPA (1630) can obtain information about the profile to be transmitted. Alternatively, information about the profile to be transmitted may be delivered to the first LPA (1630). For example, the first LPA (1630) may obtain information about the profile to be transmitted by receiving user input in which a user selects a profile through a UI provided by the first terminal (1610), or information about the profile to be transmitted may be input to the first LPA (1630) via a push input from a remote server, or the first LPA (1630) may connect to a remote server to read information about the profile to be transmitted.

[0365] Referring to FIG. 16, in step 16005, the first LPA (1630) can check whether the profile can be transmitted using the 'profile transfer setting'. Additionally, the first LPA (1630) can check the 'profile transfer setting' to determine the type of connection available for the transfer of the profile between devices. Additionally, the first LPA (1630) can check the 'profile transfer setting' to determine in what form (profile image, profile package) the profile can be transmitted.

[0366] Referring to FIG. 16, in step 16010, the first LPA (1630) may generate a 'profile transmission code'. The profile transmission code may include a 'profile identifier' of the profile to be transmitted. Additionally, the profile transmission code may include the address of an RSP server associated with the profile to be transmitted. Additionally, the profile transmission code may include other information indicating the attributes of the profile (e.g., metadata of the profile or part of the metadata). Additionally, the profile transmission code may include information necessary for the connection between two terminals to be made in step 16020. For example, it may include information necessary for the Wi-Fi connection between the two terminals (e.g., the SSID and / or BSSID of the second terminal (1660), a Pre Shared Key to be used for authentication of the connection between the two terminals, the IP address of the second terminal (1660), and a port number to be used for communication between the two terminals).

[0367] Referring to FIG. 16, in step 16015, the profile transmission code generated in step 16010 can be transmitted from the first LPA (1630) to the second LPA (1680). The profile transmission code can be transmitted in various ways.

[0368] For example, the first LPA (1630) can provide information to be transmitted to the second LPA (1680) to the first user of the first terminal (1610) through the UI of the first terminal (1610). The first user can provide the received information to the second user of the second terminal (1660). The second user can input the received information into the second LPA (1680) using the UI of the second terminal (1660).

[0369] Alternatively, the first LPA (1630) may create information to be transmitted to the second LPA (1680) in the form of an image (e.g., a QR code) and display it on the screen of the first terminal (1610), and the second user may transmit information to the second LPA (1680) by scanning the image displayed on the screen of the first terminal (1610) using the second terminal (1660).

[0370] Alternatively, the first LPA (1630) may establish a connection between the first LPA (1630) and the second LPA (1680) and use this established connection to transmit information to be transmitted. In this case, the connection established between the first LPA (1630) and the second LPA (1680) may be a direct device-to-device connection (e.g., wireless connection such as NFC, Bluetooth, UWB, WiFi-Direct, LTE D2D (device-to-device), 5G D2D, and wired connection such as a cable connection) or a remote connection in which a remote server (e.g., a relay server) is located between the first LPA (1630) and the second LPA (1680).

[0371] Referring to FIG. 16, a connection may be established (or configured) between the first LPA (1630) and the second LPA (1680) in step 16020. If information necessary for the connection is transmitted in step 16015, the first LPA (1630) and the second LPA (1680) may use this information to establish the connection. The connection between the first LPA (1630) and the second LPA (1680) may be a direct device-to-device connection (e.g., a wireless connection such as NFC, Bluetooth, UWB, WiFi-Direct, LTE D2D (device-to-device), 5G D2D, or a wired connection via cable) or a remote connection where a remote server (e.g., a relay server) is located between the first LPA (1630) and the second LPA (1680).

[0373] FIG. 17 is a diagram illustrating a detailed procedure in which mutual authentication is performed between a first terminal (1510) and a second terminal (1560) among the procedures presented in FIG. 15 according to an embodiment of the present disclosure.

[0374] Referring to FIG. 17, the terminal may include at least one LPA and at least one eSIM. For example, the first terminal (1710) may include a first LPA (1730) and a first eSIM (1720), and the second terminal (1760) may include a second LPA (1780) and a second eSIM (1770).

[0375] Referring to FIG. 17, at step 17000, the second LPA (1780) can request Euicc2.Info1 from the second eSIM (1770).

[0376] Referring to FIG. 17, in step 17005, the second eSIM (1770) can form Euicc2.Info1. Euicc2.Info1 may include the following information.

[0377] - Certificate information that the first eSIM can use to verify the second eSIM

[0378] - Certificate information that the second eSIM can use to verify the first eSIM

[0379] - Version information supported by the second terminal

[0380] Additionally, the second eSIM can provide Euicc2.Info1 to the second LPA (1780).

[0381] Referring to FIG. 17, in step 17010, the second LPA (1780) can request Euicc2.Challenge from the second eSIM (1770).

[0382] Referring to FIG. 17, in step 17015, the second eSIM (1770) can generate Euicc2.Challenge. Euicc2.Challenge may be any random number generated by the second eSIM (1770). The second eSIM (1770) can provide Euicc2.Challenge to the second LPA (1780).

[0383] Referring to FIG. 17, in step 17020, the second LPA (1780) can provide Euicc2.Info1 to the first eSIM (1720) via the first LPA (1730). Additionally, the second LPA (1780) can provide Euicc2.Challenge to the first eSIM (1720) via the first LPA (1730). At this time, the first LPA (1730) can further provide a 'profile identifier' of the profile to be transmitted to the first eSIM (1720).

[0384] Referring to Fig. 17, the following process can be performed in step 17025.

[0385] The first eSIM (1720) can select the certificate Euicc1.Certificate to use by using the ‘certificate information that the second eSIM can use to verify the first eSIM’ included in Euicc2.Info1.

[0386] The first eSIM (1720) can select a certificate to be used by the second eSIM (1770) using the ‘certificate information that the first eSIM can use to verify the second eSIM’ included in Euicc2.Info1. At this time, the selected certificate information or information that can refer to the selected certificate may be called euiccCiPKIdToBeUsed.

[0387] The first eSIM (1720) can check the 'profile transfer settings' of the profile associated with the received profile identifier. The first eSIM (1720) can check whether the profile can be transferred via device-to-device transfer.

[0388] The first eSIM (1720) can check the version information supported by the second terminal included in Euicc2.Info1 to see if there is a version supported by itself among them.

[0389] The first eSIM (1720) can generate a transaction ID that is used to refer to future communication with the second eSIM.

[0390] The first eSIM (1720) can generate Euicc1.Challenge. Euicc1.Challenge may be any random number generated by the first eSIM (1720).

[0391] The first eSIM (1720) can digitally sign all and / or some of the values ​​below. The digital signature can be performed using Euicc1.Certificate.

[0392] - Transaction ID

[0393] - Euicc1.Challenge

[0394] - Euicc2.Challenge

[0395] The first eSIM (1720) can transmit all and / or part of the following data to the second LPA (1780) via the first LPA (1730).

[0396] - Transaction ID and / or Euicc1.Challenge and / or Euicc2.Challenge and their digital signature values

[0397] - euiccCiPKIdToBeUsed

[0398] - Euicc1.Certificate

[0399] The data provided above may be referred to as Device1.Auth1.

[0400] Referring to FIG. 17, in step 17030, the second LPA (1780) can transmit all and / or part of the following data to the second eSIM (1770).

[0401] - Device1.Auth1

[0402] - Profile identifier of the profile that the first terminal intends to transmit to the second terminal

[0403] Referring to Fig. 17, the following process can be performed in step 17035.

[0404] The second eSIM (1770) can verify the validity of Euicc1.Certificate.

[0405] The second eSIM (1770) can verify the digital signature value included in Device1.Auth1.

[0406] The second eSIM (1770) can check whether the Euicc2.Challenge included in Device1.Auth1 is the same value as the Euicc2.Challenge that it transmitted in step 17020.

[0407] The second eSIM (1770) can select the certificate Euicc2.Certificate to use by using euiccCiPKIdToBeUsed.

[0408] The second eSIM (1770) can digitally sign all and / or parts of the following values. The digital signature can be performed using Euicc2.Certificate.

[0409] - Transaction ID

[0410] - Euicc1.Challenge

[0411] - Euicc2.Info2. Herein, Euicc2.Info2 may be information that can be used to perform an eligibility check on whether the 'profile transmitted by the first terminal to the second terminal' can be installed and operated on the second terminal. For example, Euicc2.Info2 may include hardware and / or software information of the second eSIM.

[0412] - Profile identifier of the profile that the first terminal intends to transmit to the second terminal

[0413] The second eSIM (1770) can transmit all and / or part of the following data to the first eSIM (1720) via the second LPA (1780) and the first LPA (1730).

[0414] - Transaction ID and / or Euicc1.Challenge and / or Euicc2.Info2 and / or 'profile identifier of the profile that the first terminal intends to transmit to the second terminal' and their digital signature values

[0415] - Euicc2.Certificate

[0416] The above data may be referred to as Device2.Auth1.

[0418] FIG. 18 is a diagram illustrating a detailed procedure in which a profile is transmitted from a first terminal (1810) to a second terminal (1860) and the transmitted profile is installed on the second terminal, among the procedures presented in FIG. 15 according to an embodiment of the present disclosure.

[0419] Referring to FIG. 18, the terminal may include at least one LPA and at least one eSIM. For example, the first terminal (1810) may include a first LPA (1830) and a first eSIM (1820), and the second terminal (1860) may include a second LPA (1880) and a second eSIM (1870).

[0420] Referring to Fig. 18, the following process can be performed at step 18000.

[0421] The first eSIM (1820) can verify the validity of Euicc2.Certificate.

[0422] The first eSIM (1820) can verify the digital signature value included in Device2.Auth1.

[0423] The first eSIM (1820) can check whether the Euicc1.Challenge included in Device2.Auth1 is the same value as the Euicc1.Challenge that it transmitted in step 17025.

[0424] The first eSIM (1820) can identify the profile it intends to transmit by checking the profile identifier included in Device2.Auth1. Alternatively, it can check whether the profile identifier included in Device2.Auth1 matches the profile identifier received in step 17020.

[0425] The first eSIM (1820) can check the 'profile transfer settings' of the profile associated with the received profile identifier. The first eSIM (1820) can check whether the profile can be transferred via device-to-device transfer. The first eSIM (1820) can check how the profile can be transferred via device-to-device transfer. The first eSIM (1820) can check whether the profile can be transferred in any form (e.g., profile image and / or profile package).

[0426] The first eSIM (1820) can perform an eligibility check to see if the profile can be properly installed and operated on the second terminal (e.g., the second eSIM). At this time, a profile identifier and Euicc2.Info2 may be used for the eligibility check.

[0427] Through the aforementioned processes, the first eSIM (1820) can determine in what form the profile can be transmitted and then use this value to create a transferOption. The transferOption may include information on which form(s) the profile can be transmitted in among the following methods.

[0428] - Profile Image

[0429] - Profile Package

[0430] The first eSIM (1820) can digitally sign all and / or some of the values ​​below. The digital signature can be performed using Euicc1.Certificate.

[0431] - Transaction ID

[0432] - transferOption

[0433] The first eSIM (1820) can transmit a Transaction ID and / or TransferOption and their digital signature values ​​to the second eSIM (1870) via the first LPA (1830) and the second LPA (1880). The value transmitted at this time may be called Device1.Auth2.

[0434] The first terminal (1810) can check the received transferOption and obtain user consent for the profile to be transmitted in that form.

[0435] Referring to Fig. 18, the following process can be performed in step 18005.

[0436] The second eSIM (1870) can verify the digital signature value included in Device1.Auth2.

[0437] The second eSIM (1870) can check the transferOption to see what form the profile will be transferred to it.

[0438] The second eSIM (1870) can generate its own encryption key pair (e.g., public key otPK.EUICC2.KA and the corresponding private key otSK.EUICC2.KA) necessary for generating a session key to be used for encrypted communication with the first eSIM (1820).

[0439] The second eSIM (1870) can digitally sign all and / or some of the values ​​below. The digital signature can be performed using Euicc2.Certificate.

[0440] - Transaction ID

[0441] - otPK.EUICC2.KA

[0442] The second eSIM (1870) can transmit the Transaction ID and / or otPK.EUICC2.KA and their digital signature values ​​to the first eSIM (1820) via the second LPA (1880) and the first LPA (1830). The value transmitted at this time may be called Device2.Auth2.

[0443] Referring to Fig. 18, the following process can be performed in step 18010.

[0444] The first eSIM (1820) can verify the digital signature value included in Device2.Auth2.

[0445] The first eSIM (1820) can generate its own encryption key pair (e.g., public key otPK.EUICC1.KA and the corresponding private key otSK.EUICC1.KA) necessary for generating a session key to be used for encrypted communication with the second eSIM (1870).

[0446] The first eSIM (1820) can generate a session key for encrypted communication with the second terminal (1860) using the otSK.EUICC1.KA it generated and the otPK.EUICC2.KA it received.

[0447] The first eSIM (1820) may prepare a profile image and / or a profile package to be transmitted to the second terminal (1860). The prepared profile image or profile package may be called a bound profile package or a bound profile image. Additionally, the bound profile package and the bound profile image may be collectively referred to as a bound profile.

[0448] During this preparation process, all and / or part of the 'profile image and / or profile package to be transmitted' may be encrypted by a previously generated session key. Additionally, all and / or part of the 'profile image and / or profile package to be transmitted' may be digitally signed using Euicc1.Certificate, and this value may be included as part of the Bound Profile. Additionally, otPK.EUICC1.KA may be included as part of the Bound Profile.

[0449] The first eSIM (1820) can transmit a Bound Profile to the second LPA (1880) via the first LPA (1830). At this time, metadata associated with the profile may be transmitted together. The metadata may be included as part of the Bound Profile or may be transmitted as data separate from the Bound Profile.

[0450] The first eSIM (1820) can delete the corresponding profile.

[0451] Referring to Fig. 18, the following process can be performed in step 18015.

[0452] The second terminal (1860) can check the transmitted metadata.

[0453] The second terminal (1860) may obtain user consent regarding the installation of the received Bound Profile.

[0454] The second terminal (1860) can install the received Bound Profile on the second eSIM (1870). This process can be carried out through collaboration between the second LPA (1880) and the second eSIM (1870). In this process, if there is encrypted data in the Bound Profile, the second eSIM (1870) can generate a session key using otSK.EUICC2.KA and otPK.EUICC1.KA, and then decrypt the data using this key. Additionally, if the Bound Profile contains an electronic signature value, the second eSIM (1870) can verify the validity of the electronic signature value using Euicc1.Certificate.

[0456] In the specific embodiments of the present disclosure described above, the components included in the disclosure are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed of a singular form, and even if a component is expressed in the singular form, it may be composed of a plural form.

[0457] Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, it is understood that various modifications are possible within the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof.

[0458] The various embodiments of the present disclosure and the terms used therein are not intended to limit the technology described in the present disclosure to specific embodiments and should be understood to include various modifications, equivalents, and / or substitutions of such embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar components. A singular expression may include a plural expression unless the context clearly indicates otherwise. In the present disclosure, expressions such as "A or B," "at least one of A and / or B," "A, B or C," or "at least one of A, B and / or C" may include all possible combinations of items listed together. Expressions such as "first," "second," "first," or "second" may modify the components, regardless of order or importance, and are used only to distinguish one component from another and do not limit the components. Where it is stated that a certain (e.g., first) component is "(functionally or telecommunicationally) connected" or "connected" to another (e.g., second) component, said certain component may be directly connected to said other component or connected through another component (e.g., third component).

[0459] As used in this disclosure, the term "module" includes a unit composed of hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be a component formed integrally, or a minimum unit or part thereof that performs one or more functions. For example, a module may be composed of an application-specific integrated circuit (ASIC).

[0460] Various embodiments of the present disclosure may be implemented as software (e.g., a program) containing instructions stored in a machine-readable storage medium (e.g., internal memory or external memory) that is readable by a machine (e.g., a computer). The machine may include a terminal according to various embodiments, which is a device capable of calling instructions stored from the storage medium and operating according to the called instructions. When the instructions are executed by a processor (e.g., the processor (920) of FIG. 9), the processor may perform a function corresponding to the instructions directly or using other components under the control of the processor. The instructions may include code generated or executed by a compiler or an interpreter.

[0461] A device-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' means merely that the storage medium does not contain a signal and is tangible, without distinguishing whether data is stored semi-permanently or temporarily on the storage medium.

[0462] Methods according to the various embodiments disclosed herein may be provided as part of a computer program product. The computer program product may be traded between a seller and a buyer as a product. The computer program product may be distributed online in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)) or through an application store (e.g., Play Store™). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created in a storage medium such as the memory of a manufacturer's server, an application store's server, or a relay server. Each component (e.g., a module or program) according to the various embodiments may be composed of a singular or multiple entities, and some of the aforementioned sub-components may be omitted, or other sub-components may be further included in the various embodiments. Generally or additionally, some components (e.g., a module or program) may be integrated into a single entity to perform the same or similar functions as those performed by each of the respective components prior to integration. Operations performed by a module, program, or other component according to various embodiments may be executed sequentially, in parallel, iteratively, or heuristically, or at least some operations may be executed in a different order, omitted, or other operations may be added.

Claims

Claim 1 A method performed by a first smart secure platform (SSP), comprising: transmitting a bundle transfer code to be used for transmitting a secondary platform bundle (SPB) to a second smart secure platform; receiving information about the second smart secure platform from the second smart secure platform; after receiving information about the second smart secure platform, transmitting first authentication information for authentication of the first smart secure platform to the second smart secure platform; receiving second authentication information for authentication of the second smart secure platform and the bundle transfer code from the second smart secure platform; and verifying the second authentication information based on certificate negotiation information included in the second authentication information. A method comprising the step of transmitting the secondary platform bundle to a second smart security platform when the second authentication information is verified, wherein the second authentication information is generated based on the verification result of the first authentication information, and the secondary platform bundle includes a bundle family identifier (SPB family identifier) ​​and a bundle family manager identifier (SPB family custodian object identifier) ​​for identifying the entity managing the bundle family identifier. Claim 2 A method according to claim 1, further comprising: a step of identifying whether to generate a bundle transfer code to be used for the transmission of the secondary platform bundle; and a step of generating the bundle transfer code based on the identification. Claim 3 delete Claim 4 A method according to claim 1, wherein the step of verifying the second authentication information includes determining whether the transmission of the secondary platform bundle is allowed based on bundle transfer setting information associated with the secondary platform bundle, and if the transmission of the secondary platform bundle is allowed, the secondary platform bundle is transmitted to the second smart security platform. Claim 5 A method according to claim 4, wherein the bundle transfer setting information comprises at least one of bundle transfer policy information or bundle transfer history information. Claim 6 In paragraph 5, the method comprises the bundle transfer policy information including an indication indicating whether the transfer of the secondary platform bundle between devices is allowed. Claim 7 A method according to claim 5, wherein the bundle transfer history information comprises at least one of information regarding the date and time when the transfer of the secondary platform bundle occurred or information regarding the number of times the transfer of the secondary platform bundle occurred. Claim 8 A method according to claim 4, further comprising the step of updating the bundle transfer setting information. Claim 9 In a first smart secure platform (SSP), at least one transceiver; and at least one processor connected to the at least one transceiver so as to be able to communicate with the at least one transceiver; A memory storing instructions configured to be connected to communicate with at least one processor and executable individually or in any combination of the at least one processor, wherein the first smart security platform transmits a bundle transfer code to be used for transmitting a secondary platform bundle (SPB) to a second smart security platform; receives information about the second smart security platform from the second smart security platform; after receiving information about the second smart security platform, transmits first authentication information for authentication of the first smart security platform to the second smart security platform; receives second authentication information for authentication of the second smart security platform and the bundle transfer code from the second smart security platform; verifies the second authentication information based on certificate negotiation information included in the second authentication information; and, if the second authentication information is verified, transmits the secondary platform bundle to the second smart security platform; wherein the second authentication information is the first authentication A first smart security platform generated based on the verification results of information, wherein the secondary platform bundle includes a bundle family identifier (SPB family identifier) ​​and a bundle family manager identifier (SPB family custodian object identifier) ​​for identifying the entity managing the bundle family identifier. Claim 10 In claim 9, the first smart security platform further performs the steps of identifying whether the first smart security platform will generate a bundle transfer code to be used for the transmission of the secondary platform bundle, and generating the bundle transfer code based on the identification. Claim 11 delete Claim 12 In claim 9, the step of verifying the second authentication information includes the step of determining whether the transmission of the secondary platform bundle is allowed based on bundle transfer setting information associated with the secondary platform bundle, and if the transmission of the secondary platform bundle is allowed, the secondary platform bundle is transmitted to the second smart security platform, the first smart security platform. Claim 13 In paragraph 12, the first smart security platform, wherein the bundle transfer setting information includes at least one of bundle transfer policy information or bundle transfer history information. Claim 14 In paragraph 13, the bundle transfer policy information includes an indication indicating whether the transfer of the secondary platform bundle between devices is allowed, a first smart security platform. Claim 15 In paragraph 13, the bundle transfer history information comprises at least one of information on the date and time when the transfer of the secondary platform bundle occurred or information on the number of times the transfer of the secondary platform bundle occurred, in a first smart security platform. Claim 16 In paragraph 12, the above command enables the first smart security platform to further perform the step of updating the bundle movement setting information. Claim 17 A method performed by a second smart secure platform (SSP), comprising: receiving a bundle transfer code to be used for transferring a secondary platform bundle (SPB) from a first smart secure platform; transmitting information about the second smart secure platform to the first smart secure platform; receiving first authentication information for authenticating the first smart secure platform from the first smart secure platform after transmitting information about the second smart secure platform; verifying the first authentication information; generating second authentication information for authenticating the second smart secure platform based on the verification result of the first authentication information; and transmitting the second authentication information and the bundle transfer code to the first smart secure platform. A method comprising the step of receiving the secondary platform bundle from the first smart security platform when the second authentication information is verified, wherein the secondary platform bundle includes a bundle family identifier (SPB family identifier) ​​and a bundle family manager identifier (SPB family custodian object identifier) ​​for identifying the entity managing the bundle family identifier. Claim 18 In claim 17, the step of receiving the secondary platform bundle comprises: receiving bundle transfer setting information associated with the secondary platform bundle, a method. Claim 19 In a second smart secure platform (SSP), at least one transceiver; and at least one processor connected to the at least one transceiver so as to be able to communicate with the at least one transceiver; A memory storing instructions that are connected to communicate with at least one processor and can be executed individually or in any combination of the at least one processor, wherein the second smart security platform receives a bundle transfer code to be used for transferring a secondary platform bundle (SPB) from the first smart security platform; transmits information about the second smart security platform to the first smart security platform; after transmitting information about the second smart security platform, receives first authentication information for authenticating the first smart security platform from the first smart security platform; verifies the first authentication information; generates second authentication information for authenticating the second smart security platform based on the verification result of the first authentication information; transmits the second authentication information and the bundle transfer code to the first smart security platform; and, if the second authentication information is verified, receives the secondary platform bundle from the first smart security platform; wherein the secondary platform bundle is a bundle family identifier (SPB A second smart security platform comprising a bundle family identifier and a bundle family manager identifier (SPB family custodian object identifier) ​​for identifying the entity managing the bundle family identifier. Claim 20 In paragraph 19, the above command further enables the second smart security platform to perform the step of receiving a bundle transfer setting associated with the secondary platform bundle.

Images