KR20210116169A - Apparatus and methods for device to device bundle or profile online transfer - Google Patents

Abstract

The present invention discloses a method and device for securely moving bundles between smart secure media or online moving profiles. According to one embodiment of the present disclosure, the method of providing a bundle to a second terminal by a first terminal includes the steps of: obtaining information about 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 use information of the second terminal from the second terminal; performing an authentication procedure for uploading the bundle and a server based on at least one of the received encryption information and bundle use information of the second terminal; and uploading the bundle to the server based on the authentication procedure.

Description

{APPARATUS AND METHODS FOR DEVICE TO DEVICE BUNDLE OR PROFILE ONLINE TRANSFER}

The present disclosure relates to a smart secure medium, and more particularly, to a method and apparatus for online moving a bundle or profile between smart secure media.

Efforts are being made to develop an improved 5G communication system or pre-5G communication system in order to meet the increasing demand for wireless data traffic after the commercialization of the 4G communication system. For this reason, the 5G communication system or the pre-5G communication system is called a 4G network after (Beyond 4G Network) communication system or an LTE system after (Post LTE) system. In order to achieve a high data rate, the 5G communication system is being considered for implementation in a very high frequency (mmWave) band (eg, such as a 60 gigabyte (60 GHz) band). In order to mitigate the path loss of radio waves and increase the propagation distance of radio waves in the ultra-high frequency band, in the 5G communication system, beamforming, massive MIMO, and Full Dimensional MIMO (FD-MIMO) are used. ), array antenna, analog beam-forming, and large scale antenna technologies are being discussed. In addition, for network improvement of the system, in the 5G communication system, an evolved small cell, an advanced small cell, a cloud radio access network (cloud RAN), and an ultra-dense network (ultra-dense network) , Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, Coordinated Multi-Points (CoMP), and interference cancellation Technology development is underway. In addition, in the 5G system, FQAM (Hybrid FSK and QAM Modulation) and SWSC (Sliding Window Superposition Coding), which are advanced coding modulation (ACM) methods, and FBMC (Filter Bank Multi Carrier), which are advanced access technologies, NOMA (non orthogonal multiple access), and sparse code multiple access (SCMA) are being developed.

On the other hand, the Internet is evolving from a human-centered connection network where humans create and consume information to an Internet of Things (IoT) network that exchanges and processes information between distributed components such as objects. Internet of Everything (IoE) technology, which combines big data processing technology through connection with cloud servers, etc. with IoT technology, is also emerging. In order to implement IoT, technology elements such as sensing technology, wired and wireless communication and network infrastructure, service interface technology, and security technology are required. , M2M), and MTC (Machine Type Communication) are being studied. In the IoT environment, an intelligent IT (Internet Technology) service that collects and analyzes data generated from connected objects and creates new values in human life can be provided. IoT is a field of smart home, smart building, smart city, smart car or connected car, smart grid, health care, smart home appliance, advanced medical service, etc. can be applied to

Accordingly, various attempts are being made to apply the 5G communication system to the IoT network. For example, in technologies such as sensor network, machine to machine (M2M), and machine type communication (MTC), 5G communication technology is implemented by techniques such as beam forming, MIMO, and array antenna. there will be The application of a cloud radio access network (cloud RAN) as the big data processing technology described above is an example of the convergence of 5G technology and IoT technology.

As described above, as various services can be provided according to the development of mobile communication systems, a method for effectively providing these services is required. For example, there is a need for a safe and efficient way to move bundles or profiles (or profile packages) online between two devices.

The disclosed embodiment provides an apparatus and method for enabling a reliable bundle or profile online movement service when a bundle or profile is to be moved online between security modules included in two electronic devices.

According to an embodiment of the present disclosure, a method for a first terminal to provide a bundle to a second terminal in a wireless communication system includes: obtaining information about a bundle to be transmitted to the second terminal; transmitting the 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 for uploading the bundle to a server based on at least one of the received encryption information and bundle use information of a second terminal; and uploading the bundle to the server based on the authentication procedure.

According to an embodiment of the present disclosure, a method for a second terminal to receive a bundle from a first terminal includes: receiving a transmission code of the bundle from the first terminal; generating at least one of encryption information and bundle use information of a 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 for downloading the bundle with a server; and downloading the bundle from the server based on the authentication procedure.

According to various embodiments of the present disclosure, a bundle or profile installed in one device may be transmitted online to another device or installed in another device in a safe and efficient manner.

1 shows a conceptual diagram of a Smart Secure Platform (SSP) according to an embodiment of the present disclosure.
2 is a conceptual diagram illustrating an internal structure of an SSP according to an embodiment of the present disclosure.
3 is a diagram illustrating an example of components in a terminal used for a terminal to download and install a bundle to an SSP according to an embodiment of the present disclosure.
4 is a diagram illustrating an example of a method in which two terminals and a server mutually operate in order to perform online transmission of a bundle from one terminal to another terminal according to an embodiment of the present disclosure.
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.
6 is a diagram illustrating a detailed procedure of a procedure for preparing for bundle transmission among the procedures presented in FIG. 5 according to an embodiment of the present disclosure.
7 is a diagram illustrating a procedure in which a terminal to transmit a bundle uploads a bundle to be transmitted to a server among the procedures shown in FIG. 5 according to an embodiment of the present disclosure.
8 is a diagram illustrating a procedure in which a bundle uploaded to a server is downloaded to a terminal to receive the bundle among the procedures presented in FIG. 5 according to an embodiment of the present disclosure.
9 is a diagram conceptually illustrating another 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. 10 is a diagram illustrating a detailed procedure for a procedure for preparing a bundle for transmission among the procedures presented in FIG. 9 according to an embodiment of the present disclosure.
11 is a diagram illustrating a procedure in which a terminal receiving a bundle communicates with a server and receives approval among the procedures shown in FIG. 9 according to an embodiment of the present disclosure.
12 is a diagram illustrating a procedure in which a terminal to transmit a bundle uploads a bundle to be transmitted to a server among the procedures shown in FIG. 9 according to an embodiment of the present disclosure.
13 is a diagram illustrating a procedure in which a bundle uploaded to a server is downloaded to a terminal to receive the bundle among the procedures presented in FIG. 9 according to an embodiment of the present disclosure.
14 is a diagram illustrating a configuration of a terminal equipped with an SSP according to some embodiments of the present disclosure.
15 is a diagram illustrating a configuration of a bundle management server according to some embodiments of the present disclosure.
16 is a diagram illustrating an example of a method in which two terminals and a server mutually operate in order to perform online transmission of a profile from one terminal to another terminal according to an embodiment of the present disclosure.
17 is a diagram illustrating the first half of a process of online transmission of a profile from one terminal to another terminal according to some embodiments of the present disclosure.
18 is a diagram illustrating a second half procedure of a process of online transmission of a profile from one terminal to another terminal according to some embodiments of the present disclosure.
19 is a diagram illustrating a configuration of a terminal on which an embedded Universal Integrated Circuit Card (eUICC) is mounted according to some embodiments of the present disclosure.
20 is a diagram illustrating a configuration of a Remote SIM Provisioning (RSP) server according to some embodiments of the present disclosure.
21 is a diagram conceptually illustrating another example of a procedure for online transmission of a profile from one terminal to another terminal according to an embodiment of the present disclosure.
22 is a diagram illustrating a detailed procedure for a procedure for preparing for profile transmission according to an embodiment of the present disclosure.
23 is a diagram illustrating a procedure in which a second terminal requests profile transmission to an RSP server according to an embodiment of the present disclosure.
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.
25 is a diagram illustrating a procedure for a second terminal to download and install a 'prepared profile' uploaded from an RSP server according to an embodiment of the present disclosure.

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

In describing the embodiments, descriptions of technical contents that are well known in the technical field to which the present disclosure pertains and are not directly related to the present disclosure will be omitted. This is to more clearly convey the gist of the present disclosure without obscuring the gist of the present disclosure by omitting unnecessary description.

For the same reason, some components are exaggerated, omitted, or schematically illustrated in the accompanying drawings. In addition, the size of each component does not fully reflect the actual size. In each figure, the same or corresponding elements are assigned the same reference numerals.

Advantages and features of the present disclosure, and a method of achieving them will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below, but may be implemented in a variety of different forms, only the present embodiments allow the present disclosure to be complete, and those of ordinary skill in the art to which the present disclosure pertains. It is provided to fully understand the scope of the disclosure, and the present disclosure is only defined by the scope of the claims. Like reference numerals refer to like elements throughout.

At this time, it will be understood that each block of the flowchart diagrams and combinations of the flowchart diagrams may be performed by computer program instructions. These computer program instructions may be embodied in a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, such that the instructions performed by the processor of the computer or other programmable data processing equipment are not described in the flowchart block(s). Create means to perform functions. These computer program instructions may also be stored in a computer-usable or computer-readable memory that may direct a computer or other programmable data processing equipment to implement a function in a particular manner, and thus the computer-usable or computer-readable memory. It is also possible that the instructions stored in the flow chart block(s) produce an article of manufacture containing instruction means for performing the function described in the flowchart block(s). The computer program instructions may also be mounted on a computer or other programmable data processing equipment, such that a series of operational steps are performed on the computer or other programmable data processing equipment to create a computer-executed process to create a computer or other programmable data processing equipment. It is also possible that instructions for performing the processing equipment provide steps for performing the functions described in the flowchart block(s).

Additionally, each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s). It should also be noted that in some alternative implementations it is also possible for the functions recited in blocks to occur out of order. For example, two blocks shown one after another may in fact be performed substantially simultaneously, or it is possible that the blocks are sometimes performed in the reverse order according to the corresponding function.

At this time, the term '~ unit' used in this embodiment means software or hardware components such as FPGA or ASIC, and '~ unit' performs certain roles. However, '-part' is not limited to software or hardware. The '~ unit' may be configured to reside on an addressable storage medium or may be configured to refresh one or more processors. Thus, as an example, '~' denotes components such as software components, object-oriented software components, class components, and task components, and processes, functions, properties, and procedures. , subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. The functions provided in the components and '~ units' may be combined into a smaller number of components and '~ units' or further separated into additional components and '~ units'. In addition, components and '~ units' may be implemented to play one or more CPUs in a device or secure multimedia card.

In the present disclosure, modifiers such as first and second referencing terms may be used to distinguish each term from each other in describing embodiments. Terms modified by modifiers such as the first, second, etc. may refer to different objects. However, terms modified by modifiers such as the first and the second may refer to the same object. That is, modifiers such as first and second may be used to refer to the same object from different viewpoints. For example, modifiers such as 1st, 2nd, etc. may be used to distinguish the same object in terms of a function or an operation. For example, the first user and the second user may refer to the same user.

In addition, in the present disclosure, each embodiment is described by taking the SSP as an example of a secure medium, but the scope of the present disclosure is not limited to that by the SSP. For example, it is apparent to those skilled in the art that various embodiments described below may be applied substantially the same or similarly to other security media that perform substantially the same or similar functions as the SSP.

Specific terms used in the following description are provided to help the understanding of the present disclosure, and the use of these specific terms may be changed to other forms without departing from the technical spirit of the present disclosure.

"SE (Secure Element)" stores security information (eg, mobile communication network access key, user identification information such as ID/passport, credit card information, encryption key, etc.) and controls module (eg, It means a security module composed of a single chip that can mount and operate a 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 provides security services (e.g., mobile communication network access, payment, user authentication, etc.) can provide

SE can be divided into UICC (Universal Integrated Circuit Card), eSE (Embedded Secure Element), and SSP (Smart Secure Platform), which is an integrated form of UICC and eSE. ), embedded, and integrated into a specific device or system on chip (SoC).

A "Universal Integrated Circuit Card (UICC)" is a smart card inserted and used in a mobile communication terminal, and is also called a UICC card. The UICC may include an access control module for accessing a network of a mobile communication service provider. Examples of the access control module include a Universal Subscriber Identity Module (USIM), a Subscriber Identity Module (SIM), and an IP Multimedia Service Identity Module (ISIM). A UICC including a USIM is usually called a USIM card. Similarly, a UICC including a SIM module is commonly referred to as a SIM card. On the other hand, the SIM module may be loaded during UICC manufacturing, or a SIM module of a mobile communication service that a user wants to use at a desired time may be downloaded to the UICC card. In addition, a plurality of SIM modules may be downloaded and installed in the UICC card, and at least one SIM module may be selected and used among them. Such a UICC card may or may not be fixed to the terminal. A UICC fixed and used in a terminal is called an eUICC (embedded UICC), and in particular, a communication processor of the terminal, an application processor, or a System-On-Chip including a single processor structure in which these two processors are integrated. The UICC built into the (SoC) is sometimes referred to as an iUICC (Integrated UICC). In general, eUICC and iUICC refer to a UICC card that is fixedly used in a terminal, remotely downloads at least one SIM module to the UICC card, and includes a function of allowing any one SIM module among the downloaded SIM modules to be selected. can do. In the present disclosure, a UICC card including a function for remotely downloading at least one SIM module and allowing a SIM module to be selected is collectively referred to as an eUICC or an iUICC. That is, a UICC card that is fixed or not fixed to a terminal among UICC cards including a function for remotely downloading a SIM module and allowing a SIM module to be selected is collectively referred to as eUICC or iUICC.

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

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. In addition, when a provisioning profile is pre-loaded in the eUICC, the eUICC identifier (eUICC ID) may be an identifier of the corresponding provisioning profile (Profile ID of Provisioning Profile). Also, in an embodiment of the present disclosure, when the terminal and the eUICC chip are not separated, the eUICC identifier (eUICC ID) may be the terminal ID. In addition, the eUICC identifier (eUICC ID) may refer to a specific secure domain of the eUICC chip.

“Embedded Secure Element (eSE)” refers to a fixed SE that is used by being 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 including an operating system and a framework. An applet-type service control module can be remotely downloaded and installed in the eSE, and the installed service control module can be used for various security services such as e-wallet, ticketing, e-passport, and digital key. In the present disclosure, an SE in the form of a single chip attached to an electronic device, in which a service control module may be remotely downloaded and installed, is collectively referred to as an eSE.

"SSP (Smart Secure Platform)" refers to a single chip capable of integrating the functions of UICC and eSE. SSP can be divided into removable (rSSP, Removable SSP), fixed (eSSP, Embedded SSP), and integrated (iSSP, Integrated SSP) built-in SoC. The SSP may include one primary platform (PP) and at least one secondary platform bundle (SPB) operating on the PP, and the primary platform includes 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. Secondary platform bundles are also called SPBs or bundles. The bundle accesses resources such as the PP's central processing unit and memory through the Primary Platform Interface (PPI) provided by the PP, and can be run on the PP through this. Communication applications such as SIM (Subscriber Identification Module), USIM (Universal SIM), and ISIM (IP Multimedia SIM) can be loaded in the bundle, and various application applications such as electronic wallet, ticketing, e-passport, digital key, etc. can In the present disclosure, the SSP may be referred to as a smart secure medium.

The SSP can be used for the above-mentioned UICC or eSE purpose depending on the bundle to be downloaded and installed, and since a plurality of bundles are installed in a single SSP and operated at the same time, the SSP can be used for a mixed purpose of UICC and eSE. That is, when the bundle including the profile operates, the SSP can be used as a UICC for accessing the network of the mobile communication service provider. In the UICC bundle, at least one or more profiles such as eUICC or iUICC described above may be remotely downloaded into the bundle, and any one or more profiles may be selected. In addition, when a bundle including a service control module loaded with application applications capable of providing services such as electronic wallet, ticketing, e-passport or digital key is operated on the SSP, the SSP can be used for the above-described eSE purpose. A plurality of service control modules may be installed and operated as integrated into one bundle, or may be installed and operated as an independent bundle.

In the SSP, a bundle may be downloaded and installed from an external bundle management server (Secondary Platform Bundle Manager, SPB Manager) using over-the-air (OTA) technology, or a bundle may be transmitted and installed from another terminal. In the present disclosure, the method of installing the downloaded or transmitted bundle is a removable SSP (rSSP) that can be inserted and removed from the terminal, a fixed SSP (eSSP) installed in the terminal, and an integrated SSP (iSSP) included in the SoC installed in the terminal. ) can be applied in the same way.

"SSP identifier (SSP ID)" is a unique identifier of the SSP built into the terminal and may be referred to as sspID. Also, when the terminal and the SSP chip are not separated as in the embodiment of the present disclosure, the SSP ID may be the terminal ID. In addition, the SSP ID may refer to a specific bundle identifier (SPB ID) in the SSP. More specifically, the SSP ID may refer to a bundle identifier of a management bundle or loader (SPBL, Secondary Platform Bundle Loader) that manages installation, activation, deactivation, and deletion of other bundles in the SSP. In addition, the SSP ID may refer to the ID of the primary platform in the SSP (Primary Platform Identifier). The SSP may have a plurality of SSP identifiers, and the plurality of SSP identifiers may be values derived from a single unique SSP identifier.

“Part Number ID” is information connected to the SSP built into the terminal, and using the information, 'manufacturer of the primary platform mounted on the SSP' and 'model information of the primary platform' may be information from which it can be inferred.

"SPB (Secondary Platform Bundle)" is driven by using PP's resources on SSP's Primary Platform (PP). It may mean that values and the operating system (HLOS) in which they operate are packaged in the form of software. In this disclosure, an SPB may be referred to as a bundle.

In the present disclosure, the "state" of a bundle may be as follows.

[enable]

In the present disclosure, the operation of enabling the bundle by the terminal or external server is changing the state of the corresponding SPB to the enabled state, and the terminal provides the service provided by the bundle (eg, communication service, credit It may mean an operation of setting to receive a card payment service, a user authentication service, etc.). An activated bundle may be expressed as an “enabled bundle”. The bundle in the active state may be stored in an encrypted state in a storage space inside or outside the SSP.

[Active]

The bundle activated in the present disclosure is driven according to an external input (eg, user input, push, application request in the terminal, authentication request from a communication operator, PP management message, etc.) or an operation inside the bundle (eg timer, polling) It can be changed to the state (Active). The bundle in the operating state is loaded into the operating memory inside the SSP from the storage space inside or outside the SSP, and the security information is processed using the security control unit (Secure CPU) inside the SSP and the security service is provided to the terminal. It can mean bundle.

[Disabled]

In the present disclosure, the operation of disabling the bundle by the terminal or the external server may mean an operation of changing the state of the bundle to the disabled state and setting the terminal so that the terminal cannot receive the service provided by the bundle. have. The SPB in the deactivated state may be expressed as a “disabled bundle”. Inactive bundles may be stored in an encrypted state in storage space inside or outside the SSP.

[Deleted]

In the present disclosure, the terminal or external server deletes a bundle by changing the state of the bundle to the deleted state or deleting related data of the bundle including the bundle so that the terminal or external server is no longer It may refer to an operation of setting the bundle so that it cannot be driven, activated, or deactivated. A bundle in a deleted state may be expressed as a “deleted bundle”.

"Bundle Image (or Image)" may be used interchangeably with a bundle or as a term referring to a data object of a specific bundle, and includes a bundle TLV (Tag, Length, Value) or bundle image TLV (Bundle Image TLV). ) can be named. If the bundle image is encrypted using encryption parameters, the bundle image can be named as Protected Bundle Image (PBI) or Protected Bundle Image TLV (PBI TLV). When a bundle image is encrypted using an encryption parameter that can only be decrypted by a specific SSP, it may be named as a Bound Bundle Image (BBI) or a Bound Bundle Image TLV (BBI TLV). The bundle image TLV may be a data set expressing information constituting a bundle in a TLV (Tag, Length, Value) format.

"Bundle identifier" is a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), a bundle family manager identifier (SPB Family Custodian Object ID), a bundle Matching ID, an event identifier (Event ID) to be referred to as a matching factor. can The bundle identifier (SPB ID) may indicate a unique identifier of each bundle. The bundle family identifier may indicate an identifier for classifying a type of a bundle (eg, a telecom bundle for accessing a mobile communication company network). In the present disclosure, the bundle family identifier may be referred to as Family ID, Fid, or FID. The bundle family manager identifier may indicate an identifier that identifies a subject (eg, a telecommunication service provider, a terminal manufacturer, a specific organization, etc.) that manages the bundle family identifier. In the present disclosure, the bundle family manager identifier may be referred to as an OID or Oid. The bundle identifier may be used as a value that can index bundles in the bundle management server or terminal.

"Bundle metadata" is a term indicating a set of information that can refer to or describe a bundle. The bundle metadata may include the above-described bundle identifier. In addition, bundle metadata may further include information about properties, characteristics, or settings of the bundle. The bundle metadata may be expressed as "metadata".

"Profile" may mean a data object such as an application, a file system, and an authentication key value stored in the UICC.

In the present disclosure, the "profile package" may mean that the contents of the "profile" are packaged in the form of software that can be installed in the UICC. The 'profile package' may be referred to as a Profile TLV or a Profile Package TLV (Profile Package TLV). When the profile package is encrypted using an encryption parameter, it may be named as a Protected Profile Package (PPP) or a Protected Profile Package TLV (PPP TLV). When the profile package is encrypted using an encryption parameter that can only be decrypted by a specific eUICC, it may be named as a Bound Profile Package (BPP) or a Bound Profile Package TLV (BPP TLV). The profile package TLV may be a data set expressing information constituting a profile in a TLV (Tag, Length, Value) format.

In the present disclosure, a 'profile image' may mean binary data in which a profile package is installed in the UICC. The 'profile image' may be called a Profile TLV or a profile image TLV. When the profile image is encrypted using an encryption parameter, the 'profile image' may be named as a Protected Profile Image (PPI) or a Protected Profile Image TLV (PPI TLV). If the profile image is encrypted using an encryption parameter that can only be decrypted by a specific eUICC, the 'profile image' may be named as a Bound Profile Image (BPI) or a Bound Profile Image TLV (BPI TLV). The profile image TLV may be a data set expressing information constituting a profile in a TLV (Tag, Length, Value) format.

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

[enable]

In the present disclosure, the operation of enabling the profile by the terminal means an operation of changing the state of the corresponding profile to the enabled state and setting the terminal to receive a communication service through the communication service provider that provided the profile can do. An activated profile may be expressed as an “enabled profile”.

[disable]

In the present disclosure, the operation of the terminal disabling the profile means the operation of changing the state of the corresponding profile to the disabled state and setting the terminal not to receive a communication service through the communication service provider that provided the profile can do. The profile in the inactive state may be expressed as a “disabled profile”.

[delete]

In the present disclosure, the operation of the terminal to delete a profile may mean an operation of changing the state of the corresponding profile to the deleted state and setting the terminal to no longer enable or disable the corresponding profile. A profile in a deleted state may be expressed as a “deleted profile”.

In the present disclosure, the operation of the terminal to enable, disable, or delete a profile is performed by setting the state of each profile to an enabled state, a disabled state, or a deleted state (deleted). Rather than changing immediately, each profile is first marked as to be enabled, to be disabled, or to be deleted, and the terminal or the UICC of the terminal is After performing a specific operation (for example, performing a refresh (REFRESH) or reset (RESET) command), each profile is changed to an enabled state, a disabled state, or a deleted state. It can also mean action. The operation of marking a specific profile as intended (i.e., to be enabled, to be disabled, or to be deleted) must be done only once per profile. It is not limited to indicating the expected status of one or more profiles, each with the same or different predetermined status, a single profile with one or more predetermined statuses, or one or more profiles with one or more respective same or different predetermined statuses. It is also possible to display the status.

In addition, when the terminal displays one or more predetermined statuses for an arbitrary profile, the two predetermined status indications may be integrated into one. For example, if a certain profile is marked as to be disabled and to be deleted, the profile may also be combined to be marked as disabled and deleted.

Also, the operation of the terminal indicating the scheduled status for one or more profiles may be performed sequentially or simultaneously. In addition, the operation of the terminal displaying the scheduled state for one or more profiles and then changing the actual profile state may be performed sequentially or simultaneously.

"Profile Identifier" means Profile ID, ICCID (Integrated Circuit Card ID), Matching ID, Event ID, Activation Code, Activation Code Token, Command Code), Command Code Token, Signed Command Code, Unsigned Command Code, ISD-P, or Profile Domain (PD) as an argument matching may be referred to. The profile identifier (Profile ID) may indicate a unique identifier of each profile. The profile identifier may further include the address of the profile providing server (SM-DP+) that can index the profile. In addition, the profile identifier may further include a signature of the profile providing server (SM-DP+).

"Bundle management server" means creating a bundle by a request from a service provider or other bundle management server, encrypting the created bundle, generating a bundle remote management command, or encrypting the created bundle remote management command. function may be included. The bundle management server that provides the above functions is 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), Administrator Bundle Server, Managing SM-DP+ (Managing Subscription Manager Data Preparation plus), Bundle Encryption Server, Bundle Creation Server, Bundle Provisioner (BP), Bundle Provider (Bundle Provider), BPC holder (Bundle Provisioning Credentials) holder) can be expressed as at least one of

In the present disclosure, the bundle management server downloads, installs, or updates bundles from the SSP and manages settings of keys and certificates for remote management of the bundle status. The bundle management server that provides the above functions is SPBM (Secondary Platform Bundle Manager), RBM (Remote Bundle Manager), IDS (Image Delivery Server), SM-SR (Subscription Manager Secure Routing), SM-SR+ (Subscription Manager Secure Routing) Plus), off-card entity of eUICC Profile Manager or PMC holder (Profile Management Credentials holder), and EM (eUICC Manager) may be expressed as at least one.

In the present disclosure, the opening mediation server may receive an event registration request (Register Event Request, Event Register Request) from one or more bundle management servers or opening mediation servers. In addition, one or more opening mediation servers may be used in combination. In this case, the first opening mediation server may receive an event registration request from the second opening mediation server as well as the bundle management server. In the present disclosure, the function of the opening mediation server may be integrated into the bundle management server. The opening intermediary server that provides the above functions is SPBM (Secondary Platform Bundle Manager), RBM (Remote Bundle Manager), SPBDS (Secondary Platform Bundle Discovery Sever), BDS (Bundle Discovery Sever), SM-DS (Subscription Manager Discovery Service) , DS (Discovery Service), Root SM-DS, and Alternative SM-DS.

In the present disclosure, the bundle management server may refer to a server that performs both a function of generating, encrypting, and transmitting a bundle or a bundle remote management command, and a function of setting an SSP and managing an installed bundle. In addition, the bundle management server may refer to a server capable of further performing the function of an opening intermediary server. Therefore, in various embodiments of the present disclosure, the operations of the bundle management server and the opening intermediary server may be performed in one bundle management server. In addition, each function may be divided and performed by a plurality of bundle management servers separated from each other. In addition, in the specification of the present disclosure, the bundle management server or the opening mediation server may be expressed as a bundle server. The bundle server may be one of the bundle management server and the opening mediation server, and may be a device including both the functions or configuration of the bundle management server and the opening mediation server.

“RSP Server (Remote SIM Provisioning Server)” may be used as a name for a profile providing server and/or a profile management server and/or an opening intermediary server to be described later. The RSP server may be expressed as SM-XX (Subscription Manager XX).

In the present disclosure, the "profile providing server" may include a function of creating a profile, encrypting a generated profile, generating a profile remote management command, or encrypting a generated profile remote management command. Profile providing server, 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) , a Profile Provider, and a PPC holder (Profile Provisioning Credentials holder).

In the present disclosure, "profile management server" may include a function for managing a profile. The profile management server includes SM-SR (Subscription Manager Secure Routing), SM-SR+ (Subscription Manager Secure Routing Plus), off-card entity of It can be expressed as eUICC Profile Manager or PMC holder (Profile Management Credentials holder), EM (eUICC Manager), PP (Profile Manager), and the like.

In the present disclosure, the profile providing server may mean a combination of the functions of the profile management server. Accordingly, in various embodiments of the present disclosure, the operation of the profile providing server may be performed by the profile management server. Similarly, the operation of the profile management server or SM-SR may be performed in the profile providing server.

In the present disclosure, an "opening brokerage server" may be expressed as a Subscription Manager Discovery Service (SM-DS), a Discovery Service (DS), a Root SM-DS, and an Alternative SM-DS. have. The opening mediation server may receive an event registration request (Register Event Request, Event Register Request) from one or more profile providing servers or opening mediation servers. In addition, one or more opening mediation servers may be used in combination. In this case, the first opening mediation server may receive an event registration request from the second opening mediation server as well as the profile providing server.

"Service provider" may refer to a business that issues a requirement to a bundle management server to request bundle creation, and provides a service to a terminal through the bundle. For example, a service provider may mean a mobile operator that provides a communication network access service through a bundle loaded with a communication application, and includes a business support system (BSS), an operation support system of the communication service provider. (Operational Supporting System, OSS), POS terminal (Point of Sale Terminal), and other IT systems may be collectively referred to. In addition, in the present disclosure, the service provider is not limited to expressing only one specific business, and may be used as a term referring to a group or association (association or consortium) of one or more businesses or an agent representing the group or association. . In addition, in the present disclosure, a service provider may be named as an operator (Operator or OP or Op.), bundle owner (BO), image owner (IO), etc., and each service provider has a name and/or At least one unique identifier (Object Identifier, OID) may be set or assigned. If a service provider refers to a group or association or agency of more than one entity, the name or unique identifier of any group or association or agency shall be shared by all entities belonging to that group or association or all entities collaborating with such entity. It can be a name or a unique identifier.

A "mobile operator" may refer to a business that provides a communication service to a terminal, and includes a business supporting system (BSS), operational supporting system (OSS), POS terminal ( point of sale terminal), and other IT systems. In addition, in the present disclosure, the telecommunication service provider is not limited to expressing only one specific business entity that provides communication services, and a group or association (association or consortium) of one or more businesses or a term referring to an agency representing the group or association may be used as In addition, in the present disclosure, a telecommunication operator is an operator (operator or OP or Op.), a mobile network operator (MNO), a mobile virtual network operator (MVNO), a service provider (SP), It may be named as a profile owner (PO), etc., and each carrier may set or be assigned at least one name and/or an object identifier (OID) of the carrier. If a telecommunications carrier refers to a group or association or agency of one or more entities, the name or unique identifier of any group or association or agency is shared by all entities affiliated with that group or association or all entities working with such entity. It can be a name or a unique identifier.

"Subscriber" may be used as a term referring to a service provider having ownership of the terminal or an end user having ownership of the terminal. In general, a terminal owned by a service provider may be referred to as an M2M device, and a terminal owned by a user may be referred to as a consumer device. In the case of an M2M terminal, although it does not have ownership of the terminal, an end user may exist who transfers or leases the terminal from a service provider, and in this case, the subscriber may be different from or the same as the service provider.

"Subscriber intent" may be used as a generic term for the intention of the subscriber to manage the bundle locally or remotely. In addition, in the case of local management, the subscriber intent refers to an end user intent, and in the case of remote management, the subscriber intent may be used as a term referring to a service provider intent.

"End User consent" may be used as a term indicating whether the user agrees to perform local management or remote management.

'Terminal' means a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, subscriber unit (Subscriber Unit), subscriber station (SS; Subscriber Station), wireless device, wireless communication device, wireless transmit/receive unit (WTRU), mobile node, mobile, or other terms. Various embodiments of the terminal include a cellular phone, a smart phone having a wireless communication function, a personal digital assistant (PDA) having a wireless communication function, a wireless modem, a portable computer having a wireless communication function, and a digital camera having a wireless communication function. devices, gaming devices with wireless communication capabilities, music storage and playback appliances with wireless communication capabilities, Internet home appliances capable of wireless Internet access and browsing, as well as portable units or terminals incorporating combinations of such functions. have. In addition, the terminal may include a machine to machine (M2M) terminal and a machine type communication (MTC) terminal/device, but is not limited thereto. In the present disclosure, a terminal may be referred to as an electronic device.

In the present disclosure, an SSP capable of downloading and installing a bundle may be embedded in the electronic device. When the SSP is not embedded in the electronic device, the SSP 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 including an SSP capable of downloading and installing a bundle. The SSP may not only be embedded in the terminal, but may 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.

In the present disclosure, a UICC that can be installed by downloading a profile may be embedded in the electronic device. When the UICC is not embedded in the electronic device, the UICC physically separated from the electronic device may be inserted into the electronic device and connected to the electronic device. For example, the UICC in the form of a card may be inserted into the electronic device. The electronic device may include a terminal, and in this case, the terminal may be a terminal including a UICC that can be installed by downloading a profile. The UICC may be embedded in the terminal, and when the terminal and the UICC are separated, the UICC may be inserted into the terminal, and 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 as eUICC, for example.

“Local Bundle Assistant (LBA)” may refer to software or an application installed in a terminal or electronic device to control the SSP. The above-described software or application may be referred to as a Local Bundle Manager (LBM).

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

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

“Event” may be used in the present disclosure for the following purposes.

[When used in conjunction with a bundle]

“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 as a remote bundle provisioning operation (Remote Bundle Provisioning Operation, or RBP operation, or RBP operation) or an event record, and each event is a corresponding event identifier (Event Identifier) , Event ID, EventID) or matching identifier (Matching Identifier, Matching ID, MatchingID), and the address (FQDN, IP Address, or URL) of the bundle management server or opening intermediary server where the event is stored, or each server identifier at least one or more It can be identified by the data it contains. Bundle Download may be used interchangeably with Bundle Installation. In addition, Event Type is a term indicating whether a specific event is a bundle download, remote bundle management (eg, delete, activate, deactivate, replace, update, etc.), or other management/processing commands of the bundle or SSP. can be used In addition, the event type includes an operation type (Operation Type or OperationType), an operation classification (Operation Class or OperationClass), an event request type (Event Request Type), an event classification (Event Class), and an event request class (Event Request Class). ) can be named.

"Local Bundle Management (LBM)" means Bundle Local Management, Local Management, Local Management Command, Local Command, Local Bundle Management Package ( LBM Package), a bundle local management package (Bundle Local Management Package), a local management package (Local Management Package), a local management command package (Local Management Command Package), the local command package (Local Command Package) and the like may be named. LBM installs an arbitrary bundle through software installed in the terminal, changes the status of a specific bundle (Enabled, Disabled, Deleted), or changes the contents of a specific bundle (eg, a bundle nickname) , or bundle summary information (Bundle Metadata, etc.) may be used for updating. The LBM may include one or more local management commands, and the target bundle for each local management command may be the same or different for each local management command.

"Remote Bundle Management (RBM)" refers to Bundle Remote Management, Remote Management, Remote Management Command, Remote Command, Remote Bundle Management Package ( RBM Package), bundled remote management package (Bundle Remote Management Package), remote management package (Remote Management Package), remote management command package (Remote Management Command Package), remote command package (Remote Command Package), etc. may be named. RBM installs any bundle, changes the status of a specific bundle (Enabled, Disabled, Deleted), or changes the contents of a specific bundle (eg, a bundle nickname (Bundle Nickname), or bundle summary information (Bundle). Metadata), etc.) can be used for updating. The RBM may include one or more remote management commands, and the bundles targeted for each remote management command may be the same or different for each remote management command.

“Target bundle” may be used as a term referring to a bundle that is a target of a local management command or a remote management command.

"Bundle Rule" may be used as a term referring to information that the terminal should check when performing local management or remote management for a target bundle. Also, the bundle rule may be used interchangeably with terms such as a bundle policy, a rule, and a policy.

[When used in connection with a profile]

"Event" may be a generic term for a profile download (Profile Download), remote profile management (Remote Profile Management), or other management/processing commands of a profile or eUICC. The event (Event) may be named as a remote SIM provisioning operation (Remote SIM Provisioning Operation, or RSP operation, or RSP operation) or an event record, and each event (Event) corresponds to an event identifier (Event Identifier) , Event ID, EventID) or matching identifier (Matching Identifier, Matching ID, MatchingID) and the address (FQDN, IP Address, or URL), the signature of the profile providing server (SM-DP+) or the opening mediation server (SM-DS), and at least one digital certificate of the profile providing server (SM-DP+) or the opening mediation server (SM-DS) It can be referred to as data that

Data corresponding to an event may be referred to as a “command code”. Part or all of the procedure using the command code may be referred to as a “command code processing procedure” or “command code procedure” or “LPA API (Local Profile Assistant Application Programming Interface)”. Profile Download may be mixed with Profile Installation.

Also, "Event Type" is a term used to indicate whether a particular event is a profile download, remote profile management (eg, delete, enable, disable, replace, update, etc.) or other profile or eUICC management/processing command. It can be used and may be named as an operation type (Operation Type or OperationType), operation classification (Operation Class or OperationClass), event request type (Event Request Type), event class (Event Class), event request class (Event Request Class), etc. can As for an arbitrary event identifier (EventID or MatchingID), a path or usage purpose (EventID Source or MatchingID Source) from which the terminal obtained the corresponding event identifier (EventID or MatchingID) may be designated.

"Local Profile Management (LPM)" means Profile Local Management, Local Management, Local Management Command, Local Command, Local Profile Management Package ( LPM Package), Profile Local Management Package, LOCAL MANAGEMENT PACKAGE, Local Management Command Package, Local Command Package, etc. may be named. LPM changes the status (Enabled, Disabled, Deleted) of a specific profile through software installed in the terminal, or the contents of a specific profile (eg, a profile nickname (Profile Nickname), or profile summary information (Profile Metadata), etc.) ) can be used for updating. The LPM may include one or more local management commands. In this case, the target profile of each local management command may be the same or different for each local management command.

"Remote Profile Management (RPM)" refers to Profile Remote Management, Remote Management, Remote Management Command, Remote Command, Remote Profile Management package ( RPM Package), Profile Remote Management Package, Remote Management Package, Remote Management Command Package, Remote Command Package, and the like. RPM changes the status (Enabled, Disabled, Deleted) of a specific profile, or changes (updates) the contents of a specific profile (eg, a profile nickname (Profile Nickname), or profile summary information (Profile Metadata), etc.) can be used for The RPM may include one or more remote management commands. In this case, the target profile of each remote management command may be the same or different for each remote management command.

A "Certificate" or Digital Certificate is a mutual authentication based on an asymmetric key consisting of a public key (PK) and a secret key (SK) pair. It can represent a digital certificate used for Each certificate includes one or more public keys (PK), a public key identifier (PKID) corresponding to each public key, and an identifier (Certificate) of the certificate issuer (CI) that issued the corresponding certificate. Issuer ID) and digital signature. Also, the certificate issuer may be called a certification issuer, a certificate authority (CA), a certification authority, and the like. In the present disclosure, a public key (PK) and a public key identifier (PKID) are a specific public key or a certificate including the corresponding public key, or a part of a specific public key or a certificate including the corresponding public key. A part, or a result of an operation of a specific public key (eg, Hash), or a result of an operation (eg, Hash) of a certificate including the corresponding public key (eg, Hash), or a portion of a specific public key As a meaning that refers to an operation result (eg, hash) value, an operation result (eg, hash) value of a part of a certificate including a corresponding public key, or a storage space in which data is stored. can be used

A "Certificate Chain" or Certificate Hierarchy is used for certificates issued by a "Certificate Issuer" (a primary certificate) to issue other certificates (a secondary certificate), or 2 When secondary certificates are used to jointly issue certificates of tertiary or higher levels, the correlation between the corresponding certificates may be indicated. At this time, the CI certificate used for the initial certificate issuance is the Root of Certificate, the top level certificate, the root CI, the root CI certificate, the root CA (Root CA), the root CA certificate (Root CA) Certificate) and the like.

And, in describing the present disclosure, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present disclosure, the detailed description thereof will be omitted.

Hereinafter, various embodiments of a method and an apparatus for moving and installing a bundle between terminals will be described.

1 shows a conceptual diagram of an SSP according to an embodiment of the present disclosure.

Referring to FIG. 1 , according to an 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 in which the two processors are integrated. For another example, the SSP 120 may be a removable type 122 in the form of an independent chip without being integrated into the SoC, or may be a built-in type 124 pre-built in the terminal 110 .

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 ID bundles. For example, as shown in FIG. 1 , when a plurality of telecom bundles 140 and 150 are included in the SSP 120 , the terminal 110 simultaneously transmits the plurality of telecom bundles 140 and 150 according to a setting. Alternatively, it is possible to use a mobile communication network by operating in time division. In addition, when the payment bundle 170 and the electronic ID bundle 180 are included in the SSP 120 , the terminal 110 uses the payment bundle 170 to make online payment through a terminal app or an external credit card PoS (Point of Sale), offline payment through the device may be used, and the identity of the terminal owner may be authenticated using the electronic ID bundle 180 .

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

Referring to FIG. 2 , according to an embodiment of the present disclosure, the SSP 210 includes one primary platform (PP) 220 and at least one secondary platform bundle operating thereon (Secondary Platform Bundle, SPB) (230, 240) may be included.

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

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

According to various embodiments, each of the secondary platform bundles 230 and 240 uses a primary platform interface (PPI) 250 to access resources such as the central processing unit and memory of the primary platform 220 . and may be driven in the SSP 210 through this.

3 is a diagram illustrating an example of components in a terminal used for a terminal to download and install a bundle to an SSP according to an embodiment of the present disclosure.

Referring to FIG. 3 , according to an 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 in which the SSP 330 is mounted and the LBA 312 for controlling the SSP 330 is installed. For example, the SSP 330 may be embedded in the terminal 310 or may be removable.

According to various embodiments, the SSP 330 is 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 . may contain one.

According to various embodiments, the secondary platform bundle 335 , 337 , or 339 is not installed in the SSP 330 at the time of shipment of the terminal, but may be downloaded and installed remotely after shipment.

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

4 is a diagram illustrating an example of a method in which two terminals and a server mutually operate in order to perform online transmission of a bundle from one terminal to another terminal according to an embodiment of the present disclosure.

Referring to FIG. 4 , in an embodiment of the present disclosure, the terminal may include at least one LBA and at least one SSP. For example, the first terminal 400 includes a first LBA 410 and a first SSP 420 , and the second terminal 450 includes a second LBA 460 and a second SSP 470 . can do.

According to various embodiments, in operation 4020 and operation 4070 , the first/second LBAs 410 and 460 give a command to the first/second SSPs 420 and 470 or the first/second SSP 420 , 470) and data can be transmitted and received. In addition, in operations 4030 and 4080 , the first/second SSPs 420 and 470 may generate, process, or verify necessary data inside the first and second SSPs 420 and 470 .

According to various embodiments, in operation 4050 (hereinafter, operation 3 ), the first and second LBAs 410 and 460 may be connected to each other to give a command to or transmit/receive data to and from the counterpart. In the third operation, the connection of 4050 may be a direct device-to-device connection between the first terminal 400 and the second terminal 450 , and although not shown, the connection between the first LBA 410 and the second LBA 460 . It may be an indirect device-to-device connection in which an external entity (eg, an external server) is connected to the . A more detailed description of a connection method between the first LBA 410 and the second LBA 460 will be described with reference to the drawings described below.

According to various embodiments, the user may send a command to the terminal or receive information to be provided by the user from the terminal. For example, as in operations 4010 and 4060, the first/second users 440 and 490 give commands to the first/second LBAs 410 and 460 of the first/second terminals 400 and 450. or may receive information to be provided by the user from the first/second LBAs 410 and 460 . The first user 440 and the second user 490 may refer to different users or may refer to the same single user.

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

Although the figure shows an example in which the first bundle management server 430 and the second bundle management server 480 directly transmit and receive messages, according to an embodiment, another one or more bundle management servers are located between the two bundle management servers. there may be For example, although not shown in the drawing, a third bundle management server exists between the first bundle management server and the second bundle management server, so that the first/second bundle management server sends a message to the second/first bundle management server. , the first/second bundle management server may send a message to the third bundle management server, and the third bundle management server may transmit this message to the second/first bundle management server. In a similar manner, a plurality of bundle management servers and/or relay servers may exist between the first bundle management server and the second bundle management server.

In the present disclosure, for convenience of technology, all of one or more bundle management servers may be referred to as one bundle management server. For example, in the drawing, the first bundle management server 430 and the second bundle management server 480 may be bundled together and referred to as a bundle management server. In this case, for example, an operation in which the first terminal transmits/receives a message to/from the second terminal via the first bundle management server and the second bundle management server is an operation in which the first terminal transmits/receives a message to/from the second terminal via the bundle management server can be described as Even when one or more bundle management servers exist between the first bundle management server and the second bundle management server, as described above, these bundle management servers may be collectively referred to as a bundle management server.

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.

Referring to FIG. 5 , the UE may include at least one LBA and at least one SSP. For example, the first terminal 510 includes a first LBA 530 and a first SSP 520 , and the second terminal 560 includes a second LBA 580 and a second SSP 570 . can do. A description of the bundle management server will be referred to FIG. 4 .

In 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.

In step 5005 , the first terminal 510 may upload a 'bundle to be transmitted to the second terminal' to the bundle management server 550 . For a more detailed description of the procedure, refer to the detailed description of FIG. 7 to be described later.

In step 5010 , the second terminal 560 may 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.

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

Referring to FIG. 6 , the UE may include at least one LBA and at least one SSP. For example, the first terminal 610 includes a first LBA 630 and a first SSP 620 , and the second terminal 660 includes a second LBA 680 and a second SSP 670 . can do.

According to various embodiments, the first terminal 610 may have a pre-installed bundle, and may further retain metadata associated with the pre-installed bundle.

According to various embodiments, the first terminal 610 includes at least one of a bundle identifier (SPB ID) related to a pre-installed bundle, a bundle family identifier (SPB Family ID), or a bundle family manager identifier (SPB Family Custodian Object ID). may hold

According to various embodiments, the first terminal 610 may have a 'bundle movement setting' related to a pre-installed bundle.

'Bundle movement setting' is information on whether the bundle can be moved between devices, and may have been created by the service provider that is the first provider of the bundle, the bundle management server, or the aforementioned service provider and bundle management. It may have been created by the collaboration of the server. The 'bundle movement settings' may be updated by the service provider, the bundle management server, or the collaboration between the service provider and the bundle management server. Alternatively, at least one subject of the service provider and the bundle management server and the terminal may collaborate to update the 'bundle movement setting'. The update time and/or method may be determined by policies of a service provider, a bundle management server, a terminal manufacturer, and the like.

The 'bundle movement setting' may optionally include a factor (or an indication) indicating whether transmission of the corresponding bundle between devices is permitted. In addition, this 'bundle movement setting' may optionally further include a factor specifying under what conditions transmission is permitted when transmission between devices of the corresponding bundle is allowed. For example, a factor indicating whether online transmission between devices of the corresponding bundle is permitted may be included.

Referring to FIG. 6 , in step 6000 , the first LBA 630 may acquire information on a bundle to be transmitted between devices. Alternatively, information on a bundle to be transmitted between devices may be transmitted to the first LBA 630 . For example, the first LBA 630 may obtain information of a bundle to be transmitted by receiving a user input for selecting a bundle through a user interface (UI) provided by the user first terminal 610 , Information of the bundle to be transmitted from the server through a push input may be input to the first LBA 630 , or the first LBA 630 may access the remote server and read information of the bundle to be transmitted.

In step 6002 , the first LBA 630 may check whether the bundle can be transmitted between devices by using the 'bundle movement setting'. Also, the first LBA 630 may check 'bundle movement setting' to determine whether online transmission of the bundle is possible between devices.

In step 6004, the first LBA 630 may generate a 'bundle transmission code'. The bundle transmission code may include a bundle identifier such as a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), and a bundle family manager identifier (SPB Family Custodian Object ID) of a bundle to be transmitted. Also, the bundle transmission information may further include other information indicating the properties of the bundle (eg, metadata of the bundle or a part of the metadata). Also, 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 performed in step 6010 . For example, information necessary for the wi-fi connection of the two terminals (eg, the SSID and/or BSSID of the first terminal 610 , the Pre Shared Key to be used for connection authentication between the two terminals, the IP address of the first terminal, the information of the two terminals port number to be used for communication).

In addition, the bundle transmission code may include information on encryption algorithms supported by the first terminal (eg, the first SSP) (Supported Crypto Info). The information on encryption algorithms supported by the first terminal may optionally include one or more of the following information: an elliptic curve curve list supported by the first terminal, a key agreement algorithm list supported by the first terminal, and the first terminal List of supported encryption algorithms.

Although the first LBA 630 is described to confirm the 'bundle movement setting' in this figure, this process may be replaced with the following process: the first LBA 630 to transmit to the first SSP 620 . transmits information (eg, bundle identifier) of the bundle to be used, the first SSP 620 confirms the 'bundle movement setting' of the bundle corresponding to the received bundle identifier, and the first SSP 620 sends the first LBA ( 630) to transmit the confirmation result.

Although it is described that the first LBA 630 generates a 'bundle transmission code' in this figure, this process may be replaced with the following process: The first LBA 630 sends a 'bundle' to the first SSP 620 . Requests information required for 'transmission code', the first SSP 620 transmits the requested information to the first LBA 630, and the first LBA 630 configures a 'bundle transmission code' based on this information can do.

Referring to FIG. 6 , in step 6005 , the bundle transmission code generated in step 6004 may be transmitted from the first LBA 630 to the second LBA 680 . The bundle transmission code may be transmitted in a variety of ways.

For example, the first LBA 630 may 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 may provide the received information to the second user of the second terminal 660 . The second user may input the provided information into the second LBA 680 using the UI of the second terminal 6620 .

Alternatively, the first LBA 630 creates information to be transmitted to the second LBA 680 in the form of an image (eg, a QR code) and displays it on the screen of the first terminal 610 , and the second user Information may be transmitted to the second LBA 680 by scanning the image displayed on the screen of the first terminal 610 using the second terminal 660 .

Referring to FIG. 6 , in step 6010 , a connection may be established (or established) 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 the bundle transmission code. The connection between the first LBA 630 and the second LBA 680 may be a direct device-to-device connection (eg, NFC, Bluetooth, UWB, WiFi-Direct, LTE device-to-device (D2D), 5G D2D) or It may be a remote connection in which a remote server (eg, a relay server) is located between the first LBA 630 and the second LBA 680 .

In this figure, it is drawn that step 6005 is performed first, followed by step 6010, 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 the bundle from the first LBA 630 to the second LBA 680 through the established connection. A transmission code may be transmitted (corresponding to step 6005).

Referring to FIG. 6 , in step 6015 , the second LBA 680 may transmit some and/or all information of the received bundle transmission code to the second SSP 670 .

Referring to FIG. 6 , in step 6020 , the second SSP 670 checks the received “encryption algorithms supported by the first terminal” to see if there are encryption algorithms supported by the second terminal (eg, the second SSP) among them. can be checked If there are encryption algorithms supported by the second terminal among the received "encryption algorithms supported by the first terminal", one of them may 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 agreement algorithm information, and encryption algorithm information.

The second SSP 670 is a key pair (temporary public key ssp2. ePK.BT and its corresponding secret key ssp2.eSK.BT) can be created. The second SSP 670 may map the generated key pair to the received bundle identifier (SPB ID). The second SSP 670 may generate “selected encryption information (ssp2.SelectedCryptoInfo)”. “Selected encryption information” may optionally include one or more of the following information: a part and/or all of the selected encryption algorithm, ssp2.eEPK.BT

In step 6020, the second SSP 670 is information that can be used to determine whether to receive and install a bundle to be transmitted by the first terminal 610 from the RSP server (commonly referred to as a conformance package or ssp2.EligibilityPackage). can create

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 corresponding 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, certificate information that can be used by the second SSP to verify the RSP server, and a second Information on key agreement algorithms supported by the SSP, and information on encryption algorithms supported by the second SSP.

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

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

Referring to FIG. 6 , in step 6025 , the second SSP 670 may transmit ReceiverInfo to the first LBA 630 via the second LBA 680 .

7 is a diagram illustrating a procedure in which a terminal to transmit a bundle uploads a bundle to be transmitted to a server among the procedures shown in FIG. 5 according to an embodiment of the present disclosure.

Referring to FIG. 7 , the UE may include at least one LBA and at least one SSP. For example, the first terminal 710 includes a first LBA 730 and a first SSP 720 , and the second terminal 760 includes a second LBA 780 and a second SSP 770 . can do. A description of the bundle management server will be referred to FIG. 4 .

Referring to FIG. 7 , in step 7000 , the first LBA 730 may request “SSP information (SspInfo)” from the first SSP 720 .

When the first LBA 730 requests “SSP information (SspInfo)” from the first SSP 720 , the first LBA 730 may inform the first SSP 720 that the inter-device bundle movement is to be performed. When the first LBA 730 requests “SSP information (SspInfo)” from the first SSP 720 , the first LBA 730 may further inform the first SSP 720 that the inter-device online bundle movement is to be performed. For example, the request message may include an indicator indicating that the bundle movement between devices will be performed. As another example, the request message may include an indicator indicating that the online bundle movement between devices will be performed. The request message may include an indicator, or the value of the indicator may be set to 1 to inform the first SSP 720 that the inter-device bundle movement will be performed or that the inter-device online bundle movement will be performed.

The first LBA 730 may provide information on 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).

In addition, step 7000 may be automatically performed immediately following the entire process described with reference to FIG. 6 , or may be performed after receiving an external input. In this case, the 'external input' may be a user input input by the first user of the first terminal 710 through the UI provided by the first terminal 710, and input from the remote server to the first LBA 730 It may be a push input that becomes In addition, step 7000 may be initiated by the first LBA 730 accessing the remote server.

Referring to FIG. 7 , in step 7005 , the first SSP 720 generates its own "SSP information (ssp1.SspInfo)" and sends the "SSP" to the bundle management server (SPBM, 750) through the first LBA 730. information" can be transmitted.

"SSP information" may include information on the first SSP 720 to be provided for bundle transmission. In this case, "SSP information" may include information (certificate negotiation information) for a certificate negotiation process that the first SSP 720 must go through to communicate with the bundle management server. "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. can Also, the “certificate negotiation information” may further include a list of key agreement algorithms supported by the first SSP 720 , and may further include a list of encryption algorithms supported by the first SSP 720 .

Also, "SSP information" may further include SSP version information including version information of at least one of the version information of the standard standard supported by the primary platform and the loader included in the first SSP 720 .

In an embodiment, the first SSP 720 may transmit "SSP information" to the bundle management server 750 via the first LBA 730 .

According to steps 7000 to 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 The SSP 720 may transmit "SSP information" to the bundle management server 750 via the first LBA 730 . However, according to an embodiment, the first LBA 730 may transmit "SSP information" to the bundle management server 750 after generating "SSP information" by itself.

Referring to FIG. 7 , in step 7010, the bundle management server 750 checks the received “SSP information”, generates “server authentication information (SPBM.Auth1)” based on this information, and sends it to the first LBA 730 . "Server authentication information" can be transmitted.

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

a) A certificate for key agreement (referred to as SPBM.Cert.KA) that can be used to verify SPBM itself and the certificates required to verify this certificate.

b) Certificate information to be used by the SPBM to verify the first SSP (referred to as CiPkIdToBeUsed)

c) Information of the encryption algorithm to be used by the SPBM when performing encrypted communication with the first SSP (referred to as CryptoToBeUsed)

In an embodiment, the bundle management server 750 may transmit “server authentication information” to the first LBA 730 .

Referring to FIG. 7 , in step 7015 , the first LBA 730 may transmit “server authentication information” to the first SSP 720 . Also, the first LBA 730 may further transmit a “bundle identifier of a bundle to be transmitted” to the first SSP 720 .

In one embodiment, the first SSP 720 may execute one or more of the following tasks.

a) You can check the validity of the received “SPBM.Cert.KA”.

b) At least one signature certificate (ssp1.Cert.DS) capable of verifying the first SSP may be selected based on the received "CiPkIdToBeUsed".

c) The public key "ssp1.ePK.KA" and the private key "ssp1.eSK.KA" which are the key pair for encryption to be used to confirm the received "CryptoToBeUsed" and to create an encryption key for encrypted communication with the bundle management server. can create In addition, the first SSP 720 may generate ShKeyM1, which is a session key to be used for encrypted communication with the bundle management server 750, using the public key for key agreement and ssp1.eSK.KA included in SPBM.Cert.KA. have.

In step 7020 , the first SSP 720 may 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.

a) ssp1.Cert.DS

b) ssp1.ePK.KA

c) A transaction ID that refers to the current session.

d) SSP identifier of the first SSP 720

e) The bundle delimiter of the bundle you want to transfer.

A part or all of "first terminal 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 digital signature data is "first terminal" It can be added as part of "authentication information".

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

In an embodiment, the first SSP 720 may transmit "first terminal authentication information (Device1.Auth)" to the first LBA 730 .

Referring to FIG. 7 , in step 7025 , the first LBA 730 may transmit “first terminal authentication information” to the bundle management server 750 . The first LBA 730 may further transmit ssp2.EligibilityPackage to the bundle management server 750 . For a description of ssp2.EligibilityPackage, refer to FIG. 6 . The first LBA 730 may further transmit a “bundle identifier of a bundle to be transmitted” to the bundle management server 750 .

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

a) The bundle management server may verify the validity of ssp1.Cert.DS included in the “first terminal authentication information”. In addition, the bundle management server may verify the validity of the signature using ssp1.Cert.DS when the electronic signature is included in the “first terminal authentication information”.

b) The bundle management server uses the 'private key corresponding to the public key for key agreement included in SPBM.Cert.KA' and ssp1.ePK.KA when there is encrypted data in the “1st terminal authentication information” Thus, it is possible to generate ShKeyM1, which is a session key to be used for encrypted communication with the first terminal, and decrypt the encrypted data using this session key.

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

d) The bundle management server may check and/or store the bundle identifier of the bundle to be transmitted by the first terminal.

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

a) The bundle management server can use the 'SSP identifier of the first SSP' and the 'bundle identifier of the bundle that the first terminal wants to transmit' to check that the first terminal (eg, the first SSP) is currently a legitimate user of the bundle. have.

b) The bundle management server may check whether the bundle to be transmitted by the first terminal is a bundle capable of online transmission.

c) The bundle management server may check ssp2.EligibilityPackage to verify at least one of the following: whether the certificate negotiation with the second terminal is successful or not, the bundle that the first terminal wants to transmit is the second terminal (eg, the second terminal) SSP) is installed and/or operated normally.

In step 7030 , the bundle management server 750 may generate a bundle request message (referred to as spbRequest) to the first terminal 710 , and the bundle management server may transmit an spbRequest to the first LBA. spbRequest may include one or more of the following information.

a) SSP identifier of the first SSP

b) SSP identifier of the second SSP

c) Bundle identifier of the bundle that the first terminal wants to transmit

d) transaction ID

Some and/or all of the information contained in spbReqeust may be encrypted using ShKeyM1, which may be included as part of spbRequest.

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

In one embodiment, the bundle management server may send an spbRequest to the first LBA.

Referring to FIG. 7 , in step 7035 , the first LBA 730 may transmit an spbRequest to the first SSP 720 . In step 7035 , the first LBA 730 may further transmit ssp2.SelectedCryptoInfo to the first SSP 720 . For a description of ssp2.SelectedCryptoInfo, refer to FIG. 6 .

In an embodiment, the first SSP 720 may perform one or more of the following processes.

a) If the spbRequest contains encrypted information, it is decrypted using ShKeyM1.

b) If the spbRequest contains a digital signature value, it is verified using SPBM.Cert.DS

c) Verifies that the SSP identifier of the first SSP and/or the SSP identifier of the second SSP and/or the bundle identifier and/or transaction ID of the bundle that the first terminal intends to transmit included in the spbRequest are correct values

The first SSP 720 may check information included in ssp2.SelectedCryptoInfo.

The first SSP 720 may set a public key “ssp1.ePK.BT” and a private key “ssp1.eSK.BT” that are key pairs for encryption. This value may be the same as the values of “ssp1.ePK.KA” and “ssp1.esk.KA” according to an embodiment.

According to an embodiment, the first SSP 720 uses the generated ssp1.eSK.BT and the 'secret key corresponding to the public key included in SPBM.Cert.KA' to communicate encrypted with the bundle management server 750 . You can create a key ShKeyBT for

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

The first SSP 720 may prepare a bundle to be transmitted to the second terminal 760 . Some and/or all of the information contained in the bundle may be encrypted using ShKeyBT. The prepared bundle can be called boundSpbImage.

The first SSP 720 may delete the prepared bundle.

After deleting the bundle, the first SSP 720 may generate a token (referred to as ssp1.Notification) for notifying the bundle management server 750 of this information.

In step 7040 , the first SSP 720 may transmit a boundSpbImage to the bundle management server 750 . The first SSP 720 may further transmit ssp1.ePK.BT to the bundle management server 750 . The first SSP 720 may further transmit ssp1.Notification to the bundle management server 750 .

Referring to FIG. 7 , in step 7045 , the bundle management server 750 may verify ssp1.Notification and transmit a response message to the first LBA 730 .

If the boundSpbImage is encrypted with an encryption key created using the public key included in ssp1.eSK.BT and 'SPBM.Cert.KA, the bundle management server 750 is ssp1.ePK.BT and 'SPBM.Cert. After generating the encryption key ShKeyBT using the 'private key corresponding to the public key included in KA', the encrypted data included in boundSpbImage can be decrypted using this encryption key.

The boundSpbImage received by the bundle management server 750 may be referred to as a 'bundle'.

The bundle management server 750 may map some or all of the following information to each other: a bundle, a bundle identifier of a bundle to be transmitted by the first terminal, and an SSP identifier of the second SSP.

The bundle management server 750 may transmit a response message to the first LBA 730 .

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 a startRequest) informing the second LBA 780 that a bundle request can be started. startRequest may include the SSP identifier of the second SSP installed in the second terminal. startRequest may include the bundle identifier of the bundle to be transmitted. startRequest may now include an indicator indicating that it is possible to initiate a bundle request. The first LBA may notify the second LBA that it is possible to initiate a bundle request by including this indicator in the startRequest or by setting and including a specific value in this indicator and transmitting it to the second LBA.

8 is a diagram illustrating a procedure in which a bundle uploaded to a server is downloaded to a terminal to receive the bundle among the procedures presented in FIG. 5 according to an embodiment of the present disclosure.

Referring to FIG. 8 , the UE 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 . A description of the bundle management server will be referred to FIG. 4 .

Referring to FIG. 8 , in step 8000 , the second LBA 880 may request “SSP information (SspInfo)” from the second SSP 870 .

When the second LBA 880 requests “SSP information (SspInfo)” from the second SSP 870 , the second LBA 880 may inform the second SSP that inter-device bundle movement is to be performed. When the second LBA 880 requests “SSP information (SspInfo)” from the second SSP 870 , the second LBA 880 may further inform the second SSP that the inter-device online bundle movement will be performed. For example, the request message may include an indicator indicating that the bundle movement between devices will be performed. As another example, the request message may include an indicator indicating that the online bundle movement between devices will be performed. The request message may include the indicator or inform the second SSP that the inter-device bundle movement will be performed or that the inter-device online bundle movement will be performed by setting the value of the indicator to a specific value.

The second LBA 880 may provide information on a 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).

Referring to FIG. 8 , in step 8005 , the second SSP 870 generates its own "SSP information (ssp2.SspInfo)" and sends the "SSP information" to the bundle management server 850 via the second LBA 880. can be transmitted.

"SSP information" may include information of the second SSP to be provided for bundle transmission. In this case, "SSP information" may include information (certificate negotiation information) for a certificate negotiation process that the second SSP 870 must go through 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. can Also, the “certificate negotiation information” may further include a list of key agreement algorithms supported by the second SSP 870 , and may further include a list of encryption algorithms supported by the second SSP 870 .

Also, "SSP information" may further include SSP version information including version information of at least one of the version information of the standard standard supported by the primary platform and the loader included in the second SSP 870 .

In an embodiment, the second SSP 870 may transmit "SSP information" to the bundle management server 850 via the second LBA.

According to steps 8000 to 8005, after the second LBA 880 requests "SSP information" from the second SSP 870, and the second SSP 870 generates its own "SSP information", the second The SSP 870 may transmit "SSP information" to the bundle management server 850 via the second LBA 880 . However, according to an embodiment, the second LBA 880 may transmit "SSP information" to the bundle management server 850 after generating "SSP information" by itself.

Referring to Figure 8, in step 8010, the bundle management server 850 checks the received "SSP information" and generates "server authentication information (SPBM.Auth2)" based on this information, and sends the "server" to the second LBA. authentication information".

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

a) A certificate for key agreement (referred to as SPBM.Cert.KA) that can be used to verify SPBM itself and the certificates required to verify this certificate.

b) Certificate information to be used by the SPBM to verify the second SSP (referred to as CiPkIdToBeUsed)

c) Information of the encryption algorithm to be used when the SPBM performs encrypted communication with the second SSP (referred to as CryptoToBeUsed)

In an embodiment, the bundle management server 850 may transmit “server authentication information” to the second LBA 880 .

Referring to FIG. 8 , in step 8015 , the second LBA 880 may transmit “server authentication information” to the second SSP 870 . The second LBA 880 may further transmit a “bundle identifier of a bundle to be transmitted” to the second SSP 870 .

In one embodiment, the second SSP 870 may execute one or more of the following tasks.

a) You can check the validity of “SPBM.Cert.KA”.

b) At least one signature certificate (ssp2.Cert.DS) capable of verifying the second SSP may be selected based on the received "CiPkIdToBeUsed".

c) The public key "ssp2.ePK.KA" and the private key "ssp2.eSK.KA" which are the key pair for encryption to be used to confirm the received "CryptoToBeUsed" and to create an encryption key for encrypted communication with the bundle management server. can create In addition, the second SSP may generate ShKeyM2, which is a session key to be used for encrypted communication with the bundle management server, by using the public key for key agreement and ssp2.eSK.KA included in SPBM.Cert.KA.

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.

a) Ssp2.Cert.DS

b) Ssp2.ePK.KA

c) A transaction ID that refers to the current session.

d) SSP identifier of the second SSP 720

e) The bundle identifier of the bundle to be sent.

Part or all of "Second Terminal Authentication Information (Device2.Auth)" may be digitally signed so that it can be verified using ssp2.Cert.DS to ensure the integrity of the information, and the digital signature data is "second terminal authentication" may be added as part of "information".

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

In an embodiment, the second SSP 870 may transmit "second terminal authentication information (Device2.Auth)" to the bundle management server 850 via the second LBA 880 .

In an embodiment, the bundle management server 850 may perform one or more of the following processes.

a) The bundle management server may verify the validity of ssp2.Cert.DS included in the “second terminal authentication information”. In addition, the bundle management server may verify the validity of the signature using ssp2.Cert.DS when the electronic signature is included in the “second terminal authentication information”.

b) The bundle management server uses 'secret key corresponding to the public key for key agreement included in SPBM.Cert.KA' and ssp2.ePK.KA when there is encrypted data in “Second terminal authentication information” Thus, ShKeyM2, which is a session key to be used for encrypted communication with the second terminal, can be generated, and encrypted data can be decrypted using the session key.

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

d) The bundle management server may check and/or store the bundle identifier of the bundle to be transmitted by the second terminal.

In an embodiment, the bundle management server 850 may further perform one or more of the following processes.

a) The bundle management server may check whether there is a bundle to be transmitted to the second terminal by using the SSP identifier of the second SSP.

b) The bundle management server may check whether there is a bundle to be transmitted to the second terminal by using the bundle identifier of the bundle to be transmitted by the second terminal.

c) When there is a bundle to be transmitted to the second terminal, the bundle management server may prepare the bundle. (The prepared bundle is called boundSpbImage)

For example, if there is a bundle mapped with 'the SSP identifier of the second SSP and/or the bundle identifier of the bundle to be transmitted by the second terminal' among the bundles uploaded from the first terminal in FIG. 7 , this bundle may be selected.

At this time, if the selected bundle does not need to be encrypted again, the bundle management server may prepare to transmit the bundle.

Alternatively, if the selected bundle needs to be encrypted with an encryption 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 prepare the bundle for transmission. have.

Alternatively, when the selected bundle needs to be encrypted with a key for encryption between the bundle management server and the second terminal, the bundle management server includes a key pair of 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 can do.

In step 8025, the bundle management server 850 may transmit a boundSpbImage to the second LBA 880. The bundle management server 850 may further transmit SPBM.ePK.BT to the second LBA 880 . The bundle management server 850 may further transmit ssp1.ePK.BT to the second LBA 880 .

Referring to FIG. 8 , a bundle may be installed in the second SSP in step 8030 .

In an 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 may decrypt the encrypted information using SHkeyM2.

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 generates an encryption key ShKeyBT using SPBM.ePK.BT. After that, you can use this key to decrypt the encrypted information.

In another embodiment, when the bundle is encrypted with an encryption key between the first terminal and the second terminal, the second SSP 870 generates an encryption key ShKeyBT using ssp1.ePK.BT and then uses this key can be used to decrypt encrypted information.

Referring to FIG. 8 , in step 8035 , the second SSP 870 may notify the bundle installation result to the bundle management server 850 . For example, the second SSP 870 may transmit a message (referred to as ssp2.Notificatoin) containing the bundle installation result to the bundle management server 850 .

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

Referring to FIG. 9 , the UE may include at least one LBA and at least one SSP. For example, as shown in FIG. 4 , the first terminal 910 includes a first LBA 930 and a first SSP 920 , and the second terminal 960 includes a second LBA 980 and a second LBA 980 . 2 SSPs 970 may be included. A description of the bundle management server will be referred to FIG. 4 .

In 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.

In step 9005 , the second terminal 960 may receive a bundle transmission 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.

In step 9010 , the first terminal 910 may upload a 'bundle to be transmitted to the second terminal' to the bundle management server 950 . For a more detailed description of the procedure, reference will be made to the detailed description of FIG. 12 to be described later.

In step 9015 , the second terminal 960 may download and install the 'bundle uploaded in step 9010' from the bundle management server 950 . For a more detailed description of the procedure, reference will be made to the detailed description of FIG. 13 to be described later.

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

Referring to FIG. 10 , the UE may include at least one LBA and at least one SSP. For example, the first terminal 1010 includes a first LBA 1030 and a first SSP 1020 , and the second terminal 1060 includes a second LBA 1080 and a second SSP 1070 . can do.

According to various embodiments, the first terminal 1010 may have a pre-installed bundle, and may further hold metadata associated with the pre-installed bundle. According to various embodiments, the first terminal 1010 provides 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) related to a pre-installed bundle. may hold

According to various embodiments, the first terminal 1010 may have a 'bundle movement setting' related to a pre-installed bundle. For a description of 'bundle movement setting', reference will be made to the description of FIG. 6 .

Referring to FIG. 10 , in step 10000 , the first LBA 1030 may acquire information on a bundle to be transmitted between devices. Alternatively, information on a bundle to be transmitted between devices may be transmitted to the first LBA. For example, the first LBA may acquire information of a bundle to be transmitted by receiving a user input for selecting a bundle through a UI provided by the user first terminal 1010, or may be transmitted through a push input from a remote server Information of the bundle to be transmitted may be input to the first LBA, or the first LBA may access the remote server and read information of the bundle to be transmitted.

In step 10002 , the first LBA 1030 may check whether the bundle can be transmitted between devices by using the 'bundle movement setting'. In addition, the first LBA 1030 may check 'bundle movement setting' to determine whether the bundle can be transmitted online between devices.

In step 10004, the first LBA 1030 may generate a 'bundle transmission code'. The bundle transmission code may include a bundle identifier such as a bundle identifier (SPB ID), a bundle family identifier (SPB Family ID), and a bundle family manager identifier (SPB Family Custodian Object ID) of a bundle to be transmitted. Also, the bundle transmission information may further include other information indicating the properties of the bundle (eg, metadata of the bundle or a part of the metadata). Also, the bundle transmission information may include the address (SPBM Addr) of the bundle management server associated with the bundle to be transmitted.

In addition, the bundle transmission code may include information on encryption algorithms supported by the first terminal (eg, the first SSP) (Supported Crypto Info). Information on encryption algorithms supported by the first terminal may selectively include one or more of the following information; A list of elliptic curve curves supported by the first terminal, a list of key agreement algorithms supported by the first terminal, and an encryption algorithm list supported by the first terminal.

Referring to FIG. 10 , in step 10005 , the bundle transmission code generated in step 10000 may be transmitted from the first LBA 1030 to the second LBA 1080 . The bundle transmission code may be transmitted in a variety of ways.

For example, the first LBA 1030 may 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 may provide the received information to the second user of the second terminal. The second user may input the provided information into the second LBA using the UI of the second terminal.

Alternatively, the first LBA 1030 makes the information to be transmitted to the second LBA 1080 in the form of an image (eg, QR code) and displays it on the screen of the first terminal, and the second user is the first terminal Information can be transmitted to the second LBA by scanning the image displayed on the screen of the second terminal.

Alternatively, the first LBA 1030 may establish a connection between the first LBA 1030 and the second LBA 1080 and transmit information to be transmitted using the established connection. At this time, the connection established between the first LBA 1030 and the second LBA 1080 is a direct device-to-device connection (eg, NFC, Bluetooth, UWB, WiFi-Direct, LTE device-to-device (D2D), 5G D2D ) or a remote connection in which a remote server (eg, a relay server) is located between the first LBA 1030 and the second LBA 1080 .

11 is a diagram illustrating a procedure in which a terminal receiving a bundle communicates with a server and receives approval among the procedures shown in FIG. 9 according to an embodiment of the present disclosure.

Referring to FIG. 11 , the UE 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 . The description of the bundle management server 1150 will refer to FIG. 4 .

Referring to FIG. 11 , in step 11000 , the second LBA 1180 may request “SSP information (SspInfo)” from the second SSP 1170 .

When the second LBA 1180 requests “SSP information (SspInfo)” from the second SSP 1170 , the second LBA 1180 may inform the second SSP that the inter-device bundle movement is to be performed. When the second LBA 1180 requests “SSP information (SspInfo)” from the second SSP 1170 , the second LBA 1180 may further inform the second SSP that the inter-device online bundle movement is to be performed. For example, the request message may include an indicator indicating that the bundle movement between devices will be performed. As another example, the request message may include an indicator indicating that the online bundle movement between devices will be performed. The request message may inform the second SSP that inter-device bundle movement or inter-device online bundle movement will be performed by including the indicator or setting the value of the indicator to a specific value.

The second LBA 1180 may provide information on 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).

Referring to FIG. 11 , in step 11005 , the second SSP generates its own “SSP information (ssp2.SspInfo)” and transmits “SSP information” to the bundle management server 1150 via the second LBA 1180 . can

"SSP information" may include information of the second SSP to be provided for bundle transmission. In this case, "SSP information" may include information (certificate negotiation information) for a certificate negotiation process that the second SSP 1170 must go through to communicate with the bundle management server 1150 . "Certificate negotiation information" is certificate information that the second SSP 1170 can use to verify the bundle management server 1150 and/or the bundle management server 1150 can use it to verify the second SSP 1170. Certificate information may be included. In addition, the "certificate negotiation information" may further include a list of key agreement algorithms supported by the second SSP, and may further include a list of encryption algorithms supported by the second SSP.

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

In an embodiment, the second SSP 1170 may transmit "SSP information" to the bundle management server 1150 via the second LBA 1180 .

According to steps 11000 to 11005, after the second LBA requests "SSP information" from the second SSP, the second SSP generates its own "SSP information", the second SSP manages the bundle through the second LBA You can send "SSP information" to the server. However, according to an embodiment, the second LBA may generate “SSP information” by itself and then transmit “SSP information” to the bundle management server.

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

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

a) A certificate for key agreement (referred to as SPBM.Cert.KA) that can be used to verify SPBM itself and the certificates required to verify this certificate.

b) Certificate information to be used by the SPBM to verify the second SSP (referred to as CiPkIdToBeUsed)

c) Information of the encryption algorithm to be used when the SPBM performs encrypted communication with the second SSP (referred to as CryptoToBeUsed)

In an embodiment, the bundle management server 1150 may transmit “server authentication information” to the second LBA 1180 .

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 a “bundle identifier of a bundle to be transmitted” to the second SSP 1170 . The second LBA 1180 may further transmit the Supported Crypto Info to the second SSP 1170 . For a description of Supported Crypto Info, refer to FIG. 10 .

Referring to FIG. 11 , in step 11020 , the second SSP 1170 may execute one or more of the following tasks.

a) You can check the validity of “SPBM.Cert.KA”.

b) At least one signature certificate (ssp2.Cert.DS) capable of verifying the second SSP may be selected based on the received "CiPkIdToBeUsed".

c) The public key "ssp2.ePK.KA" and the private key "ssp2.eSK.KA" which are the key pair for encryption to be used to confirm the received "CryptoToBeUsed" and to create an encryption key for encrypted communication with the bundle management server. can create In addition, the second SSP may generate ShKeyM2, which is a session key to be used for encrypted communication with the bundle management server, by using the public key for key agreement and ssp2.eSK.KA included in SPBM.Cert.KA.

In an embodiment, the second SSP 1170 may generate “second terminal authentication information (Device2.Auth)”. “Second terminal authentication information (Device2.Auth)” includes one or more of the following information. can do.

a) Ssp2.Cert.DS

b) Ssp2.ePK.KA

c) A transaction ID that refers to the current session.

d) SSP identifier of the second SSP

e) Part Number ID of 2nd SSP

f) The bundle identifier of the bundle to be sent.

In an embodiment, the second SSP 1170 may check the received supported Crypto Info and check whether encryption algorithms supported by the second terminal (eg, the second SSP) exist among them. If there are encryption algorithms supported by the second terminal among the received supported Crypto Info, the second SSP 1170 may select one of these 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 agreement algorithm information, and encryption algorithm information.

The second SSP 1170 is the second terminal's key pair (temporary public key ssp2.ePK.BT and its corresponding A secret key ssp2.eSK.BT) can be created. The second SSP 1170 may map the generated key pair to the received bundle identifier (SPB ID). The second SSP 1170 may generate “selected encryption information (ssp2.SelectedCryptoInfo)”. “Selected encryption information” may optionally include one or more of the following information: a part and/or all of the selected encryption algorithm, ssp2.eEPK.BT

Some or all of the “second terminal authentication information (Device2.Auth)” and/or “selected encryption information (ssp2.SelectedCryptoInfo)” is digitally signed so that it can be verified using ssp2.Cert.DS to ensure the integrity of the information. and the digital signature data may be added as part of "second terminal authentication information".

In addition, some or all of "second terminal authentication information (Device2.Auth)" and/or "selected encryption information (ssp2.SelectedCryptoInfo)" may be encrypted using the previously generated session key ShKeyM2.

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

Referring to FIG. 11 , in step 11025 , the bundle management server 1150 may perform one or more of the following processes.

a) The bundle management server may verify the validity of ssp2.Cert.DS included in the “second terminal authentication information”. In addition, the bundle management server may verify the validity of the signature using ssp2.Cert.DS when the electronic signature is included in the “second terminal authentication information”.

b) The bundle management server uses 'secret key corresponding to the public key for key agreement included in SPBM.Cert.KA' and ssp2.ePK.KA when there is encrypted data in “Second terminal authentication information” Thus, it is possible to generate ShKeyM2, which is a session key to be used for encrypted communication with the second terminal, and decrypt the encrypted data using this session key.

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

d) The bundle management server may check and/or store the bundle identifier of the bundle to be transmitted by the second terminal.

In an embodiment, the bundle management server 1150 may further perform one or more of the following processes.

a) The bundle management server may check whether the bundle is a bundle that can be transmitted online by checking the bundle identifier of the bundle that the second terminal wants to receive. For example, the process of checking whether a bundle can be transmitted online may be performed by the bundle management server 1150 performing verification using the 'bundle movement setting' value of the bundle.

b) The bundle management server may check whether the bundle to be transmitted by the second terminal is normally installed and/or operated in the second terminal (eg, the second SSP). For example, this confirmation process may be performed using the part number ID of the second terminal (eg, the second SSP) and/or the bundle identifier of the bundle to be transmitted by the second terminal.

In an embodiment, the bundle management server 1150 may map some or all of the following information to each other: an SSP identifier of the second SSP, a bundle identifier of a bundle to be transmitted, and “selected encryption information (ssp2.SelectedCryptoInfo)” ”

In step 11025, the bundle management server 1150 may transmit a response message informing the second LBA 1180 that all processes have been completed. The process of transmitting a response message indicating that all processes have been completed may be omitted.

12 is a diagram illustrating a procedure in which a terminal to transmit a bundle uploads a bundle to be transmitted to a server among the procedures shown in FIG. 9 according to an embodiment of the present disclosure.

12 , the UE 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 . A description of the bundle management server 1250 will be referred to in FIG. 4 .

Referring to FIG. 12 , in step 12000 , the first LBA 1230 may request “SSP information (SspInfo)” from the first SSP 1220 .

When the first LBA requests "SSP information (SspInfo)" from the first SSP, the first LBA may inform the first SSP that inter-device bundle movement is to be performed. When the first LBA requests "SSP information (SspInfo)" from the first SSP, the first LBA may further inform the first SSP that the inter-device online bundle movement will be performed. For example, the request message may include an indicator indicating that the bundle movement between devices will be performed. As another example, the request message may include an indicator indicating that the online bundle movement between devices will be performed. The request message may include the indicator or inform the first SSP that the inter-device bundle movement will be performed or the inter-device online bundle movement will be performed by setting the value of the indicator to 1.

The first LBA may provide information on 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).

Referring to FIG. 12 , in step 12005 , the first SSP 1220 generates its own “SSP information (ssp1.SspInfo)” and sends “SSP information” to the bundle management server 1250 via the first LBA 1230 . " can be transmitted.

"SSP information" may include information of the first SSP to be provided for bundle transmission. In this case, "SSP information" may include information (certificate negotiation information) for a certificate negotiation process that the first SSP must go through to communicate with the bundle management server. "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. In addition, the "certificate negotiation information" may further include a list of key agreement algorithms supported by the first SSP, and may further include a list of encryption algorithms supported by the first SSP.

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

In an embodiment, the first SSP 1220 may transmit "SSP information" to the bundle management server 1250 via the first LBA 1230 .

According to steps 12000 to 12005, after the first LBA requests "SSP information" from the first SSP, the first SSP generates its own "SSP information", the first SSP manages the bundle through the first LBA You can send "SSP information" to the server. However, according to an embodiment, the first LBA may generate "SSP information" by itself and then transmit "SSP information" to the bundle management server.

12, in step 12010, the bundle management server 1250 checks the received "SSP information" and generates "server authentication information (SPBM.Auth1)" based on this information, and the first LBA 1230. "Server authentication information" can be sent to

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

a) A certificate for key agreement (referred to as SPBM.Cert.KA) that can be used to verify SPBM itself and the certificates required to verify this certificate.

b) Certificate information to be used by the SPBM to verify the first SSP (referred to as CiPkIdToBeUsed)

c) Information of the encryption algorithm to be used by the SPBM when performing encrypted communication with the first SSP (referred to as CryptoToBeUsed)

In an embodiment, the bundle management server 1250 may transmit “server authentication information” to the first LBA 1230 .

Referring to FIG. 12 , in step 12015 , the first LBA 1230 may transmit “server authentication information” to the first SSP 1220 . The first LBA 1230 may further transmit a “bundle identifier of a bundle to be transmitted” to the first SSP 1220 .

Referring to FIG. 12 , in operation 12020 , the first SSP 1220 may execute one or more of the following tasks.

a) You can check the validity of the received “SPBM.Cert.KA”.

b) At least one signature certificate (ssp1.Cert.DS) capable of verifying the first SSP may be selected based on the received "CiPkIdToBeUsed".

c) The public key "ssp1.ePK.KA" and the private key "ssp1.eSK.KA" which are the key pair for encryption to be used to confirm the received "CryptoToBeUsed" and to create an encryption key for encrypted communication with the bundle management server. can create Also, the first SSP may generate ShKeyM1, which is a session key to be used for encrypted communication with the bundle management server, by using the public key for key agreement and ssp1.eSK.KA included in SPBM.Cert.KA.

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.

a) ssp1.Cert.DS

b) ssp1.ePK.KA

c) A transaction ID that refers to the current session.

d) SSP identifier of the first SSP

e) The bundle delimiter of the bundle you want to transfer.

Part or all of the "first terminal 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 digital signature data is "first terminal authentication" may be added as part of "information".

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

In an embodiment, the first SSP 1220 may transmit "first terminal authentication information (Device1.Auth)" to the bundle management server 1250 via the first LBA 1230 .

Referring to FIG. 12 , in 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.)

a) The bundle management server may verify the validity of ssp1.Cert.DS included in the “first terminal authentication information”. In addition, the bundle management server may verify the validity of the signature using ssp1.Cert.DS when the electronic signature is included in the “first terminal authentication information”.

b) The bundle management server uses the 'private key corresponding to the public key for key agreement included in SPBM.Cert.KA' and ssp1.ePK.KA when there is encrypted data in the “1st terminal authentication information” Thus, it is possible to generate ShKeyM1, which is a session key to be used for encrypted communication with the first terminal, and decrypt the encrypted data using this session key.

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

d) The bundle management server may check and/or store the bundle identifier of the bundle to be transmitted by the first terminal.

In an embodiment, the bundle management server 1250 may further perform one or more of the following processes. (Hereinafter, this series of processes will be referred to as process B.)

a) The bundle management server can use the 'SSP identifier of the first SSP' and the 'bundle identifier of the bundle that the first terminal wants to transmit' to check that the first terminal (eg, the first SSP) is currently a legitimate user of the bundle. have.

b) The bundle management server may check whether the 'bundle to be transmitted by the first terminal' is a bundle that has already been requested and approved for bundle transmission. For example, the bundle management server may check whether the bundle identifier of the 'bundle to be transmitted by the first terminal' is the stored bundle identifier through step 11025 of FIG. 11 .

Between the processes A and B presented above, the bundle management server 1250 may wait for the operation shown in FIG. 11 to be completed. That is, process A may be performed regardless of whether the operation shown in FIG. 11 is completed, but process B may have to be executed after completion of the operation shown in FIG. 11 . In this case, the bundle management server performs the process B before It may wait for the operation shown in FIG. 11 to be completed. This waiting process can be implemented in various ways described below. However, the waiting process is not limited to the various methods described below, and the waiting process is not necessarily one of the methods described below.

a) The bundle management server may send a message to the first LBA that once it has received the requested operation, it must wait until it receives a response. After waiting a predetermined time, the first LBA may send a message to the bundle management server to check whether the requested operation is completed. If the operation is completed, process B may be performed. If the operation is not completed, the bundle management server may send a message to the first LBA to wait a little longer. The above process may be repeated until the bundle management server completes the operation shown in FIG. 11 .

b) The bundle management server may wait within a predetermined time range between process A and process B. That is, if the operation shown in FIG. 11 is completed within a predetermined time after performing the process A, the process B may be performed. If the operation shown in FIG. 11 is not completed within a predetermined time after performing the process A, the bundle transmission process may be interrupted.

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

In step 12025, the bundle management server 1250 generates a message requesting the bundle to the first terminal (spbRequest. This term may also be referred to as transferOption.), and a message requesting the bundle to the first SSP 1220 ( spbRequest) can be sent. The bundle management server 1250 may further transmit ssp2.SelectedCryptoInfo to the first SSP 1220 .

spbRequest may include one or more of the following information.

a) SSP identifier of the first SSP

b) SSP identifier of the second SSP

c) Bundle identifier of the bundle that the first terminal wants to transmit

d) transaction ID

Some and/or all of the information contained in spbReqeust may be encrypted using ShKeyM1, which may be included as part of spbRequest.

Some and/or all of the information contained 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, a set of information necessary to validate SPBM.Cert.DS and SPBM.Cert.DS may be included as part of spbRequest.

In an embodiment, the bundle management server 1250 may transmit spbRequest to the first SSP 1220 via the first LBA 1230 .

In an embodiment, the bundle management server 1250 may further transmit ssp2.SelectedCryptoInfo to the first SSP 1220 via the first LBA 1230 . For a description of ssp2.SelectedCryptoInfo, refer to FIG. 6 .

Referring to FIG. 12 , in step 12030 , the first SSP 1220 may perform one or more of the following processes.

a) If the spbRequest contains encrypted information, it is decrypted using ShKeyM1.

b) If the spbRequest contains a digital signature value, after verifying the validity of SPBM.Cert.DS, the validity of the electronic signature value is verified using SPBM.Cert.DS.

c) Verifies that the SSP identifier of the first SSP and/or the SSP identifier of the second SSP and/or the bundle identifier and/or transaction ID of the bundle that the first terminal intends to transmit included in the spbRequest are correct values

The first SSP 1220 may check information included in ssp2.SelectedCryptoInfo.

The first SSP 1220 may set a public key "ssp1.ePK.BT" and a private key "ssp1.eSK.BT" as a key pair for encryption. This value may be the same as the values of “ssp1.ePK.KA” and “ssp1.eSK.KA” according to an embodiment.

According to an embodiment, the first SSP 1220 may 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'. have.

According to an embodiment, the first SSP 1220 may use the prepared ssp1.eSK.BT and ssp2.ePK.BT to create a key ShKeyBT for encrypted communication with the second terminal.

The first SSP 1220 may prepare and/or generate a bundle desired to be transmitted to the second terminal. Some and/or all of the information contained in the bundle may be encrypted using ShKeyBT. The prepared bundle can be called boundSpbImage.

The first SSP 1220 transmits some of the contents of the bundle to the second terminal (eg, i) personal information included in the bundle and/or ii) setting values and/or iii) updates made after the installation of the bundle. part and/or all) may be extracted and/or prepared. In this case, some and/or all of the information may be encrypted using ShKeyBT. This prepared data can be collectively called boundSpbImageData or boundSpbImage for convenience.

The first SSP 1220 may delete a bundle desired to be transmitted to the second terminal.

After deleting the bundle, the first SSP 1220 may generate a token (referred to as ssp1.Notification) for notifying the bundle management server 1250 of this information.

In step 12030 , the first SSP 1220 may transmit boundSpbImage or boundSpbImageData to the bundle management server 1250 . The first SSP 1220 may further transmit ssp1.ePK.BT to the bundle management server 1250 . The first SSP 1220 may further transmit ssp1.Notification to the bundle management server 1250 .

Referring to FIG. 12 , in step 12035 , the bundle management server 1250 may verify ssp1.Notification and transmit a response message informing the first LBA 1230 that all processes have been performed.

If boundSpbImage or boundSpbImageData is encrypted with an encryption key created using ssp1.eSK.BT and 'public key included in SPBM.Cert.KA', the bundle management server 1250 performs ssp1.ePK.BT and 'SPBM After generating the encryption key ShKeyBT using the 'secret key corresponding to the public key included in .Cert.KA', the encrypted data included in boundSpbImage or boundSpbImageData can be decrypted using this encryption key.

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

[CASE A]

If bundle management server receives SpbImage encrypted with ShKeyBT created using ssp1.eSK.BT and 'public key included in SPBM.Cert.KA'

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

[CASE B]

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

The result generated after the bundle management server decrypts using ShKeyBT can be referred to as 'decrypted bundle data'.

[CASE C]

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

The bundle management server stores the received result, and the stored result may be referred to as a 'received bundle'.

[CASE D]

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

After the bundle management server stores the received result, the stored result may be referred to as 'received bundle data'.

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 identifier of the bundle to be transmitted by the second SSP, and the 'decrypted bundle' described above. , 'decrypted bundle data', 'received bundle', 'received bundle data', etc.

In an embodiment, the bundle management server 1250 may transmit a response message informing the first LBA 1230 that all processes have been performed.

13 is a diagram illustrating a procedure in which a bundle uploaded to a server is downloaded to a terminal to receive the bundle among the procedures shown in FIG. 9 according to an embodiment of the present disclosure.

Referring to FIG. 13 , the UE 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 . A description of the bundle management server 1350 will refer to FIG. 4 .

Referring to FIG. 13 , in step 13000 , the second LBA 1380 may request the bundle to be transmitted from the bundle management server 1350 . This request can be made in a number of ways. For example, the second LBA 1380 may transmit “second terminal authentication information (Device2.Auth)” to the bundle management server 1350 . For a description of “second terminal authentication information (Device2.Auth)”, reference will be made to FIG. 11 .

Step 13000 may be replaced by the following process. That is, after performing step 11020 shown in FIG. 11 , the second terminal 1360 may wait for step 13005 to be described later. This waiting process can be implemented in various ways described below. However, the waiting process is not limited thereto, and the waiting method is not necessarily one of the methods described below.

a) The bundle management server 1350 may send a message to the second LBA 1380 that it has to wait until a response has been received even though it has once received the requested operation. The second LBA 1380 may transmit a message to the bundle management server 1350 to check whether the requested operation is completed after waiting a predetermined time. If the operation is completed, step 13005 may be performed. If the execution of the operation is not completed, the bundle management server 1350 may send a message to the second LBA 1380 to wait a little longer. In this case, the second LBA 1380 may send a message back to the bundle management server 1350 to check whether the requested operation is completed after waiting for a predetermined time again. The above process may be repeated until step 13005 is performed.

b) The second LBA 1380 may wait for step 13005 to be performed within a predetermined time range. If step 13005 is not performed within a predetermined time, the bundle transmission process may be stopped.

c) The bundle management server 1350 may notify the second LBA 1380 that the requested operation has been received. After that, when preparation is completed, step 13005 may be performed.

Referring to FIG. 13 , in operation 13005 , the bundle management server 1350 may perform one or more of the following processes.

The following process may be performed when the bundle management server 1350 receives a bundle request message from the second LBA 1380 in step 13000 .

a) The bundle management server may check 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 may check which terminal is currently requesting the bundle through the received 'second terminal authentication information'.

b) The bundle management server may check whether there is a bundle to be transmitted to the second terminal by using the SSP identifier of the second SSP.

c) The bundle management server may check whether there is a bundle to be transmitted to the second terminal by using the bundle identifier of the bundle to be transmitted by the second terminal.

In operation 13005 , the bundle management server 1350 may prepare a bundle to be transmitted to the second terminal 1360 . That is, prepared in FIG. 12

- Decrypted Bundle

- Decrypted bundle data

- Received bundle

- Received bundle data

If there is a mapping with 'the SSP identifier of the second SSP and/or the bundle identifier of the bundle to be transmitted by the second terminal', a bundle to be transmitted to the second terminal may be prepared. This bundle can be prepared in one of the methods described below.

[CASE A]

When the bundle management server has a decrypted bundle as a result of the process shown in FIG. 12 , the bundle management server may use this bundle to prepare a bundle to be transmitted to the second terminal. In one embodiment, the bundle management server may use ShKeyM2 to encrypt some and/or all of the bundle and then prepare the bundle for transmission. In another embodiment, the bundle management server generates a public key "SPBM.ePK.BT" and a private key "SPBM.eSK.BT" as a key pair, and then performs SPBM.eSK.BT and ssp2. After generating the encryption key ShKeyBT using ePK.KA, you can use this key to encrypt part and/or all of the bundle and prepare this bundle.

[CASE B]

When the bundle management server has bundle data decrypted as a result of the process shown in FIG. 12 , the bundle management server may use this data to prepare a bundle to be transmitted to the second terminal. In an embodiment, the bundle management server may prepare a bundle including the decrypted bundle data as a part. In another embodiment, the bundle management server may include the decrypted bundle data as additional data after preparing a bundle to be transmitted to the second terminal. In one embodiment, the bundle management server may encrypt some and/or all of the prepared bundle and/or additional data using ShKeyM2. In another embodiment, the bundle management server generates a key pair of a public key "SPBM.ePK.BT" and a private key "SPBM.eSK.BT", and SPBM.eSK.BT and ssp2.ePK. After generating the encryption key ShKeyBT using the KA, part and/or all of the prepared bundle and/or additional data can be encrypted using the encryption key ShKeyBT.

[CASE C]

When the bundle management server has a bundle received as a result of the process shown in FIG. 12 , the received bundle may be prepared as a bundle to be transmitted to the second terminal soon.

[CASE D]

When the bundle management server has bundle data received as a result of the process shown in FIG. 12 , a bundle to be transmitted to the second terminal may be prepared using the received bundle data. In an 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, some and/or all of the bundles created by the bundle management server may be encrypted using ShKeyM2. In another embodiment, some and/or all of the bundles generated by the bundle management server are generated using the key pair "SPBM.ePK.BT" and "SPBM.eSK.BT" generated by the bundle management server. It can be encrypted using the encrypted encryption key ShKeyBT.

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

In step 13005 , the bundle management server 1350 may transmit the boundSpbImage to the second LBA 1380 . The bundle management server 1350 may further transmit SPBM.ePK.BT to the second LBA 1380 . The bundle management server 1350 may further transmit ssp1.ePK.BT to the second LBA 1380 .

Referring to FIG. 13 , a bundle may be installed in the second SSP in step 13010 . The second SSP 1370 and/or the second LBA 1380 may install a bundle in the second SSP 1370 using the boundSpbImage received in operation 13005 .

In one embodiment, when the bundle and/or additional data received from the bundle management server 1350 are encrypted with an encryption key between the bundle management server and the second terminal, the second SSP 1370 is encrypted using SHkeyM2. The information can be decrypted. In another embodiment, when the bundle and/or additional data received from the bundle management server 1350 are encrypted with an encryption key between the bundle management server and the second terminal, the second SSP 1370 may use SPBM.ePK.BT to generate an encryption key ShKeyBT, and then use this key to decrypt the encrypted information.

In another embodiment, when the bundle and/or additional data received from the bundle management server 1350 are encrypted with an encryption key between the first terminal and the second terminal, the second SSP 1370 is ssp1.ePK After generating the encryption key ShKeyBT using .BT, encrypted information can be decrypted using this key. Referring to FIG. 13 , in step 13015 , the second SSP 1370 installs a bundle to the bundle management server 1350 . You can notify the results. For example, the second SSP 1370 may transmit a message (referred to as ssp2.Notificatoin) containing the bundle installation result to the bundle management server 1350 .

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

As shown in FIG. 14 , the terminal may include a transceiver 1410 and at least one processor 1420 . In addition, the terminal may further include an SSP (1430). For example, the SSP 1430 may be inserted into the terminal or may be embedded in the terminal. The at least one or more processors 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 the components shown in FIG. 14 . According to some embodiments, the transceiver 1410 , at least one processor 1420 , and a memory (not shown) may be implemented in the form of one chip. In addition, when the SSP 1430 is embedded, it may be implemented in the form of one chip including the SSP 1430 .

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

On the other hand, at least one processor 1420 is a component for controlling the overall terminal. At least one processor 1420 may control the overall operation of the terminal according to various embodiments of the present disclosure as described above.

Meanwhile, the SSP 1430 may include a processor or a controller for installing and controlling a bundle, or an application may be installed therein. Also, 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 a controller for installing and controlling a bundle, or an application may be installed therein. Some or all of the application may be installed in the SSP 1430 or a memory (not shown).

Meanwhile, the terminal may further include a memory (not shown), and may store data such as a basic program, an application program, and setting information for the operation of the terminal. In addition, the memory is a flash memory type (Flash Memory Type), a hard disk type (Hard Disk Type), a multimedia card micro type (Multimedia Card Micro Type), card type memory (eg, SD or XD memory, etc.), magnetic Memory, magnetic disk, optical disk, RAM (Random Access Memory, RAM), SRAM (Static Random Access Memory), ROM (Read-Only Memory, ROM), PROM (Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read- Only Memory) may include at least one storage medium. In addition, the processor may perform various operations using various programs, contents, data, etc. stored in the memory.

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

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 .

According to some embodiments, the transceiver 1510 may transmit and receive signals, information, data, etc. according to various embodiments of the present disclosure with the terminal. The transceiver 1450 may include an RF transmitter for up-converting and amplifying a frequency of a transmitted signal, and an RF receiver for low-noise amplifying and down-converting a received signal. However, this is only an embodiment of the transceiver 1510, and components of the transceiver 1510 are not limited to the RF transmitter and the RF receiver. Also, the transceiver 1510 may receive a signal through a wireless channel, output it to the at least one processor 1520 , and transmit a signal output from the at least one processor 1520 through a wireless channel.

Meanwhile, at least one processor 1520 is a component for overall controlling the bundle management server. The processor 1420 may control the overall operation of the bundle management server according to various embodiments of the present disclosure as described above. The one or more processors 1420 may be referred to as a controller.

Meanwhile, the bundle management server may further include a memory (not shown), and may store data such as a basic program, an application program, and setting information for the operation of the bundle management server. In addition, the memory is a flash memory type (Flash Memory Type), a hard disk type (Hard Disk Type), a multimedia card micro type (Multimedia Card Micro Type), card type memory (eg, SD or XD memory, etc.), magnetic Memory, magnetic disk, optical disk, RAM (Random Access Memory, RAM), SRAM (Static Random Access Memory), ROM (Read-Only Memory, ROM), PROM (Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read- Only Memory) may include at least one storage medium.

16 is a diagram illustrating an example of a method in which two terminals and a server mutually operate in order to perform online transmission of a profile from one terminal to another terminal according to an embodiment of the present disclosure.

As shown in FIG. 16 , a first eSIM 1603 and a second eSIM 1623 are mounted on the first terminal 1600 and the second terminal 1620 , respectively, and the first eSIM 1603 and the second A profile (not shown) may be installed in each eSIM 1623 . Also, the first LPA 1601 and the second LPA 1621 may be installed in the first terminal 1600 and the second terminal 1620 , respectively. The first eSIM 1603 and the second eSIM 1623 may be controlled by the first LPA 1601 and the second LPA 1621 , respectively. The first user 1605 and the second user 1625 connect to the eSIM of each terminal (the first eSIM 1603 and the second eSIM 1623) through the first LPA 1601 and the second LPA 1621, respectively. You can control the installed profile. In this case, the first user 1605 and the second user 1625 may be the same. Also, the first LPA 1601 and the second LPA 1621 may be connected to each other to communicate. In this case, a possible connection method between LPAs will be described with reference to the drawings to be described later.

The first LPA 1601 of the first terminal 1600 is connected to the first RSP server 1640, and the second LPA 1621 of the second terminal 1620 is connected to the second RSP server 1680. there may be In this case, the first RSP server 1640 and the second RSP server 1680 may be identical to each other. Also, for convenience, the first RSP server 1640 and the second RSP server 1680 are each configured as a single server, but according to the implementation and embodiments, one or more profile providing servers (SM-DP+) are It may be included in the configuration, and one or more opening mediation servers (SM-DS) that assist in the creation of a connection between the specific profile providing server and the terminal may be included in the server configuration. In addition, although not shown in this figure, one or more RSP servers and/or relay servers may be connected between the first RSP server 1640 and the second RSP server 1680 .

In addition, although not shown in the drawings, each RSP server and/or relay server may be connected to an operator server. When more than one operator server is included in the configuration, each operator server may be connected to each separate RSP server and/or relay server, and at least one operator server may be connected to the same RSP server and/or relay server. may be

The configuration of various servers as described above may be briefly represented as a single RSP server in the following drawings. For example, when one or more RSP servers and/or relay servers are connected between the first terminal 1600 and the second terminal 1620, and some or all of the RSP servers and/or relay servers are connected to the operator server, The configuration of various servers existing between the first terminal and the second terminal may be expressed as a single RSP server, and this single RSP server may be referred to as SM-XX in the drawings and embodiments.

17 is a diagram illustrating the first half of a process of online transmission of a profile from one terminal to another terminal according to some embodiments of the present disclosure.

Although not shown in FIG. 17 , the first terminal 1710 and the second terminal 1750 may include an eUICC and an LPA therein, respectively, as illustrated in FIG. 16 . In addition, the RSP server 1730 may mean including one or more RSP servers and/or relay servers and/or operator servers as will be described with reference to FIG. 16 .

Although not shown in FIG. 17 , the first terminal 1710 may have a 'profile movement setting'. According to various embodiments, the 'profile movement setting' is a policy for whether a profile can be moved between devices, and may be generated by a telecommunication service provider, an RSP server, or the aforementioned carrier and RSP. It may have been created by the collaboration of the server. According to various embodiments, the 'profile movement setting' inside the terminal may be updated by a communication service provider, an RSP server, or collaboration between a communication service provider and an RSP server. Alternatively, at least one subject of a communication service provider and an RSP server and the terminal may collaborate to update the 'profile movement setting'. The time and/or method at which the 'profile movement setting' is updated may be determined by a policy of a telecommunication service provider, RSP server, terminal manufacturer, and the like.

The 'profile movement setting' may include a factor (or an indication) indicating whether transmission of the corresponding profile between devices is permitted. In addition, the 'profile movement setting' may optionally further include a factor specifying under what conditions transmission is allowed when the device-to-device transmission of the corresponding profile is allowed. For example, whether the corresponding profile can be transmitted (or moved) online from one terminal to another terminal may be set. These factors may be digitally signed by at least one of an RSP server, a communication service provider, a terminal manufacturer, an eUICC, and an eUICC manufacturer. The corresponding electronic signature value may be stored in the first terminal as part of the 'profile movement setting' or together with the 'profile movement setting'.

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

The corresponding profile movement preparation information may include 'certificate negotiation information' used when the second terminal 1750 performs certificate negotiation with the RSP server. The corresponding certificate negotiation information may be some information of eUICC2.Info1 of the second terminal, which will be described later. The corresponding certificate negotiation information may include information(s) of a version supported by the eUICC of the second terminal. The corresponding certificate negotiation information may include 'certificate information that can be used to verify the eUICC of the second terminal'(s). The corresponding certificate negotiation information may include 'certificate information that can be used to verify the RSP server'(s).

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

The corresponding profile movement preparation information may include factors indicating an encryption method supported by the second terminal 1750 . The corresponding factor may include a key agreement algorithm list and/or an encryption algorithm list supported by the second terminal 1750 and/or the public key(s) of the second terminal to be used for key agreement. have.

Information transmitted from the second terminal 1750 to the first terminal 1710 may be transmitted in various ways. For example, the second terminal may 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 may provide the received information to the first user of the first terminal. The first user may input the provided information into the first terminal using the UI of the first terminal. Alternatively, the second terminal makes the information to be transmitted to the first terminal in the form of an image (eg, QR code) and displays it on the screen of the second terminal, and the first user sees the image displayed on the screen of the second terminal Information may be transmitted to the first terminal by scanning using the first terminal. However, a method for transmitting information from the second terminal to the first terminal is not limited to the above-described methods and may be determined in various ways. The first user and the second user may refer to different users or may refer to the same single user.

In an embodiment, the first terminal 1710 may determine whether the corresponding profile can be transmitted by checking the 'profile movement setting'. Also, the first terminal may determine whether the corresponding profile can be transmitted online by checking the 'profile movement setting'. Also, the first terminal may select to transmit the corresponding profile online by checking the 'profile movement setting'.

In an embodiment, the first terminal 1710 may check the received profile movement information. For example, the first terminal 1710 may verify whether there is an encryption method supported by the first terminal 1710 among the encryption methods supported by the second terminal 1750 included in the profile movement information. More specifically, the first terminal may check whether there is an algorithm supported by the first terminal among the key agreement algorithms and/or encryption algorithms supported by the second terminal. If there is an algorithm supported, the first terminal may select a key agreement algorithm and/or an encryption algorithm. In addition, the first terminal may select the public key of the second terminal to be used for later encryption key generation.

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 character string (eUICC1.Challenge) generated by the eUICC of the first terminal. eUICC1.Info1 may include information(s) of a version supported by the eUICC of the first terminal. eUICC1.Info1 may include 'certificate information that can be used to verify the eUICC of the first terminal'(s). eUICC1.Info1 may include 'certificate information that can be used to verify the RSP server'(s). eUICC1.Info1 may include a list of encryption algorithms supported by the first terminal.

Referring to FIG. 17 , in step 17010 , the RSP server 1730 may check the received eUICC1.Info1 and generate “RSP server authentication information (Server.Auth1)”. The RSP server may use the received eUICC1.Info1 to check whether a version supported by the RSP server exists among the eUICC versions supported by the first terminal. The RSP server can use the received eUICC1.Info1 to select a certificate Server.Cert that can verify itself. The RSP server may select certificate information to be used by the first terminal 1710 using the received eUICC1.Info1. The RSP server may use the received eUICC1.Info1 to select an encryption algorithm to be used for encrypted communication with the first terminal later.

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

“RSP server authentication information (Server.Auth1)” may include certificate information to be used by the first terminal. "RSP server authentication information (Server.Auth1)" may include a certificate Server.Cert that the first terminal can verify itself and related certificate chain information. “RSP server authentication information (Server.Auth1)” may include an encryption algorithm to be used in encrypted communication with the first terminal later.

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

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

Referring to FIG. 17, in step 17020, the first terminal 1710 verifies the received "RSP server authentication information (Server.Auth1)", and based on the verification result (eg, when verification is successful), “First terminal authentication information (Device1.Auth)” may be created. Terminal 1 checks the validity of Server.Cert included in “RSP Server Authentication Information (Server.Auth1)” and further validates the signature included in “RSP Server Information (Server.Auth1)” using Server.Cert. can be inspected. The first terminal may check whether the value of eUICC1.Challege included in “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 “RSP server authentication information (Server.Auth1)” is valid, and the value of eUICC1.Challenge is the same, verification may succeed.

Based on the verification result (eg, when 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.

“First terminal authentication information (Device1.Auth)” may include an eUICC identifier of an eUICC installed in the first terminal. In addition, “first terminal authentication information (Device1.Auth)” may include a profile identifier of a profile to be transmitted.

“First terminal authentication information (Device1.Auth)” may include a certificate eUICC1.Cert capable of verifying itself and related certificate chain information.

In addition, the first terminal may select some and/or all of the profile movement preparation information received from the second terminal 1750 in step 17000 . (Hereinafter, the selected information is referred to as 'mobile preparation selection information' for convenience.) For example, in 'mobile preparation selection information', the “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 normally installed and operated in the eUICC of the second terminal” may be included. In addition, the eUICC identifier of the second terminal may be included.

Part and/or all of the "first terminal authentication information (Device1.Auth)" and "mobile preparation selection information" described above may be digitally signed using the certificate eUICC1.Cert of the first terminal.

Referring to FIG. 17 , in step 17025 , the first terminal 1710 sends “first terminal authentication information (Device1.Auth)” and/or “movement preparation selection information” and/or “step 17020 to the RSP server 1730 . Electronic signature information generated by ” can be transmitted.

Referring to FIG. 17 , in step 17030 , the RSP server 1730 may verify the received “first terminal authentication information (Device1.Auth)”. The RSP server 1730 may check the validity of the eUICC1.Cert included in the “first terminal authentication information (Device1.Auth)” and may check the validity of the received electronic signature using the eUICC1.Cert. The RSP server may check whether the value of Server.Challege1 included in the “first terminal authentication information (Device1.Auth)” is the same as the value of Server.Challenge1 transmitted by itself in 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, verification may be successful.

In an embodiment, the RSP server may verify that the first terminal is a terminal using the corresponding profile using the received eUICC identifier and profile identifier of the first terminal.

In an embodiment, the RSP server includes “certificate negotiation information used when the second terminal negotiates a certificate with the RSP server” included in the “mobile preparation selection information” and “the profile to be transmitted by the first terminal is By checking the “information used to determine whether the eUICC can be installed and operated normally”, when the second terminal requests a profile to be uploaded by the first terminal later, whether the certificate negotiation between itself and the second terminal will be successful It can be verified whether the corresponding profile can operate normally in the second terminal.

In addition, the RSP server may store the received profile identifier and the eUICCC identifier of the second terminal.

Referring to FIG. 17 , based on the determination result, in step 17035 , the RSP server 1730 may transmit a message requesting a profile (or profile package key) to the first terminal 1710 . This request message may contain a set of data necessary to request the corresponding profile. For example, the request message may include the profile identifier of the profile to be requested. Also, the request message may further include a public key for key agreement of the RSP server. The public key for key agreement of the RSP server may be a temporary key.

Some and/or all of the data included in the above-mentioned request message may be electronically signed using a certificate Server.Cert of the RSP server, and this electronic signature data may be included as a part of the request message.

Referring to FIG. 17 , in step 17040 , when the first terminal 1710 checks the transmitted request message from the RSP server and the verification is successful, the first terminal may prepare a profile package related to the profile requested by the RSP server. For example, the first terminal may verify the validity of the electronic signature included in the request message of the RSP server. Also, the first terminal may verify whether the profile identifier included in the request message of the RSP server matches the identifier of the profile to be transmitted.

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

Part and/or all of the corresponding “profile information to be transmitted by the first terminal to the second terminal” may be encrypted. Some examples of how to generate the encryption key used at this time are as follows.

A) Generate an encryption key using the public key for key agreement of the RSP server provided in step 17035 and the private key for key agreement generated by the first terminal

B) Generate an encryption key using the “public key of the second terminal to be used for generating the encryption key” selected in step 17005 and the private key generated by the first terminal.

The 'profile package' may include the 'public key corresponding to the private key generated by the first terminal'. The 'profile package' may include information related to the above-mentioned encryption key, for example, the key agreement algorithm used to generate the encryption key and/or the encryption algorithm information in which the encryption key will be used.

The content of the above-described profile package may be electronically signed with the certificate eUICC1.Cert of the first terminal, and this electronic signature value may be included as a part of the profile package.

Before generating the profile package, the first terminal may disable the state of the profile to be transmitted.

Referring to FIG. 17 , in step 17045 , the first terminal 1710 may transmit a profile package to the RSP server 1730 .

Referring to FIG. 17 , in step 17050 , the RSP server 1730 may store the received profile package. In addition, the RSP server may link the received profile package and the eUICC identifier of the second terminal. In addition, if the 'encryption key generated using the public key for key agreement of the server and the secret key for key agreement generated by the first terminal' is used for encryption in step 17040, the RSP server is After the encryption key is generated using the 'key and the public key corresponding to the private key generated by the first terminal', the received profile package may be decrypted using the encryption key.

18 is a diagram illustrating a second half procedure of a process of online transmission of a profile from one terminal to another terminal according to some embodiments of the present disclosure.

Although not shown in FIG. 18 , the first terminal 1810 and the second terminal 1850 may include an eUICC and an LPA therein, respectively, as illustrated in FIG. 16 . Also, the RSP server 1830 may mean including one or more RSP servers and/or relay servers and/or operator servers as will be described with reference to FIG. 16 .

Referring to FIG. 18 , in step 18000 , a process in which the second terminal 1850 requests and receives a profile from the RSP server 1830 may be initiated. The initiation process may be initiated in a variety of ways.

For example, when the second terminal receives a code (hereinafter, referred to as an activation code) necessary for requesting a profile, a process of requesting and receiving a profile may be started.

In this case, the activation code received by the second terminal may be input in various ways. For example, the first terminal generates an image such as a QR code including the activation code information and displays it on the screen of the first terminal, and the second user uses the second terminal to scan the code shown on the screen of the first terminal. , the activation code may be input to the second terminal. Alternatively, a connection is established between the first terminal and the second terminal (in this case, a possible connection method is direct device-to-device connection (eg, NFC, Bluetooth, UWB, WiFi-Direct, LTE device-to-device) , 5G D2D) or a remote connection in which a remote server (eg, a relay server) is located between the first terminal and the second terminal.) Through this connection, the activation code may be transmitted to the second terminal. Alternatively, the activation code may be input to the second terminal by the second user inputting 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 accessing the RSP server and/or any server associated with the RSP server to obtain the activation code.

The activation code may include the eUICC identifier of the second terminal. The activation code may include a profile identifier of a profile that the first terminal wants to transmit. The activation code may include the address of the RSP server to which the second terminal needs to access in order to request a profile. The activation code is information used when the first terminal generates an encryption key to encrypt the profile in FIG. 17, for example, the key agreement algorithm used to generate the encryption key and/or the encryption algorithm information in which the encryption key will be used and/or Alternatively, the public key for key agreement used by the first terminal to generate the encryption key may be included.

Alternatively, the starting process may be initiated by the second terminal using a discovery service. For example, after the second terminal accesses the discovery server to check an event, and confirms that a profile down event has occurred, the start process may be started.

Alternatively, the starting process may be initiated by the RSP server notifying the second terminal that an event has occurred. For example, the RSP server or any server associated with the RSP server notifies the second terminal that a profile down event has occurred (eg, a PUSH service of the server may be used), and thus the start process may be started.

Alternatively, the starting process may be initiated by the second user making a profile download request to the second terminal. For example, the starting process may be started by the second user expressing his/her intention to download the profile through the UI provided by the second terminal and providing necessary information for the profile download.

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

Referring to FIG. 18 , in step 18010, the RSP server 1830 may check the received eUICC2.Info1 and generate “RSP server authentication information (Server.Auth2)”. The RSP server 1830 may check whether a version supported by the RSP server 1830 exists among the eUICC versions supported by the second terminal using the received eUICC2.Info1. The RSP server 1830 may select a certificate Server.Cert capable of verifying itself using the received eUICC2.Info1. The RSP server 1830 may select certificate information to be used by the second terminal 1350 using the received eUICC2.Info1. The RSP server 1830 may use the received eUICC2.Info1 to select an encryption algorithm to be used in encryption communication with the second terminal later.

In an 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 the received eUICC2.Challenge. “RSP server authentication information (Server.Auth2)” may include an arbitrary string (Server.Challenge2) generated by the RSP server.

“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 that can verify itself and related certificate chain information. “RSP server authentication information (Server.Auth2)” may include an encryption algorithm to be used in encrypted communication with the second terminal in the future.

Part and/or all of the “RSP Server Authentication Information (Server.Auth2)” described above may be digitally signed using the RSP Server’s certificate Server.Cert, and this digitally signed data is “RSP Server Authentication Information (Server. Auth2)”.

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

Referring to FIG. 18 , in step 18020 , the second terminal 1850 may 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 “RSP server authentication information (Server.Auth2)” and is included in “RSP server authentication information (Server.Auth2)” using Server.Cert. The validity of the signed signature can be further checked. The second terminal 1850 may check whether the value of eUICC2.Challege included in “RSP server authentication information (Server.Auth2)” is the same as the value of eUICC2.Challenge transmitted by itself in step 18005.

The second terminal 1850 may 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 contain the Server.Challenge2 it received.

“Second terminal authentication information (Device2.Auth)” may include information eUICC2.Info2 for conformity check of the eUICC installed in the second terminal. eUICC2.Info2 may be information used to determine whether a profile to be received from the first terminal later can be normally installed and operated in the eUICC of the second terminal. For example, eUICC2.Info2 may include hardware and/or software information of the eUICC installed in the second terminal. Alternatively, eUICC2.Info2 may include hardware and/or software information of the second terminal.

“Second terminal authentication information (Device2.Auth)” may include an eUICC identifier of an eUICC installed in the second terminal. “Second terminal authentication information (Device2.Auth)” may include a profile identifier of a profile requested by the second terminal. “Second terminal authentication information (Device2.Auth)” may include the activation code received in step 18000.

“Second terminal authentication information (Device2.Auth)” may include a public key for key agreement generated by the eUICC of the second terminal.

“Second terminal authentication information (Device2.Auth)” may include a certificate eUICC2.Cert capable of verifying itself and related certificate chain information.

Part and/or all of the "second terminal authentication information (Device2.Auth)" described above may be electronically signed using the certificate eUICC2.Cert of the second terminal, and this electronically signed data is "second terminal authentication information" (Device2.Auth)”.

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

Referring to FIG. 18 , in step 18030 , the RSP server 1830 may verify the received “second terminal authentication information (Device2.Auth)”. The RSP server 1830 may check the validity of eUICC2.Cert included in “Second terminal authentication information (Device2.Auth)”, and use eUICC2.Cert in “Second terminal authentication information (Device2.Auth)” Included signatures can be validated. The RSP server 1830 may check whether the value of Server.Challege2 included in “second terminal authentication information (Device2.Auth)” is the same as the value of Server.Challenge2 transmitted by itself in step 18015 .

The RSP server 1830 checks the information eUICC2.Info2 for the conformity check of the eUICC included in “Second terminal authentication information (Device2.Auth)” and the profile to be transmitted is normally installed in the second terminal and operates You can decide if you can do it.

The RSP server 1830 may check the received eUICC identifier of the second terminal. The RSP server may check whether a profile to be transmitted exists by checking the received eUICC identifier of the second terminal. The RSP server may prepare the profile to be transmitted by checking the received eUICC identifier of the second terminal.

The RSP server 1830 may check the received profile identifier. The RSP server can check whether a profile to be transmitted exists by checking the received profile identifier. The RSP server can prepare the profile to be transmitted by checking the received profile identifier.

The RSP server 1830 may check the received activation code. The RSP server may check the eUICC identifier of the second terminal included in the received activation code. The RSP server may check whether a profile to be transmitted exists by checking the eUICC identifier of the second terminal included in the received activation code. The RSP server may prepare a profile to transmit 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 a profile to be transmitted exists by checking the profile identifier included in the received activation code. The RSP server can prepare the profile to be transmitted by checking the profile identifier included in the received activation code.

The RSP server 1830 may generate an encryption key to be used for encryption using the received “public key for key agreement generated by the eUICC of the second terminal” and “private key for key agreement generated by the RSP server”. The RSP server 1830 may encrypt the profile to be transmitted using the corresponding encryption key.

In step 18030, the RSP server may prepare a profile package related to the profile requested by the second terminal 1850. The corresponding profile package may include profile information to be transmitted from the RSP server to the second terminal.

The profile package includes information used when the first terminal generates an encryption key to encrypt the profile in FIG. 17, for example, the key agreement algorithm used to generate the encryption key and/or encryption algorithm information to which the encryption key will be used, and/or Alternatively, the public key for key agreement used by the first terminal to generate the encryption key may be included.

The profile package contains the information that the RSP server used when generating the encryption key to encrypt the profile, such as the key agreement algorithm used to generate the encryption key and/or the encryption algorithm information in which the encryption key will be used and/or the encryption key generation. It may include the public key for key agreement used by the RSP server for

The contents of the above-described profile package may be digitally signed with a certificate Server.Cert of the RSP server, and this digital signature value may be included as a part of the profile package.

Referring to FIG. 18 , in step 18035 , the RSP server 1830 may transmit a profile package to the second terminal 1850 .

Referring to FIG. 18 , in step 18040 , the second terminal 1850 may install the received profile package. At this time, if part and/or entire contents of the profile package are encrypted by the first terminal, the second terminal uses the received public key for key agreement of the first terminal and the private key for key agreement of the second terminal to obtain the encryption key. After creation, the encrypted content can be decrypted. At this time, if part and/or entire contents of the profile package are encrypted by the RSP server, the second terminal generates an encryption key using the received public key for key agreement of the RSP server and the private key for key agreement of the second terminal. You can then decrypt the encrypted content.

19 is a diagram illustrating a configuration of a terminal equipped with an eUICC according to some embodiments of the present disclosure.

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

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

According to various embodiments, the transceiver 1910 may transmit and receive signals, information, data, etc. according to various embodiments of the present disclosure with a transceiver of another terminal or an external server. The transceiver 1910 may include an RF transmitter for up-converting and amplifying a frequency of a transmitted signal, and an RF receiver for low-noise amplifying and down-converting a frequency of a received signal. . However, this is only an example of the transceiver 1910, and components of the transceiver 1910 are not limited to the RF transmitter and the RF receiver. Also, the transceiver 1910 may receive a signal through a wireless channel and output it to the processor 1920 , and transmit the signal output from the processor 1920 through a wireless channel.

Meanwhile, the processor 1920 is a component for overall controlling the terminal. The processor 1920 may control the overall operation of the terminal according to various embodiments of the present disclosure as described above.

Meanwhile, the terminal may further include a memory (not shown), and may store data such as a basic program, an application program, and setting information for the operation of the terminal. In addition, the memory is a flash memory type (Flash Memory Type), a hard disk type (Hard Disk Type), a multimedia card micro type (Multimedia Card Micro Type), card type memory (eg, SD or XD memory, etc.), magnetic Memory, magnetic disk, optical disk, RAM (Random Access Memory, RAM), SRAM (Static Random Access Memory), ROM (Read-Only Memory, ROM), PROM (Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read- Only Memory) may include at least one storage medium. In addition, the processor 1920 may perform various operations using various programs, contents, data, etc. stored in the memory.

20 is a diagram illustrating a configuration of an RSP server according to some embodiments of the present disclosure.

Referring to FIG. 20 , the server may include a transceiver 2010 and a processor 2020 . Some of the server(s) described above in the present disclosure may correspond to the server described in FIG. 20 . For example, the server(s) described with reference to FIGS. 16 to 18 may include the configuration of the server described with reference to FIG. 20 .

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

According to some embodiments, the transceiver 2010 may transmit and receive signals, information, data, etc. according to various embodiments of the present disclosure with the terminal. The transceiver 2010 may include an RF transmitter for up-converting and amplifying a frequency of a transmitted signal, and an RF receiver for low-noise amplifying and down-converting a received signal. However, this is only an example of the transceiver 2010, and components of the transceiver 2010 are not limited to the RF transmitter and the RF receiver. In addition, the transceiver 2010 may receive a signal through a wireless channel and output it to the processor 2020 , and transmit the signal output from the processor 2020 through a wireless channel.

Meanwhile, at least one processor 2020 is a component for controlling the server as a whole. The processor 2020 may control the overall operation of the server according to various embodiments of the present disclosure as described above. The at least one or more processors 2020 may be referred to as a control unit.

Meanwhile, the server may further include a memory (not shown), and may store data such as a basic program, an application program, and setting information for the operation of the server. In addition, the memory is a flash memory type (Flash Memory Type), a hard disk type (Hard Disk Type), a multimedia card micro type (Multimedia Card Micro Type), card type memory (eg, SD or XD memory, etc.), magnetic Memory, magnetic disk, optical disk, RAM (Random Access Memory, RAM), SRAM (Static Random Access Memory), ROM (Read-Only Memory, ROM), PROM (Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read- Only Memory) may include at least one storage medium. In addition, the processor 2020 may perform various operations using various programs, contents, data, etc. stored in the memory.

21 is a diagram conceptually illustrating another example of a procedure for online transmission of a profile from one terminal to another terminal according to an embodiment of the present disclosure.

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 includes a first LPA 2130 and a first eSIM 2120 , and the second terminal 2160 includes a second LPA 2180 and a second terminal 2160 . 2 eSIMs 2170 may be included. For the description of the RSP server, reference will be made to the above contents (eg, FIG. 16 ).

In operation 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.

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

In step 2110 , the first terminal 2110 may 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 to be described later.

In step 21015 , the second terminal 2160 may 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 which will be described later.

22 is a diagram illustrating a detailed procedure for a procedure for preparing for profile transmission according to an embodiment of the present disclosure.

Referring to FIG. 22 , the terminal may include at least one LPA and at least one eSIM. For example, the first terminal 2210 includes a first LPA 2230 and a first eSIM 2220 , and the second terminal 2260 includes a second LPA 2280 and a second eSIM 2270 . can do.

According to various embodiments, the first terminal 2210 may have a pre-installed profile, and may further hold metadata associated with the pre-installed profile. According to various embodiments, the first terminal 2210 may have a 'profile identifier' associated with a pre-installed profile.

According to various embodiments, the first terminal 1010 may have a 'profile movement setting' related to a pre-installed profile. According to various embodiments, the 'profile movement setting' is a set of policies related to the movement of the corresponding profile between devices, and may be generated by the communication service provider, the RSP server, or the aforementioned communication service provider. It may have been created by collaboration of the RSP server. According to various embodiments, the 'profile movement setting' inside the terminal may be updated by a communication service provider, an RSP server, or collaboration between a communication service provider and an RSP server. Alternatively, at least one subject of a communication service provider and an RSP server and the terminal may collaborate to update the 'profile movement setting'. The time and/or method at which the 'profile movement setting' is updated may be determined by a policy of a telecommunication service provider, RSP server, terminal manufacturer, and the like.

The 'profile movement setting' may include a factor (or an indication) indicating whether transmission of the corresponding profile between devices is permitted. In addition, the 'profile movement setting' may optionally further include a factor specifying under what conditions transmission is allowed when the device-to-device transmission of the corresponding profile is allowed. For example, in 'profile movement setting', it may be set whether a corresponding profile can be transmitted (or moved) online from one terminal to another terminal. As another example, in the 'profile movement setting', the form in which the corresponding profile can be transmitted may be set. For example, the profile may be transmitted in the form of a profile package or in the form of a profile image, and some data of the profile (eg, may mean part or all of a series of updates that have occurred after the profile is installed in the first terminal. In this update, only data stored by the user, values set by the user, or update history performed by the carrier or RSP server) may be transmitted. The profile movement setting may include information on which method(s) among the possible transmission types of the above-described profile are allowed. These factors may be digitally signed by at least one of an RSP server, a communication service provider, a terminal manufacturer, an eUICC, and an eUICC manufacturer. The corresponding electronic signature value may be stored in the first terminal as part of the 'profile movement setting' or together with the 'profile movement setting'.

Referring to FIG. 22 , in step 22000 , the first LPA 2230 may acquire information on a profile to be transmitted. Alternatively, information of the profile to be transmitted may be transmitted to the first LPA 2230 . For example, the first LPA 2230 may obtain information on a profile to be transmitted by receiving a user input for selecting a profile through a UI provided by the user first terminal 2210, or a push input from a remote server. Information on the profile to be transmitted may be input to the first LPA 2230, or the first LPA 2230 may access the remote server and read information on the profile to be transmitted. However, the method of obtaining the information of the profile to be transmitted by the first LPA 2230 is not limited thereto.

Referring to FIG. 22 , in step 22005 , the first LPA 2230 may check whether the corresponding profile can be transmitted using 'profile move setting'. Also, the first LPA 2230 may check 'profile movement setting' to determine whether the corresponding profile can be transmitted online. In addition, the first LPA 2230 may check the 'profile movement setting' and check in what form (profile image, profile package, partial data of the profile, etc.) the corresponding profile can be transmitted.

Referring to FIG. 22 , in step 22010 , the first LPA 2230 may generate a 'profile transmission code'. The profile transmission code may include the 'profile identifier' of the profile to be transmitted. In addition, the profile transmission code may include the address of the RSP server related to the profile to be transmitted. (In the future, the second terminal 2260 may use this address to access the RSP server and download the profile.) In addition, the profile transmission code includes other information indicating the properties of the profile (eg, profile metadata or meta data). part of the data) may be further included. In addition, the profile transmission code may include information on encryption algorithms supported by the first terminal (eg, the first eSIM) (Supported Crypto Info). Information on encryption algorithms supported by the first terminal may selectively include one or more of the following information; A list of elliptic curve curves supported by the first terminal, a list of key agreement algorithms supported by the first terminal, and an encryption algorithm list supported by the first terminal.

Referring to FIG. 22 , in step 22015 , the profile transmission code generated in step 22010 may be transmitted from the first LPA 2230 to the second LPA 2280 . The profile transmission code may be transmitted in a variety of ways.

For example, the first LPA 2230 may 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 may provide the received information to the second user of the second terminal. The second user may input the provided information into the second LPA using the UI of the second terminal.

Alternatively, the first LPA 2230 makes information to be transmitted to the second LPA 2280 in the form of an image (eg, a QR code) and displays it on the screen of the first terminal, and the second user is the first terminal Information can be transmitted to the second LPA by scanning the image displayed on the screen of the second terminal using the second terminal.

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 the established connection. In this case, the connection established between the first LPA 2230 and the second LPA 2280 is a direct device-to-device connection (eg, NFC, Bluetooth, UWB, WiFi-Direct, LTE device-to-device (D2D), 5G D2D wired connection such as wireless connection and cable connection) or a remote connection in which a remote server (eg, a relay server) is located between the first LPA 2230 and the second LPA 2280 .

23 is a diagram illustrating a procedure in which the second terminal 2360 requests profile transmission to the RSP server 2350 according to an embodiment of the present disclosure.

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 . A description of the RSP server 2350 will refer to FIG. 16 .

Referring to FIG. 23 , in 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.

- The mutual authentication process may include a certificate negotiation process that the second terminal and the RSP server must go through in order to communicate. For example, the second terminal may transmit 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 to the RSP server. Upon receiving this information, the RSP server may select certificate information to be used by the second terminal to verify the RSP server and/or certificate information to be used by the RSP server to verify the second terminal. In this case, 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 acquire certificate information that can authenticate each other. In this case, the certificate information may be a certificate and/or information included in the certificate and/or a series of information that may refer to the certificate.

- The second terminal may transmit a random number (eUICC Challenge) value generated by it to the RSP server. The RSP server may digitally sign the received random number value and then transmit the signature value to the second terminal. The second terminal may authenticate the RSP server by verifying the received signature value.

- The RSP server may transmit a random number (server challenge) value generated by the RSP server to the second terminal. After digitally signing the received random number value, the second terminal may transmit the signature value to the RSP server. The RSP server may authenticate the second terminal by verifying the received signature value.

- While the RSP server and the second terminal communicate, an ID (Transaction ID) for managing a session may be exchanged. For example, the RSP server may generate a transaction ID and transmit this value to the second terminal. In this case, the digital signature value of the RSP server may be added to verify the reliability and integrity of the transaction ID.

- The RSP server and the second terminal may exchange a profile identifier associated with a profile to be transmitted in the present disclosure. For example, the second terminal may transmit the identifier of the profile to be transmitted to the RSP server. In this case, the profile identifier may be transmitted together with the electronic signature value of the second terminal to ensure reliability and integrity.

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

Referring to FIG. 23 , the following process may be performed in step 23005 .

The RSP server 2350 may check 'profile movement setting'. For example, the RSP server 2350 may check the received profile identifier, check the 'profile move setting' associated with the corresponding profile, and check whether the corresponding profile can be transmitted. Also, the RSP server 2350 may check 'profile move setting' to check whether the corresponding profile can be transmitted online. In addition, the RSP server 2350 may check the 'profile movement setting' to determine in what form (profile image, profile package, partial data of the profile, etc.) the corresponding profile can be transmitted.

The RSP server 2350 may perform an 'Eligibility Check' to check whether the corresponding profile can be installed and used in the second terminal. For example, the RSP server 2350 may check whether the corresponding profile can be installed and operated in the second terminal using the received eUICC identifier of the second terminal and the received profile identifier.

The RSP server 2350 may generate a transfer option in response to the bundle reception request of the second terminal. The transmission option may include information on whether the corresponding profile can be transmitted to the second terminal, and if transmission is possible, in what form transmission is possible. For example, the transmission option may include at least one of the following values.

- Profile transmission possible in the form of a profile image

- Profile can be transmitted in the form of a profile package

- Some data types in the profile can be transmitted

- Profile transfer not possible

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 together with a transmission option. In addition, the certificate and related information of the RSP server including the encryption key used for the digital signature may be transmitted to the second LPA 2380 .

Referring to FIG. 23 , the following process may be performed in step 23010 .

The second LPA 2380 may receive the user's consent after confirming the received transmission option.

The second LPA 2380 may transmit the received transmission option to the second eSIM 2370 . The second LPA 2380 may transmit the received signature value of the transmission option to the second eSIM 2370 . The second LPA 2380 may transmit a certificate and related information to be used to verify the digital signature value of the received transmission option to the second eSIM 2370 .

The second LPA 2380 may further selectively transmit the 'Supported Crypto Info' received in step 22015 to the second eSIM 2370 .

Referring to FIG. 23 , the following process may be performed in step 23015 .

The second eSIM 2370 may verify the validity of the received certificate and related information in step 23010 .

The second eSIM 2370 may verify the validity of the digital signature value received in operation 23010 .

The second eSIM 2370 may check the content of the transmission option received in step 23010 .

When the 'Supported Crypto Info' is received, the second eSIM 2370 may check the contents of the received 'Supported Crypto Info' and check whether an encryption algorithm supported by the second eSIM 2370 exists. If there are encryption algorithms supported by the second eSIM among the received supported Crypto Info, the second eSIM 2370 may select one of them and set it as the 'Selected Crypto Info'. The 'selected encryption algorithm' may optionally include one or more of the following information: elliptic curve information, key agreement algorithm information, and encryption algorithm information.

The second eSIM 2370 may generate a public key “otPK.EUICC.KA” and a private key “otSK.EUICC.KA” that are key pairs for encryption to be used to create an encryption key for encrypted communication. At this time, the generated encryption key may be for 'encrypted communication between the RSP server and the second terminal' or may be for 'encrypted communication between the first terminal and the second terminal'. At this time, if the generated encryption key is for 'encrypted communication between the first terminal and the second terminal', the encryption keys (otPK.EUICC.KA and otSK.EUICC.KA) are encrypted included in the above-described Selected Crypto Info. It may be an encryption key that follows an algorithm.

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

The second eSIM 2370 may further selectively transmit the Selected Crypto Info to the RSP server 2350 via the second LPA 2380 .

24 is a diagram illustrating a procedure in which the first terminal 2410 uploads the 'profile to be transmitted to the second terminal' to the RSP server 2450 according to an embodiment of the present disclosure.

Referring to FIG. 24 , the UE 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 . A description of the RSP server 2450 will refer to FIG. 16 .

Referring to FIG. 24 , in 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.

- The mutual authentication process may include a certificate negotiation process that the first terminal 2410 and the RSP server 2450 must go through in order to communicate. For example, the first terminal 2410 may use certificate information that can be used to verify the RSP server 2450 and/or the certificate information that the RSP server 2450 can use to verify the first terminal 2410 of the RSP. may be transmitted to the server 2450 . The RSP server 2450 that has received this information verifies the certificate information to be used by the first terminal 2410 to verify the RSP server 2450 and/or the RSP server 2450 verifies the first terminal 2410 . You can select the certificate information to be used for In this case, 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 may acquire certificate information that can authenticate each other. In this case, the certificate information may be a certificate and/or information included in the certificate and/or a series of information that may refer to the certificate.

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

- The RSP server 2450 may transmit a random number (server challenge) value generated by the RSP server 2450 to the first terminal 2410 . After digitally signing the received random number value, the first terminal 2410 may transmit the signature value to the RSP server 2450 . The RSP server 2450 may authenticate the first terminal 2410 by verifying the received signature value.

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

- The RSP server 2450 and the first terminal 2410 may exchange a profile identifier associated with a profile to be transmitted in the present disclosure. For example, the first terminal 2410 may transmit the identifier of the profile to be transmitted to the RSP server 2450 . In this case, the profile identifier may be transmitted together with the digital signature value of the first terminal 2410 to ensure reliability and integrity.

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

Although not shown in the drawing, the first terminal 2410 may wait between steps 24000 and 24005.

Referring to FIG. 24 , the following process may be performed in step 24005 .

The RSP server 2450 includes a public key "otPK.DP.KA" and a private key "otSK.DP.KA" which are a key pair for encryption to be used to create an encryption key for encrypted communication with the first eSIM 2420 . " can be created.

The RSP server 2450 may transmit the public key otPK.XX.KA to the first eSIM 2420 via the first LPA 2430 . In this case, otPK.XX.KA may be otPK.EUICC.KA received in step 23015 or otPK.DP.KA.

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

- Profile transmission possible in the form of a profile image

- Profile can be transmitted in the form of a profile package

- Some data types in the profile can be transmitted

- Profile transfer not possible

In this case, the otPK.XX.KA and/or the transmission option 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 through the first LPA 2430 . In addition, the certificate and related information of the RSP server that can be used to verify the electronic signature may be transmitted to the first eSIM 2420 via the first LPA 2430 .

The RSP server 2450 may further selectively transmit the Selected Crypto Info received in step 23015 to the first eSIM 2420 via the first LPA 2430 .

The first terminal 2410 (eg, the first LPA 2430) may receive user consent in relation to the received transmission option.

Referring to FIG. 24 , the following process may be performed in step 24010 .

The first eSIM 2420 may verify the validity of the received certificate and related information in operation 24005 .

The first eSIM 2420 may verify the validity of the digital signature value received in operation 24005 .

The first eSIM 2420 may check the content of the transmission option received in step 24005 .

The first eSIM 2420 may generate a public key “otPK.EUICC.KA” and a private key “otSK.EUICC.KA” that are key pairs for encryption to be used to create an encryption key for encrypted communication. In this case, the generated encryption key may be for 'encrypted communication between the RSP server and the first terminal' or may be for 'encrypted communication between the first terminal and the second terminal'. Whether the generated encryption key is used for encryption communication may be determined according to a value of otPK.XX.KA received in step 24005. The first eSIM 2420 may calculate the digital signature value of the generated otPK.EUICC.KA. The above-described otPK.EUICC.KA and/or digital signature value may be collectively referred to as Device1.Auth.

The first eSIM 2420 may generate a session key to be used for encrypted communication by using "otSK.EUICC.KA" generated by it and otPK.XX.KA received in step 24005.

The first eSIM 2420 may prepare a profile to be transmitted to the second terminal (in some cases, with the help of the first LPA). At this time, the type of the prepared profile may correspond to the transmission option received in step 24005, that is, the type of the prepared profile may be one of the following.

- profile image

- Profile package

- some data in the profile

All and/or part of the prepared profile may be encrypted by the above-described session key. In addition, all and/or part of the prepared profile may be electronically signed by the first terminal, and this electronic signature value may be included as a part of the prepared profile.

The first eSIM 2420 may delete the corresponding profile. Whether to delete the corresponding profile may be notified to the RSP server 2450 .

The first eSIM 2420 may transmit Device1.Auth and/or a 'prepared profile' to the RSP server 2450 via the first LPA 2430 .

Referring to FIG. 24 , in step 24015 , the RSP server 2450 may transmit a response message informing the first LPA 2430 that all processes have been performed.

25 is a diagram illustrating a procedure for the second terminal 2560 to download and install the 'prepared profile' uploaded from the RSP server 2550 according to an embodiment of the present disclosure.

Referring to FIG. 25 , the UE 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 . A description of the RSP server 2550 will be referred to FIG. 16 .

Although not shown in the drawing, the second terminal 2560 may wait for step 25000 to be described later to be performed after performing step 23015 shown in FIG. 23 . This waiting process can be implemented in various ways described below. However, the waiting process is not limited thereto, and the waiting process is not necessarily one of the methods described below.

a) The RSP server 2550 may send a message to the second LPA 2580 indicating that it has received the requested operation but must wait until a response is received. The second LPA 2580 may transmit a message to the RSP server 2550 to check whether the requested operation is completed after waiting a predetermined time. If the operation is completed, step 25000 may be performed. If the execution of the operation is not completed, the RSP server 2550 may send a message indicating that it should wait a little longer. In this case, the second LPA 2580 may send a message back to the bundle management server to check whether the requested operation is completed after waiting for a predetermined time again. The above process may be repeated until step 25000 is performed.

b) The second LPA 2580 may wait for step 25000 to be performed within a predetermined time range. If step 25000 is not performed within a predetermined time, the profile transmission process may be interrupted.

c) The RSP server 2550 may notify the second LBA 2580 that the requested operation has been received. (For example, the RSP server may transmit a push message to the second LBA.) After that, step 25000 may be performed.

Referring to FIG. 25 , the following process may be performed in step 25000 .

The RSP server 2550 may verify the validity of the digital signature value of Device2.Auth received in step 23015 .

The RSP server 2550 may check the contents of Device2.Auth received in step 23015 .

The RSP server 2550 may generate a public key “otPK.DP.KA” and a private key “otSK.DP.KA” that are key pairs for encryption to be used to create an encryption key for encrypted communication. In this case, the generated encryption key may be for 'encrypted communication between the RSP server and the second terminal'. The RSP server may generate a session key for encrypted communication with the second terminal using the generated key pair for encryption.

The RSP server 2550 may prepare a Bound Profile to be transmitted to the second terminal.

In this case, the prepared Bound Profile may be in one of the following forms.

- Profile image received in step 24010

- Profile package received in step 24010

- Profile package and/or image created including some data of the profile received in step 24010

- Profile package and/or image including some data of the profile received in step 24010 as additional data

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

The RSP server 2550 may transmit the Bound Profile to the second LPA 2580 .

Referring to FIG. 25 , the following process may be performed in step 25005 .

The second LPA 2580 may verify the received Bound Profile. For example, the second LPA 2580 may check and verify the content of metadata included in the Bound Profile. In addition, the second LPA 2580 may receive user consent in relation to whether the Bound Profile exists.

The second LPA 2580 and the second eSIM 2570 may install the Bound Profile received in the second eSIM.

Referring to FIG. 25 , in step 25010 , the second eSIM 2570 may notify the RSP server 2500 that the profile has been installed through the second LPA 2580 .

In the specific embodiments of the present disclosure described above, components included in the disclosure are expressed in the singular or plural according to the specific embodiments presented. However, the singular or plural expression is appropriately selected for the context presented for convenience of description, and the present disclosure is not limited to the singular or plural element, and even if the element is expressed in plural, it is composed of the singular or singular. Even an expressed component may be composed of a plurality of components.

Meanwhile, although specific embodiments have been described in the detailed description of the present disclosure, various modifications are possible without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments and should be defined by the claims described below as well as the claims and equivalents.

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 a specific embodiment, and should be understood to include various modifications, equivalents, and/or substitutions of the embodiments. In connection with the description of the drawings, like reference numerals may be used for like components. The singular expression may include the plural expression unless the context clearly dictates otherwise. In this disclosure, expressions such as "A or B", "at least one of A and/or B", "A, B or C" or "at least one of A, B and/or C", etc., refer to all of the items listed together. Possible combinations may be included. Expressions such as "first", "second", "first" or "second" can modify the corresponding elements regardless of order or importance, and are only used to distinguish one element from another element. The components are not limited. When an (eg, first) component is referred to as being “(functionally or communicatively) connected” or “connected” to another (eg, second) component, that component is It may be directly connected to the component, or may be connected through another component (eg, a third component).

The term “module” used in the present disclosure includes a unit composed of hardware, software, or firmware, and may be used interchangeably with terms such as, for example, logic, logic block, component, or circuit. A module may be an integrally formed part or a minimum unit or a part of one or more functions. For example, the module may be configured as an application-specific integrated circuit (ASIC).

Various embodiments of the present disclosure provide software (eg, a program) including instructions stored in a machine-readable storage media (eg, an internal memory or an external memory) readable by a machine (eg, a computer). can be implemented as A device is a device capable of calling a stored command from a storage medium and operating according to the called command, and may include a terminal according to various embodiments. When the instruction is executed by a processor (eg, the processor 1420 of FIG. 14 ), the processor may directly or use other components under the control of the processor to perform a function corresponding to the instruction. Instructions may include code generated or executed by a compiler or interpreter.

The device-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' means that the storage medium does not include a signal and is tangible, and does not distinguish that data is semi-permanently or temporarily stored in the storage medium.

Methods according to various embodiments disclosed in the present disclosure may be provided by being included in a computer program product. Computer program products may be traded between sellers and buyers as commodities. The computer program product may be distributed in the form of a machine-readable storage medium (eg, compact disc read only memory (CD-ROM)) or online through an application store (eg, Play Store™). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated in a storage medium such as a memory of a server of a manufacturer, a server of an application store, or a memory of a relay server. Configuration according to various embodiments Each element (eg, module or program) may be composed of a singular or a plurality of entities, and some sub-components of the aforementioned sub-components may be omitted, or other sub-components may be further included in various embodiments. have. Alternatively or additionally, some components (eg, a module or a program) may be integrated into a single entity to perform the same or similar functions performed by each corresponding component prior to integration. According to various embodiments, operations performed by a module, program, or other component may be sequentially, parallel, repetitively or heuristically executed, or at least some operations may be executed in a different order, omitted, or other operations may be added. can

Claims (2)

A method for a first terminal to provide a bundle to a second terminal, the method comprising:
obtaining information about a bundle to be transmitted to the second terminal;
transmitting the 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 for uploading the bundle to a server based on at least one of the received encryption information and bundle use information of a second terminal; and
and uploading the bundle to the server based on the authentication procedure. A method for a second terminal to receive a bundle from a first terminal, the method comprising:
receiving a transmission code of the bundle from the first terminal;
generating at least one of encryption information and bundle use information of a 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 for downloading the bundle with a server; and
and downloading the bundle from the server based on the authentication procedure.

Images