Method and apparatus for providing inter-device profile transmission in terminal supporting extended storage

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data transmission rates. The present disclosure relates to a method and an apparatus for providing inter-device profile transmission in a terminal supporting Extended Storage.

Description

Method and device for providing profile transfer between devices in an EXTENDED STORAGE-supported terminal

[0001] The present disclosure relates to a wireless communication system or a mobile communication system. Specifically, it relates to a method and apparatus for transferring subscription information between devices, and more specifically, to a method and apparatus for supporting profile transfer between devices from an Extended Storage-supported terminal to another terminal.

[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 frequency bands below 6 GHz ('Sub 6 GHz'), such as 3.5 gigahertz (3.5 GHz), but also in ultra-high frequency bands called millimeter waves (mmWave), such as 28 GHz and 39 GHz ('Above 6 GHz'). In addition, for 6G mobile communication technology, which is referred to as a system beyond 5G, implementation in the terahertz (THX) band (e.g., the 3 terahertz band at 95 GHz) is being considered to achieve transmission speeds 50 times faster and ultra-low latency reduced to one-tenth compared to 5G mobile communication technology.

[0003] In the early stages of 5G mobile communication technology, aiming to satisfy service support and performance requirements for enhanced Mobile BroadBand (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), technologies such as beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands, support for various numerologies (such as the operation of multiple subcarrier spacings) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources, initial access techniques to support multi-beam transmission and broadband, definition and operation of Band-Width Parts (BWP), Low Density Parity Check (LDPC) codes for high-volume data transmission, new channel coding methods such as Polar Codes for the reliable transmission of control information, and L2 pre-processing (L2 Standardization has been carried out for pre-processing, network slicing which provides a dedicated network specialized for specific services, and other methods.

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

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

[0006] When such 5G mobile communication systems are commercialized, connected devices, which are increasing explosively, will be connected to communication networks. Accordingly, it is expected that there will be a need to enhance the functionality and performance of 5G mobile communication systems and to integrate the operation of connected devices. To this end, new research is planned to be conducted on 5G performance improvement and complexity reduction, support for AI services, support for metaverse services, and drone communication using eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] Furthermore, the advancement of these 5G mobile communication systems encompasses multi-antenna transmission technologies such as new waveforms to guarantee coverage in the terahertz band of 6G mobile communication technology, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas; metamaterial-based lenses and antennas to improve terahertz band signal coverage; high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum); and Reconfigurable Intelligent Surface (RIS) technology; as well as Full Duplex technology for enhancing frequency efficiency and system networks in 6G mobile communication technology; AI-based communication technologies that realize system optimization by utilizing satellites and AI from the design stage and internalizing end-to-end AI support functions; and the realization of services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could serve as a foundation for the development of next-generation distributed computing technologies.

[0008] The present disclosure aims to provide a method and apparatus for moving profiles between devices in a wireless communication system or a mobile communication system, based on whether the profile(s) selected by the user to move are profile(s) extracted into memory outside the eUICC (embedded UICC (universal integrated circuit card)).

[0009] The technical problems to be solved by the present invention are not limited to those mentioned above, and other unmentioned technical problems may be considered by those skilled in the art from the various embodiments of the present disclosure described below.

[0010] A method according to one embodiment of the present disclosure for solving the above-mentioned problems is a method for moving a profile from a first terminal to a second terminal in a wireless communication system, and may include the steps of: the first terminal checking the available memory capacity of the eUICC of the second terminal from the second terminal; the first terminal checking the number of profiles that can be moved (possible) to the second terminal; checking the storage location of the profiles selected to be moved from the first terminal to the second terminal; if the first terminal determines that the selected profile is a profile stored in memory outside the eUICC, additionally processing a restoration reinstallation to the eUICC; and the first terminal processing the profile transfer to the second terminal.

[0011] A method performed by a first terminal of a wireless communication system according to an embodiment of the present disclosure for solving the above-mentioned problems may include: a step of determining whether at least one profile among one or more profiles to be moved from the first terminal to a second terminal is stored in an external storage unit of an eUICC (embedded UICC (universal integrated circuit card)) of the first terminal; a step of reinstalling the at least one profile in the eUICC if the at least one profile is stored in the external storage unit of the eUICC of the first terminal; and a step of transmitting the reinstalled at least one profile to the second terminal.

[0012] According to an embodiment, the reinstallation step may include: transmitting to the second terminal a profile among the profiles installed in the eUICC that is to be moved to the second terminal; transmitting to the eUICC a message requesting that the profile moved to the second terminal be deleted from the eUICC; and identifying whether there is available memory in the eUICC for reinstalling the at least one profile when the at least one profile is stored in the external storage of the eUICC of the first terminal.

[0013] According to an embodiment, the reinstallation step may further include: transmitting a message to the eUICC requesting that a profile installed in the eUICC that is not to be moved to the second terminal be moved to the external storage unit of the eUICC; and receiving a message from the eUICC containing information about the result of moving the profile not to be moved to the second terminal to the external storage unit of the eUICC.

[0014] According to an embodiment, the reinstallation step may further include: sending a message to the eUICC requesting that a profile installed in the eUICC that will not be moved to the second terminal be deleted from the eUICC; and receiving a message from the eUICC containing information about the result of deleting the profile that will not be moved to the second terminal from the eUICC.

[0015] According to an embodiment, the method may further include the step of transmitting the one or more profiles to be moved from the first terminal to the second terminal to the second terminal when the at least one profile is not stored in the external storage of the eUICC of the first terminal.

[0016] According to an embodiment, the method may further include the step of identifying whether there is available memory in the eUICC to reinstall the at least one profile when the at least one profile is stored in an external storage unit of the eUICC of the first terminal.

[0017] According to an embodiment, the method may further include a step of determining whether one or more profiles to be moved from the first terminal to the second terminal are transferable to the second terminal based on information regarding the available eUICC memory of the second terminal.

[0018] According to an embodiment, the method may further include the step of identifying information regarding a profile to be moved to the second terminal among the one or more profiles when the one or more profiles to be moved from the first terminal to the second terminal are not transferable to the second terminal.

[0019] A first terminal of a wireless communication system according to an embodiment of the present disclosure for solving the above-mentioned problems may include: a transceiver; and a control unit connected to the transceiver, which determines whether at least one profile among one or more profiles to be moved from the first terminal to a second terminal is stored in an external storage unit of an eUICC (embedded UICC (universal integrated circuit card)) of the first terminal, and if the at least one profile is stored in the external storage unit of the eUICC of the first terminal, reinstalls the at least one profile in the eUICC and transmits the reinstalled at least one profile to the second terminal.

[0020] One embodiment of the present invention can provide a device and a method capable of effectively providing services in a mobile communication system.

[0021] According to one embodiment of the present invention, when a user wishes to move a profile between devices in a wireless communication system or a mobile communication system, a method and apparatus for providing a move between devices may be provided based on whether the profile(s) selected by the user to move are profile(s) extracted into memory outside the eUICC (embedded UICC (universal integrated circuit card)).

[0022] The effects obtainable in the present disclosure are not limited to those mentioned in the various embodiments, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure pertains from the description below.

[0023] FIG. 1 is a diagram illustrating an example of a method in which two terminals interact to transmit a profile between two terminals according to one embodiment of the present disclosure.

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

[0025] FIG. 3 is a diagram illustrating a procedure for providing profile transfer from one terminal to another terminal according to one embodiment of the present disclosure.

[0026] FIG. 4 is a drawing illustrating a method for entering a profile transfer procedure between devices according to one embodiment of the present disclosure.

[0027] FIG. 5 is a diagram illustrating a method for handling inter-device transfer when Extended Storage is supported at a first terminal according to an embodiment of the present disclosure.

[0028] FIG. 6 is a diagram illustrating a procedure for moving after securing memory within the eUICC in a first terminal according to an embodiment of the present disclosure and reinstalling it.

[0029] FIG. 7 is a diagram illustrating a profile extraction procedure from a first terminal to an outside eUICC according to one embodiment of the present disclosure.

[0030] FIG. 8 is a drawing illustrating the configuration of a terminal according to one embodiment of the present disclosure.

[0031] FIG. 9 is a drawing illustrating the configuration of a server according to one embodiment of the present disclosure.

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

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

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

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

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

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

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

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

[0040] Furthermore, although the present disclosure describes each embodiment using an eSIM (embedded subscriber identity module) as an example of a security medium, the scope of the rights of the present disclosure is not limited to SSPs. For example, it is obvious to those skilled in the art that the various embodiments described below can be applied substantially identically or similarly to other security media that perform functions substantially identical or similar to those of an eSIM.

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

[0042] Efforts are being made to develop improved 5G or pre-5G communication systems to meet the increasing demand for wireless data traffic since the commercialization of 4G communication systems. For this reason, 5G or pre-5G communication systems are referred to as Beyond 4G Network communication systems or Post-LTE systems. To achieve high data transmission rates, the implementation of 5G communication systems in the mmWave band (e.g., the 60 GHz band) is being considered. To mitigate path loss and increase transmission distance in the mmWave band, technologies such as beamforming, massive MIMO, full Dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and large-scale antennas are being discussed for 5G communication systems. In addition, to improve the network of the system, technologies such as advanced small cell, advanced small cell, cloud radio access network (cloud RAN), ultra-dense network, Device to Device communication (D2D), wireless backhaul, moving network, cooperative communication, Coordinated Multi-Points (CoMP), 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.

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

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

[0045] As mentioned above, with the advancement of mobile communication systems enabling the provision of various services, measures to effectively provide these services are required. For example, when a profile (or profile package) is transferred between two devices, a method for mutual authentication between the two devices is required.

[0046] According to various embodiments of the present disclosure, two devices can authenticate each other, and after authentication is completed, they can provide information to a telecommunications operator to determine whether a profile installed on one device has been transmitted and installed on another device in a safe and efficient manner.

[0047] In addition, according to various embodiments of the present disclosure, device 1 (terminal 1) that transmits a profile checks the storage location of the profile to be moved before providing the profile transmission, and proceeds with recovery and reinstallation on an eUICC (embedded UICC (universal integrated circuit card)), and then proceeds with transmission to another device in a safe and efficient manner, so that device 2 (terminal 2) that receives the profile can reinstall the profile on the eUICC and use it.

[0048] Additionally, according to various embodiments of the present disclosure, terminal 1 may indicate to the terminal user the number of movable profiles and allow the terminal user to select among them the profiles to move. To this end, terminal 1 may collect at least one piece of information among the available memory of eUICC 2 collected from terminal 2 and / or information of profile(s) installed on eUICC 1 and use it for a decision. The information of profile(s) installed on eUICC 1 may be at least one of information such as data capacity, the download time of said profile, whether the profile supports device change, and whether the profile allows extended storage.

[0049] Accordingly, according to various embodiments of the present disclosure, a terminal user can move the profile(s) they wish to move from terminal 1 to terminal 2, the terminal user can reinstall the moved profile(s) as the eUICC of terminal 2, and the terminal user can activate the profile(s) to receive network services at terminal 2.

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

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

[0052] A "UICC (Universal Integrated Circuit Card)" is a smart card inserted into mobile communication terminals and is also referred to as a UICC card. A UICC may include a connection control module for connecting to a mobile carrier's network. Examples of connection control modules include USIM (Universal Subscriber Identity Module), SIM (Subscriber Identity Module), and ISIM (IP Multimedia Service Identity Module). A UICC containing a USIM is commonly referred to as a USIM card. Similarly, a UICC containing a SIM module is commonly referred to as a SIM card. Meanwhile, the SIM module is either installed during the manufacturing of the UICC or allows the user to download the SIM module of the mobile communication service they wish to use onto the UICC card at a time of their choice. Additionally, multiple SIM modules may be downloaded and installed on the UICC card, and at least one of them may be selected and used. Such a UICC card may or may not be fixed to the terminal. A UICC that is fixed to the terminal can be 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 in which these two processors are integrated is also referred to as an iUICC (Integrated UICC). Typically, eUICC and iUICC may refer to a UICC card that is fixedly used in a terminal and includes a function that allows at least one SIM module to be downloaded to the UICC card remotely and one of the downloaded SIM modules to be selected.In this disclosure, a UICC card comprising a function that allows at least one SIM module to be downloaded and selected remotely is collectively referred to as an eUICC or an iUICC. For example, among UICC cards comprising a function that allows a SIM module to be downloaded and selected remotely, a UICC card that is fixed to or not fixed to a terminal is collectively referred to as an eUICC or an iUICC. In this disclosure, the term UICC may be used interchangeably with SIM, and the term eUICC may be used interchangeably with eSIM.

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

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

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

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

[0057] In this disclosure, "profile image" may refer to binary data of a profile package installed within a UICC. The "profile image" may be named Profile TLV or Profile Image TLV. If the profile image is encrypted using encryption parameters, it may be named PPI or Protected Profile Image TLV (PPI TLV). If the profile image is encrypted using encryption parameters that can be decrypted only by a specific eUICC, it may be named BPI or Bundled Profile Image TLV (BPI TLV). A Profile Image TLV may be a data set that represents information constituting a profile in TLV format. It should be noted that in this disclosure, where it is determined that no special distinction is necessary for the invention, the "profile image" is collectively referred to as a profile package. Accordingly, in this disclosure, "EPP (Exported Profile Package)" may be a profile image generated from a first installed profile.

[0058] In this disclosure, the EPP is also a profile package generated from a first profile for device modification, as described below in the drawings, and may be composed of the same or partial data set as the first profile. For example, some data may be data from the initial installation of the first profile on the first terminal. In this case, if the EPP is composed of partial data of the first profile, one embodiment of this disclosure may include a process in which the second terminal receives and / or combines additional information (e.g., update information of the first profile generated after the initial installation of the first profile) through the first terminal and / or profile server to restore the attributes of the first profile. In this disclosure, to avoid obscuring the gist of the invention, cases where it is composed of partial or all data of the first profile may be collectively referred to as EPP without distinction.

[0059] In the present disclosure, the External Storage Profile Package (ESPP) is also a profile package generated from a first profile for transfer to External Storage, as described below in the drawings, and may be composed of the same or a partial data set as the first profile. The profile package may be composed of only a portion of files excluding sensitive data files (e.g., network access credentials, etc.) and may be composed in the form of binary data. The profile package (ESPP) to be exported externally may be encrypted with an encryption key so that it can be decrypted only by an eUICC having the same eUICC identifier (EID).

[0060] In the present disclosure, the "state" of a profile may mean one of the following profile states defined in the SGP.22 standard defined by GSMA. In Figure 2, which will be described later in the present disclosure, an Unusable state is additionally presented in addition to the currently defined profile "state," and a detailed explanation thereof will be provided later in Figure 2.

[0061] [Enable]

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

[0063] [Disable]

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

[0065] [Delete]

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

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

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

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

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

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

[0072] In the present disclosure, the "profile server" may include functions for creating a profile, encrypting a created profile, creating a profile remote management command, or encrypting a created profile remote management command. For example, the profile server may be represented as SM-DP (Subscription Manager Data Preparation), SM-DP+ (Subscription Manager Data Preparation plus), an off-card entity of Profile Domain, a profile encryption server, a profile creation server, a profile provisioner (PP), a profile provider, or a PPC holder (Profile Provisioning Credentials holder).

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

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

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

[0076] "Mobile service provider" may refer to a business entity that provides communication services to a terminal, 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. Furthermore, in this disclosure, the mobile service provider is not limited to representing a single specific business entity providing communication services, but may also be used as a term referring to a group or association or consortium of one or more business entities, or a representative representing said group or consortium. Additionally, in this disclosure, the mobile service provider may be named 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 provider may set or be assigned at least one name and / or unique identifier (object identifier, OID). If a telecommunications operator refers to a group or association of one or more businesses or an agency, the name or unique identifier of any group or association or agency may be a name or unique identifier shared by all businesses belonging to said group or association or all businesses cooperating with said agency.

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

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

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

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

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

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

[0083] "Event" may be used for the following purposes in this disclosure. Of course, it is not limited to the examples below.

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

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

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

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

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

[0089] A "Certificate" or "Digital Certificate" may represent a digital certificate used for asymmetric key-based mutual authentication consisting of a pair of a public key (PK) and a secret key (SK). Each certificate may include one or more public keys (PKs), a public key identifier (PKID) corresponding to each public key, a certificate issuer ID (Certificate Issuer ID) of the certificate issuer (CI) that issued the certificate, and a digital signature. For example, the certificate issuer may be referred to as 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 containing the public key, or a part of a specific public key or a part of a certificate containing the public key, or a result of an operation (e.g., hash) of a specific public key or a result of an operation (e.g., hash) of a certificate containing the public key, or a result of an operation (e.g., hash) of a part of a specific public key or a result of an operation (e.g., hash) of a part of a certificate containing the public key, or a storage space where data is stored.

[0090] A "Certificate Chain" or "Certificate Hierarchy" can represent the correlation between certificates when certificates issued by a "Certificate Issuer" (primary certificates) are used to issue other certificates (secondary certificates), or when secondary certificates are used to issue tertiary or higher certificates in a linked manner. For example, the CI certificate used for the initial certificate issuance 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.

[0091] In the embodiments of the present disclosure below, when the expressions "transmit data by signing" or "transmit signed data" are used, it may mean that the transmitting entity digitally signs the data to be transmitted using its private key to ensure the integrity of the data to be transmitted; that is, it means that the transmitting entity constructs and transmits a message containing the signature. For example, the expressions "transmit installation results signed by eUICC" or "transmit installation results by signing" may be interpreted to mean that eUICC transmits a message containing the installation result data and the signature in which the installation result data is signed using its private key. The receiving side can determine whether the data has been tampered with and determine its integrity by verifying it with the public key corresponding to the signed signature (e.g., the eUICC's public key).

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

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

[0094] FIG. 1 is a diagram illustrating an example of a method in which two terminals interact to transmit a profile between two terminals according to one embodiment of the present disclosure.

[0095] As illustrated in FIG. 1, a first terminal (device 1, device 1, apparatus 1) (110) and a second terminal (device 2, device 2, apparatus 2) (120) are each equipped with a first eUICC (170) and a second eUICC (190), and a profile (not shown) may be installed in each of the first eUICC (170) and the second eUICC (190). Additionally, a first LPA (160) and a second LPA (180) may be installed in each of the first terminal (100) and the second terminal (120). 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 (end user) (100) can control the profiles installed on each terminal's eUICC (e.g., the first eUICC (103) and the second eUICC (123)) through the first LPA (101) and the second LPA (121), respectively. When performing device changes, it can be assumed that the user (100) is the same user.

[0096] 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 configured) between the LPAs. The first LPA (160) and the second LPA (180) may establish a connection using information transmitted to the second LPA (180). The connection between the first LPA (160) and the second LPA (180) 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 cable) or a remote connection in which a remote server (e.g., a relay server) is located between the first LPA (160) and the second LPA (180).

[0097] A mobile service provider (150) is connected to a first RSP server (e.g., SM-DP+ 1) (130) and a second RSP server (e.g., SM-DP+ 2) (140), and the first LPA (160) of the first terminal (110) is connected to the first RSP server (130), and the second LPA (180) of the second terminal (120) is connected to the second RSP server (140). In this case, the first RSP server (130) and the second RSP server (140) may be the same or different. Also, if one or more service provider servers are 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. Additionally, for convenience, FIG. 1 illustrates a case where the first RSP server (130) and the second RSP server (140) are each 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 connection mediation servers (SM-DS) that assist in creating a connection between a specific profile server and a terminal may be included in the server configuration. Such various server configurations may be briefly indicated as a single profile server or SM-DP+ in the drawings below.

[0098] Before performing a device change to the second terminal (120), the user (100) may have subscribed to the communication service of the communication operator (150) and installed a first profile to move to the second terminal (120) on the eUICC (first eUICC) (170) of the first terminal (110).

[0099] Meanwhile, in the drawings and descriptions to be described later, _S and _T may be added to indicate the eUICC belonging to the first terminal (110) and the second terminal (120), the certificate of the eUICC belonging to the second terminal (120), or a random value generated from the terminal or eUICC. For example, if it is necessary to distinguish between the eUICC (170) of the first terminal (110) and the eUICC (190) to receive the profile to be moved, they may be distinguished in the drawings and description below as eUICC_S (e.g., the eUICC (170) in the Source terminal (110)) and eUICC_T (e.g., the eUICC (2 eUICC (190)) in the Target terminal (2 terminal (120)). Meanwhile, the first terminal (130) may have part or all of the profile encrypted and stored outside the eUICC. "Outside the eUICC" may be a memory inside the first terminal (110) or a memory connected to the outside from the first terminal (110).

[0100] This may be, for example, the memory of a cloud server or memory such as an external hard drive. In this drawing and the following description, the term is used to describe the memory within the terminal to avoid obscuring the essence of the invention, but it should be noted that this is not limited thereto.

[0101] Meanwhile, regarding the terminal's memory, it is possible to store data in either the memory connected to the LPA or the memory connected to the eUICC; however, since no special distinction is required in the invention, the case of storing data in the LPA is explained as an example, and it should be noted that the terms "stored in the LPA" and "stored in the terminal" may be used interchangeably.

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

[0103] Although not illustrated in FIG. 2, the first terminal (device 1) (200) and the second terminal (device 2) (205) may each include an eUICC and an LPA internally as illustrated in FIG. 1. Although not illustrated in FIG. 2, the first terminal (200) may possess a 'profile transfer setting'. According to various embodiments, the 'profile transfer setting' is a policy regarding whether a profile can be transferred between devices, and may be generated by a telecommunications carrier, may be generated by an RSP server, or may be generated through collaboration between the aforementioned telecommunications carrier and the RSP server. According to various embodiments, the 'profile transfer setting' within the terminal may be updated by the telecommunications carrier, the RSP server, or through collaboration between the telecommunications carrier and the RSP server. Alternatively, the terminal may collaborate with at least one of the telecommunications carrier and the RSP server to update the 'profile transfer setting'. The timing and / or method of updating 'profile migration settings' may be determined by policies of telecommunications carriers, RSP servers, terminal manufacturers, etc.

[0104] The 'Profile Transfer Setting' may include a factor (or indication) indicating whether the transfer of the profile between devices is permitted. Additionally, the 'Profile Transfer Setting' may optionally include a factor specifying the conditions under which such transfer is permitted if it is allowed. For example, the 'Profile Transfer Setting' may also include whether authentication must be performed using information received from the carrier and / or RSP server (e.g., a list of trusted CIs provided by the server) when the terminal transmitting the profile authenticates the terminal receiving the profile. That is, the carrier 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 need to authenticate whether the terminal and / or eUICC receiving the profile is a terminal and / or eUICC trusted by the carrier and / or RSP server using the aforementioned provided authentication information.

[0105] Additionally, the above 'profile transfer setting' may further include at least one signature information generated based on (or using) information indicating whether the transfer of the said profile between devices is allowed and / or information regarding under what conditions the transfer is allowed if the transfer of the said profile between devices is allowed. The at least one signature information may be information generated by, for example, at least one entity among an RSP server, a telecommunications carrier, a terminal manufacturer, an eUICC, and an eUICC manufacturer. Additionally, the at least one signature information may further include authentication information for, for example, at least one of an RSP server, a telecommunications carrier, a terminal manufacturer, an eUICC, or an eUICC manufacturer (i.e., some or all of them). Additionally, the 'profile transfer setting' may further include signature information of an RSP server for at least one of the above-mentioned at least one authentication information (i.e., some or all of them).

[0106] Referring to FIG. 2, in step 210, a profile to be transmitted from the first terminal (200) may be selected (or determined). The process of selecting or determining the profile to be transmitted may be achieved through a process in which the user directly selects the profile via a user interface (UI) provided by the first terminal (200), may be input to the first terminal (200) via a push input from a remote server, or may be achieved by the first terminal (200) connecting to a remote server and reading the relevant information. When the first terminal (200) provides a UI to the user, a list of all profiles installed on the terminal may be provided to the user through the provided UI, or only a list of profiles that are currently movable may be provided to the user. If a list of profiles that are not currently movable is provided, information indicating the movability of the profiles shown in the list may be additionally provided in the UI. In addition, through the UI, information such as profile information or profile movement policies may be optionally provided in addition to the list of profiles described above. The UI displayed on the first terminal (200) may also be shown to the user through the UI of the second terminal (205).

[0107] In step 210, the first terminal (200) can check the 'profile transfer setting' to check (or identify) whether the profile is transferable. Based on the result of checking or identifying whether the profile is transferable for the profile selected (or decided) to transfer, the first terminal (200) can perform a procedure to transfer the selected (or decided) profile to the second terminal (205). For example, the first terminal (200) can perform step 215 based on the result of checking or identifying whether the profile is transferable. Additionally, the first terminal (200) can check the 'profile transfer setting' to determine whether authentication must be performed using information received from the telecommunications carrier and / or RSP server (e.g., a trusted CI list provided by the server) when subsequently authenticating the second terminal (205).

[0108] In step 215, a connection may be established between the first terminal (200) and the second terminal (205). Alternatively, the connection between the first terminal (200) and the second terminal (205) may already be established prior to performing step 210. For example, the connection between the first terminal (200) and the second terminal (205) may be a wireless communication connection. The connection between the first terminal (200) and the second terminal (205) may be a direct device-to-device connection (e.g., NFC, Bluetooth, UWB, WiFi-Direct, LTE D2D (device-to-device), 5G D2D) or a remote connection in which a remote server (e.g., a relay server) is located between the first terminal (200) and the second terminal (205).

[0109] In step 220, the second terminal (205) may transmit its eUICC information (e.g., eUICC2.Info1) to the first terminal (200). eUICC2.Info1 may include any string (e.g., eUICC2.Challenge) generated by the eUICC of the second terminal (205). eUICC2.Info1 may include information(s) of the version supported by the eUICC of the second terminal (205). eUICC2.Info1 may include 'certificate information(s) that can be used to verify the eUICC of the second terminal (205).' eUICC2.Info1 may include 'certificate information(s) that can be used to verify the eUICC of another terminal.'

[0110] In step 225, the first terminal (200) can check the received eUICC2.Info1. The first terminal (200) can use the received eUICC2.Info1 to check whether there is a version supported by itself among the eUICC versions supported by the second terminal (205). The first terminal (200) can use the received eUICC2.Info1 to select a certificate eUICC1.Cert that can verify itself. The first terminal (200) can use the received eUICC2.Info1 to select certificate information to be used by the second terminal (205).

[0111] At this time, the detailed process for selecting certificate information to be used by the second terminal (205) using eUICC2.Info1 received by the first terminal (200) is as follows. Of course, it is not limited to the following examples.

[0112] The first terminal (200) may possess a ‘trusted CI list stored in the terminal’. Additionally, the first terminal (200) may possess a ‘trusted CI list provided by the server’. The first terminal (200) may derive a ‘trusted CI list’ using the ‘trusted CI list stored in the terminal’ and the ‘trusted CI list provided by the server’. The ‘trusted CI list’ may be a) identical to the ‘trusted CI list stored in the terminal’. b) the ‘trusted CI list’ may be identical to the ‘trusted CI list provided by the server’. c) the ‘trusted CI list’ may be the intersection of the ‘trusted CI list stored in the terminal’ and the ‘trusted CI list provided by the server’. Or, d) 'trusted CI list' may be the union of 'trusted CI list stored on the terminal' and 'trusted CI list provided from the server'.

[0113] 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, telecommunications carrier, terminal manufacturer, and eUICC manufacturer. Additionally, if the 'profile transfer setting' is configured to 'perform authentication using information received from the telecommunications carrier and / or RSP server,' then a 'trusted CI list provided by the server' may be used, as in the methods of b) to d).

[0114] The first terminal (200) 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 (205)' included in eUICC2.Info1. The first terminal (200) can select some or all of the information existing 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 (205)' included in eUICC2.Info1, and set the selected information as the certificate information to be used by the second terminal (205).

[0115] In step 225, the first terminal (200) may generate "first terminal authentication information (Device1.Auth)". "First terminal authentication information (Device1.Auth)" may include part or all of eUICC2.Info1. For example, "first terminal authentication information (Device1.Auth)" may include eUICC2.Challenge received by the first terminal (200). The first terminal authentication information (Device1.Auth) may include any string (eUICC1.Challenge) generated by the eUICC of the first terminal (200).

[0116] “The first terminal authentication information (Device1.Auth)” may include certificate information to be used by the second terminal (205). “The first terminal authentication information (Device1.Auth)” may include certificate eUICC1.Cert and related certificate chain information that can verify the first terminal (200) itself.

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

[0118] In step 230, the first terminal (200) can transmit “first terminal authentication information (Device1.Auth)” to the second terminal (205).

[0119] In step 235, the second terminal (205) can verify the received “first terminal authentication information (Device1.Auth).” The second terminal (205) can check the validity of eUICC1.Cert included in the “first terminal authentication information (Device1.Auth)” and use eUICC1.Cert to further check the validity of the signature included in the “first terminal authentication information (Device1.Auth).” The second terminal (205) can check whether the value of eUICC2.Challenge included in the “first terminal authentication information (Device1.Auth)” is the same as the value of eUICC2.Challenge that it transmitted in step 220. For example, if eUICC1.Cert is valid, the signature included in the “first terminal authentication information (Device1.Auth)” is valid, and the value of eUICC2.Challenge is the same, the verification can be successful.

[0120] Based on the verification result (e.g., if the verification is successful), the second terminal (205) can generate “second terminal authentication information (Device2.Auth)”. “second terminal authentication information (Device2.Auth)” may include part or all of Device1.Auth. For example, “Device2.Auth” may include eUICC1.Challenge received by the second terminal (205). “Device2.Auth” may include eUICC2.Info2, which is information for checking the eligibility of the eUICC installed on the second terminal (205). eUICC2.Info2 may be information used to determine whether a profile to be received from the first terminal (200) later can be properly installed and operated on the eUICC of the second terminal (205). For example, eUICC2.Info2 may include hardware and / or software information of the eUICC mounted on the second terminal (205). “Device2.Auth” may include a certificate eUICC2.Cert and related certificate chain information that can verify the second terminal (205) itself.

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

[0122] In step 240, the second terminal (205) can transmit “second terminal authentication information (Device2.Auth)” to the first terminal (200).

[0123] In step 245, the first terminal (200) can verify the received “second terminal authentication information (Device2.Auth).” The first terminal (200) can check the validity of eUICC2.Cert included in the “second terminal authentication information (Device2.Auth)” and use eUICC2.Cert to check the validity of the signature included in the “second terminal authentication information (Device2.Auth).” The first terminal (200) can check whether the value of eUICC1.Challenge included in the “second terminal authentication information (Device2.Auth)” is the same as the value of eUICC1.Challenge that it transmitted in step 230. For example, if eUICC2.Cert is valid, the signature included in the “second terminal authentication information (Device2.Auth)” is valid, and the value of eUICC1.Challenge is the same, the verification can be successful.

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

[0125] Based on the judgment result of step 245, the first terminal (200) for transmitting the profile package (EPP, exported profile package) can complete mutual authentication with the second terminal (205).

[0126] In step 250, after mutual authentication is completed, data encrypted with a session key can be transmitted and received between the first terminal (200) and the second terminal (205) at a specific time. For example, the encrypted data may be an encrypted profile package. The eUICC_T of the second terminal (205) may decrypt the session key and install the corresponding encrypted profile package.

[0127] A session key can be generated by the first terminal (200) and the second terminal (205) exchanging public keys among the ephemeral key pairs generated by the eUICC_S and eUICC_T of the first terminal (200) and the second terminal (205), respectively, for the purpose of key agreement, and by using the ephemeral private key generated by oneself and the received ephemeral public key as input. An ephemeral key pair can be used only once (one-time) for session key generation, and accordingly, it may be described interchangeably as one-time private key and one-time public key. For example, in step 235, the eUICC_T of the second terminal (205) generates an ephemeral key pair and transmits the ephemeral public key among them. If the eUICC_S of the first terminal (200), which receives the ephemeral public key, performs step 245 and succeeds in verifying the second terminal (205), the eUICC_S of the first terminal (200) may generate an ephemeral key pair and include the ephemeral public key among them in information for channel initialization of the EPP, and transmit it in step 250. The eUICC_T of the second terminal (205) can generate a session key using the ephemeral public key of the eUICC_S and the previously generated ephemeral private key as inputs, and decrypt the received EPP to process the installation.

[0128] In the following drawings of the present invention, the procedure for performing mutual authentication and subsequently transmitting data can be interpreted in the same way. That is, even without including a description of session key generation, it can be interpreted that the entities that have performed mutual authentication perform session key generation, and through this, data encrypted with the session key is transmitted between the entities.

[0129] FIG. 3 is a diagram illustrating a procedure for providing profile transfer from one terminal to another terminal according to one embodiment of the present disclosure.

[0130] Referring to FIG. 3, in step 325, the End User (300) may choose to move a profile installed on the first terminal (source terminal, source device, device 1) (305) to the second terminal (target terminal, target device, device 2) (310). A screen for selecting the move may be provided to the user (300) through a screen displayed to the user (300) on the first terminal (305) or the second terminal (310).

[0131] In step 330, the first terminal (305) and the second terminal (310) can verify eligibility for profile transfer through mutual authentication. An example of a method for mutual authentication may include the first terminal (305) and the second terminal (310) exchanging trusted CI list information stored with each other and verifying whether they have the same valid certificate chain. Since the method for mutual authentication has been described above in FIG. 2, a detailed explanation is omitted with reference to FIG. 2.

[0132] When the first terminal (305) determines the second terminal (310) to be a qualified terminal for profile transfer through mutual authentication, in step 335, the first terminal (305) may generate a profile package, e.g., an EPP, to transmit the corresponding first profile selected by the user (300) to the second terminal (310). The EPP may have the same network access credential as the first profile and may be transmitted in an encrypted form so that it can be installed only on the second eUICC of the second terminal (310). The first terminal (305) may allow the generation of a profile package (in the EPP state) only when the profile is in a disabled state. Accordingly, when the profile is in an active state, the eUICC (the first eUICC of the first terminal (305)) that receives the command may change the state of the profile to a disabled state and then perform the generation of the profile package. In addition, the above profile may transition to a temporarily locked state so that it cannot be changed to an enabled state while in a disabled state. The aforementioned state may, for example, be named the Unusable state in the present invention.

[0133] And in step 340, the first terminal (305) can transmit a profile package to the second terminal (310).

[0134] According to an embodiment, the first terminal (305) may transmit 'information of the first terminal (305)' to the second terminal (310). 'Information of the first terminal (305)' may be either eUICC certificate information or EID of the first eUICC currently installed for the profile to be moved. For example, 'information of the first terminal (305)' may be included during the procedure for mutual authentication between terminals (step 330) or included and transmitted at the time of transmitting the profile package that is an EPP (step 340). The second terminal (310) may store 'information of the first terminal (305)'.

[0135] In step 345, the second terminal (310) can receive the EPP and install it on the eUICC. In the case of EPP installation, in step 350, the eUICC can transmit the installation result (signed EPP profile installation result) to the first terminal (305), which is the Source Device rather than the Server Address of the Profile Metadata. The installation result can be transmitted as eUICC_T signed information and can be transmitted to the first terminal (305) including at least one of the information of the ICCID and the certificate information of eUICC_T.

[0136] The first terminal (305) that receives the installation result may verify the installation result in step 355. According to an embodiment, the first terminal (305) may request confirmation from the user regarding the final profile transfer for the processing of deleting the corresponding profile to be transferred by the first terminal (305). The verification of the installation result by the first terminal (305) may, for example, be an installation result verification comprising the LPA of the first terminal (305) transmitting the received encrypted installation result message to the eUICC of the first terminal (305), and the eUICC_S of the first terminal (305) receiving the eUICC_T signed installation result, at least one of the following actions. This may be an action of verifying the signature value of eUICC_T with a certificate having the same CI (Certificate Issuer) chain, verifying the information of the moved profile by checking whether the verified installation result data contains an ICCID identical to the ICCID of the profile transmitted in step 340, or determining whether the profile was installed on the eUICC_T that performed mutual authentication in step 330 by checking the EID of eUICC_T. The EID of eUICC_T may also be received included in the installation result as the certificate or EID data object of eUICC_T.

[0137] After verifying the installation result and confirming the profile transfer in the eUICC, in step 360, the eUICC of the first terminal (305) may provide the result to the LPA, and the LPA receiving this may send a deletion command for the corresponding profile based on the success response result. The deletion command for the corresponding profile may be a command such as, for example, ES10c DeleteProfile(ICCID or AID), and the eUICC of the first terminal (305) receiving this may delete the profile according to the profile deletion procedure defined in SGP.22 and send a reply with the deletion result. Meanwhile, the eUICC of the first terminal (305) may not send a success response result to the LPA, but if it succeeds in verifying the previously received profile installation result, it may determine that the deletion of the profile having the corresponding ICCID is performed as a continuous operation, delete the profile according to the profile deletion procedure defined in SGP.22, generate a deletion result, and send a reply to the LPA of the first terminal (305). The deletion result returned at step 360 can be transmitted encrypted with eUICC_S signed data.

[0138] The first terminal (305) that receives the deletion result of the profile may transmit the deletion result of the profile to the second terminal (310) at step 365 (signed delete result). The second terminal (310) that receives this may verify the deletion result at step 370 and determine whether to transition the state of the moved profile to a usable state. This may include, for example, a procedure in which the LPA of the second terminal (310) transmits the data to eUICC_T to perform verification, and the operation may be performed by including at least one of the following. The LPA of the second terminal (310) receives the result of deleting the profile and transmits it to the eUICC_T by including it in a command requesting a profile state transition (e.g., change to an available state) or signature verification, or the eUICC_T that receives it verifies the signature value of the received deletion processing result to confirm the integrity of the data, or confirms that the profile corresponding to the ICCID installed in the eUICC_T has been deleted using the information of the received data, or confirms the EID information that the corresponding ICCID has been deleted using the certificate information of the eUICC_T or the EID information included in the data object of the deletion result.

[0139] Meanwhile, if verification and / or confirmation is successful, the eUICC_T of the second terminal (310) may perform an operation including changing the state of the corresponding profile to an available state and send the result of the processing to the LPA of the second terminal (310). The available state (Usable) may be an enabled or disabled state of the profile. Alternatively, the eUICC_T of the second terminal (310) may send the verification result of the profile deletion result and, after the LPA of the second terminal (310) receives the command for the state change again, the eUICC_T of the second terminal (310) may change the state of the corresponding profile to an available state and send the result of processing it to the LPA of the second terminal (310) to the available state.

[0140] When deleting the first profile installed on the first terminal (310), in step 375, the first terminal (305) may generate and transmit a Delete Notification to the profile server (SM-DP+) (315) (step 375). As an example, the first terminal (305) may generate and transmit it in the same way as the Delete Notification defined in SGP.22. Alternatively, it may be a new notification other than a Delete Notification, such as a notification message like a profile transfer completion notification, but the method of generating and transmitting it may be the same. In the following description, it has been referred to as a Delete Notification.

[0141] The first terminal (310) may include the received profile deletion result in a profile deletion notification message and transmit it to the profile server (315). The profile deletion notification may include profile deletion result data signed by the eUICC_S of the first terminal (310), and may also be configured to include the EPP installation result received from the second terminal (310) in step 350.

[0142] A profile server (315) that receives a profile deletion notice can verify the profile deletion result by verifying the signature of the eUICC_S of the profile deletion notice received in step 380. Additionally, if there is an EPP installation result received together, the profile server (330) can verify the EPP installation result to determine whether it is a profile transfer reinstallation. The method by which the profile server (315) verifies the EPP installation result may be a method of determining by verifying using at least one of the eUICC_T signed installation result or the certificate information of the eUICC_T included in the EPP installation result. If the profile server (315) determines that it is a profile transfer reinstallation, the profile server (315) can update the information of the EID stored by mapping it to the received ICCID. Additionally, in step 385, the profile server (315) may notify the telecommunications operator (320) that a device change has occurred via ES2+.HandleNotification.

[0143] Meanwhile, although not specified in FIG. 3, if EPP creation data remains in the LPA and / or eUICC_S after the first terminal (305) has completed the device change processing, the remaining EPP creation data may be deleted together. For example, the above-described operation may be performed after the first terminal (305) sends a profile deletion notice to the profile server (315), or it may be performed together at the time when eUICC_S processes the profile deletion before sending the profile deletion notice.

[0144] FIG. 4 is a drawing illustrating a method for entering a profile transfer procedure between devices according to one embodiment of the present disclosure.

[0145] During the device change process, there may be cases where profiles are moved in bulk or profile(s) are moved individually. As the mutual authentication process for proceeding with the device change was described in FIG. 2 and the procedure for moving profiles between devices was additionally described in FIG. 3, FIG. 4 can be explained based on FIG. 2 and FIG. 3. Meanwhile, the first terminal (source terminal, source device, device 1) (405) of FIG. 4 may be a terminal that supports Extended Storage (i.e., the terminal's eUICC and LPA here support Extended Storage).

[0146] Referring to FIG. 4, in step 420, the terminal user (400) can enter the device change menu by selecting the device change menu. The first terminal (405) can perform a mutual authentication procedure between terminals based on the procedure of FIG. 2 to determine whether device change to the second terminal (target terminal, target device, device 2) (410) is possible. Prior to performing the mutual authentication procedure between terminals, the first terminal (405) may check the policy for device change movement of at least one profile among the terminal profiles. If permission from the profile server (SM-DP+) (415) is required for the policy for device change movement of the profile, in step 425, the first terminal (405) can connect to the profile server (415) and perform mutual authentication with the profile server (415). The first terminal (405) and the profile server (415) can perform mutual authentication based on the mutual authentication procedure defined in SGP.22.

[0147] A mutual authentication procedure is performed, and in step 425, the profile server (415) can generate a random value, and the first terminal (405) can receive the generated random value from the profile server (415).

[0148] The above random value may be included as a nonce value and transmitted to the second terminal (415) during the process in which the first terminal (405) performs mutual authentication with the second terminal (410) in step 430. The second terminal (410) may refer to the nonce value of the profile server (415) received from the first terminal (405) to determine whether the first terminal (405), which intends to establish mutual authentication, is a terminal for which device change permission has been approved by the profile server (415). Additionally, the nonce value may be utilized as data for the profile server (415) to determine that the profile has been moved and installed from the first terminal (405), which was previously authorized by the profile server, to the second terminal (410) by including it when transmitting a message regarding the result of the move installation to the profile server (415) via the second terminal (405) or directly at the time when the second terminal (410) completes the profile move installation.

[0149] The first terminal (405) may receive data from the second terminal (410) that includes information of the second terminal (410) and / or information of eUICC_T, and the data may be received as data signed by eUICC_T. The first terminal (405) may construct a message including the data and transmit it to the profile server (415) as a message requesting authentication for mobility permission (step 435). The profile server (415) may check the received message to verify the ICCID of the target profile to be moved, or verify the signature of eUICC_T to verify the data, and determine mobility suitability by verifying the information of the target terminal to be moved and the eUICC.

[0150] During the process (step 430) of the mutual authentication procedure above, the first terminal (405) may receive eUICCInfo2 information of eUICC_T from the second terminal (410). The received eUICCInfo2 includes information regarding whether the eUICC_T supports inter-device movement and may further include information regarding available eUICC memory. Information regarding available eUICC memory may be obtained, for example, as information included in an extCardResource data object. According to an embodiment, the information regarding available eUICC memory may be information including external memory information of the eUICC_T of the second terminal (410).

[0151] Additionally, the second terminal (410) may transmit information including whether the second terminal (410) supports device change during the mutual authentication process. The information regarding whether the second terminal (410) supports device change may be transmitted, for example, by being included as one of the RSP capabilities.

[0152] The first terminal (405) can check the available memory information of eUICC_T from the second terminal (410) based on the received information. According to an embodiment, the number of movable profiles can be determined by combining the information collected from the second terminal (405) by referring to the information obtained from the first terminal (405) (step 440).

[0153] The information obtained from the first terminal (405) may be information regarding the data capacity per profile obtained at a time prior to the first terminal (405) entering step 420. For example, the information may be profile capacity information obtained in the same manner as the estimated capacity of the profile provided as profile metadata received from the profile server (415) at the time when the first terminal (405) downloads the profile from the profile server (415) and decides whether to install it, or information on changes in the available memory of the eUICC, or the value obtained by dividing the memory capacity used by installed profiles in the eUICC provided memory by the number of installed profiles. Additionally, an example of obtaining information on changes in the available memory of the eUICC may include a method of determining by comparing the information on available memory obtained through GetEUICCInfo2 before and after profile installation. The capacity of the profile provided as profile metadata received from the profile server (415) may be, for example, profileSize INTEGER OPTIONAL returned by the ES10x.GetProfileInfo command.

[0154] Meanwhile, a situation may arise where all profiles of the first terminal (405) cannot be moved to another device. For example, this may be the case where the capacity of the profiles of the first terminal (405) is greater than the eUICC capacity of the second terminal (410). In this case, at step 445, the first terminal (405) may provide a menu to allow the user to select the profiles to move and move them to the second terminal (410). Accordingly, the user (400) can select the profile(s) to move. Also, when all profiles of the first terminal (405) can be moved, the first terminal (405) may not configure and display the corresponding menu.

[0155] Option 2 represents a procedure in which a terminal user (400) wants to move profile(s) individually from a first terminal (405) in which one or more profiles have been installed. Option 1 proceeds with the subsequent procedure by obtaining a device change request from the first terminal (405), checking available memory, and then providing a list of one or more movable profiles, while Option 2 proceeds by selecting specific profile(s) to move (step 450), thereby determining only whether the move of the profile is supported and providing support (step 470) instead of the operation of determining the number of profiles to move (step 440) mentioned earlier. Other operations, such as steps 455, 460, and 465, can be processed in the same way as steps 425, 430, and 435 of Option 1. Meanwhile, if two or more profiles to move to are selected in step 450 of Option 2, steps 455 through 470 of Option 2 may be repeated (e.g., twice when two are selected).

[0156] According to an embodiment, if two or more profiles to be moved are selected in step 450, steps 455 through 470 of Option 2 may be performed only once. According to an embodiment, if two or more profiles are all movable, they may be notified as movable in step 470, and if any one of the two or more profiles is movable, they may be determined as movable in step 470. According to an embodiment, if any one of the two or more profiles is movable, only the movable profile may be moved, and the movable profile may not be moved and may be notified to the user (400). According to an embodiment, if any one of the two or more profiles is movable, information regarding the movable profile may be provided to the user (400). According to an embodiment, if it is determined in step 470 that a profile cannot be moved, the first terminal (405) may inform the user (400) that the move of the corresponding profile is impossible by configuring a menu. According to the embodiment, if two or more profiles to be moved are selected in step 450 and any one of them cannot be moved, the first terminal (405) provides a menu to the user (400) to select the profiles to be moved, and the profile(s) to be moved can be selected according to the user's (400) selection.

[0157] Meanwhile, as described in the continuous operation in FIG. 4, if the profile transfer between devices is performed after requesting prior permission and receiving approval (when steps 425 to 455 are performed), the second terminal (410) may subsequently transmit the profile transfer installation result to the profile server (415) (not shown). If the second terminal (410) receives a random value from the profile server (415) through the first terminal (405), it may generate a message including the random value. The second terminal (410) may transmit to the profile server (415) directly from the second terminal (410) or through the first terminal (405). When the second terminal (410) directly transmits the profile transfer installation result to the profile server (415), the second terminal (410) may have obtained the address of the profile server (415) from the first terminal (405) at a specific point in time prior to, or may have the address of the profile server (415) in advance as a terminal setting. The profile server (415) receives the message and verifies the eUICC_T signature, and after verifying the signature, verifies the data. This may include, for example, one of the following: determining whether the received random value included in the message is the same as the random value previously transmitted by the profile server to the first terminal (405) to verify whether the profile is transferred from the first terminal (405). The profile server (415) may also verify the result of the profile transfer by checking whether the received ICCID and / or EID is the same as the information of the terminal to which the profile is to be transferred received from the first terminal (405).

[0158] FIG. 5 is a diagram illustrating a method for handling inter-device transfer when Extended Storage is supported at a first terminal according to an embodiment of the present disclosure.

[0159] FIG. 5 describes a method for processing a profile selected by a user depending on where it is located within the first terminal (source terminal, source device, device 1) (405). The procedure may proceed as described in FIG. 4.

[0160] At the first terminal (405), the profile movement selection procedure can be entered as described in FIG. 4 (step 520).

[0161] The user (400) can select at least one profile to move to.

[0162] The profiles that the user (400) will move to may exist only in the eUICC of the first terminal (405). This may be the case where the first terminal (405) does not support the Extended Storage function, or where it supports the Extended Storage function, but the profile(s) selected by the user (400) are all profiles stored in the eUICC of the first terminal (405).

[0163] If the first terminal (405) does not support Extended Storage, for example, if the eUICC or / and LPA of the first terminal (405) does not support Extended Storage, the first terminal (405) may enter the inter-device profile transfer step without a procedure for determining the storage location of the profile. The first terminal (405) may perform a procedure to transfer the selected profile to another terminal (for example, the second terminal (target terminal, target device, device 2) (410)), and since the procedure to transfer to another terminal is described in detail in FIG. 3, the description will be omitted. The first terminal (405) may repeat the procedure in FIG. 3 for as many profiles as the number of profiles selected for transfer by the user (400), and if one or more profiles are transferred, some of the repeated procedures may be omitted. For example, the inter-device mutual authentication procedure may be performed only once, and subsequent operations may be repeated.

[0164] If the first terminal (405) supports Extended Storage, for example, if the eUICC and LPA of the first terminal (405) support Extended Storage, the first terminal (405) can perform subsequent operations based on the determination of the storage location of the profile. The first terminal (405) can obtain the storage location of the profile through one of the following methods.

[0165] ● If the eUICC successfully performs external extraction of a profile, it identifies and stores the corresponding profile (identifiable by ICCID) as the externally extracted profile. When the LPA requests profile information from the eUICC, the eUICC replies to the LPA with the profile information.

[0166] ● When the LPA requests Extended Storage of a profile via eUICC and receives a successful response, the ICCID of the corresponding profile is stored and managed as an externally extracted profile.

[0167] The first terminal (405) can determine the storage location of selected profile(s) based on information stored in the eUICC or LPA. For example, if the metadata of a profile is returned without identification information for external extraction, the profiles can be considered as profiles stored in the eUICC.

[0168] If the profiles to be moved exist only in the eUICC of the first terminal (405), in step 525, the first terminal (405) may perform a procedure to move the selected profile to another terminal, and since this procedure has been described in detail in FIG. 3, the description will be omitted. The first terminal (405) may repeat the procedure in FIG. 3 for as many times as the number of profiles selected for movement by the user (400), and if one or more profiles are moved, some of the repeated procedures may be omitted. For example, the inter-device mutual authentication procedure may be performed only once, and subsequent operations may be repeated.

[0169] Meanwhile, the first terminal (405) can determine, through information regarding whether the profile stored in the eUICC or LPA is externally extracted, that at least one of the selected profile(s) is a profile stored outside the eUICC of the first terminal (405).

[0170] The first terminal (405) determines whether there is available memory for reinstalling a user-selected profile from outside the eUICC to the eUICC, and if there is insufficient available memory, it can proceed with a procedure to secure it as shown in FIG. 6 (step 530).

[0171] The first terminal (405) can determine whether there is available memory of the eUICC of the first terminal (400) by referring to the size information of the profile stored in the metadata of the profile moved externally, available memory information obtainable with eUICC Info2, etc.

[0172] If the first terminal (405) determines that available memory is insufficient, the first terminal (405) (via its LPA) may proceed with a procedure to secure available memory within the eUICC as shown in FIG. 6. After securing available memory, in step 535, the first terminal (405) may perform a procedure to reinstall the selected profile into the eUICC. Since the procedure to reinstall the selected profile is described in detail later in FIG. 7, the description thereof is omitted in FIG. 5. After reinstalling the selected profile, in step 540, the first terminal (405) may perform a procedure to move the profile between devices based on the procedure described in FIG. 3. The first terminal (405) may repeat steps 530 through 545 up to the number of externally extracted profile(s) selected for inter-device movement.

[0173] Meanwhile, if it is determined that there is sufficient available memory for reinstallation in the eUICC of the first terminal (405) (for example, if the available memory in the eUICC obtained by eUICCInfo2 is larger than the profile size as metadata information of the profile of the profile moved externally), the first terminal (405) may skip step 530 and perform step 535 and subsequent steps.

[0174] As previously explained in FIG. 4, prior permission from the operator's profile server (415) may be required for profile transfer between devices. If prior permission is requested and approved, and profile transfer between devices is performed, the second terminal (410) may subsequently transmit the profile transfer installation result to the profile server (415) (step 545). If the second terminal (410) receives a random value from the profile server (415) through the first terminal (405), it may generate a message including the random value. The second terminal (410) may transmit to the profile server (415) either directly from the second terminal (410) or through the first terminal (405). When the second terminal (410) directly transmits the profile transfer installation result to the profile server (415), the second terminal (410) may have obtained the address of the profile server (415) from the first terminal (405) at a specific point in time prior to, or may have the address of the profile server (415) in advance as a terminal setting. The profile server (415) receives the message and verifies the eUICC_T signature, and after verifying the signature, verifies the data. This may include, for example, one of the following. The profile server (415) may determine whether the profile is transferred from the first terminal (405) by determining whether the included received random value is the same as the random value previously transmitted to the first terminal (405). The profile server (415) may also verify the profile transfer result by checking whether the received ICCID and / or EID is the same as the information of the terminal to which the profile is to be transferred received from the first terminal (405).

[0175] FIG. 6 is a diagram illustrating a procedure for moving after securing memory within the eUICC in a first terminal according to an embodiment of the present disclosure and reinstalling it.

[0176] In the case where the user selects one or more profiles to move based on FIGS. 2 and FIGS. 3 above, and the first terminal (source terminal, source device, device 1, LPA) (600) supports Extended Storage, at least one of the profiles selected by the user may be in the terminal memory.

[0177] In this case, the profile extracted and stored by the first terminal (600) in external memory can only be restored and reinstalled to the corresponding eUICC of the first terminal (600). Therefore, if the first terminal (600) moves data to the second terminal (target terminal, target device, device 2) (610) without restoring and reinstalling it to the eUICC of the first terminal (600), the second terminal (610) cannot use it. Therefore, it is necessary to support the ability for the user to use the selected profile on the second terminal (610) as well. Accordingly, the first terminal (600), which provides an Extended Storage function for moving the profile between devices, can perform restoration and reinstallation of the corresponding profile to the eUICC of the first terminal (600) through one of the following methods.

[0178] ● Option 1: A method (step 615) of first moving the selected profiles to the second terminal (610), securing the available memory of the eUICC (605) of the first terminal (600), and then loading the terminal-extracted profiles into the eUICC (605) to reinstall them.

[0179] ● Option 2: A method of securing available memory of the eUICC (605) of the first terminal (600) by extracting all profiles that are externally movable among the unselected profiles within the eUICC (605) of the first terminal (600) to the outside of the eUICC (605) (steps 620 and 625)

[0180] ● Option 3: A method to secure available memory of the eUICC (605) of the first terminal (600) by deleting unselected profiles within the eUICC (605) of the first terminal (600) (steps 630 and 635)

[0181] The first terminal (600) can secure available memory of the eUICC (605) for reinstalling the profile into the eUICC (605) by one of the methods of options 1-3. One or more of the methods of options 1-3 may be used, and a combination of them may also be used. Meanwhile, options 1-3 may be performed repeatedly depending on the number of user-selected or unselected profiles.

[0182] For example, if the number of unselected profiles by the user is 2, steps 630 and 635 may be repeated 2 times.

[0183] In the method of first moving the selected profile of Option 1 of Step 615, the procedure for moving the profile to another device is explained in Fig. 3, so it is omitted here.

[0184] In Option 2, at step 620, LPA (600) can send a command to eUICC (605) for moving the profile outside.

[0185] This may include at least an ICCID as identification information for the profile to be moved. Option 2 may also be performed via terminal settings without the user's consent.

[0186] The eUICC (605) that receives this checks whether the profile is a profile that can be extracted externally, that is, whether it allows the Ext Storage function, based on the profile information, e.g., metadata of the stored profile, etc., using the information of the profile having the corresponding ICCID, and if it supports it, it can re-package the profile for external extraction.

[0187] In step 625, the eUICC (605) may generate a reply message and send it to the LPA (600). If the processing result is successful, the eUICC (605) may send a success response to the LPA (600), including the packaged profile data (ESPP) and the signature value of the eUICC, to the LPA (600). If, due to the configuration of the terminal (600) and the eUICC (605), the eUICC (605) uses the storage memory connected to the eUICC (605) as the memory of the terminal (600), the eUICC (605) may send only the response regarding the processing result to the LPA (600) as a reply message. Before sending a command for external extraction to the eUICC (605), if there is previously stored profile info information, the LPA (600) may refer to it to determine the ICCID included in the move storage command. This procedure may be repeated as many times as the number of profiles that allow extraction into the terminal within the profile.

[0188] For the profiles extracted into the terminal in Option 2, the terminal (600) may additionally perform a restoration reinstallation procedure to the eUICC (605) according to the terminal settings after the user performs the procedure to move the selected profiles (step 655). The additional restoration reinstallation procedure may be performed as described in steps 640 to 650 below, and the restoration reinstallation procedure may be repeated as many times as the number of profiles extracted externally. When performing the additional restoration reinstallation procedure, the terminal settings may proceed without the user's consent.

[0189] Meanwhile, instead of checking the configuration information of the profile within the eUICC (605) and extracting it externally, the terminal (600) may consider that the terminal user does not use a profile for which they have not selected to move. In this case, according to Option 3, the first terminal (600) may announce that unselected profiles are deleted from the user screen and may receive user input regarding this and enter the profile deletion procedure. The profile deletion procedure may proceed according to the profile deletion procedure defined in GSMA RSP .22. For example, at step 630, the LPA (600) may construct a message including the ICCID as identification information of the profile to be deleted in the profile deletion command and send it to the eUICC (605). Then, the eUICC (605) that receives this determines whether the profile can be deleted, and if deletion is possible, processes the deletion and sends the processing result to the LPA (600) at step 635.

[0190] If available memory for restoring and reinstalling the profile is secured in the eUICC (605) using the method of options 1-3 above, in step 640, the first terminal (600) can check the profile data stored outside the terminal among the profiles the user wants to move and provide it to the eUICC (605).

[0191] When LPA (600) receives a profile package and performs external storage, LPA (600) can transmit to eUICC (605) a restore command including the ICCID of the profile to be restored, the profile package data extracted externally, and the signature of eUICC (605).

[0192] The eUICC (605) that receives the message may proceed with reinstalling the profile in step 645. This may be carried out by including at least one of the following procedures. The eUICC (605) may check the received ICCID and verify whether the profile is an externally extracted profile, or the eUICC (605) may check whether there is some data of the profile stored mapped to the ICCID, or verify the integrity of the EPP data by verifying the signature of the received EPP data, or verify whether it was data previously signed by the eUICC (605), or create data to be restored by combining the data for which signature verification was performed with the data to be split and stored in the eUICC (605), or configure the original profile data before extraction to be restored.

[0193] When eUICC (605) completes the profile restoration reinstallation, it can reply to LPA (600) with the installation results at step 650.

[0194] Upon receiving this, the LPA (600) transmits a device transfer command for the corresponding profile, thereby requesting the eUICC (605) to generate and return an encrypted profile package for the transfer of the profile between devices, and can perform a device transfer to the second terminal (610) by transmitting the returned encrypted package to the second terminal (610) (step 655). Since the procedure for transferring the profile from the first terminal (600) to the second terminal (610) has been described above in FIG. 3, step 655 is determined by referring to this, and a detailed explanation is omitted here.

[0195] FIG. 7 is a diagram illustrating a profile extraction procedure from a first terminal to an outside eUICC according to one embodiment of the present disclosure.

[0196] FIG. 7 is for the purpose of facilitating understanding of the present disclosure and is not intended to limit the present disclosure. Some of the entities and / or operations illustrated in FIG. 7 may be omitted, and additional entities and / or operations not illustrated in FIG. 7 may be included.

[0197] The example in Fig. 7 may be an action performed at a specific point after the profile download and installation (step 720) has been performed.

[0198] Since the profile download and installation procedure can be carried out as defined in SGP.22, a detailed description is omitted here. A general profile download and installation procedure may include, for example, the execution of a mutual authentication procedure between terminals in which the terminal's LPA (705) requests an eUICC challenge value (nonce) from the eUICC (715). In the mutual authentication procedure, the method by which the terminal's eUICC (715) authenticates a profile server (not shown) may be performed by sending a message to the profile server signed with the eUICC (715)'s private key including the nonce value, and receiving a response message from the profile server containing the nonce value, and the server may also perform the same. During the mutual authentication procedure, the terminal may send a message containing the capabilities of the terminal or the eUICC (715) to the profile server, and the profile server may also send a message containing the profile server's callabilities to the eUICC (715). The profile server may generate profile metadata based on the capabilities of the received terminal or eUICC (715) and send a message containing the metadata to the terminal.The LPA (705) of the terminal may provide some or all of the metadata information of the profile received on the terminal user's screen, obtain a download response of the profile from the user (700), request a Bound Profile Package from the profile server, the profile server transmits the Bound Profile Package to the LPA (705) of the terminal, the transmitted profile Package is split and transmitted from the LPA (705) to the eUICC (715), the eUICC (715) confirms a shared secret for establishing a secure channel through one of the received messages, uses it to decrypt and install the profile package, and after installation, the eUICC (715) transmits the encrypted installation result to the profile server through the LPA (705), and the profile server transmits it to the mobile carrier server of the corresponding profile. At least one of these processes may be performed.

[0199] In step 725, the LPA (705) may perform an action to display a list of ES-supported profiles to the user (700) through the user screen. For example, step 725 of FIG. 7 may include the action described in FIG. 4. FIG. 7 may be a detailed action for option 2 (steps 620 and 625) of FIG. 6.

[0200] The profile transfer procedure may be initiated when the terminal user (700) receives input selecting the profile to transfer from the terminal user (700) in step 730. Alternatively, if the terminal recognizes that a profile transfer is necessary according to the terminal settings (e.g., detection of insufficient available memory of the eUICC (705) for installing a new profile, detection of insufficient available memory of the eUICC (705) for restoring and reinstalling a profile extracted from outside the eUICC (705), etc.), the profile transfer procedure may be initiated by obtaining the consent of the user (700) or based on the terminal's judgment.

[0201] When a profile move is determined based on the selection input of the terminal user (700) or the settings of the terminal, in step 735, the LPA (705) may send a request (for a profile move) (or a profile move request message) to the eUICC (715). For example, the request may be a new command such as RequestToExtStorage and may include the ICCID or AID (Application ID) of the profile selected by the user or terminal as identification information for the profile to be moved. If the eUICC (715) does not support a profile move, the eUICC (715) may return an error to the LPA (705) and terminate the procedure.

[0202] In step 740, the eUICC (715) that supports profile movement and receives the above request can determine whether to support ES by determining whether at least one of the following conditions is satisfied.

[0203] 1. Whether a profile identified by the corresponding ICCID or AID exists

[0204] 2. Whether ES movement is allowed as profile information (ES support, support for external split extraction, etc., check ICCID policy)

[0205] 3. Check if the status of the above profile to move is disabled (Check profile status)

[0206] If eUICC (715) fails to satisfy at least one of the above conditions, it may return an error to LPA (705) at step 745 and terminate the procedure. Meanwhile, if eUICC (710) returns an error when the profile state requesting the move is active, LPA (705) may request a change of the profile state to inactive, and after eUICC (715) performs profile inactive, LPA (705) may perform step 735 again.

[0207] eUICC (715) may determine that the profile is moveable. For example, if there is a profile identified by an ICCID or AID (received in step 735) and the ES moveable is allowed according to the information of the profile, eUICC (715) may determine that the profile is moveable.

[0208] In step 750, the eUICC (715) may configure the data of the profile to be exported (or transmitted externally). For convenience of explanation, the data of the profile to be exported (or transmitted externally) by the eUICC (715) in this disclosure will be referred to as an External Storage Profile Package (ESPP). However, it is not limited to such terms. For example, an ESPP may be a data package configured to include all or part of the files of the profile. The profile package may be composed of only a portion of the files, excluding sensitive data files, and may be composed in the form of binary data.

[0209] If the profile contains split storage request information, eUICC (715) can check the information in the profile to see if a list that does not allow extraction required by eUICC (715) has been provided.

[0210] If a list of items that are not allowed to be extracted is provided in the profile information, eUICC (715) can generate a data package excluding that list.

[0211] If the profile does not include split storage requirement information, the eUICC (715) may package the entire profile or create a data package consisting of only some files according to the split storage information set in the eUICC (715). The split storage information set in the eUICC (715) may be information identifying files or bundles of files that must be kept without being extracted from the eUICC (715). For example, files that must be kept without being extracted from the eUICC (715) may be sensitive data files, such as authentication information for network access.

[0212] eUICC (715) may also encrypt the corresponding profile package (ESPP) that it has decided to export externally with an encryption key so that it can be decrypted only by eUICC (715) with the same EID (eUICC identifier).

[0213] eUICC (715) can operate in a first storage method or a second storage method. The first storage method and the second storage method are distinguished according to the entity performing the movement to memory (710), and are used as terms to distinguish the two methods in this specification.

[0214] When the eUICC (715) operates in the first storage method, the eUICC (715) may reply to the LPA (705) with an ESPP in step 755 in response to the request in step 735. For example, the eUICC (715) may reply with only the ESPP, or it may reply with at least one of the following: an EID, decryptable eUICC information along with the ESPP, and an ICCID to identify which profile the data belongs to. For example, the eUICC (715) may transmit all or part of the data extracted from the eUICC as signed data, and accordingly, reply including the eUICC signature along with the eUICC data being replied. In step 760, the LPA (705) may store the received data in memory (710) outside the eUICC.

[0215] When the eUICC (715) operates in the second storage method, at step 765, the eUICC (715) can transmit the ESPP to the memory (710). Then, at step 770, the eUICC (715) can return the processing result to the LPA (705). For example, at step 765, the eUICC (715) may transmit only the ESPP to the memory (710), or it may transmit the ESPP along with at least one of the decryptable eUICC information, such as an EID or an ICCID to identify which profile the data belongs to, to the memory (710). For example, the eUICC (715) may transmit all or part of the data extracted from the eUICC (715) as signed data, and accordingly, transmit the eUICC signature along with the transmitted eUICC data to the memory (710). The operation of step 765 may be performed after the operation of step 770 has been performed.

[0216] After LPA (705) receives a success response for moving the profile (step 755 or 770), it may proceed with the procedure to move the profile to another terminal.

[0217] FIG. 8 is a drawing illustrating the configuration of a terminal according to one embodiment of the present disclosure.

[0218] Referring to FIG. 8, the terminal may include a transceiver (820), a processor (810), and a memory (830). Additionally, the terminal may further include an eUICC (not shown). The terminals described above in the present disclosure may correspond to the terminal described in FIG. 8.

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

[0220] A method according to one embodiment of the present disclosure may include: a step in which a terminal receives information regarding 'support for inter-device movement' of a profile from an eUICC; and a step in which the terminal determines inter-device movement of a profile based on information regarding whether the profile supports 'support for inter-device movement'.

[0221] A method according to one embodiment of the present disclosure may include: a step in which a terminal receives information from an eUICC regarding 'support for moving outside the eUICC' ​​of a profile; and a step in which the terminal determines whether to move part or all of the profile outside the eUICC based on information regarding whether the profile 'supports moving outside the eUICC'.

[0222] According to various embodiments, the transceiver (820) 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 (820) may be composed of an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies a received signal and down-converts the frequency. However, this is merely one embodiment of the transceiver (820), and the components of the transceiver (820) are not limited to an RF transmitter and an RF receiver. Additionally, the transceiver (820) may receive a signal through a wireless channel and output it to a processor (810), and transmit the signal output from the processor (810) through a wireless channel.

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

[0224] Meanwhile, the terminal may further include memory (830) and may store data such as basic programs, application programs, and setting information for the operation of the terminal. Additionally, the memory (830) may include at least one storage medium among Flash Memory Type, Hard Disk Type, Multimedia Card Micro Type, card type memory (e.g., SD or XD memory, etc.), magnetic memory, magnetic disk, optical disk, RAM (Random Access Memory), SRAM (Static Random Access Memory), ROM (Read-Only Memory), PROM (Programmable Read-Only Memory), and EEPROM (Electrically Erasable Programmable Read-Only Memory). Additionally, the memory may include chip or card-type memory such as an eUICC or embedded Secure Element installed in the terminal, in addition to the eUICC on which the profile to be extracted is installed. Additionally, the memory (830) may include memory connected to the terminal via a wired or wireless network, for example, memory of a cloud server, external memory of the terminal, or memory such as an SD micro card inserted into the terminal.

[0225] Additionally, the processor (810) can perform various operations using various programs, content, data, etc. stored in the memory (830). As previously described in FIG. 1, the memory (830) is connected to the LPA and can store profile data extracted by the LPA from the eUICC or provide it when requested by the LPA.

[0226] The eUICC (not shown) may include a transceiver, a processor, and memory. The processor of the eUICC may include an ISD-R application. The ISD-R may exist as a system application of the eUICC (e.g., as part of the OS or as a system application existing on top of the OS). The ISD-R receives commands received from the LPA through the transceiver and interprets the received commands to perform profile management operations on the eUICC, such as installing, deleting, or moving profiles.

[0227] The eUICC processor can perform at least one of the operations mentioned below.

[0228] The processor of the eUICC can perform the role of receiving the processing result from the eUICC and sending it back to the LPA through the transmission and reception unit. Additionally, the processor of the eUICC can obtain the profile status information and profile authorization information (at least one of the information regarding whether movement to another device is supported, whether movement is supported, and whether partition storage is supported) from the profile metadata and store them in memory (830), and when receiving information about the profile status from the LPA, it can obtain it and send it back to the LPA.

[0229] In addition, the eUICC processor can distinguish between profile data that must be left in the eUICC and profile data that is allowed to be moved.

[0230] In addition, the eUICC processor can generate a profile package to be moved (to storage space outside the eUICC or another device) and configure a message including the profile package to be moved.

[0231] In addition, the eUICC processor may determine whether to transfer the file package to be moved to the memory inside the terminal connected to the LPA or eUICC by referring to the settings for the memory storage entity when moving to a storage space outside the eUICC.

[0232] In addition, the eUICC may store at least one of the following in the memory of the eUICC as metadata information of the profile and as part or additional information of the metadata: status information of the profile, estimated capacity of the profile, whether the profile supports ES (External Storage), whether the profile requires partitioned storage, a list of partitioned storage requirements, whether the eUICC supports ES, information on the eUICC's ES support settings, whether the profile is allowed to move between devices, and whether operator permission (access to a profile server for such permission) is required when moving the profile between devices; and the processor may access the memory and obtain one of the above-mentioned information and utilize it as a predetermined information necessary to perform at least one operation, such as profile movement processing or deletion processing.

[0233] FIG. 9 is a drawing illustrating the configuration of a server according to one embodiment of the present disclosure.

[0234] Referring to FIG. 9, the server may include a transceiver (920), a processor (910), and a memory (930). The servers described above in the present disclosure may each correspond to the server described in FIG. 9. For example, the servers described above in FIG. 1, FIG. 3, and FIG. 4 (e.g., operator server, RSP server, SM-DP+, or SM-DS) may each include the configuration of the server described in FIG. 9.

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

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

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

[0238] Meanwhile, the server may further include memory (930) and may store data such as a basic program for the operation of the server, an application program, server configuration information regarding ES support or / and inter-device transfer support, and a carrier's policy regarding ES support or / and inter-device transfer support applied to the profile. Additionally, the memory (930) may include at least one storage medium among Flash Memory Type, Hard Disk Type, Multimedia Card Micro Type, Card Type Memory (e.g., SD or XD memory, etc.), Magnetic Memory, Magnetic Disk, Optical Disk, Random Access Memory (RAM), Static Random Access Memory (SRAM), Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), and Electrically Erasable Programmable Read-Only Memory (EEPROM). Additionally, the processor (910) may perform various operations using various programs, content, data, etc. stored in the memory.

[0239] The server may perform at least one of the actions mentioned below.

[0240] The server receives one or more messages for profile installation through the transmitting and receiving unit (920) and transmits them to the processor (910), and the processor (910) can verify the eUICC signature. The server can perform the role of delivering the verification results to the operator.

[0241] Additionally, the processor (910) of the server can check whether there is an identifier for "External Storage" support and / or "device transfer between terminals" support in the eUICC information (e.g., eUICCInfo2) included in the message received from the terminal for mutual authentication, for example, AuthenticateClient. The processor (910) can determine the metadata configuration by referring to the configuration information applied to the profile set on the profile server or the profile server obtained from the telecommunications carrier, and can send the configured profile metadata back to the terminal through the transmission / reception unit (920).

[0242] Additionally, the server processor (910) may generate a random value (nonce) to authenticate the terminal during the mutual authentication process with the terminal and send it back to the terminal, and may authenticate the entity by receiving eUICC-signed data from the terminal and verifying the signature of the data to see if the received data contains the nonce value generated and provided by the server.

[0243] Additionally, the server processor (910) may store session identification information and encryption keys for session creation in memory (930). Additionally, the server may perform the operation of signing at least one of the messages transmitted by the profile server with the server's encryption key and transmitting it to the terminal through the transmission / reception unit (920) as a message containing the profile server's signature.

[0244] Additionally, the server receives one or more messages for permission to move and install a profile between devices from Device_S via the transmitting / receiving unit (920) and transmits them to the processor (910). The processor (910) can verify the identification information of the profile to be moved, verify the eUICC_T signature, and verify at least one of the information of Device_T and eUICC_T by checking the verified message. It can also perform an eligibility check for device change by including a carrier policy regarding whether to allow device change for the corresponding profile in the server's memory (930), determine whether to allow device change through this process, and may reply to the terminal via the transmitting / receiving unit (920) regarding whether to allow the profile to be moved to another terminal.

[0245] Additionally, the server receives a message containing the profile transfer installation result through the transmission / reception unit (920), transmits it to the processor (910), and the processor (910) can verify the eUICC signature. The server checks the information of the profile included in the data of the received message (for example, whether the ICCID is mapped to the EID corresponding to the ICCID stored in memory (930)), and if it is determined to be a profile transfer installation, it updates the matching of the EID corresponding to the ICCID and performs the role of transmitting the verification result to the operator through the transmission / reception unit (920).

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

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

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

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

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

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

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

Claims

1. A method performed by a first terminal of a wireless communication system, A step of determining whether at least one profile among one or more profiles to be moved from the first terminal to the second terminal is stored in an external storage unit of the eUICC (embedded UICC (universal integrated circuit card)) of the first terminal; If the above at least one profile is stored in an external storage unit of the eUICC of the first terminal, the step of reinstalling the above at least one profile in the eUICC; and A method comprising the step of transmitting the at least one profile reinstalled above to the second terminal.

2. In claim 1, the reinstallation step is, If there is no available memory in the eUICC to reinstall the at least one profile, the step of transmitting to the second terminal a profile among the profiles installed in the eUICC that is to be moved to the second terminal; A step of sending a message to the eUICC requesting that the profile moved to the second terminal be deleted from the eUICC; and A method characterized by including the step of reinstalling at least one profile on the eUICC.

3. In claim 1, the reinstallation step is, If there is no available memory in the eUICC to reinstall the at least one profile, the step of sending a message to the eUICC requesting that the profile installed in the eUICC that will not be moved to the second terminal be moved to the external storage unit of the eUICC; and A method further comprising the step of receiving from the eUICC a message containing information about the result of moving a profile that will not be moved to the second terminal to the external storage unit of the eUICC.

4. In claim 1, the reinstallation step is, If there is no available memory in the eUICC to reinstall the at least one profile, the step of sending a message to the eUICC requesting that the profile installed in the eUICC that will not be moved to the second terminal be deleted from the eUICC; and A method further comprising the step of receiving from the eUICC a message containing information about the result of deleting from the eUICC a profile that will not be moved to the second terminal.

5. In Paragraph 1, A method characterized by further including the step of transmitting one or more profiles to the second terminal to be moved from the first terminal to the second terminal when at least one profile is not stored in the external storage of the eUICC of the first terminal.

6. In Paragraph 1, A method further comprising the step of identifying whether there is available memory in the eUICC to reinstall the at least one profile when the at least one profile is stored in an external storage unit of the eUICC of the first terminal.

7. In Paragraph 1, A method characterized by further including the step of determining whether one or more profiles to be moved from the first terminal to the second terminal are transferable to the second terminal based on information regarding the available eUICC memory of the second terminal.

8. In Paragraph 7, A method characterized by further including the step of identifying information about a profile to be moved to the second terminal among the one or more profiles when the one or more profiles to be moved from the first terminal to the second terminal are not transferable to the second terminal.

9. In the first terminal of a wireless communication system, Transmitter / receiver; and Connected to the above-mentioned transmitting and receiving unit, Determining whether at least one profile among one or more profiles to be moved from the first terminal to the second terminal is stored in an external storage unit of the eUICC (embedded UICC (universal integrated circuit card)) of the first terminal, and If the above at least one profile is stored in the external storage of the eUICC of the first terminal, the above at least one profile is reinstalled in the eUICC, and A first terminal comprising a control unit that transmits the at least one profile reinstalled above to the second terminal.

10. In claim 9, the control unit is, If there is no available memory in the eUICC to reinstall the at least one profile, the profile to be moved to the second terminal among the profiles installed in the eUICC is transmitted to the second terminal, and Send a message to the eUICC requesting that the profile moved to the second terminal be deleted from the eUICC, and A first terminal characterized by reinstalling at least one profile on the eUICC.

11. In claim 9, the control unit is, If there is no available memory in the eUICC to reinstall the at least one profile, a message is sent to the eUICC requesting that the profile among the profiles installed in the eUICC that will not be moved to the second terminal be moved to the external storage of the eUICC, and A first terminal characterized by receiving from the eUICC a message containing information about the result of moving a profile that will not be moved to the second terminal to the external storage unit of the eUICC.

12. In claim 9, the control unit is, If there is no available memory in the eUICC to reinstall the at least one profile, a message is sent to the eUICC requesting that the profile installed in the eUICC that will not be moved to the second terminal be deleted from the eUICC. A first terminal characterized by receiving from the eUICC a message containing information about the result of deleting from the eUICC a profile that will not be moved to the second terminal.

13. In claim 9, the control unit is, A first terminal characterized by transmitting one or more profiles to the second terminal to be moved from the first terminal to the second terminal when at least one profile is not stored in the external storage of the eUICC of the first terminal.

14. In claim 9, the control unit is, A first terminal characterized by determining whether one or more profiles to be moved from the first terminal to the second terminal are transferable to the second terminal based on information regarding the available eUICC memory of the second terminal.

15. In claim 14, the control unit is, A first terminal characterized by identifying information regarding a profile to be moved to the second terminal among the one or more profiles when the one or more profiles to be moved from the first terminal to the second terminal are not transferable to the second terminal.

Images