Method and device for transferring a bundle between devices

Abstract

The present disclosure relates to: a communication technology for integrating IoT technology with a 5G communication system for supporting a higher data transmission rate than a 4G system; and a system thereof. The present disclosure can be applied to smart services (e.g., smart homes, smart buildings, smart cities, smart cars or connected cars, healthcare, digital education, retail enterprises, 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 when moving bundles between smart security media.

Description

Technical Field

[0001] The present disclosure relates to smart secure elements, and more particularly, to methods and apparatus for moving bundles between smart secure media. Background Art

[0002] In order to meet the demand for increased wireless data traffic since the deployment of 4G communication systems, efforts have been made to develop improved 5G or quasi-5G communication systems. Therefore, 5G or quasi-5G communication systems are also called "super 4G network" communication systems or "post-LTE" systems. 5G communication systems are considered to be implemented in ultra-high frequency (millimeter wave) bands (e.g., 60GHz bands) in order to achieve higher data rates. In order to reduce the propagation loss of radio waves and increase the transmission distance of ultra-high frequency bands, beamforming, massive multiple input multiple output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technology are discussed in 5G communication systems. In addition, in 5G communication systems, development of system network improvements is being carried out based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communications, wireless backhaul, mobile networks, collaborative communications, coordinated multi-point (CoMP), receiving-end interference elimination, etc. In 5G systems, hybrid frequency shift keying (FSK) and quadrature amplitude modulation (QAM) modulation (FQAM) and sliding window superposition coding (SWSC) have also been developed as advanced coding modulation (ACM), and filter bank multi-carrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies.

[0003] As a human-centered connected network in which people generate and consume information, the Internet is now evolving towards the Internet of Things (IoT), in which distributed entities (such as things) exchange and process information without human intervention. The Internet of Everything (IoE), which is a combination of IoT technology and big data processing technology through connection with cloud servers, has emerged. Because IoT implementation requires technical elements such as "sensing technology", "wired / wireless communication and network infrastructure", "service interface technology" and "security technology", sensor networks, machine-to-machine (M2M) communication, machine type communication (MTC), etc. have been studied recently. Such an IoT environment can provide intelligent Internet technology services that create new value for human life by collecting and analyzing data generated between connected things. IoT can be applied to various fields including smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, health care, smart appliances and advanced medical services through the integration and combination of existing information technology (IT) with various industrial applications.

[0004] In line with this, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, machine type communications (MTC), and machine-to-machine (M2M) communications can be implemented through beamforming, MIMO, and array antennas. Cloud radio access networks (RANs) as an application of the above-mentioned big data processing technologies can also be considered as an example of the fusion of 5G technology and IoT technology. Summary of the invention

[0005] Technical issues

[0006] The disclosed embodiments provide an apparatus and method capable of implementing a reliable bundle transfer service when a bundle between security modules included in two electronic devices is transferred.

[0007] Solution to the problem

[0008] In order to solve the technical problem, the present disclosure may have the following solutions.

[0009] A method of a first secure element according to one aspect of the present disclosure includes identifying a bundle to be sent to a second secure element; determining whether transmission of the bundle is allowed based on bundle transfer configuration information associated with the bundle; and sending the bundle to the second secure element based on the determination.

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

[0011] According to various embodiments, the method may further include sending the bundle transfer code to the second secure element.

[0012] According to various embodiments, the generating of the bundle transfer code includes generating the bundle transfer code when it is identified to generate the bundle transfer code, and the bundle transfer code is a preconfigured unique ID of the bundle or a new ID for identifying the bundle.

[0013] According to various embodiments, the bundle transmission configuration information may include at least one of bundle transmission policy information or bundle transmission history information.

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

[0015] According to various embodiments, the bundle transfer history information may include at least one of information on a date and time of bundle transfer or information on a number of bundle transfers.

[0016] According to various embodiments, an operation of updating bundle delivery configuration information may also be included.

[0017] According to another aspect of the present disclosure, a first security element includes: a transceiver; and at least one processor connected to the transceiver, wherein the at least one processor is configured to identify a bundle to be sent to a second security element, determine whether to allow transmission of the bundle based on bundle transfer configuration information related to the bundle, and send the bundle to the second security element based on the determination.

[0018] According to various embodiments, the at least one processor may be configured to identify whether to generate a bundle transfer code for sending the bundle and to generate the bundle transfer code based on the identification.

[0019] According to various embodiments, the at least one processor may be configured to send the bundle transfer code to the second secure element.

[0020] According to various embodiments, the generation of the bundle transfer code may include generating the bundle transfer code when it is identified to generate the bundle transfer code, and the bundle transfer code may be a preconfigured unique ID of the bundle or a new ID for identifying the bundle.

[0021] According to various embodiments, the bundle transmission configuration information may include at least one of bundle transmission policy information or bundle transmission history information.

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

[0023] According to various embodiments, the bundle transfer history information may include at least one of information on a date and time of bundle transfer or information on a number of bundle transfers.

[0024] According to various embodiments, the at least one processor may update the bundle delivery configuration information.

[0025] According to one aspect of the present disclosure, a method for a second security element may include: receiving a bundle transfer code for sending a bundle from a first security element; sending information about a second security element to the first security element; receiving first authentication information for authenticating the first security element from the first security element; verifying the first authentication information; based on a result of the verification, sending second authentication information and a bundle transfer code for authenticating the second security element to the first security element; and receiving the bundle from the first security element.

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

[0027] According to another aspect of the present disclosure, a second security element includes: a transceiver; and at least one processor connected to the transceiver, wherein the at least one processor is configured to receive a bundle transfer code for sending a bundle from the first security element, send information about the second security element to the first security element, receive first authentication information for authenticating the first security element from the first security element, verify the first authentication information, and based on a result of the verification, send second authentication information and a bundle transfer code for authenticating the second security element to the first security element, and receive the bundle from the first security element.

[0028] According to various embodiments, the receiving of the bundle may also include the receiving of a bundle delivery configuration associated with the bundle.

[0029] According to some embodiments of the present disclosure, an electronic device that sends a bundle may perform operations including selecting a bundle to be sent by a user or external input, checking whether the selected bundle can be sent through a "bundle transmission configuration", sending the "bundle transmission configuration" to an electronic device that receives the bundle, and updating the "bundle transmission configuration" as needed.

[0030] According to some embodiments of the present disclosure, an electronic device receiving a bundle may perform operations including receiving a “bundle delivery configuration” and updating the “bundle delivery configuration” as needed.

[0031] According to some embodiments of the present disclosure, an electronic device that sends a bundle may perform operations including selecting a bundle to be sent by a user or external input, binding a "bundle transfer code" with the bundle to be sent, sending the "bundle transfer code" to an electronic device that receives the bundle, and when a bundle transmission request from the electronic device that receives the bundle includes the "bundle transfer code", checking whether the "bundle transfer code" is valid or identifying the bundle to be sent through the "bundle transfer code".

[0032] According to some embodiments of the present disclosure, an electronic device receiving a bundle may perform operations including receiving a “bundle transfer code” and inserting the “bundle transfer code” into a bundle request made to an electronic device sending the bundle.

[0033] According to some embodiments of the present disclosure, two electronic devices may go through the certificate negotiation process described below to identify information used to authenticate each other, generate authentication information for verifying themselves, send authentication information to the other electronic device, and verify the received authentication information to verify the other electronic device.

[0034] According to some embodiments of the present disclosure, the electronic device that sends the bundle may send the bundle to the electronic device that receives the bundle, and the electronic device that receives the bundle may install the received bundle.

[0035] Advantageous Effects of the Invention

[0036] According to various embodiments of the present disclosure, a bundle installed in one device may be transmitted and installed in another device through a stable and efficient method. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 is a conceptual diagram illustrating an SSP according to an embodiment of the present disclosure.

[0038] Figure 2 is a conceptual diagram illustrating an internal structure of an SSP according to an embodiment of the present disclosure.

[0039] Figure 3 An example of elements in a terminal used by the terminal to download and install a bundle to an SSP according to an embodiment of the present disclosure is shown.

[0040] Figure 4 An example of a method according to an embodiment of the present disclosure is shown, by which two terminals interact with each other in order to send a bundle to each other.

[0041] Figure 5 A process of sending a bundle package from one terminal to another terminal according to an embodiment of the present disclosure is conceptually illustrated.

[0042] Figure 6 Shows Figure 5 The detailed process of bundle transfer preparation process is presented.

[0043] Figure 7 Shows Figure 5 The detailed process of the process of sending the bundle is shown.

[0044] Figure 8 Shows Figure 5 In the process shown, the detailed process of completing the transmission process after sending the bundle is described.

[0045] Fig. 9 The configuration of a terminal according to some embodiments of the present disclosure is shown.

[0046] Fig.10 is a flow chart illustrating a method of sending a bundle by a first secure element according to an embodiment of the present disclosure.

[0047] Fig.11 is a flow chart illustrating a method of receiving a bundle by a second secure element according to an embodiment of the present disclosure.

[0048] Fig.12 An example of a method according to an embodiment of the present disclosure is shown, by which two terminals interact with each other in order to send a configuration file to each other.

[0049] Fig.13 The diagram shows a process in which a terminal sends a configuration file to another terminal according to an embodiment of the present disclosure.

[0050] Fig.14 Shows that in the implementation Fig.13 The process shown is a process in which the terminal requests approval from the RSP server in order to send the configuration file.

[0051] Fig.15 The process of one terminal sending a configuration file to another terminal according to an embodiment of the present disclosure is conceptually illustrated.

[0052] Fig.16 Shows Fig.15 The detailed process of the configuration file transfer preparation process is shown in the process.

[0053] Fig.17 Shows Fig.15 In the process shown, a detailed process of mutual authentication is performed between two terminals.

[0054] Fig.18 Shows Fig.15 In the process shown, a terminal sends a configuration file to another terminal and installs the sent configuration file. DETAILED DESCRIPTION

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

[0056] When describing the embodiments of the present disclosure, descriptions related to technical contents that are well known in the art and not directly related to the present disclosure will be omitted. Such omission of unnecessary descriptions is intended to prevent the main concept of the present disclosure from being obscured and to convey the main concept more clearly.

[0057] For the same reason, in the accompanying drawings, some elements may be enlarged, omitted or schematically shown. In addition, the size of each element does not fully reflect the actual size. In the accompanying drawings, the same or corresponding elements have the same reference numerals.

[0058] By referring to the embodiments described in detail below in conjunction with the accompanying drawings, the advantages and features of the present disclosure and the ways to achieve them will become clear. However, the present disclosure is not limited to the embodiments set forth below, but can be implemented in various different forms. The following embodiments are provided only to fully disclose the present disclosure and inform those skilled in the art of the scope of the present disclosure, which is limited only by the scope of the attached claims. Throughout the specification, the same or similar reference numerals represent the same or similar elements.

[0059] Here, it should be understood that each box of the flowchart diagram and the combination of boxes in the flowchart diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine, so that the instructions run by the processor of the computer or other programmable data processing device create a component for implementing the function specified in one or more flowchart boxes. These computer program instructions can also be stored in a computer-available or computer-readable memory, which can instruct the computer or other programmable data device to operate in a particular manner, so that the instructions stored in the computer-available or computer-readable memory produce an article of instruction components including the functions specified in one or more flowchart boxes. The computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are performed on the computer or other programmable device, thereby generating a computer-implemented process, so that the instructions running on the computer or other programmable device provide steps for implementing the functions specified in one or more flowchart boxes.

[0060] In addition, each frame of the flowchart diagram can represent a module, segment or code portion, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions mentioned in the frame may not occur in order. For example, depending on the functions involved, two frames shown in succession can actually be run substantially simultaneously, or these frames can sometimes be run in reverse order.

[0061] As used herein, "unit" refers to a software element or a hardware element that performs a predetermined function, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). However, "unit" does not always have a meaning limited to software or hardware. "Unit" can be constructed to be stored in an addressable storage medium or to run one or more processors. Therefore, "unit" includes, for example, software elements, object-oriented software elements, class elements or task elements, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcodes, circuits, data, databases, data structures, tables, arrays and parameters. The elements and functions provided by "unit" can be combined into less number of elements or "units" or divided into more number of elements or "units". In addition, elements and "units" or can be implemented as reproducing one or more CPUs in equipment or secure multimedia cards.

[0062] In order to securely store security information and provide secure security services through the stored security information, the importance of secure media is gradually emphasized.

[0063] In particular, security elements can be installed in various electronic devices (smartphones, tablets, wearable devices, vehicles, IoT devices, etc.) due to their high security level, and are used for various services included in mobile communication network access, payment, and user authentication. Security elements can have various form factors, such as universal integrated circuit cards (UICCs), embedded secure elements (eSEs), and SD cards.

[0064] In particular, since the smart security platform (SSP) integrating UICC and eSE has multiple advantages such as efficiency of implementation space, enhancement of operation capability, and expansion of storage space, SSP has attracted attention as a next-generation security element. In addition, SSP is a security element suitable for implementing security functions required for 5G terminals and IoT terminals, so the importance of SSP is gradually emphasized.

[0065] Various applications are installed in the form of bundles and run in the SSP. Therefore, the importance of methods and devices for safely installing bundles in the SSP is emphasized. The method of installing a bundle in the SSP can be mainly divided into a method of receiving a bundle from an external server and a method of receiving a bundle from another electronic device.

[0066] The method of receiving a bundle from another electronic device (i.e., a method in which a bundle is sent from one secure element to another secure element) has the advantage of sending user information stored or configured in one secure element to a new secure element and using the user information, or the method does not require the assistance of an external entity in the process of sending the bundle, so this method has attracted attention as a next-generation bundle transmission technology.

[0067] Therefore, there is a need for a solution for securely moving a bundle from one secure element to another secure element, and there is a need to develop a method and apparatus for the solution.

[0068] Hereinafter, various embodiments of the present disclosure are described with reference to the accompanying drawings. Meanwhile, although each embodiment is described with SSP as an example of a security element, the scope of the present disclosure is not limited to SSP. For example, it is clear to those skilled in the art that the various embodiments described below can be substantially the same or similarly applied to another security element that performs the same or similar functions.

[0069] Specific terms used in the following description are intended to help understanding of the present disclosure, and the use of the specific terms may be modified in various forms without departing from the technical concept of the present disclosure.

[0070] A "Secure Element (SE)" is a security module of a single chip that is configured to store security information (e.g., mobile communication network access keys, user identity information such as ID cards / passports, credit card information, and encryption keys) and use the stored security information to install and operate a control module (e.g., a network access control module such as a USIM, an encryption module, or a key generation module). SEs can be used in a variety of electronic devices (e.g., smartphones, tablets, wearable devices, vehicles, and IoT devices), and can provide security services (e.g., mobile communication network access, payment, and user authentication) through security information and control modules.

[0071] SE can be divided into a universal integrated circuit card (UICC), an embedded security element (eSE), and an intelligent security platform into which UICC and eSE are integrated, and the type of SE can be divided into a removable type, an embedded type, and an integrated type. In the integrated type, SE is integrated into a specific element or a system on a chip (SoC) according to the form in which it is connected to or installed in an electronic device.

[0072] "Universal Integrated Circuit Card (UICC)" is a smart card inserted into a mobile communication terminal to be used, also known as a UICC card. The UICC may include an access control module for accessing the network of a mobile communication service provider. For example, the access control module may include a universal subscriber identity module (USIM), a subscriber identity module (SIM), and an IP multimedia service identity module (ISIM). A UICC including a USIM is generally referred to as a USIM card. Similarly, a UICC including a SIM module is generally referred to as a SIM card. At the same time, a SIM module may be installed when the UICC is manufactured, or a SIM of a mobile communication service that a user desires to use at a desired point in time may be downloaded to the UICC card. The UICC card may download and install multiple SIM modules, and select and use at least one of the SIM modules. The UICC card may be fixed or not fixed to the terminal. A UICC fixed to a terminal to be used is referred to as an embedded UICC (embedded UICC, eUICC), and in particular, a UICC embedded in a system on chip (SoC) is referred to as an integrated UICC (integrated UICC, iUICC), which includes a communication processor, an application processor, or a single processor structure in which two processors of the terminal are integrated. Generally, eUICC and iUICC can be fixed to the terminal to be used, and can be a UICC card that can remotely download and select a SIM module. In the present disclosure, a UICC that can remotely download and select a SIM module is collectively referred to as eUICC or iUICC. That is, among UICC cards that can remotely download and select a SIM module, UICC cards that are fixed or not fixed to a terminal are collectively referred to as eUICC or iUICC.

[0073] The term UICC in the present disclosure may be used interchangeably with the term SIM, and the term eUICC may be used interchangeably with the term eSIM.

[0074] "eUICC identifier (ID)" may be a unique identifier of an eUICC embedded in a terminal and may be referred to as an EID. In addition, when a provisioning profile is preinstalled in an eUICC, the eUICC ID may be an identifier (profile ID) of a corresponding provisioning profile. In addition, in an embodiment of the present disclosure, when the terminal and the eUICC chip are not separated from each other, the eUICC ID may be a terminal ID. In addition, the eUICC ID may refer to a specific security domain of the eUICC chip.

[0075] "Embedded Security Element (eSE)" is a fixed SE fixed to an electronic device to be used. Generally, eSE can be manufactured for a manufacturer only upon request of a terminal manufacturer, and can include an operating system and a framework when manufactured. eSE can remotely download and install a service control module in the form of an applet, and can be used for various security services such as e-wallets, ticketing, e-passports, and digital keys. In the present disclosure, a single-chip form SE embedded in an electronic device that can remotely download and install a service control module is collectively referred to as eSE.

[0076] "Smart Security Platform (SSP)" can support the functions of UICC and eSE in an integrated manner in a single chip, and can be divided into a removable SSP (rSSP) type, an embedded SSP (eSSP) type, and an integrated SSP (iSSP) type embedded in a SoC. The SSP may include a primary platform (PP) and at least one secondary platform bundle (SPB) operating in the PP, the primary platform including at least one of a hardware platform and a low-level operating system (LLOS), and the secondary platform bundle including at least one of a high-level operating system (HLOS) and an application running in the HLOS. The secondary platform bundle may be referred to as an SPB or a bundle. The bundle may access resources such as a central processing unit or a memory of the PP through a primary platform interface (PPI) provided by the PP, and operate in the PP through the PPI. Communication applications such as a Subscriber Identity Module (SIM), a Universal SIM (USIM), or an IP Multimedia SIM (ISIM) may be installed in the bundle, and various applications such as an electronic wallet, ticketing, an electronic passport, and a digital key may also be installed therein. In the present disclosure, the SSP may also be referred to as an intelligent security element.

[0077] Depending on the bundle downloaded or installed, the SSP can be used for UICC or eSE, and by installing and operating multiple bundles in a single SSP, UICC and eSE can be used interchangeably. That is, when a bundle including a profile is operated, the SSP can be used for the UICC to access the network of the mobile communication service provider. The corresponding UICC bundle can be operated by remotely downloading at least one profile to the bundle and selecting the profile like an eUICC or iUICC. In addition, when a bundle including a service control module having an application capable of providing services such as an electronic wallet, ticketing, an electronic passport, or a digital key is operated on the SSP, the SSP can be used for eSE. Multiple service control modules can be installed in one bundle for operation, or can be installed in a separate bundle for operation.

[0078] The SSP may download a bundle from an external bundle management server (a secondary platform bundle manager (SPB manager)) and install the bundle through an over-the-air (OTA) technology, or may receive a bundle from another terminal and install the bundle. In the present disclosure, the method of installing a downloaded or received bundle may be similarly applied to a removable SSP (rSSP) that may be inserted into or detached from a terminal, an embedded SSP (eSSP) installed in a terminal, and an integrated SSP (iSSP) included in a SoC installed in a terminal.

[0079] "SSP ID" may be a unique identifier of an SSP embedded in a terminal, and may be referred to as an sspID. Furthermore, in an embodiment of the present disclosure, when the terminal and the SSP chip are not separated from each other, the SSP ID may be a terminal ID. Furthermore, the SSP ID may be a specific bundle ID (SPB ID) within the SSP. More specifically, the SSP ID may refer to an identifier of a management bundle (used to install another bundle in the SSP and manage enabling, disabling, and deleting of the bundle) or a loader bundle (Secondary Platform Bundle Loader (SPBL)). An SSP may have multiple SSP IDs, and multiple SSP IDs may be values ​​derived from a single unique terminal SSP ID.

[0080] A "Secondary Platform Bundle (SPB)" operates using the PP resources in the Primary Platform (PP) of the SSP, for example, a UICC bundle may be a software package of applications, file systems, and authentication key values ​​stored in an existing UICC and an operating system (HLOS) for operating the UICC. In the present disclosure, an SPB may be referred to as a bundle.

[0081] In this disclosure, the "state" of a bundle may be described as follows.

[0082] [Enable]

[0083] In the present disclosure, the operation of enabling a bundle by a terminal or an external server may be an operation of changing the state of the corresponding SPB to an enabled state and allowing the terminal to receive services provided by the corresponding bundle (e.g., communication services through a communication service provider, credit card payment services, and user authentication services). A bundle in an enabled state may be represented as an "enabled bundle". An enabled bundle may be stored in a storage space inside or outside the SSP while being encrypted.

[0084] [Activity]

[0085] In the present disclosure, an enabled bundle may be changed to an active state according to an external input to the bundle (e.g., user input, push, request of an application within the terminal, request for authenticating a communication service provider, or PP management message) or an internal operation of the bundle (e.g., timer or polling). An active bundle may be loaded from a storage space inside or outside the SSP, from an internal drive memory of the SSP, and may process security information through a security control device (security CPU) within the SSP, and provide security services to the terminal.

[0086] [Disable]

[0087] In the present disclosure, the operation of disabling a bundle by a terminal or an external server may be an operation of changing the state of the corresponding bundle to a disabled state and preventing the terminal from receiving services provided by the corresponding bundle. A bundle in a disabled state may be represented as a "disabled bundle". A disabled bundle may be stored in a storage space inside or outside the SSP when encrypted.

[0088] [delete]

[0089] In the present disclosure, the operation of deleting a bundle by a terminal or an external server may be an operation of changing the state of the corresponding bundle to a deleted state or deleting the relevant data of the corresponding bundle including the corresponding bundle and preventing the terminal or the external server from activating, enabling or disabling the corresponding bundle again. A bundle in a deleted state may be represented as a "deleted bundle".

[0090] "Bundle image (or image)" may be used interchangeably with bundle and may be used as a term to indicate a data object of a specific bundle referred to as a bundle tag, length, and value (TLV) or a bundle image TLV. When a bundle image is encrypted using encryption parameters, the bundle image may be referred to as a protected bundle image (PBI) or a protected bundle image TLV (PBI TLV). When a bundle image is encrypted using encryption parameters that can be decrypted by a specific SSP, the bundle image may be referred to as a binding bundle image (BBI) or a binding bundle image TLV (BBI TLV). A bundle image TLV may be a data set that represents information included in a bundle in tag, length, and value (TLV) form.

[0091] "Bundle identifier" may be referred to as a factor that matches a bundle ID (SPB ID), a bundle family ID (SPB family ID), a bundle family manager ID (SPB family supervisor object ID), a bundle matching ID, or an event ID. SPB ID may indicate a unique ID for each bundle. SPB family ID may indicate an identifier used to identify a bundle type (e.g., a telecommunications bundle used to access a mobile communication service provider network). In the present disclosure, a bundle family ID may be referred to as spbFamilyId. A bundle family supervisor object ID may indicate an identifier used to identify an entity that manages an SPB family ID (e.g., a communication service provider, a terminal manufacturer, or a specific group). In the present disclosure, an SPB family supervisor object ID may be referred to as Oid. The bundle identifier may be used by a bundle management server or a terminal as a value indexed by a bundle.

[0092] "Bundle metadata" is a term indicating a collection of information that references or describes a bundle. Bundle metadata may include a bundle identifier. Bundle metadata may also include information about properties, characteristics, or configuration of the bundle. Bundle metadata may be denoted as "metadata".

[0093] A "profile" may be a data object such as an application, a file system, or an authentication key value stored in the UICC.

[0094] In the present disclosure, a "profile package" may be a package of "profile" contents in the form of software that can be installed in a UICC. A "profile package" may be referred to as a profile package TLV. When a profile package is encrypted using encryption parameters, the profile package may be a protected profile package (PPP) or a protected profile package TLV (PPP TLV). When a profile package encrypted using encryption parameters can only be decrypted by a specific eUICC, the profile package may be a bound profile package (BPP) or a bound profile package (BPP) TLV. A profile package TLV may be a data set indicating information for configuring a profile in a tag, length, and value (TLV) format. In the present disclosure, a "profile image" may be binary data in which a profile package is installed in a UICC. A "profile image" may be referred to as a profile TLV or a profile image TLV. When a profile image is encrypted using encryption parameters, the profile image may be referred to as a protected profile image (PPI) or a protected profile image TLV (PPI TLV). When a profile image encrypted using encryption parameters can only be decrypted by a specific eUICC, the profile image may be referred to as a bound profile image (BPO) or a bound profile image (BPI) TLV. The profile image TLV may be a data set indicating information configuring a profile in a tag, length, and value (TLV) format. In the present disclosure, the "state" of a profile may be described as follows.

[0095] [Enable]

[0096] In the present disclosure, the operation of enabling a profile by a terminal may be an operation of changing the state of a corresponding profile to an enabled state and allowing the terminal to receive communication services through a communication service provider that provides the corresponding profile. A profile in an enabled state may be represented as an "enabled profile".

[0097] [Disable]

[0098] In the present disclosure, the operation of the terminal disabling a profile may be an operation of changing the state of the corresponding profile to a disabled state and preventing the terminal from receiving communication services through the communication service provider providing the corresponding profile. A profile in a disabled state may be represented as a "disabled profile".

[0099] [delete]

[0100] In the present disclosure, the operation of the terminal deleting a configuration file may be an operation of changing the state of the terminal to a deleted state and preventing the terminal from enabling or disabling the corresponding configuration file again. The configuration file in the deleted state may be represented as a "deleted configuration file".

[0101] In the present disclosure, the operation of enabling, disabling or deleting a configuration file by a terminal may be to first mark the state of each configuration file as a state to be enabled, a state to be disabled or a state to be deleted, without immediately changing the state of each configuration file to an enabled state, a disabled state or a deleted state, and then change the state of each configuration file to an enabled state, a disabled state or a deleted state by the terminal or the UICC of the terminal. The operation of marking a specific configuration file as a state to be changed (i.e., a state to be enabled, a state to be disabled or a state to be deleted) is not necessarily limited to marking one configuration file as a state to be changed, and one or more configuration files may be marked as the same or different states to be changed, one configuration file may be marked as one or more states to be changed, or one or more configuration files may be marked as the same or one or more different states to be changed.

[0102] When the terminal marks one or more states to be changed for a predetermined configuration file, the marking of two states to be changed can be integrated into one state. For example, when a predetermined configuration file is marked as a state to be disabled and a state to be deleted, the corresponding configuration file can be marked as a state to be disabled and deleted.

[0103] In addition, the terminal can perform the operation of marking the state to be changed for one or more configuration files in sequence or simultaneously. In addition, the terminal can perform the operation of marking the state to be changed for one or more configuration files in sequence or simultaneously, and then actually changing the state of the configuration files in sequence or simultaneously.

[0104] The profile identifier may be referred to as a factor that matches a profile ID, an integrated circuit card id (ICCID), a match ID, an event ID, an activation code, an activation code token, a command code, a command code token, a signed command code, an unsigned command code, an ISD-P, or a profile domain (PD). The profile ID may indicate a unique identifier for each profile. The profile identifier may also include an address of a profile provisioning server (SM-DP+) for indexing the profile. The profile identifier may also include a signature of the profile provisioning server (SM-DP+).

[0105] A "bundle management server" may include the functionality of generating a bundle, encrypting a generated bundle, generating a bundle remote management command, or encrypting a generated bundle remote management command by a request from a service provider or another bundle management server. The bundle management server providing this functionality may be represented as at least one of a secondary platform bundle manager (SPBM), a remote bundle manager (RBM), an image delivery server (IDS), a subscription manager data preparation (SM-DP), subscription manager data preparation plus (SM-DP+), a manager bundle server, a management subscription manager data preparation plus (SM-DP+), a bundle encryption server, a bundle generation server, a bundle provider (BP), a bundle provider (bundleprovider), and a bundle provisioning credential (bPC) holder.

[0106] In the present disclosure, the bundle management server can be used to download, install or update the bundle in the SSP, and manage the configuration of keys and certificates for remote management of the bundle status. The bundle management server providing this function can be represented as at least one of a secondary platform bundle manager (SPBM), a remote bundle manager (RBM), an image delivery server (IDS), a subscription manager secure routing (SM-SR), a subscription manager secure routing plus (SM-SR+), an off-card entity of an eUICC profile manager, a profile management credential (PMC) holder, and an eUICC manager (EM).

[0107] In the present disclosure, a subscription relay server may receive an event registration request (register event request or event registration request) from one or more of a bundle management server and a subscription relay server. When one or more subscription relay servers may be used in a mixed manner, in this case, the first subscription relay server may receive an event registration request not only from the bundle management server but also from the second subscription relay server. In the present disclosure, the functionality of the subscription relay server may be integrated into the functionality of the bundle management server. The subscription relay server providing this functionality may be represented as at least one of a secondary platform bundle manager (SPBM), a remote bundle manager (RBM), a secondary platform bundle discovery server (SPBDS), a bundle discovery server (BDS), a subscription manager discovery service (SM-DS), a discovery service (DS), a root SM-DS, and an alternative SM-DS.

[0108] In the present disclosure, a bundle management server may refer to the sum of the functions of generating, encrypting and transmitting bundles or bundle remote management commands and the functions of configuring SSP and managing installed bundles. In addition, a bundle management server may refer to the sum of the functions of a subscription relay server. Therefore, in various embodiments of the present disclosure, the operations of a bundle management server and a subscription relay server may be performed by one bundle management server. In addition, each function may be performed separately by multiple separate bundle management servers. In the specification of the present disclosure, a bundle management server or a subscription relay server may be represented as a bundle server. The bundle server may be one of a bundle management server and a subscription relay server, or may be a device including both a bundle management server and a subscription relay server.

[0109] "Remote SIM Provisioning (RSP) Server" may be used to refer to a Profile Provisioning Server and / or a Profile Management Server and / or a Subscription Relay Server as described below. The RSP Server may be denoted as Subscription Manager (SM)-XX.

[0110] In the present disclosure, a "profile provisioning server" may include a function of generating a profile, encrypting a generated profile, generating a remote management command, or encrypting a generated profile remote management command. The profile provisioning server may be represented as a subscription manager data preparation (SM-DP), a subscription manager data preparation plus (SM-DP+), an off-card entity of a profile domain, a profile encryption server, a profile generation server, a profile provider (PP), a profile provider, and a profile provisioning credential (PPC) holder.

[0111] In the present disclosure, a "profile management server" may include a function of managing a profile. The profile management server may be represented as a subscription manager secure routing (SM-SR), a subscription manager secure routing plus (SM-SR+), an off-card entity of an eUICC profile manager, a profile management credential (PMC) holder, an eUICC manager (EM), or a profile manager (PP).

[0112] In the present disclosure, the profile provisioning server may be the sum of the functions of the profile management server. Therefore, in various embodiments of the present disclosure, the operation of the profile provisioning server may be performed by the profile management server. Similarly, the operation of the profile management server or SM-SR may be performed by the profile provisioning server.

[0113] In the present disclosure, a "subscription relay server" may be represented as a subscription manager discovery service (SM-DS), a discovery service (DS), a root SM-DS, or an alternative SM-DS. The subscription relay server may receive an event registration request (register event request or event registration request) from one or more of a profile provision server and a subscription relay server. In addition, more than one subscription relay server may be used together, in which case the first subscription relay server may receive not only an event registration request from the profile provision server, but also an event registration request from a second subscription relay server.

[0114] A "service provider" may be a company that requests to publish a requirement to a bundle management server to request the generation of a bundle and provide services to a terminal through the corresponding bundle. For example, a service provider may be a mobile operator that provides communication network access services through a bundle installed in a communication application, or all business support systems (BSS), operation support systems (OSS), point of sale (POS) terminals and other IT systems of a mobile operator. In the present disclosure, a service provider is not limited to representing only one specific company, and may be used to refer to a group or association (or consortium) of one or more companies or a representative representing a corresponding group or association. In addition, in the present disclosure, a service provider may be referred to as an operator (OP or Op), a bundle owner (BO) or an image owner (IO), and each service provider may configure or receive an allocation of at least one of a name and / or a unique identifier (object identifier (OID)). When a service provider refers to a group or association or representative of one or more companies, the name or unique identifier of the predetermined group, association, representative may be a name or unique identifier shared by all companies belonging to the corresponding group or association or all companies cooperating with the corresponding representative.

[0115] "Mobile operator" may indicate a company that provides communication services to a terminal, and may include all business support systems (BSS), operation support systems (OSS), point of sale (POS) terminals and other IT systems of the mobile operator. In the present disclosure, the mobile operator is not limited to indicating only one specific company that provides communication services, and may be used to refer to a group or association (or consortium) of one or more companies or a representative representing the corresponding group or association. In addition, in the present disclosure, a mobile operator may be referred to as an operator (OP or Op), a mobile network operator (MNO), a mobile virtual network operator (MVNO), a service provider (or SP) or a profile owner (PO), and each mobile operator may configure or receive an allocation of at least one of the name and / or unique identifier (object identifier (OID)) of the mobile operator. When a mobile operator refers to a group or association or representative of one or more companies, the name or unique identifier of the predetermined group, association, representative may be a name or unique identifier shared by all companies belonging to the corresponding group or association or all companies cooperating with the corresponding representative.

[0116] "Subscriber" can be used to refer to a service provider that owns the terminal or a user (end user) that owns the terminal. Generally, the former can be called an M2M terminal (M2M device) and the latter can be called a user terminal (consumer device). In the case of an M2M terminal, there may be a user (end user) who does not own the terminal but takes over or rents the terminal from a service provider to use the terminal, in which case the user may be the same as or different from the service provider.

[0117] "Subscriber intent" may be used to refer to a subscriber's intent to manage a bundle locally or remotely. In the case of local management, subscriber intent may be user intent (end-user intent), and in the case of remote management, subscriber intent may be service provider intent.

[0118] "User consent (end user consent)" can be used to indicate whether the user agrees to local management or remote management.

[0119] "Terminal" may be referred to as user equipment (UE), mobile station (MS), 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 device or other terms. Various embodiments of the terminal may include a cellular phone, a smart phone with wireless communication function, a personal digital assistant (PDA) with wireless communication function, a wireless modem, a portable computer with wireless communication function, a photographing device (such as a digital camera) with wireless communication function, a gaming device with wireless communication function, a home appliance with wireless communication function for storing and reproducing music, an Internet home appliance capable of performing wireless Internet access and browsing, and a portable unit or terminal with an integrated combination of their functions. In addition, the terminal may include, but is not limited to, a machine-to-machine (M2M) terminal and a machine type communication (MTC) terminal / device. In the present disclosure, a terminal may be referred to as an electronic device.

[0120] In the present disclosure, an SSP that can download and install a bundle package can be embedded in an electronic device. When the SSP is not embedded in the electronic device, the SSP physically separated from the electronic device can be inserted into the electronic device and connected thereto. For example, the SSP can be inserted into the electronic device in the form of a card. The electronic device may include a terminal, and in this case, the terminal may be a terminal including the SSP that can download and install a bundle package. The SSP may be embedded in the terminal, and when the terminal and the SSP are separated from each other, it may also be inserted into the terminal, and the inserted SSP may be connected to the terminal.

[0121] In the present disclosure, a UICC that can download and install a configuration file can be embedded in an electronic device. When the UICC is not embedded in the electronic device, a UICC physically separated from the electronic device can be inserted into the electronic device and connected thereto. For example, the UICC can be inserted into the electronic device in the form of a card. The electronic device may include a terminal, and in this case, the terminal may be a terminal including a UICC that can download and install a configuration file. The UICC may be embedded in the terminal, and when the terminal and the UICC are separated from each other, it may also be inserted into the terminal, and the inserted UICC may be connected to the terminal. The UICC that can be installed by downloading a configuration file may be, for example, an eUICC.

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

[0123] "Loader (Secondary Platform Bundle Loader (SPBL))" may refer to a management bundle for managing the installation, enabling, disabling, and deletion of another bundle in an SSP. The LBA of a terminal or a remote server may install, enable, disable, or delete a specific bundle through a loader. In the present disclosure, the operation of a loader may be described as the operation of an SSP including a loader.

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

[0125] In the present disclosure, an “event” may be used for the following purposes.

[0126] [Use in conjunction with bundle]

[0127] "Events" can collectively indicate bundle downloads, remote bundle management, or other management / processing instructions for other bundles or SSPs. Events can be referred to as remote bundle provisioning operations (remote bundle provisioning operations or RBP operations) or event records, and each event can be referred to as data including an event identifier (event ID or EventID), a matching identifier (matching ID or MatchingID), the address (FQDN, IP address or URL) of the bundle management server or subscription relay server storing the corresponding event, and one or more of each server identifier. Bundle download can be used interchangeably with bundle installation. "Event type" can be used as a term to indicate that a specific event is a bundle download, remote bundle management (e.g., delete, enable, disable, change, update, etc.), or can indicate a management / processing command for another bundle or SSP, and can be referred to as an operation type (OperationType), an operation class (OperationClass), an event request type, an event class, or an event request class.

[0128] "Local Bundle Management (LBM)" may be referred to as bundle local management, local management, local management command, local command, local bundle management (LBM) package, bundle local management package, local management package, local management command package, or local command package. LBM may be used to install a predetermined bundle, change the status of a specific bundle (enable, disable, or delete), or change (update) the content of a specific bundle (e.g., a bundle nickname or bundle summary information (bundle metadata)) through software installed in a terminal. LBM may include one or more local management commands, in which case, depending on the local management command, the bundles subject to the local management command may be the same or different.

[0129] "Remote Bundle Management (RBM)" can be bundle remote management, remote management, remote management command, remote command, remote bundle management (RBM) package, bundle remote management package, remote management package, remote management command package, or remote command package. RBM can be used to install a predetermined bundle, change the status of a specific bundle (enable, disable, or delete), or change (update) the content of a specific bundle (for example, a bundle nickname or bundle summary information (bundle metadata)). RBM can include one or more remote management commands, and depending on the remote management command, the bundles subject to the remote management command can be the same or different.

[0130] "Target bundle" may be used to indicate a bundle that is subject to a local management command or a remote management command.

[0131] A "bundle rule" may be used to indicate information that a terminal should recognize when performing local management or remote management on a target bundle. In addition, a bundle rule may be used interchangeably with a bundle policy, rule, or policy.

[0132] [Used in conjunction with a configuration file]

[0133] "Event" may be a term that collectively indicates profile download, remote profile management, and other profile or eUICC management / processing instructions. An event may be referred to as a remote SIM provisioning operation (remote SIM provisioning operation or RSP operation) or an event record, and each event may be referred to as data including an event identifier (event ID or EventID) corresponding thereto, a matching identifier (matching ID or MatchingID), and an address (FQDN, IP address or URL) of a profile provisioning server (SM-DP+) or subscription relay server (SM-DS) storing the corresponding event, a signature of the profile provisioning server (SM-DP+) or subscription relay server (SM-DS), and one or more of a digital certificate of the profile provisioning server (SM-DP+) or subscription relay server (SM-DS).

[0134] The data corresponding to the event may be referred to as a "command code". The process using some or all of the command codes may be referred to as a "command code processing process", a "command code process" or a "local profile assistant application programming interface (LPA API)". Profile download may be used interchangeably with "profile installation".

[0135] The term "event type" may be used as a term to indicate that a specific event is a profile download, remote profile management (e.g., deletion, activation, deactivation, change, update, etc.), or may indicate a management / processing command of another profile or eUICC, and may be referred to as an operation type (OperationType), an operation class (OperationClass), an event request type, an event class, or an event request class. With respect to a predetermined event identifier (EventID or MatchingID), a path through which the terminal acquires a corresponding event identifier (EventID or MatchingID) or uses the corresponding event (EventID source or MatchingID source) may be specified.

[0136] "Local Bundle Management (LBM)" may be referred to as profile local management, local management, local management command, local command, local profile management (LPM) encapsulation, profile local management encapsulation, local management encapsulation, local management command encapsulation, or local command encapsulation. LPM may be used to change the state (enable, disable, or delete) of a specific profile, or to update the content of a specific profile (e.g., a profile nickname or profile summary information (profile metadata, etc.)) through software installed in a terminal. LPM may include one or more local management commands, in which case, depending on the local management command, the profiles subject to the local management command may be the same or different.

[0137] "Remote Profile Management (RPM)" may be referred to as profile remote management, remote management, remote management commands, remote commands, RPM packaging, profile remote management packaging, remote management packaging, remote management command packaging, or remote command packaging. RPM may be used to change the state of a particular profile (enable, disable, or delete) or to change (update) the content of a particular profile (e.g., a profile nickname or profile summary information (profile metadata)). RPM may include one or more remote management commands, in which case, depending on the remote management command, the profiles belonging to each remote management command may be the same or different from each other.

[0138] A "certificate" or digital certificate may be a digital certificate for mutual authentication based on an asymmetric key including a public key (PK) and a secret key (SK) pair. Each certificate may include one or more PKs, a public key identifier (PKID) corresponding to each PK, an ID of a certificate issuer (CI) that issues the corresponding certificate, and a digital signature. The certificate issuer may be a certification issuer, a certificate authority (CA), or a certification authority. In the present disclosure, a public key (PK) and a public key identifier (PKID) may be used interchangeably to indicate a specific public key, a certificate including a corresponding public key, a portion of a specific public key, a portion of a certificate including a corresponding public key, a value of a calculation result (e.g., a hash) of a specific public key, a value of a calculation result (e.g., a hash) of a certificate including a corresponding public key, a value of a calculation result (e.g., a hash) of a portion of a specific public key, a value of a calculation result (e.g., a hash) of a portion of a certificate including a corresponding public key, or a storage space for storing data.

[0139] A "certificate chain" or certificate hierarchy can be used to issue other certificates (subordinate certificates) of a certificate (primary certificate) issued by a "certificate issuer", or when a subordinate certificate is used to hierarchically issue a third-level or higher-level certificate, it can indicate the correlation between the corresponding certificates. At this time, the CI certificate used to initially issue the certificate can be referred to as the root of the certificate, the highest certificate, the root CI, the root CI certificate, the root CA, or the root CA certificate.

[0140] In the description of the present disclosure, if it is determined that a detailed description of a related known function or configuration makes the subject matter of the present disclosure unclear, the detailed description is omitted.

[0141] Hereinafter, various embodiments of a method and apparatus for moving and installing a bundle between terminals are described.

[0142] Figure 1 is a conceptual diagram of an SSP according to an embodiment of the present disclosure.

[0143] According to various embodiments, Figure 1 As shown in the example of , the terminal 110 may include the 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 into which both processors are integrated. In another example, the SSP 120 may be a removable type 122 in the form of an independent chip that is not integrated into the SoC, or an embedded type 124 pre-embedded in the terminal 110.

[0144] According to various embodiments, the SSP 120 included in the terminal may include at least one of one or more telecommunication bundles, one or more payment bundles, and one or more electronic identification bundles. Figure 1 As shown, when a plurality of telecommunication bundles 140 and 150 are included in the SSP 120, the terminal 110 can operate the plurality of telecommunication bundles 140 and 150 simultaneously or in a time-division manner to use the mobile communication network according to the configuration. In addition, when the payment bundle 170 and the electronic identification bundle 180 are included in the SSP 120, the terminal 110 can use the payment bundle 170 to use online payment through a terminal application or offline payment through an external credit card point of sale (PoS) device, and use the electronic identification bundle 180 to authenticate the identity of the terminal owner.

[0145] Figure 2 is a conceptual diagram illustrating an internal structure of a smart security platform (SSP) according to an embodiment of the present disclosure.

[0146] According to various embodiments, Figure 2 As shown in the example of , SSP 210 may include a primary platform (PP) 220 and at least one secondary platform bundle (SPB) 230 and 240 operating thereon.

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

[0148] According to various embodiments, the secondary platform bundle 230 may include a high-level operating system (HLOS) 232 and at least one application 234 operating thereon.

[0149] According to various embodiments, each of secondary platform bundles 230 and 240 may access resources such as a central processing unit and a memory of primary platform 220 through primary platform interface (PPI) 250 and operate on SSP 210 therethrough.

[0150] Figure 3 An example of an internal element of a terminal according to an embodiment of the present disclosure is shown, through which the terminal downloads and installs a bundle in an SSP.

[0151] According to various embodiments, Figure 3 As shown in the example of FIG. 3 , the terminal 310 may include the SSP 330 and / or the LBA 312 for controlling the SSP 330. For example, the terminal 310 may be a terminal in which the SSP 330 is installed and in which the LBA 312 for controlling the SSP 330 is installed. For example, the SSP 330 may be embedded in the terminal 310 or may be removable from the terminal 310.

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

[0153] According to various embodiments, when the terminal is released, the secondary platform bundle 335, 337, or 339 may be remotely downloaded and installed after the release (not installed in the SSP 330).

[0154] According to various embodiments, Figure 3 As shown in the example of , each bundle can have a different bundle family identifier and / or bundle family manager identifier 341, 342, or 343. The bundle family identifier and the bundle family manager identifier can be used as information required to download and install the bundle. That is, the SSP 330 or SPBL 333 can allow or deny the download and installation of a specific bundle based on the bundle family identifier and the bundle family manager identifier.

[0155] Figure 4 An example of a method according to an embodiment of the present disclosure is shown, by which two terminals interact with each other in order to send a bundle to each other.

[0156] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Figure 4 As shown in the example of , 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.

[0157] According to various embodiments, a user may send a command to a terminal or receive information that the user should receive from a terminal. For example, as shown in operations 4010 to 4060, the first user 440 / the second user 490 may send a command to the LBA 410 of the first terminal 400 / the LBA 460 of the second terminal 450, or receive information that the user should receive from LBAs 410 and 460.

[0158] According to various embodiments, the operation may include a process in which a user selects a bundle to be sent. In addition, the operation may also include a process in which a user identifies information of the bundle to be sent. The operation may also include an operation in which a user permits the transmission of the bundle to be sent. The operation may also include an operation in which a user permits the transmission of the bundle to be received. All selection and permission operations may not be operated as independent operations, or one or more of all selection and permission operations may be independently selected and operated.

[0159] In addition, in operations 4020 to 4070, the LBAs 410 and 460 may transmit a command to the SSPs 420 and 470 or transmit / receive data to / from the SSPs 420 and 470.

[0160] According to an embodiment, in operation, the LBA may receive a user's command and transmit the command to the SSP. In operation, when the LBA receives a user's command and transmits the command to the SSP, the LBA may receive a result sent from the SSP as a result of the command.

[0161] According to another embodiment, in operation, the LBA may transmit a command or data received from another terminal or an external server to the SSP. In operation, when the LBA transmits a command or data received from another terminal or an external server to the SSP, the LBA may receive a result sent from the SSP as a result of the command.

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

[0163] According to various embodiments, in operation, the LBA and the SSP may send and receive data to and from each other, and install bundles.

[0164] According to various embodiments, in operation 4050, the two LBAs 410 and 460 may be connected to each other and send commands to each other or send / receive data to each other. At this time, the connection in operation 4050 may be a direct device-to-device connection between terminals, or (although not shown) may be an indirect device-to-device connection through an external entity (e.g., an external server) between the two LBAs.

[0165] The connection method between two LABs is described in more detail with reference to the drawings described below.

[0166] According to various embodiments, in operations 4030 to 4080, the SSPs 420 and 470 may generate, process, or verify data required within the SSP.

[0167] According to various embodiments, in operation, the SSP may identify or update a bundle delivery configuration. In addition, in operation, the SSP may generate and use a bundle delivery code. Operations related to the bundle delivery configuration and operations related to the bundle delivery code are independent functions, and both functions may not be performed, only one of them may be performed, or both functions may be performed. Even when both functions are performed, the two functions may be performed as completely independent functions.

[0168] A more detailed method of identifying or updating a bundle delivery configuration and a more detailed method of generating and using a bundle delivery code are described below with reference to the accompanying drawings.

[0169] According to various embodiments, in operation, the SSP may generate its own SSP information or verify the SSP information received from the counterpart terminal. In addition, in operation, the SSP may generate authentication data for verifying itself or verify the authentication data received from the counterpart terminal.

[0170] According to various embodiments, in operation, the SSP may generate a bundle.

[0171] Figure 5 A process of sending a bundle package from one terminal to another terminal according to an embodiment of the present disclosure is conceptually illustrated.

[0172] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Figure 5 As shown in the example of , the first terminal 500 may include a first LBA 520 and a first SSP 510, and the second terminal 550 may include a second LBA 570 and a second SSP 560. For example, the first terminal 500 may be a terminal in which a first SSP 510 and a first LBA 520 for controlling the first SSP 510 are installed, and the second terminal 550 may be a terminal in which a second SSP 560 and a second LBA 570 for controlling the second SSP 560 are installed.

[0173] refer to Figure 5 In operation 5000, the first SSP 510 and the first LBA 520 of the first terminal 500 and the second LBA 570 of the second terminal 550 may perform a preparation process (bundle transmission preparation process) required for sending a bundle. Figure 6 The detailed description of this process is described in detail.

[0174] refer to Figure 5 In operation 5005, a process of sending a bundle package from the first terminal 500 to the second terminal 550 (bundle package transmission process) may be performed. Figure 7The detailed description of this process is described in detail.

[0175] refer to Figure 5 In operation 5010, a process (bundle installation process) of installing the bundle package transmitted to the second terminal 550 in the second terminal 550 may be performed. Figure 8 The detailed description of this process is described in detail.

[0176] Figure 6 Shows Figure 5 The detailed process of the bundle transfer preparation process is presented. More specifically, Figure 6 An example of a process of preparing a process required to send a bundle package from one terminal to another terminal according to an embodiment of the present disclosure is shown. In this specification, Figure 6 The process may be referred to as a bundle transfer preparation process.

[0177] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Figure 6 As shown in the example of , the first terminal 600 may include a first LBA 620 and a first SSP 610, and the second terminal 650 may include a second LBA 670 and a second SSP 660. For example, the first terminal 600 may be a terminal in which a first SSP 610 and a first LBA 620 for controlling the first SSP 610 are installed, and the second terminal 650 may be a terminal in which a second SSP 660 and a second LBA 670 for controlling the second SSP 660 are installed.

[0178] According to various embodiments, the first terminal 600 may have a pre-installed bundle. The bundle may be stored in the first SSP 610 or the first LBA 620, or in a memory other than the first SSP 610 and the first LBA 620 (although not in the memory). Figure 6 ), or may be stored overlappingly in at least one space among the first SSP 610, the first LBA 620, and the external memory. The bundle may be divided and stored in a combination of at least two of the first SSP 610, the second LBA 620, and the external memory, in which case there may be duplicate information between the divided bundles. All or some of the stored bundles may be encrypted and may also include signature information.

[0179] According to various embodiments, the first terminal 600 may also have metadata associated with the bundle. The metadata may be stored in the first SSP 610 or the first LBA 620, may be stored in a memory other than the first SSP 610 and the first LBA 620 (although not in the memory). Figure 6), or may be stored overlappingly in at least one space in the first SSP 610, the first LBA 620, or an external memory. In addition, the metadata may be divided and stored in a combination of at least two of the first SSP 610, the second LBA 620, and the external memory, in which case there may be duplicate information between the divided information. In addition, all or some of the stored metadata may be encrypted, and signature information may also be included.

[0180] According to various embodiments, the first terminal 600 may be associated with a corresponding bundle and may have at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB family ID), and a bundle family manager identifier (SPB family supervisor object ID). The identifier information may exist within the bundle, within the metadata, or in an independent area other than the bundle and metadata, or may be divided and stored in an overlapping manner in the bundle, metadata, and independent area. In addition, the identifier information may be encrypted or may also include its signature information.

[0181] According to various embodiments, the first terminal 600 may be associated with a corresponding bundle and may have a "bundle delivery configuration". The bundle delivery configuration may include a "bundle delivery policy". The bundle delivery configuration may also include a "bundle delivery history". The "bundle delivery configuration" may exist within the bundle, within the metadata, or in an independent area that is not the bundle and metadata, or may be divided and stored in an overlapping manner within the bundle, metadata, and independent area. The bundle delivery configuration may be encrypted or may also include its signature information.

[0182] According to various embodiments, the "Bundle Delivery Configuration" may be acquired at a necessary time point in a state where the Bundle Delivery Configuration is not pre-occupied by the terminal. At this time, the "Bundle Delivery Configuration" may be generated by a request from the terminal by the service provider, the bundle management server, or the cooperation between the service provider and the bundle management server, and sent to the terminal. Alternatively, the "Bundle Delivery Configuration" may be generated by cooperation between the terminal and at least one of the service provider and the bundle management server.

[0183] According to various embodiments, the "bundle delivery configuration" within the terminal may be updated by a service provider, a bundle management server, or cooperation between the service provider and the bundle management server. Alternatively, the "bundle delivery configuration" may be updated by cooperation between the terminal and at least one of the service provider and the bundle management server. The timing and method of the update may be determined by the policy of the service provider, the bundle management server, or the terminal manufacturing company.

[0184] According to various embodiments, a "bundle transfer policy" is a policy indicating whether a bundle can be transferred between devices, and can be generated by a service provider as the initial provider of the bundle, a bundle management server, or a collaboration between the service provider and the bundle management server. The "bundle transfer policy" may optionally include factors (or indications) indicating whether the corresponding bundle is allowed to be transferred between devices.

[0185] When the corresponding bundle is allowed to be transferred between devices, the "bundle transfer policy" may also selectively include factors indicating conditions for allowing the transfer.

[0186] Factors indicating conditions for allowing transmission may include, for example, a maximum number of transmissions of corresponding bundles allowed between devices, a time period during which transmissions of corresponding bundles are allowed between devices, or a maximum number of transmissions of corresponding bundles allowed within a specific time period.

[0187] In another example of a factor, a factor indicating whether permission of the service provider and / or bundle management server is required before the bundle is transferred between devices may be included. When permission of the service provider and / or bundle management server is required before the bundle is transferred between devices, the process of receiving permission may be performed as part of operation 6000 and / or operation 6010 and / or operation 7015 and / or operation 7040. The detailed process of the process is described with reference to the drawings described below. However, the process of receiving permission of the service provider and / or bundle management server does not have to be performed as part of operation 6000 and / or operation 6010 and / or operation 7015 and / or operation 7040, but may be performed in the process of receiving permission of the service provider and / or bundle management server. Figure 6 and / or Figure 7 It is performed at predetermined moments during the process shown. Information indicating when the license should be received from the service provider and / or bundle management server may also be included as part of the "bundle delivery policy".

[0188] In addition, in another example of factors, factors indicating the bundle transmission methods allowed between devices may be included. For example, as a bundle transmission method between devices, factors indicating whether online transmission and / or offline transmission are allowed may be included. When both online transmission and offline transmission are allowed, information indicating which transmission method between devices is preferred may be included. When both online transmission and offline transmission are allowed, information indicating whether another method can be automatically run when one method fails may be included. When both online transmission and offline transmission are allowed, information indicating whether the user's consent should be obtained to execute another method when one method fails may be included. When the bundle transmission between devices fails, information indicating whether re-supply can be performed may be included. Information indicating whether re-supply can be performed when online transmission or offline transmission between devices fails may be included. At this time, information indicating whether re-supply can be automatically run may also be included. Information indicating whether the user's consent should be obtained to run re-supply may be included. When all online transmission, offline transmission, and re-supply are allowed, configuration of the order of each method may be included. When offline transmission is first attempted and then fails, online transmission may be attempted, and when online transmission also fails, re-supply may be attempted. However, this is only an example, and the order of online transmission, offline transmission, and re-provisioning can be configured by various methods. When online transmission, offline transmission, and re-provisioning are performed in a predetermined order, information indicating whether continuous execution can be performed automatically may be included. Alternatively, when online transmission, offline transmission, and re-provisioning are performed in a predetermined order, a factor indicating whether the user's consent should be obtained whenever continuous execution is performed may be included.

[0189] As another example of a factor, the following description may also be included. Information indicating whether a notification related to the bundle transmission should be sent to the service provider and / or the bundle management server may be included. Information indicating whether the corresponding bundle can be used by multiple terminals may be included. Information indicating whether additional authentication should be performed using information received from the service provider and / or the bundle management server when the terminal sending the bundle authenticates the terminal receiving the bundle may be included. That is, the service provider and / or the bundle management server can provide reliable authentication information related to the terminal and / or SSP, and the terminal sending the bundle can authenticate whether the terminal receiving the bundle is a terminal that the service provider and / or the bundle management server can trust based on the information.

[0190] As another example of a factor, the following description may also be included. Information indicating whether information about the terminal receiving the bundle should be additionally received before the terminal sending the bundle sends the bundle may be included. At this time, the "information about the terminal receiving the bundle" to be additionally received may be directly input by the user, or may be input by an external server, or may be input by the terminal receiving the bundle through communication between the two terminals. Information indicating whether additional know your customer (KYC) authentication of the user is required may be included to configure the bundle to be sent to a state that the terminal receiving the bundle can use. At this time, additional KYC authentication may be performed in various ways. For example, KYC authentication may be performed by methods such as calling and / or ARS authentication and / or text messaging. Alternatively, when the user controls the terminal, KYC authentication may be performed by communication with a service provider and / or a bundle management server. Alternatively, when the terminal receiving the bundle communicates with the service provider and the bundle management server, authentication may be performed without any user involvement.

[0191] According to various embodiments, the "bundle transmission history" is information that records the transmission history of the bundle between devices performed in the past. For example, the "bundle transmission history" may selectively include the date and time of the bundle transmission. The "bundle transmission history" may also selectively include information about the number of bundle transmissions. The "bundle transmission history" may also selectively include at least one of information about the terminal that sent the bundle or information about the terminal that received the bundle. When the bundle has never been transmitted between devices and is initially installed in the first terminal 600, the bundle transmission history may be configured by the first terminal, a service provider as a bundle provider, a bundle management server, or a cooperation between at least two of the first terminal, the service provider, and the bundle management server. When the bundle has been transmitted between devices in the past, the bundle transmission history may be configured by the first terminal, an old terminal that has sent the bundle to the first terminal in the past, a service provider as an initial provider of the bundle, a bundle management server, or a cooperation between at least two of the first terminal, the old terminal, the service provider, and the bundle management server.

[0192] refer to Figure 6 In operation 6000, information about the bundle to be transferred between devices may be transferred to the first LBA 620. This transfer process may be performed by the user via a Figure 6The UI provided by the first terminal 600 shown may directly select the process of the bundle to execute, or may be input into the first LBA 620 through a push input from a remote server, or the first LBA 620 may access the remote server to read the corresponding information. When the first terminal 600 provides the UI to the user, a list of all bundles installed in the terminal may be provided through the UI, or only a list of bundles that can currently be transmitted may be provided. When a list of bundles that cannot currently be transmitted is provided, information indicating the possibility of transmission of the bundles in the list may be provided in addition. In addition, information about the bundles or about the transmission strategy of the bundles may be further provided through the UI as well as the list of bundles.

[0193] In operation 6000, the first LBA 620 may identify whether a corresponding bundle may be transferred between devices based on the "bundle transfer configuration". The first LBA 620 may identify a method of transferring a bundle allowed between devices through the "bundle transfer configuration". For example, a connection type between devices for bundle transfer may be identified.

[0194] The first LBA 620 can identify whether the necessity for permission from the service provider and / or bundle management server is configured in the "bundle transfer configuration" before sending the bundle. If the necessity is configured, the first terminal 600 can access a server managed by the service provider and / or bundle management server, and / or a server managed by cooperation between the service provider and the bundle management server (hereinafter referred to as the "server") to request permission to transfer the bundle between devices. At this time, the first terminal 600 can provide the "server" with information related to the bundle (for example, a bundle identifier, such as a bundle identifier (SPB ID), a bundle family identifier (SPB family ID) and a bundle family manager identifier (SPB family supervisor object ID), or other information indicating bundle attributes (for example, metadata of the bundle or some of the metadata)). In such a processor, a mutual authentication process between the first terminal and the server may also be included. If the server does not permit the corresponding bundle to be transferred between devices, the bundle transfer process may stop.

[0195] In addition, the first LBA 620 can identify whether information about the terminal receiving the bundle should be additionally received before the terminal sends the bundle, which identifies the "bundle transmission configuration" for sending the bundle. If the necessity is configured, the first LBA 620 can receive information ssp2.info about the terminal receiving the bundle. Ssp2.info can be information referring to the second terminal. Ssp2.info can be an SSP identifier of the second SSP 660. Ssp2.info can be a series of information bound to the SSP identifier of the second SSP 660. Ssp2.info can 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. In another available method of inputting ssp2.info, the information can be input through a server, or can be input through communication between the second terminal 650 and the first terminal 600.

[0196] The first LBA 620 may generate "bundle transfer information". The bundle transfer information may include a bundle identifier, such as a bundle identifier (SPB ID) of the bundle to be sent, a bundle family identifier (SPB family ID), and a bundle family manager identifier (SPB family supervisor object ID). In addition, the bundle transfer information may also include other information indicating bundle attributes (e.g., metadata of the bundle or some of the metadata). The bundle transfer information may include the address (SPBM Addr) of a bundle management server associated with the bundle to be sent. The bundle transfer information may include information required for the connection between the two terminals performed in operation 6025. For example, information required for a Wi-Fi connection between the two terminals may be included (e.g., the SSID and / or BSSID of the second terminal 650, a pre-shared key to be used to authenticate the connection between the two terminals, the IP address of the second terminal 650, and a port number to be used for communication between the two terminals).

[0197] refer to Figure 6 In operation 6005, information related to the bundle selected in operation 6000 may be transmitted from the first LBA 620 to the first SSP 610. For example, Figure 6As shown, information related to the selected bundle can be transmitted from the first LBA 620 to the first SSP 610 by selecting the 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 operation 6000. The information for identifying the bundle may be a bundle identifier (SPB ID) or other identifier for identifying the bundle identifier. In addition, the information transmitted from the first LBA 620 to the second SSP 610 may also selectively include a bundle identifier, such as a bundle family identifier (SPB family ID) or a bundle family manager identifier (SPB family supervisor object ID) or other information indicating bundle attributes (e.g., metadata of the bundle or some of the metadata).

[0198] refer to Figure 6 In operation 6010, the first SSP 610 may identify whether the bundle requested to be sent can be transferred between devices. This process may be performed by identifying the bundle requested to be sent based on the information received in operation 6005, and identifying the "bundle transfer configuration" associated with the corresponding bundle. In this process, the first SSP 610 may identify the conditions under which the bundle can be transferred between devices based on the "bundle transfer policy", and compare the "bundle transfer history" and the "bundle transfer policy" as needed to confirm whether the bundle can currently be transferred between devices.

[0199] In operation, some examples of the process of determining whether a bundle can currently be transferred between devices based on the "Bundle Transfer Configuration" are described below. For example, when the "Bundle Transfer Policy" includes a factor indicating whether the corresponding bundle is allowed to be transferred between devices, SSP 1 610 can identify the value of the factor. At this time, when the value of the factor indicates that the transfer of the corresponding bundle between the devices is prohibited, the first SSP 610 can stop the process of transferring the corresponding bundle between the devices and send the result to the first LBA 620. In another example, when the "Bundle Transfer Policy" includes information indicating the conditions for allowing the transfer of the corresponding bundle between devices, the first SSP 610 can identify these conditions and then compare these conditions with the information recorded in the "Bundle Transfer History". For example, when the "bundle transfer policy" includes the maximum number of transmissions of the corresponding bundles allowed between devices, the time period allowed for transmission of the corresponding bundles between devices, or the maximum number of transmissions of the corresponding bundles allowed within a specific time period, the first SSP 610 can identify the "bundle transfer history" and identify whether the bundle currently to be sent can be currently sent without violating the "bundle transfer policy". At this time, when it is determined that the current transmission of the bundle violates the "bundle transfer policy", the first SSP 610 can stop the process of transmitting the corresponding bundle between devices and send the result to the first LBA 620. When the necessity for permission for the service provider and / or bundle management server is configured in the "bundle transfer configuration" before sending the bundle, the approval process can be performed. That is, the first terminal 600 can request permission to transmit the bundle between devices by accessing a "server managed by the service provider and / or bundle management server and / or a server managed by cooperation between the service provider and the bundle management server" (hereinafter referred to as the "server"). At this time, the first terminal 600 can provide the "server" with information related to the bundle (for example, a bundle identifier, such as a bundle identifier (SPB ID), a bundle family identifier (SPB family ID) and a bundle family manager identifier (SPB family supervisor object ID), or other information indicating bundle attributes (for example, metadata of the bundle or some of the metadata)). In such a process, a mutual authentication process between the first terminal and the server can also be included. If the server does not permit the corresponding bundle to be transmitted between devices, the bundle transmission process can be stopped.

[0200] In operation 6010, the first SSP 610 may selectively generate a "bundle transfer code". As described above, the process of generating the bundle transfer code in operation 6010 may be a process that is selectively (optionally) performed. In this case, the process of generating the bundle transfer code may be performed or omitted as needed. For example, when the bundle transfer code is not used for the transfer of a bundle or when the bundle transfer code is used for the transfer of a bundle but a conventionally defined value (e.g., a bundle identifier) ​​is used as the bundle transfer code, the process of generating the bundle transfer code in operation 6010 may be omitted. Alternatively, when the bundle transfer code is used for the transfer of a bundle and a new bundle transfer code needs to be defined, the process of generating the bundle transfer code in operation 6010 may be performed.

[0201] As described above, the "Bundle Transfer Code" may not be used, or when used, it may be newly generated, or one of the conventionally defined values ​​may be selected and used. A more detailed description of the "Bundle Transfer Code" is provided below.

[0202] According to various embodiments, the "bundle transfer code" is a code for referring to the corresponding bundle in the process of transmitting the corresponding bundle between devices, and should be a value that can identify the corresponding bundle. The "bundle transfer code" can be an already defined value that can identify the bundle (for example, a bundle identifier (SPB ID) or a predefined value that can identify the bundle identifier), a new value generated by the first SSP 610 after receiving a request to send the bundle, or a value obtained by combining a predefined value and a newly generated value. In addition, the "bundle transfer code" can be a value or a set of values ​​including one or more values. When the "bundle transfer code" is a combination of one or more values, the values ​​may include at least one of an identifier of a predefined bundle, a predefined value that can identify the identifier of the bundle, and a value newly generated by the first SSP 610 after receiving the request. As described above, in the present disclosure, the bundle transfer code for transmitting a bundle between devices can be configured as a value other than the unique identifier of the corresponding bundle to be transmitted (the bundle identifier (SPB ID)). Therefore, the process of transmitting a bundle between devices can be performed without exposing the unique identifier of the bundle to the outside.

[0203] When the 'bundle transfer code' is used for bundle transmission, in operation 6010, the first SSP 610 may bind the 'bundle transfer code' and information on the bundle to be sent.

[0204] refer to Figure 6 In operation 6015, the response result of operation 6005 may be sent from the first SSP 610 to the first LBA 620. For example, Figure 6As shown, a response to the Select SPB command may be transmitted from the first SPB 610 to the first LBA 620 via a Select SPB Response. The response may include the "Bundle Transfer Code" described in operation 6010. In addition, the information transmitted from the first SSP 610 to the first LBA 620 may also selectively include a bundle identifier, such as a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), or a bundle family manager identifier (SPB Family Supervisor Object ID), or other information indicating bundle attributes (e.g., metadata of the bundle or some of the metadata). In addition, the information transmitted from the first SSP 610 to the first LBA 620 may also selectively include an address (SPBM Addr) of a bundle management server associated with the bundle to be sent.

[0205] Operations 6005 to 6015 may be omitted.

[0206] refer to Figure 6 In operation 6020, information required for transferring a bundle between devices 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 a "bundle transfer code". In addition, the information transferred from the first LBA 620 to the second LBA 670 may also selectively include a bundle identifier, such as a bundle identifier (SPB ID), a bundle family identifier (SPB family ID), or a bundle family manager identifier (SPB family supervisor object ID), or other information indicating bundle attributes (e.g., metadata of the bundle or some of the metadata). In operation 6025, the information transferred from the first LBA 620 to the second LBA 670 may also selectively include information required to establish a connection between the first LBA 620 and the second LBA 670. The information transferred from the first LBA 620 to the second LBA 670 may also optionally include a shared secret value to be shared between the first LBA 620 and the second LBA 670. The information transferred from the first LBA 620 to the second LBA 670 may also optionally include an address of a bundle management server (SPBM Addr) associated with the bundle to be sent. The information transferred from the first LBA 620 to the second LBA 670 may also optionally include information indicating that the bundle transfer between the devices is to be performed.

[0207] Through operation 6020, the information transmitted from the first LBA 620 to the second LBA 670 may be sent in various methods. For example, the information transmitted from the first LBA 620 to the second LBA 670 may be provided to the user through the UI of the first terminal 600, and the user may input the provided information to the second LBA through the UI of the second terminal 650. Alternatively, the first LBA may configure the information that should 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 may scan the image through the second terminal 650 and send the information to the second LBA 670. However, the method by which the information is transmitted from the first LBA 620 to the second LBA 670 is not limited to the above method.

[0208] refer to Figure 6 , in operation 6025, a connection may be established (or configured) between the first LBA 620 and the second LBA 670. If information required for the connection is sent in operation 6020, the first LBA 620 and the second LBA 670 may use the 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, Wi-Fi Direct, LTE device-to-device (D2D), and 5G D2D, or a wired connection through a cable) or a long-distance connection with a remote server (e.g., a relay server) located between the first LBA 620 and the second LBA 670.

[0209] refer to Figure 6 Although operation 6025 is shown as the last operation, it is an operation independent of other operations (i.e., operations 6000, 6005, 6010, 6015, and 6020) and can be performed regardless of the order of the operations. For example, operation 6025 can be performed between operation 6015 and operation 6020, in which case, information sent from the first LBA 620 to the second LBA 670 in operation 6020 can also be sent through the connection established in operation 6025.

[0210] Figure 7 Shows Figure 5 The detailed process of the process of transferring the bundle is shown in FIG. More specifically, Figure 7 An example of a process in which a terminal sends a bundle to another terminal according to an embodiment of the present disclosure is shown. In the present disclosure, Figure 7 The process may be referred to as a bundle transfer process.

[0211] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Figure 7 As shown in the example of , the first terminal 700 may include a first LBA 720 and a first SSP 710, and the second terminal 750 may include a second LBA 770 and a second SSP 760. For example, the first terminal 700 may be a terminal in which a first SSP 710 and a first LBA 720 for controlling the first SSP 710 are installed, and the second terminal 750 may be a terminal in which a second SSP 760 and a second LBA 770 for controlling the second SSP 760 are installed.

[0212] refer to Figure 7 In operation 7000, the second LBA 770 may request "SSP information (SspInfo)" from the second SSP 760. When the second LBA 770 requests "SSP information (SspInfo)" from the second SSP 760 in operation 7000, the second LBA 770 may notify the second SSP 760 that a bundle will be transferred between devices. In addition, the second LBA 770 may selectively provide information about the bundle to be sent to the second SSP 760. The information may selectively 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 supervisor object ID).

[0213] Operation 7000 can be Figure 6 The process shown in the figure can be automatically executed immediately after the process is completed, or can be executed after receiving external input. At this time, the "external input" can be executed by the user directly selecting the bundle to be received via the UI provided by the second terminal 750, or can be input into the second LBA 720 through a push input from a remote server, or the second LBA 720 can access the remote server to read the corresponding information.

[0214] refer to Figure 7In operation 7005, the second SSP 760 may generate its own "SSP information". The "SSP information" may include information about the second SSP that should be provided for bundle transmission. For example, the "SSP information" may include information for a certificate negotiation process that should be passed before the second SSP 760 receives the bundle (certificate negotiation information). The "certificate negotiation information" may include certificate information (SenderSpblVerification) that the second SSP 760 may use to verify another SSP and certificate information (ReceiverSpblVerification) that another SSP may use to verify the second SSP. In addition, the "certificate negotiation information" may also optionally include a list of algorithms for key sums supported by the second SSP 760, and may also optionally include a list of encryption algorithms supported by the second SSP 760. When the bundle family identifier (SPB family ID) and the bundle family manager identifier (SPB family supervisor object ID) are provided in operation 7000, the "certificate negotiation information" may be selected depending on the bundle family identifier or the bundle family manager identifier, in which case the "SSP information" may also selectively include the bundle family identifier and the bundle family manager identifier and the certificate negotiation information. The "SSP information" may also selectively include SSP version information including at least one of version information of standards supported by the host platform and loader included in the second SSP 760.

[0215] refer to Figure 7 In operation 7010, the second SSP 760 may transmit the “SSP information” generated in operation 7005 to the first SSP 710 via the second LBA 770 and the first LBA 720.

[0216] According to operations 7000 to 7010, after the second LBA 770 requests the second SSP 760 for "SSP information (SspInfo)" and the second SSP 760 generates its own "SSP information", the second SSP 760 may transmit the "SSP information" to the first SSP 710 via the second LBA 770 and the first LBA 720. However, according to an embodiment, the process of sending the "SSP information" from the second terminal 750 to the first terminal 700 is described below. For example, after the second LBA 770 generates the "SSP information" itself, the second LBA 770 may transmit the "SSP information" to the first SSP 710 via the first LBA 720. This operation may be performed in Figure 6The process shown in the figure is automatically executed immediately after the process is executed, or it can be executed after receiving external input. At this time, the "external input" can be executed by the user directly selecting the bundle to be received via the UI provided by the second terminal 750, or it can be input into the second LBA 720 through a push input from a remote server, or the second LBA 720 can access the remote server to read the corresponding information. For the "SSP information", please refer to the description in the above operation 7005.

[0217] refer to Figure 7 , in operation 7015, the first SSP 710 may identify the received 'SSP information'.

[0218] When the necessity for permission from the service provider and / or bundle management server is configured in the "bundle delivery policy" before sending the bundle, a process for receiving approval can be performed. That is, the first terminal 700 can request permission to transfer the bundle between devices by accessing a "server managed by the service provider and / or bundle management server and / or a server managed by cooperation between the service provider and the bundle management server" (hereinafter referred to as the "server"). At this time, the first terminal 700 can provide the "server" with information related to the bundle (for example, a bundle identifier, such as a bundle identifier (SPB ID), a bundle family identifier (SPB family ID), and a bundle family manager identifier (SPB family supervisor object ID), other information indicating bundle attributes (for example, metadata of the bundle or some of the metadata), or some and / or all of the SSP information of the second terminal received in a previous operation). In such a process, a mutual authentication process between the first terminal and the server may also be included. However, the mutual authentication process between the first terminal and the server does not have to be performed in this operation, and may have been performed before operation 7015. If the server does not permit the corresponding bundle to be transferred between the devices, the bundle transfer process may stop.

[0219] In operation 7015, the first SSP 710 may generate "first terminal authentication information (Device1.Auth)" for authenticating the first SSP itself.

[0220] A more detailed procedural description of the process is as follows. The first SSP 710 can identify the certificate information used to verify the first SSP itself through the received "SenderSpblVerification" and the "algorithm list of key sums supported by the second SSP 760", and select at least one key agreement certificate (ssp1.Cert.KA). Alternatively, the first SSP 710 can generate an asymmetric encryption key pair for key agreement, such as a public key "ssp1.ePK.KA" and a secret key "ssp1.eSK.KA", through the "algorithm list of key sums supported by the second SSP 760", and then select the public key "ssp1.ePK.KA" from the key pair. In addition, the first SSP 710 can identify the certificate information used to verify the first SSP itself through the received "SenderSpblVerification", and further select at least one signature certificate (ssp1.Cert.DS). The first SSP 710 may select at least one certificate of the second SSP 760, the first SSP may verify the certificate through the received “ReceiverSpblVerification”, and then configure the corresponding information as “CiPkIdToBeUsed”. The first SSP 710 may select at least one encryption algorithm to be used in the future through the “list of encryption algorithms supported by the second SSP 760”, and then configure the corresponding information as “CryptoToBeUsed”. The first SSP 710 may identify the list of “version information of standards supported by the main platform and loader included in the second SSP 760”, and identify whether the list includes the version of the standard supported by the first SSP itself.

[0221] "The first terminal authentication information (Device1.Auth)" may include at least one of "ssp1.Cert.KA", "ssp1.ePK.KA", "CiPkIdToBeUsed" and "CryptoToBeUsed". "The first terminal authentication information (Device1.Auth)" may also optionally include "ssp1.Cert.DS". "The first terminal authentication information (Device1.Auth)" may also optionally include at least one of the bundle identifier (SPB ID) of the bundle to be sent in the future, the bundle family identifier (SPB family ID) and the bundle family manager identifier (SPB family supervisor object ID).

[0222] At this time, some or all of the "first terminal authentication information (Device1.Auth)" may have a digital signature to be verified using ssp1.Cert.DS to ensure the integrity of the information, and the digital signature data may be added as part of the "first terminal authentication information".

[0223] refer to Figure 7 In operation 7020 , the first SSP 710 may transmit the “first terminal authentication information (Device1.Auth)” generated in operation 7015 to the second LBA 770 via the first LBA 720 .

[0224] refer to Figure 7 , in operation 7025, the second LBA 770 may transmit the “first terminal authentication information (Device1.Auth)” to the second SSP 760. In addition, the second LBA 770 may also transmit the “bundle transfer code” to the second SSP 760. In particular, the second LBA 770 may transmit the “bundle identifier” (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 in an operation different from operation 7025. For example, in operation 7000, the second LBA 770 may transmit the “bundle transfer code” to the second SSP 760.

[0225] refer to Figure 7 , in operation 7030, the second SSP 760 may verify the "received first terminal authentication information (Device1.Auth)". When the second SSP 760 receives "ssp1.Cert.KA", the second SSP may identify the signature of the corresponding certificate to check the validity of the certificate. When the second SSP 760 receives "ssp1.ePK.KA" and its digital signature, the second SSP may first check the validity of ssp1.Cert.DS, and then use the certificate to identify the digital signature, and identify the integrity of the received public key ssp1.ePK.KA. The second SSP 760 may identify the received "CiPkIdToBeUsed" and select at least one signing certificate (ssp2.Cert.DS) for verifying the second SSP itself.

[0226] Although not shown in the drawings, in operation 7030, the second SSP 760 may generate an asymmetric encryption key pair for key agreement, such as a public key "ssp2.ePK.KA" and a secret key "ssp2.eSK.KA", and then select the public key "ssp2.ePK.KA" from the key pair. The second SSP 760 may select one of the public key for key agreement included in ssp1.Cert.KA and ssp1.ePK.KA, and then use the value and ssp2.eSK.KA to generate a session key ShKey01 for encryption during future communications with the terminal 1. ShKey01 should be the session key for the encryption algorithm included in the received "CryptoToBeUsed".

[0227] In operation 7030, the second SSP 760 may generate “second terminal authentication information (Device2.Auth)” for authenticating the second SSP itself. The “second terminal authentication information (Device2.Auth)” may include “ssp2.Cert.DS”. The “second terminal authentication information (Device2.Auth)” may also include “ssp2.ePK.KA”. The “second terminal authentication information (Device2.Auth)” may also include a transaction ID referring to the current session generated by the SSP 2 760. The “second terminal authentication information (Device2.Auth)” may also include a “bundle transfer code”. The “second terminal authentication information (Device2.Auth)” may also include an “identifier of the main platform installed in the second SSP 760”. The second terminal authentication information (Device2.Auth) may also include a part number ID (part number ID) of the second SSP 760. The “part number ID” may be information used to infer “the manufacturer of the main platform installed in the second SSP 760 and the model information of the main platform” through the ID. The "second terminal authentication information (Device2.Auth)" may also selectively 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 supervisor object ID) associated with the bundle to be sent in the future. The "second terminal authentication information (Device2.Auth)" may also include ssp2.info. Ssp2.info may refer to information of the second terminal. Ssp2.info may be an 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. Ssp2.info may be a series of strings and / or codes bound to the SSP identifier of the second SSP 660.

[0228] At this time, some or all of the "second terminal authentication information (Device2.Auth)" may have a digital signature to be verified using ssp2.Cert.DS to ensure the integrity of the information, and the digital signature data may be added as part of the "second terminal authentication information". In addition, the "second terminal authentication information (Device2.Auth)" may be encrypted using the previously generated session key ShKey01.

[0229] refer to Figure 7 In operation 7035, the second SSP 760 may transmit the "second terminal authentication information (Device2.Auth)" generated in operation 7030 to the first LBA 720 via the second LBA 770 and the first LBA 720. At this time, the "bundle transfer code" may also be selectively sent. The first LBA 720 may additionally send the ssp2.Info received in operation 6000 to the first SSP 710.

[0230] refer to Figure 7 , in operation 7040, the first SSP 710 may verify the received "second terminal authentication information (Device2.Auth)". The first SSP 710 may verify the signature of the received "ssp2.Cert.DS" and verify the validity of the corresponding certificate. The first SSP 710 may check whether the received bundle identifier (SPB ID), bundle family identifier (SPB family ID) or bundle family manager identifier (SPB family supervisor object ID) is a correctly configured value associated with the bundle that the first SSP expects to send. Specifically, the bundle transmission configuration associated with the received bundle identifier may be identified, and it may be identified whether the corresponding bundle is a bundle that can be sent to the second terminal. The first SSP 710 may store the received transaction ID or the identifier of the main platform installed in the second SSP 760. The first SSP 710 may check whether the second SSP 760 is an SSP that can install the corresponding bundle (check eligibility) based on the received main platform ID and / or part number ID. The first SSP 710 may bind the received transaction ID or the ID of the host platform installed in the second SSP 760 with the currently running session or the bundle to be sent. The first SSP 710 may verify whether the ssp2.Info received from the first LBA 720 is the same as the ssp2.Info included in the "second terminal authentication information (Device2.Auth)" in operation 7035.

[0231] In the process, when the encrypted data is included in the "second terminal authentication information (Device2.Auth)", the first SSP 710 can generate a session key ShKey01 by using the received ssp2.ePK.KA and a key corresponding to the public key for key agreement included in its own ssp1.Cert.KA or ssp1.eSK.KA, decrypt the encrypted data by using the session key, and then perform the verification process. In addition, in the process, when the "second terminal authentication information (Device2.Auth)" includes a digital signature, the first SSP 710 can verify the validity of the received digital signature by using "ssp2.Cert.DS".

[0232] When the necessity for permission from the service provider and / or bundle management server is configured in the "bundle delivery policy" before sending the bundle, a process for receiving approval can be performed. That is, the first terminal 700 can request permission to transfer the bundle between devices by accessing a server managed by the service provider and / or bundle management server and / or a server managed by cooperation between the service provider and the bundle management server (hereinafter referred to as the "server"). At this time, the first terminal 700 can provide the "server" with information related to the bundle (for example, a bundle identifier, such as a bundle identifier (SPB ID), a bundle family identifier (SPB family ID) and a bundle family manager identifier (SPB family supervisor object ID), other information indicating bundle attributes (for example, metadata of the bundle or some of the metadata), some and / or all of the SSP information received from the second terminal, or some and / or all of the "second terminal authentication information" received from the second terminal (for example, the main platform ID and / or part number ID of the second SSP)). In such a process, a mutual authentication process between the first terminal and the server can also be included. However, the mutual authentication process between the first terminal and the server does not have to be performed in this operation, and may have been performed before operation 7040. If the server does not permit the corresponding bundle to be transferred between the devices, the bundle transfer process may stop.

[0233] Although not in Figure 7, but in operation 7040, the first SSP 710 may generate an asymmetric encryption key pair for key agreement, such as a public key "ssp1.bundle.ePK.KA" and a secret key "ssp1.bundle.eSK.KA". At this time, the key pair "ssp1.bundle.ePK.KA and ssp1.bundle.eSK.KA" may be configured to have 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 configured to have the same value as the previously used "public key included in ssp1.Cert.KA and the secret key corresponding thereto". In addition, the first SSP 710 may generate a session key ShKey02 by using ssp1.bundle.eSK.KA and ssp2.ePK.KA. When the ssp1.eSK.KA or "key" corresponding to the public key included in ssp1.Cert.Ka is reused for ssp1.bundle.eSK.KA, the session key ShKey02 may also be configured to have the same value as the previously generated ShKey01.

[0234] In operation 7040, the first SSP 710 may configure a bundle to be sent to the second terminal 720 and / or metadata associated with the bundle. At this time, the first SSP 710 may identify the bundle that the first SSP itself expects to send by using the received "bundle transfer code". The bundle to be configured may include "ssp1.Cert.DS". The bundle to be configured may also include "ssp1.bundle.ePK.KA". The bundle to be configured may also include a "transaction ID" for identifying the corresponding session. The bundle to be configured may also optionally include a "bundle transfer code". The bundle to be configured may also 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 supervisor object ID) associated with the bundle to be sent. The bundle to be configured may also optionally include metadata of the corresponding bundle. The bundle to be configured may also optionally include the address of the bundle management server (SPBM Addr).

[0235] According to various embodiments, the bundle configured in operation 7040 (or metadata associated with the bundle) may include a "bundle transfer configuration". At this time, considering the current transmission, the first SSP 710 may update the "bundle transfer history" in the bundle transfer configuration to be included in the bundle, and then insert the updated content into the bundle. Available update examples of the "bundle transfer history" are described as follows. For example, the first SSP 710 may add information about the date and time of the current bundle transfer to the bundle transfer history. The first SSP 710 may increase the information about the number of bundle transfers in the bundle transfer history by 1. The first SSP 710 may add information about at least one of the first terminal 700, the first SSP 710, and the first LBA 720 as information about the terminal sending the bundle to the bundle transfer history, or add information about at least one of the second terminal 750, the second SSP 760, and the second LBA 770 as information about the terminal receiving the bundle. The first SSP 710 may add its own digital signature to ensure the integrity of the update history.

[0236] According to various embodiments, in operation 7040, digital signature data generated using ssp1.Cert.DS may be added to the bundle to be configured. That is, digital signature data generated for some or all elements of the bundle may be added as part of the bundle. Some or all of the bundle to be configured may be encrypted using ShKey02.

[0237] refer to Figure 7, in operation 7045, the first SSP 710 may transfer the bundle generated (configured) in operation 7040 to the second LBA 770 via the first LBA 720. At this time, metadata associated with the transmitted bundle may be further selectively sent. A "bundle transfer code" associated with the transmitted bundle may be further selectively sent. A "bundle transfer configuration" associated with the transmitted bundle may be further sent. For example, the "bundle transfer configuration" may be sent in a separate format (e.g., a message) rather than in a format inserted into the bundle or metadata. At this time, the first SSP 710 may perform the transmission without any updates to the bundle transfer configuration that the first SSP has. Alternatively, the first SSP 710 may update the bundle transfer configuration before sending the bundle transfer configuration. For example, SSP 1 710 may add information about the date and time of the current bundle transfer to the bundle transfer history. The first SSP 710 may increase the information about the number of bundle transfers in the bundle transfer history by 1. The first SSP 710 may add information about at least one of the first terminal 700, the first SSP 710, and the first LBA 720 as information about the terminal sending the bundle to the bundle transfer history, or add information about at least one of the second terminal 750, the second SSP 760, and the second LBA 770 as information about the terminal receiving the bundle. Finally, the first SSP 710 may add its own digital signature to ensure the integrity of the content sent by the first SSP regardless of the update of the bundle transfer configuration. Meanwhile, according to an embodiment, as described in operation 7040, the bundle transfer configuration may be included in the configured bundle, in which case the transmission of the bundle transfer configuration in operation 7045 may be omitted.

[0238] The second SSP 710 may delete the sent bundle. Alternatively, the sent bundle may be configured to be in an unavailable state.

[0239] Figure 8 Shows Figure 5 In the process shown, the detailed process of the process of completing the transmission process after sending the bundle is described. More specifically, Figure 8 An example of a process according to an embodiment of the present disclosure is shown, in which a terminal installs a received bundle and updates related configurations. Figure 8 The process may be referred to as the bundle installation process.

[0240] According to various embodiments, a terminal may include at least one LBA and at least one SSP. Figure 8As shown in the example of , the first terminal 800 may include a first LBA 820 and a first SSP 810, and the second terminal 850 may include a second LBA 850 and a second SSP 860. For example, the first terminal 800 may be a terminal in which a first SSP 810 and a first LBA 820 for controlling the first SSP 810 are installed, and the second terminal 850 may be a terminal in which a second SSP 860 and a second LBA 870 for controlling the second SSP 860 are installed.

[0241] refer to Figure 8 In operation 8000, the second LBA 870 and the second SSP 860 may cooperate with each other to install the bundle in the second terminal 850. When the metadata is sent, the second LBA 870 or the second SSP 860 may verify the content included in the metadata. When the "bundle transfer code" is sent, the second LBA 870 or the second SSP 860 may verify whether the received bundle transfer code is the same as the bundle transfer code used in the past in the same session (e.g., in Figure 7 ) in operation 7025 of . When the "Bundle Transfer Configuration" is sent, the second LBA 870 can transmit the information to the second SSP 860. When the transaction ID is sent, the second LBA 870 or the second SSP 860 can check whether the transaction ID is the same as the transaction ID used in the current session. When at least one of the bundle identifier (SPB ID), the bundle family identifier (SPB family ID), and the bundle family manager identifier (SPB family supervisor object ID) is sent, the second LBA 870 or the second SSP 860 can identify whether the information is the same as the information about the bundle currently to be received. When ssp1.Cert.DS is sent, the second SSP 860 can authenticate the first SSP 810 by verifying the validity of the certificate. When encrypted data is included in the received data, the second SSP 860 can generate a session key ShKey02 by using the received ssp1.bundle.ePK.KA and its own ssp2.eSK.KA, decrypt the encrypted data by using the session key, and then perform verification. When a digital signature is included in the received data, the second SSP 860 can verify ssp1.Cer.DS and then verify the validity of the digital signature by using a certificate.

[0242] In operation 8000, when the necessity for additional Know Your Customer (KYC) authentication for the user is configured in the "Bundle Delivery Configuration" in order to configure the received bundle 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 the bundle management server of the installation of the current bundle in the second SSP 860. The notification may include an identifier of the installed bundle and an 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 the bundle management server to perform KYC authentication. The service provider and / or the bundle management server may activate the bundle installed in the second terminal 850 through a remote management command.

[0243] refer to Figure 8 In operation 8005, the second SSP 860 may selectively update the received bundle delivery configuration. Figure 8 The process of updating the bundle transmission configuration in operation 8005 may be a process that is selectively (optionally) performed. In this case, the process of updating the bundle transmission configuration may be performed or omitted as needed. For example, when the update of the bundle transmission configuration is not required or when the update of the bundle transmission configuration is required but the bundle transmission configuration has been updated by the first terminal and the updated configuration is sent to the second terminal and therefore the second terminal does not need to be updated, the process of updating the bundle transmission configuration may be omitted. Figure 8 Alternatively, when the bundle transmission configuration needs to be updated and needs to be executed by the second terminal, the following procedure may be performed: Figure 8 The process of updating the bundle transfer configuration in operation 8005.

[0244] According to various embodiments, the second SSP may add information about the date and time of the bundle transfer just performed to the bundle transfer history. The second SSP 860 may increase the information about the number of bundle transfers in the bundle transfer history by 1. The second SSP 860 may add information about at least one of the first terminal 800, the first SSP 810, and the first LBA 820 as information about the terminal sending the bundle to the bundle transfer history, or add information about at least one of the second terminal 850, the second SSP 860, and the second LBA 870 as information about the terminal receiving the bundle. Therefore, the second SSP 860 can identify whether the corresponding bundle can be transferred in the future based on the updated bundle transfer configuration (bundle transfer history), and determine whether to perform the process of requesting bundle transfer.

[0245] Fig. 9A configuration of a terminal according to an embodiment of the present disclosure is shown.

[0246] like Fig. 9 As shown, the terminal may include a transceiver 910 and at least one processor 920. The terminal may also include an SSP 930. For example, the SSP 930 may be inserted into the terminal and embedded in the terminal. The at least one processor 920 may be referred to as a controller. However, the configuration of the terminal is not limited to Fig. 9 , and can include Fig. 9 More or fewer elements may be shown. According to some embodiments, transceiver 910, at least one processor 920, and memory (not shown) may be implemented in the form of a single chip. When SSP 930 is embedded, a single chip including SSP 930 may be implemented.

[0247] According to various embodiments, the transceiver 910 can send signals, information and data to the transceiver of another terminal or an external server according to various embodiments of the present disclosure, and receive signals, information and data from the transceiver of another terminal or an external server. The transceiver 910 may include an RF transmitter for up-converting and amplifying the frequency of the transmitted signal and an RF receiver for low-noise amplification of the received signal and down-converting the frequency. However, this is only an embodiment of the transceiver 910, and the elements of the transceiver 910 are not limited to the RF transmitter and the RF receiver. In addition, the transceiver 910 can receive a signal through a radio channel, output the signal to at least one processor 920, and send a signal output from at least one processor 920 through a radio channel.

[0248] According to various embodiments, the transceiver 910 may transmit or receive information about an SSP included in another terminal, authentication information for authenticating another terminal, a bundle transfer code, a bundle transfer configuration, and a bundle to / from a transceiver of another terminal or an external server.

[0249] Meanwhile, at least one processor 920 is an element for overall control of the terminal. According to various embodiments disclosed above, at least one processor 920 may control the overall operation of the terminal.

[0250] Meanwhile, the SSP 930 may include a processor or a controller for installing and controlling the bundle, or may have an application installed therein.

[0251] According to various embodiments, at least one processor or controller within SSP 930 may determine whether to send a particular bundle by identifying the bundle delivery configuration. In addition, the processor or controller may update the bundle delivery configuration as needed.

[0252] According to various embodiments, at least one processor or controller within the SSP may generate a bundle transfer code for controlling a transmission process of a specific bundle. The bundle transfer code may be mapped to a specific bundle and used to control the process.

[0253] According to various embodiments, at least one processor or controller within the SSP may generate its own SSP information, and identify and verify SSP information of another SSP received from the outside.

[0254] According to various embodiments, at least one processor or controller within the SSP may generate authentication information for authenticating itself and authenticate authentication information of another SSP received from the outside.

[0255] According to various embodiments, the SSP 930 may generate bundles and may install the bundles alone or in cooperation with one or more processors 920. In addition, the SSP 930 may manage the bundles.

[0256] According to various embodiments, the SSP 930 may operate according to the control of the processor 920. Alternatively, the SSP 930 may include a processor or controller for installing and controlling the bundle, or may have applications installed therein. Some or all of the applications may be installed in the SSP 930 or a memory (not shown).

[0257] At the same time, the terminal may also include a memory (not shown), and may store basic programs, applications and data, such as configuration information for terminal operation. In addition, the memory may include a flash memory, a hard disk memory, a multimedia card micro memory, a card memory (e.g., SD memory, XD memory, etc.), a magnetic memory, a disk, an optical disk, a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), a programmable read-only memory (PROM) and an electrically erasable programmable read-only memory (EEPROM) At least one type of storage medium. In addition, the processor 920 may use various types of programs, content and data stored in the memory to perform various operations.

[0258] Fig.10 is a flow chart showing a method for sending a bundle by a first secure element according to an embodiment of the present disclosure. Fig.10 In the reference Figures 1 to 9 The descriptions performed overlap.

[0259] refer to Fig.10 In S1010, the first secure element may identify a bundle to be sent to the second secure element. Figure 6 The operation 6010 is performed the same as described above.

[0260] In S1020, the first secure element may determine whether to allow transmission of the bundle based on the bundle transmission configuration information associated with the bundle. Figure 6 The operation 6010 is performed the same as described above.

[0261] The first secure element may send the bundle to the second secure element based on the determination in S1030. Figures 5 to 7 The same description is performed.

[0262] According to various embodiments, the first secure element may identify whether to generate a bundle transfer code to be used to send the bundle, and generate the bundle transfer code based on the identification.

[0263] According to various embodiments, an operation of sending a bundle transfer code to a second secure element may also be included.

[0264] According to various embodiments, generating the bundle transfer code may include, when the generation of the bundle transfer code is identified, generating the bundle transfer code. At this time, the bundle transfer code may be a pre-configured unique ID of the bundle or a new ID for identifying the bundle.

[0265] According to various embodiments, the bundle transmission configuration information may include at least one of bundle transmission policy information or bundle transmission history information.

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

[0267] According to various embodiments, the bundle transfer history information may include at least one of information on a date and time of bundle transfer or information on a number of bundle transfers.

[0268] According to various embodiments, an operation of updating bundle delivery configuration information may also be included.

[0269] Fig.11 is a flow chart showing a method for receiving a bundle by a second secure element according to an embodiment of the present disclosure. Fig.11 In the reference Figures 1 to 10 The descriptions performed overlap.

[0270] refer to Fig.11 In S1110, the second security element may receive a bundle transfer code for sending the bundle from the first security element. Figure 7 The operation 7010 is performed the same as described above.

[0271] In S1120, the second security element may send information about the second security element to the first security element. Figure 7 The same as described in operation 7020 is performed.

[0272] In S1130, the second security element may receive first authentication information for authenticating the first security element from the first security element. Figure 7 The same as described in operation 7020 is performed.

[0273] In S1140, the second security element may verify the first authentication information. Figure 7 The same as described in operation 7030 is performed.

[0274] In S1150, the second security element may send second authentication information and a bundle transfer code for authenticating the second security element to the first security element based on the verification result. Figure 7 The same as described in operation 7035 is performed.

[0275] The second secure element may include an operation of receiving a bundle from the first secure element in S1160. This is similar to the reference Figure 7 The same is described in operation 7045.

[0276] Fig.12 An example of a method according to an embodiment of the present disclosure is shown, by which two terminals interact with each other in order to send a configuration file to each other.

[0277] like Fig.12 As shown, eSIMs 1203 and 1223 may be installed in terminals 1200 and 1220, and profiles (not shown) may be installed in eSIMs 1203 and 1223. In addition, LPAs 1201 and 1221 may be installed in terminals 1200 and 1220. eSIMs 1203 and 1223 may be controlled by LPAs 1201 and 1221. Users 1205 and 1225 may control profiles installed in eSIMs 1203 and 1223 of respective terminals through LPAs 1201 and 1221. At this time, the first user 1205 and the second user 1225 may be the same as each other. In addition, the first LPA 1201 and the second LPA 1221 may be connected to each other for communication. At this time, the connection method between LPAs is described with reference to the accompanying drawings described below.

[0278] The mobile operator 1260 may be connected to the first RSP server 1240 and the second RSP server 1280, the LPA 1201 of the first terminal 1200 may be connected to the first RSP server 1240, and the LPA 1221 of the second terminal 1220 may be 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 as or different from each other. When one or more operator servers are included in the configuration, each operator server may be connected to each separate RSP server, or at least one operator server may be connected to the same RSP server. Although for convenience, Fig.12 It is shown that each of the RSP servers 1240 and 1280 is configured as a single server, but according to implementations and embodiments, one or more profile provisioning servers (SM-DP+) may be included in the server configuration, or one or more subscription relay servers (SM-DS) for generating a connection between a specific profile provisioning server and a terminal may be included in the server configuration. As described above, in the following figures, various server configurations may be simply represented as a single RSP server.

[0279] Fig.13 The diagram shows a process in which a terminal sends a configuration file to another terminal according to an embodiment of the present disclosure.

[0280] Although not in Fig.13 As shown in Fig.12 As shown, terminals 1300 and 1350 may include an eUICC and an LPA therein.

[0281] Although not in Fig.13 , but the first terminal 1300 may have a "profile transmission configuration". The "profile transmission configuration" may be included in the profile or profile metadata, may exist in an independent area instead of the profile and profile metadata, or may be stored in the profile, profile metadata, and independent area in an overlapping or separate manner. The "profile transmission configuration" may also include one or more signature information generated based on the corresponding information. The one or more signature information may be information generated by, for example, an RSP server, a mobile operator, a terminal manufacturer, an eUICC, or an eUICC manufacturer. In addition, the one or more signature information may also include, for example, authentication information of the RSP server, a mobile operator, a terminal manufacturer, an eUICC, or an eUICC manufacturer.

[0282] According to various embodiments, the "profile transfer configuration" may be acquired at a necessary time point in a state where the profile transfer configuration is not pre-occupied by the terminal. At this time, according to a request from the terminal, the "profile transfer configuration" may be generated by the mobile operator, the RSP server, or the cooperation between the mobile operator and the RSP server, and sent to the terminal. Alternatively, the "profile transfer configuration" may be generated by cooperation between the terminal and at least one entity of the mobile operator and the RSP server.

[0283] According to various embodiments, the "profile delivery configuration" in the terminal may be updated by the mobile operator, the RSP server, or the cooperation between the mobile operator and the RSP server. Alternatively, the "profile delivery configuration" may be updated by the cooperation between the terminal and at least one entity of the mobile operator and the RSP server. The time point and method of the update may be determined by the policy of the mobile operator, the RSP server, or the terminal manufacturer.

[0284] According to various embodiments, the "profile transfer configuration" is a policy indicating whether a profile can be transferred between devices, and may be generated by a mobile operator, an RSP server, or a collaboration between a mobile operator and an RSP server.

[0285] The "profile transfer configuration" may include factors (or indications) indicating whether the corresponding profile is allowed to be transferred between devices.

[0286] In addition, when the corresponding configuration file is allowed to be transferred between devices, the "configuration file transfer configuration" may further selectively include factors indicating conditions for allowing the transfer.

[0287] Factors may include, for example, factors indicating methods for allowing the transfer of configuration files between devices. The configuration file transfer method between devices may include factors indicating whether online transfer and / or offline transfer are allowed. When both online transfer and offline transfer are allowed, factors indicating which transfer method between devices is preferred may be included. In addition, when both online transfer and offline transfer are allowed, factors indicating whether another method can be automatically executed when one method fails may be included. In addition, when both online transfer and offline transfer are allowed, factors indicating whether user consent should be obtained to execute another method when one method fails may be included. Factors indicating whether re-provisioning can be performed when configuration file transfer between devices fails may be included. When online transfer or offline transfer between devices fails, factors indicating whether re-provisioning can be performed may be included. At this time, factors indicating whether re-provisioning can be automatically performed may be included. In addition, factors indicating whether user consent should be obtained to execute re-provisioning may be included. When all online transfer, offline transfer, and re-provisioning are allowed, configuration of the order of methods may be included. When offline transfer is first attempted and then fails, online transfer may be attempted, and when online transfer also fails, re-provisioning may be attempted. However, this is only an example, and the order of online transfer, offline transfer, and re-provisioning may be configured by various methods. When online transfer, offline transfer and re-provisioning are performed in a predetermined order, a factor indicating whether continuous execution can be performed automatically may be included. Alternatively, when online transfer, offline transfer and re-provisioning are performed in a predetermined order, a factor indicating whether user consent should be obtained whenever continuous execution is performed may be included.

[0288] In another example of the factor, when the terminal sending the profile authenticates the terminal receiving the profile, a factor indicating whether the authentication should be performed using information received from the mobile operator and / or the RSP server may be included. That is, the mobile operator and / or the RSP server may provide authentication information related to the terminal and / or the eUICC that the mobile operator and / or the RSP server can trust and / or verify, and the terminal sending the profile may authenticate whether the terminal and / or the eUICC receiving the profile is a terminal and / or the eUICC that the mobile operator and / or the RSP server can trust based on the information.

[0289] refer to Fig.13, in operation 13000, a configuration file to be sent may be selected. This selection process may be performed by a process in which a user directly selects a configuration file via a user interface (UI) provided by the first terminal 1300, or may be input into the first terminal 1300 through a push input from a remote server, or the first terminal 1300 may access a remote server to read the corresponding information. When the first terminal 1300 provides the UI to the user, a list of all configuration files installed in the terminal may be provided, or only a list of configuration files that can currently be transmitted may be provided through the UI. When a list of configuration files that cannot currently be transmitted is provided, information indicating the possibility of transmission of the configuration files shown in the list may be further provided. In addition to the list of configuration files described above, information about configuration files or information about configuration file transmission policies may also be selectively provided through the UI.

[0290] In operation 13000, the first terminal 1300 can identify whether the configuration file can be transmitted by checking the "configuration file transmission configuration". In addition, the first terminal 1300 can select the configuration file transmission method by checking the "configuration file transmission configuration". For example, the first terminal 1300 can select the direct connection between the first terminal 1300 and the second terminal 1350 as the configuration file transmission method. At this time, the available direct connection may include, for example, Bluetooth, Wi-Fi, and NFC. The first terminal 1300 can select the remote connection between the first terminal 1300 and the second terminal 1350 as the configuration file transmission method. For example, a relay server may exist between the first terminal 1300 and the second terminal 1350. The relay server may be a single RSP server and / or multiple RSP servers. Alternatively, the relay server may be a predetermined server for sending a single message and / or multiple messages. Alternatively, the relay server may be a combination of a single RSP server and / or multiple RSP servers and / or a predetermined server for sending a single message and / or multiple messages.

[0291] refer to Fig.13 In operation 13005, a connection may be established between the first terminal 1300 and the second terminal 1350. 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, Wi-Fi Direct, LTE device-to-device (D2D), and 5G D2D) or a long distance connection with a remote server (e.g., a relay server) located between the first terminal 1300 and the second terminal 1350.

[0292] refer to Fig.13In operation 13010, the second terminal 1350 may send its own eUICC information (eUICC2.Info1). eUICC2.Info1 may include a predetermined string (eUICC2.Challenge) generated by the eUICC of the second terminal. eUICC2.Info1 may include (multiple) information in the version supported by the eUICC of the second terminal. eUICC2.Info1 may include (multiple) "certificate information that can be used to verify the eUICC of the second terminal". eUICC2.Info1 may include (multiple) "certificate information that can be used to verify the eUICC of another terminal".

[0293] refer to Fig.13 In operation 13015, the first terminal 1300 may identify the received eUICC2.Info1. The first terminal 1300 may identify whether there is a version supported by the first terminal among the eUICC versions supported by the second terminal based on the received eUICC2.Info1. The first terminal 1300 may select a certificate eUICC1.Cert, which may verify the first terminal 1300 based on the received eUICC2.Info1. The first terminal 1300 may select certificate information to be used by the second terminal 1350 based on the received eUICC2.Info1.

[0294] In operation 13015, the first terminal 1300 may generate "first terminal authentication information (Device1.Auth)". The "first terminal authentication information (Device1.Auth)" may include at least a portion or all of eUICC2.Info1. For example, the received eUICC2.Challenge may be included. The "first terminal authentication information (Device1.Auth)" may include a predetermined string (eUICC1.Challenge) generated by the eUICC of the first terminal.

[0295] The "first terminal authentication information (Device1.Auth)" may include certificate information to be used to authenticate the second terminal. The "first terminal authentication information (Device1.Auth)" may include certificate chain information related to the certificate eUICC1.Cert that can authenticate the first terminal.

[0296] Some and / or all of the “first terminal authentication information (Device1.Auth)” may be electronically signed using the certificate eUICC1.Cert of the first terminal, and the electronically signed data may be included as part of the “first terminal authentication information (Device1.Auth)”.

[0297] refer to Fig.13In operation 13020 , the first terminal 1300 may send “first terminal authentication information (Device1.Auth)” to the second terminal 1350 .

[0298] refer to Fig.13 , in operation 13025, the second SSP 1350 may verify the received “first terminal authentication information (Device1.Auth)”. The second terminal 1350 may check the validity of the eUICC1.Cert included in the “first terminal authentication information (Device1.Auth)”, and further check the validity of the signature included in the “first terminal authentication information (Device1.Auth)” by using the eUICC1.Cert. The second terminal 1350 may check whether the value of the eUICC2.Challege included in the “first terminal authentication information (Device1.Auth)” is the same as the value of the eUICC2.Challenge sent by the second terminal in operation 13010.

[0299] The second terminal 1350 may generate "second terminal authentication information (Device2.Auth)". The "second terminal authentication information (Device2.Auth)" may include at least some or all of Device1.Auth. For example, the received eUICC1.Challenge may be included. The "second terminal authentication information (Device2.Auth)" may include information eUICC2.Info2 for checking the qualifications of the eUICC installed in the second terminal. eUICC2.Info2 may be information for determining whether a profile to be received from the first terminal in the future can be normally installed and operated in the eUICC of the second terminal. For example, eUICC2.Info2 may include hardware and / or software information of the eUICC installed in the second terminal.

[0300] “Second terminal authentication information (Device2.Auth)” may include certificate chain information related to the certificate eUICC2.Cert that can authenticate the second terminal.

[0301] Some and / or all of the “second terminal authentication information (Device2.Auth)” may be electronically signed using the certificate eUICC2.Cert of the second terminal, and the electronically signed data may be included as part of the “second terminal authentication information (Device2.Auth)”.

[0302] refer to Fig.13 In operation 13030 , the second terminal 1350 may send “second terminal authentication information (Device2.Auth)” to the first terminal 1300 .

[0303] refer to Fig.13 , in operation 13035, the first terminal 1300 may verify the received “second terminal authentication information (Device2.Auth)”. The first terminal 1300 may check the validity of the eUICC2.Cert included in the “second terminal authentication information (Device2.Auth)”, and further check the validity of the signature included in the “second terminal authentication information (Device2.Auth)” by using the eUICC2.Cert. The first terminal 1300 may check whether the value of the eUICC1.Challege included in the “second terminal authentication information (Device2.Auth)” is the same as the value of the eUICC1.Challenge sent by the first terminal in operation 13020.

[0304] The first terminal 1300 may determine whether a profile to be transmitted by the first terminal can be normally installed and operated in the eUICC of the second terminal by identifying information eUICC2.Info2 for checking eligibility of the eUICC included in the 'second terminal authentication information (Device2.Auth)'.

[0305] refer to Fig.13 In operation 13040, the first terminal 1300 may send a configuration file package to the second terminal 1350. The second terminal 1350 may install the received configuration file package.

[0306] Fig.14 Shows that in the implementation Fig.13 The process shown is a process in which the terminal requests permission from the RSP server to send a configuration file.

[0307] Fig.14 The terminal 1450 shown may be Fig.13 The first terminal 1300 is shown.

[0308] Fig.13 The "profile transfer configuration" shown may include factors indicating whether permission from a mobile operator and / or RSP server is required when transferring a profile between devices. When permission from a mobile operator and / or RSP server is required to transfer a profile between devices, the permission process may be performed as Fig.13 However, the process of receiving the permission of the mobile operator and / or RSP server does not have to be performed as part of operation 13015 and / or operation 13035, and can be performed at Fig.13Information indicating when permission should be received from the mobile operator and / or RSP server may also be included as part of the "profile transfer configuration".

[0309] When transferring configuration files between devices requires permission from the mobile operator and / or RSP service, the following process can be used as Fig.13 The process may be performed as part of operation 13000 and / or operation 13015 and / or 13035.

[0310] refer to Fig.14 , in operation 14000 , a connection may be generated between the RSP server 1400 and the terminal 1450 .

[0311] refer to Fig.14 In operation 14005 , the terminal 1450 may send information eUICC2.Info of the second terminal 1350 receiving the configuration file to the RSP server 1400 .

[0312] When Fig.13 Executed in operation 13015 Fig.14 During the process, eUICC2.Info may include Fig.13 Some and / or all of the information in eUICC2.Info1 shown.

[0313] When Fig.13 Executed in operation 13035 Fig.14 During the process, eUICC2.Info may include Fig.13 Some and / or all of the information in eUICC2.Info1 shown. In addition, it may also include Fig.13 Some and / or all of the eUICC2.Info2 shown.

[0314] In operation 14005, the terminal 1450 may also selectively transmit information about a profile to be transmitted by the terminal to the second terminal 1350 to the RSP server 1400. The information about the profile may include an identifier (ICCID) of the profile and / or profile summary information (profile metadata).

[0315] refer to Fig.14 , in operation 14010, the RSP server 1400 may perform the following process by checking the received eUICC2.Info.

[0316] The RSP server 1400 may determine whether the second terminal 1350 can be mutually authenticated by the RSP server based on the received eUICC2.Info. For example, the RSP server 1400 may determine whether the second terminal 1350 can be mutually authenticated using information of eUICC2.Info1 included in eUICC2.Info.

[0317] The RSP server 1400 may determine whether the profile can be properly installed and operated in the second terminal 1350 based on the received eUICC2.Info. For example, the RSP server 1400 may determine whether the corresponding profile can be normally installed and operated in the second terminal 1350 based on the information of eUICC2.Info2 included in the eUICC2.Info and the received profile information.

[0318] refer to Fig.14 In operation 14015, the RSP server 1400 may send a permission determination result to the terminal 1450. For example, the RSP server 1400 may send a message indicating permission of the profile transmission to the terminal 1450. In another example, the RSP server 1400 may send a message indicating that the profile transmission is not permitted to the terminal 1450. At this time, the message sent from the RSP server 1400 to the terminal 1450 may be electronically signed using the certificate of the RSP server, and the electronically signed value may also be sent to the terminal 1450.

[0319] Fig.15 The process of one terminal sending a configuration file to another terminal according to an embodiment of the present disclosure is conceptually illustrated.

[0320] According to various embodiments, the terminal may include at least one LPA and at least one eSIM. Fig.15 As shown in the example of , the first terminal 1510 may include a first LPA 1530 and a first eSIM 1520 , and the second terminal 1560 may include a second LPA 1580 and a second eSIM 1570 .

[0321] refer to Fig.15 In operation 15000, the first LPA 1530 of the first terminal 1510 and the second LPA 1570 of the second terminal 1560 may perform a preparation process (configuration file transmission preparation process) required for transmitting a configuration file. Fig.16 The detailed description of this process is described in detail.

[0322] refer to Fig.15 In operation 15005, a mutual authentication process may be performed between the first terminal 1510 and the second terminal 1560. Fig.17 The detailed description of this process is described in detail.

[0323] refer to Fig.15 In operation 15010, a configuration file may be sent from the first terminal 1510 to the second terminal 1560, and a process of installing the sent configuration file in the second terminal may be performed. Fig.18 The detailed description of this process is described in detail.

[0324] Fig.16 According to an embodiment of the present disclosure, Fig.15 The detailed process of the configuration file transfer preparation process is shown in the process.

[0325] refer 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.

[0326] According to various embodiments, the first terminal 1610 may have a pre-installed configuration file and may also have metadata associated with the pre-installed configuration file. According to various embodiments, the first terminal 1610 may have a "configuration file identifier" associated with the pre-installed configuration file.

[0327] According to various embodiments, the first terminal 1610 may have a "profile transfer configuration" related to a pre-installed profile. According to various embodiments, the "profile transfer configuration" is a series of policies related to the transfer of corresponding profiles between devices, and may be generated by a mobile operator, an RSP server, or cooperation between a mobile operator and an RSP server. According to various embodiments, the "profile transfer configuration" within the terminal may be updated by a mobile operator, an RSP server, or cooperation between a mobile operator and an RSP server. Alternatively, the "profile transfer configuration" may be updated by cooperation between the terminal and at least one entity of the mobile operator and the RSP server. The time point and / or method of updating the "profile transfer configuration" may be determined by the policy of the mobile operator, the RSP server, or the terminal manufacturer.

[0328] "Configuration file transmission configuration" may include factors (or instructions) indicating whether to allow the corresponding configuration file to be transmitted between devices. In addition, when the corresponding configuration file is allowed to be transmitted between devices, "configuration file transmission configuration" may also selectively include factors indicating conditions for allowing transmission.

[0329] For example, the form of available connection for transmission between devices may be included. In this case, the connection that allows transmission between devices may be a direct device-to-device connection (e.g., a wireless connection such as NFC, Bluetooth, UWB, Wi-Fi Direct, LTE device-to-device (D2D), and 5G D2D, or a wired connection via a cable) or a long-distance connection with a remote server (e.g., a relay server) located between the first LBA 1630 and the second LBA 1690.

[0330] In another example, the form of corresponding configuration file transmission can be configured. The configuration file can be sent in the form of configuration file packaging or configuration file image. The configuration file transmission configuration can include information indicating which schemes are allowed in the available configuration file transmission forms.

[0331] These factors may be electronically signed by at least one of the RSP server, mobile operator, terminal manufacturer, eUICC and eUICC manufacturer. The corresponding electronic signature value may be stored in the first terminal as part of or together with the "profile delivery configuration".

[0332] refer to Fig.16 , in operation 16000, the first LPA 1630 may acquire information about the configuration file to be sent. Alternatively, the information about the configuration file to be sent may be transmitted to the first LPA 1630. For example, when the user receives a user input of selecting a configuration file through a UI provided by the first terminal 1610, the first LPA 1630 may acquire information about the configuration file to be sent, the information about the configuration file to be sent may be input to the first LPA 1630 through a push input from a remote server, or the first LPA 1630 may access a remote server to read the information about the configuration file to be sent.

[0333] refer to Fig.16 In operation 16005, the first LPA 1630 may identify whether the corresponding profile may be transmitted using the “profile transmission configuration”. In addition, the first LPA 1630 may identify the type of available connection for transmitting the corresponding profile between devices by checking the “profile transmission configuration”. In addition, the first LPA 1630 may identify the form (profile image or profile package) in which the corresponding profile may be transmitted by checking the “profile transmission configuration”.

[0334] refer to Fig.16, in operation 16010, the first LPA 1630 may generate a “profile transfer code”. The profile transfer code may include a “profile identifier” of the profile to be sent. The profile transfer code may include an address of an RSP server associated with the profile to be sent. The profile transfer code may also include other information indicating profile attributes (e.g., metadata of the profile or some of the metadata). The profile transfer code may include information required for connection between the two terminals in operation 16020. For example, information required for a Wi-Fi connection between the two terminals may be included (e.g., the SSID and / or BSSID of the second terminal 1660, a pre-shared key for authenticating a connection between the two terminals, an IP address of the second terminal 1660, and a port number for communication between the two terminals).

[0335] refer to Fig.16 In operation 16015, the profile transfer code generated in operation 16010 may be transmitted from the first LPA 1630 to the second LPA 1680. The profile transfer code may be transmitted through various methods.

[0336] For example, the first LPA 1630 may provide information that should 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 may provide the received information to the second user of the second terminal 1660. The second user may input the received information into the second LPA 1680 through the UI of the second terminal 1660.

[0337] Alternatively, the first LPA 1630 may generate information that should be sent to the second LPA 1680 in the form of an image (e.g., a QR code) and display the image on the screen of the first terminal 1610, and the second user may scan the image displayed on the screen of the first terminal 1610 through the second terminal 1660 to send the information to the second LPA 1680.

[0338] Alternatively, the first LPA 1630 may establish a connection between the first LPA 1630 and the second LPA 1680, and transmit information that should be transmitted through the established connection. At this time, the connection established 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, Wi-Fi Direct, LTE device-to-device (D2D), and 5G D2D, or a wired connection through a cable) or a long-distance connection with a remote server (e.g., a relay server) located between the first LPA 1630 and the second LPA 1680.

[0339] refer to Fig.16 , in operation 16020, a connection may be established (or configured) between the first LPA 1630 and the second LPA 1680. When the information required for the connection is transmitted in operation 16015, the first LPA 1630 and the second LPA 1680 may establish the connection using the information. 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, Wi-Fi Direct, LTE device-to-device (D2D), and 5G D2D, or a wired connection through a cable) or a long-distance connection with a remote server (e.g., a relay server) located between the first LPA 1630 and the second LPA 1680.

[0340] Fig.17 According to an embodiment of the present disclosure, Fig.15 The detailed process of mutual authentication between the first terminal 1510 and the second terminal 1560 is performed in the process shown.

[0341] refer 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.

[0342] refer to Fig.17 , in operation 17000 , the second LPA 1780 may request Euicc2.Info1 from the second eSIM 1770 .

[0343] refer to Fig.17 In operation 17005, the second eSIM 1770 may configure Euicc2.Info1. Euicc2.Info1 may include the following information.

[0344] -Certificate information that can be used by the first eSIM to authenticate the second eSIM.

[0345] -Certificate information that can be used by the second eSIM to verify the first eSIM.

[0346] - Version information supported by the second terminal.

[0347] In addition, the second eSIM may provide Euicc2.Info1 to the second LPA 1780 .

[0348] refer to Fig.17, in operation 17010 , the second LPA 1780 may request Euicc2.Challenge from the second eSIM 1770 .

[0349] refer to Fig.17 In operation 17015, the second eSIM 1770 may generate Euicc2.Challenge. Euicc2.Challenge may be a random number generated by the second eSIM 1770. The second eSIM 1770 may provide Euicc2.Challenge to the second LPA 1780.

[0350] refer to Fig.17 In operation 17020, the second LPA 1780 may provide Euicc2.Info1 to the first eSIM 1720 via the first LPA 1730. In addition, the second LPA 1780 may provide Euicc2.Challenge to the first eSIM 1720 via the first LPA 1730. At this time, the first LPA 1730 may also provide the first eSIM 1720 with a “profile identifier” of the profile to be sent.

[0351] refer to Fig.17 , in operation 17025, the following process can be performed.

[0352] The first eSIM 1720 may select the certificate Euicc1.Certificate to be used by the first eSIM through “certificate information that can be used by the second eSIM to authenticate the first eSIM” included in Euicc2.Info1.

[0353] The first eSIM 1720 may select a certificate to be used by the second eSIM through the "certificate information that may be used by the first eSIM to authenticate the second eSIM" included in Euicc2.Info1. At this time, the information that may refer to the selected certificate information or the selected certificate may be referred to as euiccCiPKIdToBeUsed.

[0354] The first eSIM 1720 may identify a “profile transfer configuration” of a profile associated with the received profile identifier. The first eSIM 1720 may check whether the corresponding profile can be transmitted through transmission between devices.

[0355] The first eSIM 1720 may identify whether there is a version supported by the first eSIM by checking the version information supported by the second terminal included in Euicc2.Info1.

[0356] The first eSIM 1720 may generate a session ID (transaction ID) for referring to future communications with the second eSIM.

[0357] The first eSIM 1720 may generate Euicc1.Challenge. Euicc1.Challenge may be a random number generated by the first eSIM 1720.

[0358] The first eSIM 1720 may electronically sign all and / or some of the following values. At this time, the electronic signature may be performed using Euiccl.Certificate.

[0359] -Transaction ID

[0360] -Euicc1.Challenge

[0361] -Euicc2.Challenge

[0362] The first eSIM 1720 may transmit all and / or some of the following data to the second LPA 1780 via the first LPA 1730 .

[0363] -Transaction ID and / or Euicc1.Challenge and / or Euicc2.Challenge, and their electronic signature value

[0364] -euiccCiPKIdToBeUsed

[0365] -Euicc1.Certificate

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

[0367] refer to Fig.17 , in operation 17030 , the second LPA 1780 may send all and / or some of the following data to the second eSIM 1770 .

[0368] -Device1.Auth1

[0369] - a profile identifier of a profile that the first terminal sends to the second terminal

[0370] refer to Fig.17 , in operation 17035, the following process can be performed.

[0371] The second eSIM 1770 may verify the validity of the Euicc1.Certificate.

[0372] The second eSIM 1770 may verify the electronic signature value included in Device1.Auth1.

[0373] The second eSIM 1770 may check whether Euicc2.Challenege included in Device1.Auth1 is identical to Euicc2.Challenge transmitted by the second eSIM in operation 17020 .

[0374] The second eSIM 1770 may select the certificate Euicc2.Certificate to be used by the second eSIM through euiccCiPKIdToBeUsed.

[0375] The second eSIM 1770 may electronically sign all and / or some of the following values. At this time, the electronic signature may be performed using Euicc2.Certificate.

[0376] -Transaction ID

[0377] -Euicc1.Challenge

[0378] -Euicc2.Info2. Euicc2.Info2 may be information that may be used to check eligibility indicating that the "configuration file sent by the first terminal to the second terminal" can be installed and operated in the second terminal. For example, Euicc2.Info2 may include hardware and / or software information of the second eSIM.

[0379] - a profile identifier of a profile that the first terminal sends to the second terminal

[0380] The second eSIM 1770 may transmit all and / or some of the following data to the first eSIM 1720 via the second LPA 1780 and the first LPA 1730 .

[0381] - Transaction ID and / or Euicc1.Challenge and / or Euicc2.Info2 and / or "Profile identifier of the profile to be sent by the first terminal to the second terminal" and its electronic signature value

[0382] -Euicc2.Certificate

[0383] This data may be referred to as Device2.Auth1.

[0384] Fig.18 The embodiment according to the present disclosure is shown Fig.15In the illustrated process, a configuration file is transmitted from the first terminal 1810 to the second terminal 1860 and the transmitted configuration file is installed in the detailed process in the second terminal.

[0385] refer 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.

[0386] refer to Fig.18 , in operation 18000, the following process may be performed.

[0387] The first eSIM 1820 may verify the validity of the Euicc2.Certificate.

[0388] The first eSIM 1820 may verify the electronic signature value included in Device2.Auth1.

[0389] The first eSIM 1820 may check whether Euicc1.Challenege included in Device2.Auth1 is identical to Euicc1.Challenge transmitted by the first eSIM in operation 17025 .

[0390] The first eSIM 1820 may identify the profile identifier included in Device2.Auth1 and specify the profile to be transmitted by the first eSIM. Alternatively, it may be checked whether the profile identifier included in Device2.Auth1 is the same as the profile identifier received in operation 17020.

[0391] The first eSIM 1820 may identify a “profile transfer configuration” of a profile associated with the received profile identifier. The first eSIM 1820 may check whether the corresponding profile may be sent through a transmission between devices. The first eSIM 1820 may identify a connection type for transmission between devices in which the corresponding profile may be transmitted. The first eSIM 1820 may identify a form in which the corresponding profile may be transmitted (e.g., a profile image and / or a profile package).

[0392] The first eSIM 1820 may check eligibility indicating whether the corresponding profile can be normally installed and operated in the second terminal (eg, the second eSIM). At this time, the profile identifier and Euicc2.Info2 may be used to check eligibility.

[0393] Through the above process, the first eSIM 1820 may determine the form in which the corresponding configuration file may be transmitted, and then generate transferOption by using the value. In the following method, transferOption may include information about the form in which the corresponding configuration file may be transmitted.

[0394] - Profile Image

[0395] -Configuration file encapsulation

[0396] The first eSIM 1820 may electronically sign all and / or some of the following values. At this time, the electronic signature may be performed using Euiccl.Certificate.

[0397] -Transaction ID

[0398] -transferOption

[0399] The first eSIM 1820 may send the transaction ID and / or transferOption and its electronic signature value to the second eSIM 1870 via the first LPA 1830 and the second LPA 1880. The sent value may be referred to as Device1.Auth2.

[0400] The first terminal 1810 may identify the received transferOption and receive user consent to transfer the configuration file in a corresponding form.

[0401] refer to Fig.18 , in operation 18005, the following process can be performed.

[0402] The second eSIM 1870 may verify the electronic signature value included in Device1.Auth2.

[0403] The second eSIM 1870 may check the transferOption to identify the form in which the second eSIM receives the configuration file.

[0404] The second eSIM 1870 may generate an encryption key pair (eg, a public key otPK.EUICC2.KA and a key otSK.EUICC2.KA corresponding thereto) required for generating a session key to be used for encrypted communication with the first eSIM 1820 .

[0405] The second eSIM 1870 may electronically sign all and / or some of the following values. At this time, the electronic signature may be performed using Euicc2.Certificate.

[0406] -Transaction ID

[0407] -otPK.EUICC2.KA

[0408] The second eSIM 1870 may send the transaction ID and / or otPK.EUICC2.KA to the first eSIM 1820 via the second LPA 1880 and the first LPA 1830. The sent value may be referred to as Device2.Auth2.

[0409] refer to Fig.18 , in operation 18010, the following process can be performed.

[0410] The first eSIM 1820 may verify the electronic signature value included in Device2.Auth2.

[0411] The first eSIM 1820 may generate an encryption key pair (eg, a public key otPK.EUICC1.KA and a key otSK.EUICC1.KA corresponding thereto) required for generating a session key to be used for encrypted communication with the second eSIM 1870.

[0412] The first eSIM 1820 may generate a session key for encrypted communication with the second terminal 1860 by using the otSK.EUICC1.KA generated by the first eSIM and the received otPK.EUICC2.KA.

[0413] The first eSIM 1820 may prepare a profile image and / or a profile package to be sent to the second terminal 1860. At this time, the prepared profile image or profile package may be referred to as a binding profile package or a binding profile image. In addition, the binding profile package and the binding profile image may be collectively referred to as a binding profile.

[0414] In such preparation, all and / or some of the "profile images and / or profile packages to be sent" may be encrypted by the previously generated session key. In addition, all and / or some of the "profile images and / or profile packages to be sent" may be electronically signed using Euiccl.Certificate, and this value may be included as part of the binding profile. In addition, otPK.EUICC1.KA may be included as part of the binding profile.

[0415] The first eSIM 1820 may send the binding profile to the second LPA 1880 via the first LPA 1830. At this time, metadata related to the corresponding profile may also be sent. At this time, the metadata may be included as part of the binding profile, or may be sent as data separate from the binding profile.

[0416] The first eSIM 1820 may delete the corresponding profile.

[0417] refer to Fig.18 , in operation 18015, the following process can be performed.

[0418] The second terminal 1860 may identify the transmitted metadata.

[0419] The second terminal 1860 may receive user consent related to installing the received binding configuration file.

[0420] The second terminal 1860 may install the received binding profile in the second eSIM 1870. This process may be performed through cooperation between the second LPA 1880 and the second eSIM 1870. When encrypted data exists in the binding profile during this process, the second eSIM 1870 may generate a session key by using otSK.EUICC2.KA and otPK.EUICC1.KA, and then decrypt the data by the key. In addition, when an electronic signature value is included in the binding profile, the second eSIM 1870 may verify the validity of the electronic signature value by using Euiccl.Certificate.

[0421] In the above detailed embodiments of the present disclosure, the elements included in the present disclosure are expressed in the singular or plural, depending on the detailed embodiments presented. However, for ease of description, the singular form or plural form is appropriately selected to the presented situation, and the present disclosure is not limited to the elements expressed in the singular or plural form. Therefore, the elements expressed in the plural may also include a single element, or the elements expressed in the singular may also include multiple elements.

[0422] Although specific embodiments have been described in the detailed description of the present disclosure, various modifications and changes may be made thereto without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be defined as limited to the embodiments, but should be defined by the appended claims and their equivalents.

[0423] It should be understood that the various embodiments of the present disclosure and the terms used therein are not intended to limit the technical features set forth herein to specific embodiments, but include various variations, equivalents or substitutions of the corresponding embodiments. Regarding the description of the accompanying drawings, similar reference numerals may be used to represent similar or related elements. The singular form of the noun corresponding to the project may include one or more of the things, unless the relevant context clearly indicates otherwise. As used herein, 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 the items listed together in a corresponding phrase. As used herein, expressions such as "first", "second", "the first" and "the second" may modify the corresponding elements, regardless of their order or importance, and may be used to simply distinguish the corresponding elements from other elements, and do not limit the corresponding elements. It should be understood that if an element (e.g., a first element) is referred to as being “coupled with / coupled to another element (e.g., the second element)” or “connected with / connected to another element (e.g., the second element)”, it means that the element can be coupled / connected to another element directly or via another element (e.g., the third element), or coupled / connected to another element directly or via another element (e.g., the third element).

[0424] As used herein, the term "module" may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with other terms (e.g., "logic," "block," "component," or "circuit"). A "module" may be the smallest unit of a single integrated component suitable for performing one or more functions, or a portion thereof. For example, according to an embodiment, a "module" may be implemented in the form of an application specific integrated circuit (ASIC).

[0425] Various embodiments of the present disclosure may be implemented as software (e.g., a program) including instructions stored in a storage medium (e.g., an internal memory or an external memory) readable by a machine (e.g., a computer). A machine is a device that can call stored instructions from a storage medium and operate according to the called instructions, and may include a terminal according to various embodiments. When the instructions are executed by a processor (e.g., Fig. 9 When the processor 920 of the processor is executed, the processor may use or not use one or more other components under the control of the processor to perform the function corresponding to the instruction. The instruction may include a code generated by a compiler or a code executed by an interpreter.

[0426] The machine-readable storage medium may be provided in the form of a non-transitory storage medium, wherein the term "non-transitory" simply means that the storage medium is a tangible device and does not include signals, but the term does not distinguish between a case where data is semi-permanently stored in the storage medium and a case where data is temporarily stored in the storage medium.

[0427] The methods according to various embodiments of the present disclosure may be included and provided in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., a compact disk read-only memory (CD-ROM)), or distributed via an application store (e.g., PlayStore). TM ) online distribution (e.g., download or upload), or directly between two user devices (e.g., smart phones). If distributed online, at least a portion of the computer program product can be temporarily generated or at least temporarily stored in a machine-readable storage medium (such as a memory of a manufacturer's server, a server of an application store, or a relay server). According to various embodiments, each of the above-mentioned elements (e.g., a module or a program) may include a single entity or multiple entities. According to various embodiments, one or more of the above-mentioned elements may be omitted, or one or more other elements may be added. Alternatively or additionally, multiple elements (e.g., modules or programs) may be integrated into a single element. In this case, according to various embodiments, the integrated element may still perform one or more functions of each of the multiple elements in the same or similar manner as they were performed by a corresponding one of the multiple elements before integration. According to various embodiments, the operations performed by a module, a program, or another element may be performed sequentially, in parallel, repeatedly, or heuristically, or one or more of the operations may be run or omitted in a different order, or one or more other operations may be added.

Claims

1. A method performed by a first smart security platform SSP, the method comprising: sending a bundle transfer code to be used for sending the secondary platform bundle SPB to the second SSP; receiving information about the second SSP from the second SSP; After receiving the information about the second SSP, sending first authentication information for authenticating the first SSP to the second SSP; receiving, from the second SSP, second authentication information and a bundle transfer code for authenticating the second SSP, wherein the second authentication information is generated based on a verification result of the first authentication information; verifying the second authentication information; as well as When the second authentication information is verified, the SPB is sent to the second SSP.

2. The method according to claim 1, further comprising: identifying whether to generate a bundle transfer code to be used for sending an SSP; as well as Based on the identification, a bundle transfer code is generated.

3. The method of claim 1, further comprising sending a bundle transfer code to a second SSP.

4. The method according to claim 1, further comprising: identifying a secondary platform bundle SPB to be sent to a second SSP; Determining whether to allow transmission of the SPB based on the bundled transmission configuration information associated with the SPB; and Based on the determination, the SPB is sent to the second SSP.

5. A first smart security platform SSP, comprising: Transceiver; as well as at least one processor, connected to the transceiver, Wherein, the at least one processor is configured to: sending a bundle transfer code to be used for sending the secondary platform bundle SPB to the second SSP, receiving information about the second SSP from the second SSP, After receiving the information about the second SSP, sending first authentication information for authenticating the first SSP to the second SSP; receiving second authentication information and a bundle transfer code for authenticating the second SSP from the second SSP, wherein the second authentication information is generated based on a verification result of the first authentication information, verifying the second authentication information, and When the second authentication information is verified, the SPB is sent to the second SSP.

6. The first SSP according to claim 5, wherein: The at least one processor is configured to: Identifies whether to generate a bundle transfer code to be used to send SSP, and Based on the identification, a bundle transfer code is generated.

7. The first SSP of claim 5, wherein: The at least one processor is configured to send a bundle transfer code to a second SSP.

8. The first SSP according to claim 5, in, The at least one processor is configured to generate a bundle transfer code if generating a bundle transfer code is identified, and The bundle delivery code is a preconfigured unique ID of the SSP or a new ID for identifying the SSP.

9. A method performed by a second smart security platform SSP, the method comprising: receiving a bundle transfer code to be used for sending a secondary platform bundle SPB from the first SSP; sending information about the second SSP to the first SSP; After sending the information about the second SSP, receiving first authentication information for authenticating the first SSP from the first SSP; Verifying the first authentication information; Based on the verification result, generating second authentication information for authenticating the second SSP; Sending the second authentication information and the bundle transfer code to the first SSP; as well as In case the second authentication information is verified, the SPB is received from the first SSP.

10. The method according to claim 9, wherein: Receiving the SPB also includes receiving a bundle delivery configuration associated with the SPB.

11. A second smart security platform SSP, comprising: Transceiver; as well as at least one processor, connected to the transceiver, Wherein, the at least one processor is configured to: receiving from the first SSP a bundle transfer code to be used for sending the secondary platform bundle SPB, sending information about the second SSP to the first SSP, After sending the information about the second SSP, receiving first authentication information for authenticating the first SSP from the first SSP, Verify the first authentication information, Based on the verification result, generating second authentication information for authenticating the second SSP, sending the second authentication information and the bundle transfer code to the first SSP, and In case the second authentication information is verified, the SPB is received from the first SSP.

12. The second SSP according to claim 11, wherein: The at least one processor is configured to receive a bundle delivery configuration associated with the SPB.

Images