Method and device for moving profiles with different versions during device change

Abstract

The disclosure relates to a communication method and system for a fifth generation (5G) communication system for converging a next 4th generation (4G) system with a beyond 4G system supporting higher data rates beyond a fourth generation (4G) system and an Internet of Things (IoT) technology. The disclosure is applicable to smart services based on 5G communication technology and IoT-related technology, such as smart home, smart building, smart city, smart car, connected car, health care, digital education, smart retail, security and safety services. The disclosure provides a method and device that enable device change when two devices having different versions, which support a device change method, attempt device change.

Description

Technical Field

[0001] This invention relates to a smart security medium, and more specifically, to a method and apparatus for making device changes between smart security media that support different versions of device change methods. Background Technology

[0002] To meet the increased demand for wireless data services since the deployment of 4G communication systems, efforts have been made to develop improved 5G or pre-5G communication systems. Therefore, 5G or pre-5G communication systems are also referred to as "super 4G networks" or "post-LTE systems." 5G communication systems are considered to be implemented in higher frequency (millimeter wave) bands, such as the 60GHz band, to achieve higher data rates. To reduce radio wave propagation loss and increase transmission distance, beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO technologies have been discussed in 5G communication systems. Furthermore, in 5G communication systems, development is underway for system network improvements based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, coordinated multipoint (CoMP), and receiver interference cancellation. In 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) as advanced coding modulation (ACM), as well as filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access technologies, have been developed.

[0003] The Internet, a human-centric network for generating and consuming information, is now evolving into the Internet of Things (IoT), where distributed entities, such as things, exchange and process information without human intervention. The Internet of Everything (IoE) is an internet that combines IoT technology and big data processing technology through connections to cloud servers. IoT implementation requires technological elements such as sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology. Recently, sensor networks, machine-to-machine (M2M) communication, and machine-type communication (MTC) have been studied. This IoT environment can provide intelligent Internet technology services that create new value for human life by collecting and analyzing data generated between connected things. Through the convergence and combination of existing information technology (IT) and various industrial applications, IT can be applied to a wide range of fields, including smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart devices, and advanced medical services.

[0004] Consistent with this, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, machine-type communication (MTC), and machine-to-machine (M2M) communication can be implemented using beamforming, MIMO, and array antennas. The application of cloud radio access networks (RAN), as a big data processing technology, can also be seen as an example of the convergence between 5G and IoT technologies.

[0005] As stated above, with the development of mobile communication systems, various services can be provided, thus requiring a solution for efficiently providing these services. For example, a method is needed to transmit profiles or services associated with those profiles when a device changes. Furthermore, when different device change methods exist and two devices support different device change methods, a method is needed that can support device changes between the two devices. Summary of the Invention

[0006] [Technical Issues]

[0007] Embodiments of this disclosure provide a method for performing device changes and a device capable of performing the method, which addresses a problem that may arise when the device change methods differ between two electronic devices when performing device changes between security modules included in two electronic devices.

[0008] [Solution to the problem]

[0009] According to embodiments of this disclosure, a method is provided performed by a first device of a first version in a communication system. The method of the first device includes: identifying a profile of the first device to be downloaded to a second device of a first version or a second version; identifying third code for downloading the profile based on first code for the first version and second code for the second version; sending the third code to the second device; and sending the profile to a profile server based on the transmission of the third code.

[0010] According to embodiments of this disclosure, a method is provided performed by a second device in communication, either a first version or a second version. The method of the second device includes: receiving, from the first device of the first version, the third code for downloading a profile of the first device, the third code being identified based on the first code for the first version and the second code for the second version; if the second device is a first version, sending the first code from the third code to a profile server; if the second device is a second version, sending the second code from the third code to the profile server; and receiving a profile from the profile server based on the sending of the first code or the second code.

[0011] According to embodiments of this disclosure, a method performed by a profile server in a communication system is provided. The profile server method includes: receiving one of a first code or a second code from a second device of a first version or a second version; identifying, based on the first code or the second code, a version of a first device on which a profile to be downloaded to the second device is installed; receiving the profile from the first device based on the identified version of the first device; and sending the profile to the second device.

[0012] According to embodiments of this disclosure, a first UE of a first version is provided in communication. The first UE includes: a transceiver; and a processor configured to: identify a profile of a first device to be downloaded to a second device of a first version or a second version; identify a third code for downloading the profile based on a first code for the first version and a second code for the second version; send the third code to the second device via the transceiver; and send the profile to a profile server via the transceiver based on the transmission of the third code.

[0013] According to embodiments of this disclosure, a second UE is provided in communication, either a first version or a second version. The second UE includes: a transceiver; and a processor configured to: receive, via the transceiver, a third code for downloading a profile of the first device using the first version, the third code being identified based on the first code for the first version and the second code for the second version; if the version of the second device is the first version, transmit the first code from the third code to a profile server via the transceiver; if the version of the second device is the second version, transmit the second code from the third code to the profile server via the transceiver; and based on the transmission of the first code or the second code, receive a profile from the profile server via the transceiver.

[0014] According to embodiments of this disclosure, a profile server in a communication system is provided. The profile server includes: a transceiver; and a processor configured to: receive, via the transceiver, one of a first code or a second code from a second device of a first version or a second version; identify, based on the first code or the second code, a version of the first device on which a profile to be downloaded to the second device is installed; receive the profile from the first device via the transceiver based on the identification of the version of the first device; and send the profile to the second device via the transceiver.

[0015] Before proceeding with the following detailed description, it may be advantageous to define certain words and phrases used in this patent document: the terms “comprising” and “including” and their derivatives mean including but not limited to; the term “or” is inclusive, referring to and / or; the phrases “associated with” and “associated with” and their derivatives may mean including, being included, interconnected with, containing, being contained, connected to or connected to, linked to or connected to, able to communicate with, cooperate with, interleaved, juxtaposed, adjacent, bound to or bound to, having, having the nature of, etc.; and the term “controller” means any device, system or part thereof that controls at least one operation, such device may be implemented in hardware, firmware, or software, or at least a combination thereof. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether local or remote.

[0016] Furthermore, the various functions described below can be implemented or supported by one or more computer programs, each computer program being formed by computer-readable program code and contained in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, associated data, or portions thereof suitable for implementation in appropriate computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium accessible by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, optical disc (CD), digital video disc (DVD), or any other type of storage. "Non-transitory" computer-readable media excludes wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable media includes media that can permanently store data, as well as media that can store data and subsequently rewrite it, such as rewritable optical discs or erasable storage devices.

[0017] Definitions of certain words and phrases are provided throughout this patent document, and those skilled in the art will understand that, in many, if not most, cases, such definitions apply to the existing and future use of the words and phrases so defined.

[0018] [Beneficial effects of the invention]

[0019] According to various embodiments of this disclosure, device changes can be performed between two devices that support different versions of the device change method. Attached Figure Description

[0020] The above and other aspects, features, and advantages of certain embodiments of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0021] Figure 1 This is a diagram illustrating a method for connecting to a mobile communication network using a device with a pre-installed UICC according to an embodiment of the present disclosure.

[0022] Figure 2 This is a diagram illustrating an example of a method of interoperation between two devices and a server according to an embodiment of the present disclosure, such that a profile or a service associated with a profile can be transmitted from one device to another.

[0023] Figure 3 This is a diagram illustrating the first step of the "first version of device modification" process according to an embodiment of the present invention.

[0024] Figure 4 This is a diagram illustrating the second step of the "device change of the first version" process according to an embodiment of the present invention.

[0025] Figure 5 This is a diagram illustrating the first step of the "second version of device change" process according to an embodiment of the present invention.

[0026] Figure 6 This is a diagram illustrating the second step of the "second version of device change" process according to an embodiment of the present invention.

[0027] Figure 7 This is a diagram illustrating the third step of the "second version of device change" process according to an embodiment of the present invention.

[0028] Figure 8 This is a diagram illustrating the fourth step of the "second version of device change" process according to an embodiment of the present invention.

[0029] Figure 9 This is a diagram illustrating the first step of a process in which a source device performing a "second version of device change" operation attempts to perform a "second version of device change" on a target device or on a target device performing a "first version of device change" according to an embodiment of the present disclosure.

[0030] Figure 10 This is a diagram illustrating the second step of a process in which a source device performing a "second version of device change" operation attempts to perform a "first version of device change" on a target device according to an embodiment of the present invention.

[0031] Figure 11 This is a diagram illustrating the structure of a device equipped with an embedded universal integrated circuit card (eUICC) according to an embodiment of the present invention.

[0032] Figure 12 This is a diagram illustrating the structure of a Remote User Identity Module (SIM) Provision (RSP) server according to an embodiment of the present invention. Detailed Implementation

[0033] The following discussion Figures 1 to 12 The various embodiments used to describe the principles of this disclosure in this patent document are merely exemplary and should not be construed as limiting the scope of this disclosure in any way. Those skilled in the art will understand that the principles of the invention can be implemented in any suitably arranged system or device.

[0034] In the following, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

[0035] In describing the embodiments, descriptions of technical content that is well-known in the technical field to which this disclosure pertains and is not directly related to this disclosure are omitted in order to clearly convey the key points of this disclosure without obscuring them by omitting unnecessary descriptions.

[0036] For the same reason, some components are shown enlarged, omitted, or schematically in the accompanying drawings. Furthermore, the dimensions of each component do not accurately reflect its actual size. Identical or similar components are given the same reference numerals in the drawings.

[0037] The advantages and features of this disclosure, as well as the methods for achieving such advantages and features, will become apparent from the embodiments described in detail with reference to the accompanying drawings. However, this disclosure is not limited to the disclosed embodiments, but can be implemented in a variety of different forms. The embodiments provided are merely illustrative of the purpose of this disclosure and fully inform those skilled in the art of the category to which this disclosure pertains. This disclosure is defined by the category of the claims. Throughout the specification, the same reference numerals denote the same parts.

[0038] In this disclosure, it will be understood that each box in a flowchart, and combinations of boxes in a flowchart, can be executed by computer program instructions. These computer program instructions may be mounted on a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus, such that the instructions, which execute on the processor of the computer or other programmable data processing apparatus, create means for performing the functions specified in the flowchart boxes. These computer program instructions may also be stored in a computer-usable or computer-readable storage medium that can direct the computer or other programmable data processing apparatus to perform its functions in a particular manner, such that the instructions stored in the computer-usable or computer-readable storage medium produce an article of art comprising an instruction means for performing the functions specified in the flowchart boxes. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable data processing apparatus, thereby producing a process executed by the computer, such that the instructions executing the computer or other programmable data processing apparatus provide steps for performing the functions described in the flowchart boxes.

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

[0040] The term "unit" as used in this embodiment refers to a software or hardware component, such as an FPGA or ASIC, and a "unit" performs a specific task. However, the term "unit" does not imply that it is limited to software or hardware. A "unit" may advantageously be configured to reside on addressable storage media and to operate on one or more processors. Therefore, a "unit" can include components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functionality provided in components and "units" can be combined into fewer components and "units," or can be further separated into additional components and "units." Furthermore, components and "units" can be implemented to operate on one or more CPUs within a device or secure multimedia card.

[0041] In this disclosure, modifiers such as "first" or "second" can be used to distinguish terms when describing embodiments. Terms modified by modifiers, such as "first" or "second," can represent different objectives. However, terms modified by modifiers, such as "first" or "second," can represent the same objective. That is, modifiers such as "first" or "second" can be used to represent the same objective from different viewpoints. For example, modifiers such as "first" or "second" can be used to distinguish the same objective in terms of functionality or operation. For example, "first end user" and "second end user" can represent the same user.

[0042] Furthermore, in this disclosure, embodiments are described using a Universal Integrated Circuit Card (UICC) as an example of a security medium; however, the scope of this disclosure is not limited to UICCs. For example, the various embodiments described below will be similarly or analogously applied to other security media that perform substantially the same or similar functions as UICCs, and will be readily apparent to those skilled in the art.

[0043] Specific terminology used in the embodiments of this disclosure is provided to aid in understanding the disclosure. The use of such specific terminology may be modified in other ways without departing from the technical spirit of this disclosure.

[0044] "UICC" is a smart key inserted and used in mobile communication terminals, and can also be referred to as a UICC card. UICC can mean a chip that stores personal information, such as network access authentication information, phone book, and SMS for mobile communication users, and that the chip enables secure use of mobile communication by performing user authentication and generating service security keys when accessing mobile communication networks (such as GSM, WCDMA, or LTE).

[0045] A UICC may include an access control module for accessing a mobile operator's network. Examples of access control modules include a Universal Subscriber Identity Module (USIM), a Subscriber Identity Module (SIM), an IP Multimedia Service Identity Module (ISIM), etc. A UICC including a USIM is typically referred to as a USIM card. Similarly, a UICC including a SIM module is typically referred to as a SIM card. In this disclosure, "SIM card," "UICC card," "USIM card," and "UICC including ISIM" can be used to mean the same thing. That is, the content of this disclosure can be equally applied to SIM cards, USIM cards, ISIM cards, or public UICC cards.

[0046] SIM modules can be installed during the manufacturing of the UICC, or SIM modules for mobile communication services used by the user at the desired time can be downloaded from the UICC card. Furthermore, multiple SIM modules can be downloaded and installed in the UICC card. At least one of the SIM modules can be selected and used. Such a UICC card can be fixed or not fixed to the device. A UICC fixed and used in a device is called an embedded UICC (eUICC). In particular, a UICC embedded in the device's communication processor, application processor, or a system-on-a-chip (SoC) including a single processor architecture integrating two processors is referred to as an integrated UICC (iUICC). Generally, eUICC and iUICC can mean a UICC card that is fixed and used in a device and includes functions for enabling at least one SIM module to be remotely downloaded to the UICC and for selecting any downloaded SIM module. In this disclosure, a UICC card having the function of enabling at least one SIM module to be downloaded and selected can be referred to as an eUICC or an iUICC. In other words, UICC cards that are fixed to or not fixed to a device and have the function of enabling the SIM module to be remotely downloaded and selected can be collectively referred to as eUICC or iUICC.

[0047] In this disclosure, the term "UICC" may be used interchangeably with SIM. The term "eUICC" may be used interchangeably with eSIM.

[0048] The "eUICC ID" can be the object ID of the eUICC embedded in the device and can be represented as an EID. Furthermore, if a provisioning profile is pre-installed on the eUICC, the eUICC ID can be the profile ID of the corresponding provisioning profile. Additionally, in embodiments of this disclosure, if the device and the eUICC chip are not separate, the eUICC ID can be the device ID. Furthermore, the eUICC ID can represent a specific security domain of the eUICC chip.

[0049] A “profile” can refer to a data object stored in UICC, such as an application, file system, or authentication key value.

[0050] In this disclosure, "profile package" can mean that the contents of a "profile" have been packaged in the form of software that can be installed in a UICC. A "profile package" can be named a profile TLV or a profile package TLV. If the profile package is encrypted with encryption parameters, it can be named a protected profile package (PPP) or a protected profile package TLV (PPP TLV). If the profile package is encrypted with encryption parameters that can be decoded only by a specific eUICC, it can be named a bound profile package (BPP) or a bound profile package TLV (BPP TLV). A profile package TLV can be a dataset representing information that constitutes a profile in the form of a label, length, value (TLV).

[0051] In this disclosure, a "profile image" can mean binary data containing a profile package installed in a UICC. A "profile image" can be named a profile TLV or a profile image TLV. If the profile image has been encrypted using encryption parameters, the "profile image" can be named a protected profile image (PPI) or a PPI TLV. If the profile image has been encrypted using encryption parameters that can be decoded only by a specific eUICC, the "profile image" can be named a bound profile image (BPI) or a bound profile image TLV (BPI TLV). A profile image TLV can be a dataset representing information that constitutes a profile in the form of a label, length, and value (TLV).

[0052] In this disclosure, the “status” of the profile may be as follows.

[0053] In this disclosure, the operation of enabling (activating) a profile by a device can mean configuring communication services so that the device can receive communication services through a mobile operator, which has provided the profile by changing its state to an enabled state. A profile in an enabled state can be referred to as an "enabled profile".

[0054] In this disclosure, the operation of disabling (deactivating) a profile by a device can mean configuring communication services so that the device cannot receive communication services through a mobile operator, which has provided the profile by changing its status to disabled. A profile in a disabled state can be represented as a "disabled profile".

[0055] In this disclosure, the act of deleting a profile by the device can mean configuring the profile so that the device no longer enables or disables the profile by changing its state to a deleted state. A profile in a deleted state can be represented as a "deleted profile".

[0056] In this disclosure, the operation of enabling, disabling, or deleting profiles by a device can mean the following: first, marking the state of each profile as pending enable, pending disable, or pending deletion, without immediately changing the state of each profile to enabled, disabled, or deleted; then, a specific operation (e.g., executing a refresh or reset command) is performed by a device connected to the UICC of the device; and finally, the state of each profile is changed to enabled, disabled, or deleted. The operation of marking the state of a specific profile as a future state (i.e., pending enable, pending disable, or pending deletion) is not substantially limited to marking the state of a profile as a future state. The states of one or more profiles can be marked as the same or different future states, the state of a profile can be marked as one or more future states, or the states of one or more profiles can be marked as one or more similar or different future states.

[0057] Furthermore, if the device marks the state of a given profile as one or more future states, then two future state marks can be integrated into one. For example, if the state of a given profile is marked as pending disable and pending delete, then the states of the corresponding profile can be integrated and marked as pending disable and pending delete.

[0058] Furthermore, operations that allow the device to mark the state of one or more profiles can be performed sequentially or simultaneously. Additionally, operations that allow the device to change the actual state of a profile after marking its future state can be performed sequentially or simultaneously.

[0059] A "profile authenticator" can be represented as a factor that matches a profile ID, integrated circuit card ID (ICCID), match ID, event ID, activation code, activation code token, command code, command code token, signed command code, unsigned command code, ISD-P, or profile field (PD). The profile ID can indicate the object ID for each profile. The profile authenticator may also include the address of the profile providing server (SM-DP+) capable of indexing the profile. Furthermore, the profile authenticator may include the signature of the profile providing server (SM-DP+).

[0060] "Remote SIM Provisioning (RSP) Server" can be used to refer to a profile provisioning server and / or a profile management server and / or a reservation relay server, which will be described later. An RSP server can be represented as a reservation manager XX (SM-XX).

[0061] In this disclosure, a "profile provider server" may include functions for generating profiles, encrypting generated profiles, generating profile remote management commands, or encrypting generated profile remote management commands. A profile provider server may be represented as a Reservation Manager Data Preparation (SM-DP), Reservation Manager Data Preparation Plus (SM-DP+), an off-card entity of a profile domain, a profile encryption server, a profile generation server, a profile provider (PP), a profile provider, a profile provider credential holder (PPC holder), etc.

[0062] In this disclosure, a “profile management server” may include functionality for managing profiles. A profile management server may be represented as a reservation manager secure route (SM-SR), a reservation manager secure route plus (SM-SR+), an off-card entity of the eUICC profile manager or a profile management credential holder (PMC holder), an eUICC manager (EM), a profile manager (PM), etc.

[0063] In this disclosure, a profile providing server can mean the combined functionality of a profile management server. Therefore, in various embodiments of the invention, the operations of a profile providing server can be performed within a profile management server. Similarly, the operations of a profile management server or SM-SR can be performed within a profile providing server.

[0064] In this disclosure, a "reservation relay server" can be represented as a reservation manager discovery service (SM-DS), a discovery service (DS), a root discovery relay server (root SM-DS), or an alternative reservation relay server (alternate SM-DS). The reservation relay server can receive event registration requests (or registration event requests or event registration requests) addressed to it from one or more profile providing servers. Furthermore, one or more discovery relay servers can be used in combination. In this case, in addition to the profile providing server, a first reservation relay server can receive event registration requests from the reservation discovery relay server.

[0065] "Mobile operator" can refer to a service that provides communication services to a device, and can refer to a Business Support System (BSS), Operation Support System (OSS), Point-of-Sale (POS) terminal, and other IT systems of the mobile operator. Furthermore, in this disclosure, "mobile operator" is not limited to referring only to a specific service that provides communication services, and can be used as a term to refer to a group or association (or alliance) of one or more enterprises, or to refer to a representative of a corresponding group or association. In addition, in this disclosure, a mobile operator can be named an operator (OP) (or Op.), a mobile network operator (MNO), a mobile virtual network operator (MVNO), a service provider (SP), a profile owner (PO), etc. At least one name and / or object identifier (OID) can be assigned to each mobile operator. If a mobile operator represents a group or association or a representative of one or more enterprises, the name or object ID of a given group or association or representative can be a name or object ID shared by all enterprises of the corresponding group or association that cooperate with the corresponding representative.

[0066] "User" can be used to refer to either a service provider who owns the device or an end user who owns the device. Typically, a device owned by a service provider can be called an M2M device. A device owned by an end user can be called a consumer device. In the case of an M2M device, there may be an end user who does not own the device but uses it, either switched from or rented from a service provider. In this case, the user may be the same as or different from the service provider.

[0067] "End user consent" can be used as a term to indicate whether an end user agrees to perform remote management.

[0068] The term "device" can be represented as a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, user unit, user station (SS), wireless device, wireless communication device, wireless transmitter / receiver unit (WTRU), mobile node, mobile phone, or other terms. Various embodiments of the device may include cellular phones, smartphones with wireless communication capabilities, personal digital assistants (PDAs) with wireless communication capabilities, wireless modems, portable computers with wireless communication capabilities, imaging devices such as digital cameras with wireless communication capabilities, gaming devices with wireless communication capabilities, music storage and playback home appliances with wireless communication capabilities, internet-connected home appliances capable of wireless internet access and browsing, and portable units or devices integrating a combination of these functions. Furthermore, the device may include machine-to-machine (M2M) devices and machine-type communication (MTC) UE / devices, but this disclosure is not limited thereto. In this disclosure, the device may be represented as an electronic device.

[0069] In this disclosure, a UICC with downloadable and installable profiles can be embedded in an electronic device. If the UICC is not embedded in the electronic device, it can be inserted into and connected to the electronic device, which is physically separate from it. For example, the UICC can be inserted into the electronic device in the form of a card. The electronic device may include a device. In this case, the device may be a device that includes a UICC with downloadable and installable profiles. The UICC can be embedded in the device. Furthermore, if the device and the UICC are separate, the UICC can be inserted into and connected to the device. For example, a UICC with downloadable and installable profiles can be represented as an eUICC.

[0070] To control UICC or eUICC in a device or electronic device, a “Local Profile Assistant (LPA)” can be referred to as software or application installed in the device or electronic device.

[0071] An "event" can be a term used to refer to a common invocation of profile download, remote profile management, or management / processing commands for other profiles or eUICCs. An event can be named a remote SIM provisioning operation (or RSP operation) or an event log. Each event can be represented as data including one or more corresponding event identifiers (IDs) (or EventIDs) or matching IDs (or matchingIDs), the address (FQDN, IP address, or URL) of the profile providing server (SM-DP+) or the discovery relay server (SM-DS) where the corresponding event is stored, a signature of the profile providing server (SM-DP+) or subscription relay server (SM-DS), or a digital certificate of the profile providing server (SM-DP+) or subscription relay server (SM-DS).

[0072] Data corresponding to an event can be represented as a "command code". Some or all of a process using command codes can be represented as a "command code processing procedure", "command code process", or "Local Profile Assistant Application Programming Interface (LPA API)". Profile download can be used interchangeably with profile installation.

[0073] In addition, "Event Type" can be used as a term to indicate whether a specific event is a profile download, remote profile management (e.g., deletion, enabling, disabling, replacing, or updating), or other profile or eUICC management / processing command, and can be named Operation Type, Operation Class, Event Request Type, Event Class, Event Request Class, etc. The path to the device that has obtained the corresponding Event ID (EventID or MatchingID) or the purpose of using the corresponding Event ID (EventID or MatchingID) can be specified within a given Event ID (EventID or MatchingID).

[0074] "Profile management" can be basically divided into "local profile management (LPM)" and "remote profile management (RPM)".

[0075] "LPM" can be named Local Profile Management, Local Management, Local Management Commands, Local Commands, Local Profile Management Package (LPM Package), Local Profile Management Package, Local Management Package, Local Management Command Package, Local Command Package, etc. LPM can be used to update the status (enabled, disabled, deleted) or content (e.g., profile nickname or profile metadata) of a specific profile through software installed on the device. An LPM can include one or more local management commands. In this case, the profile that becomes the target of each local management command can be the same or different.

[0076] "RPM" can be named Profile Remote Management, Remote Management, Remote Management Commands, Remote Commands, Remote Profile Management Package (RPM Package), Profile Remote Management Package, Remote Management Package, Remote Management Command Package, Remote Command Package, etc. RPMs can be used to update the status (enabled, disabled, deleted) of a specific profile or the content (e.g., profile nickname or profile metadata) of a specific profile. An RPM can include one or more remote management commands. In this case, the profile that becomes the target of each remote management command can be the same or different for each remote management command.

[0077] A "certificate" or "digital certificate" can refer to a digital certificate used for mutual authentication based on an asymmetric key consisting of a public key (PK) and a secret key (SK). Each certificate may include one or more PKs, a PK identifier (PKID) corresponding to each PK, the ID of the certificate issuer (CI) that issued the corresponding certificate (Certificate Issuer ID), and a digital signature. Furthermore, the certificate issuer may be named a certificate issuer, a certificate authority (CA), a certification authority, etc. In this disclosure, PK and PKID can be used to represent the following meanings: a certificate including a PK specific to the corresponding PK, a portion of a PK specific to a portion of a certificate including a corresponding PK, the value of the operation result (e.g., hash) of a PK specific to the operation result (e.g., hash) of a PK specific to a portion of a certificate including a corresponding PK, storage space for storing data, etc.

[0078] A "certificate chain" or "certificate hierarchy" indicates the correlation between certificates when a certificate issued by a "certificate issuer" (primary certificate) is used to issue other certificates (secondary certificates), or when secondary certificates are used to issue third or more certificates in a linked manner. In this context, the CI certificate used to issue the primary certificate can be named the root certificate, the highest certificate, the root CI, the root CI certificate, the root CA, the root CA certificate, etc.

[0079] Furthermore, in describing the present invention, a detailed description of a related known function or configuration will be omitted if it is considered that such a description would unnecessarily obscure the subject matter of the invention.

[0080] Various embodiments of methods and apparatus for transferring and installing software bundles between devices are described below.

[0081] Figure 1 This is a diagram illustrating a method for connecting to a mobile communication network using a device with a pre-installed UICC according to an embodiment of the present disclosure.

[0082] like Figure 1 As shown, the UICC 120 can be inserted into the device 110. For example, the UICC 120 can be a removable type or can be pre-embedded in the device.

[0083] A fixed profile installed on a UICC can mean that "access information" for a specific telecommunications company has been fixed. For example, access information could be the International Mobile Subscriber Identity (IMSI), i.e., the subscriber authenticator, and the K or Ki value required for network authentication along with the subscriber authenticator.

[0084] According to various embodiments, device 110 can perform authentication using UICC 120 in conjunction with the authentication processing system of a mobile communication operator (e.g., Home Location Register (HLR) or AuC). For example, the authentication process can be an Authentication and Key Agreement (AKA) process. After authentication, the device can use mobile communication services, such as making calls or using mobile data, through the mobile communication network 130 of the mobile communication system.

[0085] Figure 2 This is a diagram illustrating an example of a method of interoperation between two devices and a server according to an embodiment of the present disclosure, such that a profile or a service associated with a profile can be transmitted from one device to another.

[0086] like Figure 2 As shown, the first eSIM 203 and the second eSIM 223 can be installed on the first device 200 and the second device 220, respectively. Profiles (not shown) can be installed in the first eSIM 203 and the second eSIM 223, respectively. Furthermore, the first LPA 201 and the second LPA 221 can be installed in the first device 200 and the second device 220, respectively. The first eSIM 203 and the second eSIM 223 can be controlled by the first LPA 201 and the second LPA 221, respectively. The first terminal user 205 and the second terminal user 225 can control the profiles installed in the eSIMs (i.e., the first eSIM 203 and the second eSIM 223) of the devices via the first LPA 201 and the second LPA 221, respectively. In this case, the first terminal user 205 and the second terminal user 225 can be the same. Furthermore, the first LPA 201 and the second LPA 221 can be connected and communicate with each other. For possible connection methods between the LPAs in this case, refer to the description in the accompanying drawings, which will be described later.

[0087] The first LPA 201 of the first device 200 can be connected to the first RSP server 240. The second LPA 221 of the second device 220 can be connected to the second RSP server 280. In this case, the first RSP server 240 and the second RSP server 280 can be the same. Furthermore, for convenience, Figure 2 The illustration shows a scenario where the first RSP server 240 and the second RSP server 280 each comprise a single server. However, according to implementations and embodiments, one or more profile providing servers (SM-DP+) may be included in the server configuration. One or more subscription relay servers (SM-DS) used to assist in the connection and generation of a specific profile providing server and a specific device may be included in the server configuration. Furthermore, although in Figure 2Not shown, but one or more RSP servers and / or relay servers may be connected between the first RSP server 240 and the second RSP server 280.

[0088] Furthermore, despite Figure 2 Not shown, but each RSP server and / or each relay server can connect to a carrier server. If the configuration includes one or more carrier servers, each carrier server can connect to each individual RSP server and / or individual relay server. At least one carrier server can connect to the same RSP server and / or the same relay server.

[0089] As described above, in the following figures, the configuration of various servers can be simply indicated as a single RSP server. For example, if one or more RSP servers and / or relay servers are connected between the first device 200 and the second device 220, and some or all of the RSP servers and / or relay servers are connected to a carrier server, then the configuration of various servers existing between the first device and the second device can be represented as a single RSP server. In the figures and embodiments, a single RSP server can be represented as SM-XX.

[0090] Figure 3 This is a diagram illustrating the first step of the "first version of device modification" process according to an embodiment of the present invention.

[0091] Figure 3 Each of the source device 310 and target device 350 shown may include at least one LPA and at least one eSIM. For a description of the RSP server 390, refer to... Figure 2 .

[0092] According to various embodiments, the source device 310 may have a previously installed profile.

[0093] According to various embodiments, the source device 310 may possess "device change info" related to a previously installed profile. This "device change info" may be configured by the mobile operator and stored in the device before a device change is made. This process can be performed when the source device installs the corresponding profile.

[0094] "Device change information" may include the following information. The following information is merely an example, and this disclosure is not limited thereto.

[0095] In one example, device changes are not supported for the corresponding profile.

[0096] In one example, the corresponding profile supports device changes. In this case, to obtain the "Device Change Method," a remote procedure must first be executed.

[0097] In one example, the corresponding profile supports device changes. The "Device Change Method" is included in the device change information. In this case, the device change can be performed via a local procedure instead of a remote procedure.

[0098] If the relevant profile has been configured to undergo a "remote process," the following information may be further included in the "Device Change Information." The following information is merely an example, and this disclosure is not limited thereto.

[0099] In one example, the address of the server to be accessed in order to obtain the device change method is provided.

[0100] In one example, is it necessary to present the target device's eUICC ID when accessing the server in order to obtain the device change method?

[0101] In one example, when accessing a server to obtain information about device change methods, it is desirable to determine whether the target device taking over the service needs to present the information necessary to perform a conformity check, through which the target device can download and install the appropriate documentation.

[0102] "Device change method (or device change type)" refers to information previously stored in device change information or obtainable through a "remote process," and may include the following information.

[0103] In one example, information regarding how to handle a profile installed on the source device. This information may indicate any of the following:

[0104] ● Delete the corresponding profile;

[0105] ● Set the status of the corresponding profile to paused; or

[0106] ● No specific processing is performed on the corresponding profile.

[0107] In one example, "Information on how to notify the RSP server of the result when a profile is deleted or its status is set to paused on the source device." This information could indicate any of the following:

[0108] ●The source device needs to directly notify the RSP server of the corresponding results; or

[0109] ●The source device notifies the RSP server of the corresponding result through the target device.

[0110] Reference Figure 3In step 3000, the service user or device user can select a source profile associated with the service to be transmitted to the target device from the communication services currently used in the device (i.e., source device 310). In this case, the source device can provide the service user or device user with the necessary information related to the device change.

[0111] Reference Figure 3 In step 3005, the source device 310 can identify “device change information” of the profile associated with the service to be delivered by the end user.

[0112] If the "Device Change Information" indicates that the corresponding profile does not support device changes, the device change process can be paused.

[0113] Alternatively, if the “Device Change Information” indicates that the corresponding profile supports device change, but a remote procedure must first be performed to obtain the “Device Change Method”, then the source device 310 can access the RSP server 390 to obtain the “Device Change Method” and subsequently identify the information included in the “Device Change Method”.

[0114] Alternatively, if the “Device Change Information” indicates that the corresponding profile supports device change and the “Device Change Method” is included in the Device Change Information, then the source device 310 can recognize the information included in the Device Change Method.

[0115] Reference Figure 3 In step 3010, the following procedure may be performed.

[0116] If the corresponding profile has been configured to be deleted in "Information on how to handle profiles installed in the source device" under "Device Change Method", then the source device 310 can delete the corresponding profile.

[0117] Alternatively, if the corresponding profile has been configured to have its status set to paused in the "Information on how to handle profiles installed in the source device" section of "Device Change Method", the source device 310 can change the status of the corresponding profile to paused.

[0118] Alternatively, if the specific processing is configured not to be performed on the corresponding profile in the "Information on how to process the profile installed in the source device" section of the "Device Change Method", steps 3010 to 3020 can be omitted.

[0119] If the corresponding profile has been configured to be deleted or its status set to pause in the "Information on how to handle profiles installed in the source device" section of "Device Change Method", then steps 3015 to 3020, which will be described later, can be executed.

[0120] Reference Figure 3 In step 3015, the following procedure may be performed. In particular, if "the source device needs to directly notify the RSP server of the corresponding result when the profile is deleted or the status of the profile is set to paused" in the "Device Change Method", then step 3015 may be performed.

[0121] In step 3015, the source device 310 may notify the RSP server 390 that it has deleted the corresponding profile or set the status of the corresponding profile to a paused state. This process can be performed by the source device 310 sending a notification to the RSP server 390. The "notification" may include at least one of the following information. The following information is merely an example, and this disclosure is not limited thereto.

[0122] In one example, a notification serial number is provided.

[0123] In one example, information is provided that means the source device has deleted the profile or has set the profile's status to paused.

[0124] In one example, the address of the RSP server that can receive notifications.

[0125] In one example, a profile discriminator is provided for profiles that have been deleted or whose status is set to paused.

[0126] In one example, the value of a signature is provided, which is electronically signed by the source device (e.g., an eUICC installed on the source device) in part and / or all of the information.

[0127] In one example, a series of certificate information is provided to verify the value of the digital signature.

[0128] Reference Figure 3 In step 3020, the following procedure may be performed. In particular, if the "Information on how to notify the RSP server of the corresponding result when the source device deletes the profile or sets the profile status to a paused state" in the "Device Change Method" has been configured that "the source device needs to notify the RSP server of the corresponding result through the target device", then step 3020 may be performed.

[0129] In step 3020, the source device 310 may generate a partial notification certifying that the source device has deleted the corresponding profile or set the status of the corresponding profile to a paused state. The "partial notification" may include one or more of the following information. The following information is merely illustrative, and this disclosure is not limited thereto.

[0130] In one example, a notification serial number is provided.

[0131] In one example, information is provided that means the source device has deleted the profile or has set the profile's status to paused.

[0132] In one example, the address of an RSP server that can receive notifications is provided.

[0133] In one example, a profile discriminator is provided for profiles that have been deleted or whose status is set to paused.

[0134] In one example, the value of a signature is provided, which is electronically signed by the source device (e.g., an eUICC installed on the source device) in part and / or all of the information.

[0135] That is, a partial notification may be a series of information other than a series of certificate information used to verify the value of the electronic signature in the aforementioned notification.

[0136] Reference Figure 3 In step 3025, the source device 310 may prepare an activation code to be sent to the target device 350. In this case, the method for preparing the activation code may be performed in various ways, as configured in the "Information on how to handle the profile installed in the source device" and the "Information on how to notify the RSP server of the corresponding result when the profile is deleted or the status of the profile is set to a paused state in the source device" included in the "Device Change Method".

[0137] If the "Information on how to handle the profile installed on the source device" included in the "Device Change Method" has been configured to "not perform specific processing on the corresponding profile," then the "Device Change Method" may include an activation code to be sent to the target device as part of the "Device Change Method." In this case, the source device can extract the activation code included in the "Device Change Method" and can prepare to send the activation code to the target device.

[0138] Alternatively, if the corresponding profile has been configured to be deleted or its status set to pause in the "Information on how to handle profiles installed on the source device" included in the "Device Change Method," and if the "Information on how to notify the RSP server of the corresponding result when the source device deletes the profile or sets the profile's status to pause" has been configured so that "the source device needs to directly notify the RSP server of the corresponding result," then the "Device Change Method" may include an activation code to be sent to the target device as part of the "Device Change Method." In this case, the source device can extract the activation code included in the "Device Change Method" and can prepare to send the activation code to the target device.

[0139] Alternatively, if the corresponding profile has been configured to be deleted or its status set to pause in the "Information on how to handle profiles installed in the source device" included in the "Device Change Method", and the "Information on how to notify the RSP server of the corresponding result when the source device deletes the profile or sets the profile status to pause" has been configured that "the source device needs to notify the RSP server of the corresponding result through the target device", then the source device can generate an activation code by including part of the notification generated in step 3020 in the activation code.

[0140] The activation code may include one or more of the following information. The following information is merely an example, and this disclosure is not limited thereto:

[0141] ● Information indicating the format of the activation code;

[0142] ● Information about the RSP server (e.g., address and / or OID), which the RSP server needs to be accessed by the target device to download the profile; and / or

[0143] ● This indicates information about the profile to be downloaded by the target device. When the RSP server receives this information, it can mean that it can identify the corresponding profile. For example, this information can represent at least one of the following.

[0144] In one example, a profile identifier (ICCID) for the profile to be downloaded is provided. For example, if the source device has already generated an activation code, this information can be included in the activation code.

[0145] In one example, a matching ID is provided that links to the profile to be downloaded. This matching ID can be generated by the RSP server, linked to the corresponding profile, and managed by the RSP server. For example, if the activation code is included in the "Device Change Method" and is extracted by the source device, this information can be included in the activation code.

[0146] In addition, if step 3020 has already been performed, the activation code may further include the following information.

[0147] In one example, partial notification, such as if the source device has already generated an activation code, can be included in the activation code.

[0148] Reference Figure 3 In step 3030, the source device 310 may send the activation code prepared in step 3025 to the target device 350. The activation code may be sent using one of the various methods suggested below. These methods are merely examples, and this disclosure is not limited thereto.

[0149] For example, source device 310 can provide information to be sent to target device 350 to end user through the source device's user interface (UI). End user can input the provided information by using the target device's UI.

[0150] Alternatively, source device 310 can transmit information to target device 350 in the form of an image (e.g., a QR code) and display the image on the screen of source device. An end user can then send information to target device by scanning the image displayed on the screen of source device using the target device.

[0151] Alternatively, a connection can be established between the source device 310 and the target device 350. The established connection can be used to send information. In this case, the connection established between the source device 310 and the target device 350 can be a direct device-to-device connection (e.g., a wireless connection such as NFC, Bluetooth, UWB, WiFi Direct, LTE Device-to-Device (D2D), or 5G D2D, and a wired connection such as a cable connection), or it can be a remote distance connection where a remote server (e.g., a relay server) is set up between the source device 310 and the target device 350.

[0152] Figure 4 This is a diagram illustrating the second step of the "device change of the first version" process according to an embodiment of the present invention.

[0153] Figure 4 The target device 450 shown may include at least one LPA and at least one eSIM. For a description of the RSP server 490, refer to... Figure 2 .

[0154] Reference Figure 4 In step 4000, mutual authentication can be performed between the target device 450 and the RSP server 490. This mutual authentication process may include one or more of the following procedures.

[0155] In one example, the mutual authentication process may include a certificate negotiation process for communication that needs to be performed between the target device 450 and the RSP server 490. For example, the target device 450 may send certificate information to the RSP server 490 that can be used to verify the RSP server 490 and / or certificate information that the RSP server 490 can use to verify the target device. Having received this information, the RSP server 490 may select certificate information that can be used by the target device 450 to verify the RSP server and / or certificate information that can be used by the RSP server to verify the target device 450. In this case, the certificate information selected by the RSP server 490 may be sent to the target device 450. Through this process, the target device 450 and the RSP server 490 can obtain certificate information that allows them to mutually 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 can represent the certificate.

[0156] In one example, target device 450 can send a given random number (eUICC query) value generated by the target device to RSP server 490. After writing a digital signature into the received random number, RSP server 490 can send the digitally signed value to target device 450. Target device 450 can authenticate the RSP server by verifying the received digitally signed value.

[0157] In one example, RSP server 490 can send a given random number (server query) value generated by the RSP server to target device 450. After writing a digital signature into the received random number, target device 450 can send the digitally signed value to RSP server 490. RSP server 490 can authenticate target device 450 by verifying the received digitally signed value.

[0158] In one example, when the RSP server 490 and the target device 450 communicate with each other, they can exchange IDs (transaction IDs) used to manage the session. For example, after generating the transaction ID, the RSP server 490 can send the value of the transaction ID to the target device 450. In this case, to check the reliability and integrity of the transaction ID, the value of the RSP server 490's digital signature can be incremented.

[0159] In one example, RSP server 490 and target device 450 may exchange information that represents a profile associated with a service to be transmitted in this disclosure. For example, target device 450 may send information to RSP server 490 that represents a profile associated with a service to be received by target device. In this case, the "information that indicates the profile associated with the service to be received" sent from target device 450 to RSP server 490 may include... Figure 3 The information in step 3030 received from the activation code of the source device, or information generated based on the information of the received activation code. That is, the "information that indicates the profile associated with the service to be received" sent from the target device 450 to the RSP server 490 can be information including (e.g., the ICCID of the corresponding profile or the matching ID associated with the corresponding profile):

[0160] i) An activation code owned by the source device and included in the "Device Change Method", which has been extracted and sent by the source device.

[0161] ii) Activation codes generated and sent autonomously by the source device and / or information generated using the aforementioned information (e.g., when sending the ICCID, a specific text string (e.g., $) may be placed before the ICCID). In this case, the "information indicating the profile associated with the service to be received" sent from the target device 450 to the RSP server 490 may be sent together with the value of the target device 450's electronic signature to ensure reliability and integrity.

[0162] In one example, if a “partial notification” is included in the activation code received by the target device 450 from the source device, the target device 450 can pass the received partial notification to the RSP server 490.

[0163] In one example, RSP server 490 and target device 450 can exchange their IDs. For instance, RSP server 490 can provide its own object identifier (OID) to target device 450. In other examples, target device 450 can provide its own eUICC ID to RSP server 490.

[0164] Reference Figure 4 In step 4005, the RSP server 490 may perform at least one of the following processes.

[0165] In one example, RSP server 490 can identify that it has been requested by target device 450 by using information sent by target device 450 that indicates a profile associated with the service it wants to receive.

[0166] In one example, RSP server 490 can identify whether a profile is capable of making device changes by checking the "Device Change Information" of the corresponding profile.

[0167] In one instance, RSP server 490 can identify which method is allowed for device changes by checking the "Device Change Method" of the corresponding profile.

[0168] In one instance, RSP server 490 can identify whether a “notification” associated with the corresponding profile (e.g., a notification received in step 3015) has arrived.

[0169] In one example, RSP server 490 can identify the content of a "partial notification" when it receives a "partial notification" related to a corresponding profile.

[0170] In one example, RSP server 490 may perform a "qualification check" to determine whether the services expected to be received by target device 450 can be used on target device 450.

[0171] Reference Figure 4 In step 4010, the RSP server 490 may send one or more of the following information to the target device 450. The following information is merely an example, and this disclosure is not limited thereto:

[0172] ●Transaction ID;

[0173] ●The metadata of the profile expected to be received by the target device;

[0174] ● The value of the electronic signature of a portion and / or all of the data; and / or

[0175] ● The certificate of the RSP server and related information used in electronic signatures.

[0176] A series of messages sent from RSP server 490 to target device 450 can be referred to as "SM-XX signature 2".

[0177] Reference Figure 4 In step 4015, the following procedure may be performed.

[0178] The target device 450 can receive user consent related to the installation of the file. During this process, the content of the received metadata can be provided to the end user.

[0179] The target device 450 can verify the validity of the certificate and related information received in step 4010. Furthermore, the target device 450 can verify the validity of the electronic signature value received in step 4010.

[0180] The target device 450 can generate a public key “otPK.EUICC.KA” and a secret key “otSK.EUICC.KA”, which are key pairs used for encryption and to generate encryption keys for encrypted communication with the RSP server 490.

[0181] Target device 450 may send one or more of the following information to RSP server 490. The following information is merely an example, and this disclosure is not limited thereto:

[0182] ●Transaction ID;

[0183] ●otPK.EUICC.KA; and / or

[0184] ● The value of the electronic signature of the target device (e.g., the eUICC included in the target device) used for some and / or all of the data.

[0185] The series of messages sent from the target device 450 to the RSP server 490 can be referred to as "eUICC signature 2".

[0186] Reference Figure 4 In step 4020, the RSP server 490 can prepare a profile to be sent to the target device 450. A possible example of the preparation process is as follows.

[0187] ● In step 4000, when sending “information that indicates the profile associated with the service to be received by itself” to RSP server 490, if target device 450 has already sent information using the information included in the activation code “owned by the source device and included in the device change method (“device change method” has been extracted and sent by the source device)” and has not yet sent a notification from the source device, then RSP server 490 may prepare to send a new profile to target device 450 that is associated with the service used by the source device but is different from the profile owned by the source device.

[0188] ● In step 4000, when "information indicating a profile associated with a service to be received" is sent to the RSP server 490, if the target device 450 has already sent information using information included in the activation code "owned by the source device and included in the device change method (the 'device change method' has been extracted and sent by the source device)," and... Figure 3 If a notification has been sent from the source device to the RSP server 490 in step 3015, the RSP server 490 can then prepare to send a profile with the same information as the profile used by the source device to the target device 450.

[0189] ● In step 4000, when “information that indicates a profile associated with the service to be received” is sent to RSP server 490, if target device 450 has already sent information using the information included in the “activation code generated and sent by source device”, and a partial notification has also been sent from target device 450 to RSP server 490, then RSP server 490 may prepare to send a profile with the same information as the profile used by the source device to target device 450.

[0190] For encrypted communication between RSP server 490 and target device 450, a portion and / or all of the prepared profiles can be encrypted. In this case, to generate an encryption key for encrypted communication between RSP server 490 and target device 450, in step 4015, otPK.EUICC.KA sent from target device 450 to RSP server 490 can be used. The profile that has been partially and / or fully encrypted using the generated encryption key can be referred to as a "bound profile package".

[0191] Reference Figure 4 In step 4025, the RSP server 490 may send the "binding profile package" prepared in step 4020 to the target device 450.

[0192] Reference Figure 4 In step 4030, the target device 450 can install the profile by using the "bound profile package" received in step 4025.

[0193] Reference Figure 4 In step 4035, the target device 450 may notify the RSP server 490 that the profile has been installed.

[0194] Figure 5 This is a diagram illustrating the first step of the "second version of device change" process according to an embodiment of the present invention.

[0195] Figure 5 Each of the source device 510 and the target device 550 shown may include at least one LPA and at least one eSIM.

[0196] pass Figures 5 to 8 The method of transferring (or exporting) a profile or related services from a source device to a target device, as disclosed in the "Second Version Device Change," can be represented as an online transfer. An online transfer is defined as follows.

[0197] ● Online delivery: Delivering a profile or related services via online methods can mean that each of two devices establishes a connection with an RSP server and delivers the profile or related services with the help of the RSP server.

[0198] In this context, online transmission can be categorized as follows. The following categorization is merely an example, and this disclosure is not limited thereto:

[0199] ●Online image transfer: This may mean sending profile images from one device to other devices via online transfer;

[0200] ●Online Package Transfer: This may mean transferring a package from one device to another via online transfer; and / or

[0201] ●Re-providing: This means that each of the two devices establishes a connection with the RSP server, selectively deletes the profile of the device that originally had the profile installed, and the RSP server prepares the profile associated with the service to be delivered and sends the prepared profile to the other device.

[0202] "Online image delivery" and "online packet delivery" can be referred to as "online delivery".

[0203] If content has been arranged, it can be categorized using the following methods.

[0204] In one example, online delivery is provided.

[0205] In such an example, online transmission could include:

[0206] ◆Online image transmission; and / or

[0207] ◆Online package delivery.

[0208] In such an example, a redeliverable is provided.

[0209] According to various embodiments, source device 510 may have a previously installed profile and may also have metadata associated with the previously installed profile. According to various embodiments, source device 510 may have a "profile discriminator" associated with the previously installed profile.

[0210] According to various embodiments, the source device 510 may have "profile transfer settings" associated with a previously installed profile. The "profile transfer settings" may include the following information. The following information is merely illustrative and this disclosure is not limited thereto:

[0211] ●Whether the relevant profile or the services associated with the profile can be transferred from one device to another.

[0212] In addition, the “profile transfer settings” may include information indicating how a profile or the service associated with a profile can be transferred from one device to another if the profile or the service associated with the profile can be transferred from one device to another.

[0213] For example, "profile delivery settings" can include information about which of the following methods are allowed:

[0214] ● Online delivery; and / or

[0215] ●Re-provided.

[0216] For another example, "profile delivery settings" may include information about which of the following methods are allowed:

[0217] ●Online image delivery;

[0218] ● Online package delivery; and / or

[0219] ●Re-provided.

[0220] Reference Figure 5 In step 5000, the source device 510 can obtain information about the profile (associated with the service) to be transmitted. Alternatively, the information about the profile (associated with the service) to be transmitted can be passed to the source device.

[0221] For example, source device 510 can obtain information about the profile (associated with a service) to be transmitted by receiving user input from an end user who selects a profile through the UI provided by source device 510. The information about the profile (associated with a service) to be transmitted can be input to source device 510 via push input from a remote server, or source device 510 can access a remote server and read the information about the profile (associated with a service) to be transmitted.

[0222] The method by which the source device 510 obtains information about the profile (associated with the service) to be transmitted is not limited to the methods described above. The source device 510 may obtain information about the profile (associated with the service) to be transmitted based on various methods.

[0223] Reference Figure 5 In step 5005, the following procedure may be performed.

[0224] Source device 510 can identify the "profile transfer settings" of the profile obtained in step 5000. Source device 510 can identify whether the corresponding profile or the service associated with the profile can be transferred to other devices by identifying the "profile transfer settings". Source device 510 can identify how the corresponding profile or the service associated with the profile can be transferred by identifying the "profile transfer settings", and then can configure the "available options".

[0225] For example, "Available Options" can include information about which of the following methods are allowed:

[0226] ● Online delivery; and / or

[0227] ●Re-provided.

[0228] For other examples, "Available options" can include information about which of the following methods are allowed:

[0229] ●Online image delivery;

[0230] ● Online package delivery; and / or

[0231] ●Re-provided.

[0232] In this case, to configure the "Available Options," one or more of the following information can be used. The following information is merely an example, and this disclosure is not limited thereto:

[0233] ● Profile Transfer Settings for the profile to be transferred (associated with the service);

[0234] ● The functions implemented in the source device (i.e., which transmission methods the device functions support); and / or

[0235] ● The online connection status of the source device (e.g., whether the source device is currently able to communicate with the server via an online connection).

[0236] That is, the source device can identify “the transmission methods allowed in the profile transmission settings” and / or “the supported transmission methods because the method has been implemented in the source device” and / or “the possible transmission methods when taking into account the online connection status of the source device”, and then “available options” can be configured using this information.

[0237] Reference Figure 5 In step 5010, the source device 510 may generate a "transfer code". The transfer code may include one or more of the following information. The following information is merely an example, and this disclosure is not limited thereto:

[0238] ●The profile authenticator for the profile (associated with the service) to be transmitted;

[0239] ● The RSP server address associated with the profile to be transmitted (associated with the service) (which the target device 550 can then use to access the RSP server and download the profile); and / or

[0240] ● Information on cryptographic algorithms supported by the source device (e.g., an eSIM included in the source device) (supported cryptographic information). For example, the information on cryptographic algorithms supported by the source device may optionally include one or more of the following: a list of elliptic curve cryptography supported by the source device, a list of key-based algorithms supported by the source device, or a list of cryptographic algorithms supported by the source device.

[0241] ● "Available Options" generated in step 5005.

[0242] Reference Figure 5 In step 5015, the following procedure may be performed.

[0243] The transmission code generated in step 5010 can be sent from the source device 510 to the target device 550. Various methods can be used to send the transmission code, as described below. The methods described below are merely examples, and this disclosure is not limited thereto.

[0244] For example, source device 510 can provide information to end user to be sent to target device 550 through source device UI. End user can input the provided information into target device 550 by using target device 550 UI.

[0245] Alternatively, source device 510 can transmit information to target device 550 in the form of an image (e.g., a QR code) and display that information on the screen of source device 510. An end user can send information to target device 550 by scanning the image displayed on the screen of source device 550 using target device 550.

[0246] Alternatively, a connection can be established between the source device 510 and the target device 550. Information can be sent from the source device 510 to the target device 550 using the established connection. In this case, the connection established between the source device 510 and the target device 550 can be a direct device-to-device connection (e.g., a wireless connection such as NFC, Bluetooth, UWB, WiFi Direct, LTE Device-to-Device (D2D) or 5G D2D, and a wired connection such as a cable connection), or it can be a remote distance connection where a remote server (e.g., a relay server) is set up between the source device 510 and the target device 550.

[0247] If "available options" are included in the transmission code received by target device 550, target device 550 can configure "determined options", that is, indicate how to receive information about the profile or services associated with the profile to be received by the target device based on that information.

[0248] For example, "the determined options" can include information about which of the following methods are allowed:

[0249] ● Online delivery; and / or

[0250] ●Re-provided.

[0251] For other instances, "the determined options" may include information about which of the following methods are allowed:

[0252] ●Online image delivery;

[0253] ● Online package delivery; and / or

[0254] ●Re-provided.

[0255] In this case, to configure the "determined options," one or more of the following information can be used. The following information is merely an example, and this disclosure is not limited thereto:

[0256] ● The "Available Options" received in step 5015;

[0257] ● The functions implemented in the target device (i.e., which transmission methods the device supports); and / or

[0258] ● The online connection status of the target device (e.g., whether the target device can currently communicate with the server via an online connection).

[0259] In other words, the target device can identify the transmission methods allowed in the received "available options" and / or "supported transmission methods because the method has been implemented in the target device" and / or "possible transmission methods when considering the online connection status of the target device", and can then configure the "determined options" by using such information.

[0260] Figure 6 This is a diagram illustrating the second step of the "second version of device change" process according to an embodiment of the present invention.

[0261] Figure 6 The target device 650 shown may include at least one LPA and at least one eSIM. For a description of the RSP server 690, refer to... Figure 2 .

[0262] Reference Figure 6 In step 6000, mutual authentication can be performed between the target device 650 and the RSP server 690. This mutual authentication process may include one or more of the following procedures.

[0263] In one example, the mutual authentication process may include a certificate negotiation process that needs to be performed between the target device 650 and the RSP server 690 to enable mutual communication. For example, the target device 650 may send certificate information to the RSP server 690 that can be used to verify the RSP server 690 and / or certificate information that the RSP server 690 can use to verify the target device 650. Having received this information, the RSP server 690 may select the certificate information that can be used by the target device 650 to verify the RSP server 690 and / or the certificate information that the RSP server 690 can use to verify the target device 650. In this case, the certificate information selected by the RSP server 690 may be sent to the target device 650. Through this process, the target device and the RSP server 690 can obtain certificate information capable of mutual authentication. In this case, the certificate information may be a certificate and / or information included in the certificate and / or a series of information that can indicate the certificate.

[0264] In one example, target device 650 can send a given random number (eUICC query) value generated by the target device to RSP server 690. After writing a digital signature into the received random number, RSP server 690 can send the digitally signed value to target device 650. Target device 650 can authenticate RSP server 690 by verifying the received digitally signed value.

[0265] In one example, RSP server 690 can send a given random number (server query) value generated by the RSP server to target device 650. After writing a digital signature into the received random number, target device 650 can send the digitally signed value to RSP server 690. RSP server 690 can authenticate target device 650 by verifying the received digitally signed value.

[0266] In one example, when the RSP server 690 and the target device 650 communicate with each other, they can exchange IDs (transaction IDs) used to manage the session. For example, after generating the transaction ID, the RSP server 690 can send the value of the transaction ID to the target device 650. In this case, to check the reliability and integrity of the transaction ID, the value of the RSP server 690's digital signature can be incremented.

[0267] In one example, RSP server 690 and target device 650 may exchange profile authenticators associated with the services to be transmitted in this disclosure. For example, target device 650 may send a profile authenticator associated with the services to be received by target device to RSP server 690. In this case, the profile authenticator may be sent along with the value of the target device 650's electronic signature to ensure reliability and integrity.

[0268] In one example, RSP server 690 and target device 650 can exchange their IDs. For instance, RSP server 690 can provide its own object identifier (OID) to target device 650. In other examples, target device 650 can provide its own eUICC ID to RSP server 690.

[0269] In one example, target device 650 may send the "determined options" to RSP server 690.

[0270] Reference Figure 6 In step 6005, the following procedure may be performed.

[0271] RSP server 690 can identify the received "determined options". In particular, RSP server can select the "profile delivery settings" associated with the corresponding profile by identifying the received profile discriminator, and can check whether the online delivery method included in the "determined options" is a method included in the online delivery methods allowed in the "profile delivery settings".

[0272] RSP server 690 can perform a "qualification check" to determine whether the services that the target device 650 wishes to receive can be used on the target device 650. For example, RSP server 690 can perform the "qualification check" using the received target device 650's eUICC ID and the received profile authenticator.

[0273] For example, RSP server 690 can check whether the image of the profile used in the source device can be installed and operated on the target device 650. As another example, RSP server 690 can check whether the profile package stored in the source device can be installed and operated on the target device 650. Furthermore, RSP server 690 can generate a new profile that can be installed and operated on the target device 650 relative to the service to be transmitted, or it can identify whether the profile has been previously stored.

[0274] In other words, RSP server 690 can identify the options that can actually be executed during the online transmission method included in the "determined options" (i.e., as a result of the execution, the service used in the source device is transmitted to the target device 650). RSP server 690 can select one of the available options and generate a transmission option.

[0275] For example, "transfer options" may include at least one of the following information. The following information is merely an example, and this disclosure is not limited thereto:

[0276] a) Information indicating RSP server 690 (e.g., the OID of RSP server 690);

[0277] b) Information indicating the target device 650 (e.g., the eUICC ID of the eSIM installed in the target device 650);

[0278] c) A profile authenticator for the profile associated with the service to be delivered;

[0279] d) Instructions on how to execute the online transmission of information; in this case, the following may be provided:

[0280] -Online image delivery

[0281] - Online package delivery

[0282] -Re-provided, and / or

[0283] Online transmission is not possible;

[0284] e) Indicates which of the following can be used: "end-to-end encryption between the source device and the destination device" or "encryption between the destination device and the RSP server"; and / or

[0285] f) Transaction ID.

[0286] Some or all of the above information may be electronically signed by the RSP server 690. The value of the electronic signature may be included as part of the "Transmission Options".

[0287] Reference Figure 6 In step 6010, RSP server 690 may send a transmission option to target device 650. Furthermore, RSP server 690 may send the RSP server's certificate and related information used in the electronic signature performed in step 6005 to target device 650. The series of information sent from RSP server 690 to target device 650 can be represented as "SM-XX signature 2".

[0288] Reference Figure 6 In step 6015, the following procedure may be performed.

[0289] The target device 650 can recognize the received transmission options and then receive consent from the end user.

[0290] Target device 650 can verify the validity of the certificate and related information received in step 6010. Target device 650 can verify the validity of the electronic signature value received in step 6010. Target device 650 can recognize the content of the transmission options received in step 6010.

[0291] If end-to-end encryption between the source and target devices is required, the target device 650 can identify the content of the supported cryptographic information received from the source device and can identify whether the encryption algorithm supported by the target device exists in the supported cryptographic information. When the encryption algorithm supported by the target device 650 exists in the received supported encryption information, the target device 650 can select one of the encryption algorithms and configure the selected encryption algorithm as "selected encryption algorithm (selected encryption information)". The "selected encryption algorithm" may optionally include one or more of the following information: elliptic curve information, key and algorithm information, or encryption algorithm information.

[0292] Target device 650 can generate a public key "otPK.EUICC.KA" and a secret key "otSK.EUICC.KA", that is, an encrypted key pair to be used to generate an encryption key for encrypted communication. In this case, the generated encryption key can be used for "encrypted communication between the RSP server and the target device" and can also be used for "encrypted communication between the source device and the target device". In this case, if the generated encryption key is used for "encrypted communication between the source device and the target device", then the encryption key (otPK.EUICC.KA and otSK.EUICC.KA) can be an encryption key that follows the encryption algorithm included in the encryption information selected above.

[0293] Reference Figure 6 In step 6020, the target device 650 may send at least one of the following information to the RSP server 690. The following information is merely an example, and this disclosure is not limited thereto:

[0294] ●The otPK.EUICC.KA generated in step 6015;

[0295] ● The selected password information generated in step 6015; and / or

[0296] ●Signature information electronically signed by the target device 650 for part and / or all of the information.

[0297] The information sent from the target device 650 to the RSP server 690 can be represented as "eUICC signature 2".

[0298] Figure 7 This is a diagram illustrating the third step of the "second version of device change" process according to an embodiment of the present invention.

[0299] Figure 7 The source device 710 shown may include at least one LPA and at least one eSIM. For a description of the RSP server 790, refer to... Figure 2 .

[0300] Reference Figure 7 In step 7000, mutual authentication can be performed between the source device 710 and the RSP server 790. This mutual authentication process may include one or more of the following procedures.

[0301] In one example, the mutual authentication process may include a certificate negotiation process that needs to be performed between the source device 710 and the RSP server 790 to enable mutual communication. For example, the source device 710 may send certificate information to the RSP server 790 that can be used to verify the RSP server 790 and / or certificate information that the RSP server 790 can use to verify the source device 710. Having received this information, the RSP server 790 can select the certificate information that can be used by the source device 710 to verify the RSP server 790 and / or the certificate information that can be used by the RSP server 790 to verify the source device 710. In this case, the certificate information selected by the RSP server 790 can be sent to the source device 710. Through this process, the source device 710 and the RSP server 790 can obtain certificate information that enables mutual authentication. In this case, the certificate information may be a certificate and / or information included in the certificate and / or a series of information that can represent the certificate.

[0302] In one example, source device 710 can send a given random number (eUICC query) value generated by source device 710 to RSP server 790. RSP server 790 can write a digital signature into the received random number and then send the digital signature value to source device 710. Source device 710 can authenticate RSP server 790 by verifying the received digital signature value.

[0303] In one example, RSP server 790 can send a given random number (server query) value generated by the RSP server to source device 710. Source device 710 can write a digital signature into the received random number and then send the digital signature value to RSP server 790. RSP server 790 can authenticate source device 710 by verifying the received digital signature value.

[0304] In one example, when the RSP server 790 and the source device 710 communicate with each other, they can exchange IDs (transaction IDs) used to manage the session. For example, after generating the transaction ID, the RSP server 790 can send the value of the transaction ID to the source device 710. In this case, to check the reliability and integrity of the transaction ID, the value of the RSP server 790's electronic signature can be incremented.

[0305] In one example, RSP server 790 and source device 710 may exchange profile authenticators for profiles (associated with services) to be transmitted to the target device in this disclosure. For example, source device 710 may send a profile authenticator for the corresponding profile to RSP server 790. In this case, the profile authenticator may be sent along with the value of the electronic signature of source device 710 to ensure reliability and integrity.

[0306] In one example, RSP server 790 and source device 710 can exchange their IDs. For instance, RSP server 790 can provide its own object identifier (OID) to source device 710. In other examples, source device 710 can provide its own eUICC ID to RSP server 790.

[0307] Reference Figure 7 In step 7005, the following procedure may be performed.

[0308] In one example, RSP server 790 can perform one or more of the following procedures.

[0309] In one example, RSP server 790 can identify source device 710 as a legitimate entity currently using the corresponding profile by using the "source device's eUICC ID" and the "profile authenticator of the profile sent by the source device".

[0310] In one example, the RSP server can inspect other devices (e.g., Figure 6 The target device (as shown) has requested the delivery of "the service associated with the profile corresponding to the profile authenticator sent by the source device". For example, the RSP server 790 can identify whether "the profile authenticator sent by the source device" is associated with... Figure 6 The profile authenticator associated with the delivery of the requested service.

[0311] As a result of the inspection, if it has been identified that "the legitimate subject using the profile associated with the profile authenticator sent by the source device is the source device" and the delivery of the service associated with the profile has been carried out by other devices (e.g., Figure 6 If the target device (shown in the diagram) requests a transmission option, the RSP server can determine what operation needs to be performed by the source device by using the "determined options" received in step 6000 and / or the result of the "qualification check" performed in step 6005, and can generate "transmission options". For example, the RSP server can select one of the transmission methods already allowed in the "determined options" and can perform it as a result of the "qualification check", and can configure the "transmission options" based on the selected method.

[0312] For example, "transfer options" may include at least one of the following information. The following information is merely an example, and this disclosure is not limited thereto.

[0313] In one example, information indicating RSP server 790 is provided (e.g., the OID of RSP server 790).

[0314] In one example, information indicating the source device 710 is provided (e.g., the eUICC ID of the eSIM embedded in the source device 710).

[0315] In one example, information indicating the target device 650 is provided (e.g., the eUICC ID of the eSIM embedded in the target device 650).

[0316] In one example, the profile discriminator is associated with the service to be delivered.

[0317] In one example, information indicating the information that needs to be sent by the source device 710.

[0318] In such an example, a profile image associated with the service to be transmitted by the source device 710 is provided.

[0319] In such an example, a profile packet is associated with the service to be transmitted by the source device 710.

[0320] In one example, does the source device 710 need to delete the service profile associated with the service to be transmitted?

[0321] In one example, information is needed indicating which security method is used: "end-to-end encryption between the source device and the target device" or "encryption between the source device and the RSP server".

[0322] In one instance, the transaction ID.

[0323] Some or all of the above information may be digitally signed by the RSP server 790. The value of the digital signature may be included as part of the "Transmission Options".

[0324] RSP server 790 can generate a public key "otPK.DP.KA" and a secret key "otSK.DP.KA", which are the encrypted key pairs to be used to generate the encryption key for encrypted communication with source device 710. This process can be omitted if end-to-end encryption between the source and destination devices is necessary.

[0325] RSP server 790 may send one or more of the following messages to source device 710. The following messages are merely examples, and this disclosure is not limited thereto:

[0326] ●Transfer options;

[0327] ●otPK.XX.KA. In this case, otPK.XX.KA can be otPK.EUICC.KA received from the target device in step 6020, or it can be otPK.DP.KA generated by the RSP server in this process;

[0328] ● The selected password information received in step 6020;

[0329] ● For some and / or all of the information, the value of the electronic signature signed by the RSP server; and / or

[0330] ● The RSP server's certificate and related information that can be used to verify digital signatures.

[0331] Reference Figure 7 In step 7010, the following process can be performed.

[0332] The source device 710 can receive user consent in relation to the received transmission options. That is, the source device can notify the end user whether a transmission using which method can be performed based on the received transmission options, and can receive consent from the end user.

[0333] The source device 710 can verify the validity of the certificate and related information received in step 7005. The source device 710 can also verify the validity of the electronic signature value received in step 7005.

[0334] After recognizing the contents of the transmission options received in step 7005, the source device 710 may perform at least one of the following processes.

[0335] The source device 710 can use the "transfer options" to determine whether it is necessary to send the profile image or profile package to the RSP server 790 autonomously.

[0336] If it is necessary to send a profile image or profile package to the RSP server 790, the source device 710 can prepare the requested data, and the detailed process is as follows.

[0337] - The source device 710 can recognize the information included in the selected password information. For example, if "end-to-end encryption between the source device and the target device" is required, the source device can recognize the face and identify the information included in the selected password information.

[0338] Source device 710 can generate a public key “otPK.EUICC.KA” and a secret key “otSK.EUICC.KA”, that is, an encrypted key pair to be used to generate an encryption key for encrypted communication. In this case, the generated encryption key can be used for “encrypted communication between the RSP server and the source device”, and can also be used for “encrypted communication between the source device and the target device”. In step 7005, the type of encrypted communication for which the generated encryption key is used can be determined based on the received value of otPK.XX.KA. Alternatively, the type of encrypted communication for which the generated encryption key is used can follow the contents of the “transmission options”. Source device 710 can calculate the value of the electronic signature of the generated otPK.EUICC.KA. The value of otPK.EUICC.KA and / or the electronic signature can be represented as “eUICC signature 2”.

[0339] In one example, source device 710 can generate a session key for encrypted communication using “otSK.EUICC.KA” generated by the source device and otPK.XX.KA received in step 7005.

[0340] In one example, source device 710 may prepare a profile to be sent to RSP server 790. In this case, the format of the prepared profile may match the transmission option received in step 7005. That is, the format of the prepared profile may be one of the following:

[0341] ■Simplified image; or

[0342] ■Simplified document package.

[0343] In one instance, a portion and / or all of the prepared profile can be encrypted using the aforementioned session key. Furthermore, the source device 710 can electronically sign a portion and / or all of the prepared profile. The value of the electronic signature can be included as part of the prepared profile. The “prepared profile image” or “prepared profile package” can be referred to as “bound profile material.”

[0344] The source device 710 can check whether the RSP server 790 wants to delete the corresponding profile by recognizing the "transfer options". If the RSP server 790 wants to delete the corresponding profile, the source device 710 can delete the corresponding profile.

[0345] Reference Figure 7 In step 7015, the following procedure may be performed.

[0346] The source device 710 may send the corresponding information when the information to be sent to the RSP server 790 is present in the following information. However, this process may be omitted when no information to be sent is present. The following information is merely an example, and this disclosure is not limited thereto:

[0347] ● A notification will be sent to inform you that a profile has been deleted;

[0348] ●Bound brief materials; and / or

[0349] ●eUICC signature 2.

[0350] RSP server 790 can verify the validity of received notifications and / or eUICC signature 2. This process can be performed by verifying the validity of the value of the electronic signature of the source device included in the notification and / or eUICC signature 2.

[0351] Figure 8 This is a diagram illustrating the fourth step of the "second version of device change" process according to an embodiment of the present invention.

[0352] Figure 8 The target device 850 shown may include at least one LPA and at least one eSIM. For a description of the RSP server 890, refer to... Figure 2 .

[0353] Reference Figure 8 In step 8000, the following procedure can be performed.

[0354] RSP server 890 can prepare a profile to be sent to target device 850. A possible example of the preparation process is as follows.

[0355] If the bound document material is not received from the source device 710 in step 7015, the following procedure can be performed. This situation may correspond to a case where it needs to be re-provided in an online transmission method.

[0356] In one example, RSP server 890 can prepare a profile to be sent to target device 850. In this case, RSP server 890 can generate the profile to be sent to target device 850, or it can use a previously stored profile as the profile to be sent to target device 850. In this case, the prepared profile can be the same as the profile used by the source device, or it can be a profile associated with a service used by the source device but different from the profile used by the source device (e.g., providing the same service). For example, if the profile used by the source device has been deleted, the RSP server can prepare a profile that is the same as the profile used by the source device. In another example, if the profile used by the source device has not been deleted, the RSP server can prepare a profile that is different from the profile used by the source device. Whether the profile used by the source device has been deleted does not determine which profile needs to be prepared (i.e., whether the profile is the same or a different profile). This choice can depend on the choice of the mobile operator or RSP server 890.

[0357] In one example, RSP server 890 can generate a public key “otPK.DP.KA” and a secret key “otSK.DP.KA”, that is, a key pair to be used to generate an encryption key for “encrypted communication between the target device and the RSP server”. RSP server 890 can generate a session key by using the generated otSK.DP.KA and otPK.EUICC.KA from the target device 850 received in step 6020, and can use the session key to encrypt part and / or all of the prepared profile.

[0358] In one example, a prepared (or otherwise encrypted) profile can be referred to as a "bound profile".

[0359] If the bound file material has been received from the source device 710 in step 7015, the following procedure can be performed. This situation may correspond to cases requiring online transmission in online transmission methods (i.e., online image transmission or online packet transmission).

[0360] In one example, if RSP server 890 has received the "bound profile material" with "encryption between the source device and the RSP server" performed in step 7015, RSP server 890 performs decoding. In this case, decoding can be performed using the session key generated in step 7005 (otSK.DP.KA) and the source device's (otPK.EUICC.KA) received in step 7015. The decoded profile can undergo an "encryption between the target device and the RSP server" process, allowing the decoded profile to be sent to the target device. RSP server 890 can generate a public key "otPK.DP.KA" and a secret key "otSK.DP.KA," i.e., a key pair to be used to generate the encryption key for "encrypted communication between the target device and the RSP server." RSP server 890 can generate a session key using the generated otSK.DP.KA and otPK.EUICC.KA from the target device 850 received in step 6020, which can be used to encrypt the decoded profile and prepare it for transmission.

[0361] In one example, if the RSP server has already received the "bound profile material" with "encryption between source device and target device" performed in step 7015, the RSP server can prepare to send the bound profile material to the target device 850 without having to perform the decoding and encryption process separately again.

[0362] In one instance, the prepared profile, which is the result of two processes, can be represented as a "bound profile".

[0363] Reference Figure 8 In step 8005, the RSP server 890 can send a "binding profile" to the target device 850.

[0364] Reference Figure 8 In step 8010, the following procedure may be performed.

[0365] The target device 850 can verify the received "binding profile". For example, the target device 850 can identify and verify the content of metadata included in the "binding profile". In addition, the target device 850 can receive user consent regarding whether the "binding profile" can be installed.

[0366] The target device 850 can install the profile (in the eSIM embedded in the target device 850) by using the received "bound profile".

[0367] Reference Figure 8 In step 8015, the target device 850 may notify the RSP server 890 that the profile has been installed.

[0368] Figure 9 This is a diagram illustrating the first step of a process in which a source device performing a "second version of device change" operation attempts to perform a "second version of device change" on a target device or on a target device performing a "first version of device change" according to an embodiment of the present disclosure.

[0369] Figure 9 Each of the source device 910 and the target device 950 shown may include at least one LPA and at least one eSIM. The source device 910 may be a terminal operating according to "Device Change Version 2". The target device 950 may be a terminal operating according to "Device Change Version 2" or a terminal operating according to "Device Change Version 1".

[0370] According to various embodiments, the source device 910 may possess a previously installed profile and metadata associated with the previously installed profile. According to various embodiments, the source device 910 may possess a "profile authenticator" associated with the previously installed profile. According to various embodiments, the source device 910 may possess "profile transfer settings" associated with the previously installed profile. For a description of the "profile transfer settings," refer to... Figure 5 .

[0371] Reference Figure 9 In step 9000, the source device 910 can obtain information about the profile (associated with the service) to be transmitted. Alternatively, the information about the profile (associated with the service) to be transmitted can be passed to the source device 910.

[0372] For example, source device 910 can obtain information about the profile (associated with the service) to be transmitted by receiving user input from an end user who selects a profile through the UI provided by source device 910. The information about the profile (associated with the service) to be transmitted can be input to source device 910 via push input from a remote server, or source device 910 can access a remote server and read the information about the profile (associated with the service) to be transmitted.

[0373] The method by which the source device 910 obtains information about the profile (associated with the service) to be transmitted is not limited to the methods described above. The source device 910 may obtain information about the profile (associated with the service) to be transmitted based on various methods.

[0374] Reference Figure 9 In step 9005, the following process can be performed.

[0375] Source device 910 can identify the "profile transfer settings" of the profile whose information has been obtained in step 9000. The source device can identify whether a corresponding profile or the service associated with the profile can be transferred to other devices by recognizing the "profile transfer settings." Source device 910 can identify how a corresponding profile or the service associated with the profile can be transferred by recognizing the "profile transfer settings," and can configure "available options." For a description of the available options, refer to [reference needed]. Figure 5 .

[0376] Reference Figure 9 In step 9010, the source device 910 can generate a "combination code" to be sent to the target device 950. The details of the "combination code" are as follows.

[0377] In one embodiment, code is provided that can serve as the basis for generating composite code.

[0378] The source device can use the following two codes to configure the combined code:

[0379] ■ Activation code; and / or

[0380] ■Transmission code.

[0381] In one example, an activation code is provided.

[0382] Activation codes can have the same Figure 3 The activation code uses the same format as the one used in the "Device Changes in First Version" section. That is, the activation code may include some and / or all of the following information. The following information is merely an example, and this disclosure is not limited thereto:

[0383] ● Information indicating the format of the activation code;

[0384] ● Information about the RSP server (e.g., address and / or OID) that needs to be accessed by the target device 950 to download the profile;

[0385] ● Information indicating the profile to be downloaded by the target device 950. This information may mean that the RSP server can recognize the corresponding profile when it receives this information. For example, this information may represent at least one of the following:

[0386] ■ The profile identifier (ICCID) to download, and

[0387] ■ Matching ID linked to the profile to be downloaded;

[0388] ●Partial Notice.

[0389] The aforementioned matching ID can be an ID generated by the mobile operator and / or RSP server, associated with the corresponding profile, and managed by the RSP server. For example, a mobile operator can generate a matching ID to support device changes from a terminal operating under "Device Change for Version 2" to a terminal operating under "Device Change for Version 1," and can provide information to the device operating under "Device Change for Version 2" (e.g., the source device).

[0390] The above-mentioned notifications may have the same characteristics as Figure 3 It has the same format as the publicly disclosed notices, but may not have the same format as the others. Figure 3 The notification uses the same format as the publicly disclosed portion. The partial notification may be an inserted series of data to follow the format of the activation code used in "Device Changes in Version 1," without needing to record the corresponding history after the actual deletion of the corresponding profile (and...). Figure 3 (The situations differ). In other words, the data sequence can be a given value, or it can be a value agreed upon between the source device and the RSP server.

[0391] Some examples of possible activation codes are as follows.

[0392] In one example, a possible activation code may include the following information. If needed, the activation code may include additional information beyond the following. The following information is merely an example, and this disclosure is not limited thereto:

[0393] ● Information indicating the format of the activation code;

[0394] ● Information about the RSP server (e.g., address and / or OID), which the RSP server needs to be accessed by the target device to download the profile; and / or

[0395] ● Match ID.

[0396] In one example, a possible activation code may include the following information. If needed, the activation code may include additional information beyond the following. The following information is merely an example, and this disclosure is not limited thereto:

[0397] ● Information indicating the format of the activation code;

[0398] ● Information about the RSP server (e.g., address and / or OID), which the target device needs to access in order to download the profile;

[0399] ●ICCID; and / or

[0400] ●Partial Notice.

[0401] In one example, a transfer code is provided.

[0402] The transmission code can have the same as Figure 5 The transmission code uses the same format as the one used in the "Second Version Device Change" section. That is, the transmission code may include some and / or all of the following information. The following information is merely an example, and this disclosure is not limited thereto:

[0403] ●The profile authenticator for the profile (associated with the service) to be transmitted;

[0404] ● The address of the RSP server associated with the profile to be transmitted (associated with the service); and / or

[0405] ● Information on cryptographic algorithms supported by the source device (e.g., an eSIM included in the source device) (supported cryptographic information). For example, the information on cryptographic algorithms supported by the source device may optionally include one or more of the following: a list of elliptic curve cryptography supported by the source device, a list of key-based algorithms supported by the source device, and a list of cryptographic algorithms supported by the source device.

[0406] In one example, "Available Options" are provided.

[0407] This example provides a way to configure combined code.

[0408] The source device 910 can generate a "combined code" to be sent to the target device 950 by using the "activation code" and "transmission code" described in (1). In this case, the "combined code" can be a code that simply combines the "activation code" and the "transmission code", or it can be a newly generated code by combining the contents of the "activation code" and the "transmission code".

[0409] An example of “combined code” can be shown below:

[0410] ● Activation code + transfer code (e.g., this could refer to a code that adds a transfer code after the activation code); and / or

[0411] ●(Some activation code + delivery code (for example, this could mean adding the remaining information after the activation code after the content already included in the activation code is excluded from the content of the delivery code).

[0412] However, the method of configuring the "combination code" using the "activation code" and "transfer code" is not limited to the example. It is possible to allow the restoration of a given combination of "activation code" and "transfer code" by using the "combination code".

[0413] Reference Figure 9 In step 9015, the following process can be performed.

[0414] The "combined code" generated in step 9010 can be sent from the source device 910 to the target device 950. To send the "combined code," a method can be used... Figure 5 The method for sending the "transmission code" is shown in step 50154.

[0415] If the target device is a terminal operating according to the "Device Change Version 2" procedure, then after recovering the "Transmission Code" from the received "Combined Code," a device change can be performed according to the operations defined in the "Device Change Version 2." In this case, the source device, the target device, and the RSP server can all perform device changes according to the operations defined in the "Device Change Version 2." For a description of the corresponding process, refer to [reference needed]. Figures 5 to 8 .

[0416] If the target device is a terminal that operates according to the "Device Changes of Version 1", then after restoring the "Activation Code" from the received "Combined Code", execution can be performed. Figure 10 The process. In other words, the source device, target device, and RSP server can be configured according to... Figure 10 The operations disclosed herein are used to perform device changes.

[0417] Figure 10 This is a diagram illustrating the second step of a process in which a source device performing a "second version of device change" operation attempts to perform a "first version of device change" on a target device according to an embodiment of the present invention.

[0418] Figure 10 Each of the source device 1010 and target device 1050 shown may include at least one LPA and at least one eSIM. The source device 1010 may be a terminal operating according to the "Second Version Device Change" procedure. The target device 1050 may be a terminal operating according to the "First Version Device Change" procedure. For a description of the RSP server 1090, refer to... Figure 2 .

[0419] Reference Figure 10 In step 10000, mutual authentication can be performed between the target device 1050 and the RSP server 1090. This mutual authentication process may include one or more of the following procedures.

[0420] In one example, the mutual authentication process may include a certificate negotiation process that needs to be performed between the target device 1050 and the RSP server 1090 to enable mutual communication. For example, the target device 1050 may send certificate information to the RSP server 1090 that can be used to verify the RSP server 1090 and / or that can be used by the RSP server 1090 to verify the target device 1050's certificate information. Having received this information, the RSP server 1090 can select the certificate information that can be used by the target device 1050 to verify the RSP server 1090's certificate information and / or that can be used by the RSP server to verify the target device 1050's certificate information. In this case, the certificate information selected by the RSP server 1090 can be sent to the target device 1050. Through this process, the target device 1050 and the RSP server 1090 can obtain certificate information that allows them to mutually 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 can represent the certificate.

[0421] In one example, target device 1050 can send a given random number (eUICC query) value generated by the target device to RSP server 1090. After writing a digital signature into the received random number, RSP server 1090 can send the digital signature value to target device 1050. Target device 1050 can authenticate RSP server 1090 by verifying the received digital signature value.

[0422] In one example, RSP server 1090 can send a given random number (server query) value generated by the RSP server to target device 1050. After writing a digital signature to the received random number, target device 1050 can send the digital signature value to RSP server 1090. RSP server 1090 can authenticate target device 1050 by verifying the received digital signature value.

[0423] In one example, when RSP server 1090 and target device 1050 communicate with each other, they can exchange IDs (transaction IDs) used to manage the session. For example, after generating the transaction ID, RSP server 1090 can send the value of the transaction ID to target device 1050. In this case, to check the reliability and integrity of the transaction ID, the value of the RSP server 1090's digital signature can be incremented.

[0424] In one example, RSP server 1090 and target device 1050 may exchange information that indicates a profile associated with a service to be transmitted in this disclosure. For example, target device 1050 may send information to RSP server 1090 that indicates a profile associated with a service to be received by the target device. In this case, the "information that indicates a profile associated with a service to be received" sent from target device 1050 to RSP server 1090 may include... Figure 9 The information received from the source device in step 9015, either in the "combination code" or the "activation code" included in the "combination code". That is, the "information indicating the profile associated with the service to be received" sent from the target device 1050 to the RSP server 1090 can be:

[0425] i) The ICCID of the corresponding profile or information generated using the ICCID of the corresponding profile (e.g., when sending the ICCID, a specific text string, such as $, can be inserted before the ICCID); or

[0426] ii) A matching ID associated with the corresponding profile, which is included in the "activation code". In this case, the "information indicating the profile associated with the service to be received" sent from the target device 1050 to the RSP server can be sent together with the value of the target device 1050's electronic signature to ensure reliability and integrity.

[0427] In one example, if a “partial notification” is included in the activation code received by the target device 1050 from the source device 1010, the target device 1050 can pass the received partial notification to the RSP server 1090.

[0428] In one example, RSP server 1090 and target device 1050 can exchange their IDs. For instance, RSP server 1090 can provide its own object identifier (OID) to target device 1050. In another example, target device 1050 can provide its own eUICC ID to RSP server 1090.

[0429] Reference Figure 10 In step 10005, the RSP server 1090 may perform at least one of the following processes.

[0430] In one example, RSP server 1090 can identify that it has sent a profile requested by target device 1050 by using a profile sent by target device 1050 that "can indicate the profile associated with the service it wants to receive" and / or a partial notification (the presence or absence of the profile).

[0431] In one example, at least one of the following information can be identified based on the identified profile. The following information is merely an example, and this disclosure is not limited thereto:

[0432] (i) Information about the device used by the corresponding profile. For example, this information could be information indicating that the source device is a terminal operating according to "Device Changes for Version 2"; and / or

[0433] (ii) Information about the device for which the corresponding profile is to be used. For example, this information could be information indicating that the target device is a terminal operating according to the "device changes of the first version".

[0434] In one example, it can be identified whether the corresponding profile is one that allows the device to change.

[0435] In one example, a "qualification check" can be performed to identify whether the services that target device 1050 wants to receive are available on target device 1050.

[0436] Reference Figure 10 In step 10010, the RSP server 1090 may send one or more of the following information to the target device 1050. The following information is merely an example, and this disclosure is not limited thereto:

[0437] ●Transaction ID;

[0438] ●The metadata of the profile that the target device 1050 wants to receive;

[0439] ● The value of the electronic signature of a portion and / or all of the data; and / or

[0440] ● The certificate of RSP server 1090 and related information used in electronic signatures.

[0441] A series of messages sent from RSP server 1090 to target device 1050 can be referred to as "SM-XX signature 2".

[0442] Reference Figure 10 In step 10015, the following procedure may be performed.

[0443] The target device 1050 can receive user consent related to the installation of the file. During this process, the content of the received metadata can be provided to the end user.

[0444] The target device 1050 can verify the validity of the certificate and related information received in step 10010. Furthermore, the target device 1050 can verify the validity of the electronic signature value received in step 10010.

[0445] The target device 1050 can generate a public key “otPK.EUICC.KA” and a secret key “otSK.EUICC.KA”, which are encrypted key pairs to be used to generate an encrypted key for encrypted communication with the RSP server 1090.

[0446] Target device 1050 may send one or more of the following information to RSP server 1090. The following information is merely an example, and this disclosure is not limited thereto:

[0447] ●Transaction ID;

[0448] ●otPK.EUICC.KA; and / or

[0449] ● Electronic signatures of the target device used for values ​​of some and / or all of the data (e.g., eUICC included in target device 1050).

[0450] The series of messages sent from the target device 1050 to the RSP server 1090 can be referred to as "eUICC signature 2".

[0451] Reference Figure 10 In step 10020, the following procedure may be performed. Step 10020 may be performed selectively when the source device needs to delete the profile associated with the current device change procedure.

[0452] To delete the corresponding profile on source device 1010, the following steps can be performed between source device 1010 and RSP server 1090. Figure 7 The process is publicly disclosed. In this case, Figure 7 During the disclosure process, you can selectively perform only the procedure necessary to "remove the profile installed on the source device". That is, the following procedure can be performed.

[0453] In step 7000, the source device and the RSP server perform mutual authentication.

[0454] In step 7005, the RSP server requests the source device to delete the profile.

[0455] In step 7010, the process of deleting the profile from the source device.

[0456] In step 7015, the source device notifies the RSP server of the profile deletion process.

[0457] However, in order to delete the corresponding profile, the source device basically does not need to perform any actions. Figure 7 The process can be performed with the same effect (e.g., source device 1010 deletes the corresponding profile and / or RSP server 1090 recognizes that the corresponding profile has been deleted in source device 1010).

[0458] Furthermore, the process of deleting the corresponding profile in the source device 1010 is essentially unnecessary to perform in steps 10015 and 10025. This process can be... Figure 10 Perform any of steps 10000 to 10040.

[0459] Reference Figure 10 In step 10025, the RSP server 1090 can prepare a profile to be sent to the target device 1050.

[0460] In this case, the prepared profile can be either of the following two types:

[0461] ● A file containing the same credentials as the file used by source device 1010; and

[0462] ● A document containing a different document than the one used by the source device 1010.

[0463] For example, if step 10020 identifies that a profile has been deleted in the source device, RSP server 1090 can prepare to send a profile with the same credentials as the profile used by the source device (i.e., the deleted profile). In another example, if a profile has not been deleted in the source device 1010, RSP server 1090 can prepare to send a profile with credentials different from those used by the source device 1010.

[0464] The prepared profile can be a profile that can be operated on a terminal that operates according to the "device changes of the first version".

[0465] Part or all of the prepared profiles can be encrypted for encrypted communication between RSP server 1090 and target device 1050. In this case, to generate an encryption key for encrypted communication between RSP server 1090 and target device 1050, otPK.EUICC.KA, sent from target device 1050 to RSP server 1090 in step 10015, can be used. The profiles that have been partially and / or entirely encrypted using the generated encryption key can be referred to as a "bound profile package".

[0466] Reference Figure 10 In step 10030, the RSP server 1090 may send the "binding profile package" prepared in step 10025 to the target device 1050.

[0467] Reference Figure 10In step 10035, the target device 1050 can install the profile by using the "bound profile package" received in step 10030.

[0468] Reference Figure 10 In step 10040, the target device 1050 may notify the RSP server 1090 that the profile has been installed.

[0469] Figure 11 This is a diagram illustrating the structure of a device equipped with an eUICC according to an embodiment of the present disclosure.

[0470] Reference Figure 11 The device may include a transceiver 1110, a processor 1120, and an eUICC 1130. Some of the devices described in this disclosure may correspond to those in the reference numerals. Figure 11 The device described. However, the device configuration is not limited to... Figure 11 The configuration, and can include more Figure 11 The components shown are more than those in the diagram, and include more than [other components]. Figure 11 The components shown are fewer than those in the original document. According to embodiments of this disclosure, the transceiver 1110, processor 1120, and eUICC 1130 can be implemented as a single chip. Furthermore, the device may also include memory. The processor 1120 may be configured as at least one processor.

[0471] According to various embodiments, transceiver 1110 can send signals, information, data, etc. to and receive signals, information, data, etc. from transceivers of other devices or external servers. Transceiver 1110 may include an RF transmitter for up-converting and amplifying the frequency of the transmitted signal, an RF receiver for performing low-noise amplification on the received signal and down-converting the frequency of the received signal, etc. However, this is merely one embodiment of transceiver 1110, and the components of transceiver 1110 are not limited to RF transmitters and RF receivers. Furthermore, transceiver 1110 can receive signals via a wireless channel, output the signals to processor 1120, and transmit signals output by processor 1120 via a wireless channel.

[0472] Processor 1120 is a component for overall control of the device. Processor 1120 can control the overall operation of the device according to the various embodiments described above.

[0473] The device may also include a memory (not shown). The memory may store data, such as basic programs, applications, or configuration information for device operation. Furthermore, the memory may include at least one storage medium, which may include at least one of the following: flash memory, hard disk, multimedia card, card-type memory (e.g., SD or XD memory), magnetic storage, magnetic disk, optical disk, random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), programmable read-only memory (PROM), or electrically erasable programmable read-only memory (EEPROM). Additionally, the processor 1120 can perform various operations by using various programs, content, data, etc., stored in the memory.

[0474] Figure 12 This is a diagram illustrating the structure of an RSP server according to an embodiment of the present disclosure.

[0475] Reference Figure 12 The server may include a transceiver 1210 and a processor 1220. Some servers described in this disclosure may correspond to those in the reference numerals. Figure 12 The server is described. However, the server configuration is not limited to... Figure 12 The configuration, and can include more Figure 12 The components shown are more than those in the diagram, and include more than [other components]. Figure 12 The components shown are fewer than those in the original document. According to some embodiments, transceiver 1210 and processor 1220 may be implemented as a chip. Furthermore, the server may also include memory. Processor 1220 may be configured as at least one processor.

[0476] According to embodiments of this disclosure, transceiver 1210 can transmit signals, information, data, etc. to a device, and receive signals, information, data, etc. from a device. Transceiver 1210 may include an RF transmitter for up-converting and amplifying the frequency of the transmitted signal, an RF receiver for performing low-noise amplification of the received signal and down-converting the received signal, etc. However, this is merely an embodiment of transceiver 1210, and the components of transceiver 1210 are not limited to RF transmitters and RF receivers. Furthermore, transceiver 1210 can receive signals via a wireless channel, output the signals to processor 1220, and transmit signals output by processor 1220 via a wireless channel.

[0477] At least one processor 1220 is a component for an overall control server. The processor 1220 can control the overall operation of the server according to the various embodiments described above. The at least one processor 1220 may be designated as a controller.

[0478] The server may also include memory (not shown). The memory may store data, such as basic programs, applications, or configuration information for server operation. Furthermore, the memory may include at least one storage medium, which may include at least one of the following: flash memory, hard disk, multimedia card, card-type memory (e.g., SD or XD memory), magnetic storage, magnetic disk, optical disk, random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), programmable read-only memory (PROM), or electrically erasable programmable read-only memory (EEPROM). Furthermore, the processor 1220 can perform various operations by using various programs, content, data, etc., stored in the memory.

[0479] In the detailed embodiments described above, the components included in this disclosure are expressed in a singular or plural form. However, the singular or plural expressions have been suitably chosen for the purposes of description, and the invention is not limited to a singular or plural number of components. Although a component has been expressed in a plural form, it can be configured in a singular form. Although a component has been expressed in a singular form, it can be configured in a plural form.

[0480] Although detailed embodiments have been described in the detailed description of this disclosure, this disclosure can be modified in various ways without departing from its scope. Therefore, the scope of this disclosure should not be limited to the foregoing embodiments, but should be defined by the claims and their equivalents.

[0481] The various embodiments of this disclosure and the terminology used in those embodiments are not intended to limit the technology described herein to any particular embodiment, but should be interpreted as including various variations, equivalents, and / or alternatives to the respective embodiments. Similar reference numerals may be used for similar parts in the description of the drawings. Singular expressions may include plural expressions unless expressly defined in the context. In this disclosure, expressions such as “A or B,” “at least one of A and / or B,” “A, B, or C,” or “at least one of A, B, and / or C” may include all possible combinations of the listed items. Expressions such as “first,” “second,” “first,” or “second” may modify the corresponding components without regard to their order or importance and are used to distinguish only one component from the others, without limiting the corresponding components. When describing a (e.g., first) component as “(functionally or communicatively) connected to” or “linked to” other (e.g., second) components, a component may be directly connected to other components or may be connected to other components through other components (e.g., a third component).

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

[0483] Various embodiments of this disclosure can be implemented as software (e.g., a program) including instructions stored in a machine-readable storage medium (e.g., internal or external memory). A device is a device that can invoke stored instructions from a storage medium and can operate in response to the invoked instructions, and may include devices according to various embodiments of this disclosure. When instructions are processed by a processor (e.g., Figure 11 The processor 1120 or Figure 12 When the processor 1220 in the processor is executed, the processor may perform the function corresponding to the instruction directly or by using other components under the control of the processor. The instruction may include code generated or executed by a compiler or interpreter.

[0484] Machine-readable storage media may be provided in the form of non-transitory storage media. In this case, "non-transitory" simply means that the storage medium does not contain signals and is tangible, and that it is impossible to distinguish whether data is stored semi-permanently or temporarily in the storage medium.

[0485] Methods according to the various embodiments disclosed herein can be included in and provided in a computer program product. The computer program product can be traded as a product between a seller and a buyer. The computer program product can be distributed in the form of a device-readable storage medium (e.g., an optical disc read-only memory (CD-ROM)) or online via an app store (e.g., PlayStore™). In the case of online distribution, at least some of the computer program product can be temporarily stored or temporarily generated in a storage medium, such as memory in a manufacturer's server, an app store's server, or a relay server. Each of the components (e.g., modules or programs) according to the various embodiments can consist of a single entity or multiple entities. Some of the corresponding sub-elements described above can be omitted, or other sub-elements can be further included in the various embodiments. Alternatively or additionally, some components (e.g., modules or programs) can be integrated into a single entity. The single entity can perform the functions performed by each of the corresponding components before the corresponding components are integrated in the same or similar manner. Operations performed by modules, programs, or other components according to the various embodiments can be performed sequentially, in parallel, repeatedly, or tentatively, or at least some operations can be performed in a different order, or can be omitted, or other operations can be added.

[0486] Although this disclosure has been described with reference to various embodiments, those skilled in the art may suggest various changes and modifications. This disclosure is intended to include such changes and modifications that fall within the scope of the appended claims.

Claims

1. A method performed by a first device in a communication system, the method comprising: The profile identifying the first device is to be downloaded to the second device of the first or second version; Based on the first code used for the first version and the second code used for the second version, a third code for downloading the profile is identified; Send the third code to the second device; as well as Based on the transmission of the third code, the profile is sent to the profile server. The third code includes the first code used in the first version and the second code used in the second version. Wherein, the first code is the transmission code used by the second device of the first version to download the profile of the first device, and The second code is the activation code used by the second device of the second version to download the profile of the first device.

2. The method according to claim 1, wherein: The first code includes at least one of the following: information indicating the profile, address information of the profile server, information associated with the first device, or information relating to available options for downloading the profile on the second device. The second code includes at least one of the following: information indicating the format of the second code, address information of the profile server, information indicating the profile, or information indicating that the profile has been deleted or suspended in the first device.

3. The method according to claim 1, further comprising: Receive a request from the profile server to delete the profile of the first device.

4. A method performed by a second device of a first or second version in a communication system, the method comprising: Receive a third code for downloading a profile of the first device from the first version of the first device, the third code being identified based on the first code for the first version and the second code for the second version; If the version of the second device is the first version, the first code from the third code is sent to the profile server; If the version of the second device is the second version, send the second code from the third code to the profile server; as well as Based on the transmission of the first code or the second code, the profile is received from the profile server. The third code includes the first code used in the first version and the second code used in the second version. The first code is a transmission code used by the second device of the first version to download the profile of the first device. The second code is the activation code used by the second version of the second device to download the profile of the first device.

5. The method according to claim 4, wherein: The first code includes at least one of the following: information indicating the profile, address information of the profile server, information associated with the first device, or information relating to available options for downloading the profile on the second device. The second code includes at least one of the following: information indicating the format of the second code, address information of the profile server, information indicating the profile, or information indicating that the profile has been deleted or suspended in the first device.

6. A method performed by a profile server in a communication system, the method comprising: Receive one of the first code or the second code from a second device of the first version or the second version; Based on the first code or the second code, identify the version of the first device that has the file to be downloaded to the second device installed; Based on the version identification of the first device, the profile is received from the first device; as well as Send the profile to the second device. Wherein, the first code is the transmission code used by the second device of the first version to download the profile of the first device, and The second code is the activation code used by the second version of the second device to download the profile of the first device.

7. The method according to claim 6, further comprising: If the version of the second device is the first version, then receive the first code, and If the second device is version 2, receive the second code. The first code includes at least one of the following: information indicating the profile, address information of the profile server, information associated with the first device, or information relating to available options for downloading the profile on the second device. The second code includes at least one of the following: information indicating the format of the second code, address information of the profile server, information indicating the profile, or information indicating that the profile has been deleted or suspended in the first device.

8. The method according to claim 6, further comprising: If the first device is version 1, a request is sent to the first device to delete the profile of the first device.

9. A first device of a first version in a communication system, the first device comprising: transceiver; as well as A processor, operatively connected to the transceiver and configured to: The profile identifying the first device needs to be downloaded to the second device, which is either the first version or the second version. Based on the first code used in the first version and the second code used in the second version, a third code for downloading the profile is identified. The third code is sent to the second device via the transceiver, and Based on the transmission of the third code, the profile is sent to the profile server via the transceiver. The third code includes the first code used in the first version and the second code used in the second version. Wherein, the first code is the transmission code used by the second device of the first version to download the profile of the first device, and The second code is the activation code used by the second device of the second version to download the profile of the first device.

10. The first device according to claim 9, wherein: The first code includes at least one of the following: information indicating the profile, address information of the profile server, information associated with the first device, or information relating to available options for downloading the profile on the second device. The second code includes at least one of the following: information indicating the format of the second code, address information of the profile server, information indicating the profile, or information indicating that the profile has been deleted or suspended in the first device.

11. The first device according to claim 9, wherein, The processor is further configured to: The transceiver receives a request from the profile server to delete the profile of the first device.

12. A second device in a first or second version of a communication system, the second device comprising: transceiver; as well as A processor, operatively connected to the transceiver and configured to: The transceiver receives, via the first device of the first version, third code for downloading a profile of the first device, the third code being identified based on the first code for the first version and the second code for the second version. If the version of the second device is the first version, the first code from the third code is sent to the profile server via the transceiver. If the second device is version 2, the second code from the third code is sent to the profile server via the transceiver, and Based on the transmission of the first code or the second code, the profile is received from the profile server via the transceiver. The third code includes the first code used in the first version and the second code used in the second version. Wherein, the first code is the transmission code used by the second device of the first version to download the profile of the first device, and The second code is the activation code used by the second version of the second device to download the profile of the first device.

13. The second device according to claim 12, wherein: The first code includes at least one of the following: information indicating the profile, address information of the profile server, information associated with the first device, or information relating to available options for downloading the profile on the second device. The second code includes at least one of the following: information indicating the format of the second code, address information of the profile server, information indicating the profile, or information indicating that the profile has been deleted or suspended in the first device.

14. A profile server in a communication system, the profile server comprising: transceiver; as well as A processor, operatively connected to the transceiver and configured to: The transceiver receives either the first code or the second code from the second device of the first or second version. Based on the first code or the second code, identify the version of the first device that has the file to be downloaded to the second device installed. Based on the version identification of the first device, the profile is received from the first device via the transceiver; as well as The file is sent to the second device via the transceiver. Wherein, the first code is the transmission code used by the second device of the first version to download the profile of the first device, and The second code is the activation code used by the second version of the second device to download the profile of the first device.

15. The profile server according to claim 14, wherein: The transceiver is also configured to: If the version of the second device is the first version, then receive the first code, and If the second device is version 2, receive the second code. The first code includes at least one of the following: information indicating the profile, address information of the profile server, information associated with the first device, or information relating to available options for downloading the profile on the second device. The second code includes at least one of the following: information indicating the format of the second code, address information of the profile server, information indicating the profile, or information indicating that the profile has been deleted or suspended in the first device. The processor is also configured to: If the first device is version 1, a request to delete the profile of the first device is sent to the first device via the transceiver.

Images