Apparatus and methods for device to device bundle or profile online transfer

Abstract

The present disclosure discloses a method and apparatus for securely moving a bundle or profile online between smart security media. A method for a first terminal providing a bundle to a second terminal according to one embodiment of the present disclosure may include: obtaining information regarding a bundle to be transmitted to the second terminal; transmitting a transmission code of the bundle to the second terminal; receiving at least one of encryption information and bundle usage information of the second terminal from the second terminal; performing an authentication procedure to upload the bundle to a server based on at least one of the received encryption information and bundle usage information of the second terminal; and uploading the bundle to the server based on the authentication procedure.

Description

Technology Field

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

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

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

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

[0005] As mentioned above, the advancement of mobile communication systems has enabled the provision of various services, thereby requiring measures to effectively deliver these services. For example, methods are needed to safely and efficiently transfer bundles or profiles (or profile packages) online between two devices. The problem to be solved

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

[0007] A method for a first terminal to provide a bundle to a second terminal in a wireless communication system according to one embodiment of the present disclosure may include: obtaining information regarding a bundle to be transmitted to the second terminal; transmitting a transmission code of the bundle to the second terminal; receiving at least one of encryption information and bundle usage information of the second terminal from the second terminal; performing an authentication procedure to upload the bundle to a server based on at least one of the received encryption information and bundle usage information of the second terminal; and uploading the bundle to the server based on the authentication procedure.

[0008] A method for a second terminal to receive a bundle from a first terminal according to one embodiment of the present disclosure may include: receiving a transmission code of the bundle from the first terminal; generating at least one of encryption information and bundle usage information of the second terminal based on the received transmission code; transmitting at least one of the generated encryption information and bundle usage information of the second terminal to the first terminal; performing an authentication procedure with a server to download the bundle; and downloading the bundle from the server based on the authentication procedure. Effects of the invention

[0009] According to various embodiments of the present disclosure, a bundle or profile installed on one device can be transmitted online to another device and installed on another device in a safe and efficient manner. Brief explanation of the drawing

[0010] FIG. 1 shows a conceptual diagram of a Smart Secure Platform (SSP) according to an embodiment of the present disclosure. FIG. 2 shows a conceptual diagram of the internal structure of an SSP according to an embodiment of the present disclosure. FIG. 3 is a drawing illustrating an example of a component within a terminal used by a terminal according to an embodiment of the present disclosure to download and install a bundle as an SSP. FIG. 4 is a diagram illustrating an example of a method in which two terminals and a server interact with each other to enable online transmission of a bundle from one terminal to another terminal according to an embodiment of the present disclosure. FIG. 5 is a diagram conceptually illustrating an example of a procedure for online transmission of a bundle from one terminal to another terminal according to an embodiment of the present disclosure. FIG. 6 is a drawing illustrating a detailed procedure for preparing for bundle transmission among the procedures presented in FIG. 5 according to an embodiment of the present disclosure. FIG. 7 is a diagram illustrating the procedure in which a terminal to transmit a bundle uploads the bundle to a server among the procedures presented in FIG. 5 according to an embodiment of the present disclosure. FIG. 8 is a diagram illustrating a procedure in which a bundle uploaded to a server is downloaded to a terminal receiving the bundle, according to an embodiment of the present disclosure, during the procedure presented in FIG. 5. FIG. 9 is a diagram conceptually illustrating another example of a procedure for transmitting a bundle online from one terminal to another terminal according to an embodiment of the present disclosure. FIG. 10 is a drawing illustrating a detailed procedure for preparing for bundle transmission among the procedures presented in FIG. 9 according to an embodiment of the present disclosure. FIG. 11 is a diagram illustrating a procedure in which a terminal that has received a bundle communicates with a server to receive approval among the procedures presented in FIG. 9 according to an embodiment of the present disclosure. FIG. 12 is a diagram illustrating the procedure in which a terminal to transmit a bundle uploads the bundle to a server among the procedures presented in FIG. 9 according to an embodiment of the present disclosure. FIG. 13 is a diagram illustrating a procedure in which a bundle uploaded to a server is downloaded to a terminal receiving the bundle, according to an embodiment of the present disclosure, during the procedure presented in FIG. 9. FIG. 14 is a diagram illustrating the configuration of a terminal equipped with an SSP according to some embodiments of the present disclosure. FIG. 15 is a diagram illustrating the configuration of a bundle management server according to some embodiments of the present disclosure. FIG. 16 is a diagram illustrating an example of a method in which two terminals and a server interact with each other to enable online transmission of a profile from one terminal to another terminal according to an embodiment of the present disclosure. FIG. 17 is a diagram illustrating the first part of the process of transmitting a profile online from one terminal to another terminal according to some embodiments of the present disclosure. FIG. 18 is a diagram illustrating the latter part of the process of transmitting a profile online from one terminal to another terminal according to some embodiments of the present disclosure. FIG. 19 is a diagram illustrating the configuration of a terminal equipped with an embedded Universal Integrated Circuit Card (eUICC) according to some embodiments of the present disclosure. FIG. 20 is a diagram illustrating the configuration of a Remote SIM Provisioning (RSP) server according to some embodiments of the present disclosure. FIG. 21 is a diagram conceptually illustrating another example of a procedure for transmitting a profile online from one terminal to another terminal according to one embodiment of the present disclosure. FIG. 22 is a drawing illustrating a detailed procedure for preparing a profile transmission according to one embodiment of the present disclosure. FIG. 23 is a diagram illustrating a procedure in which a second terminal requests profile transmission to an RSP server according to one embodiment of the present disclosure. FIG. 24 is a diagram illustrating a procedure in which a first terminal uploads a 'profile to be transmitted to a second terminal' to an RSP server according to an embodiment of the present disclosure. FIG. 25 is a diagram illustrating a procedure in which a second terminal, according to one embodiment of the present disclosure, downloads and installs a ‘prepared profile’ uploaded from an RSP server. Specific details for implementing the invention

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

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

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

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

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

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

[0017] In this embodiment, the term "part" refers to a software or hardware component, such as an FPGA or ASIC, and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or configured to operate one or more processors. Accordingly, as an example, the "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." Furthermore, the components and "parts" may be implemented to operate one or more CPUs within a device or secure multimedia card.

[0018] In the present disclosure, modifiers such as "first," "second," etc., referring to terms may be used to distinguish each term from one another when describing embodiments. The terms modified by modifiers such as "first," "second," etc., may refer to different objects. However, the terms modified by modifiers such as "first," "second," etc., may refer to the same object. That is, modifiers such as "first," "second," etc., may be used to refer to the same object from different perspectives. For example, modifiers such as "first," "second," etc., may be used to distinguish the same object in terms of function or operation. For example, the first user and the second user may refer to the same user.

[0019] Furthermore, although the present disclosure describes each embodiment using an SSP as an example of a security medium, the scope of the rights of the present disclosure is not limited to the SSP. For example, it is obvious to those skilled in the art that the various embodiments described below can be applied substantially identically or similarly to other security media that perform substantially the same or similar functions as the SSP.

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

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

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

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

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

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

[0026] "eSE (Embedded Secure Element)" refers to a fixed SE that is fixed to an electronic device. The eSE is typically manufactured exclusively for the manufacturer at the request of the terminal manufacturer and may be manufactured to include an operating system and a framework. An applet-type service control module can be remotely downloaded and installed on the eSE, and the installed service control module can be used for various security service purposes, such as electronic wallets, ticketing, electronic passports, and digital keys. In this disclosure, a single-chip type SE attached to an electronic device, to which a service control module can be remotely downloaded and installed, is collectively referred to as an eSE.

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

[0028] Depending on the bundles downloaded and installed, the SSP may be used for the purposes of the aforementioned UICC or eSE; furthermore, by installing multiple bundles on a single SSP and operating them simultaneously, the SSP may be used for a mixed purpose combining UICC and eSE. That is, when a bundle containing a profile is in operation, the SSP may be used as a UICC to connect to a mobile carrier's network. In a UICC bundle, at least one profile, such as the aforementioned eUICC or iUICC, may be downloaded remotely into the bundle, and one or more of these profiles may be selected. Additionally, when a bundle containing a service control module equipped with an application capable of providing services such as electronic wallets, ticketing, electronic passports, or digital keys is in operation on the SSP, the SSP may be used for the purposes of the aforementioned eSE. Multiple service control modules may be integrated into a single bundle for installation and operation, or they may be installed and operate as independent bundles.

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

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

[0031] The “Part Number ID” is information connected to the SSP embedded in the terminal, and may be information that can be used to infer the ‘manufacturer of the primary platform installed on the SSP’ and the ‘model information of the primary platform’.

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

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

[0034] [Enable]

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

[0036] [Operating Status (Active)]

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

[0038] [Disabled]

[0039] In the present disclosure, the operation of a terminal or an external server disabling a bundle may mean changing the state of the bundle to a disabled state so that the terminal cannot receive the services provided by the bundle. An SPB in a disabled state may be referred to as a "disabled Bundle." A bundle in a disabled state may be stored in an encrypted state in storage space inside or outside the SSP.

[0040] [Deleted]

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

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

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

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

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

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

[0047] In the present disclosure, "profile image" may refer to binary data in which a profile package is installed within a UICC. The "profile image" may be named Profile TLV or Profile Image TLV. If the profile image is encrypted using encryption parameters, the "profile image" may be named Protected Profile Image (PPI) or Protected Profile Image TLV (PPI TLV). If the profile image is encrypted using encryption parameters that can be decrypted only by a specific eUICC, the "profile image" may be named Bound Profile Image (BPI) or Bound Profile Image TLV (BPI TLV). The Profile Image TLV may be a data set representing information constituting a profile in the TLV (Tag, Length, Value) format.

[0048] In the present disclosure, the "state" of the profile may be as follows.

[0049] [Enable]

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

[0051] [Disable]

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

[0053] [Delete]

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

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

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

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

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

[0059] A "Bundle Management Server" may include functions for creating a bundle, encrypting a created bundle, creating a bundle remote management command, or encrypting a created bundle remote management command at the request of a Service Provider or another Bundle Management Server. A Bundle Management Server providing the above-described functions may be represented as at least one of SPBM (Secondary Platform Bundle Manager), RBM (Remote Bundle Manager), IDS (Image Delivery Server), SM-DP (Subscription Manager Data Preparation), SM-DP+ (Subscription Manager Data Preparation plus), Manager Bundle Server, Managing SM-DP+ (Managing Subscription Manager Data Preparation plus), Bundle Encryption Server, Bundle Creation Server, Bundle Provisioner (BP), Bundle Provider, and BPC holder (Bundle Provisioning Credentials holder).

[0060] In the present disclosure, the bundle management server may perform the role of managing the configuration of keys and certificates for downloading, installing, or updating bundles from an SSP and for remotely managing the status of bundles. The bundle management server providing the above-described functions may be represented as at least one of SPBM (Secondary Platform Bundle Manager), RBM (Remote Bundle Manager), IDS (Image Delivery Server), SM-SR (Subscription Manager Secure Routing), SM-SR+ (Subscription Manager Secure Routing Plus), off-card entity of eUICC Profile Manager or PMC holder (Profile Management Credentials holder), or EM (eUICC Manager).

[0061] In the present disclosure, the activation intermediary server may receive an Event Register Request from one or more bundle management servers or activation intermediary servers. Additionally, one or more activation intermediary servers may be used in combination, in which case the first activation intermediary server may receive an Event Register Request from not only the bundle management server but also the second activation intermediary server. In the present disclosure, the functions of the activation intermediary server may be integrated into the bundle management server. An activation intermediary server providing the above-described functions may be represented as at least one of SPBM (Secondary Platform Bundle Manager), RBM (Remote Bundle Manager), SPBDS (Secondary Platform Bundle Discovery Server), BDS (Bundle Discovery Server), SM-DS (Subscription Manager Discovery Service), DS (Discovery Service), Root Activation Intermediary Server (Root SM-DS), and Alternative Activation Intermediary Server (Alternative SM-DS).

[0062] In the present disclosure, the bundle management server may refer to a server that performs both the function of generating, encrypting, and transmitting bundles or bundle remote management commands, and the function of managing SSP configurations and installed bundles. Additionally, the bundle management server may refer to a server capable of additionally performing the function of an activation brokerage server. Accordingly, in the various embodiments of the present disclosure below, the operation of the bundle management server and the activation brokerage server may be performed by a single bundle management server. Alternatively, each function may be divided and performed by multiple separate bundle management servers. Furthermore, in the specification of the present disclosure, the bundle management server or the activation brokerage server may be referred to as a bundle server. The bundle server may be one of a bundle management server or an activation brokerage server, or it may be a device that includes all the functions or configurations of both a bundle management server and an activation brokerage server.

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

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

[0065] In the present disclosure, the “profile management server” may include a function for managing profiles. The profile management server may be represented as SM-SR (Subscription Manager Secure Routing), SM-SR+ (Subscription Manager Secure Routing Plus), off-card entity of eUICC Profile Manager or PMC holder (Profile Management Credentials holder), EM (eUICC Manager), PP (Profile Manager), etc.

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

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

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

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

[0070] The term "Subscriber" may be used to refer to a Service Provider who owns the terminal or an End User who owns the terminal. Generally, a terminal owned by a Service Provider may be referred to as an M2M Device, while a terminal owned by a User may be referred to as a Consumer Device. In the case of M2M Devices, there may be End Users who do not own the terminal but use it after receiving it through transfer or lease from the Service Provider; in this instance, the Subscriber may be different from or the same as the Service Provider.

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

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

[0073] The term "terminal" may be referred to as a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, subscriber unit, subscriber station (SS), wireless device, wireless communication device, wireless transmit / receive unit (WTRU), mobile node, mobile, or other terms. Various embodiments of the terminal may include cellular telephones, smartphones with wireless communication capabilities, personal digital assistants (PDAs) with wireless communication capabilities, wireless modems, portable computers with wireless communication capabilities, imaging devices such as digital cameras with wireless communication capabilities, gaming devices with wireless communication capabilities, home appliances for music storage and playback with wireless communication capabilities, home appliances capable of wireless internet access and browsing, as well as portable units or terminals integrating combinations of such functions. Additionally, the terminal may include, but is not limited to, machine-to-machine (M2M) terminals and machine-type communication (MTC) terminals / devices. In the present disclosure, the terminal may be referred to as an electronic device.

[0074] In the present disclosure, an electronic device may have an embedded SSP capable of downloading and installing bundles. If the SSP is not embedded in the electronic device, an SSP that is physically separated from the electronic device may be inserted into the electronic device and connected to the electronic device. For example, the SSP may be inserted into the electronic device in the form of a card. The electronic device may include a terminal, and the terminal may be a terminal that includes an SSP capable of downloading and installing bundles. The SSP may not only be embedded in the terminal, but may also be inserted into the terminal when the terminal and the SSP are separated, and may be inserted into the terminal and connected to the terminal.

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

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

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

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

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

[0080] [When used in conjunction with bundles]

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

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

[0083] "Remote Bundle Management (RBM)" may be referred to as Bundle Remote Management, Remote Management, Remote Management Command, Remote Command, Remote Bundle Management Package, Bundle Remote Management Package, Remote Management Package, Remote Management Command Package, Remote Command Package, etc. An RBM may be used to install any bundle, change the status (Enabled, Disabled, Deleted) of a specific bundle, or update the contents of a specific bundle (e.g., Bundle Nickname or Bundle Metadata). An RBM may include one or more remote management commands, and the bundles targeted by each remote management command may be the same or different for each command.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0097] Referring to FIG. 1, according to one embodiment of the present disclosure, a terminal (110) may include an SSP (120). For example, the SSP (120) may be embedded in the SoC (130) of the terminal (110). In this case, the SoC (130) may be a communication processor, an application processor, or a processor that integrates both of these processors. As another example, the SSP (120) may be detachable (122) in the form of an independent chip that is not integrated into the SoC, or it may be embedded (124) that is pre-embedded in the terminal (110).

[0098] According to various embodiments, the SSP (120) included in the terminal may include at least one of one or more telecom bundles, one or more payment bundles, or one or more electronic identification bundles. For example, as shown in FIG. 1, when the SSP (120) includes a plurality of telecom bundles (140, 150), the terminal (110) may use a mobile communication network by operating the plurality of telecom bundles (140, 150) simultaneously or in time-sharing mode according to the settings. Additionally, when the SSP (120) includes a payment bundle (170) and an electronic identification bundle (180), the terminal (110) may use the payment bundle (170) to make online payments through a terminal app or offline payments through an external credit card PoS (Point of Sale) device, and may use the electronic identification bundle (180) to authenticate the identity of the terminal owner.

[0099] FIG. 2 shows a conceptual diagram of the internal structure of an SSP according to an embodiment of the present disclosure.

[0100] Referring to FIG. 2, according to one embodiment of the present disclosure, an SSP (210) may include one primary platform (PP) (220) and at least one secondary platform bundle (SPB) (230, 240) operating thereon.

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

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

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

[0104] FIG. 3 is a drawing illustrating an example of a component within a terminal used by a terminal according to an embodiment of the present disclosure to download and install a bundle as an SSP.

[0105] Referring to FIG. 3, according to one embodiment of the present disclosure, a terminal (310) may include an SSP (330) and / or an LBA (312) for controlling the SSP (330). For example, the terminal (310) may be a terminal equipped with an SSP (330) and an LBA (312) for controlling the SSP (330). For example, the SSP (330) may be built into the terminal (310) or be detachable.

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

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

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

[0109] FIG. 4 is a diagram illustrating an example of a method in which two terminals and a server interact with each other to enable online transmission of a bundle from one terminal to another terminal according to an embodiment of the present disclosure.

[0110] Referring to FIG. 4, in one embodiment of the present 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).

[0111] According to various embodiments, in operations 4020 and 4070, the first / second LBA (410, 460) may issue commands to the first / second SSP (420, 470) or transmit and receive data with the first / second SSP (420, 470). Additionally, in operations 4030 and 4080, the first / second SSP (420, 470) may generate, process, or verify necessary data within the first / second SSP (420, 470).

[0112] According to various embodiments, in the 4050 operation (hereinafter referred to as the third operation), the first and second LBAs (410, 460) are connected to each other to issue commands to one another or to transmit and receive data with the other. In the third operation, the connection of the 4050 may be a direct device-to-device connection between the first terminal (400) and the second terminal (450), or, although not illustrated, an indirect device-to-device connection in which an external entity (e.g., an external server) is connected between the first LBA (410) and the second LBA (460). A more detailed description of the method of connection between the first LBA (410) and the second LBA (460) will be explained with reference to the drawings described below.

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

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

[0115] In this drawing, an example is illustrated in which the first bundle management server (430) and the second bundle management server (480) directly transmit and receive messages; however, according to the embodiment, one or more other bundle management servers may be located between the two bundle management servers. For instance, although not illustrated in the drawing, a third bundle management server may exist between the first bundle management server and the second bundle management server, so that when the first / second bundle management server transmits a message to the second / first bundle management server, the first / second bundle management server first sends a message to the third bundle management server, and the third bundle management server transmits this message to the second / first bundle management server. In a similar manner, multiple bundle management servers and / or relay servers may exist between the first bundle management server and the second bundle management server.

[0116] In the present disclosure, for the convenience of the art, one or more bundle management servers may be collectively referred to as a single bundle management server. For example, in the drawings, the first bundle management server (430) and the second bundle management server (480) may be grouped together and referred to as a bundle management server. In this case, for example, the operation of a first terminal sending and receiving messages to and from a second terminal via the first bundle management server and the second bundle management server may be described as the operation of a first terminal sending and receiving messages to and from a second terminal via the bundle management server. Even if one or more bundle management servers exist between the first bundle management server and the second bundle management server, these bundle management servers may be collectively referred to as a bundle management server, as previously explained.

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

[0118] Referring to FIG. 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). Refer to FIG. 4 for a description of the bundle management server.

[0119] At step 5000, the first terminal (510) and the second terminal (560) may perform a preparation procedure (bundle transmission preparation procedure) necessary for bundle transmission. For a more detailed description of the bundle transmission preparation procedure, refer to the detailed description of FIG. 6 to be described later.

[0120] In step 5005, the first terminal (510) can upload the 'bundle to be transmitted to the second terminal' to the bundle management server (550). For a more detailed explanation of the procedure, refer to the detailed description of FIG. 7 which will be described later.

[0121] In step 5010, the second terminal (560) can download and install the 'bundle uploaded in step 5005' from the bundle management server (550). For a more detailed description of the procedure, refer to the detailed description of FIG. 8 to be described later.

[0122] FIG. 6 is a drawing illustrating a detailed procedure for preparing for bundle transmission among the procedures presented in FIG. 5 according to an embodiment of the present disclosure.

[0123] Referring to FIG. 6, the 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).

[0124] According to various embodiments, the first terminal (610) may have a pre-installed bundle and may have additional metadata associated with the pre-installed bundle.

[0125] According to various embodiments, the first terminal (610) may have at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), or a bundle family manager identifier (SPB Family Custodian Object ID) associated with a pre-installed bundle.

[0126] According to various embodiments, the first terminal (610) may have a 'bundle move setting' associated with a pre-installed bundle.

[0127] 'Bundle Transfer Settings' is information regarding whether a bundle can be transferred between devices and may be generated by the service provider who is the original provider of the bundle, by the bundle management server, or through collaboration between the aforementioned service provider and the bundle management server. 'Bundle Transfer Settings' may be updated by the service provider, the bundle management server, or through collaboration between the service provider and the bundle management server. Alternatively, at least one of the service provider or the bundle management server may collaborate with the terminal to update the 'Bundle Transfer Settings'. The timing and / or method of the update may be determined by the policies of the service provider, the bundle management server, the terminal manufacturer, etc.

[0128] The 'Bundle Transfer Settings' may optionally include a parameter (or indication) indicating whether the bundle is allowed to be transferred between devices. Additionally, these 'Bundle Transfer Settings' may optionally include a parameter specifying the conditions under which such transfer is permitted if it is allowed. For example, it may include a parameter indicating whether online transfer between devices is allowed for the bundle.

[0129] Referring to FIG. 6, at step 6000, the first LBA (630) can obtain information about a bundle to be transmitted between devices. Alternatively, information about a bundle to be transmitted between devices may be transmitted to the first LBA (630). For example, the first LBA (630) may obtain information about a bundle to be transmitted by receiving user input in which a user selects a bundle through a UI (user interface) provided by the first terminal (610), or information about a bundle to be transmitted may be input to the first LBA (630) through a push input from a remote server, or the first LBA (630) may connect to a remote server to read information about a bundle to be transmitted.

[0130] In step 6002, the first LBA (630) can check whether the bundle can be transferred between devices using the 'bundle transfer settings'. Additionally, the first LBA (630) can check whether the bundle can be transferred online between devices by checking the 'bundle transfer settings'.

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

[0132] Additionally, the bundle transmission code may include Supported Crypto Info for cryptographic algorithms supported by the first terminal (e.g., the first SSP). The Supported Crypto Info for cryptographic algorithms supported by the first terminal may optionally include one or more of the following: a list of elliptic curves supported by the first terminal, a list of key consensus algorithms supported by the first terminal, and a list of cryptographic algorithms supported by the first terminal.

[0133] Although the first LBA (630) is described in this drawing as checking the 'bundle transfer settings', this process may be replaced by the following process: the first LBA (630) transmits information (e.g., a bundle identifier) ​​of a bundle to be transmitted to the first SSP (620), the first SSP (620) checks the 'bundle transfer settings' of the bundle corresponding to the received bundle identifier, and the first SSP (620) transmits the result of the check to the first LBA (630).

[0134] Although the first LBA (630) is described in this drawing as generating a 'bundle transmission code', this process can be replaced by the following process: the first LBA (630) requests information required for the 'bundle transmission code' from the first SSP (620), the first SSP (620) transmits the requested information to the first LBA (630), and the first LBA (630) can construct the 'bundle transmission code' based on this information.

[0135] Referring to FIG. 6, in step 6005, the bundle transfer code generated in step 6004 can be transferred from the first LBA (630) to the second LBA (680). The bundle transfer code can be transferred in various ways.

[0136] 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 received information to the second user of the second terminal (660). The second user can input the received information into the second LBA (680) using the UI of the second terminal (6620).

[0137] Alternatively, the first LBA (630) may create information to be transmitted to the second LBA (680) in the form of an image (e.g., QR code) and display it on the screen of the first terminal (610), and the second user may transmit information to the second LBA (680) by scanning the image displayed on the screen of the first terminal (610) using the second terminal (660).

[0138] Referring to FIG. 6, in step 6010, a connection may be established (or configured) between the first LBA (630) and the second LBA (680). The first LBA (630) and the second LBA (680) may establish a connection using information included in a bundle transmission code. The connection between the first LBA (630) and the second LBA (680) may be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE D2D (device-to-device), 5G D2D) or a remote connection in which a remote server (e.g., a relay server) is located between the first LBA (630) and the second LBA (680).

[0139] In this drawing, step 6005 is depicted as being performed first and step 6010 as following, but this order may be changed. That is, a connection is first established between the first LBA (630) and the second LBA (680) (corresponding to step 6010), and through this established connection, a bundle transmission code can be transmitted from the first LBA (630) to the second LBA (680) (corresponding to step 6005).

[0140] Referring to FIG. 6, in step 6015, the second LBA (680) can transmit part and / or all information of the received bundle transmission code to the second SSP (670).

[0141] Referring to FIG. 6, in step 6020, the second SSP (670) can check the received “encryption algorithms supported by the first terminal” to see if there are any encryption algorithms supported by the second terminal (e.g., the second SSP) among them. If there are encryption algorithms supported by the second terminal among the received “encryption algorithms supported by the first terminal,” one of them can be selected and set as the ‘selected encryption algorithm.’ The ‘selected encryption algorithm’ may optionally include one or more of the following information: elliptic curve information, key consensus algorithm information, encryption algorithm information.

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

[0143] In step 6020, the second SSP (670) may generate information (collectively referred to as the Eligibility Package or ssp2.EligibilityPackage) that can be used to determine whether the first terminal (610) can receive and install the bundle that it intends to transmit from the RSP server.

[0144] The conformance package may include certificate negotiation information of the second terminal (660) to be used when the RSP server and the second terminal communicate later. The certificate negotiation information may optionally include one or more of the following information: information on certificates that can be used to verify the second SSP, information on certificates that the second SSP can use to verify the RSP server, information on key consensus algorithms supported by the second SSP, and information on encryption algorithms supported by the second SSP.

[0145] The conformance package may include information that can be used to determine whether a specific bundle can be successfully installed and / or operated on a second terminal. Such information may optionally include one or more of the following information: an SSP identifier of the second SSP, and a part number ID of the second SSP.

[0146] In step 6020, the second SSP may generate ReceiverInfo. ReceiverInfo may optionally include one or more of the following information: “Selected Crypto Info (ssp2.SelectedCryptoInfo)”, “Eligibility Package (ssp2.EligibilityPackage)”.

[0147] Referring to FIG. 6, at step 6025, the second SSP (670) can transmit ReceiverInfo to the first LBA (630) via the second LBA (680).

[0148] FIG. 7 is a diagram illustrating the procedure in which a terminal to transmit a bundle uploads the bundle to a server among the procedures presented in FIG. 5 according to an embodiment of the present disclosure.

[0149] Referring to FIG. 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). Refer to FIG. 4 for a description of the bundle management server.

[0150] Referring to FIG. 7, at step 7000, the first LBA (730) can request "SSP information (SspInfo)" from the first SSP (720).

[0151] When the first LBA (730) requests "SSP information (SspInfo)" from the first SSP (720), it may inform the first SSP (720) that a bundle transfer between devices will be performed. When the first LBA (730) requests "SSP information (SspInfo)" from the first SSP (720), it may further inform the first SSP (720) that an online bundle transfer between devices will be performed. For example, the request message may include an indicator indicating that a bundle transfer between devices will be performed. As another example, the request message may include an indicator indicating that an online bundle transfer between devices will be performed. The first SSP (720) may be informed that a bundle transfer between devices will be performed or that an online bundle transfer between devices will be performed by including an indicator or by setting the value of the indicator to 1.

[0152] The first LBA (730) may provide information about a bundle to be transmitted to the first SSP (720). This information may include at least one of a bundle family identifier (SPB Family ID) and a bundle family manager identifier (SPB Family Custodian Object ID).

[0153] Additionally, step 7000 may be performed automatically immediately following the entire process described in FIG. 6, or it may be performed after receiving external input. In this case, the 'external input' may be user input entered by the first user of the first terminal (710) through the UI provided by the first terminal (710), or it may be push input entered to the first LBA (730) from a remote server. Additionally, step 7000 may be initiated by the first LBA (730) connecting to the remote server.

[0154] Referring to FIG. 7, in step 7005, the first SSP (720) can generate its "SSP information (ssp1.SspInfo)" and transmit the "SSP information" to the bundle management server (SPBM, 750) via the first LBA (730).

[0155] "SSP information" may include information of the first SSP (720) that must be provided for bundle transmission. At this time, "SSP information" may include information for the certificate negotiation process that the first SSP (720) must undergo to communicate with the bundle management server (certificate negotiation information). "Certificate negotiation information" may include certificate information that the first SSP (720) can use to verify the bundle management server and / or certificate information that the bundle management server can use to verify the first SSP (720). Additionally, "certificate negotiation information" may further include a list of key consensus algorithms supported by the first SSP (720) and a list of encryption algorithms supported by the first SSP (720).

[0156] Additionally, "SSP information" may further include SSP version information that includes at least one version information among the version information of the standard specifications supported by the primary platform and loader included in the first SSP (720).

[0157] In one embodiment, the first SSP (720) can transmit "SSP information" to the bundle management server (750) via the first LBA (730).

[0158] According to steps 7000 through 7005, the first LBA (730) requests "SSP information" from the first SSP (720), and after the first SSP (720) generates its own "SSP information," the first SSP (720) can transmit the "SSP information" to the bundle management server (750) via the first LBA (730). However, according to the embodiment, the first LBA (730) may generate the "SSP information" itself and then transmit the "SSP information" to the bundle management server (750).

[0159] Referring to FIG. 7, in step 7010, the bundle management server (750) can check the received “SSP information”, generate “server authentication information (SPBM.Auth1)” based on this information, and transmit the “server authentication information” to the first LBA (730).

[0160] “Server authentication information” may include one or more of the following information.

[0161] a) a key consensus certificate (referred to as SPBM.Cert.KA) that can be used to verify SPBM itself, and certificates required to verify this certificate.

[0162] b) Certificate information that SPBM will use to verify the first SSP (referred to as CiPkIdToBeUsed)

[0163] c) Information on the encryption algorithm to be used when the SPBM communicates encryptedly with the first SSP (referred to as CryptoToBeUsed)

[0164] In one embodiment, the bundle management server (750) can transmit “server authentication information” to the first LBA (730).

[0165] Referring to FIG. 7, in step 7015, the first LBA (730) can transmit “server authentication information” to the first SSP (720). Additionally, the first LBA (730) can further transmit “bundle separator of the bundle to be transmitted” to the first SSP (720).

[0166] In one embodiment, the first SSP (720) may perform one or more of the following tasks.

[0167] a) The validity of the received “SPBM.Cert.KA” can be verified.

[0168] b) At least one signing certificate (ssp1.Cert.DS) capable of verifying the first SSP based on the received "CiPkIdToBeUsed" can be selected.

[0169] c) Check the received "CryptoToBeUsed" and generate a public key "ssp1.ePK.KA" and a private key "ssp1.eSK.KA", which are encryption key pairs to be used to create encryption keys for encrypted communication with the bundle management server. Additionally, the first SSP (720) can generate a session key, ShKeyM1, to be used for encrypted communication with the bundle management server (750) using the public key for key consensus included in SPBM.Cert.KA and ssp1.eSK.KA.

[0170] In step 7020, the first SSP (720) can generate “first terminal authentication information (Device1.Auth)” and transmit “first terminal authentication information (Device1.Auth)” to the first LBA (730). “First terminal authentication information (Device1.Auth)” may include one or more of the following information.

[0171] a) ssp1.Cert.DS

[0172] b) ssp1.ePK.KA

[0173] c) Transaction ID referring to the current session

[0174] d) SSP identifier of the first SSP (720)

[0175] e) Bundle separator of the bundle to be transmitted

[0176] Part or all of the “first terminal authentication information (Device1.Auth)” may be digitally signed so that they can be verified using ssp1.Cert.DS to ensure the integrity of the information, and the digital signature data may be added as part of the “first terminal authentication information”.

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

[0178] In one embodiment, the first SSP (720) can transmit "first terminal authentication information (Device1.Auth)" to the first LBA (730).

[0179] Referring to FIG. 7, in step 7025, the first LBA (730) can transmit “first terminal authentication information” to the bundle management server (750). The first LBA (730) can further transmit ssp2.EligibilityPackage to the bundle management server (750). Refer to FIG. 6 for a description of ssp2.EligibilityPackage. The first LBA (730) can further transmit “bundle separator of the bundle to be transmitted” to the bundle management server (750).

[0180] Referring to FIG. 7, in step 7030, the bundle management server (750) may perform one or more of the following processes.

[0181] a) The bundle management server can verify the validity of ssp1.Cert.DS included in the “first terminal authentication information.” Additionally, if the “first terminal authentication information” includes a digital signature, the bundle management server can use ssp1.Cert.DS to verify the validity of the signature.

[0182] b) If there is data encrypted in the “first terminal authentication information,” the bundle management server can generate ShKeyM1, which is a session key to be used for encrypted communication with the first terminal, using ssp1.ePK.KA and a secret key corresponding to the public key for key consensus included in SPBM.Cert.KA, and can decrypt the encrypted data using this session key.

[0183] c) The bundle management server may verify and / or store the received transaction ID and / or the SSP identifier of the first SSP.

[0184] d) The bundle management server can identify and / or store the bundle separator of the bundle that the first terminal intends to transmit.

[0185] In step 7030, the bundle management server may perform one or more of the following processes.

[0186] a) The bundle management server can check whether the first terminal (e.g., the first SSP) is currently the legitimate user of the bundle by using the 'SSP identifier of the first SSP' and the 'bundle separator of the bundle that the first terminal intends to transmit'.

[0187] b) The bundle management server can check whether the bundle that the first terminal intends to transmit is a bundle that can be transmitted online.

[0188] c) The bundle management server may examine ssp2.EligibilityPackage to verify at least one of the following: whether certificate negotiation with the second terminal was successful, and whether the bundle to be transmitted by the first terminal is properly installed and / or operational on the second terminal (e.g., the second SSP).

[0189] In step 7030, the bundle management server (750) generates a message (referred to as spbRequest) requesting a bundle from the first terminal (710), and the bundle management server may transmit spbRequest to the first LBA. spbRequest may include one or more of the following information.

[0190] a) SSP identifier of the first SSP

[0191] b) SSP identifier of the second SSP

[0192] c) Bundle separator of the bundle that the first terminal intends to transmit

[0193] d) Transaction ID

[0194] Some and / or all of the information contained in spbReqeust can be encrypted using ShKeyM1 and can be included as part of spbRequest.

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

[0196] In one embodiment, the bundle management server can send spbRequest to the first LBA.

[0197] Referring to FIG. 7, at step 7035, the first LBA (730) can send spbRequest to the first SSP (720). At step 7035, the first LBA (730) can further send ssp2.SelectedCryptoInfo to the first SSP (720). Refer to FIG. 6 for a description of ssp2.SelectedCryptoInfo.

[0198] In one embodiment, the first SSP (720) may perform one or more of the following processes.

[0199] a) If spbRequest contains encrypted information, decrypt using ShKeyM1

[0200] b) If spbRequest includes a digital signature value, verify using SPBM.Cert.DS

[0201] c) Verify whether the SSP identifier of the first SSP and / or the SSP identifier of the second SSP included in spbRequest, and / or the bundle separator and / or transaction ID of the bundle that the first terminal intends to transmit are valid values.

[0202] The first SSP (720) can check the information contained in ssp2.SelectedCryptoInfo.

[0203] The first SSP (720) can set a key pair for encryption, a public key "ssp1.ePK.BT" and a private key "ssp1.eSK.BT". Depending on the embodiment, these values ​​may be equal to the values ​​of "ssp1.ePK.KA" and "ssp1.esk.KA".

[0204] According to one embodiment, the first SSP (720) can generate a key ShKeyBT for encrypted communication with the bundle management server (750) using the generated ssp1.eSK.BT and a 'secret key corresponding to the public key included in SPBM.Cert.KA'.

[0205] According to one embodiment, the first SSP (720) can generate a key ShKeyBT for encrypted communication with the second terminal using the generated ssp1.eSK.BT and ssp2.ePK.BT.

[0206] The first SSP (720) may prepare a bundle that it wishes to transmit to the second terminal (760). Part and / or all of the information included in the bundle may be encrypted using ShKeyBT. The prepared bundle may be called boundSpbImage.

[0207] The first SSP (720) can delete the prepared bundle.

[0208] The first SSP (720) can generate a token (referred to as ssp1.Notification) to notify the bundle management server (750) of this information after deleting the bundle.

[0209] In step 7040, the first SSP (720) can send boundSpbImage to the bundle management server (750). The first SSP (720) can further send ssp1.ePK.BT to the bundle management server (750). The first SSP (720) can further send ssp1.Notification to the bundle management server (750).

[0210] Referring to FIG. 7, in step 7045, the bundle management server (750) verifies ssp1.Notification and can send a response message to the first LBA (730).

[0211] If boundSpbImage is encrypted with an encryption key created 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 use this encryption key to decrypt the encrypted data included in boundSpbImage.

[0212] The boundSpbImage received by the bundle management server (750) can be referred to as a 'bundle'.

[0213] The bundle management server (750) can map some or all of the following information to each other: a bundle, a bundle separator of the bundle that the first terminal intends to transmit, and an SSP identifier of the second SSP.

[0214] The bundle management server (750) can send a response message to the first LBA (730).

[0215] Referring to FIG. 7, in step 7050, the first LBA (730) may notify the second LBA (780) that a bundle request can be initiated. The first LBA (730) may transmit a message (referred to as startRequest) notifying the second LBA (780) that a bundle request can be initiated. startRequest may include an SSP identifier of the second SSP installed on the second terminal. startRequest may include a bundle identifier of the bundle to be transmitted. startRequest may include an indicator indicating that a bundle request can now be initiated. The first LBA may notify the second LBA that a bundle request can be initiated by including this indicator in startRequest or by setting a specific value in this indicator and then transmitting it to the second LBA.

[0216] FIG. 8 is a diagram illustrating a procedure in which a bundle uploaded to a server is downloaded to a terminal receiving the bundle, according to an embodiment of the present disclosure, during the procedure presented in FIG. 5.

[0217] Referring to FIG. 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). Refer to FIG. 4 for a description of the bundle management server.

[0218] Referring to FIG. 8, at step 8000, the second LBA (880) can request "SSP information (SspInfo)" from the second SSP (870).

[0219] When the second LBA (880) requests "SSP information (SspInfo)" from the second SSP (870), it may inform the second SSP that a bundle transfer between devices will be performed. When the second LBA (880) requests "SSP information (SspInfo)" from the second SSP (870), it may further inform the second SSP that an online bundle transfer between devices will be performed. For example, the request message may include an indicator indicating that a bundle transfer between devices will be performed. As another example, the request message may include an indicator indicating that an online bundle transfer between devices will be performed. The request message may inform the second SSP that a bundle transfer between devices will be performed or that an online bundle transfer between devices will be performed by including an indicator or by setting the value of the indicator to a specific value.

[0220] The second LBA (880) may provide information about the bundle to be transmitted to the second SSP (870). This information may include at least one of a bundle family identifier (SPB Family ID) and a bundle family manager identifier (SPB Family Custodian Object ID).

[0221] Referring to FIG. 8, in step 8005, the second SSP (870) can generate its "SSP information (ssp2.SspInfo)" and transmit the "SSP information" to the bundle management server (850) via the second LBA (880).

[0222] "SSP information" may include information of a second SSP that must be provided for bundle transmission. In this case, "SSP information" may include information for a certificate negotiation process (certificate negotiation information) that the second SSP (870) must undergo to communicate with the bundle management server (850). "Certificate negotiation information" may include certificate information that the second SSP (870) can use to verify the bundle management server and / or certificate information that the bundle management server (850) can use to verify the second SSP. Additionally, "certificate negotiation information" may further include a list of key consensus algorithms supported by the second SSP (870) and a list of encryption algorithms supported by the second SSP (870).

[0223] Additionally, "SSP information" may further include SSP version information that includes at least one version information among the version information of the standard specifications supported by the primary platform and loader included in the second SSP (870).

[0224] In one embodiment, the second SSP (870) can transmit "SSP information" to the bundle management server (850) via the second LBA.

[0225] According to steps 8000 through 8005, the second LBA (880) requests "SSP information" from the second SSP (870), and after the second SSP (870) generates its own "SSP information," the second SSP (870) can transmit the "SSP information" to the bundle management server (850) via the second LBA (880). However, according to an embodiment, the second LBA (880) may generate the "SSP information" itself and then transmit the "SSP information" to the bundle management server (850).

[0226] Referring to FIG. 8, in step 8010, the bundle management server (850) checks the received “SSP information”, generates “server authentication information (SPBM.Auth2)” based on this information, and can transmit the “server authentication information” to the second LBA.

[0227] “Server authentication information” may include one or more of the following information.

[0228] a) a key consensus certificate (referred to as SPBM.Cert.KA) that can be used to verify SPBM itself, and certificates required to verify this certificate.

[0229] b) Certificate information that SPBM will use to verify the second SSP (referred to as CiPkIdToBeUsed)

[0230] c) Information on the encryption algorithm to be used when the SPBM communicates encryptedly with the second SSP (referred to as CryptoToBeUsed)

[0231] In one embodiment, the bundle management server (850) can transmit “server authentication information” to the second LBA (880).

[0232] Referring to FIG. 8, in step 8015, the second LBA (880) can transmit “server authentication information” to the second SSP (870). The second LBA (880) can further transmit “bundle separators of bundles to be transmitted” to the second SSP (870).

[0233] In one embodiment, the second SSP (870) may perform one or more of the following tasks.

[0234] a) The validity of “SPBM.Cert.KA” can be verified.

[0235] b) You can select at least one signing certificate (ssp2.Cert.DS) capable of verifying the second SSP based on the received "CiPkIdToBeUsed".

[0236] c) Check the received "CryptoToBeUsed" and generate a public key "ssp2.ePK.KA" and a private key "ssp2.eSK.KA", which are a key pair for encryption to be used to create an encryption key for encrypted communication with the bundle management server. Additionally, the second SSP can generate ShKeyM2, which is a session key to be used for encrypted communication with the bundle management server, using the public key for key consensus included in SPBM.Cert.KA and ssp2.eSK.KA.

[0237] In step 8020, the second SSP (870) may generate “second terminal authentication information (Device2.Auth)” and transmit “second terminal authentication information (Device2.Auth)” to the bundle management server (850). “second terminal authentication information (Device2.Auth)” may include one or more of the following information.

[0238] a) Ssp2.Cert.DS

[0239] b) Ssp2.ePK.KA

[0240] c) Transaction ID referring to the current session

[0241] d) SSP identifier of the second SSP (720)

[0242] e) Bundle separator of the bundle to be received

[0243] Part or all of the “Device2.Auth” may be digitally signed so that they can be verified using ssp2.Cert.DS to ensure the integrity of the information, and the digitally signed data may be added as part of the “Device2.Auth”.

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

[0245] In one embodiment, the second SSP (870) can transmit "second terminal authentication information (Device2.Auth)" to the bundle management server (850) via the second LBA (880).

[0246] In one embodiment, the bundle management server (850) may perform one or more of the following processes.

[0247] a) The bundle management server can verify the validity of ssp2.Cert.DS included in the “second terminal authentication information.” Additionally, if the “second terminal authentication information” includes a digital signature, the bundle management server can use ssp2.Cert.DS to verify the validity of the signature.

[0248] b) If there is data encrypted in the “second terminal authentication information,” the bundle management server can generate ShKeyM2, which is a session key to be used for encrypted communication with the second terminal, using ssp2.ePK.KA and a secret key corresponding to the public key for key consensus included in SPBM.Cert.KA, and can decrypt the encrypted data using this session key.

[0249] c) The bundle management server may verify and / or store the received transaction ID and / or the SSP identifier of the second SSP.

[0250] d) The bundle management server can identify and / or store the bundle separator of the bundle that the second terminal wishes to receive.

[0251] In one embodiment, the bundle management server (850) may further perform one or more of the following processes.

[0252] a) The bundle management server can check whether there is a bundle to be transmitted to the second terminal using the SSP identifier of the second SSP.

[0253] b) The bundle management server can check whether there is a bundle to be transmitted to the second terminal using the bundle separator of the bundle that the second terminal wants to receive.

[0254] c) If the bundle management server has a bundle to be transmitted to the second terminal, it may prepare this bundle. (The prepared bundle is referred to as boundSpbImage)

[0255] For example, in FIG. 7, if there is a bundle among the bundles uploaded from the first terminal that is mapped to the 'SSP identifier of the second SSP and / or the bundle separator of the bundle that the second terminal wants to receive,' this bundle can be selected.

[0256] At this point, if the selected bundle does not need to be re-encrypted, the bundle management server can prepare this bundle for transmission.

[0257] Alternatively, if the selected bundle needs to be encrypted with a cryptographic key between the bundle management server and the second terminal, the bundle management server may use ShKeyM2 to encrypt part and / or all of the bundle and then prepare the bundle for transmission.

[0258] Alternatively, if the selected bundle needs to be encrypted with a cryptographic key between the bundle management server and the second terminal, the bundle management server may generate a key pair, a public key "SPBM.ePK.BT" and a private key "SPBM.eSK.BT", generate an encryption key ShKeyBT using SPBM.eSK.BT and ssp2.ePK.KA, and then use this key to encrypt part and / or all of the bundle and prepare the bundle for transmission.

[0259] In step 8025, the bundle management server (850) can send boundSpbImage to the second LBA (880). The bundle management server (850) can further send SPBM.ePK.BT to the second LBA (880). The bundle management server (850) can further send ssp1.ePK.BT to the second LBA (880).

[0260] Referring to Fig. 8, a bundle can be installed in the second SSP at step 8030.

[0261] In one embodiment, if the bundle is encrypted with an encryption key between the bundle management server (850) and the second terminal (860), the second SSP (870) can decrypt the encrypted information using SHkeyM2.

[0262] In another embodiment, when the bundle is encrypted with an encryption key 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 use this key to decrypt the encrypted information.

[0263] In another embodiment, when the bundle is encrypted with an encryption key between the first terminal and the second terminal, the second SSP (870) can generate an encryption key ShKeyBT using ssp1.ePK.BT and then use this key to decrypt the encrypted information.

[0264] Referring to FIG. 8, in step 8035, the second SSP (870) can notify the bundle management server (850) of the bundle installation result. For example, the second SSP (870) can send a message (referred to as ssp2.Notification) containing the bundle installation result to the bundle management server (850).

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

[0266] Referring to FIG. 9, the terminal may include at least one LBA and at least one SSP. For example, as shown in FIG. 4, the first terminal (910) may include a first LBA (930) and a first SSP (920), and the second terminal (960) may include a second LBA (980) and a second SSP (970). Refer to FIG. 4 for a description of the bundle management server.

[0267] At step 9000, the first terminal (910) and the second terminal (960) may perform a preparation procedure (bundle transmission preparation procedure) necessary for bundle transmission. For a more detailed description of the bundle transmission preparation procedure, refer to the detailed description of FIG. 10 to be described later.

[0268] In step 9005, the second terminal (960) may receive bundle transfer approval from the bundle management server (950). For a more detailed description of the procedure, refer to the detailed description of FIG. 11 to be described later.

[0269] In step 9010, the first terminal (910) can upload the 'bundle to be transmitted to the second terminal' to the bundle management server (950). For a more detailed description of the procedure, refer to the detailed description of FIG. 12 which will be described later.

[0270] In step 9015, the second terminal (960) can download and install the 'bundle uploaded in step 9010' from the bundle management server (950). For a more detailed description of the procedure, refer to the detailed description of FIG. 13 to be described later.

[0271] FIG. 10 is a drawing illustrating a detailed procedure for preparing for bundle transmission among the procedures presented in FIG. 9 according to an embodiment of the present disclosure.

[0272] Referring to FIG. 10, the 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).

[0273] According to various embodiments, the first terminal (1010) may possess a pre-installed bundle and may further possess metadata associated with the pre-installed bundle. According to various embodiments, the first terminal (1010) may possess at least one of a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), or a bundle family manager identifier (SPB Family Custodian Object ID) associated with the pre-installed bundle.

[0274] According to various embodiments, the first terminal (1010) may have a 'bundle transfer setting' related to a pre-installed bundle. For a description of the 'bundle transfer setting', refer to the description in FIG. 6.

[0275] Referring to FIG. 10, at step 10000, the first LBA (1030) can obtain information about a bundle to be transmitted between devices. Alternatively, information about a bundle to be transmitted between devices may be transmitted to the first LBA. For example, the first LBA may obtain information about a bundle to be transmitted by receiving user input in which a user selects a bundle through a UI provided by the first terminal (1010), or information about a bundle to be transmitted may be input to the first LBA through a push input from a remote server, or the first LBA may connect to a remote server to read information about a bundle to be transmitted.

[0276] In step 10002, the first LBA (1030) can check whether the bundle can be transferred between devices using the 'bundle transfer settings'. Additionally, the first LBA (1030) can check whether the bundle can be transferred online between devices by checking the 'bundle transfer settings'.

[0277] In step 10004, the first LBA (1030) may generate a 'bundle transfer code'. The bundle transfer code may include bundle identifiers such as the bundle identifier (SPB ID), bundle family identifier (SPB Family ID), and bundle family manager identifier (SPB Family Custodian Object ID) of the bundle to be transferred. Additionally, the bundle transfer information may include other information indicating the attributes of the bundle (e.g., the bundle's metadata or part of the metadata). Additionally, the bundle transfer information may include the address (SPBM Addr) of the bundle management server associated with the bundle to be transferred.

[0278] Additionally, the bundle transmission code may include Supported Crypto Info for encryption algorithms supported by the first terminal (e.g., the first SSP). The Supported Crypto Info for encryption algorithms supported by the first terminal may optionally include one or more of the following information: a list of elliptic curves supported by the first terminal, a list of key consensus algorithms supported by the first terminal, and a list of encryption algorithms supported by the first terminal.

[0279] Referring to FIG. 10, in step 10005, the bundle transfer code generated in step 10000 can be transferred from the first LBA (1030) to the second LBA (1080). The bundle transfer code can be transferred in various ways.

[0280] 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 through the UI of the first terminal. The first user can provide the received information to the second user of the second terminal. The second user can input the received information into the second LBA using the UI of the second terminal.

[0281] Alternatively, the first LBA (1030) may create information to be transmitted to the second LBA (1080) in the form of an image (e.g., a QR code) and display it on the screen of the first terminal, and the second user may transmit the information to the second LBA by scanning the image displayed on the screen of the first terminal using the second terminal.

[0282] Alternatively, the first LBA (1030) may establish a connection between the first LBA (1030) and the second LBA (1080) and use this established connection to transmit information to be transmitted. In this case, the connection established between the first LBA (1030) and the second LBA (1080) may be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE D2D (device-to-device), 5G D2D) or a remote connection in which a remote server (e.g., a relay server) is located between the first LBA (1030) and the second LBA (1080).

[0283] FIG. 11 is a diagram illustrating a procedure in which a terminal that has received a bundle communicates with a server to receive approval among the procedures presented in FIG. 9 according to an embodiment of the present disclosure.

[0284] Referring to FIG. 11, the 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). Refer to FIG. 4 for a description of the bundle management server (1150).

[0285] Referring to FIG. 11, at step 11000, the second LBA (1180) can request "SSP information (SspInfo)" from the second SSP (1170).

[0286] When the second LBA (1180) requests "SSP information (SspInfo)" from the second SSP (1170), it may inform the second SSP that a bundle transfer between devices will be performed. When the second LBA (1180) requests "SSP information (SspInfo)" from the second SSP (1170), it may further inform the second SSP that an online bundle transfer between devices will be performed. For example, the request message may include an indicator indicating that a bundle transfer between devices will be performed. As another example, the request message may include an indicator indicating that an online bundle transfer between devices will be performed. The request message may inform the second SSP that a bundle transfer between devices will be performed or that an online bundle transfer between devices will be performed by including the indicator or by setting the value of the indicator to a specific value.

[0287] The second LBA (1180) may provide information about a bundle to be transmitted to the second SSP (1170). This information may include at least one of a bundle family identifier (SPB Family ID) and a bundle family manager identifier (SPB Family Custodian Object ID).

[0288] Referring to FIG. 11, in step 11005, the second SSP can generate its "SSP information (ssp2.SspInfo)" and transmit the "SSP information" to the bundle management server (1150) via the second LBA (1180).

[0289] "SSP information" may include information of a second SSP that must be provided for bundle transmission. In this case, "SSP information" may include information for a certificate negotiation process (certificate negotiation information) that the second SSP (1170) must undergo to communicate with the bundle management server (1150). "Certificate negotiation information" may include certificate information that the second SSP (1170) can use to verify the bundle management server (1150) and / or certificate information that the bundle management server (1150) can use to verify the second SSP (1170). Additionally, "certificate negotiation information" may further include a list of key consensus algorithms supported by the second SSP and a list of encryption algorithms supported by the second SSP.

[0290] In addition, "SSP information" may further include SSP version information including at least one version information among the version information of the standard specifications supported by the primary platform and loader included in the second SSP.

[0291] In one embodiment, the second SSP (1170) can transmit "SSP information" to the bundle management server (1150) via the second LBA (1180).

[0292] According to steps 11000 through 11005, the second LBA may request "SSP information" from the second SSP, and after the second SSP generates its own "SSP information," the second SSP may transmit the "SSP information" to the bundle management server via the second LBA. However, according to an embodiment, the second LBA may generate the "SSP information" itself and then transmit the "SSP information" to the bundle management server.

[0293] Referring to FIG. 11, in step 11010, the bundle management server (1150) checks the received "SSP information" and, based on this information, generates "server authentication information (SPBM.Auth2)" and can transmit the generated "server authentication information" to the second LBA.

[0294] “Server authentication information” may include one or more of the following information.

[0295] a) a key consensus certificate (referred to as SPBM.Cert.KA) that can be used to verify SPBM itself, and certificates required to verify this certificate.

[0296] b) Certificate information that SPBM will use to verify the second SSP (referred to as CiPkIdToBeUsed)

[0297] c) Information on the encryption algorithm to be used when the SPBM communicates encryptedly with the second SSP (referred to as CryptoToBeUsed)

[0298] In one embodiment, the bundle management server (1150) can transmit “server authentication information” to the second LBA (1180).

[0299] Referring to FIG. 11, in step 11015, the second LBA (1180) may transmit “server authentication information” to the second SSP (1170). The second LBA (1180) may further transmit “bundle separator of the bundle to be transmitted” to the second SSP (1170). The second LBA (1180) may further transmit Supported Crypto Info to the second SSP (1170). For an explanation regarding Supported Crypto Info, refer to FIG. 10.

[0300] Referring to FIG. 11, in step 11020, the second SSP (1170) may perform one or more of the following tasks.

[0301] a) The validity of “SPBM.Cert.KA” can be verified.

[0302] b) You can select at least one signing certificate (ssp2.Cert.DS) capable of verifying the second SSP based on the received "CiPkIdToBeUsed".

[0303] c) Check the received "CryptoToBeUsed" and generate a public key "ssp2.ePK.KA" and a private key "ssp2.eSK.KA", which are a key pair for encryption to be used to create an encryption key for encrypted communication with the bundle management server. Additionally, the second SSP can generate ShKeyM2, which is a session key to be used for encrypted communication with the bundle management server, using the public key for key consensus included in SPBM.Cert.KA and ssp2.eSK.KA.

[0304] In one embodiment, the second SSP (1170) may generate “second terminal authentication information (Device2.Auth)”. The “second terminal authentication information (Device2.Auth)” may include one or more of the following information.

[0305] a) Ssp2.Cert.DS

[0306] b) Ssp2.ePK.KA

[0307] c) Transaction ID referring to the current session

[0308] d) SSP identifier of the second SSP

[0309] e) Part number ID of the 2nd SSP

[0310] f) Bundle separator of the bundle to be received

[0311] In one embodiment, the second SSP (1170) can check the received supported Crypto Info to determine if there are encryption algorithms supported by the second terminal (e.g., the second SSP) among them. If there are encryption algorithms supported by the second terminal among the received supported Crypto Info, the second SSP (1170) can select one of them and set it as the 'selected encryption algorithm'. The 'selected encryption algorithm' may optionally include one or more of the following information: elliptic curve information, key consensus algorithm information, encryption algorithm information.

[0312] The second SSP (1170) can generate a key pair for the second terminal (temporary public key ssp2.ePK.BT and its corresponding private key ssp2.eSK.BT) to be used to generate an encryption key for encrypted communication with the first terminal later, based on the 'selected encryption algorithm'. The second SSP (1170) can map the generated key pair to the received bundle identifier (SPB ID). The second SSP (1170) can generate “selected encryption information (ssp2.SelectedCryptoInfo)”. The “selected encryption information” may optionally include one or more of the following information: part and / or all of the selected encryption algorithm, ssp2.eEPK.BT

[0313] Part or all of the “Device2.Auth” and / or “SelectedCryptoInfo” may be digitally signed so that they can be verified using ssp2.Cert.DS to ensure the integrity of the information, and the digitally signed data may be added as part of the “Device2.Auth”.

[0314] Additionally, part or all of the “second terminal authentication information (Device2.Auth)” and / or “selected encryption information (ssp2.SelectedCryptoInfo)” may be encrypted using the previously generated session key ShKeyM2.

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

[0316] Referring to FIG. 11, at step 11025, the bundle management server (1150) may perform one or more of the following processes.

[0317] a) The bundle management server can verify the validity of ssp2.Cert.DS included in the “second terminal authentication information.” Additionally, if the “second terminal authentication information” includes a digital signature, the bundle management server can use ssp2.Cert.DS to verify the validity of the signature.

[0318] b) If there is data encrypted in the “second terminal authentication information,” the bundle management server can generate ShKeyM2, which is a session key to be used for encrypted communication with the second terminal, using ssp2.ePK.KA and a secret key corresponding to the public key for key consensus included in SPBM.Cert.KA, and can decrypt the encrypted data using this session key.

[0319] c) The bundle management server may verify and / or store the received transaction ID and / or the SSP identifier of the second SSP.

[0320] d) The bundle management server can identify and / or store the bundle separator of the bundle that the second terminal wishes to receive.

[0321] In one embodiment, the bundle management server (1150) may further perform one or more of the following processes.

[0322] a) The bundle management server can check whether the bundle is capable of online transmission by verifying the bundle separator of the bundle that the second terminal intends to receive. For example, the process of checking whether the bundle is capable of online transmission can be performed by the bundle management server (1150) using the 'bundle transfer setting' value of the bundle to perform verification.

[0323] b) The bundle management server can verify whether the bundle that the second terminal intends to receive is properly installed and / or operated on the second terminal (e.g., the second SSP). For example, this verification process may be performed using the part number ID of the second terminal (e.g., the second SSP) and / or the bundle identifier of the bundle that the second terminal intends to receive.

[0324] In one embodiment, the bundle management server (1150) may map some or all of the following information to each other: the SSP identifier of the second SSP, the bundle separator of the bundle to be received, and “selected cryptographic information (ssp2.SelectedCryptoInfo)”

[0325] In step 11025, the bundle management server (1150) may send a response message to the second LBA (1180) indicating that all processes have been completed. The process of sending a response message indicating that all processes have been completed may be omitted.

[0326] FIG. 12 is a diagram illustrating the procedure in which a terminal to transmit a bundle uploads the bundle to a server among the procedures presented in FIG. 9 according to an embodiment of the present disclosure.

[0327] Referring to FIG. 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). Refer to FIG. 4 for a description of the bundle management server (1250).

[0328] Referring to FIG. 12, at step 12000, the first LBA (1230) can request "SSP information (SspInfo)" from the first SSP (1220).

[0329] When the first LBA requests "SSP information (SspInfo)" from the first SSP, it may inform the first SSP that a bundle move between devices will be performed. When the first LBA requests "SSP information (SspInfo)" from the first SSP, it may further inform the first SSP that an online bundle move between devices will be performed. For example, the request message may include an indicator indicating that a bundle move between devices will be performed. As another example, the request message may include an indicator indicating that an online bundle move between devices will be performed. The request message may inform the first SSP that a bundle move between devices will be performed or that an online bundle move between devices will be performed by including the indicator or by setting the value of the indicator to 1.

[0330] The first LBA may provide information about a bundle to be transmitted to the first SSP. This information may include at least one of a bundle family identifier (SPB Family ID) and a bundle family manager identifier (SPB Family Custodian Object ID).

[0331] Referring to FIG. 12, in step 12005, the first SSP (1220) can generate its "SSP information (ssp1.SspInfo)" and transmit the "SSP information" to the bundle management server (1250) via the first LBA (1230).

[0332] "SSP information" may include information of the first SSP that must be provided for bundle transmission. In this case, "SSP information" may include information for the certificate negotiation process that the first SSP must undergo 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. Additionally, "certificate negotiation information" may further include a list of key consensus algorithms supported by the first SSP and a list of encryption algorithms supported by the first SSP.

[0333] In addition, "SSP information" may further include SSP version information including at least one version information among the version information of the standard specifications supported by the primary platform and loader included in the first SSP.

[0334] In one embodiment, the first SSP (1220) can transmit "SSP information" to the bundle management server (1250) via the first LBA (1230).

[0335] According to steps 12000 through 12005, the first LBA may request "SSP information" from the first SSP, and after the first SSP generates its own "SSP information," the first SSP may transmit the "SSP information" to the bundle management server via the first LBA. However, according to an embodiment, the first LBA may generate the "SSP information" itself and then transmit the "SSP information" to the bundle management server.

[0336] Referring to FIG. 12, in step 12010, the bundle management server (1250) checks the received “SSP information”, generates “server authentication information (SPBM.Auth1)” based on this information, and can transmit the “server authentication information” to the first LBA (1230).

[0337] “Server authentication information” may include one or more of the following information.

[0338] a) a key consensus certificate (referred to as SPBM.Cert.KA) that can be used to verify SPBM itself, and certificates required to verify this certificate.

[0339] b) Certificate information that SPBM will use to verify the first SSP (referred to as CiPkIdToBeUsed)

[0340] c) Information on the encryption algorithm to be used when the SPBM communicates encryptedly with the first SSP (referred to as CryptoToBeUsed)

[0341] In one embodiment, the bundle management server (1250) can transmit “server authentication information” to the first LBA (1230).

[0342] Referring to FIG. 12, in step 12015, the first LBA (1230) can transmit “server authentication information” to the first SSP (1220). The first LBA (1230) can further transmit “bundle separators of bundles to be transmitted” to the first SSP (1220).

[0343] Referring to FIG. 12, in step 12020, the first SSP (1220) may perform one or more of the following tasks.

[0344] a) The validity of the received “SPBM.Cert.KA” can be verified.

[0345] b) At least one signing certificate (ssp1.Cert.DS) capable of verifying the first SSP based on the received "CiPkIdToBeUsed" can be selected.

[0346] c) Check the received "CryptoToBeUsed" and generate a public key "ssp1.ePK.KA" and a private key "ssp1.eSK.KA", which are a key pair for encryption to be used to create an encryption key for encrypted communication with the bundle management server. Additionally, the first SSP can generate ShKeyM1, which is a session key to be used for encrypted communication with the bundle management server, using the public key for key consensus included in SPBM.Cert.KA and ssp1.eSK.KA.

[0347] In step 12020, the first SSP (1220) may generate “first terminal authentication information (Device1.Auth)” and transmit “first terminal authentication information (Device1.Auth)” to the bundle management server (1250). “First terminal authentication information (Device1.Auth)” may include one or more of the following information.

[0348] a) ssp1.Cert.DS

[0349] b) ssp1.ePK.KA

[0350] c) Transaction ID referring to the current session

[0351] d) SSP identifier of the first SSP

[0352] e) Bundle separator of the bundle to be transmitted

[0353] Part or all of the “first device authentication information (Device1.Auth)” may be digitally signed so that it can be verified using ssp1.Cert.DS to ensure the integrity of the information, and the digitally signed data may be added as part of the “first device authentication information”.

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

[0355] In one embodiment, the first SSP (1220) can transmit "first terminal authentication information (Device1.Auth)" to the bundle management server (1250) via the first LBA (1230).

[0356] Referring to FIG. 12, at step 12025, the bundle management server (1250) may perform one or more of the following processes. (Hereinafter, this series of processes will be referred to as Process A.)

[0357] a) The bundle management server can verify the validity of ssp1.Cert.DS included in the “first terminal authentication information.” Additionally, if the “first terminal authentication information” includes a digital signature, the bundle management server can use ssp1.Cert.DS to verify the validity of the signature.

[0358] b) If there is data encrypted in the “first terminal authentication information,” the bundle management server can generate ShKeyM1, which is a session key to be used for encrypted communication with the first terminal, using ssp1.ePK.KA and a secret key corresponding to the public key for key consensus included in SPBM.Cert.KA, and can decrypt the encrypted data using this session key.

[0359] c) The bundle management server may verify and / or store the received transaction ID and / or the SSP identifier of the first SSP.

[0360] d) The bundle management server can identify and / or store the bundle separator of the bundle that the first terminal intends to transmit.

[0361] In one embodiment, the bundle management server (1250) may further perform one or more of the following processes. (Hereafter, this series of processes will be referred to as Process B.)

[0362] a) The bundle management server can check whether the first terminal (e.g., the first SSP) is currently the legitimate user of the bundle by using the 'SSP identifier of the first SSP' and the 'bundle separator of the bundle that the first terminal intends to transmit'.

[0363] b) The bundle management server can check whether the 'bundle that the first terminal intends to transmit' is a bundle for which bundle transmission has already been requested and approved. For example, the bundle management server can check whether the bundle separator of the 'bundle that the first terminal intends to transmit' is a bundle separator stored through step 11025 of FIG. 11.

[0364] Between process A and process B presented above, the bundle management server (1250) may wait for the operation presented in FIG. 11 to be completed. That is, process A may be performed regardless of whether the operation presented in FIG. 11 is completed, but process B may need to be executed after the operation presented in FIG. 11 is completed, in which case the bundle management server may wait for the operation presented in FIG. 11 to be completed before performing process B. This waiting process may be implemented in various ways described below. However, the waiting process is not limited to the various ways described below, and furthermore, the waiting process does not necessarily have to be one of the methods described below.

[0365] a) The bundle management server may send a message to the first LBA indicating that it has received the requested operation but must wait for a response. After waiting for a certain period of time, the first LBA may send a message to the bundle management server to check whether the requested operation has been completed. If the operation has been completed, process B may be performed. If the operation has not been completed, the bundle management server may send a message to the first LBA indicating that it must wait a little longer. The above process may be repeated until the operation presented in FIG. 11 is completed by the bundle management server.

[0366] b) The bundle management server may wait within a set time range between process A and process B. That is, if the operation presented in FIG. 11 is completed within a set time after process A is performed, process B can be performed. If the operation presented in FIG. 11 is not completed within a set time after process A is performed, the bundle transmission process may be stopped.

[0367] c) After performing process A, the bundle management server may notify the first LBA that it has received the requested operation. Then, after the operation shown in FIG. 11 is completed, process B may be performed.

[0368] In step 12025, the bundle management server (1250) generates a message requesting a bundle (spbRequest; this term may also be referred to as transferOption) to the first terminal and can send the message requesting a bundle (spbRequest) to the first SSP (1220). The bundle management server (1250) can further send ssp2.SelectedCryptoInfo to the first SSP (1220).

[0369] spbRequest may include one or more of the following information.

[0370] a) SSP identifier of the first SSP

[0371] b) SSP identifier of the second SSP

[0372] c) Bundle separator of the bundle that the first terminal intends to transmit

[0373] d) Transaction ID

[0374] Some and / or all of the information contained in spbReqeust can be encrypted using ShKeyM1 and can be included as part of spbRequest.

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

[0376] In one embodiment, the bundle management server (1250) can send spbRequest to the first SSP (1220) via the first LBA (1230).

[0377] In one embodiment, the bundle management server (1250) may further transmit ssp2.SelectedCryptoInfo to the first SSP (1220) via the first LBA (1230). Refer to FIG. 6 for a description of ssp2.SelectedCryptoInfo.

[0378] Referring to FIG. 12, at step 12030, the first SSP (1220) may perform one or more of the following processes.

[0379] a) If spbRequest contains encrypted information, decrypt using ShKeyM1

[0380] b) If spbRequest includes an electronic signature value, validate SPBM.Cert.DS, and then validate the electronic signature value using SPBM.Cert.DS.

[0381] c) Verify whether the SSP identifier of the first SSP and / or the SSP identifier of the second SSP included in spbRequest, and / or the bundle separator and / or transaction ID of the bundle that the first terminal intends to transmit are valid values.

[0382] The first SSP (1220) can check the information contained in ssp2.SelectedCryptoInfo.

[0383] The first SSP (1220) can set a key pair for encryption, a public key "ssp1.ePK.BT" and a private key "ssp1.eSK.BT". Depending on the embodiment, these values ​​may be equal to the values ​​of "ssp1.ePK.KA" and "ssp1.eSK.KA".

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

[0385] According to one embodiment, the first SSP (1220) can create a key ShKeyBT for encrypted communication with the second terminal using the prepared ssp1.eSK.BT and ssp2.ePK.BT.

[0386] The first SSP (1220) may prepare and / or create a bundle to be transmitted to the second terminal. Part and / or all of the information contained in the bundle may be encrypted using ShKeyBT. The prepared bundle may be called boundSpbImage.

[0387] The first SSP (1220) may extract and / or prepare some of the contents of a 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) some and / or all of the updates made after the bundle installation). In this case, some and / or all of the information may be encrypted using ShKeyBT. This prepared data may be collectively referred to as boundSpbImageData or boundSpbImage for convenience.

[0388] The first SSP (1220) can delete the bundle that it wants to transmit to the second terminal.

[0389] The first SSP (1220) can generate a token (referred to as ssp1.Notification) to notify the bundle management server (1250) of this information after deleting the bundle.

[0390] In step 12030, the first SSP (1220) may send boundSpbImage or boundSpbImageData to the bundle management server (1250). The first SSP (1220) may further send ssp1.ePK.BT to the bundle management server (1250). The first SSP (1220) may further send ssp1.Notification to the bundle management server (1250).

[0391] Referring to FIG. 12, at step 12035, the bundle management server (1250) verifies ssp1.Notification and can send a response message to the first LBA (1230) indicating that all processes have been performed.

[0392] If boundSpbImage or boundSpbImageData is encrypted with an encryption key created using ssp1.eSK.BT and 'the public key included in SPBM.Cert.KA', the bundle management server (1250) 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 use this encryption key to decrypt the encrypted data included in boundSpbImage or boundSpbImageData.

[0393] In summary, one of the following scenarios can be executed by the bundle management server.

[0394] [CASE A]

[0395] If the bundle management server receives an SpbImage encrypted with ShKeyBT created using ssp1.eSK.BT and the 'public key contained in SPBM.Cert.KA'

[0396] The result generated after the bundle management server performs decryption using ShKeyBT can be referred to as the 'decrypted bundle'.

[0397] [CASE B]

[0398] If the bundle management server receives SpbImageData encrypted with ShKeyBT created using ssp1.eSK.BT and the 'public key included in SPBM.Cert.KA'

[0399] The result generated after the bundle management server performs decryption using ShKeyBT can be referred to as 'decrypted bundle data'.

[0400] [CASE C]

[0401] If the bundle management server receives an SpbImage encrypted with ShKeyBT created using ssp1.eSK.BT and ssp2.ePK.BT

[0402] The bundle management server stores the received results, and the stored results can be referred to as 'received bundles'.

[0403] [CASE D]

[0404] If the bundle management server receives SpbImageData encrypted with ShKeyBT created using ssp1.eSK.BT and ssp2.ePK.BT

[0405] After the bundle management server stores the received results, the stored results may be referred to as 'received bundle data'.

[0406] The bundle management server (1250) may map some or all of the following information to each other: the SSP identifier of the second SSP, the bundle separator of the bundle that the second SSP wants to receive, the 'decrypted bundle', 'decrypted bundle data', 'received bundle', 'received bundle data', etc. described above.

[0407] In one embodiment, the bundle management server (1250) can send a response message to the first LBA (1230) indicating that all processes have been performed.

[0408] FIG. 13 is a diagram illustrating a procedure in which a bundle uploaded to a server is downloaded to a terminal receiving the bundle, according to an embodiment of the present disclosure, during the procedure presented in FIG. 9.

[0409] Referring to FIG. 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). Refer to FIG. 4 for a description of the bundle management server (1350).

[0410] Referring to FIG. 13, at step 13000, the second LBA (1380) may request the bundle management server (1350) to receive the bundle it wishes to receive. This request may be made in various ways. For example, the second LBA (1380) may transmit “Device2.Auth” to the bundle management server (1350). Refer to FIG. 11 for a description of “Device2.Auth”.

[0411] Step 13000 can be replaced with the following process. That is, the second terminal (1360) may wait for Step 13005, described later, to be performed after performing Step 11020 presented in FIG. 11. This waiting process can be implemented in various ways described below. However, the waiting process is not limited to this, and the waiting method does not necessarily have to be one of the methods described below.

[0412] a) The bundle management server (1350) may send a message to the second LBA (1380) stating that it has received the requested operation but must wait for a response. The second LBA (1380) may wait for a certain period of time and then send a message to the bundle management server (1350) to check whether the requested operation has been completed. If the operation has been completed, step 13005 may be performed. If the operation has not been completed, the bundle management server (1350) may send a message to the second LBA (1380) stating that it must wait a little longer. In this case, the second LBA (1380) may wait for a certain period of time again and then send a message to the bundle management server (1350) again to check whether the requested operation has been completed. The above process may be repeated until step 13005 is performed.

[0413] b) The second LBA (1380) may wait for step 13005 to be performed within a set time range. If step 13005 is not performed within the set time, the bundle transfer process may be interrupted.

[0414] c) The bundle management server (1350) may notify the second LBA (1380) that it has received the requested action. Then, when preparation is complete, step 13005 may be performed.

[0415] Referring to FIG. 13, in step 13005, the bundle management server (1350) may perform one or more of the following processes.

[0416] The following process can be performed when the bundle management server (1350) receives a bundle request message from the second LBA (1380) at step 13000.

[0417] a) The bundle management server can verify whether the received “second terminal authentication information” is the same information as the “second terminal authentication information” received in step 11020 of FIG. 11. Alternatively, the bundle management server can verify which terminal is currently requesting the bundle through the received “second terminal authentication information”.

[0418] b) The bundle management server can check whether there is a bundle to be transmitted to the second terminal using the SSP identifier of the second SSP.

[0419] c) The bundle management server can check whether there is a bundle to be transmitted to the second terminal using the bundle separator of the bundle that the second terminal wants to receive.

[0420] In step 13005, the bundle management server (1350) can prepare a bundle to be transmitted to the second terminal (1360). That is, the bundle prepared in FIG. 12

[0421] - Decrypted bundle

[0422] - Decrypted bundle data

[0423] - Received bundle

[0424] - Received bundle data

[0425] If there is one that is mapped to the 'SSP identifier of the second SSP and / or the bundle separator of the bundle that the second terminal wishes to receive,' a bundle to be transmitted to the second terminal can be prepared. This bundle can be prepared by one of the methods described below.

[0426] [CASE A]

[0427] If the bundle management server has a bundle decrypted as a result of the process presented in FIG. 12, it can use this bundle to prepare a bundle to be transmitted to a second terminal. In one embodiment, the bundle management server can use ShKeyM2 to encrypt part and / or all of the bundle and then prepare the bundle for transmission. In another embodiment, the bundle management server can generate a key pair, a public key "SPBM.ePK.BT" and a private key "SPBM.eSK.BT", generate an encryption key ShKeyBT using SPBM.eSK.BT and ssp2.ePK.KA, and then use this key to encrypt part and / or all of the bundle and then prepare the bundle.

[0428] [CASE B]

[0429] If the bundle management server has decrypted bundle data as a result of the process presented in FIG. 12, it may use this data to prepare a bundle to be transmitted to a second terminal. In one embodiment, the bundle management server may prepare a bundle that includes the decrypted bundle data as part of it. In another embodiment, after preparing a bundle to be transmitted to the second terminal, the bundle management server may include the decrypted bundle data as additional data. In one embodiment, the bundle management server may use ShKeyM2 to encrypt part and / or all of the prepared bundle and / or additional data. In yet another embodiment, the bundle management server may generate a key pair, namely the public key "SPBM.ePK.BT" and the private key "SPBM.eSK.BT", generate an encryption key ShKeyBT using SPBM.eSK.BT and ssp2.ePK.KA, and then use the encryption key ShKeyBT to encrypt part and / or all of the prepared bundle and / or additional data.

[0430] [CASE C]

[0431] If the bundle management server has a bundle received as a result of the process presented in FIG. 12, the received bundle can be prepared as a bundle to be transmitted to the second terminal.

[0432] [CASE D]

[0433] If the bundle management server has bundle data received as a result of the process presented in FIG. 12, it may prepare a bundle to be transmitted to a second terminal using the received bundle data. In one embodiment, the bundle management server may generate a bundle to be transmitted to the second terminal and include the received bundle data as additional data. In one embodiment, part and / or all of the bundle generated by the bundle management server may be encrypted using ShKeyM2. In another embodiment, part and / or all of the bundle generated by the bundle management server may be encrypted using an encryption key ShKeyBT generated using the key pair "SPBM.ePK.BT" and "SPBM.eSK.BT" generated by the bundle management server.

[0434] The prepared bundle and additional data mentioned in [CASE A] to [CASE D] above may be referred to as boundSpbImage.

[0435] In step 13005, the bundle management server (1350) can send boundSpbImage to the second LBA (1380). The bundle management server (1350) can further send SPBM.ePK.BT to the second LBA (1380). The bundle management server (1350) can further send ssp1.ePK.BT to the second LBA (1380).

[0436] Referring to FIG. 13, a bundle can be installed on the second SSP in step 13010. The second SSP (1370) and / or the second LBA (1380) can install the bundle on the second SSP (1370) using the boundSpbImage received in step 13005.

[0437] In one embodiment, if the bundle and / or additional data received from the bundle management server (1350) is encrypted with an encryption key between the bundle management server and the second terminal, the second SSP (1370) can decrypt the encrypted information using SHkeyM2. In another embodiment, if the bundle and / or additional data received from the bundle management server (1350) is encrypted with an encryption key between the bundle management server and the second terminal, the second SSP (1370) can generate an encryption key ShKeyBT using SPBM.ePK.BT and then decrypt the encrypted information using this key.

[0438] In another embodiment, if the bundle and / or additional data received from the bundle management server (1350) is encrypted with an encryption key between the first terminal and the second terminal, the second SSP (1370) can generate an encryption key ShKeyBT using ssp1.ePK.BT and then use this key to decrypt the encrypted information. Referring to FIG. 13, in step 13015, the second SSP (1370) can notify the bundle management server (1350) of the bundle installation result. For example, the second SSP (1370) can send a message (referred to as ssp2.Notification) containing the bundle installation result to the bundle management server (1350).

[0439] FIG. 14 is a diagram illustrating the configuration of a terminal equipped with an SSP according to some embodiments of the present disclosure.

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

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

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

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

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

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

[0446] 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 FIG. 15 and may include more or fewer components than those shown in FIG. 15.

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

[0448] Meanwhile, at least one processor (1520) is a component for overall control of the bundle management server. The processor (1420) can control the overall operation of the bundle management server according to various embodiments of the present disclosure as described above. The at least one processor (1420) may be referred to as a control unit.

[0449] Meanwhile, the bundle management server may further include memory (not shown) and may store data such as basic programs, application programs, and configuration information for the operation of the bundle management server. In addition, the memory may include at least one storage medium among Flash Memory Type, Hard Disk Type, Multimedia Card Micro Type, Card Type Memory (e.g., SD or XD memory, etc.), Magnetic Memory, Magnetic Disk, Optical Disk, Random Access Memory (RAM), Static Random Access Memory (SRAM), Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), and Electrically Erasable Programmable Read-Only Memory (EEPROM).

[0450] FIG. 16 is a diagram illustrating an example of a method in which two terminals and a server interact with each other to enable online transmission of a profile from one terminal to another terminal according to an embodiment of the present disclosure.

[0451] As illustrated in FIG. 16, the first terminal (1600) and the second terminal (1620) are each equipped with a first eSIM (1603) and a second eSIM (1623), and a profile (not shown) may be installed on the first eSIM (1603) and the second eSIM (1623), respectively. Additionally, the first terminal (1600) and the second terminal (1620) may each be equipped with a first LPA (1601) and a second LPA (1621). The first eSIM (1603) and the second eSIM (1623) may each be controlled by the first LPA (1601) and the second LPA (1621), respectively. The first user (1605) and the second user (1625) can each control the profile installed on the eSIM (first eSIM (1603) and second eSIM (1623)) of each terminal through the first LPA (1601) and the second LPA (1621). At this time, the first user (1605) and the second user (1625) may be the same. In addition, the first LPA (1601) and the second LPA (1621) can be connected to each other and communicate. At this time, the possible connection method between the LPAs will be described by referring to the description of the drawings to be described later.

[0452] The first LPA (1601) of the first terminal (1600) may be connected to the first RSP server (1640), and the second LPA (1621) of the second terminal (1620) may be connected to the second RSP server (1680). In this case, the first RSP server (1640) and the second RSP server (1680) may be the same. Additionally, for convenience, the drawing illustrates a case where the first RSP server (1640) and the second RSP server (1680) are each configured as a single server; however, depending on the implementation and embodiment, one or more profile providing servers (SM-DP+) may be included in the server configuration, and one or more activation broker servers (SM-DS) that assist in creating a connection between a specific profile providing server and a terminal may be included in the server configuration. Additionally, although not shown in the drawing, one or more RSP servers and / or relay servers may be connected between the first RSP server (1640) and the second RSP server (1680).

[0453] Additionally, although not illustrated in the drawings, each RSP server and / or relay server may be connected to a carrier server. If one or more carrier servers are included in the configuration, each carrier server may be connected to a separate RSP server and / or relay server, or at least one carrier server may be connected to the same RSP server and / or relay server.

[0454] In this way, the configuration of various servers may be briefly represented as a single RSP server in the drawings below. For example, if 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 a carrier server, the configuration of various servers existing between the first terminal and the second terminal may be represented as a single RSP server, and this single RSP server may be referred to as SM-XX in the drawings and embodiments.

[0455] FIG. 17 is a diagram illustrating the first part of the process of transmitting a profile online from one terminal to another terminal according to some embodiments of the present disclosure.

[0456] Although not illustrated in FIG. 17, the first terminal (1710) and the second terminal (1750) may each include an eUICC and an LPA internally, as illustrated in FIG. 16. Additionally, the RSP server (1730) may mean one or more RSP servers and / or relay servers and / or operator servers, as described in FIG. 16.

[0457] Although not illustrated in FIG. 17, the first terminal (1710) may possess a 'profile transfer setting'. According to various embodiments, the 'profile transfer setting' is a policy regarding whether a profile can be transferred between devices, and may be generated by a telecommunications carrier, may be generated by an RSP server, or may be generated through collaboration between the aforementioned telecommunications carrier and the RSP server. According to various embodiments, the 'profile transfer setting' within the terminal may be updated by the telecommunications carrier, the RSP server, or through collaboration between the telecommunications carrier and the RSP server. Alternatively, the terminal may update the 'profile transfer setting' through collaboration between at least one entity among the telecommunications carrier and the RSP server. The timing and / or method of updating the 'profile transfer setting' may be determined by policies of the telecommunications carrier, the RSP server, the terminal manufacturer, etc.

[0458] The 'Profile Transfer Setting' may include a factor (or indication) indicating whether the transfer of the profile between devices is permitted. Additionally, the 'Profile Transfer Setting' may optionally include a factor specifying the conditions under which such transfer is permitted if the transfer of the profile between devices is allowed. For example, it may be configured to determine whether the profile can be transmitted (or transferred) online from one terminal to another. These factors may be digitally signed by at least one entity among an RSP server, a telecommunications carrier, a terminal manufacturer, an eUICC, and an eUICC manufacturer. The digitally signed value may be stored in the first terminal as part of the 'Profile Transfer Setting' or together with the 'Profile Transfer Setting'.

[0459] Referring to FIG. 17, in step 17000, profile transfer preparation information may be transmitted from the second terminal (1750) to the first terminal (1710). The profile transfer preparation information may include the eUICC identifier (referred to as EID) of the eUICC installed in the second terminal (1750).

[0460] The profile transfer 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 information of the second terminal's eUICC2.Info1, which will be described later. The certificate negotiation information may include information(s) of the version supported by the second terminal's eUICC. The certificate negotiation information may include 'certificate information(s) that can be used to verify the second terminal's eUICC. The certificate negotiation information may include 'certificate information(s) that can be used to verify the RSP server.'

[0461] The profile transfer preparation information may include information used to determine whether a profile to be received from the first terminal (1710) in the future can be successfully installed and operated on the eUICC of the second terminal (1750). The information may be part and / or all of the eUICC2.Info2 of the second terminal, which will be described later. For example, the information may include hardware and / or software information of the eUICC installed on the second terminal (1750). For example, the information may include hardware and / or software information of the second terminal.

[0462] The profile transfer preparation information may include factors designating encryption methods supported by the second terminal (1750). The factors may include a list of key agreement algorithms and / or encryption algorithms supported by the second terminal (1750) and / or the public key(s) of the second terminal to be used for key agreement.

[0463] Information transmitted from the second terminal (1750) to the first terminal (1710) can be transmitted in various ways. For example, the second terminal can provide information to be transmitted to the first terminal to the second user of the second terminal through the UI of the second terminal. The second user can provide the received information to the first user of the first terminal. The first user can input the received information into the first terminal using the UI of the first terminal. Alternatively, the second terminal can create the information to be transmitted to the first terminal in the form of an image (e.g., a QR code) and display it on the screen of the second terminal, and the first user can transmit the information to the first terminal by scanning the image displayed on the screen of the second terminal using 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 in various ways. The first user and the second user may refer to different users, or they may refer to the same single user.

[0464] In one embodiment, the first terminal (1710) can determine whether the profile is transmittable by checking the 'profile transfer setting'. Additionally, the first terminal can determine whether the profile is transmittable online by checking the 'profile transfer setting'. Additionally, the first terminal can select to transmit the profile online by checking the 'profile transfer setting'.

[0465] In one embodiment, the first terminal (1710) can verify the received profile transfer information. For example, the first terminal (1710) can verify whether there is an encryption method supported by itself among the encryption methods supported by the second terminal (1750) included in the profile transfer information. More specifically, the first terminal can verify whether there is an algorithm supported by itself among the key consensus algorithm and / or encryption algorithm supported by the second terminal. If there is a supported algorithm, the first terminal can select the key consensus algorithm and / or encryption algorithm. Additionally, the first terminal can select the public key of the second terminal to be used for future encryption key generation.

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

[0467] Referring to FIG. 17, in step 17010, the RSP server (1730) can check the received eUICC1.Info1 and generate “RSP server authentication information (Server.Auth1).” The RSP server can use the received eUICC1.Info1 to check whether there is a version supported by itself 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 an encryption algorithm to be used for encrypted communication with the first terminal in the future.

[0468] In one embodiment, the RSP server (1730) may generate “RSP server authentication information (Server.Auth1).” The “RSP server authentication information (Server.Auth1)” may include part or all of eUICC1.Info1. For example, the “RSP server authentication information (Server.Auth1)” may include eUICC1.Challenge received by the first terminal (1710). The RSP server authentication information (Server.Auth1) may include any string (Server.Challenge1) generated by the RSP server.

[0469] “RSP server authentication information (Server.Auth1)” may include certificate information that the first terminal must use. “RSP server authentication information (Server.Auth1)” may include a certificate Server.Cert that allows the first terminal to verify itself and related certificate chain information. “RSP server authentication information (Server.Auth1)” may include an encryption algorithm to be used for encrypted communication with the first terminal in the future.

[0470] Part or all of the previously described “RSP server authentication information (Server.Auth1)” may be digitally signed using the RSP server’s certificate Server.Cert, and this digitally signed data may be included as part of the “RSP server authentication information (Server.Auth1).”

[0471] Referring to FIG. 17, in step 17015, the RSP server (1730) can transmit “RSP server authentication information (Server.Auth1)” to the first terminal (1710).

[0472] Referring to FIG. 17, in step 17020, the first terminal (1710) can verify the received “RSP server authentication information (Server.Auth1)” and, based on the verification result (e.g., if verification is successful), generate “first terminal authentication information (Device1.Auth)”. The first terminal can check the validity of Server.Cert included in the “RSP server authentication information (Server.Auth1)” and use Server.Cert to further check the validity of the signature included in the “RSP server information (Server.Auth1)”. The first terminal can check 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 step 17005. For example, if Server.Cert is valid, the signature included in the “RSP server authentication information (Server.Auth1)” is valid, and the value of eUICC1.Challenge is the same, verification can be successful.

[0473] Based on the verification result (e.g., if verification is successful), the first terminal may generate “first terminal authentication information (Device1.Auth).” “First terminal authentication information (Device1.Auth)” may include part or all of Server.Auth1. For example, “first terminal authentication information (Device1.Auth)” may include Server.Challenge1 received by the first terminal.

[0474] “The first terminal authentication information (Device1.Auth)” may include the eUICC identifier of the eUICC installed on the first terminal. Additionally, “the first terminal authentication information (Device1.Auth)” may include the profile identifier of the profile to be transmitted.

[0475] “The first device authentication information (Device1.Auth) may include a certificate eUICC1.Cert capable of verifying itself and related certificate chain information.

[0476] Additionally, the first terminal may select part and / or all of the profile move-ready information received from the second terminal (1750) in step 17000. (Hereafter, for convenience, the selected information is referred to as "move-ready selection information.") For example, the "move-ready selection information" may include "certificate negotiation information used when the second terminal negotiates a certificate with the RSP server" received from the second terminal and "information used to determine whether the profile to be transmitted by the first terminal can be successfully installed and operated on the eUICC of the second terminal." Additionally, the eUICC identifier of the second terminal may be included.

[0477] Some and / or all of the previously described “first terminal authentication information (Device1.Auth)” and “mobility readiness selection information” may be digitally signed using the first terminal’s certificate eUICC1.Cert.

[0478] Referring to FIG. 17, in step 17025, the first terminal (1710) can transmit “first terminal authentication information (Device1.Auth)” and / or “movement readiness selection information” and / or “digital signature information generated in step 17020” to the RSP server (1730).

[0479] Referring to FIG. 17, at step 17030, the RSP server (1730) can verify the received “first terminal authentication information (Device1.Auth).” The 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 digital signature using eUICC1.Cert. The RSP server can check 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 at step 17015. For example, if 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, the verification can be successful.

[0480] In one embodiment, the RSP server can verify that the first terminal is a terminal using the corresponding profile by using the eUICC identifier and profile identifier of the received first terminal.

[0481] In one embodiment, the RSP server checks the “certificate negotiation information used when the second terminal negotiates a certificate with the RSP server” and the “information used to determine whether the profile to be transmitted by the first terminal can be successfully installed and operated on the eUICC of the second terminal” included in the “movement preparation selection information,” thereby verifying whether the certificate negotiation between itself and the second terminal will be successful and whether the said profile can be operated normally on the second terminal when the second terminal requests the profile to be uploaded by the first terminal in the future.

[0482] In addition, the RSP server can store the received profile identifier and the eUICCC identifier of the second terminal.

[0483] Referring to FIG. 17, based on the above judgment result, in step 17035, the RSP server (1730) may send a message requesting a profile (or profile package) to the first terminal (1710). This request message may include a series of data necessary to request the profile. For example, the request message may include a profile identifier of the profile to be requested. Additionally, the request message may further include the RSP server's public key for key consensus. The RSP server's public key for key consensus may be a temporary key.

[0484] Some and / or all of the data included in the aforementioned request message may be digitally signed using the RSP server's certificate Server.Cert, and this digitally signed data may be included as part of the request message.

[0485] Referring to FIG. 17, in step 17040, the first terminal (1710) checks the request message of the transmitted RSP server, and if the verification is successful, the first terminal can prepare a profile package related to the profile requested by the RSP server. For example, the first terminal can verify the validity of the digital signature included in the request message of the RSP server. In addition, the first terminal can verify whether the profile identifier included in the request message of the RSP server matches the identifier of the profile that it intends to transmit.

[0486] If verification is successful, the first terminal may prepare a profile package related to the profile requested by the RSP server. The profile package may include profile information to be transmitted by the first terminal to the second terminal.

[0487] Part and / or all of the “profile information to be transmitted by the first terminal to the second terminal” may be encrypted. Some examples of methods for generating the encryption key used in this case are as follows.

[0488] A) Generate an encryption key using the public key for key consensus of the RSP server provided in step 17035 and the private key for key consensus generated by the first terminal.

[0489] B) Generate an encryption key using the “public key of the second terminal to be used for encryption key generation” selected in step 17005 and the secret key generated by the first terminal.

[0490] The 'profile package' may include a 'public key corresponding to the secret key generated by the first terminal' mentioned above. The 'profile package' may include information related to the encryption key mentioned above, such as a key consensus algorithm used to generate the encryption key and / or information on the encryption algorithm to which the encryption key will be used.

[0491] The contents of the aforementioned profile package may be digitally signed with the certificate eUICC1.Cert of the first terminal, and this digital signature value may be included as part of the profile package.

[0492] Before generating a profile package, the first terminal can disable the status of the profile to be transmitted.

[0493] Referring to FIG. 17, in step 17045, the first terminal (1710) can transmit a profile package to the RSP server (1730).

[0494] Referring to FIG. 17, in step 17050, the RSP server (1730) can store the received profile package. Additionally, the RSP server can link the received profile package with the eUICC identifier of the second terminal. Furthermore, in step 17040, if an encryption key generated using the server's public key for key consensus and the secret key for key consensus generated by the first terminal is used for encryption, the RSP server can generate an encryption key using the public key corresponding to the server's public key for key consensus and the secret key generated by the first terminal, and then decrypt the received profile package using this encryption key.

[0495] FIG. 18 is a diagram illustrating the latter part of the process of transmitting a profile online from one terminal to another terminal according to some embodiments of the present disclosure.

[0496] Although not illustrated in FIG. 18, the first terminal (1810) and the second terminal (1850) may each include an eUICC and an LPA internally, as illustrated in FIG. 16. Additionally, the RSP server (1830) may mean one or more RSP servers and / or relay servers and / or operator servers, as described in FIG. 16.

[0497] Referring to FIG. 18, at step 18000, the process of the second terminal (1850) requesting and receiving a profile from the RSP server (1830) can be initiated. The initiation process can be initiated in various ways.

[0498] For example, the process of requesting and receiving a profile may be initiated by receiving a code (hereinafter referred to as the Activation Code) required for the second terminal to request a profile.

[0499] At this time, the activation code received by the second terminal can be entered in various ways. For example, the first terminal may generate an image such as a QR code containing activation code information and display it on the screen of the first terminal, and the activation code may be entered into the second terminal by the second user scanning the code displayed on the screen of the first terminal using the second terminal. Alternatively, a connection may be established between the first terminal and the second terminal (possible methods of connection include a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE D2D (device-to-device), 5G D2D) or a remote connection where a remote server (e.g., a relay server) is located between the first terminal and the second terminal), and the activation code may be transmitted to the second terminal through this connection. Alternatively, the activation code may be entered into the second terminal by the second user inputting it into the second terminal through the UI provided by the second terminal. Alternatively, the activation code may be input to the second terminal by transmitting the activation code to the second terminal by the RSP server and / or any server associated with the RSP server. Alternatively, the activation code may be input to the second terminal by the second terminal connecting to the RSP server and / or any server associated with the RSP server to obtain the activation code.

[0500] The activation code may include the eUICC identifier of the second terminal. The activation code may include the profile identifier of the profile that the first terminal intends to transmit. The activation code may include the address of the RSP server that the second terminal must connect to in order to request the profile. The activation code may include information that the first terminal used when generating an encryption key to encrypt the profile in FIG. 17, such as the key consensus algorithm used to generate the encryption key and / or information on the encryption algorithm to which the encryption key will be used and / or the public key for key consensus used by the first terminal to generate the encryption key.

[0501] Alternatively, the initiation process may be initiated by the second terminal using the discovery service. For instance, the second terminal may connect to the discovery server to check for events, and after confirming that a profile down event has occurred, the initiation process may be initiated.

[0502] Alternatively, the start process may be initiated by the RSP server notifying the second terminal that an event has occurred. For example, the start process may be initiated by the RSP server or any server associated with the RSP server notifying the second terminal that a profile down event has occurred (for example, the server's PUSH service may be used).

[0503] Alternatively, the initiation process may be initiated by the second user requesting a profile download from the second terminal. For example, the initiation process may be initiated by the second user expressing an intention to download the profile through the UI provided by the second terminal and providing information necessary for the profile download.

[0504] Referring to FIG. 18, in step 18005, the second terminal (1850) may transmit its eUICC information (eUICC2.Info1) to the RSP server (1830). eUICC2.Info1 may include an arbitrary string (eUICC2.Challenge) generated by the eUICC of the second terminal. eUICC2.Info1 may include information(s) of the version supported by the eUICC of the second terminal. eUICC2.Info1 may include 'certificate information(s) that can be used to verify the eUICC of the second terminal.' eUICC2.Info1 may include 'certificate information(s) that can be used to verify the eUICC of the RSP server.' eUICC2.Info1 may include a list of encryption algorithms supported by the second terminal.

[0505] Referring to FIG. 18, in step 18010, the RSP server (1830) can check the received eUICC2.Info1 and generate “RSP server authentication information (Server.Auth2).” The RSP server (1830) can use the received eUICC2.Info1 to check whether there is a version supported by itself among the eUICC versions supported by the second terminal. The RSP server (1830) can use the received eUICC2.Info1 to select a certificate Server.Cert that can verify itself. The RSP server (1830) can use the received eUICC2.Info1 to select certificate information to be used by the second terminal (1350). The RSP server (1830) can use the received eUICC2.Info1 to select an encryption algorithm to be used for encrypted communication with the second terminal in the future.

[0506] In one embodiment, the RSP server (1830) may generate “RSP server authentication information (Server.Auth2).” “RSP server authentication information (Server.Auth2)” may include part or all of eUICC2.Info1. For example, “RSP server authentication information (Server.Auth2)” may include eUICC2.Challenge received. “RSP server authentication information (Server.Auth2)” may include any string (Server.Challenge2) generated by the RSP server.

[0507] “RSP server authentication information (Server.Auth2)” may include certificate information to be used to verify the second terminal. “RSP server authentication information (Server.Auth2)” may include a certificate Server.Cert capable of verifying itself and related certificate chain information. “RSP server authentication information (Server.Auth2)” may include an encryption algorithm to be used for encrypted communication with the second terminal in the future.

[0508] Part and / or all of the previously described “RSP Server Authentication Information (Server.Auth2)” may be digitally signed using the RSP server’s certificate Server.Cert, and this digitally signed data may be included as part of the “RSP Server Authentication Information (Server.Auth2).”

[0509] Referring to FIG. 18, in step 18015, the RSP server (1830) can transmit “RSP server authentication information (Server.Auth2)” to the second terminal (1850).

[0510] Referring to FIG. 18, in step 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 check the validity of Server.Cert included in the “RSP server authentication information (Server.Auth2)” and can further check the validity of the signature included in the “RSP server authentication information (Server.Auth2)” using Server.Cert. The second terminal (1850) can check whether the value of eUICC2.Challenge included in the “RSP server authentication information (Server.Auth2)” is the same as the value of eUICC2.Challenge that it transmitted in step 18005.

[0511] The second terminal (1850) can generate “second terminal authentication information (Device2.Auth)”. “Second terminal authentication information (Device2.Auth)” may include at least part or all of Server.Auth2. For example, it may include the received Server.Challenge2.

[0512] “Device2.Auth” may include information eUICC2.Info2 for verifying the eligibility of the eUICC installed on the second terminal. eUICC2.Info2 may be information used to determine whether a profile to be received from the first terminal in the future can be properly installed and operated on the eUICC of the second terminal. For example, eUICC2.Info2 may include hardware and / or software information of the eUICC mounted on the second terminal. Alternatively, eUICC2.Info2 may include hardware and / or software information of the second terminal.

[0513] “The second terminal authentication information (Device2.Auth)” may include the eUICC identifier of the eUICC installed on the second terminal. “The second terminal authentication information (Device2.Auth)” may include the profile identifier of the profile that the second terminal wishes to request. “The second terminal authentication information (Device2.Auth)” may include the activation code received in step 18000.

[0514] “Device2.Auth” may include a public key for key consensus generated by the eUICC of the second terminal.

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

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

[0517] Referring to FIG. 18, in step 18025, the second terminal (1850) can transmit “second terminal authentication information (Device2.Auth)” to the RSP server (1830).

[0518] Referring to FIG. 18, at step 18030, the RSP server (1830) can verify the received “second terminal authentication information (Device2.Auth).” The RSP server (1830) can check the validity of eUICC2.Cert included in the “second terminal authentication information (Device2.Auth)” and can use eUICC2.Cert to check the validity of the signature included in the “second terminal authentication information (Device2.Auth).” The RSP server (1830) can check whether the value of Server.Challenge2 included in the “second terminal authentication information (Device2.Auth)” is the same as the value of Server.Challenge2 that it transmitted at step 18015.

[0519] The RSP server (1830) can determine whether the profile to be transmitted can be properly installed and operated on the second terminal by checking the eUICC2.Info2 information for the eUICC eligibility check included in the “second terminal authentication information (Device2.Auth)”.

[0520] The RSP server (1830) can check the eUICC identifier of the received second terminal. By checking the eUICC identifier of the received second terminal, the RSP server can check whether there is a profile to be transmitted. By checking the eUICC identifier of the received second terminal, the RSP server can prepare the profile to be transmitted.

[0521] The RSP server (1830) can check the received profile identifier. By checking the received profile identifier, the RSP server can check whether there is a profile to be transmitted. By checking the received profile identifier, the RSP server can prepare the profile to be transmitted.

[0522] The RSP server (1830) can check the received activation code. The RSP server can check the eUICC identifier of the second terminal included in the received activation code. By checking the eUICC identifier of the second terminal included in the received activation code, the RSP server can check whether there is a profile to be transmitted. The RSP server can prepare the profile to be transmitted by checking the eUICC identifier of the second terminal included in the received activation code. The RSP server can check the identifier of the profile included in the received activation code. The RSP server can check whether there is a profile to be transmitted by checking the identifier of the profile included in the received activation code. The RSP server can prepare the profile to be transmitted by checking the identifier of the profile included in the received activation code.

[0523] The RSP server (1830) can generate an encryption key to be used for encryption using the received “public key for key consensus generated by the eUICC of the second terminal” and the “private key for key consensus generated by the RSP server”. The RSP server (1830) can encrypt the profile to be transmitted using the corresponding encryption key.

[0524] In step 18030, the RSP server may prepare a profile package related to the profile requested by the second terminal (1850). The profile package may include profile information to be transmitted by the RSP server to the second terminal.

[0525] The profile package may include information used by the first terminal in FIG. 17 when generating an encryption key to encrypt the profile, such as the key consensus algorithm used to generate the encryption key and / or information on the encryption algorithm to be used for the encryption key and / or the public key for key consensus used by the first terminal to generate the encryption key.

[0526] The profile package may include information that the RSP server used when generating an encryption key to encrypt the profile, such as the key consensus algorithm used to generate the encryption key and / or information on the encryption algorithm to be used for the encryption key and / or the public key for key consensus that the RSP server used to generate the encryption key.

[0527] The contents of the aforementioned profile package may be digitally signed with the RSP server's certificate Server.Cert, and this digital signature value may be included as part of the profile package.

[0528] Referring to FIG. 18, in step 18035, the RSP server (1830) can transmit a profile package to the second terminal (1850).

[0529] Referring to FIG. 18, in step 18040, the second terminal (1850) can install the received profile package. At this time, if part and / or all of the contents of the profile package are encrypted by the first terminal, the second terminal can generate an encryption key using the received public key for key consensus of the first terminal and the secret key for key consensus of the second terminal, and then decrypt the encrypted contents. At this time, if part and / or all of the contents of the profile package are encrypted by the RSP server, the second terminal can generate an encryption key using the received public key for key consensus of the RSP server and the secret key for key consensus of the second terminal, and then decrypt the encrypted contents.

[0530] FIG. 19 is a drawing illustrating the configuration of a terminal equipped with an eUICC according to some embodiments of the present disclosure.

[0531] Referring to FIG. 19, the terminal may include a transceiver (1910), a processor (1920), and an eUICC (1930). Some terminals described above in the present disclosure may correspond to the terminal described in FIG. 19. For example, the first terminal and the second terminal described in FIG. 16 to 18 may each include the configuration of the terminal described in FIG. 19.

[0532] However, the configuration of the terminal is not limited to FIG. 19 and may include more or fewer components than those shown in FIG. 19. According to some embodiments, the transceiver (1910), processor (1920), and eUICC (1930) may be implemented in the form of a single chip. Additionally, the terminal may further include memory, and the processor (1920) may be configured as at least one processor.

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

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

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

[0536] FIG. 20 is a drawing illustrating the configuration of an RSP server according to some embodiments of the present disclosure.

[0537] Referring to FIG. 20, the server may include a transmitting / receiving unit (2010) and a processor (2020). Some server(s) described above in the present disclosure may correspond to the server described in FIG. 20. For example, the server(s) described in FIG. 16 to 18 may include the configuration of the server described in FIG. 20.

[0538] However, the configuration of the server is not limited to FIG. 20 and may include more or fewer components than those shown in FIG. 20. According to some embodiments, the transceiver (2010) and the processor (2020) may be implemented in the form of a single chip. Additionally, the server may further include memory, and the processor (2020) may be configured as at least one processor.

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

[0540] Meanwhile, at least one processor (2020) is a component for controlling the server overall. The processor (2020) can control the overall operation of the server according to various embodiments of the present disclosure as described above. The at least one processor (2020) may be referred to as a control unit.

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

[0542] FIG. 21 is a diagram conceptually illustrating another example of a procedure for transmitting a profile online from one terminal to another terminal according to one embodiment of the present disclosure.

[0543] Referring to FIG. 21, the terminal may include at least one LPA and at least one eSIM. For example, as shown in FIG. 16, 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). For a description of the RSP server, refer to the foregoing details (e.g., FIG. 16).

[0544] In step 21000, the first terminal (2110) and the second terminal (2160) may perform a preparation procedure necessary for profile transmission (profile transmission preparation procedure). For a more detailed description of the profile transmission preparation procedure, refer to the detailed description of FIG. 22 to be described later.

[0545] In step 21005, the second terminal (2160) may request the transmission of a profile to the RSP server (2150). For a more detailed description of the procedure, refer to the detailed description of FIG. 23 to be described later.

[0546] In step 21010, the first terminal (2110) can upload a 'profile to be transmitted to the second terminal' to the RSP server (2150). For a more detailed description of the procedure, refer to the detailed description of FIG. 24 which will be described later.

[0547] In step 21015, the second terminal (2160) can download and install the 'profile uploaded in step 21010' from the RSP server (2150). For a more detailed description of the procedure, refer to the detailed description of FIG. 25 to be described later.

[0548] FIG. 22 is a drawing illustrating a detailed procedure for preparing a profile transmission according to one embodiment of the present disclosure.

[0549] Referring to FIG. 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).

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

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

[0552] The 'Profile Transfer Setting' may include a parameter (or indication) indicating whether the transfer of the profile between devices is allowed. Additionally, the 'Profile Transfer Setting' may optionally include a parameter specifying the conditions under which the transfer is allowed if the transfer of the profile between devices is permitted. For example, the 'Profile Transfer Setting' may be configured to determine whether the profile can be transferred (or moved) online from one terminal to another. As another example, the 'Profile Transfer Setting' may be configured to determine in what form the profile can be transferred. For instance, the profile may be transferred in the form of a profile package, in the form of a profile image, or only some of the profile's data (for example, this may refer to part or all of a series of updates that occurred after the profile was installed on the first terminal. These updates may include data saved by the user, values ​​set by the user, or update history performed by a carrier or RSP server). The profile transfer settings may include information regarding which method(s) among the possible transmission forms of the aforementioned profile are permitted. These factors may be digitally signed by at least one entity among the RSP server, the telecommunications operator, the terminal manufacturer, the eUICC, and the eUICC manufacturer. The said digital signature value may be stored in the first terminal as part of the 'profile transfer settings' or together with the 'profile transfer settings'.

[0553] Referring to FIG. 22, at step 22000, the first LPA (2230) may obtain information about the profile to be transmitted. Alternatively, information about the profile to be transmitted may be delivered to the first LPA (2230). For example, the first LPA (2230) may obtain information about the profile to be transmitted by receiving user input in which a user selects a profile through a UI provided by the first terminal (2210), or information about the profile to be transmitted may be input to the first LPA (2230) via a push input from a remote server, or the first LPA (2230) may connect to a remote server to read information about the profile to be transmitted. However, the method by which the first LPA (2230) obtains information about the profile to be transmitted is not limited to this.

[0554] Referring to FIG. 22, in step 22005, the first LPA (2230) can check whether the profile can be transmitted using the 'profile transfer setting'. Additionally, the first LPA (2230) can check whether the profile can be transmitted online by checking the 'profile transfer setting'. Additionally, the first LPA (2230) can check the 'profile transfer setting' to determine in what form the profile can be transmitted (profile image, profile package, part of the profile data, etc.).

[0555] Referring to FIG. 22, in step 22010, the first LPA (2230) may generate a 'profile transmission code'. The profile transmission code may include a 'profile identifier' of the profile to be transmitted. Additionally, the profile transmission code may include the address of an RSP server associated with the profile to be transmitted. (Subsequently, the second terminal (2260) may use this address to connect to the RSP server and download the profile.) Additionally, the profile transmission code may include other information indicating the attributes of the profile (e.g., metadata of the profile or part of the metadata). Additionally, the profile transmission code may include information on cryptographic algorithms supported by the first terminal (e.g., the first eSIM) (Supported Crypto Info). The information on cryptographic algorithms supported by the first terminal may optionally include one or more of the following information: a list of elliptic curves supported by the first terminal, a list of key consensus algorithms supported by the first terminal, and a list of cryptographic algorithms supported by the first terminal.

[0556] Referring to FIG. 22, in step 22015, the profile transmission code generated in step 22010 can be transmitted from the first LPA (2230) to the second LPA (2280). The profile transmission code can be transmitted in various ways.

[0557] 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 into the second LPA using the UI of the second terminal.

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

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

[0560] FIG. 23 is a diagram illustrating a procedure in which a second terminal (2360) requests profile transmission to an RSP server (2350) according to one embodiment of the present disclosure.

[0561] Referring to FIG. 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). Refer to FIG. 16 for a description of the RSP server (2350).

[0562] Referring to FIG. 23, at step 23000, mutual authentication may be performed between the second terminal (2360) and the RSP server (2350). This mutual authentication process may include one or more of the following processes.

[0563] - The mutual authentication process may include a certificate negotiation process that must be undergone for the second terminal and the RSP server to communicate. For example, the second terminal may transmit to the RSP server certificate information that can be used to verify the RSP server and / or certificate information that the RSP server can use to verify the second terminal. Upon receiving this information, the RSP server may select the certificate information that the second terminal will use to verify the RSP server and / or the certificate information that the RSP server will use to verify the second terminal. At this time, the certificate information selected by the RSP server may be transmitted to the second terminal. Through this process, the second terminal and the RSP server can obtain certificate information that enables them to authenticate each other. In this case, certificate information may be a certificate and / or information contained in the certificate and / or a series of information that can refer to the certificate.

[0564] - The second terminal can transmit a random number (eUICC Challenge) value it has generated to the RSP server. The RSP server can digitally sign the received random number value and transmit this signed value to the second terminal. The second terminal can authenticate the RSP server by verifying the received signed value.

[0565] The RSP server can transmit a random number (server challenge) value it has generated to the second terminal. The second terminal can digitally sign the received random number value and transmit this signed value to the RSP server. The RSP server can authenticate the second terminal by verifying the received signed value.

[0566] - During communication between the RSP server and the second terminal, an ID (Transaction ID) for managing the session may be exchanged. For example, the RSP server may generate a transaction ID and transmit this value to the second terminal. At this time, the RSP server's digital signature value may be added to verify the reliability and integrity of the transaction ID.

[0567] - The RSP server and the second terminal may exchange profile identifiers associated with the profile to be transmitted in the present disclosure. For example, the second terminal may transmit the identifier of the profile it wishes to receive to the RSP server. In this case, the profile identifier may be transmitted together with the digital signature value of the second terminal to ensure reliability and integrity.

[0568] - The RSP server and the second terminal can exchange IDs with each other. For example, the RSP server can provide its OID (object identifier) ​​to the second terminal. As another example, the second terminal can provide its eUICC identifier to the RSP server.

[0569] Referring to Fig. 23, the following process can be performed in step 23005.

[0570] The RSP server (2350) can check the 'profile transfer settings'. For example, the RSP server (2350) can check the received profile identifier and the 'profile transfer settings' associated with the profile to determine whether the profile can be transmitted. Additionally, the RSP server (2350) can check the 'profile transfer settings' to determine whether the profile can be transmitted online. Additionally, the RSP server (2350) can check the 'profile transfer settings' to determine in what form (profile image, profile package, part of the profile data, etc.) the profile can be transmitted.

[0571] The RSP server (2350) can perform an 'Eligibility Check' to determine whether the profile can be installed and used on the second terminal. For example, the RSP server (2350) can check whether the profile can be installed and operated on the second terminal by using the eUICC identifier of the received second terminal and the received profile identifier.

[0572] The RSP server (2350) may generate a Transfer Option in response to a request for bundle reception from the second terminal. The Transfer Option may include information regarding whether the profile can be transmitted to the second terminal, and if transmission is possible, in what form it can be transmitted. For example, the Transfer Option may include at least one of the following values.

[0573] - Profile can be transmitted in the form of a profile image

[0574] - Profiles can be transmitted in the form of a profile package

[0575] - Some data types of the profile can be transmitted

[0576] - Profile transmission impossible

[0577] The RSP server (2350) may transmit a transmission option to the second LPA (2380). At this time, the transmission option may be digitally signed by the RSP server (2350). The digital signature value may be transmitted to the second LPA (2380) along with the transmission option. Additionally, the certificate of the RSP server, including the encryption key used for the digital signature, and related information may be transmitted to the second LPA (2380).

[0578] Referring to Fig. 23, the following process can be performed in step 23010.

[0579] The second LPA (2380) can obtain the user's consent after checking the received transmission option.

[0580] The second LPA (2380) can transmit the received transmission option to the second eSIM (2370). The second LPA (2380) can transmit the signature value of the received transmission option to the second eSIM (2370). The second LPA (2380) can transmit the certificate and related information to be used to verify the electronic signature value of the received transmission option to the second eSIM (2370).

[0581] The second LPA (2380) can optionally further transmit the 'Supported Crypto Info' received in step 22015 to the second eSIM (2370).

[0582] Referring to Fig. 23, the following process can be performed in step 23015.

[0583] The second eSIM (2370) can verify the validity of the certificate and related information received in step 23010.

[0584] The second eSIM (2370) can verify the validity of the electronic signature value received in step 23010.

[0585] The second eSIM (2370) can check the contents of the transmission option received in step 23010.

[0586] When the second eSIM (2370) receives 'Supported Crypto Info', it can check the contents of the received 'Supported Crypto Info' and determine whether there are any encryption algorithms that it supports among them. If there are encryption algorithms supported by the second eSIM among the received supported Crypto Info, the second eSIM (2370) can select one of them and set it as the 'Selected Crypto Info'. The 'Selected Crypto Info' may optionally include one or more of the following information: elliptic curve information, key consensus algorithm information, encryption algorithm information.

[0587] The second eSIM (2370) can generate a public key “otPK.EUICC.KA” and a private key “otSK.EUICC.KA”, which are encryption key pairs to be used to create encryption keys for encrypted communication. At this time, the generated encryption keys may be for ‘encrypted communication between the RSP server and the second terminal’ or for ‘encrypted communication between the first terminal and the second terminal’. At this time, if the generated encryption keys are for ‘encrypted communication between the first terminal and the second terminal’, these encryption keys (otPK.EUICC.KA and otSK.EUICC.KA) may be encryption keys that follow the encryption algorithm included in the aforementioned Selected Crypto Info.

[0588] The second eSIM (2370) can transmit the generated otPK.EUICC.KA to the RSP server (2350). This encryption key can be digitally signed by the second eSIM. The digitally signed value generated by the second eSIM can be transmitted to the RSP server. The encryption key and / or digitally signed value may be referred to as Device2.Auth.

[0589] The second eSIM (2370) can optionally transmit Selected Crypto Info to the RSP server (2350) via the second LPA (2380).

[0590] FIG. 24 is a diagram illustrating the procedure for a first terminal (2410) to upload a ‘profile to be transmitted to a second terminal’ to an RSP server (2450) according to an embodiment of the present disclosure.

[0591] Referring to FIG. 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). Refer to FIG. 16 for a description of the RSP server (2450).

[0592] Referring to FIG. 24, at step 24000, mutual authentication may be performed between the first terminal (2410) and the RSP server (2450). This mutual authentication process may include one or more of the following processes.

[0593] - The mutual authentication process may include a certificate negotiation process that must be undergone for the first terminal (2410) and the RSP server (2450) to communicate. For example, the first terminal (2410) may transmit to the RSP server (2450) certificate information that can be used to verify the RSP server (2450) and / or certificate information that the RSP server (2450) can use to verify the first terminal (2410). Upon receiving this information, the RSP server (2450) may select the certificate information that the first terminal (2410) will use to verify the RSP server (2450) and / or the certificate information that the RSP server (2450) will use to verify the first terminal (2410). At this time, the certificate information selected by the RSP server (2450) may be transmitted to the first terminal (2410). Through this process, the first terminal (2410) and the RSP server (2450) can obtain certificate information that allows them to authenticate each other. At this time, the certificate information may be a certificate and / or information included in the certificate and / or a series of information that can refer to the certificate.

[0594] - The first terminal (2410) can transmit a random number (eUICC Challenge) value generated by itself to the RSP server (2450). The RSP server (2450) can digitally sign the received random number value and then transmit this signature value to the first terminal (2410). The first terminal (2410) can authenticate the RSP server (2450) by verifying the received signature value.

[0595] - The RSP server (2450) can transmit a random number (server challenge) value generated by itself to the first terminal (2410). The first terminal (2410) can digitally sign the received random number value and then transmit this signature value to the RSP server (2450). The RSP server (2450) can authenticate the first terminal (2410) by verifying the received signature value.

[0596] - While the RSP server (2450) and the first terminal (2410) communicate, an ID (Transaction ID) for managing the session may be exchanged. For example, the RSP server (2450) may generate a transaction ID and then transmit this value to the first terminal (2410). At this time, the RSP server's digital signature value may be added to verify the reliability and integrity of the transaction ID.

[0597] - The RSP server (2450) and the first terminal (2410) may exchange profile identifiers associated with the profile to be transmitted in the present disclosure. For example, the first terminal (2410) may transmit the identifier of the profile it intends to transmit to the RSP server (2450). At this time, the profile identifier may be transmitted together with the electronic signature value of the first terminal (2410) to ensure reliability and integrity.

[0598] - The RSP server (2450) and the first terminal (2410) can exchange IDs with each other. For example, the RSP server (2450) can provide its own OID (object identifier) ​​to the first terminal (2410). As another example, the first terminal (2410) can provide its own eUICC identifier to the RSP server (2450).

[0599] Although not shown in the drawing, the first terminal (2410) can wait between step 24000 and step 24005.

[0600] Referring to Fig. 24, the following process can be performed in step 24005.

[0601] The RSP server (2450) can generate a public key "otPK.DP.KA" and a private key "otSK.DP.KA", which are encryption key pairs to be used to create an encryption key for encrypted communication with the first eSIM (2420).

[0602] The RSP server (2450) can transmit the public key otPK.XX.KA to the first eSIM (2420) via the first LPA (2430). At this time, otPK.XX.KA may be otPK.EUICC.KA received in step 23015 or otPK.DP.KA.

[0603] The RSP server (2450) can transmit a transfer option to the first eSIM (2420) via the first LPA (2430). The transfer option may include information on whether the profile can be transmitted to the second terminal, and if transmission is possible, in what form it can be transmitted. For example, the transfer option may include at least one of the following values.

[0604] - Profile can be transmitted in the form of a profile image

[0605] - Profiles can be transmitted in the form of a profile package

[0606] - Some data types of the profile can be transmitted

[0607] - Profile transmission impossible

[0608] At this time, the otPK.XX.KA and / or transmission options transmitted to the first eSIM (2420) may be digitally signed by the RSP server (2450). The digital signature value may be transmitted to the first eSIM (2420) via the first LPA (2430). Additionally, the certificate and related information of the RSP server that can be used to verify the digital signature may be transmitted to the first eSIM (2420) via the first LPA (2430).

[0609] The RSP server (2450) may optionally further transmit the Selected Crypto Info received in step 23015 to the first eSIM (2420) via the first LPA (2430).

[0610] The first terminal (2410) (e.g., the first LPA (2430)) may obtain user consent regarding the received transmission option.

[0611] Referring to Fig. 24, the following process can be performed in step 24010.

[0612] The first eSIM (2420) can verify the validity of the certificate and related information received in step 24005.

[0613] The first eSIM (2420) can verify the validity of the digital signature value received in step 24005.

[0614] The first eSIM (2420) can check the contents of the transmission option received in step 24005.

[0615] The first eSIM (2420) can generate a public key "otPK.EUICC.KA" and a private key "otSK.EUICC.KA", which are encryption key pairs to be used to create encryption keys for encrypted communication. At this time, the generated encryption keys may be for 'encrypted communication between the RSP server and the first terminal' or for 'encrypted communication between the first terminal and the second terminal'. Whether the generated encryption keys are for which encrypted communication can be determined by the value of otPK.XX.KA received in step 24005. The first eSIM (2420) can calculate the digital signature value of the generated otPK.EUICC.KA. The above-mentioned otPK.EUICC.KA and / or digital signature value may be collectively referred to as Device1.Auth.

[0616] The first eSIM (2420) can generate a session key to use for encrypted communication using the “otSK.EUICC.KA” it generated and the otPK.XX.KA received in step 24005.

[0617] The first eSIM (2420) can prepare a profile to be transmitted to the second terminal (with the help of the first LPA, if applicable). At this time, the form of the prepared profile may correspond to the transmission option received in step 24005, that is, the form of the prepared profile may be one of the following.

[0618] - Profile Image

[0619] - Profile Package

[0620] - Part of the profile data

[0621] All and / or part of the above-described prepared profile may be encrypted by the aforementioned session key. Additionally, all and / or part of the above-described prepared profile may be digitally signed by the first terminal, and this digital signature value may be included as part of the prepared profile.

[0622] The first eSIM (2420) can delete the corresponding profile. The RSP server (2450) may be notified whether the corresponding profile has been deleted.

[0623] The first eSIM (2420) can transmit Device1.Auth and / or 'prepared profile' to the RSP server (2450) via the first LPA (2430).

[0624] Referring to FIG. 24, in step 24015, the RSP server (2450) can send a response message to the first LPA (2430) indicating that all processes have been performed.

[0625] FIG. 25 is a diagram illustrating the procedure for a second terminal (2560) according to one embodiment of the present disclosure to download and install a ‘prepared profile’ uploaded from an RSP server (2550).

[0626] Referring to FIG. 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). Refer to FIG. 16 for a description of the RSP server (2550).

[0627] Although not illustrated in the drawings, the second terminal (2560) may wait for the 25000 step described below to be performed after performing the 23015 step presented in FIG. 23. This waiting process may be implemented in various ways described below. However, the waiting process is not limited to this, and the waiting process does not necessarily have to be one of the methods described below.

[0628] a) The RSP server (2550) may send a message to the second LPA (2580) stating that it has received the requested operation but must wait to receive a response. The second LPA (2580) may wait for a certain period of time and then send a message to the RSP server (2550) to check whether the requested operation has been completed. If the operation has been completed, step 25000 may be performed. If the operation has not been completed, the RSP server (2550) may send a message stating that it must wait a little longer. In this case, the second LPA (2580) may wait for a certain period of time again and then send a message to the bundle management server to check whether the requested operation has been completed. The above process may be repeated until step 25000 is performed.

[0629] b) The second LPA (2580) may wait for 25,000 steps to be performed within a set time range. If 25,000 steps are not performed within the set time, the profile transmission process may be stopped.

[0630] c) The RSP server (2550) may notify the second LBA (2580) that it has received the requested operation. (For example, the RSP server may send a push message to the second LBA.) Then, step 25000 may be performed.

[0631] Referring to Fig. 25, the following process can be performed at step 25000.

[0632] The RSP server (2550) can verify the validity of the digital signature value of Device2.Auth received in step 23015.

[0633] The RSP server (2550) can check the contents of Device2.Auth received in step 23015.

[0634] The RSP server (2550) can generate a public key "otPK.DP.KA" and a private key "otSK.DP.KA", which are encryption key pairs to be used to create encryption keys for encrypted communication. At this time, the generated encryption keys may be for 'encrypted communication between the RSP server and the second terminal'. The RSP server can generate a session key for encrypted communication with the second terminal using the generated encryption key pair.

[0635] The RSP server (2550) can prepare a Bound Profile to be transmitted to the second terminal.

[0636] At this time, the Bound Profile prepared can be one of the following forms.

[0637] - Profile image received in step 24010

[0638] - Profile package received in step 24010

[0639] - Profile package and / or image created including some data from the profile received in step 24010

[0640] - Profile package and / or image containing some of the profile data received in step 24010 as additional data

[0641] If the data received in step 24010 is encrypted with the 'session key for encrypted communication between the first terminal and the RSP server,' the following process may be performed additionally. The RSP server can decrypt the received data. The RSP server can encrypt the decrypted data with the 'session key for encrypted communication between the second terminal and the RSP server.'

[0642] The RSP server (2550) can send a Bound Profile to the second LPA (2580).

[0643] Referring to Fig. 25, the following process can be performed in step 25005.

[0644] The second LPA (2580) can verify the received Bound Profile. For example, the second LPA (2580) can check and verify the contents of the metadata included in the Bound Profile. Additionally, the second LPA (2580) can obtain user consent regarding the Bound Profile.

[0645] The second LPA (2580) and the second eSIM (2570) can install the Bound Profile received on the second eSIM.

[0646] Referring to FIG. 25, in step 25010, the second eSIM (2570) can notify the RSP server (2500) that a profile has been installed via the second LPA (2580).

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

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

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

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

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

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

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

Claims

Claim 1 In a first terminal that provides a bundle to a second terminal in a wireless communication system, a transmitting and receiving unit; A first terminal, comprising at least one processor, wherein the at least one processor obtains information regarding a bundle to be transmitted to the second terminal, determines whether the first terminal can transmit a bundle to the second terminal based on bundle transfer setting information including an indicator indicating whether the first terminal can transmit a bundle to another terminal, generates a bundle transfer code including identification information of the bundle to be transmitted to the second terminal, transmits the generated bundle transfer code to the second terminal, uploads the bundle to be transmitted to the second terminal to a bundle management server, transmits bundle transfer authentication information to the bundle management server including at least one of the first SSP (Smart Secure Platform) information of the first terminal, certificate negotiation information for authentication between the first terminal and the bundle management server, or version information of the first SSP, receives server authentication information from the bundle management server based on the transmitted bundle transfer authentication information, and the bundle to be transmitted to the second terminal is installed in the second terminal by being transmitted to the second terminal through the bundle management server. Claim 2 In claim 1, the bundle transfer setting information comprises at least one of information regarding conditions required for bundle transfer between the first terminal and the second terminal, and an indicator indicating whether bundle transfer through the bundle management server between the first terminal and the second terminal is allowed. Claim 3 In claim 1, the identification information of the bundle includes at least one of an identifier (Identity) of the bundle to be transmitted to the second terminal, a bundle family identifier (Family ID), or a bundle family manager identifier (Family Custodian Object ID), and the bundle transmission code further includes at least one of information related to the attributes of the bundle to be transmitted to the second terminal, an address of the bundle management server, information for a connection between the first terminal and the second terminal, or encryption algorithm information supported by the first terminal. Claim 4 In claim 1, the at least one processor transmits a first terminal authentication information and a bundle identifier of a bundle to be transmitted to the second terminal to the bundle management server based on the received server authentication information, receives a bundle request message from the bundle management server based on the result in which the bundle management server determines the first terminal as a terminal capable of transmitting a bundle to be transmitted to the second terminal based on the first terminal authentication information, and uploads a bundle to be transmitted to the second terminal to the bundle management server based on the received bundle request message. Claim 5 A second terminal receiving a bundle from a first terminal in a wireless communication system comprises: a transmitting and receiving unit; and at least one processor, wherein the at least one processor receives a bundle transmission code including identification information of a bundle to be received by the second terminal from the first terminal, performs an authentication procedure with a bundle management server based on the received bundle transmission code, transmits information of a bundle to be received to the bundle management server as a result of successfully performing the authentication procedure with the bundle management server, receives a first bundle and first bundle information as determined by the bundle management server that the bundle received by the second terminal corresponds to the bundle to be received, transmits second SSP information including certificate negotiation information for authentication between the second SSP (Smart Secure Platform) of the second terminal and the bundle management server to the bundle management server, and receives server authentication information generated by the bundle management server based on the second SSP information from the bundle management server. Claim 6 In paragraph 5, the identification information of the bundle to be received by the second terminal comprises at least one of the identifier (Identity), bundle family identifier (Family ID), or bundle family manager identifier (Family Custodian Object ID) of the bundle to be received by the second terminal, and the bundle transmission code further comprises at least one of information related to the attributes of the bundle to be received by the second terminal, the address of the bundle management server, information for a connection between the first terminal and the second terminal, or encryption algorithm information supported by the first terminal. Claim 7 In paragraph 5, the at least one processor transmits second terminal information, including an identifier of the second SSP and an identifier of the bundle to be received, to the bundle management server based on the server authentication information, and the second terminal receives the first bundle and the first bundle information from the bundle management server according to the result of determining that the identifier of the second SSP received from the first terminal and the identification information of the bundle to be received by the second terminal correspond to the identifier of the second SSP received from the second terminal and the identifier of the bundle to be received, respectively. Claim 8 In paragraph 5, the second terminal is determined by the bundle management server to be a terminal capable of receiving a bundle from another terminal based on bundle transfer setting information, and the bundle to be received is a bundle determined by the bundle management server to be installable on the second terminal. Claim 9 In a first terminal that provides a profile to a second terminal in a wireless communication system, a transmitting and receiving unit; and includes at least one processor, wherein the at least one processor determines a first profile to be transmitted to the second terminal among profiles installed on the first terminal, and determines whether the first profile can be transmitted to the second terminal via a profile management server based on profile transfer setting information including an identifier of the eUICC (embedded Universal Integrated Circuit Card) of the second terminal, and, as a result of verifying the profile management server, transmits first terminal authentication information including the eUICC identifier of the first terminal and the first profile identifier to the profile management server, and receives a profile request message from the profile management server based on the result of the profile management server verifying that the first terminal is using the first profile using the eUICC identifier of the first terminal and the first profile identifier, and transmits a profile package for the first profile to the profile management server based on the profile request message, and if the transmitted profile package for the first profile is encrypted by the first terminal, the profile package for the first profile is encrypted using the first public key of the first terminal and the secret key of the second terminal A first terminal that decrypts, and if the profile package for the first profile transmitted above is encrypted by the profile management server, decrypts the profile package for the first profile using the second public key of the profile management server and the secret key of the second terminal. Claim 10 In claim 9, the at least one processor receives profile movement setting information including an identifier of the eUICC and eUICC information of the second terminal from the second terminal, and the eUICC information of the second terminal includes information used to determine whether a profile to be received from the first terminal can be normally installed and operated in the eUICC of the second terminal, the first terminal. Claim 11 In claim 9, the first terminal, wherein the at least one processor transmits eUICC information of the first terminal to the profile management server, receives server authentication information of the profile management server generated by the profile management server based on the eUICC information of the first terminal, and verifies the profile management server based on the eUICC information of the first terminal and the server authentication information of the profile management server. Claim 12 In claim 9, the profile package comprises at least one of information regarding the first profile, first encryption key generation information used by the first terminal to encrypt the first profile, the first public key of the first terminal, second encryption key generation information used by the profile management server to encrypt the first profile, or the second public key of the profile management server. Claim 13 In a second terminal that receives a profile from a first terminal in a wireless communication system, a transmitting and receiving unit; and includes at least one processor, wherein the at least one processor transmits profile transfer setting information including an identifier of the eUICC (embedded Universal Integrated Circuit Card) of the second terminal to the first terminal, transmits the eUICC information of the second terminal to a profile management server, receives authentication information of the profile management server based on the eUICC information of the second terminal, verifies the profile management server based on the authentication information of the profile management server, transmits second terminal authentication information including the eUICC identifier of the second terminal and an identifier of the profile to be transmitted to the profile management server, receives a profile package for a first profile from the profile management server based on the second terminal authentication information, and if the received profile package for the first profile is encrypted by the first terminal, decrypts the profile package for the first profile using the first public key of the first terminal and the secret key of the second terminal, and if the received profile package for the first profile is encrypted by the profile management server, the second public key of the profile management server and the second terminal A second terminal that decrypts a profile package for the first profile using a secret key. Claim 14 In paragraph 13, the second terminal authentication information comprises information used to determine whether a profile to be received from the first terminal can be normally installed and operated in the eUICC of the second terminal. Claim 15 In paragraph 13, the profile package comprises at least one of the following: information regarding the first profile, first encryption key generation information used by the first terminal to encrypt the first profile, the first public key of the first terminal, second encryption key generation information used by the profile management server to encrypt the first profile, or the second public key of the profile management server.

Images