Method and apparatus for transferring bundles or configuration files online between devices

Abstract

A first terminal for providing a bundle to a second terminal in a wireless communication system, comprising a transceiver and at least one processor, the processor configured to: obtain information on a bundle to be transmitted to the second terminal; determine that the first terminal is capable of transmitting the bundle to the second terminal based on bundle transmission configuration information including an indicator indicating that the first terminal is capable of transmitting the bundle to another terminal; generate a bundle transmission code including identification information of the bundle to be transmitted to the second terminal; transmit the generated bundle transmission code to the second terminal; and upload the bundle to be transmitted to the second terminal to a bundle management server.

Description

Technical Field

[0001] This disclosure relates to a smart security medium, and more specifically, to a method and apparatus for online transfer of bundles or configuration files between smart security media. Background Technology

[0002] To meet the increasing demand for wireless data services following the commercialization of fourth-generation (4G) communication systems, considerable efforts have been made to develop fifth-generation quasi-5G communication systems, or 5G communication systems. This is one reason why "5G communication systems" or "quasi-5G communication systems" are referred to as "super 4G network communication systems" or "post-Long Term Evolution (LTE) systems." To achieve high data rates, 5G communication systems are being developed to operate in ultra-high frequency bands (millimeter wave (mmWave)), such as the 60 GHz band. To reduce radio wave propagation path loss and increase propagation distance in the millimeter wave band, technologies such as beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO are being discussed in 5G communication systems. To improve the system network for 5G communication systems, various technologies have been developed, such as evolved small cells, advanced small cells, cloud radio access networks (Cloud-RAN), ultra-dense networks, device-to-device communication (D2D), wireless backhaul, mobile networks, cooperative communication, cooperative multipoint (CoMP), and receive interference cancellation. Furthermore, other technologies have been developed for 5G communication systems, such as hybrid frequency shift keying (FSK) and quadrature amplitude modulation (QAM) (FQAM) and sliding window superposition coding (SWSC) as advanced coding and modulation (ACM) schemes, and filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA) schemes.

[0003] The Internet has evolved from a human-based network of connections where humans create and consume information to the Internet of Things (IoT), in which distributed components, such as objects, exchange information with each other to process it. The Internet of Everything (IoE) technology is a technology that combines IoT technology and big data processing technology through connectivity using cloud servers. To realize IoT, technological elements such as sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology are required. Therefore, technologies for inter-object connectivity, such as sensor networks, machine-to-machine (M2M) communication, or machine-type communication (MTC), have recently been researched. In the IoT environment, intelligent Internet technology (IT) services can be provided, collecting and analyzing data generated by connected objects and creating new value in human life. Through the convergence and combination of existing information technology (IT) and various industrial applications, IoT can be applied to a wide range of fields, such as smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0004] Various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, M2M communication, or MTC are being implemented using 5G communication technologies such as beamforming, MIMO, or array antennas. Cloud radio access networks (RAN), as an application of big data processing technology, can also be seen as an example of the integration of 5G and IoT technologies.

[0005] As mentioned above, due to the development of mobile communication systems, various services can be provided, thus requiring methods for efficiently providing such services. For example, a method is needed to securely and efficiently transmit bundles or configuration files (or configuration file packages) online between two devices (or terminals). Summary of the Invention

[0006] Technical issues

[0007] An apparatus and method are provided to enable a reliable online transfer service of bundles or configuration files when transferring bundles or configuration files online between security modules included in two electronic devices (or terminals).

[0008] Solution to the problem

[0009] According to embodiments of this disclosure, a first terminal for providing a bundle to a second terminal in a wireless communication system: based on bundle transmission configuration information including an indicator indicating that the first terminal can transmit a bundle to another terminal, obtaining information about the bundle to be transmitted to the second terminal; determining that the first terminal can transmit the bundle to the second terminal; generating a bundle transmission code including identification information of the bundle to be transmitted to the second terminal; transmitting the generated bundle transmission code to the second terminal; and uploading the bundle to be transmitted to the second terminal to a bundle management server, wherein the bundle to be transmitted to the second terminal can be transmitted to the second terminal through the bundle management server so that it can be installed in the second terminal.

[0010] Beneficial effects of this disclosure

[0011] According to various embodiments of this disclosure, a bundle or configuration file installed in one device can be transferred online to another device or installed in another device in a secure and efficient manner. Attached Figure Description

[0012] Figure 1 A schematic diagram of a Smart Security Platform (SSP) according to an embodiment of the present disclosure is shown.

[0013] Figure 2 A schematic diagram showing the internal structure of an SSP according to an embodiment of the present disclosure is provided.

[0014] Figure 3 This is a diagram illustrating an example of a component in a terminal according to an embodiment of the present disclosure, wherein the terminal uses the component to download a bundle to and install it into the SSP.

[0015] Figure 4 This is a diagram illustrating an example of a method by which two terminals and a server, according to embodiments of the present disclosure, enable the online transfer of a bundle from one terminal to another through their interoperation.

[0016] Figure 5 This is a schematic diagram illustrating an example of a process for online transmission of a bundle from one terminal to another according to an embodiment of the present disclosure.

[0017] Figure 6 This illustrates an embodiment according to the present disclosure. Figure 5 The diagram shows the detailed process of preparing the transmission bundle in the process proposed in the paper.

[0018] Figure 7 This illustrates an embodiment according to the present disclosure. Figure 5 The diagram illustrates the process in which the terminal transmitting the bundle uploads the bundle to the server.

[0019] Figure 8 This illustrates an embodiment according to the present disclosure. Figure 5 The diagram illustrates the process of downloading a bundle uploaded to a server to the terminal that will receive the bundle.

[0020] Figure 9 This is an illustration of another example of a process for online transmission of a bundle from one terminal to another, according to embodiments of the present disclosure.

[0021] Figure 10 This illustrates an embodiment according to the present disclosure. Figure 9 The diagram shows the detailed process of preparing the transmission bundle in the process proposed in the paper.

[0022] Figure 11 This illustrates an embodiment according to the present disclosure. Figure 9 The diagram illustrates the process by which the terminal receiving the bundle communicates with the server to receive the license.

[0023] Figure 12 This illustrates an embodiment according to the present disclosure. Figure 9 The diagram illustrates the process in which the terminal transmitting the bundle uploads the bundle to the server.

[0024] Figure 13 This illustrates an embodiment according to the present disclosure. Figure 9 The diagram illustrates the process of downloading a bundle that is uploaded to the server to the terminal that will receive the bundle.

[0025] Figure 14 This is a diagram illustrating the configuration of a terminal on which an SSP is installed, according to some embodiments of the present disclosure.

[0026] Figure 15 This is a diagram illustrating the configuration of a bundle management server according to some embodiments of the present disclosure.

[0027] Figure 16 This is a diagram illustrating an example of a method for two terminals and a server to interact according to an embodiment of the present disclosure to transmit a configuration file online from one terminal to another.

[0028] Figure 17 This is a diagram illustrating the first half of the process of transferring a configuration file online from one terminal to another according to an embodiment of the present disclosure.

[0029] Figure 18 This is a diagram illustrating the latter part of the process of transferring a configuration file online from one terminal to another according to an embodiment of the present disclosure.

[0030] Figure 19 This is a diagram illustrating the configuration of a terminal on which an embedded universal integrated circuit card (eUICC) is installed, according to an embodiment of the present disclosure.

[0031] Figure 20 This is a diagram illustrating the configuration of a Remote Subscriber Identity Module (SIM) Provisioning (RSP) server according to an embodiment of the present disclosure.

[0032] Figure 21 This is a diagram illustrating another example of a process for transferring a configuration file online from one terminal to another according to embodiments of the present disclosure.

[0033] Figure 22 This is a diagram illustrating a detailed process of preparing a transmission configuration file according to an embodiment of the present disclosure.

[0034] Figure 23 This is a diagram illustrating the process by which a second terminal requests an RSP server to transmit a configuration file according to an embodiment of the present disclosure.

[0035] Figure 24 This is a diagram illustrating the process by which a first terminal uploads a configuration file to a second terminal to an RSP server according to an embodiment of the present disclosure.

[0036] Figure 25 This is a diagram illustrating the process by which a second terminal, according to an embodiment of the present disclosure, downloads and installs a prepared configuration file uploaded from an RSP server. Detailed Implementation

[0037] According to embodiments of this disclosure, a first terminal for providing a bundle to a second terminal in a wireless communication system includes a transceiver and at least one processor. The at least one processor is configured to: obtain information about a bundle to be transmitted to the second terminal based on bundle transmission configuration information, including an indicator indicating that the first terminal is capable of transmitting a bundle to another terminal; determine that the first terminal is capable of transmitting the bundle to the second terminal; generate a bundle transmission code including identification information of the bundle to be transmitted to the second terminal; transmit the generated bundle transmission code to the second terminal; and upload the bundle to be transmitted to the second terminal to a bundle management server, wherein the bundle to be transmitted to the second terminal is installed in the second terminal by being transmitted to the second terminal via the bundle management server.

[0038] The bundle transfer configuration information may include at least one of the following: information about the conditions required for bundle transfer between the first terminal and the second terminal, and an indicator indicating whether bundle transfer between the first terminal and the second terminal is permitted via the bundle management server.

[0039] The bundle identification information may include at least one of the following: the identity (ID) of the bundle to be transmitted to the second terminal, the bundle family ID (Fid), and the bundle family managed object ID (Oid). The bundle transmission code may also include at least one of the following: information related to the attributes of the bundle to be transmitted to the second terminal, the address of the bundle management server, information for connecting the first terminal to the second terminal, and information on the encryption algorithms supported by the first terminal.

[0040] At least one processor may also be configured to: transmit bundle delivery authentication information to the bundle management server, the bundle delivery authentication information including at least one of the following: first Smart Security Platform (SSP) information of the first terminal, certificate negotiation information for authentication between the first terminal and the bundle management server, and version information of the first SSP; receive server authentication information from the bundle management server based on the transmitted bundle delivery authentication information; transmit first terminal authentication information and the bundle ID of the bundle to be transmitted to the second terminal to the bundle management server based on the received server authentication information; receive a bundle request message from the bundle management server in response to the bundle management server determining that the first terminal is a terminal capable of transmitting the bundle to the second terminal based on the first terminal authentication information; and upload the bundle to be transmitted to the second terminal to the bundle management server based on the received bundle request message.

[0041] According to another embodiment of this disclosure, a second terminal for receiving bundles from a first terminal in a wireless communication system includes a transceiver and at least one processor. The at least one processor is configured to: receive from the first terminal a bundle transmission code containing identification information of a bundle to be received by the second terminal; perform an authentication process with the bundle management server based on the received bundle transmission code; transmit information about the bundle to be received to the bundle management server in response to the bundle management server successfully performing the authentication process; and receive a first bundle and first bundle information from the bundle management server in response to the bundle management server determining that the bundle to be received by the second terminal corresponds to the bundle to be received.

[0042] The identification information of the bundle to be received by the second terminal may include at least one of the following: the identity (ID) of the bundle to be received by the second terminal, the bundle family ID (Fid), and the bundle family managed object ID (Oid). The bundle transmission code may further include at least one of the following: information related to the attributes of the bundle to be received by the second terminal, the address of the bundle management server, information for connecting the first terminal and the second terminal, and information on the encryption algorithms supported by the first terminal.

[0043] The at least one processor may also be configured to: transmit second Smart Security Platform (SSP) information, including certificate negotiation information for authentication between the bundle management server and the second terminal's second SSP, to the bundle management server; receive server authentication information generated by the bundle management server based on the second SSP information from the bundle management server; transmit second terminal information, including the ID of the second SSP and the ID of the bundle to be received, to the bundle management server based on the server authentication information; and, in response to the bundle management server determining that the ID of the second SSP and the identifier information of the bundle to be received by the second terminal correspond to the ID of the second SSP and the ID of the bundle to be received from the second terminal, respectively, receive the first bundle and the first bundle information from the bundle management server.

[0044] The bundle management server can determine the second terminal as a terminal capable of receiving bundles from another terminal based on the bundle transmission configuration information, and the bundle management server can determine the bundle to be received as a bundle capable of being installed on the second terminal.

[0045] According to another embodiment of this disclosure, a first terminal for providing a configuration file to a second terminal in a wireless communication system includes a transceiver and at least one processor. The at least one processor is configured to: determine a first configuration file to be transmitted to the second terminal from a configuration file installed in the first terminal; transmit configuration information based on the configuration file's identity (ID) including the embedded universal integrated circuit card (eUICC) of the second terminal, determining that the first configuration file can be transmitted to the second terminal via a configuration file management server; in response to verifying the configuration file management server, transmit first terminal authentication information including the first configuration file ID and eUICC ID of the first terminal to the configuration file management server; in response to the configuration file management server verifying that the first terminal is using the first configuration file by using the first configuration file ID and eUICC ID of the first terminal, receive a configuration file request message from the configuration file management server; and based on the configuration file request message, transmit a configuration file package of the first configuration file to the configuration file management server.

[0046] The at least one processor may also be configured to receive configuration information from the second terminal, including the ID of the eUICC and the eUICC information of the second terminal, wherein the eUICC information of the second terminal may include information for determining whether the configuration file to be received from the first terminal can be properly installed and operated in the eUICC of the second terminal.

[0047] The at least one processor may also be configured to: transmit the eUICC information of the first terminal to the configuration file management server; receive server authentication information of the configuration file management server generated by the configuration file management server based on the eUICC information of the first terminal; and verify the configuration file management server based on the eUICC information of the first terminal and the server authentication information of the configuration file management server.

[0048] The configuration file package may include at least one of the following: information about the first configuration file, first encryption key generation information used by the first terminal to encode the first configuration file, first public key of the first terminal, second encryption key generation information used by the configuration file management server to encode the first configuration file, and second public key of the configuration file management server.

[0049] According to another embodiment of this disclosure, a second terminal for receiving a configuration file from a first terminal in a wireless communication system includes a transceiver and at least one processor. The at least one processor is configured to: transmit configuration file delivery information, including the identity (ID) of an embedded universal integrated circuit card (eUICC) of the second terminal, to the first terminal; transmit eUICC information of the second terminal to a configuration file management server; receive authentication information from the configuration file management server based on the eUICC information of the second terminal; in response to verification of the configuration file management server based on the authentication information of the configuration file management server, transmit second terminal authentication information, including the ID of the configuration file to be received and the eUICC ID of the second terminal, to the configuration file management server; and receive a configuration file packet for a first configuration file from the configuration file management server based on the second terminal authentication information.

[0050] The second terminal authentication information may include information used to determine whether the configuration file to be received from the first terminal can be properly installed and operated in the eUICC of the second terminal.

[0051] The configuration file package may include at least one of the following: information about the first configuration file, first encryption key generation information used by the first terminal to encode the first configuration file, a first public key of the first terminal, second encryption key generation information used by the configuration file management server to encode the first configuration file, and a second public key of the configuration file management server. At least one processor may also be configured to: when the received configuration file package for the first configuration file is encoded by the first terminal, decode the configuration file package of the first configuration file using the first public key of the first terminal and the private key of the second terminal; and when the configuration file management server encodes the received configuration file package of the first configuration file, decode the configuration file package of the first configuration file using the second public key of the configuration file management server and the private key of the second terminal.

[0052] Embodiments of this disclosure

[0053] In the following description, embodiments of the present disclosure will be described with reference to the accompanying drawings.

[0054] In describing the embodiments, descriptions of technical content well-known in the art to which this disclosure pertains and not directly related to this disclosure will be omitted. By omitting unnecessary descriptions, the key points of this disclosure can be conveyed more clearly without obscuring the subject matter.

[0055] For the same reason, components may be exaggerated, omitted, or shown schematically in the accompanying drawings for clarity. Furthermore, the dimensions of each component do not perfectly reflect the actual dimensions. In the drawings, the same reference numerals denote the same elements.

[0056] The advantages and features of this disclosure, as well as the methods for implementing these advantages and features, can be more readily understood by referring to the following detailed description and accompanying drawings of the embodiments. In this regard, embodiments of this disclosure may take different forms and should not be construed as limited to the description herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the present embodiments of this disclosure to those skilled in the art, and this disclosure will be defined only by the appended claims. Throughout the specification, the same reference numerals denote the same elements.

[0057] Here, it will be understood that the combination of boxes in a flowchart, or the process flowchart, can be executed by computer program instructions. Because these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, the instructions executed by the processor of the computer or other programmable data processing device create units for performing the functions described in the flowchart boxes. The computer program instructions can be stored in a computer-executable or computer-readable storage medium capable of directing the computer or other programmable data processing device to perform its functions in a particular manner, and therefore the instructions stored in the computer-executable or computer-readable storage medium can also generate a manufacturing item containing instruction units for performing the functions described in the flowchart boxes. The computer program instructions can also be loaded into a computer or other programmable data processing device, and therefore, when a series of operations are performed in the computer or other programmable data processing device, the instructions for operating the computer or other programmable data processing device by generating a computer-executable process can provide operations for performing the functions described in the flowchart boxes.

[0058] Furthermore, each box may represent a module, segment, or portion of code that includes one or more executable instructions for performing a specified logical function. It should also be noted that in some alternative implementations, the functions mentioned in a box may occur out of sequence. For example, depending on the functions involved, two boxes shown consecutively may actually execute substantially simultaneously, or these boxes may sometimes execute in reverse order.

[0059] In this document, the term "unit" as used in the embodiments refers to a software component or a hardware component such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC) that performs a specific function. However, the term "unit" is not limited to software or hardware. A "unit" may be configured to reside in an addressable memory medium or to operate one or more processors. Thus, for example, the term "unit" may refer to components such as software components, object-oriented software components, class components, and task components, and may include processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, or variables. The functionality provided by components and "units" may be associated with a small number of components and "units" or may be divided into additional components and "units". Furthermore, components and "units" may be implemented to reproduce one or more central processing units (CPUs) in a device or secure multimedia card.

[0060] In the following text, a base station is an entity that allocates resources to a terminal and can be at least one of a gNode B (gNB), eNode B (eNB), Node B (NB), base station (BS), radio access unit, BS controller, or node on a network. Examples of terminals may include: user equipment (UE), mobile station (MS), cellular phone, smartphone, computer, and multimedia system capable of performing communication functions. This disclosure is not limited to the embodiments described above. Hereinafter, a technique for a terminal to receive broadcast information from a base station in a wireless communication system will be described. This disclosure relates to a communication technology and system for integrating a fifth-generation (5G) communication system with Internet of Things (IoT) technology, wherein the 5G communication system is used to support higher data rates than fourth-generation (4G) communication systems. This disclosure can be applied to smart services based on 5G communication technology and IoT-related technologies (e.g., smart homes, smart buildings, smart cities, smart cars or connected cars, healthcare, digital education, retail businesses, and security and safety-related services).

[0061] In the following description, for ease of description, terms indicating broadcast information, terms indicating control information, terms related to communication coverage, terms indicating state changes (e.g., events), terms indicating network entities, terms indicating messages, and terms indicating components of a device are exemplified. Therefore, the terminology used in this disclosure is not limited, and other terms with the same technical meaning may be used.

[0062] In the following text, for ease of description, some terms and names defined by the 3GPP LTE standard may be used. However, this disclosure is not limited to such terms and names and may be applied equivalently to systems conforming to other standards.

[0063] Wireless communication systems have evolved from providing voice-centric services in their early stages to providing broadband wireless communication services that offer high-speed, high-quality packet data services, such as 3GPP's High Speed ​​Packet Access (HSPA), Long Term Evolution (LTE or Evolved Universal Terrestrial Radio Access (E-UTRA)), LTE Advanced (LTE-A) and LTE-Pro communication standards, 3GPP2's High Rate Packet Data (HRPD) and Ultra Mobile Broadband (UMB), IEEE 802.16e, etc.

[0064] As a representative example of a broadband wireless communication system, the LTE system employs an Orthogonal Frequency Division Multiplexing (OFDM) scheme in the downlink (DL) and a Single-Carrier Frequency Division Multiple Access (SC-FDMA) scheme in the uplink (UL). UL refers to the radio link through which a terminal (UE or MS) transmits data or control signals to a base station (BS) (e.g., eNode B), and DL refers to the radio link through which the BS transmits data or control signals to the terminal. As described above, the multiple access scheme typically allocates and operates time-frequency resources for carrying data or control information from different users to prevent these resources from overlapping; that is, orthogonality is established between them to identify the data or control information of each user.

[0065] As the future communication system following LTE, 5G communication systems must be able to freely reflect the diverse needs of users and service providers. Therefore, they need to support services that meet various requirements. Services considered for 5G communication systems include enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable low-latency communications (URLLC).

[0066] According to some embodiments, eMBB is designed to provide higher data rates than those supported by LTE, LTE-A, or LTE-Pro systems. For example, in a 5G communication system, from a BS's perspective, eMBB should be able to provide a peak data rate of 20Gbps in DL and 10Gbps in UL. Simultaneously, eMBB should provide increased user-perceived data rates. Meeting this requirement may require improvements to various transmission / reception technologies, including further improvements to multiple-input multiple-output (MIMO) transmission technology. Furthermore, eMBB can meet the data rates required in 5G communication systems by using a bandwidth wider than 20MHz in the 3 to 6 GHz band, or equal to or greater than 6 GHz (instead of the 2 GHz currently used by LTE).

[0067] Meanwhile, mMTC is considered to support application services such as IoT in 5G communication systems. To effectively deliver IoT, mMTC requires support for large-scale terminal access within a cell, enhanced terminal coverage, improved battery life, and reduced terminal costs. IoT needs to be able to support a large number of terminals within a cell (e.g., 1,000,000 terminals / km). 2 This is because it connects to various sensors and devices to provide communication capabilities. Furthermore, mMTC-enabled terminals are more likely to be located in shadow areas not covered by cell coverage, such as underground within buildings due to the nature of the service; therefore, these terminals may require wider coverage than other services provided by 5G communication systems. mMTC-enabled terminals should be configured as inexpensive devices and require very long battery life, as frequent battery replacements are difficult.

[0068] Finally, URLLC (a cellular wireless communication service for mission-critical purposes) needs to provide communication with ultra-low latency and ultra-high reliability for use in remote control applications such as robots or machines, industrial automation, unmanaged aircraft, remote healthcare, or emergency alerts. For example, URLLC-enabled services should meet an air interface latency of less than 0.5 milliseconds and simultaneously require 10 -5 Or even lower packet error rates. Therefore, for services supporting URLLC, 5G communication systems need to provide shorter Transmission Time Intervals (TTIs) than those used for other services, while allocating wider resources in the frequency band. However, mMTC, URLLC, and eMBB are examples of different service types, and the service types to which this disclosure applies are not limited to these.

[0069] The services considered in the aforementioned 5G communication system can be interchanged and provided based on a single framework. In other words, for effective resource management and control, services can be integrated, controlled, and transmitted through a single system, rather than operating independently.

[0070] Furthermore, in the following description, one or more embodiments of this disclosure will be described as examples of LTE, LTE-A, LTE Pro, or New Radio (NR) systems; however, one or more embodiments of this disclosure can also be applied to other communication systems with similar technical backgrounds or channel configurations. Moreover, without significantly departing from the scope of this disclosure, embodiments of this disclosure can be applied to other communication systems by modification as determined by one of ordinary skill in the art.

[0071] In this disclosure, modifiers for indicating terms, such as "first," "second," etc., are used to distinguish these terms from each other while describing embodiments. Terms modified by modifiers (e.g., "first," "second," etc.) may refer to different objects. Alternatively, terms modified by modifiers (e.g., "first," "second," etc.) may refer to the same object. In other words, modifiers such as "first," "second," etc., can be used to refer to the same object from different perspectives. For example, modifiers such as "first," "second," etc., can be used to distinguish the same object in terms of function or operation. For example, "first user" and "second user" can refer to the same user.

[0072] Furthermore, in this disclosure, each embodiment is described using a Smart Security Platform (SSP) as an example of a security medium, but the scope of this disclosure is not limited to SSPs. For example, it will be apparent to those skilled in the art that the various embodiments described below can be applied substantially equivalently or similarly to another security medium performing substantially the same or similar functions as an SSP.

[0073] To aid in understanding this disclosure, specific terminology is provided as used in the following description, and these specific terminology may be modified to other forms within the scope of the technical concept of this disclosure.

[0074] A secure element (SE) refers to a security module comprising a single chip capable of storing security information (e.g., mobile network access keys, user identification information (such as ID cards / passports), credit card information, or encryption keys) and using the stored security information to load and operate control modules (e.g., network access control modules (such as Universal Subscriber Identity Module (USIM)), encryption modules, or key generation modules). SEs can be used in various electronic devices (e.g., smartphones, tablets, wearable devices, vehicles, and IoT devices) and provide security services (e.g., access to mobile networks, payments, or user authentication) through security information and control modules.

[0075] SEs can be classified as Universal Integrated Circuit Cards (UICCs), Embedded Secure Elements (eSEs), or SSPs that integrate both UICCs and eSEs. They can also be categorized as removable, embedded, or integrated into a specific device or System-on-Chip (SoC) depending on how the SE is connected to or installed in the electronic device.

[0076] A Universal Integrated Circuit Card (UICC) is a smart card inserted into a mobile communication terminal or similar device for use, and is also referred to as a UICC card. A UICC may include an access control module for accessing a mobile operator's network. Examples of access control modules include a Universal Subscriber Identity Module (USIM), a Subscriber Identity Module (SIM), and an Internet Protocol (IP) Multimedia Service Identity Module (ISIM). A UICC including a USIM is often referred to as a USIM card. Similarly, a UICC including a SIM is often referred to as a SIM card. A SIM can be installed during the manufacturing of the UICC, or the SIM for the mobile communication service to be used can be downloaded to the UICC when the user desires it. Furthermore, multiple SIMs can be downloaded and installed in the UICC, and at least one of the SIMs can be selected and used. A UICC may or may not be fixed to a terminal. A UICC used by being fixed to a terminal is called an embedded UICC (eUICC), and in particular, a UICC embedded in a System-on-a-Chip (SoC) is called an integrated UICC (iUICC), where the SoC includes a communication processor, an application processor, or a single processor architecture integrating both processors. Generally, eUICC and iUICC can refer to UICCs used by being fixed to a terminal and include the function of remotely downloading at least one SIM and selecting one of the downloaded at least one SIM. In this disclosure, UICCs that include the function of remotely downloading at least one SIM and selecting a SIM are collectively referred to as eUICCs or iUICCs. In other words, among UICCs that include the function of remotely downloading and selecting a SIM, UICCs that are fixed or not fixed to a terminal are collectively referred to as eUICCs or iUICCs.

[0077] In this disclosure, the terms UICC and SIM are used interchangeably, and the terms eUICC and eSIM are used interchangeably.

[0078] The eUICC identifier (ID) can be an inherent ID of the eUICC embedded in the terminal, and can be referred to as the EID. When a provisioning profile is pre-installed on the eUICC, the eUICC ID can be the provisioning profile's profile ID. Furthermore, in embodiments of this disclosure, when the terminal and the eUICC chip are not separate, the eUICC ID can be the terminal ID. The eUICC ID can refer to a specific security domain of the eUICC chip.

[0079] An embedded secure element (eSE) refers to a fixed SE used by attaching it to an electronic device. eSEs are typically manufactured specifically for the terminal manufacturer upon request and can be manufactured to include an operating system and architecture. eSEs can be remotely downloaded and installed as a service control module in the form of an applet, and the installed service control module can be used for various security services such as e-wallets, ticketing, e-passports, and digital keys. In this disclosure, SEs that can be installed as service control modules are remotely downloaded and are collectively referred to as eSEs in the form of a single chip attached to an electronic device.

[0080] A Smart Security Platform (SSP) represents a single chip capable of comprehensively supporting the functions of UICC and eSE. SSPs can be categorized as removable (removable SSP (rSSP)), embedded (embedded SSP (eSSP)), or integrated (integrated SSP (iSSP)) embedded within a SoC. An SSP may include a main platform (PP) and at least one secondary platform bundle (SPB) operating on the PP. The main platform may include at least one of a hardware platform and a low-level operating system (LLOS), and the secondary platform bundle may include at least one of a high-level operating system (HLOS) and applications driven on the HLOS. The secondary platform bundle is also referred to as an SPB or bundle. The bundle can access the resources of the PP's central processing unit or memory through the main platform interface (PPI) provided by the PP and drive these resources on the PP. Communication applications (such as Subscriber Identity Module (SIM), Universal SIM (USIM), or IP Multimedia SIM (ISIM)) may be installed on the bundle, or various applications (such as e-wallets, ticketing, e-passports, and digital keys) may be installed on the bundle. In this disclosure, SSP may also be referred to as Smart Security Media.

[0081] Depending on the downloaded and installed bundle, the SSP can be used for either the UICC or eSE mentioned above. Furthermore, when multiple bundles are installed and operated simultaneously within a single SSP, the SSP can be used for both UICC and eSE. In other words, when a bundle including a configuration file is operated, the SSP can be used by the UICC to access the mobile operator's network. One or more configuration files (such as the eUICC or iUICC mentioned above) can be remotely downloaded to the UICC bundle, and at least one of one or more configuration files can be selected. Additionally, when a bundle including a service control module (on which an application capable of providing services such as e-wallet, ticketing, e-passport, or digital key is installed on the SSP) is operated, the SSP can be used for eSE. Multiple service control modules can be installed and operated as a whole within a single bundle, or they can be installed and operated in separate bundles.

[0082] Bundles can be downloaded to and installed in an SSP from an external bundle management server (sub-platform bundle manager (SPB manager)) using over-the-air (OTA) technology, or bundles can be transferred from another terminal and installed in the SSP. In this disclosure, the method of installing downloaded or received bundles can be applied equally to removable SSPs (rSSPs) that can be inserted into or removed from a terminal, embedded SSPs (eSSPs) installed in a terminal, and integrated SSPs (iSSPs) included in a SoC installed in a terminal.

[0083] An SSP ID is a unique ID embedded in an SSP within a terminal and can be referred to as an sspID. Furthermore, as in the embodiments of this disclosure, when the terminal and the SSP chip are not separate, the SSP ID can be a terminal ID. Moreover, an SSP ID can refer to a specific bundle ID (SPB ID) within the SSP. Specifically, an SSP ID can refer to a sub-platform bundle loader (SPBL) used to manage the installation, enabling, disabling, and removal of another bundle within the SSP, or a bundle ID that manages bundles. Furthermore, an SSPID can refer to a primary platform identifier within the SSP. An SSP can have multiple SSP IDs, and these multiple SSP IDs can be values ​​derived from a single, unique SSP ID.

[0084] The part number ID is information linked to the SSP embedded in the terminal, and can be used to deduce the manufacturer of the main platform installed on the SSP and the model information of the main platform.

[0085] The secondary platform bundle (SPB) is driven on the SSP by using the resources of the main platform (PP). For example, a UICC bundle can be obtained by encapsulating software, applications, file systems, authentication keys, etc., stored in an existing UICC and the operating system (HLOS) used to operate that UICC. In this disclosure, the SPB may be referred to as a bundle.

[0086] In this disclosure, the bundle can be in the following states.

[0087] [Enabled]

[0088] In this disclosure, the operation of enabling a bundle on a terminal or external server can refer to an operation that changes the state of the SPB to an enabled state so that the terminal can receive services provided by the bundle (e.g., communication services, credit card payment services, or user authentication services from a mobile operator). A bundle in an enabled state can be referred to as an enabled bundle. An enabled bundle can be stored in encoded form in internal or external storage space of the SSP.

[0089] [Active]

[0090] In this disclosure, an activated bundle can be changed to an active state based on external input (e.g., user input, push notifications, requests from applications in the terminal, authentication requests from mobile operators, or PP management messages) or operations within the bundle (e.g., timers or polling). An active bundle can represent a bundle in a state where it is loaded from internal or external storage into the SSP's internal drive memory, security information is processed using the SSP's internal security CPU, and security services are provided to the terminal.

[0091] [Disabled]

[0092] In this disclosure, disabling a bundle on a terminal or external server can mean changing the state of a configuration file to a disabled state, preventing the terminal from receiving services provided by the bundle. A SPB in a disabled state can be referred to as a disabled bundle. A bundle in a disabled state can be stored in encoded form in internal or external storage space of the SSP.

[0093] [Deleted]

[0094] In this disclosure, the operation of deleting a bundle on a terminal or external server can refer to an operation that changes the state of the bundle to a deleted state or deletes the bundle and its related data, so that the terminal or external server can no longer activate, enable, or disable the bundle. A bundle in a deleted state can be referred to as a deleted bundle.

[0095] A bundle image, or image, can be used interchangeably with a bundle or as a data object to indicate a specific bundle, and can be referred to as a bundle label, length-value (TLV), or bundle image TLV. When a bundle image is encoded using encryption parameters, it can be called a protected bundle image (PBI) or protected bundle image TLV (PBI TLV). When a bundle image is encoded using encryption parameters that can only be decoded by a specific SSP, it can be called a bound bundle image (BBI) or bound bundle image TLV (BBI TLV). A bundle image TLV can be a dataset representing information about a bundle configured in TLV form.

[0096] A bundle delimiter can be referred to as a factor that matches a bundle ID (SPB ID), a bundle family ID (SPB family ID), a bundle family managed object ID (SPB family managed object ID), a bundle matching ID, or an event ID. The bundle ID (SPB ID) can indicate a unique ID for each bundle. The bundle family ID can indicate an ID that distinguishes the type of bundle (e.g., a telecommunications bundle for accessing a mobile communication network). In this disclosure, the bundle family ID can be referred to as a family ID, FID, or FID. The bundle family managed object ID can indicate an ID that distinguishes the object managing the bundle family ID (e.g., a mobile operator, terminal manufacturer, or a specific organization). In this disclosure, the bundle family managed object ID can be referred to as an OID or Oid. The bundle delimiter can be used as a value for indexing bundles in a bundle management server or terminal.

[0097] Bundle metadata refers to a set of information fragments that reference or describe a bundle. Bundle metadata may include the bundle delimiters mentioned above. Additionally, bundle metadata may include information about the bundle's attributes, characteristics, or configuration. Bundle metadata can also be referred to simply as metadata.

[0098] Configuration files can represent data objects, such as applications, file systems, or authentication key values ​​stored in UICC.

[0099] In this disclosure, a configuration file package can be obtained by packaging the contents of the configuration file into software that can be installed in a UICC. The configuration file package may be referred to as a configuration file TLV or a configuration file package TLV. When the configuration file package is encoded using encryption parameters, it may be referred to as a protected configuration file package (PPP) or a PPPTLV. When the configuration file package is encoded using encryption parameters that can only be decoded by a specific eUICC, it may be referred to as a bound configuration file package (BPP) or a BPP TLV. The configuration file package TLV can be a dataset representing information about configuring the configuration file in TLV form.

[0100] In this disclosure, a configuration file image can represent binary data in which a configuration file package is installed in a UICC. A configuration file image can be referred to as a configuration file TLV or a configuration file image TLV. When a configuration file image is encoded using cryptographic parameters, it can be referred to as a protected configuration file image (PPI) or a protected configuration file image TLV (PPI TLV). When a configuration file image is encoded using cryptographic parameters that can only be decoded by a specific eUICC, it can be referred to as a bound configuration file image (BPI) or a bound configuration file image TLV (BPITLV). A configuration file image TLV can be a dataset representing information about configuring a configuration file in TLV form.

[0101] In this disclosure, the configuration file can be in the following states.

[0102] [Enabled]

[0103] In this disclosure, the operation of enabling a terminal profile can refer to changing the state of the profile to an enabled state, enabling the terminal to receive communication services via the mobile operator providing the profile. A profile in an enabled state may be referred to as an enabled profile.

[0104] [Disabled]

[0105] In this disclosure, disabling a configuration file on a terminal can mean changing the state of the configuration file to a disabled state, preventing the terminal from receiving communication services via the mobile operator providing the configuration file. A configuration file in a disabled state can be referred to as a disabled configuration file.

[0106] [Deleted]

[0107] In this disclosure, the operation of deleting a configuration file on a terminal can be described as changing the state of the configuration file to a deleted state, so that the terminal can no longer enable or disable the configuration file. A configuration file in a deleted state can be referred to as a deleted configuration file.

[0108] In this disclosure, the operation of enabling, disabling, or deleting a configuration file on a terminal can represent an operation in which the state of the configuration file does not immediately change to an enabled, disabled, or deleted state, but is first marked as a to-be-enabled state, a to-be-disabled state, or a to-be-deleted state, and is changed to an enabled state, a disabled state, or a deleted state after a specific operation (e.g., a refresh or reset command) is performed on the terminal or the terminal's UICC. The operation of marking a specific configuration file as a to-be-state (e.g., to-be-enabled, to-be-disabled, or to-be-deleted state) is not limited to marking one to-be-state for one configuration file, and one or more configuration files can be marked as the same or different to-be-states.

[0109] Furthermore, when a terminal marks any configuration file as one or more pending states, two pending state marks can be integrated into one. For example, when any configuration file is marked as both to-be-disabled and to-be-deleted, the configuration file can be marked as a whole as a to-be-disabled and deleted state.

[0110] The terminal can mark one or more configuration files as pending states sequentially or simultaneously. Furthermore, the terminal can also mark one or more configuration files as pending states sequentially or simultaneously and then actually change the state of the configuration files.

[0111] The configuration file separator may be referred to as a factor that matches the configuration file ID, Integrated Circuit Card ID (ICCID), Match ID, Event ID, Activation Code, Activation Code Token, Command Code, Command Code Token, Signed Command Code, Unsigned Command Code, or ISD-P or Configuration File Field (PD). The configuration file ID can indicate a unique ID for each configuration file. The configuration file separator may also include the address of the configuration file providing server (SM-DP+) that can index the configuration files. The configuration file separator may further include the signature of the configuration file providing server (SM-DP+).

[0112] A bundle management server may include the ability to generate bundles, encode generated bundles, generate bundle remote management instructions, or encode generated bundle remote management instructions upon request from a service provider or another bundle management server. A bundle management server providing such functionality may be represented as at least one of the following: a Sub-Platform Bundle Manager (SPBM), a Remote Bundle Manager (RBM), an Image Delivery Server (IDS), a Subscription Manager Data Preparation (SM-DP), a Subscription Manager Data Preparation Enhancement (SM-DP+), a Manager Bundle Server, a Manager SM-DP+, a Bundle Encoding Server, a Bundle Generation Server, a Bundle Provider (BP), a Bundle Provider, and a Bundle Provisioning Certificate (BPC) Owner.

[0113] In this disclosure, the bundle management server can perform the following functions: managing the configuration of certificates and keys used to download bundles from the SSP, install or update bundles, and remotely managing the status of bundles. A bundle management server providing this functionality can be represented as at least one of the following: a Sub-Platform Bundle Manager (SPBM), a Remote Bundle Manager (RBM), an Image Delivery Server (IDS), a Subscription Manager Secure Router (SM-SR), a Subscription Manager Secure Router Enhancement (SM-SR+), an off-card entity of an eUICC profile manager or profile management credential (PMC) owner, and an eUICC manager (EM).

[0114] In this disclosure, a subscription intermediary server can receive registration event requests (event registration requests) from one or more bundle management servers or subscription intermediary servers. One or more subscription intermediary servers can be used in combination, and in this case, the first subscription intermediary server can receive event registration requests not only from the bundle management server but also from a second subscription intermediary server. In this disclosure, the functionality of the subscription intermediary server can be integrated into the bundle management server. A subscription intermediary server providing this functionality can be represented as at least one of the following: a sub-platform bundle manager (SPBM), a remote bundle manager (RBM), a sub-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.

[0115] In this disclosure, a bundle management server can refer to a server that performs functions such as generating, encoding, and transmitting bundles or bundle remote management instructions, as well as configuring SSPs and managing installed bundles. Furthermore, a bundle management server can refer to a server capable of further performing the functions of a subscription intermediary server. Therefore, in the various embodiments of this disclosure below, the operation of the bundle management server and the subscription intermediary server can be performed by a single bundle management server. Alternatively, the functions can be performed individually by multiple separate bundle management servers. Additionally, in the specification of this disclosure, a bundle management server or a subscription intermediary server can be referred to as a bundle server. A bundle server can be one of a bundle management server and a subscription intermediary server, or it can be an apparatus that includes the functions or configurations of both a bundle management server and a subscription intermediary server.

[0116] The term "Remote SIM Provisioning (RSP) Server" may be used to refer to the profile provisioning server and / or profile management server and / or subscription intermediary server described below. The RSP server may be referred to as a subscription manager XX (SM-XX).

[0117] In this disclosure, a configuration file provider server may include the following functions: generating configuration files, encoding the generated configuration files, generating remote management instructions for configuration files, or encoding remote management instructions for the generated configuration files. The configuration file provider server may be referred to as Subscription Manager Data Preparation (SM-DP), Subscription Manager Data Preparation Enhancement (SM-DP+), an off-card entity of a configuration file domain, a configuration file encryption server, a configuration file generation server, a configuration file provider (PP), a configuration file provider, or a configuration file provisioning certificate (PPC) owner.

[0118] In this disclosure, the configuration file management server may include functionality for managing configuration files. The configuration file management server may be referred to as Subscription Manager Secure Routing (SM-SR), Subscription Manager Secure Routing Enhancement (SM-SR+), an off-card entity of the eUICC configuration file manager, a Configuration File Management Credentials (PMC) owner, an eUICC manager (EM), or a Configuration File Manager (PP).

[0119] In this disclosure, the configuration file providing server may also include the functionality of a configuration file management server. Therefore, according to various embodiments of this disclosure, the operation of the configuration file providing server can be performed by the configuration file management server. Similarly, the operation of the configuration file management server or SM-SR can be performed by the configuration file providing server.

[0120] In this disclosure, the subscription intermediary server may be referred to as the Subscription Manager Discovery Service (SM-DS), Discovery Service (DS), Root SM-DS, or Alternate SM-DS. The subscription intermediary server may receive registration event requests (event registration requests) from one or more profile provider servers or subscription intermediary servers. One or more subscription intermediary servers may be used in combination, and in this case, the first subscription intermediary server may receive event registration requests not only from the profile provider server but also from a second subscription intermediary server.

[0121] A service provider may refer to an enterprise that requests a bundle management server to generate a bundle and provides services to a terminal through the bundle. For example, a service provider may refer to a mobile operator that provides communication network access services through a bundle on which a communication application is installed, and may be collectively referred to as all of the mobile operator's Business Support System (BSS), Operation Support System (OSS), Point-of-Sale (POS) terminals, and other IT systems. Furthermore, in this disclosure, a service provider is not limited to referring to only one specific enterprise, but may be used to refer to a group or consortium (or alliance) of one or more enterprises, or a representative of such group or consortium. In this disclosure, a service provider may be referred to as an operator (or OP or Op.), a bundle owner (BO), or an image owner (IO), and each service provider may be configured or assigned at least one of a name and / or a unique identifier (Object Identifier (OID)). When a service provider refers to a group or consortium or representative of one or more enterprises, the name or unique ID of that group or consortium or representative may be a name or unique ID shared by all enterprises belonging to that group or consortium or all enterprises cooperating with that representative.

[0122] Mobile operators may refer to enterprises that provide communication services to terminals, and may be collectively referred to as all of the mobile operator's Business Support System (BSS), Operations Support System (OSS), Point-of-Sale (POS) terminals, and other IT systems. Furthermore, in this disclosure, a mobile operator is not limited to referring to only one specific enterprise providing communication services, but may also refer to a group or consortium (or alliance) of one or more enterprises, or a representative of that group or consortium. In this disclosure, a mobile operator may be referred to as an operator (or OP or Op.), a mobile network operator (MNO), a mobile virtual network operator (MVNO), a service provider (SP), or a profile owner (PO), and each mobile operator may be configured or assigned at least one of a mobile operator name and / or a unique identifier (object identifier (OID)). When a mobile operator refers to a group or consortium or representative of one or more enterprises, the name or unique ID of the group or consortium or representative may be a name or unique ID shared by all enterprises belonging to the group or consortium or all enterprises cooperating with the representative.

[0123] A subscriber can refer to either a service provider that owns the terminal or an end user that owns the terminal. Typically, a terminal owned by a service provider can be called an M2M device, and a terminal owned by an end user can be called a user terminal (consumer device). For M2M devices, there may be end users who do not own the terminal but use it by taking over or leasing it from the service provider; in this case, the subscriber may be the same as or different from the service provider.

[0124] Subscriber intent can be used to refer to either the subscriber's intent to manage the bundle locally or remotely. For local management, subscriber intent can refer to the end-user's intent, while for remote management, subscriber intent can refer to the service provider's intent.

[0125] End-user intents can be used to indicate whether a user agrees to perform local or remote administration.

[0126] A terminal may be referred to as a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, subscriber unit, subscriber station (SS), wireless device, wireless communication device, wireless transmission / reception unit (WTRU), mobile node, mobile device, or other terms. Various embodiments of a terminal may include not only cellular phones, smartphones with wireless communication capabilities, personal digital assistants (PDAs) with wireless communication capabilities, wireless modems, portable computers with wireless communication capabilities, imaging devices (such as digital cameras) with wireless communication capabilities, gaming devices with wireless communication capabilities, music storage and playback appliances with wireless communication capabilities, and internet-connected appliances capable of wireless internet access and browsing, but also portable units or terminals in which a combination of these capabilities is integrated. A terminal may also include, but is not limited to, machine-to-machine (M2M) terminals or machine-type communication (MTC) terminals / devices. In this disclosure, a terminal may also be referred to as an electronic device.

[0127] In this disclosure, an SSP capable of downloading and installing bundled packages can be embedded in an electronic device. When the SSP is not embedded in the electronic device, it can be inserted into and connected to the electronic device, even when physically separate from it. 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 the terminal may be a terminal that includes an SSP capable of downloading and installing bundled packages. The SSP can be embedded in the terminal, and when the terminal and the SSP are detached, the SSP can be inserted into the terminal to connect to it.

[0128] In this disclosure, a UICC capable of downloading and installing configuration files can be embedded in an electronic device. When the UICC is not embedded in the electronic device, a UICC physically separate from the electronic device can be inserted and connected to the electronic device. 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 capable of downloading and installing configuration files. The UICC can be embedded in the terminal, and when the terminal and the UICC are detached, the UICC can be inserted into the terminal to connect to the terminal. The UICC capable of downloading and installing configuration files may be referred to as, for example, an eUICC.

[0129] A Local Bundle Assistant (LBA) can refer to software or applications installed on a terminal or electronic device to control an SSP. This software or application may be referred to as a Local Bundle Manager (LBM).

[0130] A loader (sub-platform bundle loader (SPBL)) can refer to a management bundle used to manage the installation, enabling, disabling, and removal of another bundle within an SSP. An LBA on a terminal or remote server can use a loader to install, enable, disable, or remove specific packages. In this disclosure, the operation of a loader can also be described as the operation of an SSP including a loader.

[0131] Local Profile Assistant (LPA) can refer to software or applications installed on a terminal or electronic device that enable the terminal or electronic device to control the UICC or eUICC.

[0132] In this disclosure, events may be used for the following purposes.

[0133] [When used in relation to a bundle]

[0134] An event can be a term collectively referred to as a bundle download, remote bundle management, or another bundle or SSP management / processing command. An event can be referred to as a Remote SIM Provisioning Operation (RSP Operation) or an event log, and each event can be identified by data including at least one of the following: a corresponding event identifier (Event ID or EventID) or matching identifier (Matching ID or MatchingID), the address (Fully Qualified Domain Name (FQDN), IP address, or Uniform Resource Locator (URL)) of the bundle management server or subscription intermediary server storing the event, or an identifier for each server. Bundle download and bundle installation are used interchangeably. Furthermore, an event type can be used as a term to indicate whether a particular event is a bundle download, remote bundle management (e.g., deletion, enabling, disabling, replacing, or updating), or another bundle or SSP management / processing command. Additionally, an event type can be referred to as OperationType, OperationClass, Event Request Type, Event Class, or Event Request Class.

[0135] Local Bundle Management (LBM) can be referred to as local bundle management, local management, local management commands, local commands, LBM packages, local bundle management packages, local management packages, local management command packages, or local command packages. LBMs can be used to install arbitrary bundles via software installed in a terminal, change the status of a specific bundle (enabled, disabled, or deleted), or modify (update) the contents of a specific bundle (e.g., bundle aliases or bundle metadata). An LBM may include one or more local management commands, and in this case, the bundle governed by the local management command may be the same or different for each local management command.

[0136] Remote Bundle Management (RBM) can be referred to as bundle remote management, remote management, remote management commands, remote commands, RBM packages, bundle remote management packages, remote management packages, remote management command packages, or remote command packages. RBMs can be used to install arbitrary bundles, change the status of specific bundles (enabled, disabled, or deleted), or modify (update) the contents of specific configuration files (e.g., bundle aliases or bundle metadata). An RBM can include one or more remote management commands, and in this case, the bundle governed by the remote management commands can be the same or different for each remote management command.

[0137] The target bundle can be used to reference bundles governed by local or remote administration commands.

[0138] Bundle rules can be used to reference information that needs to be recognized by the endpoint when performing local or remote management of a target bundle. Furthermore, bundle rules can be used interchangeably with bundle policies, rules, or strategies.

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

[0140] An event can be a term collectively referred to as a profile download, remote profile management, or another profile or eUICC management / processing command. An event can be referred to as a Remote SIM Provisioning Operation (RSP Operation) or an event log, and each event can be referred to as data including at least one of the following: a corresponding event identifier (Event ID or EventID) or matching identifier (Matching ID or MatchingID); the address (FQDN, IP address, or URL) of the profile provider server (SM-DP+) or subscription intermediary server (SM-DS) storing the event; a signature of the profile provider server (SM-DP+) or subscription intermediary server (SM-DS); and a digital certificate of the profile provider server (SM-DP+) or subscription intermediary server (SM-DS).

[0141] The data corresponding to an event can be referred to as a command code. Part or all of the process using command codes can be referred to as a command code processing procedure, a command code procedure, or a Local Configuration File Assistant (LPA) application programming interface (API). Configuration file download and configuration file installation are used interchangeably.

[0142] Event type can be used as a term to indicate whether an event is a configuration file download, remote configuration file management (e.g., deletion, enabling, disabling, replacing, or updating), or another configuration file or eUICC management / processing command, and can be referred to as OperationType, OperationClass, Event Request Type, Event Class, or Event Request Class. A path to obtain the terminal event identifier (EventID or MatchingID) or a purpose for use (EventID source or MatchingID source) can be assigned to any event identifier (EventID or MatchingID).

[0143] Local configuration file management (LPM) can be referred to as local configuration file management, local management, local management commands, local commands, LPM packages, local configuration file management packages, local management packages, local management command packages, or local command packages. LPMs can be used to change the state (enabled, disabled, or deleted) of specific configuration files, or to modify the contents of specific configuration files (e.g., configuration file aliases or configuration file metadata), through software installed in a terminal or similar source. An LPM may include one or more local management commands, and in this case, the configuration files governed by the local management commands may be the same or different for each local management command.

[0144] Remote configuration file management (RPM) can be referred to as remote configuration file management, remote management, remote management commands, remote commands, RPM packages, remote configuration file management packages, remote management packages, remote management command packages, or remote command packages. RPMs can be used to change the status (enabled, disabled, or deleted) of a specific configuration file or to modify (update) the contents of a specific configuration file (e.g., configuration file aliases or configuration file metadata). An RPM may include one or more remote management commands, and in this case, the configuration file governed by the remote management command may be the same or different for each remote management command.

[0145] A certificate or digital certificate can refer to a digital certificate used for mutual authentication based on an asymmetric key pair including a public key (PK) and a private key (SK). Each certificate may include one or more PKs, a PK identifier (PKID) corresponding to each PK, an identifier (ID) of the certificate issuer (CI) that issued the corresponding certificate, and a digital signature. The certificate issuer may be referred to as a proof issuer, a certificate authority (CA), or a proof authority. In this disclosure, PK and PKID can be used to indicate the meaning of a storage space that stores a specific PK or a certificate including a specific PK, a portion of a specific PK or a portion of a certificate including a specific PK, the result of an operation on a specific PK (e.g., a hash value) or the result of an operation on a certificate including a specific PK (e.g., a hash value), the result of an operation on a portion of a specific PK (e.g., a hash value) or the result of an operation on a certificate including a specific PK (e.g., a hash value), or data.

[0146] A certificate chain or certificate hierarchy refers to the association between certificates when a certificate issued by a certificate issuer (primary certificate) is used to issue another certificate (secondary certificate), or when a secondary certificate is used to issue a tertiary or higher-level certificate in a connected manner. Here, the CI certificate initially used to issue the certificate can be referred to as the root certificate, top-level certificate, root CI, root CI certificate, root CA, or root CA certificate.

[0147] In describing this disclosure, detailed descriptions of relevant functions or configurations may be omitted where it is believed that such descriptions may unnecessarily obscure the substance of this disclosure.

[0148] In the following sections, various embodiments relating to methods and apparatus for transferring and installing bundles between terminals (also referred to as devices) will be described.

[0149] Figure 1 A schematic diagram of a Smart Security Platform (SSP) according to an embodiment of the present disclosure is shown.

[0150] refer to Figure 1 According to embodiments of this disclosure, terminal 110 may include SSP 120. For example, SSP 120 may be embedded in SoC 130 of terminal 110. Here, SoC 130 may be a communication processor, an application processor, or a processor that integrates both. As another example, SSP 120 may be a removable type 122 in the form of a stand-alone chip, which is not integrated with the SoC, or it may be an embedded type 124 pre-embedded in terminal 110.

[0151] According to various embodiments, the SSP 120 included in the terminal may include at least one of the following: one or more telecommunications bundles, one or more payment bundles, or one or more electronic ID bundles. For example, such as Figure 1 As shown, when the SSP includes multiple telecommunications bundles 140 and 150, the terminal 110 can use the mobile communication network by simultaneously or in time-sharing operation of the multiple telecommunications bundles 140 and 150 according to the configuration. Furthermore, when the SSP 120 includes a payment bundle 170 and an electronic ID bundle 180, the terminal 110 can use the payment bundle 170 to make online payments via a terminal application or offline payments via an external point-of-sale (PoS) device, and can use the electronic ID bundle 180 to authenticate the terminal holder's identity.

[0152] Figure 2 A schematic diagram showing the internal structure of an SSP according to an embodiment of the present disclosure is provided.

[0153] Reference Figure 2 According to embodiments of the present disclosure, SSP 210 may include a primary platform (PP) 220 and at least one of secondary platform bundles (SPBs) 230 and 240 that operate on the PP 220.

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

[0155] According to various embodiments, SPB 230 may include an advanced operating system (HLOS) 232 and at least one application 234 operating thereon.

[0156] According to various embodiments, each of SPBs 230 and 240 can use the main platform interface (PPI) 250 to access the resources of PP 220, such as the central processing unit and memory, and is driven in SSP 210 through the resources.

[0157] Figure 3 This is a diagram illustrating an example of a component in a terminal according to an embodiment of the present disclosure, used by the terminal to download and install a bundle into an SSP.

[0158] refer to Figure 3 According to embodiments of this disclosure, terminal 310 may include SSP 330 and / or LBA 312 for controlling SSP 330. For example, terminal 310 may be a terminal with SSP 330 installed and LBA 312 for controlling SSP 330 installed. SSP 330 may be embedded in terminal 310 or may be removable from terminal 310.

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

[0160] According to various embodiments, when the terminal is released, the sub-platform bundle 335, 337 or 339 may not be installed in SSP 330, but may be remotely downloaded and installed after release.

[0161] According to various embodiments, such as Figure 3 As shown, the bundle may include different FIDs and / or OIDs 341, 342, and 343. These FIDs and / or OIDs 341, 342, and 343 can be used as information required to download and install the bundle. In other words, the SSP 330 or SPBL 333 can allow or deny the download and installation of a specific bundle based on the FIDs and / or OIDs 341, 342, and 343.

[0162] Figure 4 This is a diagram illustrating an example of a method, according to an embodiment of the present disclosure, in which two terminals and a server, through their interoperation, enable the online transfer of a bundle from one terminal to another.

[0163] refer to Figure 4 According to embodiments of this disclosure, a terminal may include at least one LBA and at least one SSP. For example, a first terminal 400 may include a first LBA 410 and a first SSP 420, and a second terminal 450 may include a second LBA 460 and a second SSP 470.

[0164] According to various embodiments, in operations 4020 and 4070, the first LBA 410 and the second LBA 460 can transmit commands to the first SSP 420 and the second SSP 470, or transmit / receive data to / from the first SSP 420 and the second SSP 470. Furthermore, in operations 4030 and 4080, the first SSP 420 and the second SSP 470 can generate, process, or verify data required internally by the first SSP 420 and the second SSP 470.

[0165] According to various embodiments, in operation 4050 (hereinafter referred to as the third operation), the first LBA 410 and the second LBA 460 can be connected to each other to transmit commands to each other, or to transmit data to / receive data from each other. In the third operation, the connection in operation 4050 can be a direct connection between the first terminal 400 and the second terminal 450, or, although not shown, an indirect connection in which an external entity (e.g., an external server) is connected between the first LBA 410 and the second LBA 460. A detailed description of the method of connecting the first LBA 410 and the second LBA 460 will now be described with reference to the accompanying drawings.

[0166] According to various embodiments, a user can transmit commands to or receive information to be provided from the terminal. For example, as in operations 4010 and 4060, a first user 440 and a second user 490 can transmit commands to or receive information to be provided to the user from the first LBA 410 and the second LBA 460 of the first terminal 400 and the second terminal 450. The first user 440 and the second user 490 may represent different users or the same user.

[0167] According to various embodiments, the bundle management server can transmit / receive data to / from terminals. For example, as in operations 4040 and 4090, the first bundle management server 430 and the second bundle management server 480 can receive messages from or transmit messages to the first LBA 410 and the second LBA 460 of the first terminal 400 and the second terminal 450. The first bundle management server 430 and the second bundle management server 480 can be different bundle management servers or the same bundle management server. When the first bundle management server 430 and the second bundle management server 480 are different from each other, as in operation 4000, the two servers can transmit / receive messages.

[0168] Figure 4 An example is shown in which the first bundle management server 430 and the second bundle management server 480 directly transmit / receive messages. However, according to embodiments, one or more other bundle management servers may exist between the two bundle management servers. For example, although not shown, a third bundle management server may exist between the first and second bundle management servers, and when the first or second bundle management server wants to transmit a message to the second or first bundle management server, the first or second bundle management server may first transmit the message to the third bundle management server, and the third bundle management server may transmit the message to the second or first bundle management server. Similarly, multiple bundle management servers and / or relay servers may exist between the first and second bundle management servers.

[0169] In this disclosure, for ease of description, all of one or more bundle management servers may be referred to as a bundle management server. For example, the first bundle management server 430 and the second bundle management server 480 may be collectively referred to as a bundle management server. In this case, for example, the process by which a first terminal transmits / receives messages to / from a second terminal through the first bundle management server and the second bundle management server can be described as the process by which the first terminal transmits / receives messages to / from the second terminal through the bundle management server. Even when there are one or more bundle management servers between the first bundle management server and the second bundle management server as described above, these bundle management servers may be collectively referred to as bundle management servers.

[0170] Figure 5 This is a schematic diagram illustrating an example of a process for online transmission of a bundle from one terminal to another according to an embodiment of the present disclosure.

[0171] refer to Figure 5 The terminal may include at least one LBA and at least one SSP. For example, the first terminal 510 may include a first LBA 530 and a first SSP 520, and the second terminal 560 may include a second LBA 580 and a second SSP 570. (See also...) Figure 4 Details about the bundle management server are described.

[0172] In operation 5000, the first terminal 510 and the second terminal 560 can perform the preparation process required for transmitting the bundle (bundle transmission preparation process or bundle delivery preparation process). The following will refer to... Figure 6 Describe the details of the bundle transfer preparation process.

[0173] In operation 5005, the first terminal 510 can upload the bundled package to be transmitted to the second terminal to the bundled package management server 550. The following will refer to... Figure 7 Describe the details of the corresponding process.

[0174] In operation 5010, the second terminal 560 can download the bundled package uploaded in operation 5005 from the bundled package management server 550 and install the bundled package. The following will refer to... Figure 8 Describe the details of the corresponding process.

[0175] Figure 6 This illustrates an embodiment according to the present disclosure. Figure 5 The diagram shows the detailed process of preparing the transmission bundle in the process proposed in the paper.

[0176] refer to Figure 6The terminal may include at least one LBA and at least one SSP. For example, the first terminal 610 may include a first LBA 630 and a first SSP 620, and the second terminal 660 may include a second LBA 680 and a second SSP 670.

[0177] According to various embodiments, the first terminal 610 may include a pre-installed bundle and also include metadata associated with the pre-installed bundle.

[0178] According to various embodiments, the first terminal 610 may include at least one of a bundle ID (SPB ID), an FID (SPB family ID), or an OID (SPB family managed object ID) associated with the pre-installed bundle.

[0179] According to various embodiments, the first terminal 610 may include a bundle delivery configuration associated with a pre-installed bundle.

[0180] Bundle delivery configuration is information about the feasibility of bundling delivery between devices, and can be generated by the service provider (which is the initial provider), the bundle management server, or a collaboration between the service provider and the bundle management server. The bundle delivery configuration can be updated by the service provider, the bundle management server, or a collaboration between the service provider and the bundle management server. Alternatively, the bundle delivery configuration can be updated through collaboration between the terminal and at least one of the entities of the service provider and the bundle management server. The timing and / or method of the update can be determined by the policies of the service provider, the bundle management server, and the terminal manufacturer.

[0181] Bundle transfer configurations can optionally include factors (or indicators) indicating whether bundle transfer between devices is permitted. Furthermore, bundle transfer configurations can optionally include factors specifying the conditions under which bundle transfer between devices is permitted. For example, factors indicating whether online transfer of bundles between devices is feasible may be included.

[0182] Reference Figure 6 In operation 6000, the first LBA 630 can obtain information about the bundle to be transferred between the devices. Alternatively, information about the bundle to be transferred between the devices can be passed to the first LBA 630. For example, the first LBA 630 can obtain information about the bundle to be transferred by receiving user input from a user selecting a bundle via a user interface (UI) provided by the first terminal 610. Alternatively, information about the bundle to be transferred can be input to the first LBA 630 via push input from a remote server, or the first LBA 630 can read information about the bundle to be transferred by accessing a remote server.

[0183] In operation 6002, the first LBA 630 can identify whether the transfer of bundles between devices is feasible by using the bundle transfer configuration. Furthermore, the first LBA 630 can identify whether online transfer of bundles between devices is feasible by checking the bundle transfer configuration (or bundle transfer settings).

[0184] In operation 6004, the first LBA 630 can generate a bundle transfer code. The bundle transfer code may include a bundle separator for the bundle to be transferred, such as a bundle ID (SPB ID), FID (SPB Family ID), or OID (SPB Family Managed Object ID). Additionally, the bundle transfer code may include other information indicating the attributes of the bundle (e.g., metadata of the bundle or a portion of its metadata). The bundle transfer code may include n addresses (SPBM Addr) of the bundle management server associated with the bundle to be transferred. The bundle transfer code may include information required to connect the two terminals in operation 6010. For example, it may include information required for Wi-Fi connectivity between the two terminals (e.g., the SSID and / or BSSID of the first terminal 610, a pre-shared key for connection authentication between the two terminals, the IP address of the first terminal, and the port number for communication between the two terminals).

[0185] Furthermore, the bundled transmission code may include information (SupportedCryptoInfo) about the encryption algorithms supported by the first terminal (e.g., the first SSP). This information may optionally include at least one of the following: a list of elliptic curve cryptography supported by the first terminal, a list of key negotiation algorithms supported by the first terminal, and a list of encryption algorithms supported by the first terminal.

[0186] Although the first LBA 630 is described in the accompanying drawings for identifying the bundle transmission configuration, this process can be replaced by the following: the first LBA 630 can transmit information about the bundle to be transmitted (e.g., bundle ID) to the first SSP 620, the first SSP 620 can identify the bundle transmission configuration of the bundle corresponding to the received bundle ID, and the first SSP 620 can transmit the identification result to the first LBA 630.

[0187] Although the process of generating bundle transfer code by the first LBA 630 is described, this process can be replaced by the following: the first LBA 630 can transmit the information required for the bundle transfer code to the first SSP 620, the first SSP 620 can transmit the requested information to the first LBA 630, and the first LBA 630 can configure the bundle transfer code based on the information.

[0188] Reference Figure 6 In operation 6005, the bundle transfer code generated in operation 6004 can be transferred from the first LBA 630 to the second LBA 680. The bundle transfer code can be transferred via any of a variety of methods.

[0189] For example, the first LBA 630 can provide information to be transmitted to the second LBA 680 to the first user of the first terminal 610 through the UI of the first terminal 610. The first user can provide the provided information to the second user of the second terminal 660. The second user can input the provided information into the second LBA 680 by using the UI of the second terminal 660.

[0190] Alternatively, the first LBA 630 can generate an image (e.g., a QR code) of information to be transmitted to the second LBA 680 and display the information on the screen of the first terminal 610, and the second user can scan the image displayed on the screen of the first terminal 610 by using the second terminal 660 and transmit the information to the second LBA 680.

[0191] Reference Figure 6 In operation 6010, a connection can be established (or configured) between the first LBA 630 and the second LBA 680. The first LBA 630 and the second LBA 680 can establish a connection using information included in the bundled transfer code. The connection between the first LBA 630 and the second LBA 680 can be a direct connection between devices (e.g., NFC, Bluetooth, UWB, Wi-Fi Direct, LTE device-to-device (D2D), or 5G D2D) or a remote connection in which a remote server (e.g., a relay server) is located between the first LBA 630 and the second LBA 680.

[0192] The diagram shows that operation 6005 is executed first, followed by operation 6010, but this order can be switched. In other words, a connection can be established between the first LBA 630 and the second LBA 680 first (corresponding to operation 6010), and the bundled transfer code can be transferred from the first LBA 630 to the second LBA 680 (corresponding to operation 6005) through the established connection.

[0193] Reference Figure 6 In operation 6015, the second LBA 680 may transmit part and / or all of the received bundle transmission code to the second SSP 670.

[0194] Reference Figure 6The second SSP 670 can identify the received encryption algorithms supported by the first terminal to determine whether an encryption algorithm supported by the second terminal (e.g., the second SSP) exists among them. When an encryption algorithm supported by the second terminal exists among the received encryption algorithms supported by the first terminal, one of the encryption algorithms supported by the second terminal can be selected to configure the same encryption algorithm as the selected encryption algorithm. The selected encryption algorithm may optionally include at least one of the following: elliptic curve information, key negotiation algorithm information, and encryption algorithm information.

[0195] The second SSP 670 can generate a key pair (temporary public key ssp2.ePK.BT and corresponding private key ssp2.eSK.BT) for the second terminal 660 based on the selected encryption algorithm, for later use in generating an encryption key for encrypted communication with the first terminal 610. The second SSP 670 can map the generated key pair to a received bundle ID (SPB ID). The second SSP 670 can generate selected encryption information (ssp2.SelectedCryptoInfo). The selected encryption information may optionally include at least one of the following: part and / or all of the selected encryption algorithm and ssp2.eEPK.BT.

[0196] The second SSP 670 can generate information such as (collectively referred to as an eligibility package or ssp2.EligibilityPackage), which can later be used to determine whether the bundle to be transmitted by the first terminal 610 can be received from the RSP server and installed.

[0197] The qualification package may include certificate negotiation information of the second terminal 660, which will be used later when the RSP server and the second terminal 660 communicate with each other. The certificate negotiation information may optionally include at least one of the following: information relating to a certificate that can be used to verify the second SSP, information relating to a certificate that the second SSP can use to verify the RSP server, information relating to a key negotiation algorithm supported by the second SSP, and information relating to an encryption algorithm supported by the second SSP.

[0198] The qualification package may include information that can be used to determine whether a particular bundle can be properly installed and / or operated in the second terminal 660. This information may optionally include at least one of the following: the SSP ID of the second SSP and the part number ID of the second SSP.

[0199] In operation 6020, the second SSP can generate ReceiverInfo. ReceiverInfo may optionally include at least one of the following: the selected encryption information (ssp2.SelectedCryptoInfo) and the eligibility package (ssp2.EligibilityPackage).

[0200] Reference Figure 6 In operation 6025, the second SSP 670 can transmit ReceiverInfo to the first LBA 630 via the second LBA 680.

[0201] Figure 7 This illustrates an embodiment according to the present disclosure. Figure 5 The diagram illustrates the process in which the terminal transmitting the bundle uploads the bundle to the server.

[0202] refer to Figure 7 The terminal may include at least one LBA and at least one SSP. For example, the first terminal 710 may include a first LBA 730 and a first SSP 720, and the second terminal 760 may include a second LBA 780 and a second SSP 770. (Already referenced) Figure 4 Details about the bundle management server are described.

[0203] Reference Figure 7 In operation 7000, the first LBA 730 can request SSP information (SspInfo) from the first SSP 720.

[0204] When requesting SSP information (SspInfo) from the first SSP 720, the first LBA 730 can notify the first SSP 720 to perform an inter-device bundle transfer. Similarly, when requesting SSP information (SspInfo) from the first SSP 720, the first LBA 730 can notify the first SSP 720 to perform an online inter-device bundle transfer. For example, the request message may include an indicator indicating that an inter-device bundle transfer should be performed. As another example, the request message may include an indicator indicating that an online inter-device bundle transfer should be performed. The request message may include an indicator, or the value of the indicator may be configured to 1, thereby notifying the first SSP 720 to perform either an inter-device bundle transfer or an online inter-device bundle transfer.

[0205] The first LBA 730 can provide the first SSP 720 with information about the bundle to be transmitted. This information may include at least one of FID (SPB Family ID) and OID (SPB Family Managed Object ID).

[0206] Operation 7000 can be performed Figure 6 All the procedures described herein can be executed automatically immediately afterward, or they can be executed after receiving external input. Here, external input can be user input entered by the first user of the first terminal 710 through the UI provided by the first terminal 710, or push input from a remote server to the first LBA 730. In addition, operation 7000 can be initiated when the first LBA 730 accesses the remote server.

[0207] Reference Figure 7 In operation 7005, the first SSP 720 can generate its SSP information (ssp1.SspInfo) and transmit the SSP information to the bundle management server (SPBM) 750 through the first LBA 730.

[0208] SSP information may include information about the first SSP 720 to be provided for bundle transmission. Here, the SSP information may include information for the certificate negotiation process (certificate negotiation information), in which the first SSP 720 performs the certificate negotiation process to communicate with the bundle management server 750. The certificate negotiation information may include certificate information that can be used by the first SSP 720 to verify the bundle management server 750 and / or certificate information that can be used by the bundle management server 750 to verify the first SSP 720. Furthermore, the certificate negotiation information may also include a list of key negotiation algorithms supported by the first SSP 720, and a list of encryption algorithms supported by the first SSP 720.

[0209] SSP information may also include SSP version information, which includes at least one version of a standard supported by the loader and the main platform included in the first SSP 720.

[0210] According to an embodiment, the first SSP 720 can transmit SSP information to the bundle management server 750 via the first LBA 730.

[0211] In operations 7000 to 7005, the first LBA 730 can request SSP information from the first SSP 720, the first SSP 720 can generate its own SSP information, and the first SSP 720 can transmit the SSP information to the bundle management server 750 through the first LBA 730. However, according to an embodiment, the first LBA 730 can generate its own SSP information and transmit it to the bundle management server 750.

[0212] Reference Figure 7In operation 7010, the bundle management server 750 can identify the received SSP information, generate server authentication information (SPBM.Auth1) based on the SSP information, and transmit the server authentication information to the first LBA 730.

[0213] Server authentication information may include at least one of the following:

[0214] a) A key protocol certificate (referred to as SPBM.Cert.KA) can be used to verify SPBM itself as well as the certificate required to verify the key protocol certificate.

[0215] b) Certificate information (referred to as CiPkIdToBeUsed), which can be used by SPBM to verify the first SSP.

[0216] c) Encryption algorithm information (referred to as CryptoToBeUsed), which is used by the SPBM to perform encrypted communication with the first SSP.

[0217] According to an embodiment, the bundle management server 750 can transmit server authentication information to the first LBA 730.

[0218] Reference Figure 7 In operation 7015, the first LBA 730 can transmit server authentication information to the first SSP 720. Additionally, the first LBA 730 can also transmit the bundle separator (spbId) of the bundle to be transmitted to the first SSP 720.

[0219] According to an embodiment, the first SSP 720 may perform at least one of the following specified operations.

[0220] a) It can identify the validity of the received SPBM.Cert.KA.

[0221] (b) You may choose to verify at least one of the first SSP's signing certificates (ssp1.Cert.DS) based on the received CiPkIdToBeUsed.

[0222] c) It can identify the received CryptoToBeUsed and generate an encryption key pair, namely, a public key ssp1.ePK.KA and a private key ssp1.eSK.KA, which is used to generate an encryption key for encrypted communication with the bundle management server 750. Furthermore, the first SSP 720 can generate ShKeyM1 using ssp1.eSK.KA and the key protocol public key included in SPBM.Cert.KA. ShKeyM1 is the session key for encrypted communication with the bundle management server 750.

[0223] In operation 7020, the first SSP 720 may generate first terminal authentication information (Device1.Auth) and transmit the first terminal authentication information (Device1.Auth) to the first LBA 730. The first terminal authentication information (Device1.Auth) may include at least one of the following information.

[0224] a)ssp1.Cert.DS

[0225] b)ssp1.ePK.KA

[0226] c) Refer to the transaction ID of the current session

[0227] d) SSP ID of the first SSP 720

[0228] e) Bundle separator to be transmitted

[0229] It is possible to digitally sign part or all of the first terminal authentication information (Device1.Auth), so that the integrity of the information can be guaranteed by using ssp1.Cert.DS, and the digitally signed data can be added as part of the first terminal authentication information (Device1.Auth).

[0230] In addition, part or all of the first terminal authentication information (Device1.Auth) can be encoded using the generated session key ShKeyM1.

[0231] According to an embodiment, the first SSP 720 can transmit first terminal authentication information (Device1.Auth) to the first LBA 730.

[0232] Reference Figure 7 In operation 7025, the first LBA 730 can transmit the first terminal authentication information (Device1.Auth) to the bundle management server 750. The first LBA 730 can also transmit ssp2.EligibilityPackage to the bundle management server 750. Details regarding ssp2.EligibilityPackage have been referenced in [reference missing]. Figure 6 The description is provided. The first LBA 730 can also transmit the bundle separator of the bundle to be transmitted to the bundle management server 750.

[0233] Reference Figure 7 In operation 7030, the bundle management server 750 may perform at least one of the following procedures.

[0234] a) The bundle management server can verify the validity of ssp1.Cert.DS included in the first terminal authentication information (Device1.Auth). Furthermore, when the first terminal authentication information (Device1.Auth) includes a digital signature, the bundle management server can verify the validity of the signature using ssp1.Cert.DS.

[0235] b) When the first terminal authentication information (Device1.Auth) includes encoded data, the bundle management server can generate a session key ShKeyM1 for encrypted communication with the first terminal by using ssp1.ePK.KA and a private key corresponding to the public key of the key protocol included in SPBM.Cert.KA, and decode the encoded data by using the session key.

[0236] c) The bundle management server can identify and / or store the received transaction ID and / or the SSPID of the first SSP.

[0237] d) The bundle management server can identify and / or store the bundle separators of the bundles to be transmitted by the first terminal.

[0238] In operation 7030, the bundle management server 750 may also perform at least one of the following processes.

[0239] a) The bundle management server can verify whether the first terminal (e.g., the first SSP) is a legitimate entity using the current bundle by using the SSP ID of the first SSP and the bundle separator of the bundle to be transmitted by the first terminal.

[0240] b) The bundle management server can verify whether the bundle to be transmitted by the first terminal is a bundle that can be transmitted online.

[0241] c) The bundle management server can verify at least one of the following by verifying ssp2.EligibilityPackage: whether certificate negotiation with the second terminal was successful, and whether the bundle to be transferred by the first terminal was properly installed and / or operated in the second terminal (e.g., the second SSP).

[0242] In operation 7030, the bundle management server 750 may generate a message (referred to as spbRequest) for requesting a bundle from the first terminal 710 and transmit the spbRequest to the first LBA 730. The spbRequest may include at least one of the following information.

[0243] a) The SSP ID of the first SSP

[0244] b) The SSP ID of the second SSP

[0245] c) The bundle separator for the bundle to be transmitted by the first terminal

[0246] d) Transaction ID

[0247] Some and / or all of the information included in the spbRequest can be encoded using ShKeyM1, and ShKeyM1 can be included as part of the spbRequest.

[0248] Some and / or all of the information included in the spbRequest can be digitally signed using SPBM.Cert.DS, and the value of the digital signature can be included as part of the spbRequest.

[0249] According to an embodiment, the bundle management server 750 can transmit a spbRequest to the first LBA 730.

[0250] Reference Figure 7 In operation 7035, the first LBA 730 can transmit a spbRequest to the first SSP 720. In operation 7035, the first LBA 730 can also transmit ssp2.SelectedCryptoInfo to the first SSP 720. (See reference...) Figure 6 The details about ssp2.SelectedCryptoInfo are described.

[0251] According to an embodiment, the first SSP 720 may perform at least one of the following processes.

[0252] a) When spbRequest includes encoded information, the encoded information is decoded using ShKeyM1.

[0253] b) When spbRequest includes a digital signature value, verify the value using SPBM.Cert.DS.

[0254] c) Verify that the SSP ID of the first SSP and / or the SSP ID of the second SSP included in the spbRequest and / or the bundle separator and / or transaction ID of the bundle to be transmitted by the first terminal have the correct values.

[0255] The first SSP 720 can recognize the information included in ssp2.SelectedCryptoInfo.

[0256] The first SSP 720 can be configured as a public key ssp1.ePK.BT and a private key ssp1.eSK.BT as an encryption key pair. According to an embodiment, the value of the encryption key can be the same as the values ​​of ssp1.ePK.KA and ssp1.eSK.KA.

[0257] According to an embodiment, the first SSP 720 can generate a key ShKeyBT for encrypted communication with the bundle management server 750 by using the generated ssp1.eSK.BT and a private key corresponding to the public key included in SPBM.Cert.KA.

[0258] According to an embodiment, the first SSP 720 can generate a key ShKeyBT for encrypted communication with the second terminal 760 by using the generated ssp1.eSK.BT and ssp2.ePK.BT.

[0259] The first SSP 720 can prepare a bundle to be transmitted to the second terminal 760. Some and / or all of the information included in the bundle can be encoded using ShKeyBT. The prepared bundle can be referred to as boundSpbImage.

[0260] The first SSP 720 can delete the prepared bundle.

[0261] The first SSP 720 can delete the bundle and generate a token (called ssp1.Notification) to notify the bundle management server 750 of the deletion.

[0262] In operation 7040, the first SSP 720 can transfer boundSpbImage to the bundle management server 750. The first SSP 720 can also transfer ssp1.ePK.BT to the bundle management server 750. The first SSP 720 can also transfer ssp1.Notification to the bundle management server 750.

[0263] Reference Figure 7 In operation 7045, the bundle management server 750 can verify ssp1.Notification and transmit a response message to the first LBA 730.

[0264] When boundSpbImage is encoded by an encryption key generated using ssp1.eSK.BT and the public key included in SPBM.Cert.KA, the bundle management server 750 can generate an encryption key ShKeyBT using ssp1.ePK.BT and the private key corresponding to the public key included in SPBM.Cert.KA, and then decode the encoded data included in boundSpbImage using the encryption key.

[0265] The boundSpbImage received by the bundle management server 750 can be referred to as a bundle.

[0266] The bundle management server 750 can map some or all of the following information to each other: bundle, bundle separator of the bundle to be transmitted by the first terminal, and SSP ID of the second SSP.

[0267] The bundle management server 750 can transmit response messages to the first LBA 730.

[0268] Reference Figure 7 In operation 7050, the first LBA 730 can notify the second LBA 780 that bundle request initiation is feasible. The first LBA 730 can transmit a message (referred to as a startRequest) to the second LBA 780 to notify that bundle request initiation is feasible. The startRequest may include the SSP ID of the second SSP installed in the second terminal. The startRequest may include a bundle separator for the bundle to be transmitted. The startRequest may include an indicator indicating that bundle request initiation is now feasible. The first LBA can add the indicator to the startRequest, or it can set a specific value to the indicator and then add it to the startRequest, and transmit the startRequest to the second LBA, thereby notifying the second LBA that bundle request initiation is feasible.

[0269] Figure 8 This illustrates an embodiment according to the present disclosure. Figure 5 The diagram illustrates the process of downloading a bundle uploaded to a server to the terminal that will receive the bundle.

[0270] refer to Figure 8 The terminal may include at least one LBA and at least one SSP. For example, the second terminal 860 may include a second LBA 880 and a second SSP 870. (Already referenced) Figure 4 Details about the bundle management server are described.

[0271] Reference Figure 8 In operation 8000, the second LBA 880 can request SSP information (SspInfo) from the second SSP 870.

[0272] When requesting SSP information (SspInfo) from the second SSP 870, the second LBA 880 can notify the second SSP 870 to perform an inter-device bundle transfer. When requesting SSP information (SspInfo) from the second SSP 870, the second LBA 880 can further notify the second SSP 870 to perform an online inter-device bundle transfer. For example, the request message may include an indicator indicating that an inter-device bundle transfer should be performed. As another example, the request message may include an indicator indicating that an online inter-device bundle transfer should be performed. The request message may include an indicator, or the value of the indicator may be set to a specific value, thereby notifying the second SSP to perform an inter-device bundle transfer or an online inter-device bundle transfer.

[0273] The second LBA 880 can provide the second SSP 870 with information about the bundle to be transmitted. This information may include at least one of FID (SPB Family ID) and OID (SPB Family Managed Object ID).

[0274] Reference Figure 8 In operation 8005, the second SSP 870 can generate its SSP information (ssp2.SspInfo) and transmit the SSP information to the bundle management server 850 through the second LBA 880.

[0275] SSP information may include information about the second SSP to be provided for bundle transmission. Here, SSP information may include information (certificate negotiation information) for the second SSP 870 to perform a certificate negotiation process in communication with the bundle management server 850. The certificate negotiation information may include certificate information that the second SSP 870 can use to verify the certificate of the bundle management server 850 and / or certificate information that the bundle management server 850 can use to verify the certificate of the second SSP 870. Furthermore, the certificate negotiation information may also include a list of key negotiation algorithms supported by the second SSP 870, and a list of encryption algorithms supported by the second SSP 870.

[0276] SSP information may also include SSP version information, which includes at least one version of the loader and the standard supported by the main platform included in the second SSP 870.

[0277] According to an embodiment, the second SSP 870 can transmit SSP information to the bundle management server 850 via the second LBA 880.

[0278] In operations 8000 to 8005, the second LBA 880 can request SSP information from the second SSP 870, the second SSP 870 can generate its own SSP information, and the second SSP 870 can transmit the SSP information to the bundle management server 850 through the second LBA 880. However, according to an embodiment, the second LBA 880 can generate its own SSP information and transmit it to the bundle management server 850.

[0279] Reference Figure 8 In operation 8010, the bundle management server 850 can identify the received SSP information, generate server authentication information (SPBM.Auth2) based on the SSP information, and transmit the server authentication information to the second LBA 880.

[0280] Server authentication information may include at least one of the following:

[0281] a) A key protocol certificate (referred to as SPBM.Cert.KA) can be used to verify SPBM itself and the certificate required to verify the key protocol certificate.

[0282] b) Certificate information (referred to as CiPkIdToBeUsed), which can be used by the SPBM to verify the second SSP.

[0283] c) Encryption algorithm information (referred to as CryptoToBeUsed), which is used by the SPBM to perform encrypted communication with the second SSP.

[0284] According to an embodiment, the bundle management server 850 can transmit server authentication information to the second LBA 880.

[0285] Reference Figure 8 In operation 8015, the second LBA 880 can transmit the server authentication information (SPBM.Auth2) to the second SSP 870. The second LBA 880 can also transmit the bundle separator (spbId) of the bundle to be received to the second SSP 870.

[0286] According to an embodiment, the second SSP 870 may perform at least one of the following specified operations.

[0287] a) The validity of SPBM.Cert.KA can be verified.

[0288] (b) You may choose to verify at least one of the signature certificates (ssp2.Cert.DS) of the second SSP based on the received CiPkIdToBeUsed.

[0289] c) It can identify the received CryptoToBeUsed and generate an encryption key pair, namely, a public key ssp2.ePK.KA and a private key ssp2.eSK.KA, which is used to generate an encryption key for encrypted communication with the bundle management server. Furthermore, the second SSP can generate ShKeyM2 using ssp2.eSK.KA and the key protocol public key included in SPBM.Cert.KA. ShKeyM2 is the session key for encrypted communication with the bundle management server.

[0290] In operation 8020, the second SSP 870 can generate second terminal authentication information (Device2.Auth) and transmit the second terminal authentication information (Device2.Auth) to the bundle management server 850. The second terminal authentication information (Device2.Auth) may include at least one of the following information.

[0291] a)ssp2.Cert.DS

[0292] b)ssp2.ePK.KA

[0293] c) Refer to the transaction ID of the current session

[0294] d) SSP ID of the second SSP 870

[0295] e) Bundle separator for the bundle to be received

[0296] It is possible to digitally sign part or all of the second terminal authentication information (Device2.Auth), so that the integrity of the information can be guaranteed by using ssp2.Cert.DS, and the digitally signed data can be added as part of the second terminal authentication information.

[0297] In addition, part or all of the second terminal authentication information (Device2.Auth) can be encoded using the generated session key ShKeyM2.

[0298] According to an embodiment, the second SSP 870 can transmit the second terminal authentication information (Device2.Auth) to the bundle management server 850 via the second LBA 880.

[0299] According to an embodiment, the bundle management server 850 may perform at least one of the following processes.

[0300] a) The bundle management server can verify the validity of ssp2.Cert.DS included in the second terminal authentication information. Furthermore, when the second terminal authentication information includes a digital signature, the bundle management server can verify the validity of the signature using ssp2.Cert.DS.

[0301] b) When the second terminal authentication information includes encoded data, the bundle management server can generate a session key ShKeyM2 for encrypted communication with the second terminal by using ssp2.ePK.KA and a private key corresponding to the public key of the key protocol included in SPBM.Cert.KA, and decode the encoded data by using the session key.

[0302] c) The bundle management server can identify and / or store the received transaction ID and / or the SSPID of the second SSP.

[0303] d) The bundle management server can identify and / or store the bundle separators of the bundles to be received by the second terminal.

[0304] According to an embodiment, the bundle management server 850 may also perform at least one of the following processes.

[0305] a) The bundle management server can identify whether a bundle to be transmitted to the second terminal exists by using the SSP ID of the second SSP.

[0306] b) The bundle management server can identify whether a bundle to be transmitted to the second terminal exists by using the bundle separator of the bundle to be received by the second terminal.

[0307] c) When a bundle needs to be transmitted to a second terminal, the bundle management server can prepare the bundle. (The prepared bundle is called a boundSpbImage.)

[0308] For example, when Figure 7 When the bundle uploaded from the first terminal contains a bundle that maps to the SSP ID of the second SSP and / or a bundle separator for the bundle to be received by the second terminal, such a bundle can be selected.

[0309] Here, when the selected bundle does not require re-encoding, the bundle management server can prepare to transmit the bundle.

[0310] Alternatively, when it is necessary to encode the selected bundle using an encryption key between the bundle management server and the second terminal, the bundle management server can encode part and / or all of the bundle using ShKeyM2 and then prepare the bundle for transmission.

[0311] Alternatively, when it is necessary to encode the selected bundle using an encryption key between the bundle management server and the second terminal, the bundle management server can generate a public key SPBM.ePK.BT and a private key SPBM.eSK.BT as a key pair, generate an encryption key ShKeyBT using SPBM.eSK.BT and ssp2.ePK.KA, encode the portion and / or all of the bundle using the encryption key, and then prepare to transmit the bundle.

[0312] In operation 8025, the bundle management server 850 can transfer boundSpbImage to the second LBA 880. The bundle management server 850 can also transfer SPBM.ePK.BT to the second LBA 880. The bundle management server 850 can also transfer ssp1.ePK.BT to the second LBA 880.

[0313] Reference Figure 8 In operation 8030, a bundle (boundSpbImage) can be installed in the second SSP 870.

[0314] According to an embodiment, when a bundle is encoded using a key for encryption between the bundle management server 850 and the second terminal 860, the second SSP 870 can decode the encoded information using ShKeyM2.

[0315] According to another embodiment, when the bundle is encoded using a key for encryption between the bundle management server 850 and the second terminal 860, the second SSP 870 can generate an encryption key ShKeyBT using SPBM.ePK.BT, and then decode the encoded information using the encryption key.

[0316] According to another embodiment, when the bundle is encoded using a key for encryption between the first terminal and the second terminal, the second SSP 870 can generate an encryption key ShKeyBT using ssp1.ePK.BT, and then decode the encoded information using the encryption key.

[0317] Reference Figure 8In operation 8035, the second SSP 870 can notify the bundle management server 850 of the result of the bundle installation. For example, the second SSP 870 can transmit a message containing the result of the bundle installation (referred to as ssp2.Notification) to the bundle management server 850.

[0318] Figure 9 This is an illustration of another example of a process for online transmission of a bundle from one terminal to another, according to embodiments of the present disclosure.

[0319] refer to Figure 9 The terminal may include at least one LBA and at least one SSP. For example, such as Figure 9 As shown, the first terminal 910 may include a first LBA 930 and a second SSP 920, and the second terminal 960 may include a second LBA 980 and a second SSP 970. (See reference...) Figure 4 Details about the bundle management server are described.

[0320] In operation 9000, the first terminal 910 and the second terminal 960 may perform the preparation process required for transmitting the bundled packet (bundle transmission preparation process). Details regarding the bundled packet transmission preparation process will be referenced below. Figure 10 Describe it.

[0321] In operation 9005, the second terminal 960 can receive a bundle transfer license from the bundle management server 950. The following will refer to... Figure 11 Describe the details of the corresponding process.

[0322] In operation 9010, the first terminal 910 can upload the bundled package to be transmitted to the second terminal to the bundled package management server 950. The following will refer to... Figure 12 Describe the details of the corresponding process.

[0323] In operation 9015, the second terminal 960 can download the bundle uploaded in operation 9010 from the bundle management server 950 and install the bundle. The following will refer to... Figure 13 Describe the details of the corresponding process.

[0324] Figure 10 This illustrates an embodiment according to the present disclosure. Figure 9 The diagram illustrates the detailed process of preparing the transmission bundle, as presented in the process described.

[0325] refer to Figure 10The terminal may include at least one LBA and at least one SSP. For example, the first terminal 1010 may include a first LBA 1030 and a first SSP 1020, and the second terminal 1060 may include a second LBA 1080 and a second SSP 1070.

[0326] According to various embodiments, the first terminal 1010 may include a pre-installed bundle and metadata associated with the pre-installed bundle. According to various embodiments, the first terminal 1010 may include at least one of a bundle ID (SPB ID), an FID (SPB family ID), or an OID (SPB family managed object ID) associated with the pre-installed bundle.

[0327] According to various embodiments, the first terminal 1010 may include a bundle delivery configuration associated with a pre-installed bundle. References have been made to... Figure 6 Details regarding the bundle delivery configuration are described.

[0328] Reference Figure 10 In operation 10000, the first LBA 1030 can obtain information about the bundle to be transferred between devices. Alternatively, information about the bundle to be transferred between devices can be passed to the first LBA 1030. For example, the first LBA 1030 can obtain information about the bundle to be transferred by receiving user input of selecting a bundle via the UI provided by the first terminal 1010, by inputting information about the bundle to be transferred via push input from a remote server, or by reading information about the bundle to be transferred by accessing a remote server.

[0329] In operation 10002, the first LBA 1030 can identify whether the transfer of bundles between devices is feasible by checking the bundle transfer configuration (also known as bundle transfer settings). Furthermore, the first LBA 1030 can identify whether online transfer of bundles between devices is feasible by checking the bundle transfer configuration.

[0330] In operation 10004, the first LBA 1030 may generate a bundle transfer code (or bundle delivery code). The bundle transfer code may include a bundle separator for the bundle to be transferred, such as a bundle ID (SPB ID), FID (SPB Family ID), or OID (SPB Family Managed Object ID). Additionally, the bundle transfer code may include other information indicating the attributes of the bundle (e.g., metadata of the bundle or a portion of its metadata). The bundle transfer code may include n addresses (SPBM Addresses) of the bundle management server associated with the bundle to be transferred.

[0331] Furthermore, the bundled transmission code may include information (SupportedCryptoInfo) about the encryption algorithms supported by the first terminal (e.g., the first SSP). This information may optionally include at least one of the following: a list of elliptic curve cryptography supported by the first terminal, a list of key negotiation algorithms supported by the first terminal, and a list of encryption algorithms supported by the first terminal.

[0332] Reference Figure 10 In operation 10005, the bundle transfer code generated in operation 10004 can be transferred from the first LBA 1030 to the second LBA 1080. The bundle transfer code can be transferred via any of a variety of methods.

[0333] For example, the first LBA 1030 can provide information to be transmitted to the second LBA 1080 to the first user of the first terminal 1010 through the UI of the first terminal 1010. The first user can provide the provided information to the second user of the second terminal 1060. The second user can input the provided information into the second LBA 1080 through the UI of the second terminal 1060.

[0334] Alternatively, the first LBA 1030 can generate an image (e.g., a QR code) of information to be transmitted to the second LBA 1080 and display the information on the screen of the first terminal 1010; and the second user can scan the image displayed on the screen of the first terminal 1010 by using the second terminal 1060 and transmit the information to the second LBA 1080.

[0335] Alternatively, the first LBA 1030 can establish a connection between the first LBA 1030 and the second LBA 1080, and use the established connection to transmit the information to be transmitted. Here, the connection between the first LBA 1030 and the second LBA 1080 can be a direct connection between devices (e.g., NFC, Bluetooth, UWB, Wi-Fi Direct, LTE device-to-device (D2D) or 5G D2D) or a remote connection in which a remote server (e.g., a relay server) is located between the first LBA 1030 and the second LBA 1080.

[0336] Figure 11 This illustrates an embodiment according to the present disclosure. Figure 9 The diagram illustrates the process by which the terminal that received the bundle communicates with the server to receive the license.

[0337] Reference Figure 11The terminal may include at least one LBA and at least one SSP. For example, the second terminal 1160 may include a second LBA 1180 and a second SSP 1170. Details regarding the bundle management server (SPBM) 1150 have been referenced. Figure 4 It has been described.

[0338] Reference Figure 11 In operation 11000, the second LBA 1180 can request SSP information (SspInfo) from the second SSP 1170.

[0339] When requesting SSP information (SspInfo) from the second SSP 1170, the second LBA 1180 can notify the second SSP 1170 to perform an inter-device bundle transfer. When requesting SSP information (SspInfo) from the second SSP 1170, the second LBA 1180 can further notify the second SSP 1170 to perform an online inter-device bundle transfer. For example, the request message may include an indicator indicating that an inter-device bundle transfer should be performed. As another example, the request message may include an indicator indicating that an online inter-device bundle transfer should be performed. The request message may include an indicator, or the value of the indicator may be set to a specific value, thereby notifying the second SSP 1170 to perform an inter-device bundle transfer or an online inter-device bundle transfer.

[0340] The second LBA 1180 can provide the second SSP 1170 with information about the bundle to be transmitted. This information may include at least one of FID (SPB Family ID) and OID (SPB Family Managed Object ID).

[0341] Reference Figure 11 In operation 11005, the second SSP 1170 can generate its SSP information (ssp2.SspInfo) and transmit the SSP information to the bundle management server 1150 through the second LBA 1180.

[0342] SSP information may include information about the second SSP to be provided for bundle transmission. Here, SSP information may include information (certificate negotiation information) used by the second SSP 1170 to perform a certificate negotiation process to communicate with the bundle management server 1150. The certificate negotiation information may include certificate information that the second SSP 1170 can use to verify the certificate information of the bundle management server 1150 and / or that the bundle management server 1150 can use to verify the certificate information of the second SSP 1170. Furthermore, the certificate negotiation information may also include a list of key negotiation algorithms supported by the second SSP, and a list of encryption algorithms supported by the second SSP.

[0343] SSP information may also include SSP version information, which includes at least one version of the standard supported by the loader included in the second SSP and the main platform.

[0344] According to an embodiment, the second SSP 1170 can transmit SSP information to the bundle management server 1150 via the second LBA 1180.

[0345] According to operations 11000 and 11005, the second LBA 1180 can request SSP information from the second SSP 1170, the second SSP 1170 can generate its own SSP information, and then the second SSP 1170 can transmit the SSP information to the bundle management server 1150 through the second LBA 1180. However, according to an embodiment, the second LBA 1180 can generate its own SSP information and transmit the SSP information to the bundle management server 1150.

[0346] Reference Figure 11 In operation 11010, the bundle management server 1150 can identify the received SSP information, generate server authentication information (SPBM.Auth2) based on the SSP information, and transmit the generated server authentication information to the second LBA 1180.

[0347] Server authentication information may include at least one of the following:

[0348] a) A key protocol certificate (referred to as SPBM.Cert.KA) can be used to verify SPBM itself and the certificate required to verify the key protocol certificate.

[0349] b) Certificate information (referred to as CiPkIdToBeUsed), which can be used by the SPBM to verify the second SSP.

[0350] c) Encryption algorithm information (referred to as CryptoToBeUsed), which is used by the SPBM to perform encrypted communication with the second SSP.

[0351] According to an embodiment, the bundle management server 1150 can transmit server authentication information to the second LBA 1180.

[0352] Reference Figure 11In operation 11015, the second LBA 1180 can transmit server authentication information to the second SSP 1170. The second LBA 1180 can also transmit the bundle separator (spbId) of the bundle to be received to the second SSP 1170. The second LBA 1180 can also transmit SupportedCryptoInfo to the second SSP 1170. (See reference...) Figure 10 Details about SupportedCryptoInfo are described.

[0353] Reference Figure 11 In operation 11020, the second SSP 1170 may perform at least one of the following specified operations.

[0354] a) It can identify the validity of SPBM.Cert.KA.

[0355] (b) You may choose to verify at least one of the signature certificates (ssp2.Cert.DS) of the second SSP based on the received CiPkIdToBeUsed.

[0356] c) It can identify the received CryptoToBeUsed and generate an encryption key pair, namely, a public key ssp2.ePK.KA and a private key ssp2.eSK.KA, which is used to generate an encryption key for encrypted communication with the bundle management server. Furthermore, the second SSP can generate ShKeyM2 using ssp2.eSK.KA and the key protocol public key included in SPBM.Cert.KA. ShKeyM2 is the session key for encrypted communication with the bundle management server.

[0357] According to an embodiment, the second SSP 1170 can generate second terminal authentication information (Device2.Auth). The second terminal authentication information (Device2.Auth) may include at least one of the following information.

[0358] a)ssp2.Cert.DS

[0359] b)ssp2.ePK.KA

[0360] c) Refer to the transaction ID of the current session

[0361] d) SSP ID of the second SSP

[0362] e) Part Number ID of the Second SSP

[0363] f) Bundle separator for the bundle to be received

[0364] According to an embodiment, the second SSP 1170 can identify the received SupportedCryptoInfo and determine whether an encryption algorithm supported by the second terminal 1160 (e.g., the second SSP 1170) exists within it. When an encryption algorithm supported by the second terminal 1160 is present in the received SupportedCryptoInfo, the second SSP 1170 can select one of the encryption algorithms as the selected encryption algorithm. The selected encryption algorithm may optionally include at least one of the following: elliptic curve information, key negotiation algorithm information, and encryption algorithm information.

[0365] The second SSP 1170 can generate a key pair (temporary public key ssp2.ePK.BT and corresponding private key ssp2.eSK.BT) for the second terminal 1160 based on the selected encryption algorithm, for later use in generating encryption keys for encrypted communication with the first terminal. The second SSP 1170 can map the generated key pair to the received bundle ID (SPB ID). The second SSP 1170 can generate selected encryption information (ssp2.SelectedCryptoInfo). The selected encryption information may optionally include at least one of the following: part and / or all of the selected encryption algorithm and ssp2.eEPK.BT.

[0366] To ensure the integrity of the information, part or all of the second terminal authentication information (Device2.Auth) and / or the selected encrypted information (ssp2.SelectedCryptoInfo) can be digitally signed so that it can be verified using ssp2.Cert.DS, and the digital signature data can be added as part of the second terminal authentication information.

[0367] In addition, part or all of the second terminal authentication information (Device2.Auth) and / or the selected encryption information (ssp2.SelectedCryptoInfo) can be encoded using the session key ShKeyM2 generated above.

[0368] In operation 11020, the second SSP 1170 can transmit the second terminal authentication information (Device2.Auth) and / or the selected encryption information (ssp2.SelectedCryptoInfo) to the bundle management server 1150 via the second LBA 1180.

[0369] Reference Figure 11 In operation 11025, the bundle management server 1150 may perform at least one of the following procedures.

[0370] a) The bundle management server can verify the validity of ssp2.Cert.DS included in the second terminal authentication information. Furthermore, when the second terminal authentication information includes a digital signature, the bundle management server can verify the validity of the signature using ssp2.Cert.DS.

[0371] b) When the second terminal authentication information includes encoded data, the bundle management server can generate a session key ShKeyM2 for encrypted communication with the second terminal by using ssp2.ePK.KA and a private key corresponding to the public key of the key protocol included in SPBM.Cert.KA, and decode the encoded data by using the session key.

[0372] c) The bundle management server can identify and / or store the received transaction ID and / or the SSPID of the second SSP.

[0373] d) The bundle management server can identify and / or store the bundle separators of the bundles to be received by the second terminal.

[0374] According to an embodiment, the bundle management server 1150 may also perform at least one of the following processes.

[0375] a) The bundle management server can identify the bundle separator of the bundle to be received by the second terminal and verify whether the bundle is a bundle that can be transmitted online. For example, when the bundle management server 1150 performs verification by using the bundle transmission configuration value of the bundle, it can perform the process of verifying whether the bundle is a bundle that can be transmitted online.

[0376] (b) The bundle management server can identify whether a bundle to be received by the second terminal is properly installed and / or operated in the second terminal (e.g., the second SSP). For example, this identification process can be performed using the part number ID of the second terminal (e.g., the second SSP) and / or the bundle separator of the bundle to be received by the second terminal.

[0377] According to an embodiment, the bundle management server 1150 may map some or all of the following information: the SSP ID of the second SSP, the bundle separator of the bundle to be received, and the selected encryption information (ssp2.SelectedCryptoInfo).

[0378] In operation 11025, the bundle management server 1150 may transmit a response message indicating that all processes are complete to the second LBA 1180. The process of transmitting the response message indicating that all processes are complete may be omitted.

[0379] Figure 12 This illustrates an embodiment according to the present disclosure. Figure 9 The diagram illustrates the process in which the terminal transmitting the bundle uploads the bundle to the server.

[0380] refer to Figure 12 The terminal may include at least one LBA and at least one SSP. For example, the first terminal 1210 may include a first LBA 1230 and a first SSP 1220. Details regarding the bundle management server 1250 have been referenced. Figure 4 It has been described.

[0381] Reference Figure 12 In operation 12000, the first LBA 1230 can request SSP information (SspInfo) from the first SSP 1220.

[0382] When requesting SSP information (SspInfo) from the first SSP, the first LBA can notify the first SSP to perform an inter-device bundle transfer. When requesting SSP information (SspInfo) from the first SSP, the first LBA can further notify the first SSP to perform an online inter-device bundle transfer. For example, the request message may include an indicator indicating that an inter-device bundle transfer should be performed. As another example, the request message may include an indicator indicating that an online inter-device bundle transfer should be performed. The request message may include an indicator, or the value of the indicator may be set to 1, thereby notifying the first SSP to perform an inter-device bundle transfer or an online inter-device bundle transfer.

[0383] The first LBA can provide the first SSP with information about the bundle to be transmitted. This information may include at least one of FID (SPB Family ID) and OID (SPB Family Managed Object ID).

[0384] Reference Figure 12 In operation 12005, the first SSP 1220 can generate its SSP information (ssp1.SspInfo) and transmit the SSP information to the bundle management server 1250 through the first LBA 1230.

[0385] SSP information may include information about the first SSP to be provided for bundle transmission. Here, SSP information may include information used by the first SSP to perform a certificate negotiation process to communicate with the bundle management server (certificate negotiation information). Certificate negotiation information may include certificate information that the first SSP can use to verify the bundle management server and / or certificate information that the bundle management server can use to verify the first SSP. Furthermore, certificate negotiation information may also include a list of key negotiation algorithms supported by the first SSP, and a list of encryption algorithms supported by the first SSP.

[0386] SSP information may also include SSP version information, which includes at least one version of the standard supported by the loader included in the first SSP and the main platform.

[0387] According to an embodiment, the first SSP 1220 can transmit SSP information to the bundle management server 1250 through the first LBA 1230.

[0388] According to operations 12000 and 12005, the first LBA can request SSP information from the first SSP, the first SSP can generate its own SSP information, and then the first SSP can transmit the SSP information to the bundle management server through the first LBA. However, according to an embodiment, the first LBA can generate the SSP information itself and transmit the SSP information to the bundle management server.

[0389] Reference Figure 12 In operation 12010, the bundle management server 1250 can identify the received SSP information, generate server authentication information (SPBM.Auth1) based on the SSP information, and transmit the server authentication information to the first LBA 1230.

[0390] Server authentication information may include at least one of the following:

[0391] a) A key protocol certificate (referred to as SPBM.Cert.KA) can be used to verify SPBM itself and the certificate required to verify the key protocol certificate.

[0392] b) Certificate information (referred to as CiPkIdToBeUsed), which can be used by the SPBM to verify the first SSP.

[0393] c) Encryption algorithm information (referred to as CryptoToBeUsed), which is used by the SPBM to perform encrypted communication with the first SSP.

[0394] According to an embodiment, the bundle management server 1250 can transmit server authentication information to the first LBA 1230.

[0395] Reference Figure 12 In operation 12015, the first LBA 1230 can transmit server authentication information to the first SSP 1220. Additionally, the first LBA 1230 can also transmit the bundle separator (spbId) of the bundle to be transmitted to the first SSP 1220.

[0396] Reference Figure 12 In operation 12020, the first SSP 1220 may perform at least one of the following specified operations.

[0397] a) It can identify the validity of the received SPBM.Cert.KA.

[0398] (b) You may choose to verify at least one of the first SSP's signing certificates (ssp1.Cert.DS) based on the received CiPkIdToBeUsed.

[0399] c) It can identify the received CryptoToBeUsed and generate an encryption key pair, namely, a public key ssp1.ePK.KA and a private key ssp1.eSK.KA, which is used to generate an encryption key for encrypted communication with the bundle management server. Furthermore, the first SSP can generate ShKeyM1 using ssp1.eSK.KA and the key protocol public key included in SPBM.Cert.KA. ShKeyM1 is the session key for encrypted communication with the bundle management server.

[0400] In operation 12020, the first SSP 1220 can generate first terminal authentication information (Device1.Auth) and transmit the first terminal authentication information (Device1.Auth) to the bundle management server 1250. The first terminal authentication information (Device1.Auth) may include at least one of the following information.

[0401] a)ssp1.Cert.DS

[0402] b)ssp1.ePK.KA

[0403] c) Refer to the transaction ID of the current session

[0404] d) SSP ID of the first SSP

[0405] e) Bundle separator for the bundle to be transmitted

[0406] It is possible to digitally sign part or all of the first terminal authentication information (Device1.Auth), so that the integrity of the information can be guaranteed by using ssp1.Cert.DS, and the digitally signed data can be added as part of the first terminal authentication information.

[0407] In addition, part or all of the first terminal authentication information (Device1.Auth) can be encoded using the generated session key ShKeyM1.

[0408] According to an embodiment, the first SSP 1220 can transmit the first terminal authentication information (Device1.Auth) to the bundle management server 1250 through the first LBA 1230.

[0409] Reference Figure 12 In operation 12025, the bundle management server 1250 may execute at least one of the following procedures. (In the following text, a series of such procedures will be referred to as procedure A).

[0410] a) The bundle management server can verify the validity of ssp1.Cert.DS included in the first terminal authentication information. Furthermore, when the first terminal authentication information includes a digital signature, the bundle management server can verify the validity of the signature using ssp1.Cert.DS.

[0411] b) When the first terminal authentication information includes encoded data, the bundle management server can generate a session key ShKeyM1 for encrypted communication with the first terminal by using ssp1.ePK.KA and a private key corresponding to the public key of the key protocol included in SPBM.Cert.KA, and decode the encoded data by using the session key.

[0412] c) The bundle management server can identify and / or store the received transaction ID and / or the SSPID of the first SSP.

[0413] d) The bundle management server can identify and / or store the bundle separators of the bundles to be transmitted by the first terminal.

[0414] According to an embodiment, the bundle management server 1250 may also perform at least one of the following processes. (Hereinafter, such a series of processes will be referred to as process B).

[0415] a) The bundle management server can verify whether the first terminal (e.g., the first SSP) is a legitimate entity using the current bundle by using the SSP ID of the first SSP and the bundle separator of the bundle to be transmitted by the first terminal.

[0416] b) The bundle management server can verify whether the bundle to be transmitted by the first terminal is a bundle that has been requested and authorized for transmission. For example, the bundle management server can identify whether the bundle delimiter of the bundle to be transmitted by the first terminal is... Figure 11 The bundle separator stored in operation 11015.

[0417] Between process A and process B, the bundle management server 1250 can stand by until... Figure 11 The operation proposed in the document has been completed. In other words, regardless of... Figure 11 Whether the operation proposed in the document is completed or not, process A can be executed, but process B is only executed when... Figure 11 The operation proposed in the document is executed only after it is completed, and in this case, the bundle management server can standby before executing process B, until... Figure 11 The operation proposed in the document is complete. This standby process can be executed by any of the various methods described below. However, the standby of the process is not limited to the various methods described below, and is not necessarily one of the methods described below.

[0418] a) The bundle management server can transmit a message to the first LBA indicating that the requested operation has been received, but it needs to wait until a response is received. The first LBA can wait for a period of time, and then transmit the message to the bundle management server to verify whether the requested operation has been executed. When the operation has been completed, process B can be executed. When the operation has not been completed, the bundle management server can transmit a message to the first LBA to wait for a longer period of time. This process can be repeated until... Figure 11 The operation proposed in the document has been completed.

[0419] (b) The bundle management server can standby within a defined time frame between process A and process B. In other words, it will wait until a defined time frame following the execution of process A. Figure 11 When performing the operation proposed in [the document], process B can be executed. If the operation is not completed within a defined timeframe after the execution of process A... Figure 11 When performing the operation described in the document, the transmission of the bundled package can be stopped.

[0420] c) After executing process A, the bundle management server can notify the first LBA that the requested operation has been received. Then, it can complete... Figure 11 The operation proposed in the text is followed by process B.

[0421] In operation 12025, the bundle management server 1250 can generate a message (spbRequest, which may also be referred to as TransferOption) requesting a bundle to the first terminal 1210, and transmit the message (spbRequest) requesting a bundle to the first SSP 1220. The bundle management server 1250 can also transmit ssp2.SelectedCryptoInfo to the first SSP 1220.

[0422] spbRequest may include at least one of the following information.

[0423] a) The SSP ID of the first SSP

[0424] b) The SSP ID of the second SSP

[0425] c) The bundle separator for the bundle to be transmitted by the first terminal

[0426] d) Transaction ID

[0427] Some and / or all of the information included in the spbRequest can be encoded using ShKeyM1, and ShKeyM1 can be included as part of the spbRequest.

[0428] Some and / or all of the information included in the spbRequest can be digitally signed using SPBM.Cert.DS, and the value of the digital signature can be included as part of the spbRequest. In this case, a series of information required to verify the validity of SPBM.Cert.DS can be included as part of the spbRequest.

[0429] According to an embodiment, the bundle management server 1250 can transmit the spbRequest to the first SSP 1220 via the first LBA 1230.

[0430] According to an embodiment, the bundle management server 1250 can also transmit ssp2.SelectedCryptoInfo to the first SSP 1220 via the first LBA 1230. (See also...) Figure 6 The details about ssp2.SelectedCryptoInfo are described.

[0431] Reference Figure 12 In operation 12030, the first SSP 1220 may perform at least one of the following procedures.

[0432] a) When spbRequest includes encoded information, the encoded information is decoded using ShKeyM1.

[0433] b) When spbRequest includes a digital signature value, verify the validity of SPBM.Cert.DS, and then use SPBM.Cert.DS to verify the validity of the digital signature value.

[0434] c) Verify that the SSP ID of the first SSP and / or the SSP ID of the second SSP included in the spbRequest and / or the bundle separator and / or transaction ID of the bundle to be transmitted by the first terminal have the correct values.

[0435] The first SSP 1220 can recognize the information included in ssp2.SelectedCryptoInfo.

[0436] The first SSP 1220 can be configured as a public key ssp1.ePK.BT and a private key ssp1.eSK.BT as an encryption key pair. According to an embodiment, the value of the encryption key can be the same as the values ​​of ssp1.ePK.KA and ssp1.eSK.KA.

[0437] According to an embodiment, the first SSP 1220 can generate a key ShKeyBT for encrypted communication with the bundle management server by using the prepared ssp1.eSK.BT and the public key included in SPBM.Cert.KA.

[0438] According to an embodiment, the first SSP 1220 can generate a key ShKeyBT for encrypted communication with the second terminal by using the prepared ssp1.eSK.BT and ssp2.ePK.BT.

[0439] The first SSP 1220 can prepare and / or generate a bundle to be transmitted to the second terminal. Some and / or all of the information included in the bundle can be encoded using ShKeyBT. The prepared bundle can be referred to as boundSpbImage.

[0440] The first SSP 1220 can extract and / or prepare a portion of the contents of the bundle to be transmitted to the second terminal (e.g., i) personal information included in the bundle; and / or ii) setting values; and / or iii) part and / or all of the updates performed after the bundle is installed). Here, part and / or all of the information can be encoded using ShKeyBT. The prepared data can be referred to as boundSpbImageData, or for ease of description, collectively referred to as boundSpbImage.

[0441] The first SSP 1220 can remove bundles that are to be transferred to the second terminal.

[0442] The first SSP 1220 can delete the bundle and generate a token (called ssp1.Notification) to notify the bundle management server 1250 of the deletion.

[0443] In operation 12030, the first SSP 1220 can transfer boundSpbImage or boundSpbImageData to the bundle management server 1250. The first SSP 1220 can also transfer ssp1.ePK.BT to the bundle management server 1250. The first SSP 1220 can also transfer ssp1.Notification to the bundle management server 1250.

[0444] Reference Figure 12 In operation 12035, the bundle management server 1250 can verify ssp1.Notification and transmit a response message to the first LBA 1230 indicating that all processes have been executed.

[0445] When boundSpbImage or boundSpbImageData is encoded using an encryption key prepared using ssp1.eSK.BT and a public key included in SPBM.Cert.KA, the bundle management server 1250 can generate an encryption key ShKeyBT using ssp1.ePK.BT and a private key corresponding to the public key included in SPBM.Cert.KA. The encoded data included in boundSpbImage or boundSpbImageData is then decoded using the encryption key.

[0446] In other words, one of the following scenarios can be performed by the bundle management server 1250.

[0447] [Scenario A]

[0448] When the bundle management server receives a SpbImage encoded using ShKeyBT generated by utilizing the public keys included in ssp1.eSK.BT and SPBM.Cert.KA, the result generated when the bundle management server performs decoding using ShKeyBT can be referred to as the decoded bundle.

[0449] [Scenario B]

[0450] When the bundle management server receives SpbImageData encoded using ShKeyBT generated by utilizing the public keys included in ssp1.eSK.BT and SPBM.Cert.KA, the result generated when the bundle management server performs decoding using ShKeyBT can be referred to as the decoded bundle data.

[0451] [Scenario C]

[0452] When the bundle management server receives a SpbImage encoded using ShKeyBT generated by ssp1.eSK.BT and ssp2.ePK.BT, the bundle management server can store the received result, and the stored result can be referred to as the received bundle.

[0453] [Scenario D]

[0454] When the bundle management server receives SpbImageData encoded using ShKeyBT generated by ssp1.eSK.BT and ssp2.ePK.BT, the bundle management server can store the received result, and the stored result can be referred to as the received bundle data.

[0455] Bundle management server 1250 can map some or all of the following information to each other: the SSP ID of the second SSP as described above, the bundle separator of the bundle to be received by the second SSP, the decoded bundle, the decoded bundle data, the received bundle and the received bundle data.

[0456] According to an embodiment, the bundle management server 1250 can transmit a response message to the first LBA 1230 indicating that all processes have been executed.

[0457] Figure 13 This illustrates an embodiment according to the present disclosure. Figure 9 The diagram illustrates the process of downloading a bundle that is uploaded to the server to the terminal that will receive the bundle.

[0458] refer to Figure 13 The terminal may include at least one LBA and at least one SSP. For example, the second terminal 1360 may include a second LBA 1380 and a second SSP 1370. Details regarding the bundle management server 1350 have been referenced. Figure 4 It has been described.

[0459] Reference Figure 13In operation 13000, the second LBA 1380 can request a bundle to be received from the bundle management server 1350. This request can be performed using any of a variety of methods. For example, the second LBA 1380 can transmit second terminal authentication information (Device2.Auth) to the bundle management server 1350. (See reference...) Figure 11 Details regarding the second terminal authentication information (Device2.Auth) are described.

[0460] Operation 13000 can be replaced by the following procedure. In other words, after executing... Figure 11 Following operation 11020, the second terminal 1360 can remain in standby mode until operation 13005, as described below, is executed. This standby process can be performed by any of the various methods described below. However, the standby process is not limited to these methods and is not necessarily one of those methods.

[0461] a) Bundle management server 1350 can transmit a message to second LBA 1380 indicating that the requested operation has been received, but needs to wait until a response is received. Second LBA 1380 can wait for a period of time, then transmit the message to bundle management server 1350 to verify whether the requested operation has been executed. When the operation is completed, operation 13005 can be executed. If the operation is not completed, bundle management server 1350 can transmit the message to second LBA 1380 to wait for a longer period. In this case, second LBA 1380 can wait for a period of time again, then transmit the message to bundle management server 1350 again to verify whether the requested operation has been executed. This process can be repeated until operation 13005 is executed.

[0462] (b) The second LBA 1380 can standby until operation 13005 is performed within a defined time frame. If operation 13005 is not performed within the defined time frame, the bundle transmission can be stopped.

[0463] c) The bundle management server 1350 can notify the second LBA 1380 that the requested operation has been received. Then, when preparation is complete, operation 13005 can be executed.

[0464] Reference Figure 13 In operation 13005, the bundle management server 1350 may perform at least one of the following procedures.

[0465] When the bundle management server 1350 has received the bundle request message from the second LBA 1380 during operation 13000, the following procedure can be performed.

[0466] a) The bundle management server can identify whether the received second terminal authentication information matches the information in the bundle. Figure 11 The second terminal authentication information received in operation 11020 is the same. Alternatively, the bundle management server can identify which terminal requested the current bundle by using the received second terminal authentication information.

[0467] b) The bundle management server can identify whether a bundle to be transmitted to the second terminal exists by using the SSP ID of the second SSP.

[0468] c) The bundle management server can identify whether a bundle to be transmitted to the second terminal exists by using the bundle separator of the bundle to be received by the second terminal.

[0469] In operation 13005, the bundle management server 1350 can prepare the bundle to be transmitted to the second terminal 1360. In other words, in the following:

[0470] -Decoded bundle,

[0471] -Decoded bundle data,

[0472] - The received bundle, and

[0473] - Received bundle data

[0474] They are Figure 12 The bundle to be transmitted to the second terminal is ready when one of them is mapped to the SSP ID of the second SSP and / or the bundle separator of the bundle to be received by the second terminal. The bundle can be prepared by one of the following methods.

[0475] [Scenario A]

[0476] When as Figure 12 When the process described above results in a decoded bundle, the bundle management server can use the decoded bundle to prepare a bundle to be transmitted to the second terminal. According to one embodiment, the bundle management server can encode a portion and / or all of the bundle using ShKeyM2 and prepare the bundle for transmission. According to another embodiment, the bundle management server can generate a public key SPBM.ePK.BT and a private key SPBM.eSK.BT as a key pair, generate an encryption key ShKeyBT using SPBM.ePK.BT and ssp2.ePK.KA, encode a portion and / or all of the bundle using the encryption key, and then prepare the bundle.

[0477] [Scenario B]

[0478] When as Figure 12 When the result of the proposed process contains decoded bundled data, the bundled management server can prepare a bundle to be transmitted to the second terminal using the decoded bundled data. According to one embodiment, the bundled management server can prepare a bundle including a portion of the decoded bundled data. According to another embodiment, the bundled management server can prepare a bundle to be transmitted to the second terminal and then add the decoded bundled data as additional data. According to one embodiment, the bundled management server can encode a portion and / or all of the bundle prepared using ShKeyM2 and / or additional data. According to another embodiment, the bundled management server can generate a public key SPBM.ePK.BT and a private key SPBM.eSK.BT as a key pair, generate an encryption key ShKeyBT using SPBM.ePK.BT and ssp2.ePK.KA, and then encode a portion and / or all of the bundle prepared using the encryption key ShKeyBT and / or additional data.

[0479] [Scenario C]

[0480] When as Figure 12 When the result of the process proposed in the paper is a received bundle, the bundle management server can prepare the received bundle as a bundle to be transmitted to the second terminal.

[0481] [Scenario D]

[0482] When as Figure 12 When the process described above results in received bundled data, the bundled management server can use the received bundled data to prepare a bundle to be transmitted to the second terminal. According to an embodiment, the bundled management server can generate a bundle to be transmitted to the second terminal and add the received bundled data as additional data. According to an embodiment, part and / or all of the bundle generated by the bundled management server can be encoded using ShKeyM2. According to another embodiment, part and / or all of the bundle generated by the bundled management server can be encoded using the encryption key ShKeyBT (which is generated using the key pair SPBM.ePK.BT and SPBM.eSK.BT generated by the bundled management server).

[0483] The bundle and additional data prepared in [Scenario A] through [Scenario D] can be referred to as boundSpbImage.

[0484] In operation 13005, the bundle management server 1350 can transfer boundSpbImage to the second LBA 1380. The bundle management server 1350 can also transfer SPBM.ePK.BT to the second LBA 1380. The bundle management server 1350 can also transfer ssp1.ePK.BT to the second LBA 1380.

[0485] Reference Figure 13 In operation 13010, the bundle can be installed in the second SSP 1370. The second SSP 1370 and / or the second LBA 1380 can install the bundle in the second SSP 1370 using the boundSpbImage received in operation 13005.

[0486] According to one embodiment, when bundled packages and / or additional data received from bundled package management server 1350 are encoded using a key for encryption between the bundled package management server and the second terminal, the second SSP 1370 can decode the encoded information using ShKeyM2. According to another embodiment, when bundled packages and / or additional data received from bundled package management server 1350 are encoded using a key for encryption between the bundled package management server and the second terminal, the second SSP 1370 can generate an encryption key ShKeyBT using SPBM.ePK.BT, and then decode the encoded information using the encryption key.

[0487] According to another embodiment, when bundled packages and / or additional data received from the bundle management server 1350 are encoded using a key for encryption between the first and second terminals, the second SSP 1370 can generate an encryption key ShKeyBT using ssp1.ePK.BT, and then decode the encoded information using the encryption key. (See also...) Figure 13 In operation 13015, the second SSP 1370 can notify the bundle management server 1350 of the result of the bundle installation. For example, the second SSP 1370 can transmit a message containing the result of the bundle installation (referred to as ssp2.Notification) to the bundle management server 1350.

[0488] Figure 14 This is a diagram illustrating the configuration of a terminal on which an SSP is installed, according to some embodiments of the present disclosure.

[0489] like Figure 14As shown, the terminal may include a transceiver 1410 and at least one processor 1420. Furthermore, the terminal may also include an SSP 1430. For example, the SSP 1430 may be inserted into or embedded in the terminal. The at least one processor 1420 may also be referred to as a controller. However, the configuration of the terminal is not limited to... Figure 14 And the terminal may include more Figure 14 The number of components shown may be more or less. According to some embodiments, the transceiver 1410, at least one processor 1420, and memory (not shown) can be implemented as a single chip. Furthermore, when the SSP 1430 is embedded, a single chip can be implemented by further including the SSP 1430.

[0490] According to various embodiments, transceiver 1410 can transmit signals, information, and data according to various embodiments of the present disclosure to a transceiver of another terminal or external server, and receive signals, information, and data according to various embodiments of the present disclosure from a transceiver of another terminal or external server. Transceiver 1410 may include an RF transmitter for up-converting and amplifying the frequency band of the transmitted signal, and an RF receiver for low-noise amplification and down-converting the frequency band of the received signal. However, this is only one embodiment of transceiver 1410, and the components of transceiver 1410 are not limited to RF transmitters and RF receivers. Furthermore, transceiver 1410 can receive signals via a wireless channel and output the signals to at least one processor 1420, and can transmit signals output from at least one processor 1420 via a wireless channel.

[0491] Meanwhile, at least one processor 1420 is typically a component used to control the terminal. At least one processor 1420 can control the overall operation of the terminal according to the various embodiments disclosed above.

[0492] Additionally, SSP 1430 may include a processor or controller for installing and controlling the bundle, or it may be installed with the application. Furthermore, according to various embodiments, SSP 1430 may operate under the control of processor 1420. Alternatively, SSP 1430 may include a processor or controller for installing and controlling the bundle, or it may be installed with the application. Part or all of the application may be installed in SSP 1430 or in memory (not shown).

[0493] The terminal may also include a memory (not shown) that can store data for the operation of the terminal, such as basic programs, applications, configuration information, etc. The memory may include at least one storage medium selected from flash memory, hard disk memory, multimedia card micro-type memory, card-type memory (e.g., Secure Digital (SD) or Extreme Digital (XD) memory), magnetic storage, magnetic disk, optical disk, random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), programmable read-only memory (PROM), and electrically erasable programmable read-only memory (EEPROM). Furthermore, the processor can perform various operations using various programs, contents, and data stored in the memory.

[0494] Figure 15 This is a diagram illustrating the configuration of a bundle management server according to some embodiments of the present disclosure.

[0495] According to some embodiments, the bundle management server may include a transceiver 1510 and at least one processor 1520. However, the configuration of the bundle management server is not limited to... Figure 15 Furthermore, the bundle management server can include more than Figure 15 The components shown may have more or fewer components.

[0496] According to some embodiments, transceiver 1510 can transmit signals, information, and data according to various embodiments of the present disclosure to a terminal and receive signals, information, and data according to various embodiments of the present disclosure from a terminal. Transceiver 1510 may include an RF transmitter for up-converting and amplifying the frequency band of a transmitted signal and an RF receiver for low-noise amplification and down-converting the frequency band of a received signal. However, this is only one embodiment of transceiver 1510, and the components of transceiver 1510 are not limited to RF transmitters and RF receivers. Furthermore, transceiver 1510 can receive signals via a wireless channel and output such signals to at least one processor 1520, and can transmit signals output from at least one processor 1520 via a wireless channel.

[0497] Meanwhile, at least one processor 1520 is typically a component used to control the bundle management server. The processor 1520 can control the overall operation of the bundle management server according to the various embodiments disclosed above. The at least one processor 1520 may also be referred to as a controller.

[0498] Additionally, the bundle management server may include a memory (not shown), which can store data used for the operation of the bundle management server, such as basic programs, applications, configuration information, etc. The memory may include at least one storage medium selected from flash memory, hard disk, multimedia card micro-type, card-type memory (e.g., Secure Digital (SD) or Extreme Digital (XD) memory), magnetic storage, magnetic disk, optical disk, random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), programmable read-only memory (PROM), and electrically erasable programmable read-only memory (EEPROM).

[0499] Figure 16 This is a diagram illustrating an example of a method for two terminals and a server to interact according to an embodiment of the present disclosure to transmit a configuration file online from one terminal to another.

[0500] like Figure 16 As shown, the first terminal 1600 and the second terminal 1620 may each include a first eSIM 1603 and a second eSIM 1623, and a configuration file (not shown) may be installed in each of the first eSIM 1603 and the second eSIM 1623. Furthermore, a first LPA 1601 and a second LPA 1621 may be installed in the first terminal 1600 and the second terminal 1620, respectively. The first eSIM 1603 and the second eSIM 1623 may be controlled by the first LPA 1601 and the second LPA 1621, respectively. A first user (i.e., the first terminal user) 1605 and a second user (i.e., the second terminal user) 1625 may control the configuration file installed in the eSIM (first eSIM 1603 and second eSIM 1623) of each terminal via the first LPA 1601 and the second LPA 1621, respectively. Here, the first user 1605 and the second user 1625 may be the same user. Furthermore, the first LPA 1601 and the second LPA 1621 can be connected and communicate with each other. Here, possible methods for connecting the LPAs will be described below with reference to the accompanying drawings.

[0501] The first LPA 1601 of the first terminal 1600 can be connected to the first RSP server 1640, and the second LPA 1621 of the second terminal 1620 can be connected to the second RSP server 1680. Here, the first RSP server 1640 and the second RSP server 1680 can be the same RSP server. Furthermore, in Figure 16For convenience, the first RSP server 1640 and the second RSP server 1680 are each shown as a single server. However, according to embodiments, the server configuration may include one or more profile provider servers (SM-DP+), or one or more subscription intermediary servers (SM-DS) that help establish connections between specific profile provider servers and terminals. Furthermore, although not shown, one or more RSP servers and / or relay servers may be connected between the first RSP server 1640 and the second RSP server 1680.

[0502] Furthermore, although not shown, each RSP server and / or relay server can connect to a carrier server. Additionally, when the configuration includes one or more carrier servers, each carrier server can connect to a separate RSP server and / or relay server, or at least one carrier server can connect to the same RSP server and / or relay server.

[0503] It should be noted that in the following figures, these various server configurations can be simplified and shown as a single RSP server. For example, when one or more RSP servers and / or relay servers are connected between the first terminal 1600 and the second terminal 1620, and some or all of the RSP servers and / or relay servers are connected to the operator's server, the various server configurations existing between the first terminal and the second terminal can be represented as a single RSP server, and such a single RSP server may be referred to as SM-XX in the figures and embodiments.

[0504] Figure 17 This is a diagram illustrating the first half of the process of transferring a configuration file online from one terminal to another according to an embodiment of the present disclosure.

[0505] Despite Figure 17 Not shown in the image, but as... Figure 16 As shown, each of the first terminal 1710 and the second terminal 1750 can include eUICC and LPA. Furthermore, as... Figure 16 As shown, the RSP server 1730 may include at least one RSP server and / or relay server and / or carrier server.

[0506] Despite Figure 17Although not shown, the first terminal 1710 may include a configuration file transfer configuration. According to various embodiments, the configuration file transfer configuration is a strategy regarding the possibility of transferring configuration files between devices and may have been generated by the mobile operator, RSP server, or a collaboration between the mobile operator and the RSP server as described above. According to various embodiments, the configuration file transfer configuration in the terminal may be updated by the mobile operator, the RSP server, or a collaboration between the mobile operator and the RSP server. Alternatively, the configuration file transfer configuration may be updated by collaboration between the terminal and at least one of the entities of the mobile operator and the RSP server. The timing and / or method for updating the configuration file transfer configuration may be determined by the strategy of the mobile operator, the RSP server, or the terminal manufacturer.

[0507] The configuration file transfer configuration may include factors (or indicators) indicating whether the transfer of configuration files between devices is permitted. Furthermore, the configuration file transfer configuration may optionally include factors specifying conditions under which the transfer of configuration files between devices is permitted. For example, it may be configured whether a configuration file can be transferred (or transmitted) online from one terminal to another. This factor may be electronically signed by at least one of the following entities: the RSP server, the mobile operator, the terminal manufacturer, the eUICC, or the eUICC manufacturer. The value of the electronic signature may be stored in the first terminal 1710 as part of or together with the configuration file transfer configuration.

[0508] Reference Figure 17 In operation 17000, configuration file transfer preparation information (PreparationInfo) can be transferred from the second terminal 1750 to the first terminal 1710. The configuration file transfer preparation information may include the eUICC ID (referred to as EID) of the eUICC installed in the second terminal 1750.

[0509] The configuration file transmission preparation information may include certificate negotiation information used when the second terminal 1750 negotiates a certificate with the RSP server. The certificate negotiation information may be part of the eUICC2.Info1 file of the second terminal, as described below. The certificate negotiation information may include information about the supported versions of the second terminal's eUICC. The certificate negotiation information may include certificate information that can be used to verify the second terminal's eUICC. The certificate negotiation information may include certificate information that can be used to verify the RSP server.

[0510] The configuration file transmission preparation information may include information used to determine whether the configuration file to be received later from the first terminal 1710 can be installed correctly and operated in the eUICC of the second terminal 1750. This information may be part and / or all of the eUICC2.Info2 of the second terminal as described below. For example, this information may include hardware and / or software information of the eUICC installed in the second terminal 1750.

[0511] The configuration file transmission preparation information may include factors indicating the encryption methods supported by the second terminal 1750. These factors may include a list of key negotiation algorithms supported by the second terminal 1750 and / or a list of encryption algorithms and / or public keys of the second terminal to be used for the key protocol.

[0512] Information transmitted from the second terminal 1750 to the first terminal 1710 can be transmitted via any of various methods. For example, the second terminal can provide information to be transmitted to the first terminal to a second user of the second terminal through the second terminal's UI. The second user can provide the provided information to a first user of the first terminal. The first user can input the provided information into the first terminal using the first terminal's UI. Alternatively, the second terminal can generate an image (e.g., a QR code) of the information to be transmitted to the first terminal and display the image on the screen of the second terminal, and the first user can scan the image displayed on the screen of the second terminal and transmit the information to the first terminal. However, the method of transmitting information from the second terminal to the first terminal is not limited to the methods described above and can be determined differently. The first user and the second user can represent different users or the same user.

[0513] According to an embodiment, the first terminal 1710 can determine whether a configuration file can be transmitted by recognizing the configuration file transmission configuration. Furthermore, the first terminal can determine whether a configuration file can be transmitted online by recognizing the configuration file transmission configuration. The first terminal can select to transmit the configuration file online by recognizing the configuration file transmission configuration.

[0514] According to an embodiment, the first terminal 1710 can identify the received configuration file transmission configuration. For example, the first terminal 1710 can verify whether its own supported encryption method exists among the encryption methods supported by the second terminal 1750 included in the configuration file transmission configuration. Specifically, the first terminal can identify whether its own supported algorithm exists among the key negotiation algorithm and / or encryption algorithm supported by the second terminal. When a supported algorithm exists, the first terminal can select the key negotiation algorithm and / or encryption algorithm. Furthermore, the first terminal can select the second terminal's public key for later use in generating an encryption key.

[0515] In operation 17005, the first terminal 1710 may transmit its eUICC information (eUICC1.Info1) to the RSP server 1730. eUICC1.Info1 may include a random string (eUICC1.Challenge) generated by the first terminal's eUICC. eUICC1.Info1 may include information about the versions supported by the first terminal's eUICC. eUICC1.Info1 may include certificate information that can be used to verify the first terminal's eUICC. eUICC1.Info1 may include certificate information that can be used to verify the RSP server. eUICC1.Info1 may include a list of encryption algorithms supported by the first terminal.

[0516] Reference Figure 17 In operation 17010, RSP server 1730 can examine the received eUICC1.Info1 and generate RSP server authentication information (Server.Auth1). The RSP server can use the received eUICC1.Info1 to identify whether its supported version exists among the eUICC versions supported by the first terminal. The RSP server can use the received eUICC1.Info1 to select a certificate, Server.Cert, that can verify itself. The RSP server can use the received eUICC1.Info1 to select certificate information to be used by the first terminal 1710. The RSP server can use the received eUICC1.Info1 to select the encryption algorithm to be used during subsequent encrypted communication with the first terminal.

[0517] According to an embodiment, RSP server 1730 can generate RSP server authentication information (Server.Auth1). The RSP server authentication information (Server.Auth1) may include a portion or all of eUICC1.Info1. For example, the RSP server authentication information (Server.Auth1) may include eUICC1.Challenge, which has already been received by the first terminal 1710. The RSP server authentication information (Server.Auth1) may also include a random string (Server.Challenge1) generated by the RSP server.

[0518] The RSP server authentication information (Server.Auth1) may include certificate information to be used by the first terminal. The RSP server authentication information (Server.Auth1) may include certificate chain information related to the certificate Server.Cert, which enables the first terminal to verify itself. The RSP server authentication information (Server.Auth1) may include the encryption algorithm to be used later during encrypted communication with the first terminal.

[0519] Part or all of the aforementioned RSP server authentication information (Server.Auth1) can be electronically signed using the RSP server's certificate Server.Cert, and such electronically signed data can be included as part of the RSP server authentication information (Server.Auth1).

[0520] Reference Figure 17 In operation 17015, RSP server 1730 can transmit RSP server authentication information (Server.Auth1) to first terminal 1710.

[0521] Reference Figure 17 In operation 17020, the first terminal 1710 can verify the received RSP server authentication information (Server.Auth1) and generate first terminal authentication information (Device1.Auth) based on the verification result (e.g., when verification is successful). The first terminal can verify the validity of Server.Cert included in the RSP server authentication information (Server.Auth1), and can also verify the validity of the signature included in the RSP server authentication information (Server.Auth1) by using Server.Cert. The first terminal can verify whether the value of eUICC1.Challenge included in the RSP server authentication information (Server.Auth1) is the same as the value of eUICC1.Challenge transmitted by itself in operation 17005. For example, verification may succeed when Server.Cert is valid, the signature contained in the RSP server authentication information (Server.Auth1) is valid, and the value of eUICC1.Challenge is the same.

[0522] The first terminal can generate first terminal authentication information (Device1.Auth) based on the verification result (e.g., when verification is successful). The first terminal authentication information (Device1.Auth) may include part or all of Server.Auth1. For example, the first terminal authentication information (Device1.Auth) may include Server.Challenge1 that has already been received by the first terminal.

[0523] The first terminal authentication information (Device1.Auth) may include the eUICCID of the eUICC installed on the first terminal. Additionally, the first terminal authentication information (Device1.Auth) may include the configuration file separator for the configuration file to be transmitted.

[0524] The first terminal authentication information (Device1.Auth) may include certificate chain information related to the certificate eUICC1.Cert that can verify itself.

[0525] Furthermore, the first terminal may select a portion and / or all of the configuration file transmission preparation information received from the second terminal 1750 during operation 17000. (Hereinafter, for convenience, the selected information will be referred to as transmission preparation selection information.) For example, the transmission preparation selection information may include certificate negotiation information already received from the second terminal and used when the second terminal negotiates a certificate with the RSP server, as well as information used to determine whether the configuration file to be transmitted by the first terminal is properly installed and operable in the second terminal's eUICC. Additionally, the transmission preparation selection information may include the second terminal's eUICC ID.

[0526] The first terminal authentication information (Device1.Auth) and part and / or all of the transmission preparation selection information can be electronically signed using the first terminal's certificate eUICC1.Cert.

[0527] Reference Figure 17 In operation 17025, the first terminal 1710 may transmit the first terminal authentication information (Device1.Auth) generated in operation 17020 and / or transmit preparation selection information (PreparationInfo) and / or electronic signature information to the RSP server 1730.

[0528] Reference Figure 17In operation 17030, RSP server 1730 can verify the received first terminal authentication information (Device1.Auth). RSP server 1730 can verify the validity of eUICC1.Cert included in the first terminal authentication information (Device1.Auth), and verify the validity of the received electronic signature by using eUICC1.Cert. RSP server can verify whether the value of Server.Challenge1 included in the first terminal authentication information (Device1.Auth) is the same as the value of Server.Challenge1 transmitted by itself in operation 17015. For example, verification can succeed when eUICC1.Cert is valid, the signature included in the first terminal authentication information (Device1.Auth) is valid, and the value of Server.Challenge1 is the same.

[0529] According to an embodiment, the RSP server can verify that the first terminal is a terminal using a configuration file by using the received eUICC ID of the first terminal and the configuration file separator.

[0530] According to an embodiment, the RSP server can identify the certificate negotiation information used when the second terminal negotiates a certificate with the RSP server, as well as the information used to determine whether the configuration file to be transmitted by the first terminal can be installed normally and operated in the eUICC of the second terminal (these are included in the transmission preparation selection information), and when the second terminal later requests the configuration file to be uploaded by the first terminal, verify whether the certificate negotiation between the RSP server and the second terminal will be successful and whether the configuration file will run normally in the second terminal.

[0531] Furthermore, the RSP server can store the received configuration file separator and the eUICC ID of the second terminal.

[0532] Reference Figure 17 In operation 17035, based on the determined result, RSP server 1730 may transmit a message requesting a configuration file (or configuration file package) to first terminal 1710. This request message may include a series of data fragments required to request the configuration file. For example, the request message may include configuration file delimiters for the requested configuration file. Furthermore, the request message may also include the RSP server's key protocol public key. The RSP server's key protocol public key may be a temporary key.

[0533] Part or all of the data included in the request message may be electronically signed by a certificate server using an RSP server, and such electronically signed data may be included as part of the request message.

[0534] Reference Figure 17 In operation 17040, the first terminal 1710 can identify the request message transmitted by the RSP server, and when the verification of the RSP server is successful, prepare a configuration file package related to the configuration file requested by the RSP server. For example, the first terminal 1710 can verify the validity of the electronic signature included in the request message of the RSP server. Furthermore, the first terminal 1710 can verify whether the configuration file delimiter included in the request message of the RSP server matches the delimiter of the configuration file to be transmitted.

[0535] Upon successful verification, the first terminal 1710 can prepare a configuration file package related to the configuration file requested by the RSP server. The configuration file package may include configuration file information to be transferred from the first terminal to the second terminal.

[0536] Part and / or all of the configuration file information to be transmitted from the first terminal to the second terminal can be encoded. Some examples of methods for generating the encryption key used in this case are as follows.

[0537] A) An encryption key is generated by using the public key of the key protocol of the RSP server provided in Operation 17035 and the private key of the key protocol generated by the first terminal.

[0538] B) An encryption key is generated by using the public key of the second terminal selected in operation 17005 for generating the encryption key and the private key generated by the first terminal.

[0539] The configuration file package may include a public key corresponding to the private key generated by the first terminal. The configuration file package may include information related to the encryption key, such as the key negotiation algorithm used to generate the encryption key and / or encryption algorithm information used to employ the encryption key.

[0540] The contents of the configuration file package can be digitally signed by the first terminal's certificate eUICC1.Cert, and the value of the digital signature can be included as part of the configuration file package.

[0541] The first terminal 1710 can disable the status of the configuration file to be transferred before generating the configuration file package.

[0542] Reference Figure 17 In operation 17045, the first terminal 1710 can transmit the configuration file package to the RSP server 1730.

[0543] Reference Figure 17In operation 17050, RSP server 1730 can process the received configuration file packet. For example, the RSP server can store the received configuration file packet and link it to the eUICC ID of the second terminal 1750. Furthermore, when encoding in operation 17040 using an encryption key generated by utilizing the server's key protocol public key and the key protocol key generated by the first terminal, the RSP server can generate an encryption key using the server's key protocol public key and the public key corresponding to the private key generated by the first terminal, and then decode the received configuration file packet using the encryption key.

[0544] Figure 18 This is a diagram illustrating the latter part of the process of transferring a configuration file online from one terminal to another according to an embodiment of the present disclosure.

[0545] Despite Figure 18 Not shown, but each of the first terminal 1810 and the second terminal 1850 may include eUICC and LPA, such as Figure 16 As shown. Furthermore, the RSP server 1830 may include at least one RSP server and / or relay server and / or carrier server, such as... Figure 16 As shown.

[0546] Reference Figure 18 This can initialize the process of the second terminal 1850 requesting and receiving a configuration file from the RSP server 1830. This initialization process can be started using any of a variety of methods.

[0547] For example, the initialization process for requesting and receiving configuration files can begin with the input of the code (hereinafter referred to as the activation code) required for requesting the configuration file in the second terminal 1850 of operation 18000.

[0548] Here, the activation code input to the second terminal can be entered using any of a variety of methods. For example, the first terminal can generate an image including activation code information, such as a QR code, and display the image on its screen. The second user can then scan the QR code displayed on the first terminal's screen using the second terminal, thus inputting the activation code into the second terminal. Alternatively, a connection can be established between the first and second terminals (possible connection methods include direct device-to-device connections (e.g., NFC, Bluetooth, UWB, Wi-Fi Direct, LTE D2D, or 5G D2D) or a remote connection with a remote server (e.g., a relay server) located between the first and second terminals), and the activation code can be transmitted to the second terminal through this connection. Alternatively, the activation code can be input to the second terminal when the second user inputs the activation code through the UI provided by the second terminal. Alternatively, the activation code can be input to the second terminal as the RSP server and / or a random server associated with the RSP server transmit the activation code to the second terminal. Alternatively, the activation code can be input to the second terminal as the second terminal obtains the activation code by accessing the RSP server and / or a random server associated with the RSP server.

[0549] The activation code may include the eUICC ID of the second terminal. The activation code may include a configuration file separator for the configuration file to be transmitted by the first terminal. The activation code may include the address of the RSP server to be accessed by the second terminal to request the configuration file. The activation code may include the encryption key used by the first terminal to generate the encryption key for... Figure 17 Information encoded in the configuration file, such as the key negotiation algorithm used to generate the encryption key, and / or encryption algorithm information used to use the encryption key, and / or the key protocol public key used by the first terminal to generate the encryption key.

[0550] Alternatively, the initialization process can be initiated when the second terminal uses the discovery service. For example, the initialization process can be initiated after the second terminal identifies the event by accessing the discovery server, and then identifies that a configuration file download event has occurred.

[0551] Alternatively, the initialization process can be initiated when the RSP server notifies the second terminal that an event has occurred. For example, the initialization process can be initiated when the RSP server or a random server associated with the RSP server notifies the second terminal that a configuration file download event has occurred (e.g., using the server's push service).

[0552] Alternatively, the initialization process can be initiated when a second user requests the second terminal to download a configuration file. For example, the initialization process can begin when the second user displays their intention to download the configuration file through the UI provided by the second terminal, and provides the information required to download the configuration file.

[0553] Reference Figure 18 In operation 18005, the second terminal 1850 may transmit its eUICC information (eUICC2.Info1) to the RSP server 1830. The eUICC2.Info1 may include a random string (eUICC2.Challenge) generated by the second terminal's eUICC. The eUICC2.Info1 may include information about the versions supported by the second terminal's eUICC. The eUICC2.Info1 may include certificate information that can be used to verify the second terminal's eUICC. The eUICC2.Info1 may include certificate information that can be used to verify the RSP server's eUICC. The eUICC2.Info1 may include a list of encryption algorithms supported by the second terminal.

[0554] Reference Figure 18 In operation 18010, RSP server 1830 can examine (e.g., identify) the received eUICC2.Info1 and generate RSP server authentication information (Server.Auth2). RSP server 1830 can identify, using the received eUICC2.Info1, whether a version it supports exists among the eUICC versions supported by the second terminal. RSP server 1830 can use the received eUICC2.Info1 to select a certificate, Server.Cert, capable of verifying itself. RSP server 1830 can use the received eUICC2.Info1 to select certificate information to be used by the second terminal 1850. RSP server 1830 can use the received eUICC2.Info1 to select an encryption algorithm to be used during subsequent encrypted communication with the second terminal.

[0555] According to an embodiment, RSP server 1830 can generate RSP server authentication information (Server.Auth2). The RSP server authentication information (Server.Auth2) may include a portion or all of eUICC2.Info1. For example, the RSP server authentication information (Server.Auth2) may include the already received eUICC2.Challenge. The RSP server authentication information (Server.Auth2) may also include a random string (Server.Challenge2) generated by the RSP server.

[0556] The RSP server authentication information (Server.Auth2) may include certificate information used to verify the second terminal. The RSP server authentication information (Server.Auth2) may include certificate chain information associated with the certificate Server.Cert, which is capable of verifying itself. The RSP server authentication information (Server.Auth2) may include the encryption algorithm used later during encrypted communication with the second terminal.

[0557] Part or all of the aforementioned RSP server authentication information (Server.Auth2) can be electronically signed using the RSP server's certificate Server.Cert, and such electronically signed data can be included as part of the RSP server authentication information (Server.Auth2).

[0558] Reference Figure 18 In operation 18015, RSP server 1830 can transmit RSP server authentication information (Server.Auth2) to the second terminal 1850.

[0559] Reference Figure 18 In operation 18020, the second terminal 1850 can verify the received RSP server authentication information (Server.Auth2) and generate second terminal authentication information (Device2.Auth). The second terminal 1850 can verify the validity of Server.Cert included in the RSP server authentication information (Server.Auth2), and can also verify the validity of the signature included in the RSP server authentication information (Server.Auth2) using Server.Cert. The second terminal 1850 can verify whether the value of eUICC2.Challenge included in the RSP server authentication information (Server.Auth2) is the same as the value of eUICC2.Challenge transmitted by itself in operation 18005.

[0560] The second terminal 1850 can generate second terminal authentication information (Device2.Auth). The second terminal authentication information (Device2.Auth) may include part or all of Server.Auth2. For example, the second terminal authentication information may include the received Server.Challenge2.

[0561] The second terminal authentication information (Device2.Auth) may include eUICC2.Info2, used to perform eUICC eligibility checks on the eUICC installed on the second terminal. eUICC2.Info2 may be information used to determine whether a configuration file to be received later from the first terminal can be installed correctly and operated within the eUICC on the second terminal. For example, eUICC2.Info2 may include hardware and / or software information of the eUICC installed on the second terminal. Alternatively, eUICC2.Info2 may include hardware and / or software information of the second terminal.

[0562] The second terminal authentication information (Device2.Auth) may include the eUICCID of the eUICC installed on the second terminal. Additionally, the second terminal authentication information (Device2.Auth) may include a configuration file separator for the configuration file requested by the second terminal. The second terminal authentication information (Device2.Auth) may include the activation code received in Operation 18000.

[0563] The second terminal authentication information (Device2.Auth) may include the public key of the key protocol generated by the eUICC of the second terminal.

[0564] The second terminal authentication information (Device2.Auth) may include certificate chain information related to the certificate eUICC2.Cert that can verify itself.

[0565] Part or all of the aforementioned second terminal authentication information (Device2.Auth) can be electronically signed using the second terminal's certificate eUICC2.Cert, and such electronically signed data can be included as part of the second terminal authentication information (Device2.Auth).

[0566] Reference Figure 18 In operation 18025, the second terminal 1850 can transmit the second terminal authentication information (Device2.Auth) to the RSP server 1830.

[0567] Reference Figure 18In operation 18030, RSP server 1830 can verify the received second terminal authentication information (Device2.Auth). RSP server 1830 can verify the validity of eUICC2.Cert included in the second terminal authentication information (Device2.Auth), and verify the validity of the signature included in the second terminal authentication information (Device2.Auth) by using eUICC2.Cert. RSP server 1830 can verify whether the value of Server.Challenge2 included in the second terminal authentication information (Device2.Auth) is the same as the value of Server.Challenge2 transmitted by itself in operation 18015.

[0568] RSP server 1830 can identify the information eUICC2.Info2 used for the eUICC eligibility check included in the second terminal authentication information (Device2.Auth), and determine whether the configuration file to be transmitted can be installed correctly on the second terminal and can be operated on the second terminal.

[0569] RSP server 1830 can identify the eUICC ID of the received second terminal. The RSP server can identify the eUICC ID of the received second terminal to determine if a configuration file to be transmitted exists. The RSP server can identify the eUICC ID of the received second terminal to prepare the configuration file to be transmitted.

[0570] The RSP server 1830 can recognize the received configuration file delimiter. The RSP server can recognize the received configuration file delimiter to determine if a configuration file to be transmitted exists. The RSP server can recognize the received configuration file delimiter to prepare the configuration file to be transmitted.

[0571] RSP server 1830 can recognize the received activation code. The RSP server can recognize the eUICC ID of the second terminal included in the received activation code. The RSP server can recognize the eUICC ID of the second terminal included in the received activation code to determine if a configuration file to be transmitted exists. The RSP server can recognize the eUICC ID of the second terminal included in the received activation code to prepare the configuration file to be transmitted. The RSP server can recognize the configuration file separator included in the received activation code. The RSP server can recognize the configuration file separator included in the received activation code to determine if a configuration file to be transmitted exists. The RSP server can recognize the configuration file separator included in the received activation code to prepare the configuration file to be transmitted.

[0572] RSP server 1830 can generate an encryption key for encoding using the received key protocol public key generated by the eUICC of the second terminal and the key protocol private key generated by the RSP server. RSP server 1830 can then encode the configuration file to be transmitted using the encryption key.

[0573] In operation 18030, the RSP server can prepare a configuration file package related to the configuration file requested by the second terminal 1850. The configuration file package may include configuration file information to be transferred from the RSP server to the second terminal.

[0574] The configuration file package may include the encryption key used by the first terminal to generate encryption keys for... Figure 17 Information encoded in the configuration file, such as the key negotiation algorithm used to generate the encryption key, and / or encryption algorithm information used to use the encryption key, and / or the key protocol public key used by the first terminal to generate the encryption key.

[0575] The configuration file package may include information used by the RSP server to generate encryption keys to encode the configuration file, such as the key negotiation algorithm used to generate the encryption keys, and / or encryption algorithm information used to use the encryption keys, and / or the key protocol public key used by the RSP server to generate the encryption keys.

[0576] The contents of the configuration file package can be digitally signed by the certificate server of the RSP server, and the value of the digital signature can be included as part of the configuration file package.

[0577] Reference Figure 18 In operation 18035, RSP server 1830 can transfer the configuration file package to the second terminal 1850.

[0578] Reference Figure 18 In operation 18040, the second terminal 1850 can install the received configuration file package. Here, when part and / or all of the configuration file package is encoded by the first terminal, the second terminal can generate an encryption key using the received public key of the first terminal's key protocol and the private key of the second terminal's key protocol, and then decode the encoded content. Here, when the RSP server encodes part and / or all of the configuration file package, the second terminal can generate an encryption key using the received public key of the RSP server's key protocol and the private key of the second terminal's key protocol, and then decode the encoded content.

[0579] Figure 19 This is a diagram illustrating the configuration of a terminal on which eUICC is installed, according to some embodiments of the present disclosure.

[0580] refer to Figure 19 The terminal may include a transceiver 1910, a processor 1920, and an eUICC 1930. In this disclosure, some of the terminals described above may correspond to... Figure 19 The terminal described in [the document]. For example... Figures 16 to 18 The first terminal and the second terminal described herein may each include Figure 19 The terminal configuration described in the document.

[0581] However, the terminal configuration is not limited to Figure 19 And the terminal may include more Figure 19 The number of components shown may be more or less. According to some embodiments, the transceiver 1910, processor 1920, and eUICC 1930 may be implemented as a single chip. Furthermore, the terminal may also include memory, and the processor 1920 may be configured as at least one processor.

[0582] According to various embodiments, transceiver 1910 can transmit signals, information, and data according to various embodiments of the present disclosure to a transceiver of another terminal or external server and receive signals, information, and data from a transceiver of another terminal or external server. Transceiver 1910 may include an RF transmitter for up-converting and amplifying the frequency band of the transmitted signal and an RF receiver for amplifying the frequency band of the received signal with low noise and down-converting it. However, this is only one embodiment of transceiver 1910, and the components of transceiver 1910 are not limited to RF transmitters and RF receivers. Furthermore, transceiver 1910 can receive signals on a wireless channel and output such signals to processor 1920, or transmit signals output from processor 1920 on a wireless channel.

[0583] Meanwhile, the processor 1920 is typically a component used to control the terminal. The processor 1920 can control the overall operation of the terminal according to the various embodiments disclosed above.

[0584] The terminal may also include a memory (not shown) that can store data for the operation of the terminal, such as basic programs, application programs, configuration information, etc. The memory may include at least one storage medium selected from flash memory, hard disk memory, multimedia card micro-type memory, card-type memory (e.g., Secure Digital (SD) or Extreme Digital (XD) memory), magnetic storage, magnetic disk, optical disk, random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), programmable read-only memory (PROM), and electrically erasable programmable read-only memory (EEPROM). Furthermore, the processor 1920 can perform various operations using various programs, contents, and data stored in the memory.

[0585] Figure 20 This is a diagram illustrating the configuration of an RSP server according to some embodiments of the present disclosure.

[0586] Reference Figure 20 The server may include a transceiver 2010 and a processor 2020. In this disclosure, some of the servers described above may correspond to... Figure 20 The server described in [the document]. For example... Figures 16 to 18 The server described in the document may include Figure 20 The server configuration described in the document.

[0587] However, server configuration is not limited to Figure 20 And the server can include more Figure 20 The components shown may have more or fewer components. According to some embodiments, the transceiver 2010 and processor 2020 may be implemented as a single chip. Furthermore, the server may also include memory, and the processor 2020 may be configured to have at least one processor.

[0588] According to some embodiments, transceiver 2010 can transmit signals, information, and data according to various embodiments of the present disclosure to and from a terminal. Transceiver 2010 may include an RF transmitter for up-converting and amplifying the frequency band of the transmitted signal and an RF receiver for amplifying the frequency band of the received signal with low noise and down-converting it. However, this is only one embodiment of transceiver 2010, and the components of transceiver 2010 are not limited to RF transmitters and RF receivers. Furthermore, transceiver 2010 can receive signals on a wireless channel and output such signals to processor 2020, or transmit signals output from processor 2020 on a wireless channel.

[0589] Meanwhile, at least one processor 2020 is typically a component used to control the server. The processor 2020 can control the overall operation of the server according to the various embodiments disclosed above. The at least one processor 2020 can also be referred to as a controller.

[0590] Additionally, the server may include memory (not shown), which can store data used for server operations, such as basic programs, applications, configuration information, etc. The memory may include at least one storage medium selected from flash memory, hard disk memory, multimedia card micro-type memory, card-type memory (e.g., Secure Digital (SD) or Extreme Digital (XD) memory), magnetic storage, magnetic disk, optical disk, random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), programmable read-only memory (PROM), and electrically erasable programmable read-only memory (EEPROM). Furthermore, the processor 2020 can perform various operations using various programs, contents, and data stored in the memory.

[0591] Figure 21 This is a diagram illustrating another example of a process for transferring a configuration file online from one terminal to another according to embodiments of the present disclosure.

[0592] refer to Figure 21 The terminal may include at least one LPA and at least one eSIM. For example, such as Figure 16 As shown, the first terminal 2110 may include a first LPA 2130 and a first eSIM 2120, and the second terminal 2160 may include a second LPA 2180 and a second eSIM 2170. Details regarding the RSP server have been described above (e.g., in...). Figure 16 middle).

[0593] In operation 21000, the first terminal 2110 and the second terminal 2160 can perform the preparation process required for transferring the configuration file (configuration file transfer preparation process). The following will refer to... Figure 22 Describe the details of the configuration file transfer preparation process.

[0594] In operation 21005, the second terminal 2160 can request the RSP server 2150 to transfer the configuration file. The following will refer to... Figure 23 Describe the details of the corresponding process.

[0595] In operation 21010, the first terminal 2110 can upload the configuration file to be transferred to the second terminal to the RSP server 2150. The following will refer to... Figure 24 Describe the details of the corresponding process.

[0596] In operation 21015, the second terminal 2160 can download the configuration file uploaded in operation 21010 from the RSP server 2150 and install the configuration file. The following will refer to... Figure 25 Describe the details of the corresponding process.

[0597] Figure 22 This is a diagram illustrating a detailed process of preparing a transmission configuration file according to an embodiment of the present disclosure.

[0598] refer to Figure 22 The terminal may include at least one LPA and at least one eSIM. For example, the first terminal 2210 may include a first LPA 2230 and a first eSIM 2220, and the second terminal 2260 may include a second LPA 2280 and a second eSIM 2270.

[0599] According to various embodiments, the first terminal 2210 may include a pre-installed configuration file and metadata associated with the pre-installed configuration file. According to various embodiments, the first terminal 2210 may include a configuration file separator associated with the pre-installed configuration file.

[0600] According to various embodiments, the first terminal 2210 may include a configuration file transfer configuration associated with a pre-installed configuration file. According to various embodiments, the configuration file transfer configuration is a set of policies related to configuration file transfer between devices, and may have been generated by a mobile operator, an RSP server, or a collaboration between a mobile operator and an RSP server as described above. According to various embodiments, the configuration file transfer configuration in the terminal may be updated by a mobile operator, an RSP server, or a collaboration between a mobile operator and an RSP server. Alternatively, the configuration file transfer configuration may be updated through collaboration between the terminal and at least one of the entities of the mobile operator and the RSP server. The timing and / or method for updating the configuration file transfer configuration may be determined by the policies of the mobile operator, the RSP server, or the terminal manufacturer.

[0601] The configuration file transfer configuration may include factors (or indicators) indicating whether the transfer of configuration files between devices is permitted. Furthermore, the configuration file transfer configuration may optionally include factors specifying conditions under which the transfer of configuration files between devices is permitted. For example, the configuration file transfer configuration may configure whether a configuration file can be transferred (or transmitted) online from one terminal to another. As another example, the configuration file transfer configuration may configure the format used to transfer the configuration file. For example, the configuration file may be transferred as a configuration file package or as a configuration file image, or only a portion of the configuration file data may be transferred (e.g., representing part or all of a series of updates that occur after the configuration file is installed on the first terminal. These updates may include data stored by the user, values ​​set by the user, or details about updates performed by the mobile operator or RSP server). The configuration file transfer configuration may include information about which (or which) of the possible transfer formats of the configuration file are permitted. This factor may be electronically signed by at least one entity, including the RSP server, mobile operator, terminal manufacturer, eUICC, or eUICC manufacturer. The value of the electronic signature may be stored in the first terminal as part of or along with the configuration file transfer configuration.

[0602] Reference Figure 22 In operation 22000, the first LPA 2230 can obtain information about the configuration file to be transmitted. Alternatively, information about the configuration file to be transmitted can be passed to the first LPA 2230. For example, the first LPA 2230 can obtain information about the configuration file to be transmitted by receiving user input from a user selecting a configuration file via a UI provided by the first terminal 2210. Alternatively, information about the configuration file to be transmitted can be input to the first LPA 2230 via push input from a remote server, or the first LPA 2230 can read information about the configuration file to be transmitted by accessing a remote server. However, the method by which the first LPA 2230 obtains information about the configuration file to be transmitted is not limited to these methods.

[0603] Reference Figure 22 In operation 22005, the first LPA 2230 can identify whether a configuration file is transferable by using (e.g., checking) the configuration file transfer configuration (or configuration file transfer settings). Furthermore, the first LPA 2230 can identify whether online transfer of the configuration file is feasible by checking the configuration file transfer configuration. Moreover, the first LPA 2230 can identify the format used to transfer the configuration file (e.g., configuration file image, configuration file package, or partial data of the configuration file) by checking the configuration file transfer configuration.

[0604] Reference Figure 22 In operation 22010, the first LPA 2230 may generate a configuration file transfer code (or configuration file delivery code). The configuration file transfer code may include a configuration file separator for the configuration file to be transferred. Furthermore, the configuration file transfer code may include the address of the RSP server associated with the configuration file to be transferred. (Later, the second terminal 2260 can download the configuration file by accessing the RSP server using said address.) Additionally, the configuration file transfer code may include other information indicating the attributes of the configuration file (e.g., metadata of the configuration file or a portion of the metadata). Furthermore, the configuration file transfer code may include information (SupportedCryptoInfo) regarding the cryptographic algorithms supported by the first terminal (e.g., the first eSIM). The information regarding the cryptographic algorithms supported by the first terminal may optionally include at least one of the following: a list of elliptic curve cryptography supported by the first terminal, a list of key negotiation algorithms supported by the first terminal, and a list of cryptographic algorithms supported by the first terminal.

[0605] Reference Figure 22 In operation 22015, the configuration file transfer code generated in operation 22010 can be transferred from the first LPA 2230 to the second LPA 2280. The configuration file transfer code can be transferred via any of a variety of methods.

[0606] For example, the first LPA 2230 can provide information to be transmitted to the second LPA 2280 to the first user of the first terminal through the UI of the first terminal. The first user can provide the provided information to the second user of the second terminal. The second user can input the provided information to the second LPA 2280 through the UI of the second terminal.

[0607] Alternatively, the first LPA 2230 can generate an image (e.g., a QR code) of the information to be transmitted to the second LPA 2280 and display the information on the screen of the first terminal, and the second user can scan the image displayed on the screen of the first terminal using the second terminal 2260 and transmit the information to the second LPA 2280.

[0608] Alternatively, the first LPA 2230 can establish a connection between the first LPA 2230 and the second LPA 2280, and transmit the information to be transmitted using the established connection. Here, the connection established between the first LPA 2230 and the second LPA 2280 can be a direct connection between devices (e.g., a wireless connection such as NFC, Bluetooth, UWB, Wi-Fi Direct, LTE device-to-device (D2D) or 5G D2D, or a wired connection such as a cable connection), or a remote connection in which a remote server (e.g., a relay server) is located between the first LPA 2230 and the second LPA 2280.

[0609] Figure 23 This is a diagram illustrating the process by which a second terminal 2360, according to an embodiment of the present disclosure, requests an RSP server 2350 to transmit a configuration file.

[0610] refer to Figure 23 The terminal may include at least one LPA and at least one eSIM. For example, the second terminal 2360 may include a second LPA 2380 and a second eSIM 2370. (Already referenced) Figure 16 Details about the RSP server 2350 are described.

[0611] Reference Figure 23 In operation 23000, mutual authentication can be performed between the second terminal 2360 and the RSP server 2350. Such a mutual authentication process may include at least one of the following processes.

[0612] The mutual authentication process may include a certificate negotiation process to be performed for communication between the second terminal and the RSP server. For example, the second terminal may transmit multiple certificate information that can be used to verify the RSP server and / or multiple certificate information that the RSP server can use to verify the second terminal. Upon receiving such information, the RSP server can select the certificate information that the second terminal can use to verify the RSP server and the certificate information that the RSP server can use to verify the second terminal. Here, the multiple certificate information selected by the RSP server can be transmitted to the second terminal. Through this process, the second terminal and the RSP server can obtain certificate information for mutual authentication. Here, certificate information may represent a certificate and / or information included in the certificate and / or a series of information that can reference the certificate.

[0613] The second terminal can transmit its own generated random number (eUICC Challenge) value to the RSP server. The RSP server can digitally sign the received value or random number and transmit the signed value to the second terminal. The second terminal can verify the received signature value to authenticate the RSP server.

[0614] The RSP server can transmit a self-generated random number (server challenge) to the second terminal. The second terminal can digitally sign the received value or random number and transmit the signed value to the RSP server. The RSP server can verify the received signature value to authenticate the second terminal.

[0615] When the RSP server and the second terminal communicate with each other, they can exchange IDs (transaction IDs) used to manage the session. For example, the RSP server can generate a transaction ID and transmit its value to the second terminal. Here, the RSP server's digital signature value can be added to identify the reliability and integrity of the transaction ID.

[0616] The RSP server and the second terminal can exchange configuration file delimiters associated with the configuration files to be transmitted in this disclosure. For example, the second terminal can transmit the delimiter of the configuration file to be received to the RSP server. Here, the configuration file delimiter can be transmitted along with the second terminal's electronic signature value to ensure reliability and integrity.

[0617] The RSP server and the second terminal can exchange their IDs. For example, the RSP server can provide its object identifier (OID) to the second terminal. As another example, the second terminal can provide its eUICC ID to the RSP server.

[0618] Reference Figure 23 In operation 23005, RSP server 2350 can transmit RSP server authentication information (Server.Auth2) to the second LPA 2380. For example, the following procedure can be performed.

[0619] RSP server 2350 can identify configuration file transmission settings. For example, RSP server 2350 can identify the received configuration file delimiter and determine whether configuration file transmission is feasible by checking the configuration file transmission settings associated with the configuration file. Furthermore, RSP server 2350 can determine whether online transmission of the configuration file is feasible by checking the configuration file transmission settings. Moreover, RSP server 2350 can identify the format used to transmit the configuration file (e.g., configuration file image, configuration file package, or partial data of the configuration file) by checking the configuration file transmission settings.

[0620] RSP server 2350 can perform qualification checks to identify whether a configuration file can be installed and used on a second terminal. For example, RSP server 2350 can check whether a configuration file can be installed and operated on a second terminal by using the received eUICC ID of the second terminal and the received configuration file separator.

[0621] RSP server 2350 can generate transfer options in response to a configuration file receiving request from a second terminal. Transfer options may include information about whether the configuration file can be transferred to the second terminal, and, if transfer is feasible, information about the transfer type. For example, transfer options may include at least one of the following values.

[0622] - Configuration files can be transmitted as configuration file images.

[0623] - Configuration files can be transmitted as configuration file packages.

[0624] - Some data in the configuration file is transferable.

[0625] - Transferring the configuration file is not feasible

[0626] RSP server 2350 can transmit transmission options to second LPA 2380. Here, the transmission options can be electronically signed by RSP server 2350. The value of the electronic signature can be transmitted to second LPA 2380 along with the transmission options. Furthermore, the RSP server's certificate and related information (including the encryption key used for electronic signing) can be transmitted to second LPA 2380.

[0627] Reference Figure 23 In operation 23015, the second eSIM 2370 can transmit the second terminal authentication information (Device2.Auth) to the RSP server 2350. For example, the following procedure can be performed.

[0628] The second LPA2380 can identify the received transmission options and obtain the user's consent.

[0629] The second LPA2380 can transmit the received transmission options to the second eSIM 2370. The second LPA2380 can also transmit the signature value of the received transmission options to the second eSIM 2370. Furthermore, the second LPA2380 can transmit a certificate and related information to the second eSIM 2370, which is used to verify the electronic signature value of the received transmission options.

[0630] The second LPA 2380 may optionally further transmit the SupportedCryptoInfo received in operation 22015 to the second eSIM 2370.

[0631] Reference Figure 23 The following procedure can be performed in operation 23015.

[0632] The second eSIM 2370 can verify the validity of the certificate and related information received in operation 23010.

[0633] The second eSIM 2370 can verify the validity of the digital signature value received in operation 23010.

[0634] The second eSIM 2370 can identify details of the transmission options received in operation 23010.

[0635] Upon receiving SupportedCryptoInfo, the second eSIM 2370 can identify the details of the received SupportedCryptoInfo and determine whether its supported encryption algorithms are present within it. If the encryption algorithms supported by the second eSIM are present in the received SupportedCryptoInfo, the second eSIM 2370 can select one of the encryption algorithms as the selected encryption algorithm (SelectedCryptoInfo). The selected encryption algorithm may optionally include at least one of the following: elliptic curve information, key negotiation algorithm information, and encryption algorithm information. In operation 23015, the second eSIM 2370 may also transmit the selected encryption algorithm (SelectedCryptoInfo) to the RSP server 2350.

[0636] The second eSIM 2370 can generate a public key otPK.EUICC.KA and a private key otSK.EUICC.KA, which are key pairs used for encryption. These key pairs are used to generate encryption keys for encrypted communication. Here, the generated encryption keys can be used for encrypted communication between the RSP server and the second terminal, or for encrypted communication between the first terminal and the second terminal. When the generated encryption keys are used for encrypted communication between the first terminal and the second terminal, the encryption keys (otPK.EUICC.KA and otSK.EUICC.KA) can be encryption keys that conform to the encryption algorithms included in SelectedCryptoInfo.

[0637] The second eSIM 2370 can transmit the generated otPK.EUICC.KA to the RSP server 2350. The encryption key can be digitally signed by the second eSIM. The value of the digital signature generated by the second eSIM can be transmitted to the RSP server. The encryption key and / or the value of the digital signature can be referred to as Device2.Auth.

[0638] The second eSIM 2370 can also selectively transmit selected encrypted information to the RSP server 2350 via the second LPA 2380.

[0639] Figure 24 This is a diagram illustrating the process by which a first terminal 2410, according to an embodiment of the present disclosure, uploads a configuration file to be transmitted to a second terminal to an RSP server 2450.

[0640] refer to Figure 24 The terminal may include at least one LPA and at least one eSIM. For example, the first terminal 2410 may include a first LPA 2430 and a first eSIM 2420. (Already referenced) Figure 16 Details about the RSP server 2450 are described.

[0641] Reference Figure 24 In operation 24000, mutual authentication can be performed online between the first terminal 2410 and the RSP server 2450. Such a mutual authentication process may include at least one of the following processes.

[0642] The mutual authentication process may include a certificate negotiation process to be performed for communication between the first terminal 2410 and the RSP server 2450. For example, the first terminal 2410 may transmit to the RSP server 2450 multiple certificate information that can be used to verify the RSP server 2450 and / or multiple certificate information that the RSP server 2450 can use to verify the first terminal 2410. Upon receiving such information, the RSP server 2450 can select multiple certificate information to be used by the first terminal 2410 to verify the RSP server 2450 and to verify the first terminal 2410. Here, each certificate information selected by the RSP server 2450 can be transmitted to the first terminal 2410. Through this process, the first terminal 2410 and the RSP server 2450 can obtain certificate information for mutual verification. Here, certificate information may represent a certificate, and / or information included in a certificate, and / or a series of information that can reference a certificate.

[0643] - The first terminal 2410 can transmit the value of a random number (eUICC Challenge) generated by itself to the RSP server 2450. The RSP server 2450 can electronically sign the received value or random number and transmit the signed value to the first terminal 2410. The first terminal 2410 can verify the received signed value to authenticate the RSP server 2450.

[0644] RSP server 2450 can transmit the value of a random number (serverChallenge) it generates to first terminal 2410. First terminal 2410 can electronically sign the received value or random number and transmit the signed value to RSP server 2450. RSP server 2450 can verify the received signed value to authenticate first terminal 2410.

[0645] When the RSP server 2450 and the first terminal 2410 communicate with each other, they can exchange IDs (transaction IDs) used to manage the session. For example, the RSP server 2450 can generate a transaction ID and transmit its value to the first terminal 2410. Here, the RSP server's electronic signature value can be added to identify the reliability and integrity of the transaction ID.

[0646] RSP server 2450 and first terminal 2410 can exchange configuration file delimiters associated with the configuration files to be transmitted in this disclosure. For example, first terminal 2410 can transmit the delimiter of the configuration file to be transmitted to RSP server 2450. Here, the configuration file delimiter can be transmitted along with the value of the first terminal 2410's electronic signature to ensure reliability and integrity.

[0647] - RSP server 2450 and first terminal 2410 can exchange IDs. For example, RSP server 2450 can provide its object identifier (OID) to first terminal 2410. As another example, first terminal 2410 can provide its eUICC ID to RSP server 2450.

[0648] Although not shown, the first terminal 2410 can be on standby between operations 24000 and 24005.

[0649] Reference Figure 24 In operation 24005, RSP server 2450 can transmit RSP server authentication information (Server.Auth1) to the first eSIM 2420. For example, the following procedure can be performed.

[0650] RSP server 2450 can generate a public key otPK.DP.KA and a private key otSK.DP.KA, which are key pairs used for encryption. These key pairs are used to generate encryption keys for encrypted communication with the first eSIM 2420.

[0651] RSP server 2450 can transmit the public key otPK.XX.KA to first eSIM 2420 via first LPA 2430. Here, otPK.XX.KA can be otPK.EUICC.KA or otPK.DP.KA received in operation 23015.

[0652] RSP server 2450 can transmit transfer options to first eSIM 2420 via first LPA 2430. Transfer options may include information about whether a configuration file can be transferred to a second terminal, and, if transfer is feasible, information about the type of transfer. For example, transfer options may include at least one of the following values.

[0653] - Configuration files can be transmitted as configuration file images.

[0654] - Configuration files can be transmitted as configuration file packages.

[0655] - Some data in the configuration file is transferable.

[0656] - Transferring the configuration file is not feasible

[0657] Here, the otPK.XX.KA and / or transfer option transmitted to the first eSIM 2420 can be electronically signed by the RSP server 2450. The electronically signed value can be transmitted to the first eSIM 2420 via the first LPA 2430. Furthermore, the certificate and related information of the RSP server, which can be used to verify the electronic signature, can be transmitted to the first eSIM 2420 via the first LPA 2430.

[0658] In operation 24005, RSP server 2450 may also selectively transmit the SelectedCryptoInfo received in operation 23015 to first eSIM 2420 via first LPA 2430.

[0659] The first terminal 2410 (e.g., the first LPA 2430) may receive an end-user license in relation to the received transmission options.

[0660] Reference Figure 24 In operation 24010, the RSP server 2450 can transmit first terminal authentication information (Device1.Auth) to the first eSIM 2420. For example, the following procedure can be performed.

[0661] The first eSIM 2420 can verify the validity of the certificate and related information received in operation 24005.

[0662] The first eSIM 2420 can verify the validity of the digital signature value received in operation 24005.

[0663] The first eSIM 2420 can identify the details of the transmission options received in operation 24005.

[0664] The first eSIM 2420 can generate a public key otPK.EUICC.KA and a key otSK.EUICC.KA, which are key pairs used for encryption to generate encryption keys for encrypted communication. Here, the generated encryption key can be used for encrypted communication between the RSP server and the first terminal, or for encrypted communication between the first terminal and the second terminal. The value of otPK.XX.KA received in operation 24005 can be used to determine which encrypted communication the generated encryption key is for. The first eSIM 2420 can calculate the value of the digital signature of the generated otPK.EUICC.KA. The values ​​of otPK.EUICC.KA and / or the digital signature can be collectively referred to as Device1.Auth.

[0665] The first eSIM 2420 can generate a session key for encrypted communication using its own generated otSK.EUICC.KA and the otPK.XX.KA received in operation 24005.

[0666] The first eSIM 2420 (and, if necessary, the first LPA 2430) can prepare a configuration file to be transmitted to the second terminal. Here, the format of the prepared configuration file can match the transmission options received in operation 24005. In other words, the format of the prepared configuration file can be one of the following.

[0667] -Configuration image

[0668] -Configuration package

[0669] - Partial data from the configuration file

[0670] All and / or part of the prepared configuration file can be encoded by the session key. Furthermore, all and / or part of the prepared configuration file can be digitally signed by the first terminal, and the value of the digital signature can be included as part of the prepared configuration file.

[0671] The first eSIM 2420 can delete the configuration file. Whether or not the configuration file is deleted can be notified to the RSP server 2450.

[0672] The first eSIM 2420 can transmit Device1.Auth and / or the prepared configuration file to the RSP server 2450 via the first LPA 2430.

[0673] Reference Figure 24 In operation 24015, RSP server 2450 can transmit a response message to first LPA 2430 indicating that all processes have been executed.

[0674] Figure 25 This is a diagram illustrating the process by which a second terminal 2560, according to an embodiment of the present disclosure, downloads a prepared configuration file uploaded from an RSP server 2550 and installs the prepared configuration file.

[0675] refer to Figure 25 The terminal may include at least one LPA and at least one eSIM. For example, the second terminal 2560 may include a second LPA 2580 and a second eSIM 2570. (Already referenced) Figure 16 Details about the RSP server 2550 are described.

[0676] Although not shown, it is in execution Figure 23 Following operation 23015, the second terminal 2560 can remain in standby mode until operation 25000, as described below, is executed. This standby process can be performed using any of the various methods described below. However, the standby process is not limited to these methods and is not necessarily one of those methods.

[0677] a) RSP server 2550 can transmit a message to second LPA 2580 indicating that the requested operation has been received, but it needs to wait until a response is received. Second LPA 2580 can wait for a period of time, then transmit a message to RSP server 2550 to verify whether the requested operation has been executed. When the operation is completed, operation 25000 can be executed. If the operation is not completed, RSP server 2550 can transmit a message indicating a slightly longer wait time. In this case, second LPA 2580 can wait for a period of time again, then transmit a message to RSP server 2550 again to verify whether the requested operation has been executed. This process can be repeated until operation 25000 is executed.

[0678] b) The second LPA 2580 can standby until operation 25000 is executed within a defined time frame. If operation 25000 is not executed within the defined time frame, configuration file transmission can be stopped.

[0679] c) RSP server 2550 may notify the second LPA 2580 that the requested operation has been received. (For example, the RSP server may transmit a push message to the second LPA 2580.) Operation 25000 may then be performed.

[0680] Reference Figure 25 The following process can be executed.

[0681] RSP server 2550 can verify the validity of the electronic signature value of Device2.Auth received in operation 23015.

[0682] RSP server 2550 can identify the details of Device2.Auth received in operation 23015.

[0683] The RSP server 2550 can generate a public key otPK.DP.KA and a key otSK.DP.KA, which are key pairs used for encryption. These key pairs are used to generate encryption keys for encrypted communication. Here, the generated encryption keys can be used for encrypted communication between the RSP server and the second terminal. The RSP server can use the generated encryption key pairs to generate session keys for encrypted communication with the second terminal.

[0684] RSP server 2550 can prepare the binding configuration file to be transferred to the second terminal.

[0685] Here, the prepared binding configuration file can be one of the following formats.

[0686] - The configuration file image received in operation 24010

[0687] - Configuration file package received in operation 24010

[0688] - A configuration file package and / or image generated using partial data from the configuration file received in operation 24010.

[0689] - Includes partial data from the configuration file received in Operation 24010 as additional data in the configuration file package or image.

[0690] When the data received in operation 24010 is encoded using the session key for encrypted communication between the first terminal and the RSP server, the following procedures can be performed additionally. The RSP server can decode the received data. The RSP server can then encode the decoded data using the session key to enable encrypted communication between the second terminal and the RSP server.

[0691] In operation 25000, RSP server 2550 can transfer the binding configuration file to the second LPA 2580.

[0692] Reference Figure 25 The following process can be executed.

[0693] The second LPA 2580 can verify the received binding profile. For example, the second LPA 2580 can identify and verify the details of the metadata included in the binding profile. Furthermore, the second LPA 2580 can receive end-user licenses associated with the binding profile.

[0694] In operation 25005, the second LPA 2580 and the second eSIM 2570 can install the received binding profile in the second eSIM 2570.

[0695] Reference Figure 25 In operation 25010, the second eSIM 2570 can notify the RSP server 2550 that the configuration file has been installed via the second LPA 2580.

[0696] In the above embodiments of this disclosure, elements included in this disclosure are represented in a singular or plural form according to the embodiments. However, the singular or plural form is appropriately chosen for ease of explanation, and this disclosure is not limited thereto. Thus, elements represented in a plural form may also be configured as a single element, and elements represented in a singular form may also be configured as a plural element.

[0697] Furthermore, while specific embodiments have been described in the detailed description of this disclosure, various modifications can be made without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the above embodiments, but should be determined not only by the scope of the appended claims, but also by the equivalents of the claims.

[0698] It should be understood that the various embodiments of this disclosure and the terminology used herein are not intended to limit the technology described herein to the specific embodiments, but rather to include various modifications, equivalents, and / or alternatives to the corresponding embodiments. Regarding the description of the drawings, the same reference numerals may denote the same elements. Expressions used in the singular may include plural expressions unless they have a clearly different meaning in the context. In this disclosure, expressions such as “A or B,” “at least one of A and / or B,” “A, B, or C,” or “at least one of A, B, and / or C” include all possible combinations of the listed elements. Expressions such as “first,” “second,” etc., may modify the corresponding elements regardless of their order or importance and are used merely to distinguish one element from another, without limiting the corresponding element. When one element (e.g., a first element) is (functionally or communicatively) connected to or accessed by another element (e.g., a second element), that element may be connected directly or through another element (e.g., a third element).

[0699] As used in this disclosure, the term "module" includes a unit consisting of hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module can be a component configured as a whole, a minimum unit performing one or more functions, or a portion thereof. For example, a module may be configured as an application-specific integrated circuit (ASIC).

[0700] Various embodiments of this disclosure can be implemented as machine-readable storage media (e.g., software including instructions stored in internal or external memory, such as a program). A machine is a device capable of recalling stored instructions from a storage medium and operating according to the recalled instructions, and may include a terminal according to the various embodiments. When instructions are sent by a processor (e.g., ... Figure 14 When the processor 1420 is executed, the processor may perform the function corresponding to the instructions directly or by using other components controlled by the processor. Instructions may include code generated or executed by a compiler or interpreter.

[0701] Machine-readable storage media may be provided in the form of non-transitory storage media. The term "non-transitory" means only that the storage medium does not include signals and is tangible, and does not distinguish whether the data is stored in the storage medium semi-permanently or temporarily.

[0702] Methods according to various embodiments of this disclosure can be provided by being included in a computer program product. A computer program product is a product that can be traded between a seller and a buyer. The computer program product can be distributed in the form of a machine-readable storage medium (e.g., an optical disc read-only memory (CD-ROM)) or through an app store (e.g., the Play Store). TM Online distribution. In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated in a storage medium, such as the manufacturer's server, the app store's server, or the memory of a relay server. Each of the components (e.g., modules or programs) according to various embodiments may include single or multiple entities, and some of the aforementioned sub-components may be omitted, or other sub-components may be further included in the various embodiments. Alternatively or additionally, some components (e.g., modules or programs) may be integrated into one entity, and the functions performed by each component prior to integration may be performed in the same or similar manner. According to various embodiments, operations performed by modules, programs, or other components may be performed sequentially, in parallel, repeatedly, or tentatively, and at least some operations may be performed in a different order or omitted, or other operations may be added.

Claims

1. A first terminal for providing a bundle to a second terminal in a wireless communication system, the first terminal comprising: transceiver; as well as At least one processor, configured as follows: Obtain information related to the bundle to be transmitted to the second terminal; Based on the bundle transmission configuration information, including an indicator that the first terminal can transmit the bundle to another terminal, it is determined that the first terminal can transmit the bundle to the second terminal. Generate a bundle transfer code that includes the identification information of the bundle to be transmitted to the second terminal; The generated bundle transfer code is transmitted to the second terminal; Transmit bundle transmission authentication information to the bundle management server. The bundle transmission authentication information includes at least one of the following: the first intelligent security platform SSP information of the first terminal, the certificate negotiation information between the first terminal and the bundle management server for authentication, or the version information of the first SSP of the first terminal. Receive server authentication information based on the transmitted bundle authentication information from the bundle management server; Based on the received server authentication information, the first terminal authentication information and the bundle ID of the bundle to be transmitted to the second terminal are transmitted to the bundle management server. as well as In response to receiving a bundle request message based on the first terminal authentication information from the bundle management server, the bundle to be transmitted to the second terminal is uploaded to the bundle management server. The bundle to be transmitted to the second terminal is transmitted to the second terminal via the bundle management server so that it can be installed on the second terminal.

2. The first terminal as described in claim 1, wherein, The bundle transfer configuration information includes at least one of the following: information related to the conditions required for bundle transfer between the first terminal and the second terminal, or an indicator indicating whether bundle transfer between the first terminal and the second terminal is permitted through the bundle management server.

3. The first terminal as described in claim 1, wherein, The identification information of the bundle includes at least one of the following: the identity ID of the bundle to be transmitted to the second terminal, the bundle family ID (Fid) or the bundle family managed object ID (Oid), and The bundle transmission code further includes at least one of the following: information related to the attributes of the bundle to be transmitted to the second terminal, the address of the bundle management server, information for connecting the first terminal and the second terminal, or encryption algorithm information supported by the first terminal.

4. The first terminal as described in claim 1, wherein, The bundle request message is generated by the bundle management server based on the first terminal authentication information, which determines the first terminal as a terminal capable of transmitting the bundle to the second terminal.

5. A second terminal for receiving a bundle from a first terminal in a wireless communication system, the second terminal comprising: transceiver; as well as At least one processor, configured as follows: Receive a bundle transmission code from the first terminal, which includes identification information of the bundle to be received by the second terminal; The second intelligent security platform (SSP) information is transmitted to the bundle management server. The second SSP information includes certificate negotiation information for authentication between the bundle management server and the second SSP of the second terminal. Receive server authentication information generated by the bundle management server based on the second SSP information from the bundle management server; Based on the server authentication information, second terminal information, including the ID of the second SSP and the ID of the bundle to be received, is transmitted to the bundle management server. as well as In response to the bundle management server determining that the ID of the second SSP and the identification information of the bundle to be received by the second terminal correspond to the ID of the second SSP and the ID of the bundle to be received, respectively, the first bundle and information related to the first bundle are received from the bundle management server.

6. The second terminal as described in claim 5, wherein, The identification information of the bundle to be received by the second terminal includes at least one of the following: the identity ID of the bundle to be received by the second terminal, the bundle family ID (Fid) or the bundle family managed object ID (Oid), and The bundle transmission code further includes at least one of the following: information relating to the attributes of the bundle to be received by the second terminal, the address of the bundle management server, information for connecting the first terminal to the second terminal, or encryption algorithm information supported by the first terminal.

7. The second terminal as described in claim 5, wherein, The bundle management server is configured to: determine the second terminal as a terminal capable of receiving bundles from another terminal based on bundle transmission configuration information, and The bundle management server is configured to identify the bundle to be received as one that can be installed on the second terminal.

Images