Method and apparatus for processing profile deletion and restoration during profile transmission between devices in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates. A method performed by a first terminal in a wireless communication system, according to various embodiments, comprises the steps of: transmitting, to a second terminal, a profile package generated on the basis of a profile of the first terminal; if the movement of the profile package to the second terminal is cancelled, receiving a message including information related to the deletion of the profile package; verifying the information related to the deletion of the profile package; and changing the state of a profile of the first terminal.

Description

Method and device for handling profile deletion and restoration when transmitting profiles between devices in a wireless communication system

[0001] The present disclosure relates to a wireless communication system or a mobile communication system. Specifically, the present disclosure relates to a method and device for transferring subscription information between devices, and to a method and device for restoring profile use on a terminal to be transferred when profile transfer between devices is interrupted, and for deleting a profile package created for transfer when installation is interrupted.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in the sub-6GHz frequency band such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (mmWave) such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G mobile communication technology, which is called the system after 5G communication (Beyond 5G), implementation in the terahertz (THz) band (for example, 3 THz band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low latency time that is reduced to one-tenth.

[0003] In the early stages of 5G mobile communication technology, the goal is to support services and satisfy performance requirements for enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC). These include beamforming and massive MIMO to mitigate path loss of radio waves in ultra-high frequency bands and increase the transmission distance of radio waves, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (Bidth Part), new channel coding methods such as LDPC (Low Density Parity Check) codes for large-capacity data transmission and Polar Code for reliable transmission of control information, and L2 pre-processing (L2). Standardization has been made for network slicing, which provides dedicated networks specialized for specific services, and pre-processing.

[0004] Currently, discussions are underway to improve and enhance the initial 5G mobile communication technology in consideration of the services that 5G mobile communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (Vehicle-to-Everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by vehicles, NR-U (New Radio Unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE Power Saving), Non-Terrestrial Network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and Positioning.

[0005] In addition, standardization of wireless interface architecture / protocols is in progress for technologies such as intelligent factories (Industrial Internet of Things, IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) that provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement technology including Conditional Handover and Dual Active Protocol Stack (DAPS) handover, and 2-step random access (2-step RACH for NR) that simplifies random access procedures. Standardization is also in progress for system architecture / services such as 5G baseline architecture (e.g., Service-based Architecture, Service-based Interface) for grafting Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) that provides services based on the location of the terminal.

[0006] Once these 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, necessitating enhanced functionality and performance of 5G mobile communication systems and integrated operation of these connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity, supporting AI services, supporting metaverse services, and drone communications by utilizing eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] In addition, the development of these 5G mobile communication systems includes new waveforms to ensure coverage in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), Array Antenna, and Large Scale Antenna, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM), Reconfigurable Intelligent Surface (RIS) technology, as well as full duplex technology to improve the frequency efficiency and system network of 6G mobile communication technology, satellite, AI (Artificial Intelligence) from the design stage and AI-based communication technology that realizes system optimization by internalizing end-to-end AI support functions, and ultra-high-performance communication and computing resources to provide services with complexity that exceeds the limits of terminal computing capabilities. It can serve as a basis for the development of next-generation distributed computing technologies that can be realized by utilizing them.

[0008] The present disclosure provides a method and device for allowing a user to reuse a profile previously used on a terminal when a connection between two security modules (or between electronic devices) is interrupted when transferring a profile between two electronic devices in a wireless communication system or mobile communication system. In addition, the present disclosure provides a method and device for processing profile deletion and providing the processing result to a profile server and / or a telecommunications company during the process of transferring subscriber information between devices.

[0009] According to one embodiment of the present disclosure, a method for recovering a state of a first profile in a first terminal in a wireless communication system may include: a step in which the first terminal determines to move to a second terminal for the first profile; a step in which the first terminal generates an EPP to be moved from the first profile; a step in which the first terminal determines whether to change the state of the first profile to a locked state (Unusable); a step in which the first terminal performs verification of an EPP deletion result through linkage with the first terminal or a profile server; and a step in which the state of the first profile is recovered based on the EPP deletion verification result.

[0010] The disclosed embodiment provides a device and method capable of effectively providing a service in a mobile communication system.

[0011] The effects that can be obtained from the present disclosure are not limited to the effects mentioned in the various embodiments, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the art to which the present disclosure belongs from the description below.

[0012] FIG. 1 is a diagram illustrating an example of how two terminals interact to transmit a profile between them according to an embodiment of the present disclosure.

[0013] FIG. 2 is a diagram illustrating an example of a state transition of a profile according to an embodiment of the present disclosure.

[0014] FIG. 3A is a diagram illustrating an example of a method for stopping a device change to a second terminal and restoring a profile of a first terminal according to one embodiment of the present disclosure.

[0015] FIG. 3b is a diagram illustrating an example of a method for stopping a device change to a second terminal and restoring a profile of a first terminal according to one embodiment of the present disclosure.

[0016] FIG. 4A is a diagram illustrating an example of a method for providing a processing result to a telecommunications service provider when a device change to a second terminal is stopped according to an embodiment of the present disclosure.

[0017] FIG. 4b is a diagram illustrating an example of a method for providing a processing result to a telecommunications service provider when a device change to a second terminal is stopped according to an embodiment of the present disclosure.

[0018] FIG. 5A is a diagram illustrating an example of a method for stopping a device change to a second terminal and restoring a profile of a first terminal according to one embodiment of the present disclosure.

[0019] FIG. 5b is a diagram illustrating an example of a method for stopping a device change to a second terminal and restoring a profile of a first terminal according to one embodiment of the present disclosure.

[0020] FIG. 6 is a diagram illustrating an example of a method for stopping a device change to a second terminal and restoring a profile of a first terminal according to one embodiment of the present disclosure.

[0021] FIG. 7 is a diagram illustrating the configuration of a “trusted CI list” according to some embodiments of the present disclosure.

[0022] FIG. 8 is a diagram illustrating a procedure for transmitting a profile from one terminal to another terminal according to an embodiment of the present disclosure.

[0023] FIG. 9 is a diagram illustrating a configuration of a terminal according to some embodiments of the present disclosure.

[0024] FIG. 10 is a diagram illustrating a configuration of a server according to some embodiments of the present disclosure.

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

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

[0027] For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically depicted. Furthermore, the dimensions of each component do not entirely reflect its actual size. Identical or corresponding components in each drawing are assigned the same reference numbers.

[0028] The advantages and features of the present disclosure, and methods for achieving them, will become clearer with reference to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below and may be implemented in various different forms. These embodiments are provided solely to ensure that the present disclosure is complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Like reference numerals designate like elements throughout the specification.

[0029] At this time, it will be understood that each block of the processing flowchart drawings and combinations of the flowchart drawings can be performed by computer program instructions. These computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flowchart block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can direct a computer or other programmable data processing equipment to implement the functions in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured item that includes an instruction means for performing the functions described in the flowchart block(s). Since the computer program instructions may be installed on a computer or other programmable data processing device, a series of operational steps may be performed on the computer or other programmable data processing device to create a computer-executable process, and the instructions that cause the computer or other programmable data processing device to perform the steps for performing the functions described in the flowchart block(s) may also provide steps for performing the functions described in the flowchart block(s).

[0030] Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a specific logical function(s). It should also be noted that in some alternative implementation examples, the functions described in the blocks may occur out of order. For example, two blocks depicted in succession may actually be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on their respective functions.

[0031] Here, the term '~ unit' used in the present embodiment means a software or hardware component such as an FPGA or ASIC, and the '~ unit' performs certain roles. However, the '~ unit' is not limited to software or hardware. The '~ unit' may be configured to be on an addressable storage medium and may be configured to play one or more processors. Accordingly, as an example, the '~ unit' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and '~ units' may be combined into a smaller number of components and '~ units' or further separated into additional components and '~ units'. Additionally, components and '~parts' may be implemented to regenerate one or more CPUs within a device or secure multimedia card.

[0032] In this disclosure, modifiers such as "first" and "second" that designate terms may be used to distinguish each term from another when describing embodiments. The terms modified by modifiers such as "first" and "second" may refer to different objects. However, the terms modified by modifiers such as "first" and "second" may also refer to the same object. That is, modifiers such as "first" and "second" may be used to refer to the same object from different perspectives. For example, modifiers such as "first" and "second" may be used to distinguish the same object from a functional or operational perspective. For example, "first user" and "second user" may refer to the same user.

[0033] Furthermore, while the present disclosure describes each embodiment using SSP as an example of a security medium, the scope of the present disclosure is not limited to SSP. For example, it will be apparent to those skilled in the art that the various embodiments described below can be applied substantially identically or similarly to other security mediums that perform functions substantially identical or similar to SSP.

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

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

[0036] Meanwhile, the Internet is evolving from a human-centric network where humans create and consume information to an Internet of Things (IoT) network where information is exchanged and processed between distributed components, such as objects. The Internet of Everything (IoE) is also emerging, combining IoT technologies with big data processing technologies, such as those connected to cloud servers. To implement the IoT, technological elements such as sensing technology, wireless and wired communication and network infrastructure, service interface technology, and security technology are required. Recently, research is being conducted on technologies such as sensor networks, Machine-to-Machine (M2M), and Machine-Type Communication (MTC) for connecting objects. In the IoT environment, intelligent IT (Internet Technology) services can be provided that collect and analyze data generated from connected objects to create new value for human life. IoT can be applied to areas such as smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart appliances, and advanced medical services through the convergence and integration of existing IT (information technology) technologies with various industries.

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

[0038] As described above, the advancement of mobile communication systems has enabled the provision of a variety of services, necessitating methods for effectively delivering these services. For example, when a bundle or profile (or profile package) is transferred between two devices, a method for mutual authentication between the two devices is required.

[0039] According to one embodiment of the present disclosure, a method for recovering a state of a first profile in a first terminal in a wireless communication system may include: a step of the first terminal determining a movement to a second terminal for the first profile; a step of the first terminal generating an EPP to be moved from the first profile; a step of the first terminal determining whether to change the state of the first profile to a locked state (Unusable); a step of the first terminal performing verification of an EPP deletion result through linkage with the first terminal or a profile server; and a step of recovering the state of the first profile based on the EPP deletion verification result.

[0040] A method according to one embodiment of the present disclosure may include a step of receiving a deletion message of a profile package (EPP) created for mobile installation from a first terminal or a second terminal, a step of determining whether the status of the first profile is recoverable, and a step of composing a message including the result and transmitting the message to the first terminal or the second terminal, as a method for determining whether a profile server in a wireless communication system is recoverable.

[0041] According to one embodiment of the present disclosure, a method for transmitting a deletion processing and processing result of an EPP to a profile server by a first terminal in a wireless communication system may include a step of the first terminal determining a movement to a second terminal for a first profile, a step of performing mutual authentication with the second terminal based on a communication connection with the second terminal or received eUICC information of the second terminal, a step of transmitting identification information of the first terminal to the second terminal, a step of generating a profile package (EPP) to be moved, and a step of transmitting the EPP to the second terminal.

[0042] According to one embodiment of the present disclosure, a method for a second terminal in a wireless communication system to transmit a deletion processing and processing result of an EPP to a profile server may further include the steps of receiving a profile package (EPP) from a first terminal based on mutual authentication with the first terminal, receiving identification information of the first terminal, processing EPP deletion and determining a target for generating and receiving the processing result, and configuring and transmitting a deletion notification message including further information of the first terminal.

[0043] A method according to one embodiment of the present disclosure is a method for a profile server in a wireless communication system to receive a deletion notification message, the method including the steps of receiving a deletion notification message from a first terminal or a second terminal, verifying the received message to determine whether a corresponding profile is installed abnormally, and transmitting the verification result to a telecommunications service provider so that the telecommunications service provider receiving the verification result performs an action according to whether a corresponding profile is installed abnormally.

[0044] According to various embodiments of the present disclosure, two devices can authenticate each other, and after authentication is complete, the two devices can provide the telecommunications carrier with information that determines whether a profile installed on one device has been safely and efficiently transferred and installed on the other device. Accordingly, according to various embodiments of the present disclosure, the telecommunications carrier can take appropriate action in the event of abnormal operation. Furthermore, user convenience can be enhanced by providing a method for restoring a previously installed profile before the profile is transferred and reinstalled on the other device.

[0045] "SE (Secure Element)" may refer to a security module consisting of a single chip that can store security information (e.g., mobile network access keys, user identification information such as ID cards / passports, credit card information, encryption keys, etc.) and operate a control module (e.g., network access control module such as USIM, encryption module, key generation module, etc.) that utilizes the stored security information. SE may be used in various electronic devices (e.g., smartphones, tablets, wearable devices, automobiles, IoT devices, etc.) and provide security services (e.g., mobile network access, payment, user authentication, etc.) through security information and control modules.

[0046] SE can be divided into UICC (Universal Integrated Circuit Card), eSE (Embedded Secure Element), SSP (Smart Secure Platform), which is an integrated form of UICC and eSE, and can be further subdivided into removable, fixed (Embedded), and integrated (Integrated) types that are integrated into specific components or SoC (system on chip) depending on the form in which they are connected or installed in electronic devices.

[0047] A "UICC (Universal Integrated Circuit Card)" is a smart card inserted into mobile terminals and used, also known as a UICC card. A UICC may include a connection control module for accessing a mobile carrier's network. Examples of connection control modules include a Universal Subscriber Identity Module (USIM), a Subscriber Identity Module (SIM), and an IP Multimedia Service Identity Module (ISIM). A UICC containing a USIM is commonly referred to as a USIM card. Similarly, a UICC containing a SIM module is commonly referred to as a SIM card. The SIM module may be built into the UICC during manufacturing, or the user may download the desired mobile service's SIM module onto the UICC card at any time. Furthermore, multiple SIM modules may be downloaded and installed on a UICC card, and at least one SIM module may be selected for use. These UICC cards may or may not be fixed to the terminal. A UICC fixed to the terminal is referred to as an eUICC (embedded UICC). In particular, a UICC embedded in a System-On-Chip (SoC) that includes a communication processor, an application processor, or a single processor structure that integrates the two processors of a terminal is also called an iUICC (Integrated UICC). Typically, eUICC and iUICC may refer to a UICC card that is fixedly used in a terminal and includes a function that allows at least one SIM module to be downloaded remotely to the UICC card and any one of the downloaded SIM modules to be selected.In the present disclosure, a UICC card that includes a function that allows at least one SIM module to be downloaded remotely and a SIM module to be selected is collectively referred to as an eUICC or iUICC. For example, among UICC cards that include a function that allows a SIM module to be downloaded remotely and a SIM module to be selected, a UICC card that is or is not fixed to a terminal is collectively referred to as an eUICC or iUICC. In the present disclosure, the term "UICC" may be used interchangeably with "SIM," and the term "eUICC" may be used interchangeably with "eSIM."

[0048] The "eUICC identifier (eUICC ID)" may be a unique identifier of the eUICC embedded in the terminal and may be referred to as EID. In addition, if a provisioning profile is pre-loaded in the eUICC, the eUICC identifier (eUICC ID) may be an identifier of the corresponding provisioning profile (Profile ID of the Provisioning Profile). In addition, in one embodiment of the present disclosure, if the terminal and the eUICC chip are not separated, the eUICC identifier (eUICC ID) may be a terminal ID. In addition, the eUICC identifier (eUICC ID) may refer to a specific secure domain (Secure Domain) of the eUICC chip. The eUICC identifier may also be provided as predetermined information included in an eUICC certificate. In the present disclosure, providing the EID may be a certificate including EID information or the EID information itself.

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

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

[0051] In the present disclosure, a "profile package" may mean that the contents of a "profile" are packaged in a software form that can be installed in a UICC. A "profile package" may be referred to as a Profile Package TLV. If the profile package is encrypted using encryption parameters, it may be referred to as a Protected Profile Package (PPP) or a Protected Profile Package TLV (PPP TLV). If the profile package is encrypted using encryption parameters that can only be decrypted by a specific eUICC, it may be referred to as a Bound Profile Package (BPP) or a Bound Profile Package TLV (BPP TLV). A Profile Package TLV may be a data set that expresses information that constitutes a profile in the TLV (Tag, Length, Value) format.

[0052] In the present disclosure, a 'profile image' may refer to binary data of a profile package installed in a UICC. The 'profile image' may be named Profile TLV or Profile Image TLV. If the profile image is encrypted using encryption parameters, it may be named PPI or Protected Profile Image TLV (PPI TLV). If the profile image is encrypted using encryption parameters that can only be decrypted by a specific eUICC, it may be named BPI or Bundled Profile Image TLV (BPI TLV). The profile image TLV may be a data set representing information that constitutes a profile in TLV format. It should be noted that in the present disclosure, if it is determined that no special distinction is necessary for the invention, the 'profile image' is collectively expressed as a profile package. Therefore, in the present disclosure, the 'EPP (Exported Profile Package)' may be a profile image generated from a first profile installed in a first terminal.

[0053] In the present disclosure, the EPP may also be a profile package generated from the first profile for device change, as described later in the drawings, and may be composed of the same or part of the data set as the first profile. For example, some of the data may be data when the profile 1 is initially installed on the first terminal. In this case, when the EPP is composed of part of the data of the first profile, an embodiment of the present disclosure may include a process in which the second terminal receives and / or combines additional information (e.g., profile 1 update information generated after the initial profile 1 installation) through the first terminal and / or the profile server to restore the properties of the first profile. In the present disclosure, in order not to obscure the logic of the invention, cases in which the EPP is composed of part or all of the data of profile 1 may be collectively expressed as EPP.

[0054] In this disclosure, the "state" of a profile may mean one of the states of the profile below defined in the SGP.22 standard defined by the GSMA. In the present disclosure, the "state" of the currently defined profile is additionally presented as an Unusable state, and a detailed description thereof will be provided later in FIG. 2.

[0055] [enable]

[0056] In the present disclosure, the action of a terminal activating a profile may refer to an action of changing the status of the profile to enabled, thereby enabling the terminal to receive communication services through a telecommunications service provider that provided the enabled profile. A profile in an enabled state may be expressed as an "enabled profile."

[0057] [disable]

[0058] In the present disclosure, the action of a terminal disabling a profile may refer to an action of changing the status of the profile to disabled, thereby preventing the terminal from receiving communication services through the telecommunications service provider that provided the disabled profile. A disabled profile may be expressed as a "disabled profile."

[0059] [delete]

[0060] In the present disclosure, the action of a terminal deleting a profile may mean an action of changing the status of the profile to a deleted status, thereby preventing the terminal from activating or deactivating the deleted profile. A profile in a deleted status may be expressed as a "deleted profile."

[0061] In the present disclosure, the operation of the terminal activating, disabling, or deleting a profile may mean an operation of not immediately changing the status of each profile to an enabled, disabled, or deleted state, but only marking each profile as to be enabled, disabled, or deleted, and then changing each profile to an enabled, disabled, or deleted state after the terminal or the UICC of the terminal performs a specific operation (e.g., performing a REFRESH or RESET command). The act of marking a particular profile as being in a scheduled state (e.g., to be enabled, to be disabled, or to be deleted) is not necessarily limited to marking a single scheduled state for a single profile, but may also mark one or more profiles as being in the same or different scheduled states, mark one profile as being in more than one scheduled state, or mark one or more profiles as being in more than one scheduled state, which may be the same or different.

[0062] Additionally, if a terminal indicates more than one scheduled status for a given profile, the two scheduled status indications may be combined into one. For example, if a given profile is marked as "to be disabled" and "to be deleted," the indicated profiles may be combined into "to be disabled and deleted."

[0063] Additionally, the terminal's actions of indicating a scheduled status for one or more profiles may be performed sequentially or simultaneously. Furthermore, the terminal's actions of indicating a scheduled status for one or more profiles and then changing the status of the actual profiles may be performed sequentially or simultaneously.

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

[0065] “RSP Server (Remote SIM Provisioning Server)” may be used as a name to refer to a profile (provisioning) server, a profile management server, and / or an activation brokerage server, which will be described later. The RSP server may be expressed as SM-XX (Subscription Manager XX).

[0066] In the present disclosure, a "profile server" may include a function for generating a profile, encrypting a generated profile, generating a profile remote management command, or encrypting a generated profile remote management command. For example, the profile server may be expressed as a Subscription Manager Data Preparation (SM-DP), a 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 (Profile Provisioner, PP), a profile provider, or a profile provisioning credentials holder (PPC holder).

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

[0068] In this disclosure, the profile server may also mean a combination of the functions of a profile management server. Accordingly, in various embodiments of the present disclosure, the operations of the profile server may be performed by the profile management server. Similarly, the operations of the profile management server or SM-SR may be performed by the profile provision server.

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

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

[0071] The term "Subscriber" can refer to either the Service Provider who owns the terminal, or the End User who owns the terminal. Typically, a terminal owned by a Service Provider is referred to as an M2M Device, while a terminal owned by a User is referred to as a Consumer Device. In the case of M2M terminals, there may be an End User who does not own the terminal but transfers or leases the terminal from the Service Provider. In this case, the Subscriber and the Service Provider may be different or the same.

[0072] "Subscriber intent" can be used as a general term to refer to a subscriber's intent to manage their profile locally or remotely. Furthermore, for local management, subscriber intent can refer to end-user intent, and for remote management, subscriber intent can refer to service provider intent.

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

[0074] A 'terminal' may be referred to as a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, subscriber unit (SU), subscriber station (SS), wireless device, wireless communication device, wireless transmit / receive unit (WTRU), mobile node, mobile, or other terms. Various embodiments of the terminal may include a cellular telephone, a smart phone having a wireless communication function, a personal digital assistant (PDA) having a wireless communication function, a wireless modem, a portable computer having a wireless communication function, a photographing device such as a digital camera having a wireless communication function, a gaming device having a wireless communication function, a music storage and playback home appliance having a wireless communication function, an internet home appliance capable of wireless internet access and browsing, as well as portable units or terminals that integrate combinations of such functions. In addition, the terminal may include, but is not limited to, an M2M (Machine to Machine) terminal, an MTC (Machine Type Communication) terminal / device. In the present disclosure, a terminal may also be referred to as an electronic device.

[0075] In the present disclosure, an electronic device may be equipped with a UICC capable of downloading and installing a profile. If the UICC is not embedded in the electronic device, a UICC physically separated from the electronic device may be inserted into and connected to the electronic device. For example, the UICC may be inserted into the electronic device in the form of a card. The electronic device may include a terminal, and in this case, the terminal may be a terminal including a UICC capable of downloading and installing a profile. The UICC may be embedded in the terminal, or, if the terminal and the UICC are separated, the UICC may be inserted into the terminal and connected to the terminal. A UICC capable of downloading and installing a profile may be referred to, for example, as an eUICC.

[0076] "LPA (Local Profile Assistant)" may refer to software or an application installed in a terminal or electronic device to control a UICC or eUICC in the terminal or electronic device. In the present disclosure, when it is expressed that a terminal transmits a command to an eUICC or that a terminal receives a command from an eUICC, the terminal's end point may be interpreted as an LPA.

[0077] "Event" may be used in the present disclosure for the following purposes, including, but not limited to, the following examples.

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

[0079] Data corresponding to an event may be referred to as a "command code." Part or all of the procedure utilizing the command code may be referred to as a "command code processing procedure," a "command code procedure," or an "LPA API (Local Profile Assistant Application Programming Interface)." Profile download may be used interchangeably with profile installation.

[0080] Additionally, "Event Type" may be used as a term to indicate whether a particular event is a profile download, remote profile management (e.g., delete, activate, deactivate, replace, update, etc.), or other profile or eUICC management / processing command, and may be named as Operation Type (or OperationType), Operation Class (or OperationClass), Event Request Type, Event Class, Event Request Class, etc. Any event identifier (EventID or MatchingID) may be specified with the path through which the terminal acquired the event identifier (EventID or MatchingID) or its usage purpose (EventID Source or MatchingID Source).

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

[0082] "Remote Profile Management (RPM)" can be named as Profile Remote Management, Remote Management, Remote Management Command, Remote Command, Remote Profile Management Package (RPM Package), Profile Remote Management Package, Remote Management Package, Remote Management Command Package, Remote Command Package. RPM can be used to change the state of a specific profile (Enabled, Disabled, Deleted), or to update the contents of a specific profile (e.g., Profile Nickname, Profile Metadata, etc.). RPM can contain one or more remote management commands, in which case the target profile of each remote management command can be the same or different for each remote management command.

[0083] A "certificate" or digital certificate can refer to a digital certificate used for mutual authentication based on an asymmetric key, which consists of a pair of public keys (PK) and secret keys (SK). Each certificate can include one or more public keys (PK), a public key identifier (PKID) corresponding to each public key, an identifier (Certificate Issuer ID) of the certificate issuer (CI) that issued the certificate, and a digital signature. For example, the certificate issuer can be named a certification issuer, a certificate authority (CA), or a certification authority. For example, in the present disclosure, a public key (PK) and a public key identifier (PKID) may be used to refer to a specific public key or a certificate including the public key, or a portion of the specific public key or a portion of the certificate including the public key, or a computational result (e.g., hash) value of the specific public key or a computational result (e.g., hash) value of the certificate including the public key, or a computational result (e.g., hash) value of a portion of the specific public key or a computational result (e.g., hash) value of a portion of the certificate including the public key, or a storage space where data is stored.

[0084] A "Certificate Chain" or Certificate Hierarchy can indicate the relationship between certificates issued by a "Certificate Issuer" (primary certificate) when those certificates are used to issue other certificates (secondary certificates), or when secondary certificates are used to issue three or more certificates in a chain. For example, the CI certificate used to issue the initial certificate may be named the Root of Certificate, the top-level certificate, the Root CI, the Root CI Certificate, the Root CA, or the Root CA Certificate.

[0085] In the embodiments of the present disclosure below, when it is expressed as “signing and transmitting data” or “transmitting signed data,” it may mean that the transmitting entity digitally signs the data to be transmitted with its own private key to ensure the integrity of the data to be transmitted, that is, the transmitting entity constructs and transmits a message including a signature. For example, the expression that the eUICC transmits a deletion result signed by the eUICC or that the eUICC signs and transmits the deletion result may be interpreted to mean that the eUICC transmits a message including the deletion result data and a signature signed by its own private key. The receiving side can verify the signature included in the message with the corresponding public key (e.g., the public key of the eUICC) to determine whether the data has been tampered with and determine its integrity.

[0086] In addition, when explaining the present disclosure, if it is determined that a specific description of a related public notice function or configuration may unnecessarily obscure the gist of the present disclosure, the detailed description is omitted.

[0087] Below, various embodiments of methods and devices for moving and installing profiles between terminals are described.

[0088] FIG. 1 is a diagram illustrating an example of how two terminals interact to transmit a profile between them according to an embodiment of the present disclosure.

[0089] As illustrated in FIG. 1, the first terminal (110) and the second terminal (120) are equipped with a first eUICC (170) and a second eUICC (190), respectively, and the first eUICC (170) and the second eUICC (190) may each have a profile (not shown) installed. In addition, the first terminal (100) and the second terminal (120) may each have a first LPA (160) and a second LPA (180) installed. The first eUICC (170) and the second eUICC (190) may be controlled by the first LPA (160) and the second LPA (180), respectively. The user (100) can control the profiles installed in the eUICCs of each terminal (e.g., the first eUICC (103) and the second eUICC (123)) through the first LPA (101) and the second LPA (121), respectively. When performing a device change, it can be assumed that the user is the same user.

[0090] The first LPA (160) and the second LPA (190) can be connected to each other and communicate. At this time, a connection can be established (or set up) between the LPAs. The first LPA (160) and the second LPA (190) can also establish a connection using information transmitted to the second LPA (190). The connection between the first LPA (160) and the second LPA (190) may be a direct device-to-device connection (e.g., a wireless connection such as NFC, Bluetooth, UWB, WiFi-Direct, LTE D2D (device-to-device), 5G D2D, or a wired connection via a cable) or may be a long-distance connection in which a remote server (e.g., a relay server) is located between the first LPA (160) and the second LPA (190).

[0091] The telecommunications service provider (150) may be connected to a first RSP server (130) and a second RSP server (140), the first LPA (160) of the first terminal (110) may be connected to the first RSP server (130), and the second LPA (180) of the second terminal (120) may be connected to the second RSP server (140). At this time, the first RSP server (130) and the second RSP server (140) may be the same or different. In addition, when more than one service provider server is included in the configuration, each service provider server may be connected to a separate RSP server, or at least one service provider server may be connected to the same RSP server. In addition, for convenience, FIG. 1 illustrates a case where each of the first RSP server (130) and the second RSP server (140) is configured as a single server. However, depending on the implementation and embodiment, one or more profile servers (SM-DP+) may be included in the server configuration, and one or more opening brokerage servers (SM-DS) that assist in establishing a connection between a specific profile server and a terminal may also be included in the server configuration. In this way, the configuration of various servers may be simply referred to as a single profile server or SM-DP+ in the drawings below.

[0092] Before performing a device change to a second terminal (120), the user (100) may subscribe to a communication service of a telecommunications service provider (150) and install a first profile to be moved to the second terminal (120) in the eUICC (100) of the first terminal (110).

[0093] Meanwhile, in the drawings and descriptions to be described later, _S and _T may be added to indicate eUICCs belonging to the first terminal (110), the second terminal (120), a certificate of the eUICC belonging to the second terminal (120), or a random value generated by the terminal or the eUICC. For example, if it is necessary to distinguish between the eUICC (170) of the first terminal (110) and the eUICC (190) that will receive the profile to be moved, they may be distinguished and indicated as eUICC_S (e.g., eUICC in the Source terminal) and eUICC_T (e.g., eUICC in the Target terminal) in the drawings and descriptions to be described below.

[0094] FIG. 2 is a diagram illustrating a state transition of a profile according to an embodiment of the present disclosure.

[0095] Referring to FIG. 2, the "state" of a profile may have one of the states of activation, deactivation, and deletion described in the background of the invention above, and may further include the state of an additional profile for changing a device. The eUICC of the terminal may receive and process a profile management message received from the LPA of the terminal in order to change the state of the stored profile. For example, an ES10x function indicating a specific profile management may be transmitted to the eUICC, and the transmitted message may include one or more pieces of information including a profile identifier such as an ICCID or Application ID, a flag indicating whether to transmit a reset message from the eUICC to the modem, and an EPP delimiter. Then, the ISD-R of the eUICC that received the message may confirm the command received from the LPA, perform a command for the required profile state transition, and reply the processing result to the LPA.

[0096] For example, a transition to the Enabled (210) state may mean an operation in which the eUICC receives a profile activation command from the LPA while the profile is in the Disabled (220) state and processes a change. A transition to the Disabled (220) state may mean an operation in which the eUICC receives a profile deactivation command from the LPA while the profile is in the Enabled (210) state and processes a change.

[0097] Transitioning to the Delete (230) state may mean an action in which the eUICC receives a profile deletion command from the LPA while the profile is in the Disabled (220) state and processes the deletion of the profile.

[0098] The actions for the above-described profile state transition can be interpreted with reference to the actions for profile state change defined in GSMA's SGP.22 or the description described in the background of the invention above.

[0099] Meanwhile, additional profile "states" not currently defined in SGP.22 for device changes may be introduced. Furthermore, it may be possible for the eUICC to perform state transitions as a result of other actions processed through LPA commands. For example, a state transition performed by the eUICC could be a transition to the Unusable state.

[0100] [Unusable (200)]

[0101] The Unusable state may indicate a profile state in which a transition to an enabled state (via a disabled state) is not possible before a certain condition is satisfied. For example, an eUICC that receives a command for an EPP creation request from an LPA may create an EPP from the first profile, change the state of the first profile to Unusable, and reply the result to the LPA. More specifically, the action of the terminal changing the profile to Unusable may refer to an action that occurs in the first terminal and the eUICC changes the state of the first profile to Unusable at the time the eUICC receives a request to create a profile package for device change. If the profile was in the Enabled (210) state at the time it receives and processes the EPP creation command, a transition to the Unusable (200) state via the disabled (200) state may be performed. In addition, the default setting state of a profile package (EPP) created from the first profile for moving to a second terminal may be indicated as the Unusable state. As an action occurring in the second terminal, the second terminal may receive the second profile package generated from the first profile in an Unusable state for device change. In the device change, the Unusable state may mean a state in which transition to the profile activation state is impossible before the eUICC_S receives the result of the deletion processing of the profile package transmitted to the second terminal. The state in which transition to the profile activation state is impossible may also comprehensively include transitioning to the profile activation state via profile deactivation.

[0102] The transition from the Unusable (200) state to the Delete (230) state may be performed as part of the process in which the eUICC receives and processes a device change interrupt command. For example, the device change interrupt command described above may be a command such as ES10x. cancel Profile Export.

[0103] In the present disclosure, the operation of allowing a terminal to restore a first profile in an unusable state to a disabled state may be, for example, an operation occurring in the first terminal, when the result of a deletion process of an EPP generated from the first profile is received from a second terminal or a server and verification is successful. As another example, the operation may mean an operation occurring in the second terminal, when the second terminal receives the result of a deletion process of the first profile from the first terminal or a server and verification is successful, changing the EPP to a disabled state.

[0104] When an eUICC receives a delete command from the LPA for a profile in the Unusable (200) state, for example, ES10c.DeleteProfile (ICCID or Application ID), it can allow the deletion of the instructed profile. For example, since the deletion is not in the disabled state, the eUICC can generate an error message and send it to the LPA and terminate the procedure according to the current GSMA SGP.22, but it can allow the deletion of the profile to complete the deletion.

[0105] Alternatively, even if the eUICC does not explicitly receive a delete command for a profile in the Unusable (200) state from the LPA, the eUICC may delete the profile in the Unusable (200) state if the deletion conditions are met during the process of performing a device change. For example, the above-described operation may occur if the eUICC of the second terminal does not receive a delete message for Profile 1 within a certain period of time after receiving an EPP from the eUICC of the second terminal.

[0106] FIGS. 3A and 3B are diagrams illustrating an example of a method for stopping a device change to a second terminal and restoring a profile of a first terminal according to one embodiment of the present disclosure.

[0107] Referring to FIGS. 3A and 3B , an End User (300) may select to move a profile installed on a first terminal (310) to a second terminal (320) (step 3000). The screen for selecting the move may be provided to the user through a screen displayed to the user on the first terminal (310) or the second terminal (320). The first terminal (310) and the second terminal (320) may verify eligibility for profile transfer through mutual authentication (step 3010). An example of a method for mutual authentication may include the first terminal (310) and the second terminal (320) exchanging information on a list of trusted CIs stored with each other and verifying whether they have a valid and identical certificate chain. The method for mutual authentication will be described later in FIG. 8 .

[0108] If the first terminal determines the second terminal as an eligible terminal for profile transfer through mutual authentication, the first terminal can generate a profile package, EPP, to transmit the first profile selected by the user to the second terminal (step 3020). The EPP can have the same network access credentials as the first profile, and can be transmitted encrypted so that it can be installed only on the second eUICC of the second terminal. The first terminal (310) can allow the generation of a profile package (in EPP state) only when the profile is in a disabled state. In addition, the existing profile can be transitioned to a temporarily locked state so that it cannot be changed to an enabled state in a disabled state. The above-described state can be named, for example, as an Unusable state in the present invention. The description of the Unusable state will be given in reference to the description in FIG. 2.

[0109] 'Information of the first terminal' may be included and transmitted from the first terminal to the second terminal (320). 'Information of the first terminal' may be one of the eUICC certificate information or EID of the first eUICC on which the profile to be moved is currently installed. The time at which 'information of the first terminal' is transmitted to the second terminal may occur before the time at which the profile package in the Exported state is deleted from the second terminal (step 3080). For example, 'information of the first terminal' may be included and transmitted during the procedure for mutual authentication between terminals (step 3010) or when the profile package which is EPP is transmitted (step 3030). 'Information of the first terminal' may be stored in the second terminal (320).

[0110] The second terminal (320) can receive the EPP and install it on the eUICC (3040). In the case of EPP installation, the eUICC can transmit the installation result to the first terminal, which is the Source Device, rather than the Server Address of the Profile Metadata. The installation result is transmitted as eUICC_T signed information, and can be transmitted to the first terminal including at least one of ICCID and certificate information of the eUICC_T (step 3050). The first terminal that has received the installation result can verify the installation result and request the user to confirm the final profile transfer (step 3060). The eUICC of the first terminal (310) can verify the signature of the received eUICC signed installation result to verify whether the ICCID previously transmitted has been installed on the eUICC_T.

[0111] The user can request cancellation of the transfer (step 3070) through the UI of the first terminal (310) or the second terminal (320) (e.g., by clicking the cancel button). The LPA of the second terminal (320) can transmit a command to delete the profile package to the eUICC. The command to delete the profile package can be an explicit delete command or a cancel device change command that includes deletion of the profile package (or some data of the profile package). The eUICC that receives the command to delete the profile package can delete the EPP and / or EPP installation data, and generate an EPP Delete Result (step 3080) and transmit it to the first terminal (310). In addition, if the second terminal (320) receives EPP-related data from the first terminal during the process of processing the transfer cancellation and stores it in the terminal (e.g., in the LPA), it can also delete the data stored in the terminal.

[0112] The eUICC of the second terminal can generate and sign an EPP Delete Result. At this time, the EPP Delete Result can be transmitted including at least one of the following information: the ICCID, which is the ID of the deleted profile, and the certificate information of the eUICC_T for signature verification (step 3090).

[0113] The eUICC_S of the first terminal (310) that received the EPP Delete Result can verify the signature of the EPP Delete Result to confirm whether the ICCID is identical to the ICCID of the profile that has been changed to the Unusable state (step 3100). If the signature verification is successful, the eUICC_S of the first terminal (310) can unlock the profile state (step 3110) to change the existing profile state to the Enabled state and return the processing result to the first terminal (310).

[0114] Thereafter, when deleting the first profile installed in the first terminal (310), the first terminal (310), the profile server (330), and the Mobile Service Provider (340) can generate and transmit a Delete Notification according to the profile deletion according to the Delete Notification processing defined in SGP.22 (step 3120).

[0115] Previously, the user can confirm the final profile transfer (3060) and proceed with the transfer. At this time, the first terminal (310) can transmit an ES10x command for the first profile to be transferred to the eUICC_S, so that the eUICC_S can process the deletion of the first profile (step 3130). The eUICC_S can generate a profile deletion result and reply to the first terminal with data signed by the eUICC_S (step 3140). The profile deletion result can be generated by including at least one of the ICCID of the deleted profile and 'first terminal information'.

[0116] The first terminal (310) can include the received profile deletion result in a profile deletion notification message and transmit it to the profile server (330) (step 3150). The profile deletion notification can include profile deletion result data signed by the eUICC_S of the first terminal (310), and can also be configured to further include the EPP installation result received from the second terminal (320) in step 3050.

[0117] The profile server (330) that receives the profile deletion notification can verify the signature of the eUICC_S of the received profile deletion notification to verify the profile deletion result. In addition, if there is an EPP installation result received together, the profile server (330) can additionally determine whether the profile is moved or reinstalled by verifying the EPP installation result (step 3160). The method by which the profile server (330) verifies the EPP installation result may be a method of verifying and determining using at least one of the eUICC_T signed installation result included in the EPP installation result or the certificate information of the eUICC_T. If the profile server (330) determines that the profile is moved or reinstalled, the profile server (330) can update the information of the EID that is stored by mapping it to the received ICCID. In addition, the profile server can notify the telecommunications operator that a device change has occurred through ES2+.HandleNotification (step 3170).

[0118] Meanwhile, after completing the device change process, the first terminal (310) may delete the remaining EPP generation data if any remains in the LPA and / or eUICC_S. For example, the above-described operation may be performed after transmitting a notification regarding the deletion of profile 1 to the profile server (330). As another example, the above-described operation may be performed simultaneously when the eUICC_S processes the deletion of profile 1.

[0119] Meanwhile, it should be noted that steps 3150 to 3170 of FIG. 3b may also be performed as one of the operations in steps 5170 to 5190 of FIG. 5b. For example, steps 3150 to 3170 of FIG. 3b may be described based on Method 1 in the description of steps 5170 to 5190 of FIG. 5b, and thus the corresponding steps in FIG. 5b may be interpreted with reference to the description.

[0120] FIGS. 4A and 4B are diagrams illustrating examples of a method for providing a telecommunications service provider with processing results when a device change to a second terminal is interrupted according to one embodiment of the present disclosure.

[0121] Referring to FIGS. 4A and 4B , an End User (400) may select to move a profile installed on a first terminal (410) to a second terminal (420) (step 4000). The screen for selecting the move may be provided to the user through a screen displayed to the user on the first terminal (410) or the second terminal (420). The first terminal (410) and the second terminal (420) may verify eligibility for profile transfer through mutual authentication (step 4010). An example of a method for mutual authentication may be for the first terminal (410) and the second terminal (420) to exchange information on a list of trusted CIs stored between each other and verify whether they have a valid and identical certificate chain. The method for mutual authentication will be described later in FIG. 8.

[0122] When the first terminal determines the second terminal as an eligible terminal for profile transfer through mutual authentication, the first terminal can generate a profile package, EPP, to transmit the first profile selected by the user to the second terminal. The EPP can have the same network access credentials as the first profile, and can be transmitted encrypted so that it can be installed only on the second eUICC of the second terminal. The first terminal (410) can also allow the generation of a profile package (in EPP state) only when the profile is in a disabled state.

[0123] The 'information of the first terminal' may be transmitted from the first terminal to the second terminal (420). The 'information of the first terminal' may be either eUICC certificate information or EID of the first eUICC on which the profile to be moved is currently installed. The time at which the 'information of the first terminal' is transmitted to the second terminal may occur before the time at which the profile package (EPP) is deleted from the second terminal (step 4060). For example, the 'information of the first terminal' may be transmitted by being included during the procedure for mutual authentication between terminals (step 4010) or by being included at the time of transmitting the profile package which is the EPP (step 4030). The second terminal (420) may store the 'information of the first terminal'.

[0124] The second terminal (420) can receive EPP and install it in the eUICC (step 4040).

[0125] The second terminal (420) may not successfully complete the subsequent device change procedure because it does not receive a message from the first terminal (410) regarding the deletion of the first profile. Alternatively, the device change procedure may be interrupted when only some data regarding EPPs have been received before the second terminal (420) receives a message from the first terminal (410) regarding the deletion of the first profile. For example, reasons for not completing the device change procedure may include a user changing his mind, interruption of the device change, or a disconnection between devices.

[0126] The second terminal (420) may enter a procedure for deleting the received EPP (or some data of the EPP received so far) (step 4050). After a certain period of time has elapsed after user input (400) or detection of a disconnection between devices, the second terminal (420) may enter a setting (e.g., EPP deletion) according to a specific condition.

[0127] The LPA of the second terminal (420) can transmit an ES10x.message to the eUICC for deleting a profile package (EPP). The eUICC, which receives the ES10x.message, can delete the installed EPP (step 4060). As described above in FIG. 3, the EPP deletion can also be performed by the eUICC by receiving a device change cancellation command (e.g., ES10x.cancelProfileExport). The eUICC can additionally determine whether to generate a Delete Notification (step 4070) while deleting the EPP. It should be noted that the EPP Delete Notification can also be used as another function name, such as cancel notification, to mean canceling the corresponding device change procedure. However, in FIG. 3a, FIG. 3b, and the present disclosure, the phrase "delete notification" can be used to mean deleting part or all of the information of the EPP transmitted to the Target Device. Of course, it is not limited to the above meaning.

[0128] For example, eUICC can check Profile Export Configuration information by checking Profile metadata. Profile Export Configuration information can be setting information that includes at least one of whether a Delete Notification is required when deleting an EPP and the server address to receive the notification.

[0129] If there is no request to send a Delete Notification to the server when deleting an EPP, the second terminal (420) can terminate the procedure (step 4140) without generating a Delete Notification after deleting the EPP.

[0130] When there is a request to create a Delete Notification to the server when EPP is deleted, the second terminal (420) can create a Delete Notification and transmit it to the server as data signed by eUICC_T.

[0131] EPP Delete Notification can be generated by including at least one of the ICCID as the ID of the deleted profile, first terminal information, a certificate of the second eUICC, and data signed with the private key of the second eUICC.

[0132] The second terminal (420) can transmit an EPP Delete Notification to the server. The second terminal (420) can connect to the server address to be transmitted (e.g., one of the SM-XX server addresses included in the PE Configuration set in the Profile metadata, the Notification receiver, or the SM-XX server address pre-stored in the terminal) (step 4090).

[0133] The transmission method may be based on TLS authentication at the transport layer, based on the Notification transmission method defined in SGP.22. Alternatively, the EPP Delete Notification may be transmitted after additional mutual authentication and performance negotiation between the terminal and the RSP server (step 4080) like an ES9+ message other than the Notification defined in SGP.22. The transmitted message may be a new ES9+ message or an extended form of the OtherSignedNotification currently defined in SGP.22.

[0134] The profile server (430) that receives the EPP Delete Notification can verify the eUICC_T signature and, if the first terminal information is received, can verify whether the stored EID and the eUICC_S EID received with the first terminal information are identical by mapping them to the received ICCID (step 4100).

[0135] - The profile server (430) receives the first terminal information, and if the EID matching result is the same, it can be determined as normal deletion during Profile Export.

[0136] - The profile server (430) receives the first terminal information, and if the EID matching result is different, it can be determined as an abnormal operation.

[0137] If the first terminal information is not received, the profile server (430) can recognize it as a deletion of an existing installed profile in one terminal rather than a change of device and process it as defined in SGP.22. For example, the profile server (430) can process it by verifying whether the EID stored by mapping with the received ICCID and the EID included in the certificate of the second eUICC are the same.

[0138] The profile server (430) can transmit the verification result to the telecommunications service provider (440) as ES2+.HandleNotification. For example, the profile server (430) can transmit the NotificationEvent as Delete during Profile Export, NotificationEventStatus = Success, and can also provide an additional notification as EID mismatch when eUICC_S EID = / EID mapped to the corresponding ICCID (step 4110).

[0139] The telecommunications operator (440) may receive ES2+.HandleNotification and additionally determine processing for the corresponding ICCID. If it recognizes that the eUICC_S EID = / is different from the EID mapped to the corresponding ICCID and thus an EID mismatch, the telecommunications operator (440) may recognize this as an abnormal situation (e.g., SIM duplication). The telecommunications operator (440) may block network access from the first terminal (410) in the corresponding operator's network (step 4120) according to the operator's policy.

[0140] If the operator network blocks access, the first terminal (410) cannot receive communication services using the pre-installed first profile. On the other hand, if the operator network maintains access permission, the first terminal (410) can receive continuous communication services if the pre-installed first profile is activated (step 4130).

[0141] FIGS. 5A and 5B are diagrams illustrating another example of a method for stopping a device change to a second terminal and restoring a profile of a first terminal according to one embodiment of the present disclosure.

[0142] Referring to FIGS. 5a and 5b, the profile server (530) may perform verification to restore a profile locked in an Unusable state to an available state in the first terminal (510).

[0143] An end user (500) may select to move a profile installed on a first terminal (510) to a second terminal (520) (step 5000). The screen for selecting the move may be provided to the user through a screen displayed to the user on the first terminal (510) or the second terminal (520). The first terminal (510) and the second terminal (520) may verify eligibility for profile transfer through mutual authentication (step 5010). An example of a method for mutual authentication may be for the first terminal (510) and the second terminal (520) to exchange information on a list of trusted CIs stored with each other and verify whether they have a valid and identical certificate chain. The method for mutual authentication will be described later in FIG. 8.

[0144] When the first terminal determines the second terminal as an eligible terminal for profile transfer through mutual authentication, the first terminal can generate a profile package, EPP, to transmit the first profile selected by the user to the second terminal (step 5020). The EPP can have the same network access credentials as the first profile, and can be transmitted encrypted so that it can be installed only on the second eUICC of the second terminal. The first terminal (510) can allow the creation of a profile package (EPP) only when the profile is in a disabled state. In addition, the existing profile can be temporarily locked to a disabled state so that it cannot be changed to an enabled state. For example, the above-described state can be named an Unusable state in the present invention. For a description of the Unusable state, refer to the description in FIG. 2.

[0145] 'Information of the first terminal' may be included and transmitted from the first terminal to the second terminal (520). 'Information of the first terminal' may be one of the eUICC certificate information or EID of the first eUICC on which the profile to be moved is currently installed. The time at which 'information of the first terminal' is transmitted to the second terminal may occur before the time at which the profile package in the Exported state is deleted from the second terminal (step 5060). For example, 'information of the first terminal' may be included and transmitted during the procedure for mutual authentication between terminals (step 5010) or when the profile package which is EPP is transmitted (step 5030). The second terminal (520) may store 'information of the first terminal'.

[0146] The first terminal (510) may additionally request server verification in order to change the first profile, which has been changed to an Unusable state in the first terminal due to reasons such as a device change failure, to an available state. The predetermined information regarding whether server verification is required may include at least one of whether server verification is required for recovery and the address of a server to be accessed, and the predetermined information regarding whether server verification is required may be set in the metadata of the profile, stored in a pre-loaded form in the terminal, or exist as information in a setting in a file of the profile.

[0147] If the eUICC of the first terminal (510) determines that server intervention is necessary to restore the state of the first profile in the Unusable state based on the predetermined information mentioned above, the eUICC may additionally generate an eUICC_S Challenge and send it in response to the first terminal (510). The first terminal (510) may transmit the eUICC_S Challenge to the eUICC_T of the second terminal (520). For example, the eUICC_S Challenge may be transmitted together with the EPP transmission at step 5030. The eUICC_T may store the eUICC_S Challenge.

[0148] The second terminal (520) can receive the EPP and install it on the eUICC (5040). In the case of EPP installation, the eUICC can transmit the installation result to the first terminal, which is the Source Device, rather than the Server Address of the Profile Metadata. The installation result can be transmitted as data signed by the eUICC_T, and the data can be transmitted to the first terminal including at least one of ICCID, EID, and certificate information of the eUICC_T (step 5050). The first terminal that has received the installation result can verify the installation result and request the user to confirm the final profile transfer (step 5060). The eUICC of the first terminal (510) can verify the signature of the installation result signed by the received eUICC to verify whether the ICCID previously transmitted has been installed on the eUICC_T.

[0149] The user can request cancellation of the transfer through the UI of the first terminal (510) or the second terminal (520) (e.g., by clicking the cancel button, etc.) (step 5070). The LPA of the second terminal (520) can transmit a command to delete the profile package transmitted to the eUICC. The eUICC, which has received the command to delete the profile package, can delete the EPP and generate an EPP Delete Result (step 5080) and transmit it to the profile server (530). As described above, in addition, if the second terminal (520) receives EPP-related data from the first terminal and stores it in the terminal (e.g., the LPA), the second terminal (520) can additionally delete the data stored in the terminal (e.g., the LPA).

[0150] The eUICC of the second terminal can generate an EPP Delete Result with data signed by the eUICC (step 5080). The EPP Delete Result data can be transmitted including at least one of the following information: the ICCID, which is the ID of the deleted profile, and the certificate information of the eUICC_T for signature verification (step 5090).

[0151] The profile server (530) can verify the deletion result of the EPP by verifying the eUICC signature (eUICC_S signature) of the EPP Delete Result (step 5100).

[0152] The profile server (530) may compose a deletion proof message including the received eUICC_S Challenge and reply to the second terminal (520) (step 5110). The deletion proof message may be signed and transmitted with the profile server's key. The deletion proof message may further include at least one of the following information: an ICCID, an eUICC_T certificate with eUICC_T information, a profile server certificate, or an EID of the eUICC_T with eUICC_T information.

[0153] The second terminal (520) can transmit a deletion proof message received from the profile server (530) to the first terminal (510).

[0154] The eUICC_S of the first terminal (510) that received the deletion proof message can perform verification (step 5120) by including at least one of the following actions. Of course, the present invention is not limited to the following examples.

[0155] - Verify the certificate of the received profile server

[0156] - Verify the signature of the received profile server

[0157] - Verify that the eUICC_S Challenge is identical to the previously transmitted eUICC_S Challenge:

[0158] It can be confirmed that this is a server's proof message for the deletion processing message sent from eUICC_T to the profile server, which eUICC_S previously sent EPP to.

[0159] - Confirm eUICC_T information using the received eUICC_T certificate or EID or other specified information.

[0160] - eUICC_S verifies whether the received ICCID is identical to the ICCID of the Unusable profile:

[0161] The deleted EPP has the same ICCID as the Unusable profile, so compare and verify the received ICCID with the ICCID of the Unusable profile.

[0162] - Result of EPP deletion processing transmitted from eUICC_T

[0163] If the signature verification is successful in the eUICC_S of the first terminal (510), the eUICC_S of the first terminal (510) can release the profile status lock (step 5130). In the process of releasing the profile status lock, the eUICC_S can delete the previously transmitted eUICC_S Challenge.

[0164] For example, if the first terminal (510) succeeds in signature verification in eUICC_S, it can reply the processing result to the LPA of the first terminal (510) and receive a command for profile state lock release from the LPA, thereby releasing the profile state lock as a result of the profile state lock release command.

[0165] Thereafter, when the first profile installed in the first terminal (510) is deleted, the first terminal (510), the profile server (530), and the Mobile Service Provider (540) can generate and transmit a Delete Notification according to the profile deletion according to the Delete Notification processing defined in SGP.22 (step 5140).

[0166] Previously, the user can confirm the final profile transfer (5060) and proceed with the transfer. In this case, the first terminal (510) can transmit an ES10x command for the first profile to be transferred to the eUICC, so that the eUICC_S can delete the first profile (step 5150). The eUICC_S can generate a profile deletion result, sign it, and reply to the second terminal (step 5160). The profile deletion result message can be generated by including at least one of the ICCID of the deleted profile and 'first terminal information'. In addition, if the eUICC_S has stored the eUICC_S Challenge previously generated and transmitted to the second terminal, it can delete the stored eUICC_S Challenge.

[0167] The second terminal (5160) that receives the eUICC_S Challenge verifies the signature of the eUICC_S to confirm that the profile has been deleted from the eUICC_S, and can change the moved profile to an available state (e.g., a disabled state).

[0168] Additionally, the first terminal (510) and / or the second terminal (520) may optionally provide the device change processing results to the profile server (530) (step 5170). Step 5170 may include one of the following methods, but is not limited to the following examples.

[0169] 1. When a notification for profile deletion is sent from the first terminal (510) to the profile server (530), information is included that can indicate that a device change has occurred to the second terminal (520).

[0170] 2. Explicitly transmit to the profile server (530) that the profile transfer procedure has been completed in the second terminal (520).

[0171] 3. A message is sent from the second terminal (520) to the first terminal (510) notifying that the profile transfer procedure is complete, and the message is sent from the first terminal (510) to the profile server (530).

[0172] In the case of method 1: A notification regarding profile deletion can be transmitted from the first terminal (510) to the profile server (530).

[0173] The profile deletion notification may be transmitted as data generated and signed by the eUICC of the first terminal (510). The notification may further include information indicating that a profile deletion has occurred as part of the device change process. For example, it may be the name of the notification function (e.g., DeleteNotoficationForPE). Meanwhile, the data constituting the notification may additionally include and be transmitted information indicating the completion of the device change to the second terminal. For example, the notification may include the EPP installation result received from the second terminal (520) in step 5050. Alternatively, the notification may further include an explicit installation completion message received from the second terminal (520).

[0174] The profile server (530) that receives the notification for profile deletion can verify the signature of the eUICC_S of the received profile deletion notification to verify the profile deletion result. In addition, the profile server (530) can additionally determine that the profile was deleted from the first terminal (510) and installed in the second terminal (520) during the device change by referring to the function name or included data of the notification message. For example, if the profile server (530) receives the EPP installation result, it can additionally determine whether the profile is moved and reinstalled by verifying the EPP installation result. The received EPP installation result can be received as eUICC_T signed data. Therefore, the method for the profile server (530) to verify the EPP installation result may be a method of verifying and determining with at least one of the installation result signed by the eUICC_T included in the EPP installation result or the certificate information of the eUICC_T.

[0175] In the case of method 2: As described above, after the second terminal (520) receives the signed deletion result from the first terminal (510) (step 5160), the eUICC of the second terminal (520) can change the status of the corresponding profile to an available state (e.g., disabled). Optionally, the second terminal (520) can further generate a message regarding the completion of the device change procedure. The message regarding the completion of the device change procedure can be a message including at least one of the ICCID of the installed profile, the eUICC_S certificate, the eUICC_T certificate, the EID of the eUICC_S, or the EID information of the eUICC_T. The second terminal (520) can also transmit a device change procedure completion message as a message signed by the eUICC_T of the second terminal to the profile server (530). The profile server (530) can verify the signature of the eUICC_T by checking the received message. Additionally, the profile server (530) can confirm the received message and determine the completion of the device change procedure from the first terminal (510) to the second terminal (520). Additionally, the profile server (530) can additionally receive a deletion notification message from the first terminal (510) and determine the final completion of the device change procedure.

[0176] In the case of method 3: The second terminal (520) may transmit the device change completion message signed by eUICC_T to the first terminal (510), and the first terminal (510) may construct and transmit a message including the device change completion message signed by eUICC_T to the profile server (530).

[0177] The first terminal (510) may also transmit to the profile server (530) the device change completion message signed by eUICC_T as additional data of the profile deletion notification transmitted in the method 1 above or as data of a separate message. For example, in the case of profile deletion during a device change, the first terminal (510) may not transmit the existing profile deletion message defined in SGP.22 or an extended message thereof, but may instead construct and transmit a separate message, such as a device change processing completion message. The message transmitted by the first terminal (510) may be transmitted as an eUICC_S signed message. The profile server (530) that receives the eUICC_S signed message may verify the signature of the eUICC_S. In addition, the profile server (530) may additionally verify the eUICC_T signature to confirm the data if the transmitted message includes eUICC_T signed data.

[0178] If the profile server (530) receives the message and successfully verifies it, the profile server (530) can update the ICCID-EID mapping information from the EID of the eUICC_S to the EID of the eUICC_T (step 5180). In addition, the profile server (530) can also notify the telecommunications carrier of the device change through ES2+.HandleNotification (step 5190).

[0179] FIG. 6 is a diagram illustrating another example of a method for stopping a device change to a second terminal and restoring a profile of a first terminal according to one embodiment of the present disclosure.

[0180] Referring to FIG. 6, a method may also be possible in which the first terminal (610) receives the EPP deletion result from the second terminal (620), transmits it to the profile server (630), and receives permission for a status change from the profile server to process the change. After the first terminal (610) creates an EPP during the process of performing a device change, and after unlocking the status of the existing profile to the Unusable status, an unexpected situation such as a change of mind by the user or a disconnection between the terminals during the device change process may occur at a certain point (step 6040). In this case, for the convenience of the user, the existing profile 1 may be restored to a usable state, and at this time, server intervention may be required.

[0181] Telecommunications carriers can set certain information for profile status recovery as a policy for profiles. For example, this information can be included in the profile's metadata or in an attribute file (Elementary File) included in the profile.

[0182] The information to be set may include at least one of whether to notify the server of a device change, whether to notify of a profile status change to Unusable, an operation for a change in Unusable status, the address of the server for transmitting the profile status change, the address of the server for authorizing profile status restoration, or the number of allowed profile status restorations. The address of the server for transmitting the profile status change message and the address of the server for authorizing profile status restoration may be the same or different.

[0183] An end user (600) can select to move a profile installed on a first terminal (610) to a second terminal (620) (step 6000). The screen for selecting the move can be provided to the user through a screen displayed to the user on the first terminal (610) or the second terminal (620). Please confirm whether my expression is appropriate. Terminal 1 (610) and terminal 2 (620) can verify eligibility for profile transfer through mutual authentication (step 6010). An example of a method for mutual authentication may be for the first terminal (610) and terminal 2 (620) to exchange information on a list of trusted CIs stored with each other and verify whether they have a valid and identical certificate chain. The method for mutual authentication will be described later in FIG. 8.

[0184] When eUICC_S creates a profile package EPP to be moved from the first profile and changes the status of the profile to Unusable, the first terminal (610) can transmit a profile status change message to the server with reference to predetermined information for profile status recovery (step 6030).

[0185] A profile status change message may be transmitted with data signed by eUICC_S and may include at least one of the following information: ICCID of the profile, eUICC_S certificate, changed status=Unusable, and verification code for the status change. An example of the status change verification code may be an eUICC_S Challenge, which is a random value generated and included by eUICC_S.

[0186] The first terminal (610) and the profile server (630) may transmit a status change message after performing mutual authentication to determine whether they are in the same certificate chain as the profile server (620). For example, this may be performed by referring to the mutual authentication procedure defined in SGP.22 (step 6030). Alternatively, the first terminal (610) may perform authentication at the network layer by referring to the notification transmission procedure defined in GSMA's SGP.22 to transmit the status change message (step 6030).

[0187] The profile server (630) that receives the status change message can verify the signature of eUICC_S and check whether the profile status of the received ICCID has changed to Unusable.

[0188] The profile server (630) can update the status of the received profile with the status of the corresponding profile, and can also notify the telecommunications service provider (640) of the changed status. For example, a message such as ES2+.HandleNotification can be used.

[0189] An input (input, etc.) for stopping the profile movement of the user (600) in the first terminal (610) or a network connection error for changing the device may be detected (step 6040).

[0190] The profile server (630) may issue a recovery code to the first terminal (610) in response to a profile status change message. The recovery code may include at least one of the following: the address of the server performing the recovery, the address of the server that issued the recovery code, and identification information for identifying the profile to be recovered. The recovery code may be, for example, one of the following: ICCID, a random string, or S_Challenge.

[0191] In this case, the first terminal (610) may enter a procedure for recovering the profile status. At the time of entering the procedure for recovering the profile status, the first profile may be in an Unusable state, and an EPP in an Unusable state may have been created. In addition, the EPP may exist in the first terminal, or may have been transferred to the second terminal and transmitted / installed in the second terminal (step 6040).

[0192] The first terminal (610) can determine whether EPP has been transmitted to the second terminal (620).

[0193] The first terminal (610) can determine whether the EPP has been transmitted to the second terminal (620), and can determine that the EPP has been generated in the first terminal (610) and transmitted to the second terminal (620). If the EPP has been transmitted to the second terminal (620), the first terminal (610) must first process the deletion of the profile transmitted to the second terminal (620), and can notify the user of this through the UI (600).

[0194] The user (600) can process profile deletion. The process of processing profile deletion may include the LPA of the second terminal (620) requesting deletion of the EPP moved and installed in the eUICC_T of the second terminal (620) and receiving the generated deletion result. In addition, the eUICC_T of the second terminal (620) may reply to the LPA including the signature of the eUICC_S regarding the deletion result. The second terminal (620) may transmit the deletion result signed by the eUICC_T to the first terminal (610). The data of the deletion result message replied by the eUICC_T may include at least one of the ICCID and the EID. In addition, the data of the deletion result message may be transmitted further including the signature of the eUICC_T and an eUICC_T certificate as predetermined information for signature verification (step 6050).

[0195] The first terminal (610) may receive the deletion result signed by eUICC_T, include it in a status recovery request message, and transmit the status recovery request message to the profile server (630). The first terminal (610) may also transmit the status recovery request message including the recovery code received from the profile server (630).

[0196] After the profile server (630) performs mutual authentication to determine whether the first terminal (610) is in the same certificate chain as the profile server (620), the first terminal (610) may transmit a status recovery request message. For example, the transmission of the above-described status recovery request message may be performed with reference to the mutual authentication procedure defined in SGP.22 (step 6060). When the profile server (630) receives the status recovery request message, the profile server may verify the status recovery request message (step 6065). The verification of the status recovery request message may include at least one of the following actions, but is not limited to the following examples.

[0197] - Verification of eUICC_T certificate and certificate chain

[0198] - Signature verification of the corresponding profile recovery message signed with the key of eUICC_T

[0199] - Confirm whether EPP has been deleted through the recovery request message

[0200] Upon confirming the EPP deletion, the profile server (630) may generate a profile recovery message, sign it, and reply to the first terminal (610) (step 6070). Additionally, the profile server (630) may change the status of the profile back to its previous state.

[0201] A profile recovery message may be a message containing at least one of the ICCID of the profile whose state is to be recovered or a recovery indicator.

[0202] The eUICC_S of the first terminal (610) that received the profile recovery message can verify the signature of the profile server (step 6080) and change the status of the ICCID to the previous status and store it (step 6090).

[0203] The eUICC_S may transmit the result of the profile status change to the first terminal (610) to notify the user (600) that the profile status has been restored. Additionally, the eUICC_S may also sign the result of the processing of the profile status change and return it to the profile server.

[0204] The first terminal (610) can determine whether the EPP has been transmitted to the second terminal (620), and can determine that the EPP was generated in the first terminal (610) but before being transmitted to the second terminal (620). In this case, the first terminal (610) can enter the profile recovery phase using one of the following methods. Of course, the present invention is not limited to the following examples.

[0205] 1) If permission to the server is not required due to the setting information of the corresponding profile: When the first terminal (610) detects an input for recovery of the user (600) or a connection error, etc., the first terminal (610) can cause the eUICC_S to process EPP deletion for the requested ICCID.

[0206] When the first terminal (610) explicitly transmits an EPP deletion command to the eUICC_S, or when the first terminal (610) transmits a profile status recovery command to the eUICC_S, the eUICC_S can perform an operation including deleting the EPP.

[0207] For example, when the first terminal (610) explicitly transmits an EPP deletion command, the transmitted EPP deletion command may be defined as an ES10x. message for new EPP deletion, or an identifier indicating EPP profile deletion may be further included in the existing ES10x.DisabledProfile command. The distinction of the above-described EPP deletion command may be provided as information for distinguishing between two profiles having the same ICCID in the eUICC_S. The above-described description may be equally applicable to other embodiments of the present invention.

[0208] When the eUICC_S receives the received EPP delete command, it can check the ICCID to confirm the profile to be deleted. The eUICC_S can store information about the EPP profile created when the eUICC_S created the EPP. For example, it can store the identification information for the EPP profile in the metadata of the EPP or in the ISD-R. The eUICC_S can also perform an operation to determine whether it is an EPP. For example, the operation to determine whether it is an EPP can be an operation to check the metadata of the profile or an operation to check the attribute information for the corresponding profile stored in the ISD-R.

[0209] If the eUICC_S successfully responds with the deletion of the EPP, the LPA of the first terminal (610) can transmit a command to deactivate or activate the first profile to the eUICC_S. The eUICC_S, which has received the command to deactivate or activate the first profile, can perform the requested operation. The eUICC_S can additionally verify whether there is an EPP in the eUICC_S as a condition for performing the requested operation, and if there is an EPP, return an error to notify the terminal to perform the deletion of the EPP.

[0210] When the first terminal (610) transmits a profile status recovery command to the eUICC_S, the eUICC_S may perform an operation of deleting an EPP. The first terminal (610) may transmit the profile status recovery command to the eUICC_S. The profile status recovery command may be defined as an ES10x message. The profile recovery command may be transmitted to the eUICC_S including the ICCID of the profile to be recovered, and the eUICC_S that receives the profile recovery command may additionally determine whether there is an EPP in the eUICC_S before changing the profile status to the previous disabled state.

[0211] For example, eUICC_S can determine that a profile with an EPP identifier (or data distinguished by EPP) has the same ICCID as the ICCID of the requested profile. If an EPP exists, eUICC_S can delete the target EPP, change the status of the first profile with the requested ICCID to the previous status, and then reply the result of the processing to the first terminal (610).

[0212] As mentioned above, an EPP may be an image having all or part of the attributes of the first profile. Therefore, when an EPP exists, it may mean that part or all of an EPP created for profile migration during a device change process exists in the eUICC_S. The eUICC_S can display and manage the data created for the device change as profile data (e.g., EPP) created for the device change.

[0213] Meanwhile, the status recovery command may include deleting EPP-related data generated by the eUICC and reverting the status of the existing profile to its previous state. For example, the above-described command may be a request to cancel a device change.

[0214] The first terminal (610) can confirm the received result and provide the processing result to the user (600).

[0215] 2) If permission to the server is required for the profile setting information: The first terminal (610) can delete the EPP by sending an EPP deletion command to the eUICC_S when detecting an Input for recovery of the user (600) or a connection error. The deletion of the EPP can be processed as described above (e.g., 1). The eUICC_S can sign the EPP deletion result and reply to the first terminal (610).

[0216] The first terminal (610) may receive the deletion result signed by eUICC_S and transmit the deletion result to the profile server (630) by including it in a status recovery request message. The first terminal (610) may also transmit the message by including the recovery code received from the profile server.

[0217] After the profile server (630) performs mutual authentication to determine whether the first terminal (610) is in the same certificate chain as the profile server (630), the first terminal (610) may transmit a status recovery request message. For example, the transmission of the above-described status recovery request message may be performed with reference to the mutual authentication procedure defined in SGP.22 (step 6060). When the profile server (630) receives the status recovery request message, the profile server may verify the status recovery request message. The verification of the status recovery request message may include at least one of the following actions, but is not limited to the following examples.

[0218] - Verification of eUICC_S certificate and certificate chain

[0219] - Signature verification of the corresponding profile recovery message signed with the key of eUICC_S

[0220] - Confirm whether EPP has been deleted through the recovery request message

[0221] Upon confirming the EPP deletion, the profile server may generate a profile recovery message, sign it, and reply to terminal 1 (610). Additionally, the profile status may be changed back to its previous state.

[0222] A profile recovery message may be a message that includes at least one of the following information: the ICCID of the profile whose state is to be recovered, and a recovery indicator.

[0223] The eUICC_S of the first terminal (610) that received the profile recovery message can verify the signature of the profile server and change the corresponding ICCID status to the previous status and store it.

[0224] The eUICC_S may transmit the result of the profile status change to the first terminal (610) to notify the user (600) that the profile status has been restored. Additionally, the eUICC_S may sign the result of the processing of the profile status change and return it to the profile server.

[0225] FIG. 7 is a diagram illustrating the configuration of a “trusted CI list” according to some embodiments of the present disclosure.

[0226] Referring to FIG. 7, the 'trusted CI list (700) stored in the terminal' may be a list of eUICCs trusted by the terminal manufacturer and / or eUICC manufacturer. Alternatively, the 'trusted CI list (700) stored in the terminal' may be a list of information that can be used to verify eUICCs trusted by the terminal manufacturer and / or eUICC manufacturer. More specifically, the Trusted CI by Device Info (s) included in the 'trusted CI list (700) stored in the terminal' may be a) information that can identify eUICCs trusted by the terminal manufacturer and / or eUICC manufacturer, or b) certificate information that can verify eUICCs trusted by the terminal manufacturer and / or eUICC manufacturer. For example, the Trusted CI by Device Info (s) may be public key information of the top root certificate of the certificate chain of the eUICC whose reliability is to be verified. Alternatively, the Trusted CI by Device Info(s) may be the public key ID (PKID) information of the top root certificate of the certificate chain of the eUICC whose authenticity is to be verified.

[0227] The 'trusted CI list (700) stored in the terminal' may be information created and / or provided by the terminal manufacturer and / or eUICC manufacturer.

[0228] The 'Trusted CI list (700) stored in the terminal' may be pre-stored in the terminal before performing a profile transfer. In addition, the 'Trusted CI list (700) stored in the terminal' may be obtained from the terminal manufacturer and / or eUICC manufacturer at the time necessary for performing a profile transfer.

[0229] The 'Trusted CI list (710) provided from the server' may refer to a list of eUICCs trusted by the telecommunications service provider and / or the RSP server. Alternatively, the 'Trusted CI list (710) provided from the server' may be a list of information that can be used to verify eUICCs trusted by the telecommunications service provider and / or the RSP server. More specifically, the Trusted CI by Server Info (s) included in the 'Trusted CI list (710) provided from the server' may be a) information that can identify eUICCs trusted by the telecommunications service provider and / or the RSP server, or b) certificate information that can verify eUICCs trusted by the telecommunications service provider and / or the RSP server. For example, the Trusted CI by Server Info (s) may be public key information of the top root certificate of the certificate chain of the eUICC whose reliability is to be verified. Alternatively, the Trusted CI by Server Info(s) may be the public key ID (PKID) information of the top root certificate of the certificate chain of the eUICC whose authenticity is to be verified.

[0230] The 'trusted CI list provided from the server (710)' may be information generated and / or provided by a telecommunications service provider and / or an RSP server.

[0231] The 'trusted CI list provided by the server (710)' may be stored in the terminal before performing profile transfer. In addition, the 'trusted CI list provided by the server (1650)' may be obtained from the telecommunications service provider and / or RSP server at the time necessary for performing profile transfer.

[0232] FIG. 8 is a diagram illustrating a procedure for transmitting a profile from one terminal to another terminal according to an embodiment of the present disclosure.

[0233] Although not shown in FIG. 8, the first terminal (800) and the second terminal (810) may each include an eUICC and an LPA internally, as shown in FIG. 1. Although not shown in FIG. 8, the first terminal (800) may have a 'profile transfer setting'. According to various embodiments, the 'profile transfer setting' is a policy regarding whether a profile can be transferred between devices, and may have been created by a telecommunications service provider, an RSP server, or through collaboration between the telecommunications service provider and the RSP server as mentioned above. According to various embodiments, the 'profile transfer setting' within the terminal may be updated by the telecommunications service provider, the RSP server, or collaboration between the telecommunications service provider and the RSP server. Alternatively, at least one of the telecommunications service provider and the RSP server and the terminal may collaborate to update the 'profile transfer setting'. The timing and / or method for updating the 'profile transfer setting' may be determined by policies of the telecommunications service provider, the RSP server, the terminal manufacturer, etc.

[0234] The 'Profile Migration Setting' may include an argument (or indication) indicating whether the transfer of the profile between devices is permitted. In addition, the 'Profile Migration Setting' may optionally further include an argument specifying under what conditions the transfer is permitted if the transfer of the profile between devices is permitted. For example, whether the terminal transmitting the profile must perform authentication using information transmitted from the telecommunications service provider and / or RSP server (e.g., a trusted CI list provided by the server as shown in FIG. 7) when authenticating the terminal receiving the profile may also be included in the 'Profile Migration Setting'. That is, the telecommunications service provider and / or RSP server may provide authentication information related to terminals and / or eUICCs that they can trust and / or verify, and the terminal transmitting the profile may be required to authenticate whether the terminal and / or eUICC receiving the profile is a terminal and / or eUICC that the telecommunications service provider and / or RSP server trusts using the aforementioned provided authentication information.

[0235] In addition, the 'profile transfer setting' may further include at least one signature information generated based on (or using) information indicating whether device-to-device transfer of the corresponding profile is permitted and / or information regarding under what conditions transfer is permitted if device-to-device transfer of the corresponding profile is permitted. The at least one signature information may be information generated by at least one entity among the RSP server, the communication service provider, the terminal manufacturer, the eUICC, and the eUICC manufacturer, for example. In addition, the at least one signature information may further include authentication information for at least one (i.e., part or all) of the RSP server, the communication service provider, the terminal manufacturer, the eUICC, and the eUICC manufacturer, for example. In addition, the 'profile transfer setting' may further include signature information of the RSP server for at least one (i.e., part or all) of the at least one authentication information included above.

[0236] Referring to FIG. 8, in step 8000, a profile to be transmitted may be selected (or determined). The process of selecting or determining a profile to be transmitted may be performed through a process in which a user directly selects a profile through a UI (user interface) provided by the first terminal (800), or may be input to the first terminal (800) through a push input from a remote server, or the first terminal (800) may access a remote server and read the corresponding information. When the first terminal (800) provides a UI to the user, a list of all profiles installed in the terminal may be provided through the provided UI, or only a list of profiles that are currently movable may be provided. When a list of profiles that are currently not movable is provided, information indicating the movability of the profiles shown in the list may be additionally provided in the UI. In addition to the list of profiles described above, information such as profile information or profile movement policies may be selectively provided through the UI. The UI displayed on the first terminal (800) may also be shown to the user through the UI of the second terminal (810).

[0237] In step 8000, the first terminal (800) can check the 'profile movement setting' to check (or identify) whether the profile can be moved. Based on the result of the confirmation or identification of whether the profile can be moved for the profile selected (or determined) to be transmitted, the first terminal (800) can perform a procedure for transmitting the selected (or determined) profile to the second terminal (810). For example, the first terminal (800) can perform step 8010 based on the result of the confirmation or identification of whether the profile can be moved. In addition, the first terminal (800) can check the 'profile movement setting' to check whether authentication should be performed using information transmitted from a telecommunications service provider and / or an RSP server (for example, a trusted CI list provided from the server illustrated in FIG. 7) when authenticating the second terminal (850) later.

[0238] At step 8010, a connection may be created between the first terminal (800) and the second terminal (850). Alternatively, the connection between the first terminal (800) and the second terminal (850) may already be created before performing step 8000. For example, the connection between the first terminal (800) and the second terminal (850) may be a wireless communication connection. The connection between the first terminal (800) and the second terminal (850) may be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE device-to-device (D2D), 5G D2D) or a long-distance connection in which a remote server (e.g., a relay server) is located between the first terminal (800) and the second terminal (850).

[0239] At step 8020, the second terminal (810) can transmit its eUICC information (e.g., eUICC2.Info1). eUICC2.Info1 can include any string generated by the eUICC of the second terminal (e.g., eUICC2.Challenge). eUICC2.Info1 can include information(s) on the version supported by the eUICC of the second terminal. eUICC2.Info1 can include 'certificate information(s) that can be used to verify the eUICC of the second terminal'(s). eUICC2.Info1 can include 'certificate information(s) that can be used to verify the eUICC of another terminal'(s).

[0240] At step 8030, the first terminal (800) can check the received eUICC2.Info1. The first terminal (800) can use the received eUICC2.Info1 to check whether there is a version that it supports among the eUICC versions supported by the second terminal. The first terminal (800) can use the received eUICC2.Info1 to select a certificate eUICC1.Cert that can verify itself. The first terminal (800) can use the received eUICC2.Info1 to select certificate information to be used by the second terminal (810).

[0241] At this time, the detailed process for selecting certificate information to be used by the second terminal (810) using the eUICC2.Info1 received by the first terminal (800) is as follows. Of course, it is not limited to the example below.

[0242] The first terminal (800) may have a 'trusted CI list stored in the terminal' described in FIG. 7. In addition, the first terminal (800) may have a 'trusted CI list provided from the server' described in FIG. 7. The first terminal (800) may derive a 'trusted CI list' using the 'trusted CI list stored in the terminal' and the 'trusted CI list provided from the server'. The 'trusted CI list' may be a) the same as the 'trusted CI list stored in the terminal'. b) the 'trusted CI list' may be the same as the 'trusted CI list provided from the server'. c) the 'trusted CI list' may be an intersection of the 'trusted CI list stored in the terminal' and the 'trusted CI list provided from the server'. Alternatively, d) the 'trusted CI list' may be a union of the 'trusted CI list stored in the terminal' and the 'trusted CI list provided from the server'.

[0243] Which of the methods mentioned in a) to d) above will be used may be determined by the policy of at least one entity among the RSP server, the telecommunications carrier, the terminal manufacturer, and the eUICC manufacturer. In addition, if the 'Profile Migration Settings' is set to 'Authentication must be performed using information transmitted from the telecommunications carrier and / or the RSP server,' a 'trusted CI list provided by the server' may have to be used, as in methods b) to d).

[0244] The first terminal (800) can check whether there is an intersection between the derived 'trusted CI list' and the 'certificate information(s) that can be used to verify the eUICC of the second terminal' included in eUICC2.Info1. The first terminal (800) can select some or all of the information that exists in the intersection of the 'trusted CI list' and the 'certificate information(s) that can be used to verify the eUICC of the second terminal' included in eUICC2.Info1, and set the selected information as certificate information to be used by the second terminal (850).

[0245] At step 8030, the first terminal (800) can generate “first terminal authentication information (Device1.Auth).” The “first terminal authentication information (Device1.Auth)” can include part or all of eUICC2.Info1. For example, the “first terminal authentication information (Device1.Auth)” can include eUICC2.Challenge that the first terminal (800) received. The first terminal authentication information (Device1.Auth) can include an arbitrary string (eUICC1.Challenge) generated by the eUICC of the first terminal.

[0246] “First terminal authentication information (Device1.Auth)” may include certificate information to be used by the second terminal (810). “First terminal authentication information (Device1.Auth)” may include a certificate eUICC1.Cert that can verify the first terminal (800) itself and related certificate chain information.

[0247] Part or all of the “first terminal authentication information (Device1.Auth)” described above may be electronically signed using the certificate eUICC1.Cert of the first terminal, and this electronically signed data may be included as part of the “first terminal authentication information (Device1.Auth).”

[0248] At step 8040, the first terminal (800) can transmit “first terminal authentication information (Device1.Auth)” to the second terminal (850).

[0249] In step 8050, the second terminal (850) can verify the received “first terminal authentication information (Device1.Auth)”. The second terminal (810) can check the validity of eUICC1.Cert included in the “first terminal authentication information (Device1.Auth)” and further check the validity of the signature included in the “first terminal authentication information (Device1.Auth)” using eUICC1.Cert. The second terminal (810) can check whether the value of eUICC2.Challege included in the “first terminal authentication information (Device1.Auth)” is identical to the value of eUICC2.Challenge transmitted by the second terminal (810) in step 8020. For example, if eUICC1.Cert is valid, the signature included in the “first terminal authentication information (Device1.Auth)” is valid, and the values ​​of eUICC2.Challenge are identical, verification can be successful.

[0250] Based on the verification result (e.g., if verification is successful), the second terminal (810) can generate “second terminal authentication information (Device2.Auth).” The “second terminal authentication information (Device2.Auth)” can include part or all of Device1.Auth. For example, the second terminal authentication information (Device2.Auth) may include the eUICC1.Challenge received by the second terminal (810). The second terminal authentication information (Device2.Auth) may include eUICC2.Info2, which is information for checking the eligibility of the eUICC installed in the second terminal. The eUICC2.Info2 may be information used to determine whether a profile to be received from the first terminal (800) in the future can be normally installed and operated in the eUICC of the second terminal (850). For example, the eUICC2.Info2 may include hardware and / or software information of the eUICC installed in the second terminal (810). The second terminal authentication information (Device2.Auth) may include a certificate eUICC2.Cert capable of verifying the second terminal (810) itself and related certificate chain information.

[0251] Part or all of the “second terminal authentication information (Device2.Auth)” described above may be electronically signed using the certificate eUICC2.Cert of the second terminal, and this electronically signed data may be included as part of the “second terminal authentication information (Device2.Auth).”

[0252] At step 8060, the second terminal (810) can transmit “second terminal authentication information (Device2.Auth)” to the first terminal (800).

[0253] At step 8070, the first terminal (800) can verify the received “second terminal authentication information (Device2.Auth)”. The first terminal (800) can check the validity of eUICC2.Cert included in the “second terminal authentication information (Device2.Auth)” and can check the validity of the signature included in the “second terminal authentication information (Device2.Auth)” using eUICC2.Cert. The first terminal (800) can check whether the value of eUICC1.Challege included in the “second terminal authentication information (Device2.Auth)” is identical to the value of eUICC1.Challenge transmitted by the first terminal (800) at step 8030. For example, if eUICC2.Cert is valid, the signature included in the “second terminal authentication information (Device2.Auth)” is valid, and the values ​​of eUICC1.Challenge are identical, verification can be successful.

[0254] Based on the verification result (for example, if verification is successful), the first terminal (800) can determine whether the profile to be transmitted by the first terminal (800) itself can be normally installed and operated in the eUICC of the second terminal (850) by checking the information eUICC2.Info2 for eligibility check of the eUICC included in the “second terminal authentication information (Device2.Auth)”.

[0255] Based on the judgment result of step 8070, the first terminal (800) for transmitting the profile package (EPP) and the second terminal (810) can complete mutual authentication.

[0256] After completing mutual authentication, data encrypted with a session key can be transmitted and received between the first terminal (800) and the second terminal (810) at a specific point in time. For example, the encrypted data may be an encrypted profile package. The eUICC_T of the second terminal (810) may decrypt the session key and install the corresponding encrypted profile package.

[0257] A session key can be generated by exchanging one-time public keys among ephemeral key pairs generated by the eUICC_S and eUICC_T of the first terminal (800) and the second terminal (810) for the purpose of key agreement, and using the one-time private key generated by the first terminal (800) and the one-time public key received as input. For example, in step 8060, the eUICC_T of the second terminal (810) generates an ephemeral key pair and transmits a one-time public key among them, and if the eUICC_S of the first terminal (800) that received the one-time public key performs step 8070 and the verification of the second terminal (810) is successful, the eUICC_S of the first terminal (800) may generate an ephemeral key pair and include the one-time public key among them in the information for channel initialization of the EPP and transmit it at step 8080. The eUICC_T of the second terminal (801) may generate a session key using the one-time public key of the eUICC_S and the one-time private key generated previously as inputs and decrypt the received EPP to process the installation.

[0258] FIG. 9 is a diagram illustrating a configuration of a terminal according to some embodiments of the present disclosure.

[0259] Referring to FIG. 9, the terminal may include a transceiver (920), a processor (910), and a memory (930). Additionally, the terminal may further include an eUICC (not shown). The terminals described in this disclosure may correspond to the terminal described in FIG. 9. For example, the first terminal and the second terminal described in FIGS. 1 to 8 may each include the configuration of the terminal described in FIG. 9.

[0260] However, the configuration of the terminal is not limited to FIG. 9, and may include more or fewer components than those illustrated in FIG. 9. According to some embodiments, the transceiver (920), processor (910), memory (930), and eUICC may be implemented in the form of a single chip. In addition, the processor (920) may be configured as at least one processor.

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

[0262] Meanwhile, the processor (910) is a component for overall control of the terminal. The processor (910) can control the overall operation of the terminal according to various embodiments of the present disclosure as described above. The processor (910) may include the LPA illustrated in FIG. 1 as a control application of the eUICC.

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

[0264] An eUICC (not shown) may include a transceiver, a processor, and a memory. The ISD-R application of the eUICC is a system application of the eUICC (e.g., a part of the OS or a system application existing on the OS), and may receive commands from the LPA through the transceiver, interpret the received commands, and transmit them to the processor of the eUICC so that the processor can perform profile management operations such as profile installation and deletion on the eUICC. In addition, the ISD-R application of the eUICC may perform the role of receiving the processing result from the eUICC and replying to the LPA through the transceiver. In addition, the processor of the eUICC may determine whether the profile status has changed from the profile metadata using the profile status information and the profile authority information, and may also generate a deletion processing result message when processing profile deletion. The eUICC may store in memory metadata information of the profile and some or all of the metadata as additional information, such as status information of the profile and information on whether the profile is an EPP, and the processor may access the memory to obtain one of the above-described pieces of information and use it as predetermined information necessary to perform at least one operation, such as changing the profile status, notifying a deletion message, or performing deletion processing.

[0265] FIG. 10 is a diagram illustrating a configuration of a server according to some embodiments of the present disclosure.

[0266] Referring to FIG. 10, the server may include a transceiver (1020), a processor (1010), and a memory (1030). The servers described above in the present disclosure may each correspond to the server described in FIG. 10. For example, the servers described in FIGS. 1 to 8 (e.g., a business server, an RSP server, an SM-DP+, or an SM-DS) may each include the configuration of the server described in FIG. 10.

[0267] However, the configuration of the server is not limited to FIG. 10, and may include more or fewer components than those illustrated in FIG. 10. According to some embodiments, the transceiver (1020), the processor (1010), and the memory (1030) may be implemented in the form of a single chip. In addition, the processor (1010) may be configured as at least one processor.

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

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

[0270] Meanwhile, the server may further include a memory (1030) and may store data such as basic programs for server operation, application programs, and setting information for device changes. In addition, the memory (1030) may include at least one storage medium among a Flash Memory Type, a Hard Disk Type, a Multimedia Card Micro Type, a card-type memory (e.g., SD or XD memory, etc.), a magnetic memory, a magnetic disk, an optical disk, a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a Read-Only Memory (ROM), a Programmable Read-Only Memory (PROM), and an Electrically Erasable Programmable Read-Only Memory (EEPROM). In addition, the processor (1010) may perform various operations using various programs, contents, data, etc. stored in the memory.

[0271] The server can receive a profile deletion message through the transceiver (1020), transmit it to the processor (1010), and verify the eUICC signature in the processor (1010). In addition, the server can check the profile information included in the received data (e.g., whether the ICCID is mapped to the EID corresponding to the ICCID stored in the memory (not shown)) to determine whether there is an abnormality, and transmit the verification result to the business operator through the transceiver (1020). In addition, the server can receive a status change message of the first profile through the transceiver (1020), receive a status restoration request message of the first profile, and store the profile status in the memory. In addition, the server can perform at least one of the following operations: determining whether a profile is state-recoverable through a processor (1010), and, if it is a state-recoverable profile, generating a message including an indicator for restoration processing, signing the message with a key of the profile server, and replying the message including the signature of the profile server to the first terminal through a transceiver (1020).

[0272] In the specific embodiments of the present disclosure described above, components included in the disclosure are expressed in the singular or plural form, depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for convenience of explanation, and the present disclosure is not limited to singular or plural components. Components expressed in the plural form may be composed of singular elements, or components expressed in the singular form may be composed of plural elements.

[0273] While the detailed description of this disclosure has described specific embodiments, it should be understood that various modifications are possible without departing from the scope of this disclosure. Therefore, the scope of this disclosure should not be limited to the described embodiments, but should be defined not only by the scope of the claims described below, but also by equivalents thereof.

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

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

[0276] Various embodiments of the present disclosure may be implemented as software (e.g., a program) including instructions stored in a machine-readable storage medium (e.g., an internal memory or an external memory) that can be read by a machine (e.g., a computer). The device is a device that can call instructions stored in the storage medium and perform operations according to the called instructions, and may include a terminal according to various embodiments. When the instructions are executed by a processor (e.g., the processor 910 of FIG. 9), the processor may directly, or under the control of the processor, perform a function corresponding to the instructions using other components. The instructions may include code generated or executed by a compiler or an interpreter.

[0277] A device-readable storage medium may be provided in the form of a non-transitory storage medium. Here, "non-transitory" simply means that the storage medium does not contain signals and is tangible, but does not distinguish between whether data is stored semi-permanently or temporarily on the storage medium.

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

Claims

1. A method performed by a first terminal in a wireless communication system, A step of transmitting a profile package generated based on the profile of the first terminal to a second terminal; If the movement of the above profile package to the second terminal is canceled, a step of receiving a message including information related to the deletion of the above profile package; A step of performing verification on information related to the deletion of the above profile package; and A method comprising a step of changing the status of the profile of the first terminal.

2. In paragraph 1, A method wherein information related to the deletion of the profile package includes at least one of information on the result of deleting the profile package, an identifier of the profile package, or information on an eUICC (embedded universal integrated circuit card) certificate of the second terminal.

3. In paragraph 1, A method wherein information related to deletion of the profile package includes at least one of an identifier of the profile package or information regarding an eUICC of the second terminal.

4. In paragraph 1, A method in which, if the above verification is successful, the status of the profile of the first terminal is changed to an active status.

5. A method performed by a second terminal in a wireless communication system, A step of receiving, from a first terminal, a profile package generated based on the profile of the first terminal; and If the movement of the above profile package to the second terminal is canceled, the step of deleting the profile package and generating information related to the deletion of the profile package is included. A method wherein the status of the profile of the first terminal is based on information related to deletion of the profile package.

6. In the fifth paragraph, the method, Further comprising a step of transmitting information related to the deletion of the profile package to the profile server, A method wherein information related to the deletion of the profile package includes at least one of information on the result of deleting the profile package, an identifier of the profile package, or information on an eUICC (embedded universal integrated circuit card) certificate of the second terminal.

7. In the fifth paragraph, the method, Further comprising a step of transmitting information related to deletion of the profile package to the first terminal, A method wherein information related to deletion of the profile package includes at least one of an identifier of the profile package or information regarding an eUICC of the second terminal.

8. In paragraph 5, A method wherein, if verification of information related to deletion of the above profile package is successful, the status of the profile of the first terminal is changed to an active status.

9. In the first terminal of the wireless communication system, Transmitter and receiver; and At least one control unit connected to the above transceiver unit, At least one control unit: To the second terminal, transmit a profile package generated based on the profile of the first terminal, If the movement of the above profile package to the second terminal is canceled, a message containing information related to the deletion of the above profile package is received, Perform verification of information related to the deletion of the above profile package, and A first terminal configured to change the status of the profile of the first terminal.

10. In paragraph 9, A first terminal, wherein information related to the deletion of the profile package includes at least one of information on the result of the deletion of the profile package, an identifier of the profile package, or information on an eUICC (embedded universal integrated circuit card) certificate of the second terminal.

11. In paragraph 9, A first terminal, wherein information related to deletion of the profile package includes at least one of an identifier of the profile package or information regarding an eUICC of the second terminal.

12. In paragraph 9, A first terminal, wherein if the above verification is successful, the status of the profile of the first terminal is changed to an active state.

13. In the second terminal of the wireless communication system, Transmitter and receiver; and At least one control unit connected to the above transceiver unit, At least one control unit: Receive, from a first terminal, a profile package generated based on the profile of the first terminal, and If the movement of the above profile package to the second terminal is canceled, the above profile package is set to be deleted and information related to the deletion of the above profile package is generated. A second terminal, wherein the status of the profile of the first terminal is based on information related to the deletion of the profile package.

14. In the 13th paragraph, the at least one control unit: It is further configured to transmit information related to the deletion of the above profile package to the profile server, A second terminal, wherein information related to the deletion of the profile package includes at least one of information on the result of the deletion of the profile package, an identifier of the profile package, or information on an eUICC (embedded universal integrated circuit card) certificate of the second terminal.

15. In the 13th paragraph, the at least one control unit: It is further set to transmit information related to the deletion of the profile package to the above first terminal, A second terminal, wherein information related to the deletion of the profile package includes at least one of an identifier of the profile package or information regarding the eUICC of the second terminal.

Images