Method and device for transmitting network access information between terminals in mobile communication system

Abstract

The present disclosure relates to: a communication technology and a system thereof that integrates IoT technology with a 5G communication system that supports a data transmission rate higher than that of a 4G system. The present disclosure can be applied to smart services based on 5G communication technology and IoT-related technologies (e.g., smart homes, smart buildings, smart cities, smart cars or connected cars, health care, digital education, retail business, safety and security-related services, etc.). The present invention proposes a method and an apparatus for realizing convenient device-to-device communication service mobility by combining a user's device transfer initiation terminal and an operator support method even when a user initiates device transfer from any terminal when moving a profile between devices. In particular, according to one embodiment of the present invention, a method may be provided, comprising the following steps: receiving an input of a first profile for mobile installation in a first terminal; in the first terminal, determining that the device transmission method of the communication service provider is the ODSA method by checking the profile metadata, the configuration server or the terminal memory; determining, by the ECS, the ECS / DP+ authentication method as the user authentication method for device transmission, and sending it to the terminal together with the current value and the SM‑DP+ address generated by the ECS; receiving, by the ECS, the authentication result data processed by the SM‑DP+ from the first terminal, and verifying, by the ECS, the current value generated and transmitted by the ECS contained in the data and signature data of the SM‑DP+ server through the GSMA Root CI certificate; if verified, providing an activation code to the terminal, and displaying a QR code on the screen of the first terminal.

Description

Technical Field

[0001] The present disclosure relates to a method and apparatus for transmitting and reinstalling access information of a communication system installed in one device in a wireless communication system to another device. Background Art

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

[0003] The Internet is a human-centered connectivity network where humans generate and consume information, and is now developing into the Internet of Things (IoT), where distributed entities such as things exchange and process information without human intervention. The Internet of Everything (IoE) has emerged, which is a combination of IoT technology and big data processing technology through connection with cloud servers. Technology elements such as "sensing technology", "wired / wireless communication and network infrastructure", "service interface technology" and "security technology" have recently been studied for IoT implementation, sensor networks, machine-to-machine (M2M) communication, machine type communication (MTC), etc. This IoT environment can provide intelligent Internet technology services that create new value for human life by collecting and analyzing data generated between connected things. Through the integration and combination between existing information technology (IT) and various industrial applications, IT can be applied to various fields, including smart homes, smart buildings, smart cities, smart cars or connected cars, smart grids, health care, smart devices and advanced medical services.

[0004] In line with this, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, machine type communications (MTC), and machine-to-machine (M2M) communications can be implemented through beamforming, MIMO, and array antennas. Cloud radio access networks (RANs) as an application of the above-mentioned big data processing technologies can also be considered as an example of the fusion between 5G technologies and IoT technologies.

[0005] A Universal Integrated Circuit Card (UICC) is a smart card inserted and used in a mobile communication terminal, and is also referred to as a UICC card. A UICC may include an access control module for accessing a network of a mobile communication service provider. Examples of access control modules include a Universal User Identity Module (USIM), a User Identity Module (SIM), and an IP Multimedia Service Identity Module (ISIM). A UICC including a USIM is generally referred to as a USIM card. Similarly, a UICC including a SIM module is generally referred to as a SIM card. In the following description of the present disclosure, the term "SIM card" will be used in a general sense, including a UICC card, a USIM card, a UICC including an ISIM, and the like. That is, the technical application of a SIM card can even be equally applied to a USIM card, an ISIM card, or a universal UICC card.

[0006] The SIM card stores the personal information of mobile communication users, performs user authentication and generates service security keys when accessing the mobile communication network, thereby achieving safe mobile communication use.

[0007] The SIM card is usually produced as a dedicated card for the corresponding provider by request of a specific mobile communication service provider when producing the card, and authentication information for network access of the provider (e.g., Universal Subscriber Identity Module (USIM) application and International Mobile Subscriber Identity (IMSI), K value, OPc value, etc.) is preloaded into the card, and the card is activated. Thus, the produced SIM card is delivered to the corresponding mobile communication service provider and provided to the user, and then, if necessary, the management of installation, modification and deletion of applications in the UICC can be performed using technologies such as Over the Air (OTA). The user can insert the UICC card into his mobile communication terminal to use the network and application services of the mobile communication service provider, and when replacing the terminal, by moving the UICC card from the existing terminal and inserting it into the new terminal, the user can use the authentication information, mobile communication phone number, personal phone book, etc. stored in the UICC card as is in the new terminal.

[0008] However, SIM cards are inconvenient for mobile communication terminal users to receive services from other mobile communication companies. It is inconvenient for mobile communication terminal users to physically obtain SIM cards to receive services from mobile communication service providers. For example, when traveling to another country, it is inconvenient for users to obtain local SIM cards to receive local mobile communication services. Roaming services solve the above inconveniences to some extent, but there are problems that services cannot be provided without contracts between communication companies and the cost is high.

[0009] In the case of remotely downloading the SIM module and installing it in the UICC card, this inconvenience can be solved to a large extent. That is, the SIM module of the mobile communication service that the user wants to use at the desired time point can be downloaded to the UICC card. This UICC card can download and install multiple SIM modules, and only select and use one SIM module among the multiple SIM modules. This UICC card can be fixed to the terminal or not fixed to the terminal. In particular, the UICC fixed to the terminal and used in the terminal is called an embedded UICC (eUICC), and eUICC generally means a UICC card fixed to the terminal and used in the terminal, and can be selected by remotely downloading the SIM module. In the present disclosure, UICC cards that can remotely download and select SIM modules will be collectively referred to as eUICCs. That is, UICC cards that are fixed or not fixed to the terminal in the UICC card that can remotely download and select the SIM module are collectively referred to as eUICCs. In addition, the downloaded SIM module information will be collectively referred to as the term eSIM profile. That is, in the UICC card that can remotely download and select the SIM module, the UICC card fixed to the terminal and the UICC card not fixed to the terminal are collectively referred to as eUICCs. Furthermore, the downloaded SIM module information will be collectively referred to as the term configuration file.

[0010] In order to take full advantage of downloading the SIM module of the mobile communication service to the UICC card and turning on the communication service, the communication service provider introduces the on-device service activation service in the terminal. On-device service activation is a general term for a solution that enables users to subscribe to and turn on new communication services through a web portal or app in the terminal, or to transfer, install and turn on communication services when changing devices. The on-device service activation service can be used interchangeably with the terms ODSA or ODA. In addition, the module that needs to be installed in the terminal to support ODSA is called an ODSA client, and the ODSA client can be used interchangeably with the terms ODSA or ODA.

[0011] In order to determine whether a terminal or user who wants to use a specific service has the right to access or use the corresponding service, the service provider can introduce a rights configuration server (ECS). The ECS can consider the user information of the terminal user and the network status of the terminal to determine whether the requesting terminal can provide a communication-based service, and in the case where the requesting terminal can provide a communication-based service, the ECS can send predetermined information to the terminal to provide the communication-based service to the terminal. ECS is currently being introduced for services such as Voice over LTE (VoLTE), Voice over Wi-Fi (VoWiFi), and Device Service Activation (ODSA). In ODSA, ECS acts as the provider's ODSA gateway server accessed by the terminal's ODSA client, and the message protocol between the ODSA client and ECS is defined by the GSM Association (GSMA) in the TS.43 standard. The ECS address can be expressed in various ways, but an example of an expression is a fully qualified domain name (FQDN), which can be as shown in ase.mnc according to the combination of MCC and MNC. <mnc>.mcc <mcc>.pub.3gppnetwork.org, MCC and MNC are inherent identification numbers of communication service providers. <mnc>and <mcc>are the decimal formats of the corresponding MNC and MCC, and when the corresponding information is two digits, <mnc>and <mcc>It can be made into a three-digit number by adding 0 to the beginning.

[0012] When replacing a terminal, by moving and inserting the SIM card from the existing terminal to the new terminal, a communication service user can use mobile communication network access because it uses the authentication information stored in the UICC card. However, in the case of a terminal equipped with an eUICC, the downloaded configuration file is decoded and installed only inside the eUICC, and after the configuration file is installed, the configuration file cannot be extracted to the outside of the terminal again, thereby making it necessary to download and (re)install the configuration file in the new terminal.

[0013] At the time of disclosing this article, in order to deliver and install communication services when changing the device of a terminal equipped with an eUICC, communication service providers are standardizing a method using LPA and SM-DP+ and a method using an ODSA client and ECS to GSMA, and it is expected that communication service providers will select one of these methods to support the delivery installation of communication services. However, according to each method, the support is only available in an existing terminal (an existing terminal with a profile installed) or a new terminal to be changed; therefore, the user cannot perform the delivery installation of the communication service according to a combination of the user-started terminal and the provider's support method, which is inconvenient. This will refer to Figure 2 Further description.

[0014] Existing mobile communication companies provide a process for verifying the identity of the user or an ID authentication process when the SIM card is lost to reissue the SIM card, and this process can be applied to the purpose of downloading the configuration file to the eUICC of the new terminal when the device of the terminal equipped with the eUICC is changed. However, such a process is usually only processed when the user visits an offline branch, or when such a process is processed online, a stricter identity authentication or ID verification process is required compared to the offline branch. When changing the terminal, in order to reinstall the configuration file to the new terminal, there is the inconvenience that the user must go through such a strict identity authentication or ID verification process. In the case where the user has an existing terminal, the communication service provider can use the EAP-AKA method to authenticate the user. The EAP-AKA method is a method that the communication service provider generally uses for user authentication in communication services, but only when the SIM module is activated can the authentication be performed so that the SIM information can be accessed. When the SIM module is not activated, the EAP-AKA method cannot be used. Summary of the invention

[0015] Technical issues

[0016] The technical problem to be solved by the present disclosure is to use the communication service used in the existing terminal in the communication system by reinstalling / opening the communication service to the replaced new terminal. To this end, when a new eUICC profile corresponding to a profile stored in the eUICC of the existing terminal is downloaded and installed online, a device transfer method is selected in consideration of a combination of a user-initiated terminal and a provider-supported method. In particular, the present disclosure provides a method for supporting an ODSA method in an existing terminal and supporting an LPA method in a new terminal. In addition, the present disclosure provides a download method that does not require a separate user ID authentication, and the download method can be provided even when the SIM module is disabled.

[0017] Solution to the problem

[0018] Technical problems to be solved in the embodiments of the present disclosure are not limited to the above-mentioned technical problems, and other technical problems not described will be clearly understood from the following description by ordinary technicians in the technical field to which the present disclosure belongs.

[0019] According to the disclosed content for solving the above-mentioned problems, a method performed by a terminal in a wireless communication system may include: obtaining information related to device transmission; determining a device transmission method based on the information related to the device transmission; sending a first message including information related to authentication and an identifier of the terminal to a server through the determined device transmission method, wherein the server is identified based on the information related to the device transmission; and receiving a second message including an authentication method determined by the server from the server based on the information related to authentication and the identifier of the terminal.

[0020] In some examples, the device transfer method may be at least one of an On-Device Service Activation (ODSA) method or a Local Profile Assistant (LPA) method.

[0021] In some examples, the information related to the device transmission may be acquired through at least one of information received by the second server, information pre-stored in the terminal, or profile metadata information.

[0022] In some examples, the authentication method may be at least one of authentication using Subscription Manager Data Preparation + (SM-DP +), Extensible Authentication Protocol for Third Generation Authentication and Key Agreement (EAP-AKA) authentication, authentication using Rights Configuration Server (ECS) and SM-DP +, or authentication based on OAuth / Open ID protocol.

[0023] In another example of the present disclosure, a method performed by a server in a wireless communication system may include: receiving a first message including authentication-related information and an identifier of the terminal from the terminal through a device transmission method determined by the terminal; determining a processable authentication method based on the authentication-related information and the identifier of the terminal; and sending a second message including the determined authentication method to the terminal, wherein the device transmission method is determined based on the device transmission-related information obtained by the terminal.

[0024] In another example of the present disclosure, a terminal may include: a transceiver configured to send and receive at least one signal; and a controller connected to the transceiver, wherein the controller may be configured to: obtain information related to device transmission; determine a device transmission method based on the information related to the device transmission; send a first message including information related to authentication and an identifier of the terminal to a server through the determined device transmission method, wherein the server is identified based on the information related to the device transmission; and receive a second message including an authentication method determined by the server from the server based on the information related to authentication and the identifier of the terminal.

[0025] In another example of the present disclosure, a server may include: a transceiver configured to send and receive at least one signal; and a controller coupled to the transceiver, wherein the controller may be configured to: receive a first message including authentication-related information and an identifier of the terminal from the terminal through a device transmission method determined by the terminal; determine a processable authentication method based on the authentication-related information and the identifier of the terminal; and send a second message including the determined authentication method to the terminal, wherein the device transmission method is determined based on the device transmission-related information obtained by the terminal.

[0026] According to an embodiment of the present disclosure for solving the above-mentioned problem, a method performed by a first terminal may include: receiving an input for moving an installed first profile, obtaining information about whether device transmission of a communication service provider is supported and a supporting method; sending predetermined information required for selecting a user authentication method to an ECS, the user authentication method including support for a profile server authentication method; obtaining ECS ​​generated data and a profile server address, proving that it is an ECS request for user authentication processing from the ECS to the profile server; performing user authentication through the profile server, and replying the result thereof to the ECS.

[0027] According to an embodiment of the present disclosure for solving the above-mentioned problem, a method performed by a terminal may include: determining a provider support method to be used in the terminal by identifying a user launching the terminal and a provider support method, and collecting user authentication methods supportable in the terminal, and sending the collected user authentication methods to an ECS server.

[0028] According to an embodiment of the present disclosure for solving the above-mentioned problem, the method performed by the ECS may include: selecting an authentication method with reference to possible authentication method information provided by the first terminal; generating predetermined data for authentication according to the selected authentication method, and sending the predetermined data to the terminal; verifying the user authentication result received from the terminal; processing a series of processes required for device transmission according to the verification result, and sending predetermined information required for configuration file download to the first terminal.

[0029] According to an embodiment of the present disclosure for solving the above-mentioned problem, a method performed by a profile server may include: receiving a user authentication request including data generated by an ECS from a first terminal; performing user authentication on the first terminal and replying with a result.

[0030] According to an embodiment of the present disclosure for solving the above problem, the method executed by the second terminal may include: acquiring, from the first terminal, predetermined information sent by the ECS to the first terminal; sending the predetermined information to a configuration file server, receiving and installing the configuration file.

[0031] The technical problems to be solved in the present disclosure are not limited to the above-mentioned technical problems, and other technical problems not described will be clearly understood from the following description by ordinary technicians in the technical field to which the present disclosure belongs.

[0032] Advantageous Effects of the Invention

[0033] According to an embodiment of the present disclosure, in a method for transmitting and installing a communication service when changing the device of an eSIM terminal of a communication service provider, a seamless UI / UX can be provided to the user in consideration of the combination of the device transmission support method of the communication service provider and the device transmission start terminal of the user. In addition, when the user replaces a terminal equipped with an eUICC, the terminal and the ECS can use the authentication information of the USIM or the profile server to conveniently move the profile from the device to another device without entering additional information about the user identity authentication information. In particular, even in the case where USIM authentication is not possible, the authentication information of the profile server can be used to conveniently move the profile from the device to another device without entering an ID to the user. In addition, the communication service provider can delete the profile installed in the existing terminal as needed so that the profile can be reused later. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 is a block diagram showing the configuration of a communication system to which an embodiment of the present disclosure is applied;

[0035] Figure 2 is a diagram showing whether device transfer is supported according to a combination of a user activation terminal of a communication company and a communication service mobility support method for eSIM device transfer;

[0036] Figure 3 is a flow chart showing the eSIM device transfer processing and determination criteria of a terminal;

[0037] Figure 4 is a message flow diagram showing a method for obtaining eSIM device transmission configuration information of a provider in a terminal;

[0038] Figure 5A is a message flow diagram showing an embodiment in which a communication company provides an ODSA method and uses EAP-AKA authentication;

[0039] Figure 5B is a message flow diagram showing an embodiment in which a communication company provides an ODSA method and uses ECS / SM-DP+ authentication;

[0040] Figure 5C is a message flow diagram illustrating an embodiment of a process for a user interface (UI) and user experience (UX) when a communications company provides an LPA method and a user initiates a device transfer;

[0041] Figure 5D is a diagram showing a representative process of UI and UX transmitted by an eSIM device started in a first terminal;

[0042] Fig. 6A is a message flow diagram showing an embodiment in which a communication company provides an ODSA method and uses OTP or OAuth / Open ID authentication;

[0043] Figure 6B is a message flow diagram showing an embodiment in which a communication company provides an LPA method and uses LPA and SM-DP+ authentication in a first terminal (old terminal);

[0044] Figure 6C is a diagram showing a representative process of UI and UX transmitted by an eSIM device activated in a second terminal;

[0045] Figure 7 is a block diagram illustrating a block configuration of a terminal in a wireless communication system according to an embodiment of the present invention. DETAILED DESCRIPTION

[0046] Hereinafter, the working principle of the present disclosure will be described in detail with reference to the accompanying drawings. In the following description, when describing the present disclosure, in the case where it is determined that the detailed description of the relevant known functions or structures may unnecessarily obscure the main points of the present disclosure, the detailed description thereof will be omitted. The terms described below are defined in consideration of the functions in the present disclosure, which may vary according to the intentions or habits of the users and providers. Therefore, they should be defined based on the content in the full text of this specification. For the same reason, some components are enlarged, omitted or schematically shown in the accompanying drawings. In addition, the size of each component does not fully reflect the actual size. In each of the accompanying drawings, the same reference numerals represent the same or corresponding components. With reference to the embodiments described in detail below in conjunction with the accompanying drawings, the advantages and features of the technical ideas of the present disclosure and the methods for implementing them will become apparent. However, the present disclosure is not limited to the embodiments disclosed below, but can be implemented in various different forms, and only the embodiments of the present disclosure enable the present disclosure to be completed, and are provided to fully inform the scope of the present disclosure to the ordinary technicians in the field to which the present disclosure belongs, and the present disclosure is limited only by the scope of the claims. Throughout the specification, the same reference numerals represent the same components. In addition, when describing the present disclosure, in the case where it is determined that the detailed description of the relevant function or configuration may unnecessarily obscure the subject matter of the technical idea according to the present disclosure, its detailed description will be omitted. The terms described below are defined in consideration of the functions in the present disclosure, which may vary according to the intentions or habits of users and providers. Therefore, they should be defined based on the content in the full text of this specification.

[0047] In the following, a base station is an object for performing resource allocation of a terminal, and may be at least one of a gNode B, an eNode B, a Node B, a base station (BS), a wireless access unit, a base station controller, or a node on a network. The terminal may include a user equipment (UE), a mobile station (MS), a cellular phone, a smart phone, a computer, or a multimedia system capable of performing a communication function. In the present disclosure, a downlink (DL) is a wireless transmission path for a signal sent from a base station to a terminal, and an uplink (UL) is a wireless transmission path for a signal sent from a terminal to a base station. In the following, although an LTE or LTE-A system may be described as an example, the embodiments of the present disclosure may be applied to other communication systems having similar technical backgrounds or channel types. For example, a 5G mobile communication technology (5G, new radio (NR)) developed after LTE-A may be included in a system to which an embodiment of the present disclosure may be applied, and the following 5G may be a concept including existing LTE, LTE-A, and other similar services. In addition, the present disclosure may be applied to other communication systems by determining a technician with skilled technical knowledge by some modifications within the scope of the present disclosure that do not significantly deviate from the present disclosure. In this case, it will be understood that each block of the message flow diagrams and combinations of the message flow diagrams can be implemented by computer program instructions.

[0048] Because these computer program instructions can be installed in a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, the instructions executed by the processor of the computer or other programmable data processing device generate means for performing the functions described in the message flow diagram block. Because these computer program instructions can be stored in a computer-usable or computer-readable memory, which can guide the computer or other programmable data processing device to implement the functions in a specific manner, the instructions stored in the computer-usable or computer-readable memory can produce a product containing instruction means for performing the functions described in the message flow diagram block. Because the computer program instructions can be installed on a computer or other programmable data processing device, a series of operational steps are performed on the computer or other programmable data processing device to generate a computer-implemented process; therefore, the instructions for executing the computer or other programmable data processing device can provide steps for performing the functions described in the message flow diagram block.

[0049] In addition, each block can represent a module, segment or a part of code including one or more executable instructions for performing a specified logical function. In addition, it should be noted that in some alternative implementations, the functions stated in the frame can occur out of order. For example, the two blocks shown in sequence can actually be executed substantially simultaneously, or these blocks can sometimes be executed in reverse order according to the corresponding functions. In this case, the term "unit" used in the present embodiment means software or hardware components, such as field programmable gate arrays (FPGAs) or application specific integrated circuits (ASICs), and "units" perform certain roles. However, "units" are not limited to software or hardware. "Units" can be configured to be inherently stored in addressable storage media, or can be configured to reproduce one or more processors. Therefore, as an example, "units" include components such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcodes, circuits, data, databases, data structures, tables, arrays and variables. The functions provided in components and "units" can be combined into smaller amounts of components and "units", or can be further separated into additional components and "units". In addition, components and "units" can be implemented to reproduce one or more CPUs in a device or secure multimedia card. In addition, in one embodiment, a "unit" can include one or more processors.

[0050] First, the terms used in this specification are defined.

[0051] In this specification, UICC is a smart card used by being inserted into a mobile communication terminal, and refers to a chip that implements secure mobile communication by performing user authentication and service security key generation when accessing mobile communication systems such as GSM, WCDMA, LTE, and 5G by storing personal information such as network access authentication information, SMS, and phone books of mobile communication users. Depending on the type of mobile communication network accessed by the user, the UICC can be loaded with communication applications such as a subscriber identity module (SIM), a universal SIM (USIM), and an IP multimedia SIM (ISIM), and provides advanced security functions for loading various applications such as electronic wallets, ticketing, and electronic passports.

[0052] In this specification, an embedded UICC (eUICC) is a security module in the form of a chip embedded in a terminal, rather than a removable type that can be inserted into or removed from a terminal. The eUICC can be installed by downloading a configuration file using over-the-air (OTA) technology. The eUICC can be referred to as a UICC that can download and install a configuration file.

[0053] In this specification, the method of downloading and installing a configuration file in an eUICC using OTA technology can be applied to a removable UICC that can be inserted into and removed from a terminal. That is, the embodiments of the present disclosure can be applied to a UICC that can be installed by downloading a configuration file using OTA technology.

[0054] In this specification, the term UICC may be used interchangeably with SIM, and the term eUICC may be used interchangeably with eSIM.

[0055] In this specification, the profile may mean that an application, a file system, an authentication key value, etc. stored in the UICC are packaged in the form of software. In addition, the profile may be referred to as access information.

[0056] In this specification, a USIM profile may have the same meaning as a profile, or may mean that information in a USIM application included in a profile is packaged in the form of software.

[0057] In this specification, the profile server includes the functions of generating a profile, encrypting the generated profile, generating profile remote management instructions, or encrypting the generated profile remote management instructions, and can be expressed as subscription manager data preparation (SM-DP), subscription manager data preparation + (SM-DP +), or subscription manager secure routing (SM-SR).

[0058] The term "terminal" or "device" used in this specification may be referred to as a mobile station (MS), a user equipment (UE), a user terminal (UT), a wireless terminal, an access terminal (AT), a terminal, a user unit, a subscriber station (SS), a wireless device, a wireless communication device, a wireless transmit / receive unit (WTRU), a mobile node, a mobile or other terms. Various embodiments of the terminal may include a cellular phone, a smart phone with a wireless communication function, a personal digital assistant (PDA) with a wireless communication function, a wireless modem, a portable computer with a wireless communication function, a photographing device such as a digital camera with a wireless communication function, a gaming device with a wireless communication function, a music storage and playback device with a wireless communication function, an Internet home appliance capable of performing wireless Internet access and browsing, and a portable unit or terminal including a combination of such functions. In addition, the terminal may include a machine-to-machine (M2M) terminal and a machine type communication (MTC) terminal / device, but is not limited thereto. In this specification, a terminal may be referred to as an electronic device or simply a device.

[0059] In this specification, a terminal or device may include software or an application installed in the terminal or device to control the UICC or eUICC. The software or application may be referred to as, for example, a local profile assistant (LPA). In this specification, an eUICC identifier (eUICC ID) may be an inherent identifier of an eUICC embedded in a terminal and is referred to as an EID.

[0060] In this specification, an application protocol data unit (APDU) may be a message used for interaction between a controller in a terminal or device and an eUICC.

[0061] In this specification, a profile package may be used interchangeably with a profile or may be used as a term for a data object indicating a specific profile, and is referred to as a profile TLV or a profile package TLV. A profile identifier is an inherent identification number of a profile, and may be referred to as an integrated circuit card identifier (ICCID). In the case where a profile package is encrypted using encryption parameters, the profile package may be referred to as a protected profile package (PPP) or a protected profile package TLV (PPPTLV). In the case where a profile package is encrypted using encryption parameters that can only be decrypted by a specific eUICC, the profile package may be referred to as a binding profile package (BPP) or a binding profile package TLV (BPP TLV). A profile package TLV may be a data set representing information constituting a profile in a TLV (tag, length, value) format.

[0062] In this specification, AKA is Authentication and Key Agreement and may indicate an authentication algorithm for accessing 3GPP and 3GPP2 networks. K is an encryption key value stored in the eUICC for the AKA authentication algorithm, and in this specification, OPc is a parameter value that may be stored in the eUICC for the AKA authentication algorithm.

[0063] In this specification, NAA is an application program for network access application, and may be an application program stored in UICC or eUICC to access the network, such as USIM or ISIM. NAA may be a network access module.

[0064] In this specification, ECS may be used interchangeably with rights configuration server, subscription authentication server, subscription server, rights authentication server, and rights server (ES), and ODSA client may be used interchangeably with ODSA and ODA.

[0065] In this disclosure, end user, user, user, service user and user refer to a person who performs device transfer and may be used interchangeably.

[0066] In the present disclosure, eSIM transfer, device transfer, subscription transfer, movement, and profile movement of subscription information between terminals of a communication service when changing devices mean profile movement corresponding to USIM card movement when a device equipped with an eUICC is changed from a first terminal to a second terminal, and can be used interchangeably. This should be interpreted according to the context.

[0067] Furthermore, in describing the present disclosure, in the case where it is determined that a detailed description of a related function or configuration may unnecessarily obscure the subject matter of the present disclosure, the detailed description thereof will be omitted.

[0068] Hereinafter, embodiments presented through the accompanying drawings will be described.

[0069] Figure 1 is a block diagram illustrating the configuration of a communication system to which an embodiment of the present disclosure is applied.

[0070] exist Figure 1 In the figure, the part marked with slashes indicates the standard entities and interfaces defined in GSMA TS.43, and the shaded part indicates the standard entities and interfaces defined in GSMA.22. In the present disclosure, the terminal user 100 is a user who performs profile movement between devices, and the device 105 means a terminal or device capable of wireless communication services. The device 105 includes the LPA 140 and the eUICC 160, and in the case of supporting the rights configuration exchange with the ECS, the device 105 includes the ODSA client 110. The LPA 140 and the SM-DP + 150 are standard entities defined in GSMA SGP.22, and the LPA may involve moving the profile to another profile when downloading and installing the profile in the eUICC and when changing the device. The terminal 105 may receive an input of the profile movement from the user 100 from the ODSA client 110 or the LPA 140, and start the device transfer process. In this case, in the absence of predetermined information and processing methods on whether predefined device transmission is supported, etc., the terminal can access the configuration server 170, which is a separate server, in order to obtain information, and obtain and utilize all or part of the information necessary for determining the device transmission method of the terminal. The configuration server 170 may be implemented separately or as one of the BSS / OSS 130 of the communication service provider. The mobile network operator (MNO) BSS / OSS 130 is a server system for the communication service provider to operate and process communication services, and is also referred to as the backend system of the communication company, and in some descriptions of the present disclosure, the MNO BSS / OSS 130 and the communication service provider may be used interchangeably. The MNO BSS / OSS may perform subscription and cancellation of communication services in the eUICC device, and process device transmission by exchanging information with the SM-DP+150 server (which is a configuration file server) or the ECS 120 (which is a server that handles service subscription management). The ECS 120 and the SM-DP+150 server may interwork with the backend system of the communication service provider, and may be implemented independently of the backend system of the communication service or as part of the backend system. The ODSA client 110 and the LPA 140 may be integrated into one application, or may be implemented separately. Figure 1 The configuration server 170 is shown to be connected to the ODSA client 110, but the present disclosure is not limited thereto, and other applications of the terminal or LPA may directly access the configuration server 170 to obtain information for device transfer processing and processing subsequent processes.

[0071] Figure 2 2 is a diagram showing whether device transfer is supported according to a combination of a user activation terminal of a communication company and a communication service mobility support method for eSIM device transfer.

[0072] As described above, when changing the device of the eUICC terminal, it is expected that two methods coexist in the method of transmitting and installing the communication service, and it is expected that the provider will select and support one of these methods. The As-Is table 200 indicates the method that can be provided by considering the combination of the user-initiated terminal and the provider-supported method at the time point of disclosing this article. The provider-supported method is the ODSA method, and the provider does not provide the user to initiate the device transmission in the first terminal 300, and the processing process is not defined in the TS.43 standard. In the case where the provider-supported method is the LPA method and the user starts to change the device in the second terminal 350, there is no method for the second terminal 350 to process the method. Because the LPA method uses the ICCID information of the profile to move the one that has been installed in the terminal, the method is a method that the second terminal 350 cannot currently support, but in the case where the user 100 can use the first terminal, the method can be used by allowing it to be processed by the corresponding terminal. However, at the time point of disclosing this article, the terminal does not provide a corresponding processing method. Therefore, the method of device transmission to be provided when the present disclosure is introduced is shown in the future table 210. In the original table 200, all parts marked as unsupported, i.e., FAIL, can be supported by the present disclosure, and for this purpose, reference is made to Figure 5D and Figure 6C The user interface (UI), user experience (UX), and call flow to support this scenario are shown.

[0073] Figure 3 is a flow chart showing the eSIM device transfer processing procedure and determination criteria of a terminal.

[0074] First, when the configuration file is moved when the device is changed, the terminal 105 can determine whether the terminal generating the event of the user performing the device transfer is an existing terminal in which the existing configuration file is to be moved or a new terminal in which the configuration file is to be reinstalled. Hereinafter, for the sake of convenience of description, the terminal in which the existing configuration file is to be moved will be referred to as the first terminal 300, and the terminal in which the configuration file is to be reinstalled will be referred to as the second terminal 350. The device 105 can be used without having to distinguish between the first terminal and the second terminal. The device 105 can identify whether the user is inputting from the first terminal or the second terminal by separating the input menu of the user 100. As will be referred to later Figure 4 As described, when the user selects the device transfer menu in the device 105 and inputs a device transfer request (300), the device 105 can identify information collected through information pre-stored in the terminal and the configuration server 170 or metadata of the profile to identify whether the communication service provider supports device transfer (305) and the support method (310) for the profile, and when performing device transfer, the device 105 can identify the state of the terminal, including information about whether the device transfer requesting terminal 105 is the first terminal 300 or the second terminal 350, and finally determine (310) the device transfer method of the communication service to be used by the terminal 105. Whether device transfer (305) is supported refers to determining whether a profile previously installed in the eUICC of the first terminal 300 can be downloaded to the second terminal 350 as a profile having the same communication service subscription configuration.

[0075] After identifying whether the communication service provider supports device transfer of the profile (305) and the support method 310, the terminal 105 can obtain information about whether it supports the device transfer method of the communication service provider using the ODSA client and ECS as the device transfer support method of the profile, or information about whether it supports the device transfer method using the LPA and SM-DP+ server. The communication service provider may support one or more of the above two device transfer methods. In the case where there are one or more device transfer support methods for the profile moved by the communication service provider collected from the terminal, the communication service provider may additionally store information about the priority of applying the device transfer method to the profile metadata or the configuration server 170, and provide the information to the terminal. In addition, the terminal 105 may display a screen requesting selection to the user 100 so that the user can select it, or may select and use one of the two methods according to the terminal basic configuration. The device transfer method using the ODSA client and ECS will be described in the ODSA method so as to be described later, and the device transfer method using the LPA and SM-DP+ server will be described in the LPA method, and the detailed process including each device transfer method will be referred to. FIG. 5A to FIG. 5D as well as FIG. 6A to FIG. 6C Detailed description. In the case where the terminal 105 should be processed in the LPA method according to the information acquired in the above method, the subsequent process should be performed differently depending on whether the terminal 105 that initiates the device transfer is the first terminal 300 or the second terminal 350. In the case where the device transfer method of the provider acquired by the terminal 105 is the LPA method and the terminal 105 that initiates the device transfer is the first terminal 300, the LPA 140 of the terminal may request a command for requesting a profile move, the command including predetermined information about the profile to change the device to the SM-DP+ 150. The SM-DP+ 150 may notify the communication service provider 130 of the device transfer request and create a profile that will be downloaded for device transfer in the second terminal 350 and in the communication service provider 130 through the ES2+ interface defined in GSMA SGP.22. The SM-DP + 150 may exchange (mutually authenticate) the signature value of the eUICC certificate and the SM-DP + between the SM-DP + 150 and the eUICC 160 of the first terminal 300 in which the profile to be moved is installed, and authenticate the user by authenticating the eUICC 160 and the terminal in which the profile is installed. Hereinafter, for the convenience of description, in the present disclosure, the above method will be referred to as the SM-DP + authentication method 315. When the user is authenticated by the SM-DP + authentication, the SM-DP + 150 may transmit data necessary for downloading the profile to be generated in the second terminal 350 to the first terminal 300. When the first terminal 300 acquires the corresponding data and displays the data in the first terminal 300 in the form of a quick response (QR) code, the second terminal 350 may scan (340) the QR code displayed on the screen of the first terminal, and receive and install the profile from the profile server 150 included in the QR code, thereby completing (390) the profile transmission installation according to the device transfer. Instead of displaying the information with the QR code, the first terminal 300 may transmit the information to the second terminal 350 via short-range communication such as NFC, Bluetooth, UWB, or WiFi communication or a server. However, in the case where the first terminal 300 displays the information in the QR code, the second terminal 350 may install the profile through a normal eSIM profile download process of scanning the QR code; therefore, it is advantageous to perform the device transfer operation without modifying the existing profile download process. In the following, an example of using a QR code is shown, but the embodiments of the present disclosure are not limited thereto. The following shows an example of a configuration of data required to download a profile to be displayed in a QR code.

[0076] LPA:x$SMDP.TEST.COM$XXXXX

[0077] In the above example, SMDP.TEST.COM represents the configuration file server address as an example, $ is a separator to distinguish each information, LPA: indicates that the data is an activation code format for downloading a configuration file, x represents the type of activation code, and the value can be a number, such as 1, or 2, or 3, or 4, for example, and XXXXX is the data of the activation code token (ACToken) area, which can be information encoding information including part or all of the following ASN.1Data, and is marked with XXXXX for convenience.

[0078] ASN.1Data

[0079] OtherSignedNotification::=SEQUENCE{

[0080] tbsOtherNotification NotificationMetadata,

[0081] euiccNotification signature [APPLICATION 55] OCTET STRING, --eUICC signatureof tbsOtherNotification, Tag '5F37'

[0082] euiccCertificate Certificate,--eUICC Certificate(CERT.EUICC.ECDSA)signed by the EUM

[0083] eumCertificate Certificate--EUM Certificate(CERT.EUM.ECDSA)signed by the requested CI

[0084] }

[0085] NotificationMetadata::=

[47] SEQUENCE{--Tag'BF2F'

[0086] seqNumber[0] INTEGER,

[0087] profileManagementOperation[1]NotificationEvent, / *Only one bit SHALLbe set to 1* /

[0088] notificationAddress UTF8String,--FQDN to forward thenotificationiccid Iccid OPTIONAL

[0089] }

[0090] In this case, the encoding may be 1) encoding the subsequent ASN.1 format data in the DER method and then hexadecimal encoding the data so that the data can be represented in characters; and 2) encoding the subsequent ASN.1 format data in the DER method and then BASE64 encoding the data so that the data can be represented in characters. Hereinafter, for the convenience of description, the corresponding data required to download the configuration file may be collectively referred to as an activation code. Although not described in the drawings, before deleting the configuration file in order to move the configuration file from the first terminal 300, the first terminal 300 may obtain the device information (e.g., eUICCInfo, DeviceInfo) of the second terminal 350, and then send the device information to the configuration file server to check whether the configuration file reinstallation is possible in the second terminal 350, and then perform the subsequent process. In addition, although not described in the drawings, the first terminal 300 may obtain the International Mobile Equipment Identity (IMEI) of the second terminal 350, and request (e.g., marked with *#06# on the terminal keypad) input through the user screen to add and send the IMEI when requesting device transfer to the ECS or LPA. In the case where the device transfer method of the provider acquired by the terminal 105 is the LPA method and the terminal 105 initiating the device transfer is the second terminal 350, the second terminal 350 may create a menu that can guide different processes to the user according to whether the first terminal 300 is available and display the menu on the screen. In the case where the first terminal 300 is available, the second terminal 350 may display a guide message about the process in the first terminal 300 and move to a menu that can scan the QR code displayed from the first terminal 300 and standby. After the user performs the above-mentioned LPA method in the first terminal 300, when the first terminal 300 acquires data required to download the profile from the profile server and displays the data in the form of a QR code, the second terminal 350 may scan (385) the QR code so that the subsequent process is processed in the same manner. In the case where the user 100 inputs that the first terminal 300 does not exist, the second terminal 350 may display a guide message indicating that the communication service provider cannot support the device transfer service of the profile in the absence of the existing first terminal 300, and end (308) the process. In a case where the device transfer method of the provider acquired by the terminal 105 is the ODSA method and the terminal 105 that initiates the device transfer is the first terminal 300, the terminal can collect status information of the profile to be moved installed in the terminal and information about the authentication method implemented in the terminal to send the information from the ODSA client 110 to the ECS 120, and the terminal or the server can determine the authentication method used for the corresponding profile.The profile status information is information about whether the profile is enabled or disabled, and enabled means a state in which the network is activated to a state in which the terminal 105 can access the file data of the corresponding profile. Disabled means a state in which the network is not activated to a state in which the terminal 105 cannot access the file data of the corresponding profile. The terminal may determine the authentication method according to the priority of the authentication method configured therein, and send the authentication method to the ECS 120, and the authentication method may be determined in a manner in which the ECS 120 finally recognizes, determines, and replies. Alternatively, the terminal may send the status information of the profile to be moved from the terminal 120 and information about all authentication methods that the terminal can support to the ECS 120, and the ECS 120 may select an authentication method and reply to the method in the method in consideration of the authentication method and priority of the authentication method application of the service provider for the profile. In the present disclosure, the first terminal 300 may select one of the following methods: an ECS&DP+ method 325 (which is an ECS 120 and SM-DP+150 collaborative authentication method 315), which is an authentication method that can be supported by the terminal to prove ODSA service access qualification; an EAP-AKA method 330 using a k value and an internal mobile subscriber identifier (IMSI) (which is user identifier information stored in a SIM module); and an OAuth / Open ID method 335, which is an authentication method based on web service login, and then identifies whether the corresponding access terminal and user have ODSA service qualification authentication through data exchange with the ECS 120. Reference will be made below. FIG. 5A to FIG. 5D The process including each authentication method is described in detail. When the qualification of the terminal and the subscription of the ODSA service access are authenticated in the ECS 120, the ECS 120 may obtain the data necessary for the second terminal 350 to download the configuration file from the SM-DP+150 through the communication company backend system 130, and reply the data to the ODSA client of the first terminal 300. Alternatively, the communication company backend system 130 may reply a method including obtaining data through data self-generation of the first terminal 300, instead of sending the data required to download the configuration file from the corresponding SM-DP+150. Reference will be made later Figure 5C A detailed method for the first terminal 300 to acquire corresponding data is described. When the data acquired by the first terminal 300 is displayed on the first terminal 300 in the form of a QR code, the second terminal 350 can scan the QR code displayed on the screen of the first terminal 300, and receive and install the profile from the profile server 150 included in the QR code to complete (390) profile movement and installation according to device transfer. In the case where the device transfer method of the provider acquired by the terminal 105 is the ODSA method and the terminal 105 that initiates the device transfer is the second terminal 350, the terminal can acquire corresponding information about whether the first terminal 300 exists from the user 100 through user input. In the case where the information that the user 100 can use the first terminal 300 is input to the second terminal 350, the second terminal 350 can receive the input of the phone number (MSISDN) of the first terminal 300 to receive the authentication code from the user, and send the phone number (MSISDN) to the ECS 120. The ECS 120 can exchange messages with a separate authentication server of a communication company, and the separate authentication server of the communication company can send the authentication code with a text message to the corresponding phone number (MSISDN). When the authentication code with the text message is received in the first terminal 300, the user may input the authentication code into the second terminal 350 to authenticate the existence of the right to access the ODSA service. In the case where the device transmission method of the provider acquired by the terminal is the ODSA method and the information that the user 100 cannot use the first terminal 300 is input into the second terminal 350, the second terminal 350 may be connected to a web portal or web application to select and authenticate the OAuth / Open ID method 370, which is a user authentication method by a login method. When the authentication access terminal and the corresponding user are qualified to access the ODSA service through such a one-time password or password (SMS-OTP) method 365 or the OAuth / Open ID method 370, the ECS 120 may transmit the data required for the second terminal 350 to download the configuration file from the configuration file server 170 to the ODSA client 110 of the second terminal 350 in the activation code format. Data is sent from the ODSA client 110 of the terminal to the LPA 140, and the LPA 140 may download the profile to be transferred and installed from the SM-DP+ server 150 and install the profile in the eUICC 160 to process the profile movement according to the device transfer. Figure 3 In the following figures, since this point may be compromised, the process for combining and using multiple authentication methods is not described in detail, but is described by Figure 4 The terminal can enhance the authentication for processing device transmission by using one or more authentication methods to process authentication based on the information obtained from the second terminal 350 (e.g., authentication method supported by the provider) and user input (e.g., whether the first terminal is available), profile status information (e.g., profile activation status), etc. For example, when the second terminal 350 uses the ODSA method and the first terminal 300 is available (360), and when the provider supports the OAuth / OpenID and SMS-OTP methods, the second terminal 350 can log in to the provider's web portal in the OAuth / Open ID method 370 to authenticate the user, and the first terminal 300 is available; therefore, the second terminal 350 can also provide authentication through SMS-OTP (355).

[0091] Figure 4 : is a message flow chart showing a method of acquiring configuration information for a profile move process when a device is changed in a terminal 105 equipped with an eUICC.

[0092] In the device 105, in the case where the terminal user 100 selects a profile to be moved to a new terminal when changing the device in the terminal, the terminal can obtain the MCC+MNC (meaning the mobile country code (MCC) and mobile network code (MNC) defined in ITU-T Recommendation E.212) value with the mobile communication company identification information from the metadata information of the profile. Alternatively, in the case where the terminal does not have the profile to be moved, that is, in the case where the new terminal attempts to change the device, the terminal 105 can provide the user 100 with a menu for selecting a communication service provider, thereby obtaining the MCC+MNC information of the communication service provider. Through the MCC+MNC information, the terminal can determine which provider's profile to identify the mobile configuration. In addition, the terminal 105 can provide a menu for moving the profile of the end user 100 to select the information about the start of the process of changing the device of the profile, and whether to access through which terminal of the first terminal 300 or the second terminal 350. The terminal 105 can identify the device transmission configuration information of the provider for the profile movement to select (470) one of the LPA method or the ECS method as the method to be used for the profile movement. The device transmission configuration information required by the terminal may include information about whether the communication service provider for the profile supports device transmission, and includes authentication method identification information and information about preference priority, such as device transmission support method (LPA method or ODSA method) according to the supported method, SM-DP+ server address or ECS address, and supported user authentication methods such as EAP-AKA, ECS&DP+ and OAuth / Open ID. As a method of identifying the device transmission configuration information, the terminal 105 may perform the following operations.

[0093] - Option 1: In the case where the user 100 selects a profile to be moved through the UI of the terminal, the LPA 140 may perform an ES10c.GetProfilesInfo() function call defined in GSMA SGP.22 on the eUICC 160 to obtain status information and metadata information of the profile.

[0094] -Option 2: In order to save memory and battery, the terminal 105 does not receive all device transmission configuration information of the communication service provider stored in the configuration server 170 during a specific period of time or when the terminal is initially started, but when the user 100 selects a communication company in the UI of the terminal 105, the terminal 105 can request the configuration server 170 for the device transmission configuration information about the MCC+MNC of the communication company, and in response to the request, obtain the device transmission configuration information of the specific provider.

[0095] - Option 3: In the case where the configuration server 170 exists to process device transfer and the server address is configured in the terminal 105, the terminal can carry, store and use some or all device transfer configuration information from the server at the initial startup or at a specific period according to the terminal configuration. In the case where the user selects a specific communication service provider or selects a configuration file to be moved, the terminal 105 can identify the corresponding information stored in the memory of the terminal to obtain and utilize the matching value.

[0096] -Option 4: In the case where the device transfer method for each communication service provider or the terminal for the communication service provider is released, the terminal 105 preloads the device transfer method of the communication company, and as described above, when the user 100 selects a profile or a communication service provider of a profile to move from the menu, the terminal 105 can match it to the information stored in the memory to identify the device transfer configuration information.

[0097] The terminal 105 may use one or more of the above four methods in combination, and in the case where the device transmission configuration information obtained through the corresponding options is different, the terminal 105 may determine and configure the method according to the terminal configuration. As an example, the terminal may determine the priority of the metadata of the most recent configuration information or select the configuration file as another example. FIG. 5A to FIG. 5D as well as Figures 6A to 6C The described embodiments describe in detail the process for receiving and using corresponding configuration information for each situation.

[0098] FIG. 5A to FIG. 5D An embodiment of the device transfer method is shown in the case of being started in the first terminal 300. The entire process for the device transfer process can be roughly divided into the following processes: a step of the first terminal 300 determining the eSIM configuration information, a step of performing terminal and user authentication for identifying ODSA service qualifications, a step of issuing an activation code when the authentication is completed, and a step of the second terminal 350 acquiring corresponding information to download the configuration file and complete the mobile installation.

[0099] Figure 5A is a message flow diagram illustrating an embodiment in which a communication company provides an ODSA method and uses EAP-AKA authentication.

[0100] The terminal user 100 may select a profile to be moved for device transfer in the LPA of the first terminal 300, or select a screen of an application in which the LPA is implemented, and select a menu to move the corresponding profile (step 5a-10). When the corresponding menu is selected, the terminal 300 may have the communication service provider identification ID information (MCC+MNC) of the corresponding profile, identify whether the configuration information for changing the eSIM device of the corresponding communication company is stored in the terminal, and the LPA1 140 of the terminal may perform an ES10c.GetProfileInfo() function call defined in GSMA SGP.22 on the eUICC 160 of the terminal to obtain the status information of the corresponding profile. The LPA1 410 may also identify whether the information about device transfer in the metadata of the corresponding profile from the eUICC 160 of the terminal is supported, and whether there is identification information about the support method or server address, so as to perform subsequent processing together with the status information. In steps 5a-10 to 5a-30, the method of identifying by option 1 and option 3 is listed, but the method of acquiring the status information is not limited thereto, and as described above with reference to Figure 4 As described, the state information can be obtained by using and combining one or more of options 1 to 4. Through the collected information, the first terminal 300 can support the ODSA method in which the communication company uses the ODSA client 110 and the ECS 120, and obtain the ECS address for processing the corresponding method, and determine the device transmission method to be processed in the terminal thereafter (step 5a-40). The ODSA client of the first terminal 300 or ODSA1 500 (which is an application that implements the ODSA client) can obtain the state information of the profile obtained through the profile metadata identification from LPA1 510 (step 5a-30), and identify the terminal's ability to collect possible authentication methods of the terminal and send an authentication request to the ECS 120. As an example, the authentication request can be represented as step 5a-50. The corresponding authentication request message may include: IMEI as a terminal identifier, identification information about the authentication method implemented in the terminal, and define and include ICCID, IMEI or Extensible Authentication Protocol (EAP) ID, or a new identifier as identification information, which can infer that the requesting terminal is the first terminal 300 and includes ICCID as the target profile ID to be moved and the status information of the corresponding profile. Among the information included in the authentication request message, information required for device transmission processing, such as identification information indicating that the requesting terminal is the first terminal 300, ICCID as the target profile ID to be moved, and the status information of the corresponding profile may not be added to the authentication request message, but included at the device transmission request time point after the authentication is completed and sent from the terminal (step 5a-160). The identification information about the authentication method implemented in the terminal can be used as an indicator indicating whether the corresponding authentication method has been implemented in the terminal, or has been implemented in the terminal and is available at the corresponding transmission time point. In the case where the ECS120 can determine the profile status information through the identification information about the corresponding authentication method, the terminal can send the message without including the profile status information. As identification information about the authentication method implemented in the terminal, in the case where the Extensible Authentication Protocol for Third Generation Authentication and Key Agreement (EAP-AKA) is implemented in the terminal, the terminal may include the EAP ID in the authentication request and send the authentication request (step 5a-50). In the case where the ECS&DP+ method is used as an authentication method available in the terminal, a new identifier for distinguishing the ECS&DP+ method may be defined, or an existing identifier (e.g., SM-DP+ address) may be used as the corresponding identification information. For the convenience of this disclosure, the corresponding identifier will be referred to as DP+AuthSupport. In the case where the terminal does not have identification information about the authentication method or authentication token, the ECS may determine that the terminal can only provide OAuth / Open ID.When the ECS 120 receives authentication identification information about one or more authentication methods supported by the terminal from the terminal (step 5a-60), for example, when the ECS 120 includes and receives EAP ID as an EAP-AKA identifier and DP+AuthSupport as an identifier for ECS&DP+ authentication, the ECS 120 can select a possible method according to the provider's preference and whether the provider supports the authentication server, and reply to the terminal with the selected method. In step 5a-50, an example of the identification information or new identifier indicating that the requesting terminal is the first terminal 300 may be a new value, such as OldTerminal=True, old terminal ID=old terminal IMEI, or in the case of including the inherent identification number ICCID of the profile to be moved, the ECS 120 may determine the first terminal 300 with old_terminal_iccid=ICCID as an example. In addition, the ECS 120 may combine the corresponding ICCID information and OldTerminal=True or old terminal ID=old terminal IMEI to determine the first terminal 300. The ECS 120 may determine whether a relay with the provider's AAA (Authentication, Authorization, and Accounting) authentication server may be supported in order to perform EAP-AKA authentication, and identify the priority of the authentication method that the provider wants to provide when multiple authentication methods are available. Steps 5a-60 to 5a-170 illustrate a method when the ECS 120 performs authentication with EAP-AKA through a corresponding identifier. As described above, as identification information about the authentication method implemented in the terminal, in the case where the Extensible Authentication Protocol for Third Generation Authentication and Key Agreement (EAP-AKA) is implemented in the terminal, the terminal may send an authentication request including an EAP_ID (step 5a-50). The first terminal 300 may include an International Subscriber Identity Module (IMSI) value selected by the user for moving in the EAP ID to transmit the EAP ID to the configuration file of the ECS 120, and may not obtain a corresponding value, but in the case where EAP-AKA is implemented in the terminal, the first terminal 300 may configure and transmit the EAP ID value to NULL or a null value, or may define and provide a separate identifier or value for indicating the EAP ID value. The IMSI value is information that can be acquired from the internal data of the profile or the metadata of the profile when the status information of the profile is enabled, and it can indicate that EAP-AKA is implemented so that EAP-AKA can be provided and the corresponding authentication can be used at the current request time point when the device transfer is performed. Failure to acquire the corresponding information means that EAP-AKA has been implemented in the terminal at the corresponding time point, but the profile status information is disabled, and the ECS 120 can determine the status information.The first terminal 300 may include and transmit the status information of the profile acquired in step 5a-30 to the ECS 120 together to clearly inform the ECS 120 that EAP-AKA authentication is available in the corresponding terminal (step 5a-50). In the case where EAP-AKA has been implemented in the terminal through the authentication request message received by the ECS 120, but the profile status is disabled, the ECS 120 may reply to the terminal with a provider message, which includes information on whether to perform user authentication using EAP-AKA and a processing guide (step 5a-70). In this case, the terminal may display the provider message to obtain the user's consent, and the user 100 may approve or reject the authentication process with EAP-AKA (step 5a-80). In the case of approval, by temporarily changing the profile status from a disabled state to an enabled state using the eUICC (step 5a-90), the LPA1 510 may obtain the user's consent to enable EAP-AKA authentication, and then, if the user allows, the LPA1 510 may process 10c.EnabldProfile() using the eUICC. When the profile state is changed to the enabled state, LPA1 510 may obtain the profile state information and the IMSI value from the eUICC and send them to ODSA1 500. As in step 5a-95, the ODSA1 500 of the first terminal receiving them may send an authentication request message to the ECS 120 using the EAP_ID as the IMSI value. Alternatively, the ODSA1 500 may additionally include and send the profile state information to notify the ECS 120 that the profile state has been changed and that the EAP-AKA authentication is available. In the case of user rejection (step 5a-170), the first terminal 300 sends a rejection message to the ECS 120, and when the ECS 120 receives the rejection message, the ECS 120 may select an authentication method to be used by referring to another authentication method received by the existing terminal (step 5a-50) to process the authentication process (step 5a-180). The EAP-AKA method may use a question response mechanism and generate an encrypted session through symmetric key-based authentication. When ECS 120 determines that the EAP-AKA method is available together with the authentication identification information of the terminal or a combination of the terminal identification information and the profile status information and selects the EAP-AKA method, ECS 120 may request an EAP-AKA query to provider authentication server 540 (step 5a-120).The provider authentication server 540 executes the AKA algorithm to generate an EAP-AKA challenge value as defined in "RFC4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement" and replies to the ECS 120, and the ECS 120 may reply to the terminal with the EAP-AKA challenge together with the selected authentication method and the required value for verification (step 5a-110). The authentication method selected by the ECS 120 may be notified by a separate delimiter (e.g., AuthType (EAP-AKA) in step 5a-110), or the ECS 120 may be determined by receiving predetermined information that may determine the corresponding authentication method (e.g., receiving only the EAP-AKA challenge value of step 5a-110). When receiving the corresponding EAP-AKA query, the eUICC of the first terminal 300 may use the corresponding challenge value and security key value of the SIM module and the reply information including the result value to perform the EAP-AKA algorithm (step 5a-130). The ECS 120 may relay the received information to the provider authentication server 540, and the provider authentication server 540 may verify the EAP-AKA challenge value according to the value received from the first terminal 300 (step 5a-130), and reply to the ECS 120 (step 5a-140) whether to perform authentication. In the case that the corresponding authentication result is successful (step 5a-140), the ECS 120 may generate an authentication token (AuthToken), which may be used for a session connection with the ECS 120 thereafter, and send the authentication token (AuthToken) to the first terminal 300 (step 5a-150). The first terminal 300 may use the IMEI and the received authentication token as parameters with the inherent identification information of the terminal to request the movement of the device subscribing to the communication service (step 5a-160). As described above, the information required for the device transfer process, such as the identification information indicating that the requesting terminal is the first terminal 300, the ICCID as the target profile ID to be moved, and the status information of the corresponding profile may not be added to the authentication request message, and after the authentication is completed, the method of sending information including the information from the terminal at the device transfer request time point (step 5a-160). This is also applicable to another embodiment in which the first terminal 300 requests the device to transfer.The specific authentication process and parameters between the authentication server and the terminal using EAP-AKA refer to the "RFC4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and KeyAgreement (EAP-AKA)" specification.

[0101] When the corresponding authentication is completed, the ECS 120, the SM-DP+ server 150 and the MNO BSS / OSS 130 may obtain the information necessary to change the service subscription information, and the SM-DP+ server 150 and the MNO BSS / OSS 130 may prepare to generate a configuration file (step 5a-190). In step 5a-190, the ECS 120 may request new subscription information from the backend system of the communication service provider, and the new subscription information includes a subscription ID mapped to the current ICCID of the corresponding configuration file or the IMEI of the new terminal. The MNO BSS / OSS 130, which has received the information, may perform a series of processes for configuration file generation through the SM-DP+ server 150 and the ES2+ interface defined in SGP.22 to obtain information including the ICCID and activation code of the configuration file to be installed in the second terminal 350, and reply the information to the ECS 120. The ICCID and activation code may be obtained and replied to the ECS 120. The information required to change the ECS service subscription information can be updated at the corresponding time point or after a specific time point to change the subscription information stored in the ECS 120. The ECS 120 can send the received activation code to the ODSA1 500 of the first terminal (step 5a-200). According to the provider's policy, the ECS 120 can send (step 5a-200) information including a value on whether to delete the corresponding configuration file from the first terminal 300. When the corresponding information is received, the first terminal 300 displays a method for obtaining the activation code sent from the second terminal 350 to the first terminal 300 using a user guide message of the corresponding terminal (step 5a-210). In the case where the first terminal 300 receives the value on whether to delete from the first terminal 300 together (step 5a-200), the first terminal 300 can guide the user to delete the existing configuration file, and only when the existing configuration file is deleted, the device transmission can be processed, thereby obtaining the user's consent. In the case where the user agrees to the deletion, when the ODSA client or ODSA1 500, which is an application implementing the ODSA client in the first terminal, requests LPA1 510 to delete the profile, LPA1 510 may perform an "ES10c.DeleteProfile" function call for the profile to be moved to delete the profile from the eUICC, and reply to LPA1 510 or ODSA1 500 with a notification about the deletion of the profile. When ODSA1 500 receives the notification of the deletion of the profile through LPA1 510 or LPA1, the UE may process to activate and provide an activation code. The terminal user 100 may obtain the activation code from the second terminal 350 according to the guidance in step 5a-210 (step 5a-220).For example, the activation code may be displayed in the form of a QR code together with the user UI of the second terminal 350, and the QR code may be scanned using the camera of the first terminal 300. When the activation code is input to the second terminal 350, the LPA 2530 may obtain the activation code and access the SM-DP+ server address configured in the activation code to download the configuration file to the second terminal according to the remote SIM provisioning process defined in GSMA SGP.22, thereby completing the installation (step 5a-230). When the download installation process is completed, the MNO's backend system 130 sends the ICCID or ICCID of the new configuration file installed in the second terminal 350 together with the IMEI of the second terminal 350 to the ECS 120, and the ECS 120 matches the ICCID with the ICCID value obtained in (step 5a-120), and in the case where the ICCID and ICCID values ​​are the same, the ECS 120 may update the corresponding subscription information, and optionally reply the update result to the provider backend system 130.

[0102] Figure 5B is a message flow chart showing an embodiment of using the ECS / DP+ method as an authentication method for supporting profile movement of the ODSA method initiated in the first terminal.

[0103] As above Figure 5A As described in steps 5a-10 to 5a-50, the first terminal 300 may obtain configuration information transmitted through the configuration file, storage, and device of the configuration server 170. Thereafter, when performing terminal and user authentication, in the case of performing the ECS&DP+ authentication method, the terminal may request authentication by including an identifier indicating that DP+AuthSupport is possible in the authentication request sent to the ECS 120. In the present disclosure, hereinafter, for the sake of convenience of description, DP+AuthSupport of steps 5a-50 is indicated as an arbitrary identifier, but the present disclosure is not limited to the name, and the terminal may use the SM-DP+ address capable of performing authentication as an identifier having identifier information indicating that authentication can be performed using SM-DP+.

[0104] When receiving the corresponding authentication method, the ECS 120 may identify the capability for supporting the corresponding authentication method by including information about whether the GSMA root authentication issuer (CI) certificate and the SM-DP + address to be redirected in order to perform the corresponding authentication are configured, and determine the processing using the corresponding authentication method. In the case where the terminal uses the SM-DP + address capable of performing authentication as an identifier, the ECS 120 may additionally determine whether to use the received SM-DP + address as the SM-DP + address to be redirected.

[0105] When the corresponding authentication method is determined, the ECS 120 may generate a current value as arbitrary data (step 5b-20), and reply to the first terminal 300 with a message including the ECS&DP+ authentication method, the SM-DP+ server address to be authenticated, and the generated current value (step 5b-30).

[0106] As mentioned above Figure 5A As described above, the ECS 120 may explicitly notify the terminal of the selected authentication type, and even if the selected authentication type is not explicitly provided, the terminal may determine the authentication type by providing predetermined information that the terminal may determine, that is, for example, a reply to the SM-DP+ server address to be authenticated. As an example, the ECS may request redirection to the SM-DP+ server address in order to authenticate using the HTTP "302 Found" response structure replied when the ECS selects the OAuth / Open ID authentication method, and in this case, one of the following examples may be included.

[0107] Example 1) Http Response - 302 Found

[0108] Include the following in your title

[0109] Location:<SM-DP+address to perform authentication> / authorize?

[0110] Include the following in the body

[0111] response type=code&

[0112] scope=SM-DP+Auth&

[0113] nonce=<ECS generation nonce value> &

[0114] Client ID=<ID pre-issued from SM-DP+to be authenticated by ECS> &

[0115] redirect URL=<ECS address encrypted with AES as address to reply>

[0116] Example 2) Http Response - 302 Found

[0117] Location:<SM-DP+address to perform authentication> / authorize?

[0118] Include the following in the body

[0119] response type = SM-DP + Auth &

[0120] nonce=ECS generation nonce value&

[0121] client ID=<ID pre-issued from SM-DP+to be authenticated by ECS> &

[0122] redirect URI= <ECS address encrypted with AES as address to reply

[0123] As in Example 1) or Example 2), in the case where the scope or response type of the HTTP "302Found" response structure includes an identifier indicating DP+ authentication and is replied, the terminal can determine that the ECS request is to utilize ECS&DP+ authentication instead of utilizing the OAuth / Open ID method, and ODSA1 500 can utilize the internal operation of the first terminal 300 to send the received data to LPA1 510 (step 5b-40). As described below, the DP+ authentication process is then performed. In the case of the OAuth / Open ID authentication method, the code received as the response type requires the client ID, redirection URI, and binding, and the initial Http response 302Found includes the client id and redirection URI and should be sent. The OAuth2.0 / OIDC server can pre-issue the client ID of the ECS through a previous contract and have information about the redirection URI, and when the terminal requests authentication with a specific client ID and redirection URI, the OAuth2.0 / OIDC server can verify the information, issue the code, and reply. However, since ECS / SM-DP + authentication can be processed without a previous contract with SM-DP + and ECS, if the Http response 302 Found includes an identifier indicating DP + authentication, even if the Http response 302 Found does not include one or both of the client ID and the redirection URI, the terminal does not treat it as an error, but should process it as a DP + authentication process.

[0124] Although not shown in the drawings, before performing the process between the eUICC and the SM-DP+ (step 5b-50), a mutual authentication process may be performed first. First, the LPA1 510 may request ES10b.GetEUICCChallenge to the eUICC of the first terminal 300 in which the corresponding profile is installed, receive an eUICCChallenge value with a corresponding message value, and send an ES9+.InitiateAuthenticate request message including an eUICCChallenge value to the SM-DP+ 150. The profile server may verify the corresponding value to generate a transaction ID, and generate and respond to the signature of the profile server to obtain data including the transaction ID and the eUICCChallenge value. In this case, the InitiateAuthenticate response message may include a profile signature value and a transaction ID. After receiving the InitiateAuthenticate response message, the first terminal 300 may generate the current value received from the ECS120 (step 5b-40), the ICCID of the device transfer target profile, and the eUICC signature data in which the ICCID is installed, and send the data including them to the SM-DP+ server 150. In addition to the eUICC signature data, the EID may be included, or information that replaces the eUICC signature data may be included, and a message including the EID may be sent. An example of the message sent may be a message such as ES9+.AuthenticateClientRequest(matchingID=ICCID1, AuthRequest(current value, eUICC signature)) (step 5b-50). When the SM-DP+ server 150 receives the AuthenticateClientRequest message, the SM-DP+ server 150 may perform a verification authentication process, which includes the subscription information contained in the AuthenticateClientRequest message, the ICCID of the profile to be transmitted (expressed as ICCID1), and the signature data verification of the eUICC of the first terminal to verify the eUICC installation of the first terminal of the ICCID, generate a signature of the profile server as a verification result, and include an authentication token, which includes the current value, the eUICC signature data, and the signature data of the profile server received in step 5b-50 in the authentication client response message, and reply to the message (step 5b-60). The corresponding reply information may additionally include an EID mapped to the ICCID.An example of a corresponding reply message may be ES9+.AuthenticateClientResponse(AuthResponse(AuthToken(EID, ICCID, CurrentValue, DP+Signature)))(step 5b-60).

[0125] In the SM-DP + 150 server, the signature data verification of the eUICC 160 of the first terminal 300 may be a signature verification of the data including the ICCID or additional data (ECS Nonce, eUICC signature value, processing sequence number) in the ICCID using the certificate of the eUICC 160 of the first terminal 300. The signature verification may be an elliptic curve digital signature authentication (ECDSA). The eUICC certificate may be authenticated by the eUICC manufacturer (EUM) certificate. The EUM certificate may be authenticated by the certificate authority (CA) certificate owned by the profile server 150. The CA certificate may also be referred to as a root certificate issuer (CI) certificate. In addition, the verification process may include a process of identifying that the eUICC finally installed for the ICCID is the eUICC 160 of the first terminal 300, and a process of identifying the validity of the message using the message processing sequence number. In addition, although the verification process of the profile server 150 is not shown in the accompanying drawings, the profile server 150 may include a process of asking the provider server whether to allow the profile to be reinstalled for authentication of the ICCID and replying the result. When LPA1 510 receives the corresponding authentication token from SM-DP+ 150 (step 5b-60), LPA1 510 may send the corresponding information to ODSA1 500, and ODSA1 500 may reply the corresponding authentication token together with the terminal identification information to ECS 120 (step 5b-70).

[0126] The ECS 120 may verify the validity of the current value that was originally generated and sent with the received authentication token (step 5b-20), and verify the SM-DP+ signature value (step 5b-80) to perform the subsequent processes (steps 5a-190 to 5a-230) as described above, thereby completing the device transfer process. The current value generated by the ECS 120 may be used as an identifier to determine whether the current value is reused for the authentication request and to prove / verify whether it is a request from the ECS 120. When the ECS 120 receives a message including the current value, the ECS 120 may determine the validity of the current value, and include a process for determining whether the message sent is a response value to the message originally generated in the ECS and whether the current value is not reused. In addition, as described above, since the ECS 120 supporting the corresponding authentication stores the GSMA CI certificate as the same root CI certificate as the root CI certificate of the SM-DP+ server 150, the SM-DP+ signature value (step 5b-80) may be verified using the CI certificate owned by the ECS server 120. In addition, because SM-DP + 150 and ECS 120 have the root CI certificate of GSMA, and ECS 120 and SM-DP + 150 are in the same GSMA certificate chain, ECS 120 can support corresponding authentication even if ECS 120 does not directly interact with the SM-DP + 150 server.

[0127] Figure 5C : is a message flow diagram showing an embodiment in which a communication company provides an LPA method and uses LPA and SM-DP+ authentication in a first terminal (old terminal).

[0128] As described above, when the user 100 selects a profile to be moved from the UI of the first terminal 300 and selects the profile move menu, the terminal can identify the configuration information about the device transfer method to determine the process using the LPA method (step 5c-30). Figure 4 The described processes are the same or similar, so a detailed description thereof will be omitted. After performing mutual authentication with SM-DP+150, LPA1510 may request device transfer using a message including the ICCID and device transfer indicator of the profile to be moved with the ES9+.AuthenticationClientRequest message. The profile server 150 having received the message may perform a process of asking whether the profile for the ICCID is allowed to be reinstalled to the provider server 130 and replying to the result (step 5c-50). In addition, before the provider server starts step 5c-20, or as one of the processes in step 5c-50, the provider's profile policy may be notified to the profile server. In the case where the communication service provider supports profile device transfer for the corresponding ICCID, SM-DP+ and the provider server 130 may process profile commands, preparations, and generation (step 5c-60). The corresponding message may be an ES2+.DownloadOrder, ES2+.ConfirmOrder, or ES2+.ReleaseProfile command message. When the processing is completed (step 5c-60), the SM-DP+150 server may respond (step 5c-70) with an ES9+.AuthenticationClientResponse message including TransferType, ServiceProviderMesage, and an attached activation code. TransferType is an identifier of the provider's device transfer support method, and may indicate whether it is to download the profile by reissuing a new activation code with corresponding identification information, or whether the terminal deletes the existing profile and generates an activation code including information with a deletion notification, and whether the profile server is verified by some or all of the deletion notifications included in the activation code generated later. ServiceProviderMesage represents data for guiding the user about the profile processing for device transfer, etc. In the case where the user 100 finally agrees to the device transfer process processing (step 5c-80), LPA1 510 may reply to the SM-DP+150 with a message including the user's response to the device transfer processing. For example, the message may be an ES9+.CancelSession (final user confirmation result) (step 5c-90) message. According to the policy of the communication service provider receiving the message in step 5c-70, the first terminal 300 can delete the previously installed configuration file when moving the configuration file, and perform the process of generating and utilizing the activation code in the terminal by deleting the message (steps 5c-95 and 5c-100).Even in the case where a request for deleting a profile (DeleteOldProfile) is included, the processes of steps 5c-95 and 5c-100 may be provided, such as step 5a-200. The first terminal 300 may delete the profile (step 5c-95), and compose and display a QR code using all or part of the generated deletion notification information (step 5c-100). When the user 100 inputs to delete the profile for device transfer through local profile management (for example, clicking the OK button in step 5d-40), the eUICC 160 may delete the profile (step 5c-95) and transmit the result message to the LPA1 510. The LPA1 510 may set a bit indicating DeleteProfile in the event information (NotificationEvent) data to be received in the second control message (for example, ES10c.ListNotificationRequest message), and send the message to the eUICC 160. The eUICC 160, which has received the second message, may reply to the LPA1 510 with all notification information corresponding to DeleteProfile. The notification includes at least one of processing sequence number information (indicated by sequence, Seq or SeqNumber) or profile ID (or ICCID or ICCID). LPA1 510 may select a notification corresponding to the deleted profile or Seq value, and send a third control message (e.g., ES10c.RetrieveNotification message) including the Seq value to the eUICC. eUICC 160 may send notification information corresponding to the Seq value in the stored notification information to LPA1 510. The information included in the notification information may include at least one of the following information. Thereafter, the first terminal 300 may encode and display the information included in the QR code (step 5c-100).

[0129] -seqNumber: Process sequence number information

[0130] -profileManagementOperation: A separator indicating whether the corresponding profile has been deleted

[0131] -notificationAddress: configuration file server address

[0132] -ICCID: Deleted Profile ID

[0133] -euiccNotification Signature: A digital signature of the eUICC 160 that proves the ICCID of the corresponding profile, an indicator that the processed operation is a deletion, and a SEQ value.

[0134] -eUICCCertificate: eUICC certificate used to prove the validity of the eUICC signature.

[0135] -EUMCertificate: Additional certificate used to prove the validity of the eUICC certificate

[0136] The QR code is information to be sent to the second terminal 350 for profile download and installation, and according to an embodiment of the present disclosure, the second terminal 350 may eventually send some or all of the information obtained through the QR code to the profile server. The second terminal 350 may scan the QR code to start the profile download process (step 5a-230). In the case where the activation code issued from the provider is received and installed in steps 5c-95 and 5c-100 (step 5c-70) without generating the activation code with profile deletion notification in step 5a-230, the profile download process may be performed according to the process defined in GSMA SGP.22v2 thereafter. In step 5a-230, as in step 5c-95 or step 5c-100, in the case where the profile is deleted and the corresponding deletion information is utilized, the second terminal 350 may send an InitiateAuthenticate message including the eUICCChallenge value of the eUICC to install the profile to the profile server corresponding to the profile server address included in the QR code. The profile server may verify the corresponding value to generate a transaction ID, and generate and respond to the signature of the profile server for data including the transaction ID and the eUICCChallenge value. In this case, the InitiateAuthenticate response message may include the profile signature value and the transaction ID. After receiving the InitiateAuthenticate response message, the second terminal 350 may receive data including the ICCID included in the QR code and eUICC signature data of the first terminal 300, generate eUICC signature data signed by the eUICC of the second terminal 350 for the data, include the data in the AuthenticateClientRequest message, and send the AuthenticateClientRequest message to the profile server. When the profile server 150 receives the AuthenticateClientRequest message, by performing a verification process including the ICCID of the profile to move the profile included in the AuthenticateClientRequest message and the signature data verification of the eUICC in which the profile of the first terminal 300 is installed, the profile server 150 may determine whether to download the corresponding profile, and include data including profile metadata corresponding to the profile in the AuthenticateClientResponse message and reply.In addition, the signature data verification of the eUICC 160 of the first terminal may be a signature verification of data including the ICCID and additional data (processing sequence number, profile deletion delimiter, profile server address, deleted profile ICCID, eUICC signature value) using the certificate of the eUICC 160 of the first terminal 300. Thereafter, the second terminal 350 receives the AuthenticateClientResponse message, and when the AuthenticateClientResponse message includes ProfileMetadata, the second terminal 350 may perform some or all of the process of receiving consent from the user to receive the profile by displaying a UI, the process of requesting input of a confirmation code and receiving the input, and the process of generating a one-time public key (otpk.eUICC) of the eUICC. Thereafter, when the second terminal 350 sends a GetBoundProfilePackage request including otpk.eUICC to the profile server 150, the profile server may reply to the second terminal 350 with a BoundProfilePackage including information encrypted using the encryption key generated using otpk.eUICC. Upon receiving the BoundProfilePackage, the second terminal 350 may install the profile in the eUICC of the second terminal 350 to complete all processes.

[0137] Figure 5D is a diagram showing a representative process of a user interface (UI) and user experience (UX) delivered by an eSIM device activated in a first terminal. Figure 5D Shows when FIG. 5A to FIG. 5C An example of the expected UI and UX of the user when the process is processed is implemented in the terminal. The order indicated by the numbers is the processing order of the corresponding process, and the order indicated by 3-A to 3-C indicates the time point of branching according to the device transfer method and the provider support method in the processing of the corresponding process. The user 100 can identify the SIM card information currently installed in the corresponding terminal through a menu configured by a terminal such as the first terminal 300. For example, the profile information stored in the SIM card and the eUICC can be displayed to the user as shown in screen No. 1. On the corresponding screen, the user can select the profile to be moved (step 5d-10) or select one or more profiles (for example, all move) through a separate menu. When the user selects the profile to be moved, a separate menu list can be displayed so that the terminal can receive a command to process the corresponding profile as in step 5d-20, and an identifier indicating that the device transfer is performed as one of them can be provided to the separate menu. The menu entry can identify the terminal as the first terminal 300, and process it in the case where the user selects the profile to be moved in the terminal, and select the corresponding menu even if the same device transfer menu is entered or the case of processing the menu is different from the case of processing in the new terminal. In the case of selecting device transfer for the corresponding profile, when LPA1 510 of the first terminal 300 performs ES10c.GetProfileInfo() function call in eUICC to bring metadata information of the profile, LPA1 510 can identify MCC+MNC using the inherent identification number of the communication service provider of the profile. In addition, in this case, LPA1 510 can identify the status information of the corresponding profile. The terminal can obtain the provider identification number of the profile to be moved by the user from the terminal without user interaction, and compose and display screen No. 2 through the metadata of the corresponding profile and the predetermined information obtained by the provider identification number. As described above with reference to Figure 4 As described, when the user 100 selects to request device transfer through the device transfer menu, as in step 5d-20 of screen No. 2, the terminal can initiate a process for obtaining provider configuration information about device transfer, including whether and how the communication service provider supports device transfer, to determine the device transfer method to be used in the terminal through the metadata of the profile to be moved and information obtained from a separate configuration server or storage of the terminal. When the user 100 selects the device transfer menu (step 5d-20), the first terminal 300 can display different screens depending on whether and how the device transfer method is supported, such as steps 5d-30, 5d-40, and 5d-50. Step 5d-30 shows an example displayed on the screen when the communication company of the selected profile does not support the device transfer method. Although in Figure 5D It is not specified that when a profile is selected in step 5d-10, the terminal can bring out the provider's device transfer configuration information from the metadata or the terminal's memory, and in the case where there is no information about device transfer support in the corresponding information, in step 5d-20, the terminal can process to non-selectively expose the device transfer menu in the menu itself. In this case, only the device transfer supporting provider can expose the corresponding device transfer menu. In addition, at the time point of step 5d-20 of entering the eSIM transfer menu, the provider can determine the EAP-AKA method support information and the profile status information, and notify the user that the profile should be enabled to support the EAP-AKA method. Figure 5C As shown, in the case where the terminal determines the processing in the LPA method as a result of identifying the information acquired in steps 5d-10 and 5d-20, the first terminal 300 can process authentication through SM-DP+ and display a provider message pre-configured in LPA or received through SM-DP+ on the terminal screen. For example, as in step 5d-40, the first terminal 300 may display a message for processing user consent to delete an existing profile for moving the corresponding profile. Figure 5A or Figure 5B As shown, in the case where the terminal determines the processing in the ODSA method as a result of identifying the information acquired in steps 5d-10 and 5d-20, the terminal can trigger ODSA1500, which is its ODSA client, and when ODSA1500 requests device transfer to ECS 120 (step 5a-50), user authentication is performed, and in the case where the user is authenticated as a result of the user authentication, as in step 5d-50, the terminal can display the provider's web screen, which is information about the device movement process of the communication service to be moved (profile). The composition of the web screen may vary depending on the provider. Fig. 6A As shown in step 6a-140 of , in the case where the terminal requests device transmission from ODSA1 500 to ECS 120 without an authentication identifier, ECS 120 can select OAuth / Open ID using a user authentication method. In addition, as described above, ECS 120 can select a method and, for example, send EAP_ID as an identifier for requesting EAP-AKA in the authentication method requested by the terminal, but for reasons such as not supporting a relay with an AAA server, the ECS having received the EAP_ID does not process the identifier, but in the case where the ECS supports OAuth / Open ID, the ECS can reply including the client ID and the redirection URI in the initial http response 302found so that the request is processed with OAuth / Open ID.

[0138] In this case, the terminal can receive a login page (i.e., redirection URI) requesting input of a user ID and password from the ECS 120, and display the login page on the user screen (step 6c-70) to process user authentication with an ID and password, and then move to the same screen as step 5d-50. As described above, in the case where the EAP-AKA method or the ECS&DP+ authentication method is determined by terminal configuration, user selection, or ECS selection, the user can complete the user authentication process without interaction in the terminal UI, such as ID generation. When the user authentication is completed by changing the device with the LPA or ODSA method, the first terminal 300 can generate an activation code and provide the activation code together with the method of obtaining the activation code from the second terminal 350 (step 5d-60). Although the method of providing the activation code in the form of a QR code is shown in step 5d-60, the activation code information can be transmitted through an inter-terminal transmission protocol. The user 100 can input the activation code information into the LPA2530 of the second terminal 350 by the method provided in (step 5d-60) (steps 5d-70 and 5d-80). As described above in step 5a-230, when the corresponding information is input, the second terminal 350 can download and install the configuration file, and as in the example of step 5d-90, when the download and installation of the configuration file are completed, the user can recognize that the reinstallation of the configuration file has been completed in the first terminal 300. As in step 5d-100, according to the provider policy of the first terminal 300 and the deletion process agreed by the user, the configuration file that has completed the device transfer process is deleted from the configuration file list of the first terminal 300; therefore, the configuration file may no longer be processed to be exposed to the user.

[0139] FIG. 6A to FIG. 6C is a diagram showing a process in which a user initiates device transfer in a second terminal (new terminal). Fig. 6A is a message flow diagram showing an embodiment in which a communication company provides an ODSA method and uses OTP or OAuth / Open ID authentication. Figure 4 As described above (step 6a-30), the terminal user 100 can select a communication company for the user to change the device in the second terminal 350, and the terminal obtains the configuration information. Therefore, the terminal can determine the subsequent device transfer process in the ODSA method (step 6a-30). Figure 4 A detailed method for obtaining configuration information is described, so additional description will be omitted here. The second terminal 350 can generate and display a menu indicating whether there is a user-held terminal capable of receiving SMS (step 6a-40), and in the case where the user 100 can receive the authentication code through the existing terminal 300, the user can enter the user's phone number, i.e., MSISDN, on the screen, which is an inherent number for identifying the user in the mobile network (step 6a-60). Although not specified above, messages are exchanged between the ODSA 110 and ECS 120 of the terminal using an HTTP-based mechanism. The ODSA2520 of the second terminal 350 that receives the input can send an authentication request Https request message including the IMEI of the requesting terminal 350 and the MSISDN of the first terminal 300 to the ECS120 (step 6a-70). The ECS 120 having received the message parses the message, and in the case of the MSISDN value, the ECS 120 may send the OTP to the phone number (MSISDN) provided by the end user 100 (step 6a-90), and include the cache file in the HTTP 200OK, and send the HTTP 200OK to the ODSA 2520 (step 6a-80). The ODSA 2520 may reply a new acquisition request to the ECS 120 (step 6a-110), including the OTP parameters received and input by the end user 100 through the first terminal 300 and the cache file received from the previous HTTP 200OK response. The ECS 120 may verify the received OTP, generate a new authentication token (AuthToken), and reply the new authentication token (AuthToken) to the ODSA 2520 (step 6a-120). Thereafter, the ODSA 2520 may request the ECS 120 to change the device, including the corresponding authentication token (step 6a-130). As described above, in order to obtain device delivery configuration information for profile installation for device delivery processing and verify the service status of the terminal, when ODSA 110 sends an HTTP request to ECS 120, ECS 120 may process the request and reply a result value to ODSA 110. In the case where the received Get request does not include EAP_ID, DP+AuthSupport, or MSISDN, or indicates that the corresponding or other authentication means provided by the terminal is unavailable, ECS 120 may request OAuth / Open ID authentication from the terminal (step 6a-140).

[0140] The method for performing OAuth / Open ID authentication (step 6a-100) is described in more detail below. In the case where the second terminal 350 starts, because the existing terminal 300 is not available (step 6a-40), when the ECS 120 does not receive the MSISDN information, the ECS 120 does not have an available authentication device. Therefore, the ECS 120 can reply "302Found" as a response for retransmitting the received GET request from the ODSA client of the terminal to the authentication server of the service provider. As described above, the ECS 120 can send the URL address of the authentication point to be redirected for open ID processing as the location value of the header to the corresponding "302Found". In addition, as the main message of "302Found", the ECS 120 may include "openid" as the value of the scope and response type=code, and reply response type=code and scope=openid. "openid" is one of the possible values ​​of the Scope parameter, and can indicate that the application wants to use the open ID connection standard protocol for user identification. The response type=code can be used as an identifier indicating the code that should be replied from the authentication server indicated in the location.

[0141] The open ID authentication server (the authentication point to be redirected) can select an authentication method (additional SMS authentication, etc.) to authenticate the user 100 according to the policy of the service provider, and reply with a code value as a result. Here, the OAuth2.0 authentication code (a temporary code provided for exchange with an access token) can be replied to the terminal. The terminal includes the corresponding authentication code as a response value of "302Found" and sends it to ECS 120. When ECS 120 receives the corresponding authentication code, ECS 120 can send the corresponding authentication code to the open ID authentication server to request an access token and an ID token. When the open ID authentication server verifies and approves the OAuth2.0 authentication code, the open ID authentication server can reply with an access token and an ID token to ECS 120. ECS 120 can use the corresponding token value to identify the user information of the corresponding user, restore the original GET resource request, and perform subsequent processes for device transfer. As has been previously referred to Figure 5A The process for updating user information and generating a profile for a user's communication service between ECS 120 / SM-DP + 150 and MNO BSS / OSS 130 is described, and its detailed description will be omitted. After processing the corresponding process, ECS 120 receives an activation code as predetermined information required to download the corresponding profile from MNO BSS / OSS 130 or SM-DP + 150, and sends the activation code to ODSA 2520, and ODSA 2520 sends the activation code information to LPA 2530 through LPA API. Therefore, LPA 2530 can trigger the profile download in SM-DP + 150 to complete the process of downloading and installing the profile according to the process defined in GSMA SGP.22 (step 5a-230).

[0142] Figure 6B : is a message flow diagram showing an embodiment in which a communication company provides an LPA method and uses LPA and SM-DP+ authentication in a first terminal (old terminal).

[0143] As mentioned above Figure 5A As described above, the terminal user 100 can select a communication company, wherein the user will perform device transfer in the second terminal, and the terminal can obtain configuration information, such as reference Figure 4 As described, the device transmission method to identify the provider is through a combined LPA method. In this case, the terminal can determine and perform the process in the LPA method (step 6b-10). At the current time point when the second terminal 350 initiates disclosure, because there is no method capable of processing the LPA method, the terminal can display a message on the screen of the second terminal 350 to identify whether the existing terminal is available to the user (step 6b-20). Because the device transmission method based on LPA can be provided without considering the profile status information of the existing terminal, the message about whether to use the existing terminal in step 6b-20 can be processed differently from step 6a-40. For example, the message in step 6a-40 can identify whether the existing terminal is available and whether the terminal is a terminal capable of receiving SMS together, but in step 6b-20, only whether the existing terminal is available can be identified and processed. In the case where the user inputs that the first terminal 300 is available in the second terminal 350 (step 6b-30), as shown in step 6b-40, the second terminal 350 can enable the first terminal 300 to perform the device transmission process through the LPA process. As an example, in the first terminal 300, the Figure 5C After the guide message (step 6b-50) of the process from step 5c-10 to step 5c-100 is displayed on the screen of the second terminal 350, so that the user 100 can perform the subsequent process in the first terminal 300, the screen of the second terminal 350 can be moved to the screen of the LPA 2530 to receive the activation code and standby. The UI / UX for the corresponding processing will be referred to later. Figure 6C As described above Figure 5C As described above, when the user 100 processes the LPA-based device transmission, receives (step 5c-70) or generates (step 5c-100) the activation code in the first terminal 300, and displays the activation code on the screen, the second terminal 350 can receive the input of the corresponding information through the camera in the LPA2530 by scanning the displayed activation code (step 5c-110). Access the SM-DP+ server address extracted from the activation code, download the configuration file and complete the installation of the configuration file. In the case where the terminal receives the input of the user without the first terminal 300 (step 6b-30), the terminal can display a user guide message to query the communication service provider (step 6b-50), and end all processes.

[0144] Figure 6C is a diagram showing a representative process of UI and UX for eSIM device transmission initiated in a second terminal. Figure 6C It is representatively shown in Fig. 6A and Figure 6B FIG. 4 is a diagram of the UI / UX implemented in FIG. 4 , as a case where the user starts device transfer in the second terminal 350. (4-A, 4-B) and (6-A, 6-B) on the mobile phone screen in the scenario starting from the second terminal 350 represent representative branch time points. Figure 4 As described above, when the user enters a menu for device transmission in the second terminal 350 (step 6c-20), the terminal can collect provider configuration information about device transmission and display the provider configuration information on the screen (step 6-30). For example, the terminal can list the provider configuration information using the configuration server ( Figure 4 Options 2 and 3) or through information stored in memory ( Figure 4 Option 4) of the present invention obtains all communication service provider information, or extracts only the providers that can provide device delivery in the corresponding area by additionally combining the location information of the terminal and the like with the corresponding information, and then displays the list of providers on the screen. As another example, when the user 100 provides information about the communication service provider of the mobile profile, such as in Figure 4 In option 2 of , the terminal may identify the selected communication service provider name or MCC+MNC of the communication service provider in a memory in the terminal or the configuration server, and selectively display only the information of the mapped provider. In this case, in the case where the provider does not support device transmission, although in Figure 6C Not shown, the terminal may also display a separate guidance message on the screen, and end the process after step 6c-30 without entering step 6c-40 or step 6c-90. When the user 100 selects a provider in step 6c-30, the terminal may process by branching to the screen of step 6c-40 or 6c-90 according to the provider's identified device transmission support method. The processing in step 6c-40 is a case where the selected communication service provider supports ODSA-based device transmission, and the terminal provides an additional menu about whether there is an existing terminal as in step 6c-50, and is connected to the SMS-OTP authentication progress screen provided in the terminal (step 6c-60) or the URL in the location header received from ECS120 through a 302 found http response according to the user's response to display the provider providing screen (step 6c-70). When the user authentication is completed according to the corresponding authentication method, the communication service subscription app or web portal of the second terminal 350 receives the activation code information and transmits the corresponding activation code information to LPA2530 through the LPA API, and when the LPA2530 that has received the corresponding activation code information completes all processing / installation of the configuration file download, LPA2530 can display to the user 100 that the configuration file to be moved has been installed, as in step 6c-80. In the case that the device transmission support method of the provider determined by the terminal through step 6c-30 is the LPA method, the second terminal 350 can notify that the process is changed according to whether there is an existing terminal 300, as in step 6c-90, and in the case that the existing terminal 300 is not available, the second terminal 350 can display the provider contact message, as in step 6c-100, and end all processes. In the case that the second terminal 350 responds that the existing terminal 300 is available, the second terminal 350 can generate an additional guide message to guide the user to process in the first terminal 300, and the activation code (e.g., scanning the QR code) can stand by in the process for input (step 6c-110). In the case that the user's response (eg, activation code input) does not occur during the timer according to the configuration of the terminal, the terminal may display a user guide message and end the device transfer process or may extend the standby time. Figure 5D When the LPA process in the first terminal 300 in the first terminal 300 is used to change the device and receive the release of the activation code, the user can process Figure 5D The subsequent process, such as the example of step 6c-110, completes the device transmission through menu selection to receive the activation code in the second terminal 350.

[0145] Figure 7 is a block diagram illustrating a block configuration of a terminal in a wireless communication system according to an embodiment of the present invention.

[0146] refer to Figure 7 , the terminal 700 includes a transceiver 710, a message processor 720, a processor (controller) 730, a memory 740, and a screen display unit 750. However, the components of the terminal 700 are not limited to the above examples. For example, the base station may include more or fewer components than the aforementioned components. In addition, at least one component of the terminal 700 may be implemented in the form of a chip. According to some embodiments, the transceiver 710 may perform functions for sending and receiving signals through a wireless channel, such as frequency band conversion and amplification of signals. That is, the transceiver 710 may include an RF processor that up-converts a baseband signal into an RF band signal, sends the RF band signal through an antenna, and down-converts the RF band signal received by the antenna into a baseband signal, and also includes a transmit filter, a receive filter, an amplifier, a mixer, an oscillator, a digital-to-analog converter (DAC), and an analog-to-digital converter (ADC).

[0147] In addition, the transceiver 710 may receive a signal through a wireless channel, output the signal to the processor 730, and transmit a signal output from the processor 730 through a wireless channel. Figure 7 Only one antenna is shown in FIG. 7 , but the terminal may include multiple antennas. In addition, the transceiver 710 may include multiple RF chains.

[0148] The transceiver 710 may perform beamforming. For beamforming, the transceiver 710 may adjust the phase and amplitude of each signal transmitted and received through multiple antennas or antenna elements. In addition, the baseband processor in the transceiver 710 may perform a conversion function between a baseband signal and a bit string according to the physical layer specification of the system. For example, when transmitting data, the baseband processor may encode and modulate the transmitted bit string to generate a complex symbol. In addition, when receiving data, the baseband processor may demodulate and decode the baseband signal provided from the RF processor to recover the received bit string. For example, in the case of following the orthogonal frequency division multiplexing (OFDM) method, when transmitting data, the baseband processor may encode and modulate the transmitted bit string to generate a complex symbol, map the complex symbol to a subcarrier, and then form an OFDM symbol through an inverse fast Fourier transform (IFFT) operation and a cyclic prefix (CP) insertion.

[0149] In addition, when receiving data, the baseband processor can divide the baseband signal provided from the RF processor into OFDM symbol units, restore the signal mapped to the subcarrier through a fast Fourier transform (FFT) operation, and then restore the received bit string through demodulation and decoding.

[0150] The transceiver 710 may be defined as a transceiver and include a message transceiver. The message processor 720 may perform an operation of determining the type of message data sent or received by the transceiver 710. For example, the message processor 720 may determine whether the received message is a radio resource control (RRC) layer control message (including a system information block (SIB)) or a user data message. The message processor 720 may be included in the controller 730.

[0151] The controller 730 controls the overall operation of the terminal 700. For example, the controller 730 may send and receive signals through the message processor 720. In addition, the controller 730 writes and reads data in the memory 740. The controller 730 may be at least one. For example, the controller 730 may include a communication processor (CP) that controls communication and an application processor (AP) that controls an upper layer (e.g., an application). According to some embodiments, in the presence of provider configuration information transmitted about a device pre-stored in the memory 740, the controller 730 may request information from the memory 740 to control the screen display unit 750 to display information, or may receive information to perform additional operations.

[0152] The controller 730, the message processor 720, and the transceiver 710 may control the terminal 700 to access the selected provider network according to the user or terminal configuration. In addition, according to some embodiments, the controller 730 may perform a process in which the terminal infers information that can be referred to when selecting a service by matching a data record read through the memory 740 or information collected through the controller 730, the message processor 720, and the transceiver 710. According to some embodiments, the controller 730 may determine whether the user's consent to specific information stored in the terminal 700 is required, and display it on the screen display unit 750.

[0153] In addition, the controller 730 may control the terminal 700 to perform corresponding operations. According to some embodiments, the controller 730 may include an LPA responsible for driving and controlling the eUICC, an ODSA client for communication service subscription and device transfer processing, an LPA or an ODSA client, or an application in which both are integrated. In addition, the controller 730 may obtain predetermined information required for device transfer through the memory 740, determine whether the LPA or ODSA client operation is necessary for communication service device transfer, and process subsequent processes. In addition, the controller 730 may obtain device transfer information provided by the communication service provider that may be collected through the message processor 720 and the transceiver 710, combine the device transfer information with the device transfer additional information identified by the memory 740 of the terminal 700 and the profile status information obtained by the controller 730, and control the terminal 700 using the method to be processed between the LPA and ODSA device transfer methods and the authentication method to be applied.

[0154] The controller 730 can combine the terminal capability information obtained from the message processor 720, the transceiver 710 and the memory 740, the device transfer method information of the provider, and the predetermined information input in the screen display unit 750 to determine whether the terminal supports profile movement, and if the terminal supports profile movement, the controller 730 can determine whether to perform the role of the first terminal or the second terminal and whether to continue which device transfer method process.

[0155] The controller 730 may send a request to the memory 740 to protect information about whether the provider supports device transmission, supported methods and configuration server addresses to be connected to support, ECS or DP+ server addresses, or supported user authentication methods, etc., to control the terminal 700 to process the request. According to some embodiments, the controller 730 may receive device transmission configuration information other than the authentication method supporting the capabilities of the terminal from the memory 740, and send the information to the ECS server through the message processor 720 and the message transceiver 710, or may select specific parameters and send the information through the message processor 720 and the message transceiver 710. In addition, in the case where the processor 730 determines that the terminal does not provide the EAP-AKA function at the corresponding time point (for example, in the case where the profile is disabled), the processor 730 may control the terminal 700 to limit the operation of the EAP-AKA process.

[0156] The memory 740 stores data used for the operation of the terminal 700, such as basic programs, applications, and configuration information. The memory 740 may include UICC, eUICC, ISSP, and iUICC, which are hardware security modules embedded in the terminal. In this embodiment, the memory 740 may be formed by a storage medium such as ROM, RAM, hard disk, CD-ROM, and DVD, or a combination of storage media, and provides storage data such as transmission configuration according to a request from the controller 730. In addition, the memory 740 may be integrated with the controller 730 and a system on chip (SoC).

[0157] The screen display unit 750 may display information processed by the controller 730, or may display the process of an operation performed by the terminal 700 through the processing of the controller 730, or may approve an event requesting the user to perform. According to some embodiments, the screen display unit 750 may reply and display the stored profile information, the mobile menu between profile devices, and the result of inputting and entering the activation code to the user. According to some embodiments, the LPA or ODSA application or an application in which the two are integrated may include the screen display unit 750 and the controller 730. The present disclosure is not limited to the above examples.

[0158] In the specific embodiments of the present disclosure described above, the components included in the present disclosure are expressed in the singular or plural, depending on the specific embodiment presented. However, the singular or plural expressions are appropriately selected for the situation presented for convenience of description, and the present invention is not limited to singular or plural components, and even if a component is expressed in plural, it can also be formed as a singular, or even if a component is expressed in singular, it can also be formed as a plural.

[0159] In the detailed description of the present disclosure, although specific embodiments have been described, various modifications are possible without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be defined by the claims described below and the claims equivalent to the claims.< / mcc> < / mnc> < / mcc> < / mnc> < / mcc> < / mnc>

Claims

1. A method performed by a terminal in a wireless communication system, the method comprising: Sending a first message including a terminal identifier and an extensible authentication protocol EAP identifier ID to a server; After performing Extensible Authentication Protocol for third generation authentication and key agreement (EAP-AKA) authentication with an authentication server, receiving from the server a second message including an authentication token associated with the EAP-AKA authentication; Sending a third message to the server requesting a subscription transmission, wherein the third message includes the terminal identifier and the authentication token; as well as In response to the third message, a fourth message including an activation code is received from the server.

2. The method according to claim 1, wherein: The third message also includes an old terminal identifier indicating that the request is from an old terminal.

3. The method according to claim 1, further comprising: New terminals are notified by scanning using a quick response QR code to download the configuration file.

4. A method performed by a server in a wireless communication system, the method comprising: receiving a first message including a terminal identifier and an extensible authentication protocol EAP identifier ID from a terminal; After performing Extensible Authentication Protocol for third generation authentication and key agreement (EAP-AKA) authentication with an authentication server, sending a second message including an authentication token associated with the EAP-AKA authentication to the terminal; receiving a third message from the terminal requesting a subscription to a transmission, wherein the third message includes the terminal identifier and the authentication token; as well as In response to the third message, a fourth message including an activation code is sent to the terminal.

5. The method according to claim 4, wherein: The third message also includes an old terminal identifier indicating that the request is from an old terminal.

6. The method according to claim 4, further comprising: An EAP challenge is received from the authentication server.

7. A terminal, comprising: a transceiver configured to transmit and receive at least one signal; as well as a controller, coupled to the transceiver, Wherein, the controller is configured as: Sending a first message including a terminal identifier and an extensible authentication protocol EAP identifier ID to a server; After performing Extensible Authentication Protocol for third generation authentication and key agreement (EAP-AKA) authentication with an authentication server, receiving from the server a second message including an authentication token associated with the EAP-AKA authentication; sending a third message to the server requesting a subscription to be delivered, wherein the third message includes the terminal identifier and the authentication token; and In response to the third message, a fourth message including an activation code is received from the server.

8. The terminal according to claim 7, wherein: The third message also includes an old terminal identifier indicating that the request is from an old terminal.

9. The terminal according to claim 7, wherein: The controller is also configured to notify the new terminal to download the configuration file by using a quick response QR code scan.

10. A server, comprising: a transceiver configured to transmit and receive at least one signal; as well as a controller, coupled to the transceiver, Wherein, the controller is configured as: receiving a first message including a terminal identifier and an extensible authentication protocol EAP identifier ID from a terminal; After performing Extensible Authentication Protocol for third generation authentication and key agreement (EAP-AKA) authentication with an authentication server, sending a second message including an authentication token associated with the EAP-AKA authentication to the terminal; receiving a third message from the terminal requesting a subscription to a transmission, wherein the third message includes the terminal identifier and the authentication token; and In response to the third message, a fourth message including an activation code is sent to the terminal.

11. The server according to claim 10, wherein: The third message also includes an old terminal identifier indicating that the request is from an old terminal, and The controller is further configured to: receive an EAP challenge from the authentication server.

Images