Method and apparatus for restoring a profile in case of device change failure

Abstract

The disclosure relates to a communication technology and a system thereof for combining IoT technology with a 5G communication system to support a higher data transmission rate than an ultra 4G system. The disclosure can be applied to intelligent services (e.g., smart home, smart building, smart city, smart car or connected car, health care, digital education, retail business, security and safety-related services, etc.) based on 5G communication technology and IoT-related technology. The disclosure provides a method and apparatus for recovering a profile in case of profile movement failure during profile movement between intelligent security media.

Description

Technical Field

[0001] This disclosure relates to smart security media, and more specifically, to a method and apparatus for recovering a file in the event of a file movement failure when the file is moved between smart security media. 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 "beyond 4G networks" or "post-LTE systems." 5G communication systems are considered to be implemented in higher frequency (millimeter wave (mmWave)) bands (e.g., the 60 GHz 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, system network improvements are being developed based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, cooperative multipoint (CoMP), and receiver interference cancellation. In 5G systems, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) have also been developed 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.

[0003] The internet, a human-centric network of connections where humans generate and consume 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), combining IoT technology with cloud server connectivity and big data processing, has emerged. As technological elements necessary for realizing IoT, such as sensing technology, wired / wireless communication and network infrastructure, service interface technology, and security technology, sensor networks, machine-to-machine (M2M) communication, and machine-type communication (MTC) have recently been studied. Such an IoT environment can provide intelligent internet technology services, creating new value for human life by collecting and analyzing data generated between interconnected things. Through the convergence and integration of existing information technology (IT) and various industrial applications, IoT can be applied to a wide range of fields, including smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0004] Correspondingly, 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. Cloud radio access networks (RAN), as an application of the aforementioned big data processing technologies, can also be considered an example of the integration of 5G and IoT technologies.

[0005] The above information is presented as background information only to aid in understanding this disclosure. No determination or assertion is made regarding whether any of the above can be applied to this disclosure as prior art. Summary of the Invention

[0006] Technical issues

[0007] As mentioned above, with the development of mobile communication systems, various services can be provided, and a solution is needed to effectively provide such services. For example, a method is needed to securely and efficiently move profiles (or profile packages) online between two devices.

[0008] Technical solution

[0009] The disclosed embodiments provide an apparatus and method for recovering a profile in the event of a profile movement failure when a profile is moved between security modules included in two electronic devices.

[0010] According to one aspect of this disclosure, a method is performed by a first device in a communication system. The method includes sending a device change request to a server for installing a profile from the first device onto a second device; receiving a device change response from the server instructing the deletion of the profile; deleting the profile from the first device based on the response; and sending a recovery request for the deleted profile to the server based on a stored server address.

[0011] According to another aspect of this disclosure, a method performed by a server in a communication system includes: receiving from a first device a device change request to install a profile in the first device onto a second device; sending a device change response to the first device instructing the deletion of the profile; and receiving from the first device a recovery request for the deleted profile, wherein the address of the server is stored in the first device.

[0012] According to another aspect of this disclosure, a first device in a communication system includes a transceiver; and a controller configured to send a device change request via the transceiver to a server for installing a profile in the first device onto a second device, receive a device change response via the transceiver from the server instructing the deletion of the profile in the device change request, delete the profile in the first device based on the response, and send a recovery request for the deleted profile via the transceiver to the server based on the server's storage address.

[0013] According to another aspect of this disclosure, a server in a communication system includes a transceiver; and a controller configured to receive, via the transceiver, a device change request from a first device to install a profile in the first device onto a second device, to send via the transceiver a device change response to the device change request instructing the deletion of the profile, and to receive via the transceiver from the first device a request to restore a deleted profile, wherein the address of the server is stored in the first device.

[0014] Before proceeding with the detailed description below, it may be advantageous to define certain words and phrases used throughout this patent document: the terms “comprising” and “including” and their derivatives mean unrestricted inclusion; the term “or” is inclusive, meaning and / or; the phrases “associated with” and “associated with” and their derivatives can mean including, being included, interconnected with, containing, being contained, connected to or connected with, coupled to or coupled with, able to communicate with, cooperate with, interleaved, juxtaposed, proximate, combined with or combined with, having, having characteristics, etc.; 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 some combination of both. It should be noted that the functionality associated with any particular controller can be centralized or distributed, local or remote.

[0015] 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 does not include 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 and media that can store data and be rewritten later, such as rewritable optical discs or erasable storage devices.

[0016] This patent document provides definitions for certain words and phrases, and those skilled in the art should understand that, in many cases, if not most, such definitions apply to the prior and future use of the words and phrases defined in this way.

[0017] Beneficial effects

[0018] According to various embodiments of this disclosure, if a migration failure occurs when moving a file installed in one device to another device, the file installed in the original device can be restored. Attached Figure Description

[0019] To gain a more complete understanding of this disclosure and its advantages, reference is now made to the following description in conjunction with the accompanying drawings, wherein like reference numerals denote like parts:

[0020] Figure 1 A method for connecting a terminal to a mobile communication network using a UICC with a fixed profile installed in the terminal, according to an embodiment of the present disclosure, is shown.

[0021] Figure 2 An example of a method according to an embodiment of the present disclosure is shown, wherein two terminals and a server interact to move a profile or profile-related service online or offline from one terminal to another.

[0022] Figure 3 The document illustrates possible states according to embodiments of the present disclosure and the conditions for transitioning to each state;

[0023] Figure 4A process for preparing a device change according to an embodiment of the present disclosure is illustrated;

[0024] Figure 5 An example of a process for performing device changes according to embodiments of the present disclosure is shown;

[0025] Figure 6 Another example of a process for performing device changes according to embodiments of the present disclosure is shown;

[0026] Figure 7 An embodiment according to this disclosure is shown. Figure 4 The detailed process of step S410 provided in the document;

[0027] Figure 8 A method is shown for putting a profile in a "suspended" state or restoring a "suspended" profile to an available state through remote profile management according to embodiments of the present disclosure;

[0028] Figure 9 Another method for restoring a "suspended" profile to a usable state according to embodiments of the present disclosure is shown;

[0029] Figure 10 A method for reinstalling a deleted profile in a source terminal to perform a device change, according to an embodiment of the present disclosure, is illustrated.

[0030] Figure 11 Another example of a process for performing device changes according to embodiments of the present disclosure is shown;

[0031] Figure 12 The configuration of a terminal equipped with eUICC according to an embodiment of this disclosure is shown; and

[0032] Figure 13 The configuration of an RSP server according to an embodiment of this disclosure is shown. Detailed Implementation

[0033] The following discussion Figures 1 to 13 The various embodiments used to describe the principles of this disclosure in this patent document are merely exemplary and should not be construed in any way as limiting the scope of this disclosure. Those skilled in the art will understand that the principles of this disclosure 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. In describing the embodiments of the present disclosure, descriptions related to techniques well-known in the art and not directly related to the present disclosure will be omitted. Unnecessary descriptions are omitted to prevent obscuring the main concept of the present disclosure and to more clearly convey the main concept.

[0035] For the same reason, some elements may be exaggerated, omitted, or shown schematically in the accompanying drawings. Furthermore, the size of each element does not perfectly reflect its actual size. In the drawings, identical or corresponding elements have the same reference numerals.

[0036] The advantages and features of this disclosure, as well as the ways in which they are implemented, will become apparent from the embodiments described in detail below with reference to the accompanying drawings. However, this disclosure is not limited to the embodiments set forth below, but can be implemented in various different forms. The following embodiments are provided only to fully disclose this disclosure and to inform those skilled in the art of its scope, and this disclosure is limited only by the scope of the appended claims. Throughout the specification, the same or similar reference numerals denote the same or similar elements.

[0037] Here it will be understood that each box in a flowchart illustration, and combinations of boxes in a flowchart illustration, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, create means for implementing the functions specified in one or more boxes of the flowchart. These computer program instructions can also be stored in a computer-usable or computer-readable storage medium, which can instruct the computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-usable or computer-readable storage medium produce an article of manufacture including instruction means for implementing the functions specified in the flowchart boxes or boxes. The computer program instructions can also be loaded onto a computer or other programmable data processing device to cause a series of operational steps to be performed on the computer or other programmable device, thereby producing a computer-implemented process, such that the instructions, which execute on the computer or other programmable device, provide steps for implementing the functions specified in one or more boxes of the flowchart.

[0038] Furthermore, each box in the flowchart can represent a module, code segment, or code section, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions mentioned in the boxes may not appear in a specific order. For example, two boxes shown consecutively may actually be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order, depending on the functions involved.

[0039] As used herein, "cell" refers to a software or hardware element that performs a predetermined function, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC). However, "cell" does not always have a meaning limited to software or hardware. A "cell" can be configured to be stored in addressable memory or to execute one or more processors. Therefore, a "cell" includes, for example, software elements, object-oriented software elements, class elements or task elements, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and parameters. The elements and functions provided by a "cell" can be combined into a smaller number of elements or "cells," or divided into a larger number of elements or "cells." Furthermore, elements and "cells" can be implemented as replicas of one or more CPUs within a device or secure multimedia card.

[0040] In this disclosure, when describing embodiments, modifiers such as "first," "second," etc., as used herein, are used to distinguish various terms. Terms modified by modifiers such as "first" and "second" may refer to different objects. However, terms modified by modifiers such as "first" and "second" may refer to the same object. That is, modifiers such as "first" and "second" can be used to refer to the same object from different perspectives. For example, modifiers such as "first" and "second" can be used to distinguish the same object based on function or operation. For example, "first user" and "second user" can refer to the same user.

[0041] Furthermore, in this disclosure, each embodiment is described by way of example of SSP and UICC as security media, but the scope of this disclosure is not limited to SSP and UICC. For example, it will be apparent to those skilled in the art that the various embodiments described below can be applied substantially the same or similarly to other security media that perform substantially the same or similar functions as SSP and UICC.

[0042] The specific terminology used in the following description is provided to aid in understanding this disclosure, and these specific terms may be changed to other forms without departing from the technical spirit of this disclosure.

[0043] A Universal Integrated Circuit Card (UICC) is a smart card inserted into and used in mobile communication terminals, etc., also known as a UICC card. A UICC represents a chip that stores the personal information of mobile communication subscribers (such as network access authentication information, telephone number lists, and SMS), and performs subscriber authentication and service security key generation when accessing mobile communication networks (such as GSM, WCDMA, LTE, etc.), thereby enabling stable use of mobile communications.

[0044] A UICC may include an access control module for accessing a mobile operator's network. For example, the access control module includes a Universal Subscriber Identification Module (USIM), a Subscriber Identification Module (SIM), an IP Multimedia Service Identification Module (ISIM), etc. A UICC including a USIM may be referred to as a USIM card. Similarly, a UICC including a SIM module may be referred to as a SIM card. The terms "SIM card," "UICC card," "USIM card," and "UICC including ISIM" in this disclosure are used herein to mean the same thing. That is, the content of this disclosure can be equally applied to SIM cards, USIM cards, ISIM cards, or ordinary UICC cards.

[0045] Simultaneously, the SIM module can be installed during UICC manufacturing or downloaded to the UICC card to use mobile communication services at the user's desired time. Furthermore, multiple SIM modules can be downloaded and installed onto the UICC card, and at least one SIM module can be selected and used. The UICC card may or may not be fixed in the terminal. A UICC fixed in the terminal is called an embedded UICC (eUICC). Specifically, a UICC embedded in a system-on-a-chip (SoC), including the terminal's communication processor, application processor, or a single-processor architecture integrating both a communication processor and an application processor, can be called an integrated UICC (iUICC). Typically, eUICCs and iUICCs are fixed to the terminal and used, and can represent a UICC card that includes the ability to remotely download at least one SIM module and select one from the downloaded SIM modules.

[0046] In this disclosure, a UICC card that includes the ability to remotely download and select at least one SIM module will be referred to as an eUICC or iUICC. That is, among UICC cards that include the ability to remotely download and select a SIM module, UICC cards that are fixed or not fixed in the terminal are collectively referred to as eUICC or iUICC.

[0047] In this disclosure, the term UICC is used interchangeably with SIM, and the term eUICC is used interchangeably with eSIM.

[0048] The term "eUICC identifier (eUICC ID)" can be a unique identifier of the eUICC embedded in the terminal, and can be referred to as the EID. Furthermore, when a supply profile is pre-installed in the eUICC, the eUICC identifier (eUICC ID) can be the identifier of the corresponding supply profile (the profile ID of the supply profile). Additionally, in embodiments of this disclosure, when the terminal and the eUICC chip are not separated, the eUICC identifier (eUICC ID) can be the terminal ID. Furthermore, the eUICC identifier (eUICC ID) can refer to a specific security domain of the eUICC chip.

[0049] The term "profile" can refer to data objects stored in UICC, such as applications, file systems, and authentication key values.

[0050] In this disclosure, the term "profile package" can refer to the contents of a "profile" packaged into a software format that can be installed in a UICC. A "profile package" can be referred to as a profile TLV or a profile package TLV. When a profile package is encrypted using encryption parameters, it can be referred to as a protected profile package (PPP) or a protected profile package TLV (PPP TLV). When a profile package is encrypted using encryption parameters that can only be decrypted by a specific eUICC, it can be referred to as a bound profile package (BPP) or a bound profile package TLV (BPPTLV). A profile package TLV can be a dataset expressing information about a configuration profile in TLV (tag, length, value) format. In this disclosure, "profile package" and "profile" are used interchangeably.

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

[0052] [Enabled]

[0053] In this disclosure, the operation of enabling a profile by a terminal refers to configuring the terminal to receive communication services through a mobile operator that has already provided the profile by changing the profile's state to an enabled state. A profile in an enabled state can be represented as an "enabled profile".

[0054] [Disabled]

[0055] In this disclosure, the operation of disabling a profile by a terminal refers to configuring the terminal not to receive communication services from a mobile operator that has already provided the profile by changing the profile's state to a disabled state. A profile in a disabled state can be represented as a "disabled profile".

[0056] [Deleted]

[0057] In this disclosure, the operation of deleting a profile by a terminal can be represented by configuring the terminal to no longer enable or disable profiles by changing the profile's state to a deleted state. A profile in a deleted state can be represented as a "deleted profile".

[0058] In this disclosure, the operation of enabling, disabling, or deleting profiles on the terminal can represent the operation of marking each profile as "to be enabled," "to be disabled," or "to be deleted," without immediately changing the state of each profile to enabled, disabled, or deleted, and then changing the state of each profile to "enabled," "disabled," or "deleted" after a specific operation (e.g., a refresh or reset command) is performed on the terminal or the UICC of the terminal. The operation of marking a profile as scheduled (i.e., to be enabled, to be disabled, or to be deleted) is not necessarily limited to marking one schedule state for a profile, and can separately mark one or more profiles as being in the same or different schedule states, mark a profile as being in one or more schedule states, or mark one or more profiles as being in the same or different schedule states.

[0059] Furthermore, when the terminal displays the status of one or more scheduled profiles, the two flags for the scheduled status can be integrated into one flag. For example, if a scheduled profile is flagged as both "to be disabled" and "to be deleted", the profile can be flagged as a combination of "to be disabled" and "to be deleted".

[0060] Furthermore, the terminal can sequentially or simultaneously perform operations to mark the scheduling state for one or more profiles. Additionally, the terminal can sequentially or simultaneously perform operations to mark the scheduling state for one or more profiles, and then actually change the profile's state.

[0061] The term "profile delimiter" can be referred to as a profile identifier (profile ID), integrated circuit card ID (ICCID), match ID, event identifier (event ID), activation code, activation code token, command code, command code token, signed command code, unsigned command code, ISD-P, or a factor of the match profile field (PD). The profile ID can indicate a unique identifier for each profile. The profile delimiter may also include the address of the profile provider server (SM-DP+) capable of indexing the profile. Furthermore, the profile delimiter may also include the signature (SM-DP+) of the profile provider server.

[0062] The term "Remote SIM Provisioning (RSP) Server" can be used to refer to the name of a profile provisioning server and / or a profile management server and / or an open intermediary server, which will be described later. An RSP server can be represented as a subscription manager XX (SM-XX).

[0063] In this disclosure, the term "profile provider server" may include the functionality of 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 at least one of Subscription Manager Data Preparation (SM-DP), Subscription Manager Data Preparation Plus (SM-DP+), an off-card entity of a profile domain, a profile encryption server, a profile generation server, a profile provider (PP), a profile provider, or a profile provider credential holder (PPC holder).

[0064] In this disclosure, a "profile management server" may include the function of managing profiles. A profile management server may be represented as a Subscription Manager Security Router (SM-SR), a Subscription Manager Security Router Plus (SM-SR+), an off-card entity of the eUICC Profile Manager, a Profile Management Credential Holder (PMC Holder), an eUICC Manager (EM), a Profile Manager (PP), etc.

[0065] In this disclosure, the profile providing server can also provide the functionality of a profile management server. Therefore, in various embodiments of this disclosure, the operation of the profile providing server can also be performed by the profile management server. Similarly, the operation of the profile management server or the SM-SR can also be performed by the profile providing server.

[0066] In this disclosure, the term "open mediation server" can refer to the Subscription Manager Discovery Service (SM-DS), the Discovery Service (DS), the Root Open Mediation Server (Root SM-DS), and the Alternate Open Mediation Server (Alternate SM-DS). An open mediation server can receive event registration requests from one or more profile providing servers or open mediation servers. Furthermore, one or more open mediation servers can be used in combination, and a first open mediation server can receive event registration requests from a second open mediation server and a profile providing server.

[0067] The term "mobile operator" can refer to an enterprise that provides communication services to terminals, and can be a term collectively referring to the mobile operator's Business Support System (BSS), Operations Support System (OSS), and Point-of-Sale (POS) terminals, as well as other IT systems. Furthermore, in this disclosure, "mobile operator" is not limited to referring to only one specific enterprise that provides communication services, and can be used as a term to refer to a group or association (or consortium) of one or more enterprises, or an agent representing that group or association. Additionally, in this disclosure, a mobile operator can be referred to as 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., and each mobile operator can be configured or assigned at least one name and / or unique identifier (Object Identifier (OID)). If a mobile operator refers to a group, association, or agent of one or more enterprises, the name or unique identifier of the designated group, association, or agent can be shared by all enterprises belonging to that group or association, or all enterprises cooperating with that agent.

[0068] The term "subscriber" can be used to refer to either a service provider that owns the terminal or an end user that owns the terminal. Typically, a terminal owned by a service provider can be called an M2M device, and a terminal owned by a user can be called a user device (consumer device). In the case of an M2M terminal, there may be an end user who uses the terminal by taking over or leasing it from a service provider, although the user does not own the terminal, and here, the subscriber may be different from or the same as the service provider.

[0069] The term "subscriber intent" can be used collectively to refer to a subscriber's intent to manage a profile locally or remotely. Furthermore, in the case of local management, subscriber intent can refer to end-user intent, while in the case of remote management, subscriber intent can be used as a term referring to service provider intent.

[0070] The term "end-user consent" can be used to indicate whether a user consents to local or remote administration.

[0071] The term "terminal" can refer to a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, subscriber unit, subscriber station (SS), wireless device, wireless communication device, wireless transceiver unit (WTRU), mobile node, mobile device, or other terms. Various embodiments of a terminal may include a cellular phone, a smartphone with wireless communication capabilities, a personal digital assistant (PDA) with wireless communication capabilities, a wireless modem, a portable computer with wireless communication capabilities, a shooting device such as a digital camera with wireless communication capabilities, a gaming device with wireless communication capabilities, a home appliance with wireless communication capabilities for storing and reproducing music, an internet-connected home appliance capable of performing wireless internet access and browsing, and a portable unit or terminal integrating these functions. Furthermore, a terminal may include, but is not limited to, machine-to-machine (M2M) terminals and machine-type communication (MTC) terminals / devices. In this disclosure, a terminal may be referred to as an electronic device.

[0072] In this disclosure, a UICC capable of downloading and installing profiles can be embedded in an electronic device. If the UICC is not embedded in the electronic device, it can be connected to the electronic device by being physically separated from it and inserted into it. For example, the UICC can be in the form of a card for insertion into the electronic device. The electronic device may include a terminal, and the terminal may include a UICC capable of downloading and installing profiles. The UICC can be embedded in the terminal, and if the UICC is detached from the terminal, it can also be inserted into the terminal for connection. A UICC capable of downloading and installing profiles may be referred to as, for example, an eUICC.

[0073] The term "Local Profile Assistant (LPA)" can refer to software or applications installed on a terminal or electronic device to control the UICC or eUICC on the terminal or electronic device.

[0074] "Event" can be a term encompassing profile download, remote profile management, or other profile or eUICC management / processing instructions. An event can be referred to as a Remote SIM Provisioning Operation (RSP Operation) or an event log, and each event can be referred to as an event identifier (event ID), a matching identifier (match ID), or data including at least one of the following: the address (FQDN, IP address, or URL) of the Open Mediation Server (SM-DS) or Profile Provisioning Server (SM-DP+) storing the corresponding event, a signature of the Open Mediation Server (SM-DS) or Profile Provisioning Server (SM-DP+), or a digital signature of the Open Mediation Server (SM-DS) or Profile Provisioning Server (SM-DP+).

[0075] The data corresponding to an event can be called a "command code". The process using all or part of the command code can be called a "command code processing procedure" or "command code procedure", or "Local Profile Assistant Application Programming Interface (LPAAPI)". Profile download can be used interchangeably with profile installation.

[0076] Furthermore, "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, replacement, updating, etc.), or other profile or eUICC management / processing commands. Event type can be referred to as operation type, operation class, event request type, event class, event request class, etc. Regarding the predefined event identifier (eventID or matchingID), the path through which the terminal has obtained the corresponding event identifier (eventID or matchingID) or the use of the corresponding event identifier (eventID source or matchingID source) can be specified.

[0077] The term "profile management" can be broadly divided into "local profile management" and "remote profile management".

[0078] The term "Local Profile Management (LPM)" can also be referred to as profile local management, local management, local management commands, local commands, Local Profile Management (LPM) package, profile local management package, local management package, local management command package, local command package, etc. LPM can be used to change the status (enabled, disabled, deleted) of a specific profile, or to modify (update) the content of a specific profile (e.g., profile nickname, profile summary information (profile metadata), etc.) through software installed in the terminal. An LPM can include one or more local management commands. Here, depending on each local management command, the profiles that conform to each local management command can be the same or different.

[0079] The term "Remote Profile Management (RPM)" can also be referred to as profile remote management, remote management, remote management commands, remote commands, remote profile management packages (RPM packages), profile remote management packages, remote management packages, remote management command packages, and remote command packages. RPMs can be used to change the status of a specific profile (enabled, disabled, and deleted) or to modify (update) the content of a specific profile (e.g., profile nickname or profile summary information (profile metadata)). An RPM can include one or more remote management commands, and the profile that conforms to each remote management command can be the same or different for each remote management command.

[0080] The term "certificate" or digital certificate can refer to a digital certificate used for mutual authentication based on asymmetric keys, which include a pair of public keys (PK) and private keys (SK). Each certificate may include one or more public keys (PK), a public key identifier (PKID) corresponding to each public key, an identifier (Certificate Publisher ID) of the Certificate Issuer (CI) that issued the corresponding certificate, and a digital signature. The Certificate Issuer may be referred to as a Certification Publisher, Certification Authority (CA), or Certification Authority, etc. In this disclosure, the public key (PK) and the public key identifier (PKID) can be used to refer to a certificate that includes a specific public key or a portion thereof, a portion thereof that includes a specific public key or a portion thereof, a calculated value (e.g., a hash value) of a specific public key, a calculated value (e.g., a hash value) of a portion thereof, or a calculated value (e.g., a hash value) of a portion thereof that includes a portion thereof, or storage space that stores multiple data.

[0081] According to a "certificate chain" or certificate hierarchy, a certificate issued by a "certificate issuer" (primary certificate) can be used to issue another certificate (secondary certificate). Furthermore, if a secondary certificate is used to issue a tertiary or higher-level certificate, the certificate chain or certificate hierarchy can indicate the relevance of the corresponding certificates. Here, the CI certificate used to issue the initial certificate can be referred to as the root certificate, highest certificate, root CI, root CI certificate, root CA, root CA certificate, etc.

[0082] Furthermore, in describing this disclosure, detailed descriptions of relevant known functions or configurations will be omitted where it is determined that such detailed descriptions may unnecessarily obscure the subject matter of this disclosure.

[0083] In the following sections, various embodiments relating to methods and apparatus for moving and installing profiles between terminals will be described.

[0084] Figure 1 A method for connecting a terminal to a mobile communication network using a UICC with a fixed profile installed in the terminal, according to an embodiment of the present disclosure, is illustrated.

[0085] like Figure 1 As shown, the UICC 120 can be inserted into the terminal 110. For example, the UICC 120 can be detachable or pre-embedded in the terminal.

[0086] A UICC with a fixed profile indicates that the "access information" allowed to access a specific mobile operator is fixed. For example, access information may include the IMSI as a subscriber delimiter, the K or Ki value required for network authentication, and the subscriber identifier.

[0087] Terminal 110, according to various embodiments, can use UICC 120 to perform authentication with a mobile operator's authentication processing system (e.g., Home Location Register (HLR) or AuC). For example, the authentication process can be an authentication and key agreement (AKA) process. If authentication is successful, the terminal can use mobile communication services such as telephone calls or mobile data usage through the mobile communication operator network 130 using the mobile communication system.

[0088] Figure 2 An example of a method according to an embodiment of the present disclosure is shown, wherein two terminals and a server interact to move a profile or profile-related service from one terminal to another.

[0089] like Figure 2 As shown, the first terminal 200 is equipped with a first eSIM 203, and the second terminal 220 is equipped with a second eSIM 223. Profiles (not shown) can be installed in the first eSIM 203 and the second eSIM 223. Furthermore, a first LPA 201 and a second LPA 221 can be installed in the first terminal 200 and the second terminal 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 user 205 and the second user 225 can control the profiles installed in the eSIMs (first eSIM 203 and second eSIM 223) of their respective terminals via the first LPA 201 and the second LPA 221, respectively. Here, the first user 205 and the second user 225 can be the same. Furthermore, the first LPA 201 and the second LPA 221 can be connected to each other to perform communication. Possible connection methods between LPAs will be described below.

[0090] The first LPA 201 of the first terminal 200 can be connected to the first RSP server 240, and the second LPA 221 of the second terminal 220 can be connected to the second RSP server 280. Here, the first RSP server 240 and the second RSP server 280 can be the same. Furthermore, for convenience, the figure shows each of the first RSP server 240 and the second RSP server 280 configured as a single server. However, depending on the implementation and embodiment, one or more profile providing servers (SM-DP+) can be included in the server configuration. The server configuration may include one or more open mediation servers (SM-DS) that help generate connections between specific profile providing servers and terminals. Furthermore, although not shown in the figure, one or more RSP servers and / or relay servers can be connected between the first RSP server 240 and the second RSP server 280.

[0091] Furthermore, although not shown in the diagram, each RSP server and / or relay server can connect to a carrier server. When the configuration includes one or more carrier servers, each carrier server can connect to each individual RSP server and / or relay server, and at least one carrier server can connect to the same RSP server and / or relay server.

[0092] The configuration of the various servers described above can be simply represented as a single RSP server in the following figures. For example, one or more RSP servers and / or relay servers are connected between the first terminal 200 and the second terminal 220. If some or all of the RSP servers and / or relay servers are connected to the operator's server, the configuration of the various servers existing between the first terminal and the second terminal can be represented as a single RSP server, which may be referred to as SM-XX in the figures and embodiments.

[0093] Figure 3 A profile of possible states according to an embodiment of this disclosure and the conditions for transitioning to each state are shown.

[0094] refer to Figure 3 The profile can be in an enabled state 310. A profile in an enabled state can receive communication services through the mobile operator that provides the profile.

[0095] refer to Figure 3 A profile can be in a disabled state (350). A profile in a disabled state cannot receive telecommunications services through the mobile operator that provided the profile.

[0096] Although the difference between the enabled and disabled states lies in whether communication services are currently being received, both states can be considered "available" because they can be switched between each other according to user intent, as will be discussed later. That is, profiles in either the enabled or disabled states can use communication services without the help of an RSP server (in the case of the disabled state, communication services can be used if the user changes the disabled state to the enabled state). Therefore, profiles in both the enabled and disabled states can be considered available.

[0097] refer to Figure 3A profile can be in a paused state 390. A paused profile cannot be used unless it becomes enabled or disabled due to conditions described later. That is, as described later, a "paused" state can be considered an "unavailable" state because a paused state may not change to an enabled or disabled state based on user intent. In other words, a profile in a "paused" state can be considered unavailable because even if the user wants to, they can only use the communication service with the help and / or approval of the RSP server.

[0098] In addition, refer to Figure 3 According to local profile management or remote profile management, a profile that is enabled can be changed to a disabled state. Here, local profile management can be performed by user input. Furthermore, although not shown in the figure, a profile that is enabled can be changed to a suspended state according to local profile management or remote profile management. Local profile management can be performed by user input, or it can be performed as part of another operation (e.g., the device change operation described in this disclosure).

[0099] In addition, refer to Figure 3 According to local profile management or remote profile management, a profile that is in a disabled state can be changed to an enabled state. Here, local profile management can be performed by user input. In addition, according to local profile management or remote profile management, a profile that is in a disabled state may be changed to a suspended state. Here, local profile management can be performed by user input, or it can be performed as part of another operation (e.g., the device change operation described in this disclosure).

[0100] In addition, refer to Figure 3 According to remote profile management, a profile that is paused can be turned into a disabled state. Alternatively, although not shown in the diagram, a profile can be turned into an enabled state according to remote profile management. (See also...) Figure 8 or Figure 9 Describes the process of changing a suspended profile to a disabled and / or enabled state based on remote profile management.

[0101] The "paused state" can be a type of "disabled state". For example, flags or parameters related to "paused" can be additionally included in the "disabled state". These flags or parameters can be located in the profile or profile metadata.

[0102] Some possible examples of distinguishing between "disabled state" and "paused state" by using the above flags or parameters are as follows.

[0103] (1) For example, if additional flags or parameters are included, the profile can be considered to be in a "suspended state"; otherwise, the profile can be considered to be in a "disabled state".

[0104] (2) As another example, even with the addition of flags or parameters, the “paused state” and “disabled state” can be distinguished based on the value of the flags or parameters. For example, if the value of the flag or parameter is 1, it can indicate the “paused” state, and if the value of the flag or parameter is 0, it can indicate the “disabled” state.

[0105] The method described above for distinguishing between "paused state" and "disabled state" is merely an example and is not limited to this.

[0106] Figure 4 A process for preparing for device changes according to an embodiment of the present disclosure is illustrated.

[0107] Figure 4 The source terminal 410 shown may include at least one LPA and at least one eSIM. (Refer to...) Figure 2 Description of RSP server 490.

[0108] According to one embodiment, source terminal 410 may include a pre-installed profile.

[0109] Furthermore, according to one embodiment, the source terminal 410 may include "device change information" associated with a pre-installed profile. This "device change information" may be configured by the mobile operator before performing a device change and may be stored in the terminal. If the source terminal 410 has already installed the corresponding profile, the above process can be performed.

[0110] "Equipment change information" may include factors containing the following information:

[0111] - Device changes are not supported in the corresponding profile;

[0112] - Supports device changes according to the corresponding documentation, provided that a remote procedure is first performed to obtain the "Device Change Method"; and / or

[0113] - Supports device changes in the corresponding profile. The device change method is included in the device change information. Here, device changes can be performed through local procedures, without being subject to remote procedures.

[0114] If the corresponding profile is configured for "remote processing", the "Device Change Information" may also include the following information:

[0115] - The address of the server to be accessed in order to obtain the device change method;

[0116] - When accessing the server, does the source terminal 410 need to display the target terminal's eUICC identifier to obtain the device change method; and / or

[0117] - When accessing a server, if the target terminal wants to receive the transmitted services in order to obtain the device's change method, does it need to display information required to perform an eligibility check, which is related to whether the corresponding documentation can be downloaded and installed?

[0118] The "device change method (or device change type)" pre-stored in device change information or information obtainable through the aforementioned "remote process" may include all or some of the following factors:

[0119] - Information related to the processing of the profile installed in the source terminal.

[0120] This information may include the following:

[0121] - Delete the file;

[0122] - Configure the profile to be paused; and / or

[0123] - Do not perform any special processing on the profile;

[0124] - Information regarding the method for providing a notification to the RSP server that yields the same result when the source terminal 410 deletes the profile or configures the profile to be paused. This information may include the following:

[0125] - The source terminal 410 itself needs to provide notifications to the RSP server; and / or

[0126] - Source terminal 410 provides notifications to the RSP server via the target terminal. Here, a "partial notification" method can be used. For details on partial notifications, please refer to the description below. Figure 5 and Figure 6 Description;

[0127] - A factor indicating whether a request can be made to restore a profile that has been deleted or configured to be paused; that is, it can include a restore request permission indicator. An example of using this factor is as follows:

[0128] - A terminal can request the recovery of a deleted profile only if the recovery request allow indicator, which indicates whether a request to recover a deleted profile can be made, is configured to "recovery allowed". Here, recovering a deleted profile can refer to the process of reinstalling a profile with the same functionality as the deleted profile in the terminal; and / or

[0129] - A terminal may request the restoration of a profile configured to be suspended only if the restoration request permission indicator, which indicates whether a request to restore a profile configured to be suspended is configured to "restore," is set to "restore." Here, restoring a profile configured to be suspended can refer to the process of resetting a profile that has been configured to be suspended to an enabled state.

[0130] refer to Figure 4 In step S400, the service subscriber or end user can select a source profile associated with the service they want to transmit to the target terminal from the communication services currently used by the terminal (i.e., source terminal 410). Here, the source terminal 410 can provide the service subscriber or end user with the information required for device changes.

[0131] Reference Figure 4 In step S405, the source terminal 410 can identify the "device change information" of the profile associated with the service that the user wants to transmit.

[0132] When the "Device Change Information" indicates that device changes for the corresponding profile are not supported, the device change process can be stopped.

[0133] If the "Device Change Information" indicates that a remote procedure needs to be executed first to obtain the "Device Change Method" when a device change that supports the corresponding profile is required, then step S410 can be executed.

[0134] If the "Device Change Information" indicates that device changes are supported for the corresponding profile, and the "Device Change Method" is included in the Device Change Information, then step S415 can be executed.

[0135] refer to Figure 4 In step S410, a remote procedure can be executed. (Refer to...) Figure 7 The remote procedure is described in detail. In step S410, the source terminal 410 can obtain the "Device Change Method" from the RSP server 490.

[0136] Reference Figure 4 In step S415, the source terminal 410 may perform a process of receiving user consent related to whether to perform device changes and / or the method for performing device changes.

[0137] Combining the information from the processing of the profile installed on the source terminal 410 via step S410 of the "Device Change Method" provided by the RSP server, or the "Device Change Method" pre-stored in the terminal and received with user consent via step S415, if the information includes a configuration for deleting the corresponding profile, execution can proceed. Figure 6 The process can be executed if the information includes a configuration where the corresponding profile is set to be paused. Figure 5 The process, and if the information includes configurations that prevent special operations from being performed for the corresponding profile, can be executed. Figure 11 The process.

[0138] Figure 5 An example of a process for performing device changes according to embodiments of the present disclosure is shown.

[0139] Specifically, when the "Information related to the processing of the profile installed in the source terminal" in the "Device Change Method" includes a configuration where the corresponding profile is configured to be in a paused state, execution is possible. Figure 5 The processing.

[0140] Figure 5 The source terminal 510 and target terminal 550 shown may each include at least one LPA and at least one eSIM. (Refer to...) Figure 2 Description of RSP server 590.

[0141] Reference Figure 5 In step S500, the source terminal 510 may configure the source profile associated with the service to be transmitted to the target terminal 550 to be in a "paused" state.

[0142] Subsequently, based on the information included in "Information related to the method of providing configuration result notification to the RSP server when the source terminal 510 configures the profile to be in a paused state" in the "Device Change Method", the process can branch as follows.

[0143] If the information includes information configured to indicate that "the source terminal 510 itself needs to provide a notification to the RSP server 590", then step S505 can be performed.

[0144] If the information includes information configured to indicate that “source terminal 510 provides notification to RSP server 590 through target terminal 550”, then step S510 can be performed.

[0145] Step S515 can be performed after step S505 or step S510.

[0146] refer to Figure 5 In step S505, the source terminal 510 may provide the RSP server 590 with a notification that the source terminal itself has configured the source profile to be in a paused state. If the source terminal 510 sends a pause notification to the RSP server 590, the above process can be executed.

[0147] A “pause notification” may include at least one of the following:

[0148] -Notification serial number;

[0149] - This indicates that the source terminal 510 has configured the profile to be in a paused state;

[0150] - The address of the RSP server 590 to receive the notification;

[0151] - The profile delimiter for profiles configured to be in a paused state;

[0152] - A signature value used by the source terminal 510 (e.g., an eUICC installed on the source terminal) to digitally sign all or part of the information; or

[0153] - A series of certificate information used to verify the signature value.

[0154] In step S505, although not shown in the figure, the source terminal 510 may prepare an activation code to be sent to the target terminal 550. Here, the activation code to be sent to the target terminal 550 may be included as part of the "device change method". Here, the source terminal 510 may extract the activation code included in the "device change method" and prepare to send the activation code to the target terminal 550.

[0155] Activation codes may include one or more of the following information:

[0156] -Information indicating the format of the activation code;

[0157] - Target terminal 550 can access information from RSP server 590 (e.g., address and / or OID) to download profiles; and / or

[0158] - Indicates the information of the profile that the target terminal 550 wants to download (e.g., the matching ID associated with the profile to be downloaded, which can be generated by the RSP server and linked to the corresponding profile, and therefore can be managed by the RSP server).

[0159] Reference Figure 5 In step S510, the source terminal 510 can generate a "partial pause notification", which is sent to the RSP server 590 through the target terminal 550.

[0160] A "partial suspension notice" may include one or more of the following information:

[0161] -Notification serial number;

[0162] - This indicates that the source terminal has configured the profile to be in a paused state;

[0163] - The address of the RSP server 590 to receive the notification;

[0164] - The profile delimiter configured to be in a paused state; and / or

[0165] - A signature value obtained by the source terminal (e.g., an eUICC installed on the source terminal) for digitally signing all or part of the above information.

[0166] That is, a partial suspension notification can be a series of information in addition to a series of certificate information used to verify the signature value in the suspension notification.

[0167] In step S510, although not shown in the figure, the source terminal 510 may prepare an activation code to be sent to the target terminal 550. For example, the source terminal 510 may generate an activation code and prepare to send it to the target terminal 550. The activation code may include one or more of the following information:

[0168] -Information indicating the format of the activation code;

[0169] - The target terminal 550 can access the RSP server 590 to download information (e.g., address and / or OID) of the profile.

[0170] - Indicates information about the profile that the target terminal 550 wants to download (e.g., the profile delimiter of the profile to be downloaded); and / or

[0171] - Partial pause notification (e.g., a partial pause notification sent from source terminal 510 to target terminal 550 in step S510).

[0172] Reference Figure 5 In step S515, the source terminal 510 may send the activation code prepared in step S505 or S510 to the target terminal 550.

[0173] Activation codes may include one or more of the following information:

[0174] -Information indicating the format of the activation code;

[0175] - The target terminal 550 can access the RSP server 590 to download information (e.g., address and / or OID) of the profile.

[0176] - Indicates information about the file that the target terminal 550 wants to download; and / or

[0177] - Partial suspension notice.

[0178] The activation code above can be transferred using one of the methods provided below.

[0179] For example, source terminal 510 can provide the user with information that will be sent to target terminal 550 through its UI. The user can then input the received information using the UI of target terminal 550.

[0180] Alternatively, the source terminal 510 generates information to be sent to the target terminal 550 in the form of an image (e.g., a QR code), and the generated image is displayed on the screen of the source terminal 510. The user sends the information to the target terminal 550 by scanning the image displayed on the screen of the source terminal.

[0181] Alternatively, a connection can be established between the source terminal 510 and the target terminal 550, and the established connection can be used to send information. Here, the connection established between the source terminal 510 and the target terminal 550 can be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi Direct, LTE device-to-device (D2D), a wireless connection such as 5G D2D, or a wired connection such as a cable connection), or it can be a remote connection between the source terminal 510 and the target terminal 550 with a remote server (e.g., a relay server) located between them.

[0182] Reference Figure 5 In step S520, the target terminal 550 can download and install the file from the RSP server 590.

[0183] The target terminal 550 can establish a connection with the RSP server 590 and request a file from the RSP server 590 using information included in the activation code (e.g., information indicating the file the target terminal 550 wants to download). The RSP server 590 can prepare the file to be sent to the target terminal 550 based on the received information. In the above process, at least one of the following processes may be further included:

[0184] - Mutual authentication between the target terminal 550 and the RSP server;

[0185] - A qualification check performed by the RSP server to determine whether the profile to be sent can be installed and run correctly on the target terminal 550; or

[0186] - The user agrees to install the corresponding file on the target terminal 550.

[0187] The RSP server can send the prepared profile to the target terminal 550. The target terminal 550 can then install the profile received from the RSP server on the target terminal 550 (e.g., the eUICC of the target terminal 550).

[0188] Reference Figure 5 In step S525, the target terminal 550 can send the installation results of the file to the RSP server 590.

[0189] Figure 6 Another example of a process for performing device changes according to embodiments of this disclosure is shown.

[0190] Specifically, if the "Information related to the processing of the profile installed in the source terminal 610" in the "Device Change Method" includes a configuration that the corresponding profile is to be deleted, then execution is possible. Figure 6 The process.

[0191] Figure 6 The source terminal 610 and target terminal 650 shown may each include at least one LPA and at least one eSIM. (Refer to...) Figure 2 Description of RSP server 690.

[0192] Reference Figure 6 In step S600, the source terminal 610 may delete the source profile associated with the service, which will be transmitted to the target terminal 650.

[0193] Subsequently, based on the information included in the "Method for Providing a Notification of Profile Deletion Results to RSP Server 690 When the Source Terminal 610 Has Deleted the Profile" in the "Device Change Method", the process can branch as follows.

[0194] If the information includes information configured to indicate that "the source terminal 610 itself needs to provide a notification to the RSP server 690", then step S605 can be performed.

[0195] If the information includes information configured to indicate that “source terminal 610 provides a notification to RSP server 690 through target terminal 650”, then step S610 can be performed.

[0196] Step S615 can be performed after step S605 or step S610.

[0197] Reference Figure 6 In step S605, the source terminal 610 can provide the RSP server 690 with a notification that the source terminal itself has deleted the source profile. If the source terminal 610 sends a deletion notification to the RSP server 690, the above process can be executed.

[0198] A “removal notification” may include at least one of the following:

[0199] -Notification serial number;

[0200] - This indicates that the source terminal 610 has deleted the profile;

[0201] - The address of the RSP server 690 to receive the notification;

[0202] - The delimiter of the deleted profile;

[0203] - A signature value obtained by the source terminal 610 (e.g., an eUICC installed on the source terminal) digitally signing all or part of the above information; or

[0204] -A series of certificate information used to verify the signature value

[0205] In step S605, although not shown in the figure, the source terminal 610 may prepare an activation code to be sent to the target terminal 650. Here, the activation code to be sent to the target terminal 650 may be included as part of the "device change method". Here, the source terminal 610 may extract the activation code included in the "device change method" and prepare to send the activation code to the target terminal 650.

[0206] Activation codes may include one or more of the following information:

[0207] -Information indicating the format of the activation code;

[0208] - Target terminal 650 can access information from RSP server 690 (e.g., address and / or OID) to download profiles; and / or

[0209] - Indicates information about the profile that the target terminal 650 wants to download (e.g., a matching ID associated with the profile to be downloaded, which can be generated by the RSP server and linked to the corresponding profile, and therefore can be managed by the RSP server).

[0210] Reference Figure 6 In step S610, the source terminal 610 can generate a "partial deletion notification", which is sent to the RSP server 690 through the target terminal 650.

[0211] A partial removal notice may include one or more of the following information:

[0212] -Notification serial number;

[0213] - This indicates that the source terminal has deleted the profile;

[0214] - The address of the RSP server to receive the notification;

[0215] - The profile delimiter of the deleted profile; and / or

[0216] - A signature value digitally signed by the source terminal 610 (e.g., an eUICC installed on the source terminal) for all or part of the above information.

[0217] That is, a partial deletion notice can be a series of information in addition to a series of certificate information used to verify the signature value in the deletion notice.

[0218] In step S610, although not shown in the figure, the source terminal 610 may prepare an activation code to be sent to the target terminal 650. For example, the source terminal 610 may generate an activation code and prepare to send it to the target terminal 650.

[0219] Activation codes may include one or more of the following information:

[0220] -Information indicating the format of the activation code;

[0221] - The target terminal 650 can access the RSP server 690 to download information (e.g., address and / or OID) of the profile.

[0222] - Indicates information about the profile that the target terminal 650 wants to download (e.g., the profile delimiter of the profile to be downloaded); and / or

[0223] - Partial deletion notification (e.g., a partial deletion notification sent by the source terminal 610 to the target terminal 650 in step S610).

[0224] Reference Figure 6 In step S615, the source terminal 610 may send the activation code prepared in step S605 or S610 to the target terminal 650.

[0225] Activation codes may include one or more of the following information:

[0226] -Information indicating the format of the activation code;

[0227] - The target terminal 650 can access information about the RSP server (e.g., address and / or OID) to download the profile.

[0228] - Indicates information about the file that the target terminal 650 wants to download; and / or

[0229] - Partial deletion notification.

[0230] The activation code can be transmitted using one of the methods provided below.

[0231] For example, source terminal 610 can provide information to the user that will be sent to target terminal 650 through its UI. The user can then input the provided information using the UI of target terminal 650.

[0232] Alternatively, source terminal 610 generates information to be sent to target terminal 650 in the form of an image (e.g., a QR code), and the generated image is displayed on the screen of the source terminal. The user scans the image displayed on the screen of source terminal 610 using target terminal 650 to send the information to target terminal 650.

[0233] Alternatively, a connection can be established between the source terminal 610 and the target terminal 650, and the established connection can be used to send information. Here, the connection established between the source terminal 610 and the target terminal 650 can be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi Direct, LTE device-to-device (D2D), a wireless connection such as 5G D2D, or a wired connection such as a cable connection), or it can be a remote connection between the source terminal 610 and the target terminal 650 with a remote server (e.g., a relay server) located between them.

[0234] Reference Figure 6 In step S620, the target terminal 650 can download and install the file from the RSP server 690. The above process may include the following procedures.

[0235] The target terminal 650 can establish a connection with the RSP server 690 and request a file from the RSP server 690 using information included in the activation code (e.g., information indicating the file the target terminal 650 wants to download). The RSP server 690 can prepare the file to be sent to the target terminal 650 based on the received information. In the above process, at least one of the following processes may be further included:

[0236] - Mutual authentication between the target terminal 650 and the RSP server;

[0237] - A qualification check performed by the RSP server to determine whether the profile to be sent can be installed and run correctly on the target terminal 650; or

[0238] - The user agrees to install the corresponding file on the target terminal 650.

[0239] The RSP server can send the prepared profile to the target terminal 650. The target terminal 650 can then install the profile received from the RSP server on the target terminal 650 (e.g., the target terminal's eUICC).

[0240] Reference Figure 6 In step S625, the target terminal 650 can send the installation results of the file to the RSP server 690.

[0241] Figure 7 An embodiment according to this disclosure is shown. Figure 4 The detailed process of step S410 provided in the document.

[0242] Figure 7 The source terminal 710 and target terminal 750 shown may each include at least one LPA and at least one eSIM. (Refer to...) Figure 2 Description of RSP server 790.

[0243] Reference Figure 7 In step S700, the source terminal 710 can obtain the address of the RSP server 790 that it can attempt to access in order to obtain the "Device Change Method". The address of the RSP server 790 that the source terminal may attempt to access can be included in the "Device Change Information".

[0244] refer to Figure 7 The following procedure can be performed in step S705.

[0245] If the "Device Change Information" includes information configured to indicate that the source terminal 710 needs to display the eUICC identifier of the target terminal 750 in order to obtain the device change method when accessing the server, then the source terminal 710 can obtain the eUICC identifier of the target terminal 750. This process can be performed by the source terminal 710 receiving the eUICC identifier of the target terminal 750 from the target terminal 750.

[0246] If the "Device Change Information" includes information configured to instruct the target terminal 750 to display information required to perform a qualification check when the source terminal 710 accesses the server to obtain a device change method, and this qualification check involves whether the profile associated with the service the target terminal wants to receive can be downloaded and installed, then the source terminal 710 can obtain the information of the target terminal 750 required for the qualification check. This process can be performed by the source terminal 710 receiving the target terminal 750's eUICC information (euiccinfo2) and information such as LPA and modem (deviceinfo) from the target terminal 750.

[0247] Reference Figure 7 In step S710, mutual authentication can be performed between the source terminal 710 and the RSP server 790. The mutual authentication process may include one or more of the following example processes.

[0248] In one example, the mutual authentication process may include a certificate negotiation process required for communication between the source terminal 710 and the RSP server 790. For instance, the source terminal 710 may send multiple certificate information that can be used to verify the RSP server 790 and / or multiple certificate information that the RSP server 790 can use to verify the source terminal 710. Upon receiving this information, the RSP server 790 can select the multiple certificate information that the source terminal 710 will use to verify the RSP server 790 and / or multiple certificate information that the RSP server 790 can use to verify the source terminal 710. Here, the multiple certificate information selected by the RSP server 790 can be sent to the source terminal 710. Through this process, the source terminal 710 and the RSP server 790 can obtain certificate information for mutual authentication. Here, the certificate information may be a certificate, information included in the certificate, and / or a series of information that may involve the certificate.

[0249] In another example, source terminal 710 can send a pre-defined random number (eUICC challenge) value generated by itself to RSP server 790. RSP server 790 can digitally sign the received random number and then send the signed value to source terminal 710. Source terminal 710 can verify the received signature value to authenticate RSP server 790.

[0250] In another example, RSP server 790 can send a random number (server challenge) value generated by itself to source terminal 710. Source terminal 710 can digitally sign the received random number value and then send the signed value to RSP server 790. RSP server 790 can verify the received signature value to authenticate source terminal 710.

[0251] In yet another example, during communication between RSP server 790 and source terminal 710, IDs (transaction IDs) used to manage the session can be exchanged. For instance, RSP server 790 can generate a transaction ID and send its value to source terminal 710. Here, a digital signature value from RSP server 790 can be added to verify the reliability and integrity of the transaction ID.

[0252] In yet another example, RSP server 790 and source terminal 710 can exchange their own IDs. For instance, RSP server 790 can provide source terminal 710 with its own object identifier (OID). As another example, source terminal 710 can provide RSP server 790 with its own eUICC identifier.

[0253] refer to Figure 7 The following procedure can be performed in step S715.

[0254] The source terminal 710 can send a profile delimiter to the RSP server 790 for the profile associated with the service to be transmitted to the target terminal 750.

[0255] The source terminal 710 may send a request for service delivery, i.e., a device change request, to the RSP server 790. The device change request may include the eUICC identifier of the target terminal 750. The device change request may include the eUICC information (euiccinfo2) of the target terminal 750 and information such as LPA and modem (deviceinfo).

[0256] Reference Figure 7 In step S720, the RSP server 790 can prepare a profile to be sent to the target terminal 750.

[0257] During the preparation of the profile, if it is necessary to perform qualification identification to determine whether the corresponding profile can be installed and run normally on the target terminal 750, the RSP server can use the eUICC information (euiccinfo2) of the target terminal 750 received in step S715 and information such as LPA and modem (deviceinfo) to perform qualification checks.

[0258] If the profile needs to be matched with the eUICC identifier of the target terminal 750 during the profile preparation process, the RSP server 790 can perform the matching process by using the eUICC identifier of the target terminal 750 received in step S715.

[0259] Reference Figure 7 In step S725, the RSP server 790 can send a response message to the target terminal 750 in response to the device change request, i.e., a device change response. The device change response may include a "device change method." (Refer to...) Figure 4 A description of the "device change method". The device change response may also include a message from the mobile operator notifying the user about the device change.

[0260] Reference Figure 7 In step S730, the source terminal 710 may receive user consent related to the device change. If a message indicating that the mobile operator wants to provide the user with a notification about the device change was sent in step S725, this message may be provided to the user during the process of obtaining user consent.

[0261] Reference Figure 7 In step S735, the source terminal 710 can send the result of user consent to the RSP server 790.

[0262] The result of user consent may include one of the following messages:

[0263] - The user agrees to the device changes;

[0264] - The user does not agree to the device changes;

[0265] - The user postpones device changes; and / or

[0266] - No user response.

[0267] Reference Figure 7 In step S740, the following process can be performed.

[0268] If the user agrees to the device change, the RSP server 790 can send a success message to the source terminal 710 instructing the continuation of the device change process.

[0269] When the user disagrees with the device change, the RSP server 790 can cancel the preparation of the download of the profile prepared in step S720.

[0270] Figure 8 A method is shown for putting a profile in a "paused" state or restoring a "paused" profile to an available state through remote profile management according to embodiments of the present disclosure.

[0271] Figure 8 The terminal 810 shown may include at least one LPA and at least one eSIM. (Refer to...) Figure 2 Description of RSP server 890.

[0272] Reference Figure 8 In step S800, terminal 810 may obtain the address of RSP server 890 from which it will receive the Remote Profile Management Package (RPMpackage). The address of the RSP server that terminal 810 wants to access may be pre-stored in terminal 810, or terminal 810 may access another RSP server (e.g., another Open Mediation Server (SM-DS)) to obtain the address of the RSP server that the terminal can access in order to receive the Remote Profile Management Package (RPMpackage).

[0273] Reference Figure 8 In step S805, mutual authentication can be performed between terminal 810 and RSP server 890. This mutual authentication process may include one or more of the following example processes.

[0274] In one example, the mutual authentication process may include a certificate negotiation process required for communication between terminal 810 and RSP server 890. For example, terminal 810 may send multiple certificate information that can be used to verify RSP server 890 and / or multiple certificate information that RSP server 890 can use to verify terminal 810. Upon receiving this information, RSP server 890 can select the multiple certificate information that terminal 810 will use to verify RSP server 890 and / or multiple certificate information that RSP server 890 can use to verify terminal 810. Here, the multiple certificate information selected by RSP server 890 can be sent to terminal 810. Through this process, terminal 810 and RSP server 890 can obtain certificate information for mutual authentication. Here, certificate information may be a certificate, information included in a certificate, and / or a series of information that may involve a certificate.

[0275] In another example, terminal 810 can send a pre-defined random number (eUICC challenge) value generated by terminal 810 itself to RSP server 890. RSP server 890 can digitally sign the received random number and then send the signed value to terminal 810. Terminal 810 can verify the received signature value to authenticate RSP server 890.

[0276] In another example, RSP server 890 can send a random number (server challenge) value generated by itself to terminal 810. Terminal 810 can digitally sign the received random number value and then send the signed value to RSP server 890. RSP server 890 can verify the received signature value to authenticate terminal 810.

[0277] In yet another example, during communication between RSP server 890 and terminal 810, IDs (transaction IDs) used to manage the session can be exchanged. For instance, RSP server 890 can generate a transaction ID and send its value to terminal 810. Here, a digital signature value from RSP server 890 can be added to verify the reliability and integrity of the transaction ID.

[0278] In yet another example, within this disclosure, RSP server 890 and terminal 810 can exchange profile identifiers to perform remote profile management. For instance, terminal 810 can send a profile identifier for remote profile management to RSP server 890. Here, the profile identifier can be sent along with a digital signature value from terminal 810 to ensure reliability and integrity.

[0279] In yet another example, RSP server 890 and terminal 810 can exchange their own IDs. For instance, RSP server 890 can provide terminal 810 with its own object identifier (OID). As another example, terminal 810 can provide RSP server 890 with its own eUICC identifier.

[0280] Reference Figure 8 In step S810, the following process can be performed.

[0281] RSP server 890 can identify whether a remote profile management package (RPM package) is to be sent to terminal 810 by using the received eUICC identifier and / or profile delimiter from terminal 810. The RPM package may include one or more of the following remote profile management commands:

[0282] - Enable profile;

[0283] -Disable shortcuts;

[0284] - Put the profile in a paused state; and / or

[0285] -Restore the profile.

[0286] RSP server 890 can send RPM packages to terminal 810.

[0287] Reference Figure 8 In step S815, terminal 810 can execute the received remote profile management command.

[0288] If terminal 810 receives a remote profile management command instructing it to "pause the profile," it can perform one of the following procedures: If the corresponding profile is disabled, the terminal can change the profile to a paused state. If the corresponding profile is enabled, the terminal can change the profile to a paused state. Alternatively, if the corresponding profile is enabled, the terminal can disable the profile and then change the profile to a paused state.

[0289] If terminal 810 receives a remote profile management command instructing it to "enable profile", it can perform one of the following procedures: If the corresponding profile is disabled, the terminal can change the profile to an enabled state. If the corresponding profile is paused, the terminal can change the profile to an enabled state. Optionally, if the corresponding profile is paused, the terminal can disable the profile and then change it to an enabled state.

[0290] If terminal 810 receives a remote profile management command instructing "disable profile", it can perform one of the following procedures: If the corresponding profile is enabled, the terminal can change the profile to disabled. If the corresponding profile is paused, the terminal can change the profile to disabled.

[0291] If terminal 810 receives a remote profile management command instructing it to "restore profile", it can perform one of the following procedures: Terminal 810 can change a profile that is in a suspended state to a disabled state. Terminal 810 can change a profile that is in a suspended state to an enabled state. Terminal 810 can change a profile that is in a suspended state to a disabled state, and then change the profile to an enabled state.

[0292] Reference Figure 8 In step S820, terminal 810 may generate a remote profile management execution result (loadRPMpackageresult) based on the result of the executed remote profile management command. The "remote profile management performance result" may include one or more of the following information:

[0293] - A profile delimiter for profiles that execute remote profile management commands;

[0294] - Remote profile management commands that have already been executed;

[0295] --The profile has been enabled;

[0296] --The profile has been disabled;

[0297] --The profile has been changed to a paused state; and / or

[0298] --The file has been restored.

[0299] Reference Figure 8 In step S825, terminal 810 can send the "Remote Profile Management Performance Result" generated in step S820 to RSP server 890.

[0300] If it is necessary to restore the existing version due to an error in step S520 Figure 5 The profile paused in step S500 can then use the aforementioned remote profile management process, particularly the process of restoring, enabling, and / or disabling a paused profile (for convenience, the process of "restoring, enabling, and / or disabling a paused profile" will be collectively referred to as the "profile restoration process" later). That is, if in Figure 5 If an error occurs in step S520 and the profile installation does not execute correctly on the target terminal, then the above steps can be performed. Figure 8The profile is made available so that the source terminal can make the profile, which was in a suspended state (i.e., in step S500), available. More detailed information related to this is as follows.

[0301] (1) Steps for preparing the RSP server to be restored.

[0302] exist Figure 5 In step S520, if an error occurs when the target terminal 550 downloads and / or installs the profile from the RSP server 590, the RSP server 590 can prepare a remote profile management package (RPMpackage) to be sent to the source terminal 510. Here, the RPMpackage may include one or more of the following remote profile management commands to restore the profile:

[0303] - Enable profile;

[0304] -Disable profiles; and / or

[0305] -Restore the profile.

[0306] Here, the conditions under which the RSP server prepares to send the Remote Profile Management Package (RPMpackage) to the source terminal can be at least one of the following:

[0307] An error occurred while downloading the file;

[0308] -In step S520, the mutual authentication between the target terminal and the RSP server fails;

[0309] - Failure to qualify in step S520;

[0310] - A simplified installation rejected by the user in step S520; or

[0311] - A permanent error occurred while installing the profile.

[0312] - A permanent error that occurs when installing a profile refers to an error in which the profile cannot be installed even if the target terminal retryes installing the corresponding profile.

[0313] Temporary errors during profile installation refer to errors that may occur when the target terminal retryes installing the corresponding profile. Temporary errors may occur during profile installation, such as:

[0314] - Installation failure due to insufficient memory: An installation error occurred due to insufficient installation space in eUICC; or

[0315] - Installation failure due to interruption: Installation error occurred due to an unexpected interruption during operation.

[0316] If the aforementioned temporary error occurs in step S520, one of the following procedures can be performed:

[0317] -RSP server does not prepare to send RPM packages to the source terminal

[0318] - The RSP server prepares the RPM package to be sent to the source terminal or

[0319] - If the number of attempts to install the profile on the target terminal reaches the allowed retry limit, and if the profile installation fails after the allowed retry limit is reached, the RSP server prepares an RPM package to send to the source terminal.

[0320] After the RSP server prepares the RPM package to be sent to the source terminal through the above process, the RSP server may perform one or more of the following operations.

[0321] - Store the RPM package and / or data to be sent to the source terminal.

[0322] - An instruction to send an RPM package to the source terminal is registered in another RSP server (another open intermediary server (SM-DS)).

[0323] (2) The source terminal performs the recovery steps.

[0324] After that, as Figure 8 As shown, the process of "restoring a suspended profile" is performed through remote profile management, thus restoring the profile suspended in step S500 in the source terminal 510 (i.e., the profile becomes enabled or disabled, and thus becomes available).

[0325] Here, in Figure 8 The starting step S800 in the process shown can be one of the following:

[0326] -The source terminal 810 begins executing step S800 without external input.

[0327] -Source terminal 810 begins executing step S800 based on the configuration file.

[0328] -Source terminal 810 begins periodically executing step S800

[0329] - The source terminal 810 receives input from the user and begins executing step S800. For example, if the user expresses his / her intention to restore the corresponding profile through the UI provided by the source terminal, then step S800 is executed.

[0330] - The source terminal 810 receives input from the RSP server and begins executing step S800.

[0331] Figure 9 Another method for restoring a "suspended" profile to a usable state, according to embodiments of this disclosure, is shown. Figure 9 In this context, restoring a paused profile to an available state can be represented by the operation of "enabling" or "disabling" the profile state. The process of "restoring a paused profile to an available state" can be simply described as the process of "restoring a profile".

[0332] Figure 9 The source terminal 910 shown may include at least one LPA and at least one eSIM. For the RSP server 990, refer to... Figure 2 The description.

[0333] exist Figure 9 In the process of restoring the profile, you can... Figure 5 Executed after the process. If in Figure 5 If an error occurs in step S520 and the profile needs to be restored, the profile that was paused in step S500 can be used. That is, if in... Figure 5 If an error occurs in step S520, the profile installation cannot be performed normally and cannot be used on the target terminal. In order to make the profile, which is in a suspended state (i.e., in step S500), available on the source terminal, the following procedure can be performed.

[0334] refer to Figure 9 In step S900, the following process can be performed.

[0335] Source terminal 910 can obtain the address of the RSP server 990 to be accessed in order to request profile recovery. The addresses of the RSP servers that source terminal 910 can access can be pre-stored in source terminal 910, and source terminal 910 can access another RSP server (e.g., another Open Mediation Server (SM-DS)) to obtain the address of the RSP server to be accessed in order to perform recovery.

[0336] Here, the condition for the source terminal to begin executing step S900 can be one of the following:

[0337] -Source terminal 910 automatically starts executing step S900

[0338] - The source terminal 910 receives input from the user and begins executing step S900. For example, when the user expresses his / her intention to restore the corresponding profile through the UI provided by the source terminal, step S900 is executed; or

[0339] - The source terminal 910 receives input from the RSP server (e.g., the RSP server indicated by reference numeral 990 or another RSP server) and begins to execute step S900.

[0340] Reference Figure 9 In step S905, mutual authentication can be performed between the source terminal 910 and the RSP server 990. The mutual authentication process may include one or more of the following example processes.

[0341] In one example, the mutual authentication process may include a certificate negotiation process required for communication between the source terminal 910 and the RSP server 990. For instance, the source terminal 910 may send multiple certificate information that can be used to verify the RSP server 990 and / or multiple certificate information that the RSP server 990 can use to verify the source terminal 910. Upon receiving this information, the RSP server 990 can select which multiple certificate information the source terminal 910 will use to verify the RSP server 990 and / or which multiple certificate information that the RSP server 990 can use to verify the source terminal 910. Here, the multiple certificate information selected by the RSP server 990 can be sent to the source terminal 910. Through this process, the source terminal 910 and the RSP server 990 can obtain certificate information for mutual authentication. Here, the certificate information may be a certificate, information included in a certificate, and / or a series of information that may involve a certificate.

[0342] In another example, source terminal 910 may send a predetermined random number (eUICC challenge) value generated by itself to RSP server 990. RSP server 990 may digitally sign the received random number and then send the signed value to source terminal 910. Source terminal 910 may verify the received signature value to authenticate RSP server 990.

[0343] In another example, RSP server 990 can send a pre-generated random number (server challenge) value to source terminal 910. Source terminal 910 can digitally sign the received random number and then send the signed value to RSP server 990. RSP server 990 can verify the received signature value to authenticate source terminal 910.

[0344] In yet another example, during communication between RSP server 990 and source terminal 910, IDs (transaction IDs) used to manage the session can be exchanged. For instance, RSP server 990 can generate a transaction ID and send its value to source terminal 910. Here, a digital signature value from RSP server 990 can be added to verify the reliability and integrity of the transaction ID.

[0345] In yet another example, RSP server 990 and source terminal 910 can exchange their own IDs. For instance, RSP server 990 can provide source terminal 910 with its own object identifier (OID). As yet another example, source terminal 910 can provide RSP server 990 with its own eUICC identifier.

[0346] refer to Figure 9 In step S910, the following process can be performed.

[0347] Source terminal 910 can send a request for profile recovery to RSP server 990. Here, source terminal 910 can send the profile delimiter of the profile to be recovered to RSP server 990.

[0348] refer to Figure 9 In step S915, the following process can be performed.

[0349] RSP server 990 may perform one or more of the following procedures based on the request message received in step S910:

[0350] - By using the received "eUICC identifier of the source terminal" and the "profile delimiter" of the profile requested for recovery, it can be identified that the source terminal is already a valid user of the corresponding profile; and / or

[0351] - It can identify whether the profile requested for recovery can be recovered in the source terminal where the profile was requested for recovery.

[0352] The process of determining whether a requested profile can be recovered in the source terminal where the profile recovery has been requested is described in detail below.

[0353] exist Figure 5 In step S520, if an error occurs during the download and / or installation of the profile on the target terminal 550, the RSP server 990 can determine that it is possible to restore the corresponding profile on the source terminal 910.

[0354] Here, when RSP server 990 determines that the recovery of the corresponding profile is possible, "an error that occurs during the download and / or installation of the profile on the target terminal" may include at least one of the following:

[0355] An error occurred while downloading the file;

[0356] -In step S520, the mutual authentication between the target terminal and the RSP server fails;

[0357] - Failure to qualify in step S520; and / or

[0358] -The installation of the profile that was rejected by the user in step S520;

[0359] - A permanent error occurred while installing the documentation; or

[0360] - A temporary error that occurs during profile installation exceeds the allowed retry limit. That is, when a temporary error occurs, the RSP server and the target terminal can attempt profile installation as many times as allowed (here, the allowed retry limit is a positive integer value including 0), but the profile installation fails because it exceeds the allowed retry limit.

[0361] A permanent error that occurs during profile installation refers to an error in which the profile cannot be installed even if the target terminal retryes the installation of the corresponding profile.

[0362] Temporary errors that occur during profile installation refer to errors that may occur when the target terminal retryes installing the corresponding profile. Temporary errors may occur during profile installation, such as:

[0363] - Installation failure due to insufficient memory: An installation error occurred due to insufficient installation space in eUICC; or

[0364] - Installation failure due to interruption: Installation error occurred due to an unexpected interruption during operation.

[0365] After step S915, steps S920 to S925 can be performed in various ways as follows.

[0366] (1) Determine if the requested file recovery is impossible.

[0367] Reference Figure 9 In step S920, the RSP server 990 may provide a notification to the source terminal 910 that the profile recovery requested in step S910 is not possible.

[0368] (2) Determine if the requested profile recovery is possible (Scenario 1).

[0369] Reference Figure 9 In step S920, the RSP server 990 may provide the source terminal 910 with a notification that the profile recovery requested in step S910 is possible.

[0370] For example, a message sent from an RSP server to a source terminal may include one or more of the following information:

[0371] - The profile delimiter of the profile to be restored;

[0372] - Information about the RSP server (e.g., the OID indicating the RSP server);

[0373] - The eUICC identifier of the source terminal;

[0374] - A flag or parameter indicating whether recovery of the corresponding profile is possible. Flags and parameters can be configured to specific values;

[0375] - A method for restoring the corresponding profile. For example, the method indicates whether the profile needs to be configured to an "enabled" or "disabled" state; and / or

[0376] -RSP server 990 provides a signature value for digitally signing all or part of a message.

[0377] refer to Figure 9 In step S925, the following process can be performed.

[0378] The source terminal 910 can identify the message received in step S920. The source terminal can verify that the digital signature of the received message is valid. The source terminal can identify the content of the received message. That is, the source terminal can identify whether the content of the received message is correct and can identify the operations that need to be performed by the source terminal itself.

[0379] Source terminal 910 can restore the corresponding profile. In other words, the source terminal can make the corresponding profile available. For example, the source terminal can "enable" or "disable" the corresponding profile.

[0380] (3) Determine if the requested profile recovery is possible (Scenario 2).

[0381] Reference Figure 9 In step S920, the RSP server 990 may generate a remote profile management package (RPMpackage) to be sent to the source terminal 910. Here, the RPMpackage may include one or more of the following remote profile management commands:

[0382] - Enable profile;

[0383] -Disable profiles; and / or

[0384] -Restore the profile.

[0385] RSP server 990 can send RPM packages to terminal 910. Here, to ensure the reliability and integrity of the RPM packages, the RSP server can also generate a digital signature value.

[0386] refer to Figure 9 In step S925, the following process can be performed.

[0387] The source terminal 910 can identify the message received in step S920. The source terminal can verify the validity of the received digital signature. The source terminal can identify the content of the received RPM package in order to identify the operations that need to be performed by the source terminal itself.

[0388] Source terminal 910 can restore the corresponding profile. In other words, the source terminal can make the corresponding profile available. For example, the source terminal can "enable" or "disable" the corresponding profile.

[0389] Source terminal 910 can generate a remote profile management execution result (loadRPMpackageresult) based on the result of executing the remote profile management command. The "remote profile management performance result" may include one or more of the following information:

[0390] - The profile delimiter of the profile to which remote profile management commands have been executed; and / or

[0391] - Remote profile management commands that have already been executed:

[0392] - Profiles have been enabled;

[0393] - Profiles have been disabled; and / or

[0394] -The file has been restored.

[0395] The source terminal 910 can send the generated "Remote Profile Management Performance Results" to the RSP server 990.

[0396] (4) Determine if the requested profile recovery is possible (Scenario 3).

[0397] refer to Figure 9 In step S920, the following process can be performed.

[0398] RSP server 990 can prepare a remote profile management package (RPMpackage) to be sent to source terminal 910. This RPMpackage may include one or more of the following remote profile management commands to perform profile restoration:

[0399] - Enable profile;

[0400] -Disable profiles; and / or

[0401] -Restore the profile.

[0402] After the RSP server prepares the RPM package to be sent to the source terminal through the above process, the RSP server can perform one or more of the following operations:

[0403] - Store the RPM package and / or data to be sent to the source terminal.

[0404] - An instruction to send an RPM package to the source terminal is registered in another RSP server (another open mediation server (SM-DS)).

[0405] RSP server 990 can send one or more of the following messages to source terminal 910:

[0406] - The file restoration was approved; and / or

[0407] - The RPM package is prepared.

[0408] After that, as Figure 8 As shown, the process of "restoring a paused profile" can be performed through remote profile management.

[0409] Figure 10 A method for performing device changes by reinstalling deleted profiles on a source terminal, according to an embodiment of this disclosure, is illustrated. Figure 10 In Chinese, the term "reinstall" for a deleted profile can have the same meaning as the term "restore" for a deleted profile.

[0410] Figure 10 The source terminal 1010 shown may include at least one LPA and at least one eSIM. For the RSP server 1090, refer to... Figure 2 The description.

[0411] Figure 10 Implementations of the methods provided in [the document] can be performed through [the following methods]: Figure 6 The process shown was not executed when the profile was not properly installed on the target terminal. That is, after executing step S600, if an error occurs in a step after S605, and therefore the profile is not properly installed on the target terminal, then the following can be executed: Figure 10 The process. A situation where the installation profile is not installed correctly on the target terminal is referred to as a "normal installation profile installation failure on the target terminal," and a detailed description of the "normal installation profile installation failure on the target terminal" is as follows.

[0412] [Situation of normal profile installation failure in the target terminal]

[0413] “A normal profile installation failure in the target terminal” can include at least one of the following situations.

[0414] - The target device does not request the download and installation of the documentation;

[0415] - A situation where the target terminal requests a file download and installation, but an error occurs during the download. Possible examples of errors during file download are as follows:

[0416] --In step S620, the mutual authentication between the target terminal and the RSP server fails;

[0417] -- Qualification check failure in step S620; and / or

[0418] --The installation of the profile was rejected by the user in step S620;

[0419] - Although the target terminal has requested the download and installation of the archive, a permanent error occurs during archive installation; and / or

[0420] - Although the target terminal has requested to download and install the profile, a temporary error occurred during the installation of the profile, exceeding the allowed retry limit. That is, when a temporary error occurs, the RSP server and the target terminal can attempt to install the profile up to the allowed retry limit (here, the allowed retry limit is a positive integer value including 0), but the profile installation fails because the allowed retry limit has been exceeded.

[0421] A permanent error during profile installation refers to an error in which the profile installation cannot be completed even if the target terminal retryes the installation. For example, a permanent error can refer to any error that may occur during installation, in addition to the temporary errors described later.

[0422] A temporary error during profile installation refers to an error that may occur when the target terminal retryes installing the corresponding profile. Possible temporary errors during profile installation may include one of the following examples:

[0423] - Installation failure due to insufficient memory: An installation error occurred due to insufficient installation space in eUICC; or

[0424] - Installation failure due to interruption: Installation error occurred due to an unexpected interruption during operation.

[0425] exist Figure 10 Various embodiments of reinstalling the deleted profile in the source terminal via steps S1000 to S1040 are shown.

[0426] The various embodiments of reinstalling the deleted profile in the source terminal as described in this figure can mainly include the following two processes:

[0427] Step 1. Request: The source terminal sends a recovery request to the RSP server; and

[0428] Step 2. Accept: The RSP server accepts the request from the source terminal and performs the recovery.

[0429] As described above, the execution conditions for the two processes (step 1. request, step 2. accept) can be as follows.

[0430] [Step 1. Request]

[0431] As above Figure 4 As described herein, the source terminal may include a "device change method (or device change type)" associated with the deleted profile, and the "device change method" may include a "recovery request permission indicator" indicating whether a recovery request for the deleted profile can be executed. The source terminal may request the recovery of the deleted profile only if the recovery request permission indicator is configured to "request allowed".

[0432] [Step 2. Accept]

[0433] When the server receives a request from the terminal to restore deleted profiles, the server may perform the restoration after determining whether to do so. The conditions for performing the restoration may include all or some of the conditions described below:

[0434] - Received a request from the terminal to restore (or reinstall) the profile;

[0435] - The recovery request permission indicator associated with the profile is configured to "request allowed";

[0436] -A recovery request indicator has been sent to the source terminal;

[0437] - The terminal requesting profile recovery is the same as the source terminal; and / or

[0438] - It has been confirmed that [a normal profile installation failure has occurred on the target terminal].

[0439] Based on the above conditions, various embodiments of reinstalling the deleted profile in the source terminal will be described below through steps S1000 to S1040.

[0440] refer to Figure 10 In step S1000, the following process can be performed.

[0441] The source terminal can obtain information about the profile to be reinstalled. For example, a user or subscriber can select the profile to be reinstalled through the UI provided by the source terminal. Here is a possible example of the UI:

[0442] 1) The source terminal can provide the user or subscriber with the contents of the deleted profile for device modification;

[0443] 2) The source terminal can provide users or subscribers with input methods for reinstalling deleted profiles to make device changes;

[0444] 3) Users or subscribers can use the above input method to select a profile from the deleted profiles for device changes for reinstallation; and / or

[0445] 4) The source terminal can identify the profile to be reinstalled by user or subscriber input.

[0446] The source terminal can obtain the address of the RSP server 1090 to be accessed in order to reinstall the selected profile. Here are some possible examples of methods for obtaining the address of the RSP server that the source terminal can access:

[0447] - The address of the RSP server accessed to reinstall the profile is pre-stored in the terminal and / or profile (metadata);

[0448] -use Figure 6 The address of the RSP server shown. That is, the address of the RSP server accessed for device changes is (re)used; and / or

[0449] - Access another RSP server (e.g., another Open Mediation Server (SM-DS)) to obtain the address of the RSP server to access during reinstallation.

[0450] refer to Figure 10 After step S1000, one of the following processes may be performed in some cases.

[0451] [Scenario 1]

[0452] When the source terminal is stored Figure 6 This can be performed when an activation code (referred to as a "stored activation code") is prepared in step S605 or S610.

[0453] This situation can occur without the source terminal experiencing... Figure 4 Step S410 (i.e., Figure 7 Executed during the process (which can occur on the source terminal) Figure 4 Step S410 (i.e., Figure 7 The process (but does not send the target terminal's eUICC identifier to the RSP server) is executed, or it can be performed even though the source terminal has already passed... Figure 4 Step S410 (i.e., Figure 7The process involves sending the target terminal's eUICC identifier to the RSP server, but the RSP server does not bind the "Preparation Profile for Device Change" and the "target terminal's eUICC identifier" (i.e., it is configured so that only terminals with the corresponding eUICC identifier can receive the profile). This situation can be provided when the RSP server does not specify a particular terminal (e.g., the target terminal) instead of the source terminal as the terminal capable of receiving the "Preparation Profile for Device Change" (this situation is simply referred to as "the profile is not bound to the target terminal").

[0454] Here, the following procedure can be performed.

[0455] refer to Figure 10 In step S1005, the following process can be performed.

[0456] In one example, the source terminal can send a reinstallation request to the RSP server using the "stored activation code". Here, the conditions under which the source terminal can request reinstallation can follow the conditions in [Step 1. Request].

[0457] In one example, the RSP server can determine whether to perform a reinstallation after receiving a request from the source terminal. Here, the conditions under which the RSP server determines whether to accept the reinstallation can follow the [Step 2. Accept] condition.

[0458] In one example, the RSP server can perform a qualification check on whether a pre-prepared "Preparation Profile for Device Change" can be installed on source terminal 1010. This qualification check can be performed by receiving eUICC information (euiccinfo2) and information such as LPA and modem information (deviceinfo) from source terminal 1010. If the "Preparation Profile for Device Change" is not suitable for source terminal 1010, the RSP server can prepare a profile suitable for source terminal 1010 for reinstallation.

[0459] In one example, all or part of the three processes described above (i.e., the process of the source terminal sending a reinstallation request to the RSP server using a "stored activation code," the process of the RSP server determining whether to perform a reinstallation upon receiving the request from the source terminal, and the process of the RSP server performing an eligibility check and, if necessary, preparing a profile suitable for the source terminal) can be performed as part of a process described later, namely, the process of the source terminal receiving a profile from the RSP server and reinstalling that profile. For example, the source terminal can perform mutual authentication with the RSP server to receive and reinstall the profile, and the three processes described above can be performed as part of that process.

[0460] In one example, the source terminal can receive a profile from the RSP server and reinstall it. This process is similar to... Figure 6 The steps S620 to S625 provided in the previous disclosure are different. (The difference is that the operations performed by the target terminal in steps 620 to S625 are performed by the source terminal in this disclosure.)

[0461] [Scenario 2]

[0462] This can be performed when the profile is bound to a target terminal. That is, when the RSP server specifies a particular terminal (e.g., the target terminal) instead of the source terminal as the terminal capable of receiving the profile prepared for device changes, this can be performed. However, this can also be performed even when the profile is not bound to a target terminal.

[0463] Here, the following procedure can be performed.

[0464] Reference Figure 10 In step S1010, mutual authentication can be performed between the source terminal 1010 and the RSP server 1090. The mutual authentication process may include one or more of the following example processes.

[0465] In one example, the mutual authentication process may include a certificate negotiation process, which is required for the source terminal 1010 and the RSP server 1090 to communicate. For example, the source terminal 1010 may send multiple certificate information that can be used to verify the RSP server 1090 and / or that the RSP server 1090 can use to verify the source terminal 1010. Upon receiving this information, the RSP server 1090 can select which multiple certificate information the source terminal 1010 uses to verify the RSP server 1090 and / or which multiple certificate information the RSP server 1090 can use to verify the source terminal 1010. Here, the multiple certificate information selected by the RSP server 1090 can be sent to the source terminal 1010. Through this process, the source terminal 1010 and the RSP server 1090 can obtain certificate information for mutual authentication. Here, the certificate information may be a certificate, information included in the certificate, and / or a series of information that may involve the certificate.

[0466] In another example, source terminal 1010 can send a pre-defined random number (eUICC challenge) value generated by itself to RSP server 1090. RSP server 1090 can digitally sign the received random number and then send the signed value to source terminal 1010. Source terminal 1010 can verify the received signature value to authenticate RSP server 1090.

[0467] In another example, RSP server 1090 can send a pre-generated random number (server challenge) value to source terminal 1010. Source terminal 1010 can digitally sign the received random number and then send the signed value to RSP server 1090. RSP server 1090 can verify the received signature value to authenticate source terminal 1010.

[0468] In yet another example, during communication between RSP server 1090 and source terminal 1010, IDs (transaction IDs) used for managing the session can be exchanged. For example, RSP server 1090 can generate a transaction ID and send the ID value to source terminal 1010. Here, a digital signature value of RSP server 1090 can be added to verify the reliability and integrity of the transaction ID.

[0469] In yet another example, RSP server 1090 and source terminal 1010 can exchange their own IDs. For instance, RSP server 1090 can provide its own object identifier (OID) to source terminal 1010. As another example, source terminal 1010 can provide its own eUICC identifier to RSP server 1090.

[0470] refer to Figure 10 In step S1015, the following process can be performed.

[0471] Source terminal 1010 may send a request to RSP server 1090 for a reinstallation profile. Here, source terminal 1010 may send the profile delimiter of the profile to be reinstalled to RSP server 1090. Furthermore, the conditions under which the source terminal may request reinstallation may follow the [Step 1. Request] conditions as described above.

[0472] refer to Figure 10 In step S1020, the following process can be performed.

[0473] RSP server 1090 may determine whether to perform a reinstallation based on the request message received in step S1015. The conditions for the RSP server to determine whether to accept the reinstallation may follow the [Step 2. Accept] conditions.

[0474] As a result, if the RSP server determines to reinstall the profile, it can prepare the activation key required for the installation profile and send it to the source terminal. Here, the activation key may include one or more of the following information:

[0475] -Information indicating the format of the activation code;

[0476] - The source terminal can access information about the RSP server (e.g., address and / or OID) to download the profile; and / or

[0477] - Indicates the profile that the source terminal wants to download. (For example, the match ID associated with the profile to be downloaded. The match ID can be generated by the RSP server and linked to the profile, and thus managed by the RSP server).

[0478] The activation code sent from the RSP server to the source terminal can be referred to as the "received activation code".

[0479] Furthermore, when the RSP server determines that the appropriate profile needs to be reinstalled, it can perform a qualification check on whether the previously prepared "profile for device change" can be installed on the source terminal 1010. This process can be performed by receiving eUICC information (euiccinfo2) and information such as LPA and modem (deviceinfo) from the source terminal 1010. If the "profile for device change" is not suitable for the source terminal 1010, the RSP server can prepare a profile suitable for the source terminal 1010 for reinstallation.

[0480] Steps S1015 and S1020, in whole or in part, can be performed as part of step S1010 described above. That is, the RSP server and the source terminal can exchange messages to perform mutual authentication in step S1010, and the exchanged messages may include all or part of the messages required for steps S1015 and S1020, and can be sent. Furthermore, in order to perform mutual authentication in step S1010, the RSP server and the source terminal perform operations required for mutual authentication, such as processing received messages and generating messages to be sent, and as part of this operation, all or part of the operations required for steps S1015 and S1020 can be performed.

[0481] Reference Figure 10 In step S1025, the source terminal can download and install the file from the RSP server using the "received activation code". This process is the same as step S1005 above, except that if the "stored activation code" is used in step S1005, the "received activation code" is used in step S1025.

[0482] [Scenario 3]

[0483] This can be performed when the profile is bound to a target terminal. That is, when the RSP server specifies a particular terminal (e.g., the target terminal) instead of the source terminal as the terminal capable of receiving the profile prepared for device changes. However, this can also be performed when the profile is not bound to a target terminal.

[0484] Here, the following procedure can be performed.

[0485] Reference Figure 10 In step S1030, mutual authentication can be performed between the source terminal 1010 and the RSP server 1090. The mutual authentication process may include one or more of the following example processes.

[0486] In one example, the mutual authentication process may include a certificate negotiation process required for communication between the source terminal 1010 and the RSP server 1090. For example, the source terminal 1010 may send multiple certificate information that can be used to verify the RSP server 1090 and / or multiple certificate information that the RSP server 1090 can use to verify the source terminal 1010. Upon receiving this information, the RSP server 1090 may select the multiple certificate information that the source terminal 1010 uses to verify the RSP server 1090 and / or multiple certificate information that the RSP server 1090 can use to verify the source terminal 1010. Here, the multiple certificate information selected by the RSP server 1090 may be sent to the source terminal 1010. Through this process, the source terminal 1010 and the RSP server 1090 can obtain certificate information for mutual authentication. Here, the certificate information may be a certificate, information included in the certificate, and / or a series of information that may involve the certificate.

[0487] In another example, source terminal 1010 can send a pre-defined random number (eUICC challenge) value generated by itself to RSP server 1090. RSP server 1090 can digitally sign the received random number and then send the signed value to source terminal 1010. Source terminal 1010 can verify the received signature value to authenticate RSP server 1090.

[0488] In another example, RSP server 1090 can send a pre-generated random number (server challenge) value to source terminal 1010. Source terminal 1010 can digitally sign the received random number and then send the signed value to RSP server 1090. RSP server 1090 can verify the received signature value to authenticate source terminal 1010.

[0489] In yet another example, during communication between RSP server 1090 and source terminal 1010, IDs (transaction IDs) used for managing the session can be exchanged. For example, RSP server 1090 can generate a transaction ID and send the transaction ID value to source terminal 1010. Here, a digital signature value from RSP server 1090 can be added to verify the reliability and integrity of the transaction ID.

[0490] In yet another example, RSP server 1090 and source terminal 1010 can exchange their own IDs. For instance, RSP server 1090 can provide its own object identifier (OID) to source terminal 1010. As another example, source terminal 1010 can provide its own eUICC identifier to RSP server 1090.

[0491] refer to Figure 10 In step S1035, the following process can be performed.

[0492] Source terminal 1010 may send a request to RSP server 1090 for a reinstallation profile. Here, source terminal 1010 may send the profile delimiter of the requested reinstallation profile to RSP server 1090. Furthermore, the conditions under which the source terminal may request reinstallation may follow the [Step 1. Request] conditions as described above.

[0493] RSP server 1090 can determine whether to perform a reinstallation based on the received request message. Here, the conditions for the RSP server to determine whether to accept the reinstallation can follow the [Step 2. Accept] condition.

[0494] As a result, if the RSP server determines to reinstall the profile, then step S1040 can be executed.

[0495] Furthermore, when the RSP server determines that the appropriate profile needs to be reinstalled, it can perform a qualification check on whether the pre-prepared "profile for device change" can be installed on the source terminal 1010. This process can be performed by receiving eUICC information (euiccinfo2) and information such as LPA and modem (deviceinfo) from the source terminal 1010. If the "profile for device change" is not suitable for the source terminal 1010, the RSP server can prepare a profile suitable for the source terminal 1010 for reinstallation.

[0496] Step S1035, in whole or in part, can be performed as part of step S1030 described above. That is, in order to perform mutual authentication in step S1030, messages are exchanged between the RSP server and the source terminal, and all or part of the messages required for step S1035 can be included in the messages exchanged between them and sent. Furthermore, in order to perform mutual authentication in step S1030, the RSP server and the source terminal perform operations required for mutual authentication, such as processing received messages and generating messages to be sent, and as part of these operations, all or part of the operations required for step S1035 can be performed.

[0497] Reference Figure 10 In step S1040, a profile download and installation process can be performed between the source terminal 1010 and the RSP server 1090. The RSP server 1090 can send the prepared profile to the source terminal 1010. The profile can be the one prepared in step S1035, or a profile prepared in that step in response to a request from the source terminal. The source terminal 1010 can install the received profile.

[0498] Figure 11 Another example of a process for performing device changes according to embodiments of the present disclosure is shown.

[0499] Specifically, when the "Information related to processing the profile installed in the source terminal 1110" in the "Device Change Method" is configured to indicate that there is no special operation on the profile, it can be executed. Figure 11 The process. That is, the process can be executed when the corresponding file is deleted or configured not to be in a paused state.

[0500] Figure 11 The source terminal 1110 and target terminal 1150 shown may each include at least one LPA and at least one eSIM. (Refer to...) Figure 2 Description of RSP server 1190.

[0501] Reference Figure 11 In step S1105, the source terminal 1110 can send an activation code to the target terminal 1150.

[0502] Various methods can be used to prepare the activation code to be sent to the target terminal 1150. For example, two possible methods are as follows:

[0503] - Source terminal 1110 can extract the activation code included in the "Device Change Method" and prepare to send the activation code to target terminal 1150; and

[0504] - The source terminal 1110 can generate its own activation code and prepare to send the activation code to the target terminal 1150.

[0505] The activation code to be sent to the target terminal may include one or more of the following information:

[0506] -Information indicating the format of the activation code;

[0507] -Target terminal 1150 can access information about the RSP server (e.g., address and / or OID) to download the profile; and / or

[0508] - Indicates the file information that the target terminal 1150 wants to download. For example, the information might be as follows:

[0509] --The profile delimiter for the profile to be downloaded; and / or

[0510] --The matching ID associated with the profile to be downloaded. This matching ID can be generated by the RSP server and linked to the corresponding profile, thus being managed by the RSP server.

[0511] The activation code above can be transmitted using one of the methods provided below.

[0512] In one example, source terminal 1110 can provide the user with information to be sent to target terminal 1150 through its UI. The user can then input the received information using the UI of target terminal 1150.

[0513] In another example, source terminal 1110 generates information to be sent to target terminal 1150 in the form of an image (e.g., a QR code), and the generated image is displayed on the screen of the source terminal. The user scans the image displayed on the screen of source terminal 1110 using target terminal 1150 to send the information to target terminal 1150.

[0514] In another example, a connection can be established between source terminal 1110 and target terminal 1150, and the established connection can be used to send information. Here, the connection established between source terminal 1110 and target terminal 1150 can be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi Direct, LTE device-to-device (D2D), a wireless connection such as 5G D2D, or a wired connection such as a cable connection), or it can be a remote connection with a remote server (e.g., a relay server) located between source terminal 1110 and target terminal 1150.

[0515] Reference Figure 11 In step S1120, the target terminal 1150 can download and install the file from the RSP server 1190. The above process may include the following steps.

[0516] The target terminal 1150 can establish a connection with the RSP server 1190 and request a file from the RSP server 1190 using information included in the activation code (e.g., information indicating the file the target terminal 1150 wants to download). The RSP server 1190 can prepare a file to be sent to the target terminal 1150 based on the received information. In the above process, at least one of the following processes may be further included:

[0517] - Mutual authentication between target terminal 1150 and RSP server 1190;

[0518] - An eligibility check performed by RSP server 1190 is used to determine whether the profile to be sent can be installed and operated normally in target terminal 1150; or

[0519] - The user agrees to install the corresponding file on the target terminal 1150.

[0520] RSP server 1190 can send a prepared profile to target terminal 1150. Target terminal 1150 can install the profile received from RSP server 1190 in target terminal 1150 (e.g., the target terminal's eUICC).

[0521] refer to Figure 11 In step S1115, the following process can be performed.

[0522] If the profile installation fails, the target terminal 1150 can send a profile installation result indicating the failure to the RSP server 1190. Steps S1120 to S1135 can be omitted here. Furthermore, the source terminal 1110 can continue using the installed profile.

[0523] If the profile is installed successfully, the installed profile may be configured to be in an "unavailable" state. The "unavailable" state may indicate that the profile was installed normally in the terminal, but cannot be used without the approval process of the RSP server (e.g., steps S1120 to S1135 described later) (e.g., it cannot be changed to an "enabled" or "disabled" state). Here, the target terminal 1150 may send a profile installation result indicating successful installation to the RSP server 1190. The profile installation result may also include information indicating that the profile was installed successfully but is currently configured to be disabled.

[0524] Reference Figure 11 In step S1120, the RSP server 1190 can send a request to the source terminal 1110 to change the status of the profile. The specific process is as follows.

[0525] Various methods can be used to establish a connection between the RSP server 1190 and the source terminal 1110 for communication. Some possible examples are as follows:

[0526] In one example, when the source terminal and the RSP server are Figure 4 When communication is performed in step S410, in step S1120, the established connection is maintained and not released, and can be used for communication. Some possible examples are as follows:

[0527] --After completing step S740, the source terminal can wait while maintaining the connection. Thereafter, the RSP server can execute step S1120 to request a profile state change (e.g., the RSP server can use a push method); and / or

[0528] --Although not shown in the figure, after step S740 is completed, the source terminal can send a message to identify whether there is a profile status change message to be sent by the RSP server. If there is a profile status change message to be sent by the RSP server, step S1120 can be executed. If the RSP server determines that it does not need to send a profile status change message, the processing after step S1120 can be omitted. If the RSP server has not yet determined whether to send a profile status change message at the time of receiving the acknowledgment request message from the source terminal, the RSP server can wait until it determines whether to send a profile status change message, and then can execute step S1120. Alternatively, if the RSP server has not yet determined whether to send a profile status change message at the time of receiving the acknowledgment request message from the source terminal, the RSP server can send a message to the source terminal indicating to wait for a slightly longer period of time, and the source terminal can send an acknowledgment message to the RSP server again to identify the existence of a profile status change message. (That is, various types of polling schemes can be used.)

[0529] In another example, if not executed Figure 4 If step S410 is performed, or if the connection between the source terminal and the RSP server is still released even after step S410 is performed, a new connection can be established between the source terminal and the RSP server. Some possible examples are as follows:

[0530] --The source terminal first attempts to connect to the RSP server automatically or upon user request, and then can execute step S1120 through the established connection.

[0531] --The RSP server can perform step S1120 using methods such as pushing to the source terminal; and / or

[0532] --RSP server 1190 registers an indication in another RSP server (e.g., a discovery (DS) server) that a request for a profile status change exists, and the source terminal can identify from the other RSP server that it needs to perform an access to RSP server 1190, and can then access RSP server 1190 to perform step S1120.

[0533] The profile status change request message sent by RSP server 1190 to source terminal 1110 may include one or more of the following:

[0534] - The profile delimiter for the profile requesting a state change;

[0535] - Information about the RSP server (e.g., the OID indicating the RSP server);

[0536] - The eUICC identifier of the source terminal;

[0537] - The desired method of change;

[0538] - Delete the file;

[0539] - Change the profile to a paused state; and / or

[0540] The digital signature value used by the RSP server 1190 is used to sign part and / or all of a message.

[0541] refer to Figure 11 In step S1125, the following process can be performed.

[0542] The source endpoint can change the profile's status based on the RSP server's status change request. For example, one of the following two procedures can be executed.

[0543] Delete the profile; or

[0544] Configure the profile to be paused.

[0545] The source terminal can send the result of a state change performed by itself to the RSP server. Here, the state change result message sent by the source terminal to the RSP server may include one or more of the following:

[0546] - The profile delimiter for profiles whose state has already been changed;

[0547] - Information about the RSP server (e.g., the OID indicating the RSP server);

[0548] - The eUICC identifier of the source terminal;

[0549] -Results of the already executed state changes:

[0550] --Delete profile; and / or

[0551] --Change the profile to a paused state; and / or

[0552] - A digital signature value used by the source terminal to sign some and / or all of the messages.

[0553] Various methods can be used to send state change result messages from the source terminal to the RSP server. Some possible examples are as follows:

[0554] -Sent as a response message to step S1120; and / or

[0555] - Sent via a separate notification process.

[0556] Reference Figure 11 In step S1130, the RSP server 1190 can send a request to the target terminal 1110 to change the status of the profile. The specific process is as follows.

[0557] Various methods can be used to provide a process for establishing a connection between the RSP server 1190 and the target terminal 1150 for communication. Some possible examples are as follows.

[0558] In one example, if the connection established between the target terminal and the RSP server is not released even after step S1115, the connection can be reused. Some possible examples are as follows:

[0559] --After completing step S1115, the target terminal can wait while maintaining the connection. Afterward, the RSP server can execute step S1130 to request a status change for the profile.

[0560] In one example, although not shown in the figure, after step S1115, the RSP server can send a message requesting to wait to the target terminal. Thereafter, step S1130 can be executed at the point when the RSP server needs to request a change in the profile status.

[0561] In another example, although not shown in the figure, after step S1115, the RSP server can send a message requesting to wait to the target terminal. The target terminal can then send a message to identify whether a profile status change message exists to be sent by the RSP server. If a profile status change message exists to be sent by the RSP server, step S1130 can be executed. If the RSP server determines that a profile status change message does not need to be sent, the process after step S1130 can be omitted. If the RSP server has not yet determined whether to send a profile status change message at the time of receiving the acknowledgment request message from the source terminal, the RSP server can wait until it determines whether to send the profile status change message, and then execute step S1130. Alternatively, if the RSP server has not yet determined whether to send a profile status change message at the time of receiving the acknowledgment request message from the target terminal, the RSP server can send a message to the target terminal indicating to wait a slightly longer time, and the target terminal can send an acknowledgment message to the RSP server again to identify the existence of a profile status change message (i.e., various types of polling schemes can be used).

[0562] In one example, if the connection between the target terminal and the RSP server is released after step S1115, a new connection can be established between the target terminal and the RSP server. Some possible examples are as follows:

[0563] --The target terminal first attempts to connect to the RSP server automatically or upon user request, and then can execute step S1130 through the established connection.

[0564] --The RSP server can perform step S1130 using methods such as pushing to the target terminal; and / or

[0565] --RSP server 1190 registers an indication in another RSP server (e.g., a discovery (DS) server) that a request for a profile status change exists, and the target terminal can identify from the other RSP server that it needs to perform an access to RSP server 1190, and can then access RSP server 1190 to perform step S1130.

[0566] The profile status change request message sent by RSP server 1190 to target terminal 1150 may include one or more of the following:

[0567] - The profile delimiter for the profile requesting a state change;

[0568] - Information about the RSP server (e.g., the OID indicating the RSP server);

[0569] - The eUICC identifier of the target terminal;

[0570] - Desired change method:

[0571] --Make the profile available. For example, the following two state changes are possible:

[0572] ---Change the profile to be enabled; and / or

[0573] ---Change the profile to a disabled state; and / or

[0574] The digital signature value used by the RSP server 1190 is used to sign part and / or all of a message.

[0575] refer to Figure 11 The following process can be performed in step S1135.

[0576] The target endpoint can change the profile's status based on the RSP server's status change request. In other words, the source endpoint can configure the profile to be enabled based on the RSP server's status change request. For example, one of the following two procedures can be executed:

[0577] - Configure the profile to be enabled; or

[0578] - Configure the profile to be disabled.

[0579] The target terminal can send the result of a state change performed by the target terminal itself to the RSP server. Here, the state change result message sent by the target terminal to the RSP server may include one or more of the following: and / or

[0580] - The profile delimiter for profiles whose state has already been changed;

[0581] - Information about the RSP server (e.g., the OID indicating the RSP server);

[0582] - The eUICC identifier of the target terminal;

[0583] -Results of the already executed state changes:

[0584] --Configure the profile to be available (for example, the following two results may occur):

[0585] --- Configure profiles to be enabled; and / or

[0586] ---Configure the profile to be paused; and / or

[0587] - A digital signature value used by the target terminal to sign some and / or all of the messages.

[0588] Various methods can be used to send state change result messages from the target terminal to the RSP server. Some possible examples are as follows:

[0589] -Sent as a response message to step S1130; and / or

[0590] - Sent via a separate notification process.

[0591] Figure 12 The configuration of a terminal equipped with eUICC according to an embodiment of the present disclosure is shown.

[0592] Reference Figure 12 The terminal may include a transceiver 1210, a processor 1220, and an eUICC 1230. Some of the terminals described above in this disclosure may correspond to... Figure 12 The terminal described herein. However, the terminal configuration is not limited to... Figure 12 And can include more than Figure 12 The components shown may include more or fewer components. According to one embodiment, the transceiver 1210, processor 1220, and eUICC 1230 may be implemented as a single chip. Furthermore, the terminal may also include memory, and the processor 1220 may be configured as at least one processor.

[0593] According to various embodiments, transceiver 1210 can transmit signals, information, data, etc. to or receive signals, information, data, etc. from the transceiver of another terminal or external server. According to various embodiments of this disclosure, transceiver 1210 may include an RF transmitter for up-converting and amplifying the frequency of the transmitted signal, and an RF receiver for low-noise amplification of the received signal and down-converting its frequency. 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 and output the signals to processor 1220, and transmit signals output from processor 1220 via a wireless channel.

[0594] Meanwhile, the processor 1220 is a component for the overall control of the terminal. According to the various embodiments of this disclosure as described above, the processor 1220 can control the overall operation of the terminal.

[0595] The terminal may further include a memory (not shown), in which data such as basic programs, application programs, and configuration information for terminal operation can be stored. Furthermore, the memory may include at least one storage medium selected from flash memory, hard disk memory, multimedia card micro-memory, 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), and electrically erasable programmable read-only memory (EEPROM). Additionally, the processor 1220 can use various programs, content, data, etc., stored in the memory to perform various operations.

[0596] Figure 13 The configuration of an RSP server according to an embodiment of this disclosure is shown.

[0597] refer to Figure 13 The server may include a transceiver 1310 and a processor 1320. Some of the servers described above in this disclosure may correspond to... Figure 13 The server described herein. However, the server configuration is not limited to... Figure 13 And can include more than Figure 13 The components shown may include more or fewer components. According to one embodiment, the transceiver 1310 and processor 1320 may be implemented as a single chip. Furthermore, the server may further include memory, and the processor 1320 may be configured as at least one processor.

[0598] According to one embodiment, and various embodiments of this disclosure, transceiver 1310 can transmit signals, information, and data to or receive signals, information, and data from a terminal. Transceiver 1310 may include an RF transmitter for up-converting and amplifying the frequency of the transmitted signal, and an RF receiver for low-noise amplification of the received signal and down-converting its frequency. However, this is merely one embodiment of transceiver 1310, and the components of transceiver 1310 are not limited to RF transmitters and RF receivers. Furthermore, transceiver 1310 can receive signals via a wireless channel and output those signals to processor 1320, and can also transmit signals output from processor 1320 via a wireless channel.

[0599] Simultaneously, at least one processor 1320 is an element for the overall control of the server. According to various embodiments of the present disclosure as described above, the processor 1320 can control the overall operation of the server. This at least one processor 1320 may be referred to as a controller.

[0600] Additionally, the server may further include a memory (not shown) that can store data such as basic programs, applications, and configuration information for server operation. Furthermore, the memory may include at least one storage medium selected from flash memory, hard disk memory, multimedia card micro-memory, 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), and electrically erasable programmable read-only memory (EEPROM). Moreover, the processor 1320 can use various programs, contents, data, etc., stored in the memory to perform various operations.

[0601] In the detailed embodiments described above, elements included in this disclosure are represented in a singular or plural form according to the presented embodiments. However, for the sake of convenience, singular or plural forms have been suitably chosen as presented, and this disclosure is not limited to elements expressed in a singular or plural form. Thus, an element represented in a plural form may also include a single element, or an element represented in a singular form may include multiple elements.

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

[0603] It should be understood that the various embodiments of this disclosure and the terminology used therein are not intended to limit the technical features set forth herein to the particular embodiments, but rather to include various variations, equivalents, and / or substitutions of the corresponding embodiments. Regarding the description of the drawings, similar reference numerals may be used to denote similar or related elements. It should be understood that the singular form of a noun corresponding to an item may include one or more things unless the relevant context clearly indicates otherwise. As used herein, each of phrases such as “A or B,” “at least one of A and B,” “at least one of A or B,” “at least one of A, B, or C,” “at least one of A, B, and C,” and “at least one of A, B, or C” may include all possible combinations of the items listed together in the corresponding phrase. As used herein, terms such as “a,” “b,” “first,” and “second” may be used simply to distinguish one element from another and do not limit these elements in other respects (e.g., importance or order). It should be understood that if an element (e.g., the first element) is referred to as “coupled to another element (e.g., the second element),” “coupled to another element (e.g., the second element),” “connected to another element (e.g., the second element),” or “connected to another element (e.g., the second element)”, regardless of whether the terms “operationally” or “communicatively” are used, it means that the element can be coupled to another element directly (e.g., wired), wirelessly, or via another element (e.g., the third element).

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

[0605] The various embodiments described herein can be implemented as software (e.g., a program) including one or more instructions stored in a machine-readable storage medium (e.g., internal or external memory). The machine is a device that can invoke instructions stored therein from the storage medium and operate according to the invoked instructions, and may include a terminal according to various embodiments. When the instructions are processed by a processor (e.g., Figure 13 When the processor (1320) is executed, the processor can perform functions corresponding to the instructions, with or without using other components under the processor's control. Instructions may include code generated by a compiler or code executable by an interpreter.

[0606] Machine-readable storage media may be provided in the form of non-transitory storage media. Here, the term "non-transitory" simply means that the storage medium is a tangible device and does not include signals (e.g., electromagnetic waves), but the term does not distinguish between where data is stored semi-permanently in the storage medium and where data is temporarily stored in the storage medium.

[0607] Methods according to various embodiments of this disclosure may be included in and provided therein in a computer program product. The computer program product may be used as a product in transactions between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., an optical disc read-only memory (CD-ROM)) or via an app store (e.g., the Play Store). TM Online distribution (e.g., download or upload) or direct distribution between two user devices (e.g., smartphones). If online distribution is used, at least a portion of the computer program product may be temporarily generated or at least temporarily stored in a machine-readable storage medium, such as the memory of a manufacturer's server, an app store server, or a relay server. According to various embodiments, each of the above elements (e.g., a module or program) may include a single entity or multiple entities. According to various embodiments, one or more of the above elements may be omitted, or one or more other elements may be added. Alternatively or additionally, multiple elements (e.g., modules or programs) may be integrated into a single element. In this case, according to various embodiments, the integrated element may still perform one or more functions of each of the multiple elements in the same or similar manner as performed by a corresponding element of the multiple elements prior to integration. According to various embodiments, the operations performed by a module, program, or other element may be performed sequentially, in parallel, repeatedly, or heuristically, or one or more operations may be performed in a different order or omitted, or one or more other operations may be added.

[0608] Although this disclosure has been described with reference to various embodiments, various changes and modifications will be apparent to those skilled in the art. 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, including a first profile, the method comprising: Send a device change request to the server to install the second profile corresponding to the first profile onto the second device; The server receives a device change response as a response to a device change request, which instructs the deletion of the first profile. The device change response includes an instruction to support profile restoration. The first profile in the embedded general-purpose integrated circuit card (eUICC) of the first device is deleted based on the device change response. Based on the instructions included in the device change response, the selection of the deleted first profile for profile recovery, and the address of the server already stored in the first device, a recovery request for the deleted first profile is sent to the server. as well as Receive the recovery response from the server in response to the recovery request.

2. The method according to claim 1, further comprising: Receive from the server the profile corresponding to the first deleted profile, based on the activation code used for profile recovery. The activation code used for profile recovery is included in the recovery response.

3. The method according to claim 1, in, The recovery response is based on verification of a permanent error in the profile installation on the second device. Errors other than temporary errors were identified as permanent errors. Temporary errors included insufficient memory for the second profile and interruptions during profile installation. The information in the deleted first profile includes the integrated circuit card identifier (ICCID) of the deleted first profile.

4. The method according to claim 1, further comprising: Perform the mutual authentication process with the server. Among them, a recovery request is sent after the mutual authentication process is performed, and The selection of the first deleted profile for profile recovery is performed based on the user interface of the first device.

5. A method performed by a server in a communication system, the method comprising: Receives a device change request from a first device that includes a first profile, requesting that a second profile corresponding to the first profile be installed on a second device; In response to a device change request, a device change response is sent to the first device instructing the deletion of the first profile. The device change response includes an instruction to support profile restoration. as well as The first device receives a request to restore a first profile deleted from the first device's embedded universal integrated circuit card (eUICC). The restoration request includes information about the deleted first profile, and Send a recovery response to the recovery request to the first device.

6. The method according to claim 5, further comprising: Receive information from the second device regarding the installation results of the second profile corresponding to the first profile; as well as A permanent error was detected in the installation profile on the second device. The recovery response is sent to the first device based on this identification result. Errors other than temporary errors were identified as permanent errors. Temporary errors included insufficient memory for the second profile and interruptions during profile installation. The information in the deleted first profile includes the integrated circuit card identifier (ICCID) of the deleted first profile.

7. The method according to claim 5, further comprising: Based on the activation code used for profile recovery, a profile corresponding to the deleted first profile is sent to the first device. The activation code used for profile recovery is included in the recovery response.

8. The method according to claim 5, further comprising: Perform a mutual authentication process with the first device. Among them, the recovery request is received after the mutual authentication process is performed, and The server is the subscription manager data preparation plus SM-DP+.

9. A first device in a communication system, the first device comprising: transceiver; Embedded Universal Integrated Circuit Card (eUICC); and The controller is configured as follows: The transceiver sends a device change request to the server to install the second profile corresponding to the first profile onto the second device. The transceiver receives a device change response from the server as a response to a device change request, instructing the deletion of the first profile. The device change response includes an indication that profile restoration is supported. The first profile in the embedded general-purpose integrated circuit card eUICC is deleted based on the device change response, and Based on the instructions included in the device change response, the selection of the deleted first profile for profile recovery, and the address of the server already stored in the first device, a recovery request for the deleted first profile is sent to the server via the transceiver. as well as Receive the recovery response from the server via the transceiver.

10. The first device according to claim 9, in, The controller is also configured to receive from the server via a transceiver a profile corresponding to the first deleted profile, based on an activation code used for profile recovery. The activation code used for profile recovery is included in the recovery response.

11. The first device according to claim 9, in, The recovery response is based on verification of a permanent error in the profile installation on the second device. Errors other than temporary errors were identified as permanent errors. Temporary errors included insufficient memory for the second profile and interruptions during profile installation. The information in the deleted first profile includes the integrated circuit card identifier (ICCID) of the deleted first profile.

12. The first device according to claim 9, in, The controller is also configured to perform a mutual authentication process with the server. Among them, a recovery request is sent after the mutual authentication process is performed, and The selection of the first deleted profile for profile recovery is performed based on the user interface of the first device.

13. A server in a communication system, the server comprising: transceiver; and The controller is configured as follows: The device receives a device change request via a transceiver from a first device including a first profile, requesting the installation of a second profile corresponding to the first profile onto a second device. In response to the device change request, a device change response instructing the deletion of the first profile is sent to the first device via a transceiver. This device change response includes an instruction supporting profile restoration. The transceiver receives a request from the first device to restore a first profile deleted from the first device's embedded universal integrated circuit card (eUICC). The restoration request includes information about the deleted first profile, and A recovery response to the recovery request is sent to the first device via the transceiver.

14. The server according to claim 13, in, The controller is also configured to receive information from the second device via a transceiver regarding the installation results of the second profile corresponding to the first profile, and to identify permanent errors in the profile installation on the second device. The recovery response is sent to the first device based on this identification result. Errors other than temporary errors were identified as permanent errors. Temporary errors included insufficient memory for the second profile and interruptions during profile installation. The information in the deleted first profile includes the integrated circuit card identifier (ICCID) of the deleted first profile.

15. The server according to claim 13, wherein, The controller is also configured to send a profile corresponding to the deleted first profile to the first device via a transceiver, based on an activation code used for profile recovery. The activation code used for profile recovery is included in the recovery response, and The server is the subscription manager data preparation plus SM-DP+.

Images