Patent Description:
A Universal Integrated Circuit Card (UICC) is a smart card designed to be inserted in a mobile communication terminal and to store personal information (such as subscriber authentication information, contacts, and Short Messing Service (SMS) information for subscriber authentication and traffic security key generation processing) for use in attempting access to a mobile communication network such as Global System for Mobile Communication (GSM), Wideband Code Division Multiple Access (WCDMA), and Long Term Evolution (LTE). The UICC contains a Subscriber Identity Module (SIM) application, a Universal SIM (USIM) application, and/or an IP Multimedia SIM (ISIM) application to give access to corresponding types of mobile communication networks, and it provides a high-level security function for supporting various applications such as an electronic wallet, an electronic ticketing, and an electronic passport.

Typically, the UICC is manufactured on demand from a mobile communication operator in the form of an operator-dedicated card storing authentication information (e.g., USIM application, IMSI, and K value) for use in access to the operator's network. Accordingly, the manufactured UICC is delivered to the subscriber via the mobile communication operator and, if necessary, applications are installed, updated, and deleted in the UICC by using a management technology such as Over The Air (OTA). The UICC is designed to be attachable/detachable to/from a mobile communication terminal such that the subscriber can install the UICC in the mobile communication terminal for use of the network and application services of the corresponding mobile communication operator and, when swapping the terminal for another one, easily transfer the authentication information, contact information, and phonebook to the new terminal.

The UICC has a physical shape and a logical function defined by an international standardization organization called the European Telecommunications Standard Institute (ETSI) to maintain global compatibility. With regard to the form factor specifying the physical shape, the UICC is gradually being downsized from the most widely used Mini SIM to the Micro SIM that emerged a few years ago and finally to the recent Nano SIM. Although this contributes greatly to the compact design of mobile communication terminals, there will be no standardization for a UICC smaller in size than the recent Nano SIM because further downsizing of the UICC increases the risk of loss and makes it difficult to form a slot for receiving the excessively small UICC.

Meanwhile, a detachable UICC is not appropriate for Machine-to-Machine (M2M) communication devices (such as an intelligent electronic appliance, an electricity/water meter, and a Closed-Circuit Television (CCTV)), which connect to the mobile communication network without a user's manipulation in various installation environments.

In order to solve the above problems, installation in the manufacturing stage of the mobile communication terminal of a security module responsible for the functions of the legacy detachable UICC may be considered. However, this approach has drawbacks in that the security module embedded in a terminal without operator-specific authentication information (in so far as it is not dedicated to a specific mobile communication operator) allows only the user subscribed to a mobile communication operator to configure the authentication information (USIM application, IMSI, and K value) for use in the corresponding mobile communication network.

Also, unlike the legacy UICC, which is manufactured and distributed for a specific mobile communication operator, the newly introduced embedded security module has to meet requirements for allowing the user who has purchased the terminal to install and maintain the authentication information of various mobile communication operators securely and flexibly in the course of subscribing and unsubscribing to a specific mobile communication operator or switching the subscription between operators.

<CIT> relates to a method for managing mobile communication subscriber information (profile), such as for remotely installing and uninstalling a profile onto a security module (Universal Integrated Circuit Card (UICC)) that is embedded inside a terminal and that is not attachable or detachable, thereby replacing UICC. A method for a server installing a profile is described, wherein the method for the server installing the profile for a terminal having an embedded security module comprises the steps of: receiving from the terminal a profile installation request including an identifier of the terminal embedded security module; receiving an encrypted profile corresponding to the installation request; and transmitting to the terminal the encrypted profile.

In <CIT> a method and apparatus for setting profiles are described. The profile setting method includes receiving, from a first terminal, a profile transfer request message that requests transfer of a first profile or portion thereof from a first secure element to a second secure element; sending, to the first terminal, a request message requesting the first profile or portion thereof; receiving, from the first terminal, the first profile or portion thereof; configuring a second profile using the received first profile or portion thereof; and sending, to a second terminal, the configured second profile.

<CIT> discloses technology for backing up and restoring a profile of an eUICC.

The present invention aims to provide a method and a system for providing a profile to a terminal.

The communication service implementation method and system of the present invention is advantageous in terms of facilitating registration of an eUICC terminal with an operator and switching a subscription between operators. Also, the communication service implementation method and apparatus of the present invention is advantageous in terms of installment and management of a profile in the eUICC terminal in a remote and flexible manner.

Exemplary embodiments of the present invention are described in detail with reference to the accompanying drawings.

Detailed descriptions of technical specifications well-known in the art and unrelated directly to the present invention may be omitted to avoid obscuring the subject matter of the present invention. This aims to omit unnecessary description so as to make clear the subject matter of the present invention.

For the same reason, some elements are exaggerated, omitted, or simplified in the drawings and, in practice, the elements may have sizes and/or shapes different from those shown in the drawings. Throughout the drawings, the same or equivalent parts are indicated by the same reference numbers.

Advantages and features of the present invention and methods of accomplishing the same may be understood more readily by reference to the following detailed description of exemplary embodiments and the accompanying drawings. The present invention may, however, be embodied in many different forms and should not be construed as being limited to the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided so that this disclosure will be thorough and complete and will fully convey the concept of the invention to those skilled in the art, and the present invention will only be defined by the appended claims. Like reference numerals refer to like elements throughout the specification.

It will be understood that each block of the flowcharts and/or block diagrams, and combinations of blocks in the flowcharts and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus, such that the instructions which are executed via the processor of the computer or other programmable data processing apparatus create means for implementing the functions/acts specified in the flowcharts and/or block diagrams. These computer program instructions may also be stored in a non-transitory computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the non-transitory computer-readable memory produce articles of manufacture embedding instruction means that implement the function/act specified in the flowcharts and/or block diagrams. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which are executed on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the flowcharts and/or block diagrams.

Furthermore, the respective block diagrams may illustrate parts of modules, segments, or codes including at least one or more executable instructions for performing specific logic function(s). Moreover, it should be noted that the functions of the blocks may be performed in a different order in several modifications. For example, two successive blocks may be performed substantially at the same time, or may be performed in reverse order according to their functions.

According to various embodiments of the present disclosure, the term "module", means, but is not limited to, a software or hardware component, such as a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks. A module may advantageously be configured to reside on the addressable storage medium and configured to be executed on one or more processors. Thus, a module may include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. The functionality provided for in the components and modules may be combined into fewer components and modules or further separated into additional components and modules. In addition, the components and modules may be implemented such that they execute one or more CPUs in a device or a secure multimedia card.

Detailed descriptions of well-known functions and structures incorporated herein may be omitted to avoid obscuring the subject matter of the present invention. Exemplary embodiments of the present invention are described in detail with reference to the accompanying drawings.

First, terms herein are defined. The terms are defined for a person skilled in the art, but descriptions will be made thereof in detail, if necessary to help understand operations and properties related to the present invention.

It should be noted that the eUICC is characterized by being fixed in a terminal, but the term "eUICC" is used as a concept including the legacy detachable eUICC that is equivalent in functionality to the eUICC.

In the present invention, the UICC is a smart card or a chip card designed to be inserted in a mobile communication terminal and to store personal information (such as subscriber authentication information, contacts, and Short Messing Service (SMS) information for subscriber authentication and traffic security key generation processing) for use in attempting access to a mobile communication network such as GSM, WCDMA, and LTE. The UICC contains a SIM application, a Universal SIM(USIM) application, and/or an ISIM application to give access to corresponding types of mobile communication networks, and it provides a high-level security function for supporting various applications such as an electronic wallet, an electronic ticketing, and an electronic passport.

Although the description is directed to the eUICC as a security module in the form of a chip fixed in a terminal, the embodiments of the present invention can be applicable to the legacy UICC, which is identical with the eUICC functionally, electrically, and in terms of software characteristics. The embodiments of the present invention may be applicable for the operation of an eUICC manufactured in the form of a UICC. The eUICC is designed to install a profile downloaded through a cellular network or an Internet Protocol (IP) network such as Wireless Fidelity (Wi-Fi). The embodiments of the present invention may be applied regardless of the type of network through which the profile is downloaded.

In the following description, the term "profile" may denote a software package of at least one of an application, a file system, and an authentication value being stored in the UICC.

In the following description, the term "USIM profile" is used with the same meaning as profile or refers to the information contained in the USIM application of the profile in the form of a software package.

In the following description, the terms "first delivery server", "first Subscription Manager Data Preparation (SMDP)", "first off-card entity of Profile Domain", "first profile encryption server"," first profile generation server", and "first Profile Provisioner or Profile Provider" are used interchangeably.

In the following description, the terms "second delivery server", "second SM-DP", "second off-card entity of Profile Domain, "second profile encryption server", "second profile generation server", and "second Profile Provisioner or Profile Provider" are used interchangeably. Depending on the case, the first and second delivery servers may be implemented as a single server and, in this case, the server may be referred to as first/second delivery server, first/second SM-DP, first/second off-card entity of Profile Domain, first/second rofile generation server, and first/second Profile Provisioner or Profile Provider.

In the following description, the terms "third delivery server", "third profile management server", "third SM-SR", "third off-card entity of eUICC Profile Manager", and "Profile Manager are used interchangeably. Depending on the case, the first to third delivery servers may be implanted as a single server and, in this case, the corresponding server may be interchangeably referred to as a delivery server, delivery platform and an SM server.

In the following description, the term "terminal" may be interchangeably referred to as a mobile station(MS),User Equipment (UE), User Terminal (UT), radio terminal, Access Terminal (AT), terminal, Subscriber Unit, Subscriber Station (SS), wireless device, wireless communication device, Wireless Transmit/Receive Unit (WTRU), mobile node, mobile, and the like. In various embodiments, examples of the terminal may include a cellular phone, a wireless communication function-enabled smartphone, a wireless communication function-enabled Personal Digital Assistant (PDA), a wireless modem, a wireless communication function-enabled portable computer, a wireless communication function-enabled image capture device such as a digital camera, a wireless communication function-enabled gaming device, a wireless communication function enabled-music storage and playback device, a wireless Internet access and browsing-enabled device, and a portable unit or terminal in the form of any combination of the aforementioned devices. A communication function-enabled meter may be included as an example of the terminal.

Although the description is directed to a Machine-to-Machine (M2M) terminal or Machine Type Communication (MTC) terminal/device, the present invention is not limited thereto.

In the following description, a profile identifier may be referred to as a factor matching a profile ID, Integrated Circuit Card ID (ICCID), and Issuer Security Domain-Profile (ISD-P). The profile ID may be a unique identifier of a profile. In the following description, an eUICC identifier may be a unique identifier of the eUICC of a terminal and referred to as an eUICC ID (EID). The profile identifier may also be used to identify the profile in the network.

<FIG> is a diagram illustrating a wireless communication system for remote download of a profile according to an embodiment of the present invention.

In reference to <FIG>, the communication system may include at least one of a terminal <NUM>, a third delivery server <NUM>, a second delivery server <NUM>, and a first delivery server <NUM>.

In detail, the communication system may include the terminal <NUM> which connects to a wireless communication network, the third delivery server <NUM> for delivering a profile to the terminal <NUM>, the first delivery server <NUM> for generating and encrypting the profile, and the second deliver server <NUM> for relaying the profile from the first delivery server <NUM> to the third delivery server <NUM> and protecting against reinstallation of the profile.

In an embodiment, the profile may include an encryption key (e.g., K) for authenticating the subscriber identity (e.g., International Mobile Subscriber Identity (IMSI)) and information on the communication service provided by the corresponding operator.

In an embodiment, the terminal may communicate signals with the third delivery server <NUM> and receive information related to the profile.

<FIG> is a signal flow diagram illustrating a procedure for remote profile download according to an embodiment of the present invention.

In reference to <FIG>, a terminal <NUM> may receive profile information through at least one of a third delivery server <NUM>, a second delivery server <NUM>, and a first delivery server <NUM>.

In detail, the first delivery server <NUM> may generate and encrypt a profile and send the profile to the second delivery server <NUM> at step <NUM>.

The second delivery server <NUM> may send the encrypted profile to the third delivery server <NUM> at step <NUM>.

The terminal <NUM> may send a profile installation request including an eUICC identifier (EID) to the third delivery server <NUM> at step <NUM>. In detail, the terminal <NUM> may transmit to the third delivery server <NUM> the profile installation request including the EID as a factor.

Afterward, the terminal <NUM> may download the profile through interoperation among the terminal <NUM>, the third delivery server <NUM>, the second delivery serve <NUM>, and the first delivery server <NUM> at step <NUM>.

<FIG> is a block diagram illustrating a configuration of a terminal according to an embodiment of the present invention.

In the embodiment of <FIG>, the terminal may include a transceiver <NUM> for data communication through a wireless network, an eUICC <NUM>, a controller <NUM> for controlling installation of the profile received through a connection established with the third delivery server, and a storage unit <NUM> for storing data input through the transceiver <NUM> and processing results of the controller <NUM>. The controller <NUM> may include at least one processor and control the overall operations of the terminal in a embodiment of the present appliation.

<FIG> is a block diagram illustrating a configuration of a first delivery server according to an embodiment of the present invention.

In the embodiment of <FIG>, the first delivery server may include a transceiver <NUM> for communication with another entity such as the second delivery server, a controller <NUM> for performing profile encryption, and a storage unit <NUM> for storing the encrypted profile. The controller <NUM> may include at least one processor and control overall operations of the first delivery server.

<FIG> is a block diagram illustrating a configuration of a second delivery server according to an embodiment of the present invention.

In the embodiment of <FIG>, the second delivery server may include a transceiver <NUM> for communication with another entity such as the first and third delivery servers, a controller <NUM> for controlling profile reinstallation, and a storage unit <NUM> for storing data input through the transceiver <NUM> and processing results of the controller <NUM>. The controller <NUM> may include at least one processor and control overall operations of the second delivery server.

<FIG> is a diagram illustrating a configuration of a third delivery server according to an embodiment of the present invention.

In the embodiment of <FIG>, the third delivery server may include a transceiver <NUM> for communication with another entity such as the terminal and second delivery server in the communication system, a controller <NUM> for performing authentication and authorization during the profile installation, and a storage <NUM> for storing data input through the transceiver <NUM> and processing results of the controller <NUM>. The controller <NUM> may include at least one processor and control overall operations of the third delivery server.

<FIG> is a block diagram illustrating a wireless communication system for remote download of a profile according to another embodiment of the present invention.

In reference to <FIG>, the wireless communication system includes an operator terminal <NUM>, an operator server <NUM>, a terminal <NUM>, a relay server <NUM>, a third delivery server <NUM>, a second delivery server <NUM>, a first delivery server <NUM>, and a Primary third delivery server <NUM>, one of which communicates data with another entity. In detail, the operator terminal <NUM>, the operator server <NUM>, the relay server <NUM>, and the Primary third delivery server <NUM> are further added to the system to support profile download of the terminal <NUM>.

In this embodiment, the operator terminal <NUM> may connect to the operator server <NUM> and transmit at least one of terminal information, contract code, terminal-specific profile ID, and Primary third delivery server address to the operator server <NUM>, the terminal information, contract code, terminal-specific profile ID, and Primary third delivery server address being received from the terminal <NUM>. In detail, the operator terminal <NUM> may be a terminal for use by the operator managing the operator server <NUM> or a terminal stationed in an office of an agent under the management of the operator managing the operator server <NUM>. In this embodiment, the contract code may be stored in the terminal <NUM> and determined through a contract with the operator. The contract code may include the information related to the operator server address. The profile ID may be an identifier for identifying the profile to be downloaded by the terminal <NUM>.

The operator server <NUM> may be a server of the communication network operator and transmit at least one of the terminal information, contract code, terminal-specific profile ID, and Primary third delivery server address to the relay server <NUM>, the at least one of the terminal information, contract code, terminal-specific profile ID, and Primary third delivery server address being received from the operator terminal <NUM> or the terminal <NUM>. According to an embodiment of the present invention, the operator server <NUM> may determine that the relay server <NUM> relays information based on the at least one of the received information and communicates signals with the relay server <NUM>.

The third delivery server <NUM> may transmit the profile to the terminal <NUM> through signal communication with the terminal <NUM>. The third delivery server <NUM> may communicate signals with the Primary third delivery server <NUM> based on at least one of the information received from the relay server <NUM>. In detail, the third delivery server <NUM> may transmit the information on the address of the third delivery server <NUM> to the Primary third delivery server <NUM> based on the received information.

The Primary third delivery server <NUM> may communicate signals with at least one of the terminal <NUM> and the third delivery server <NUM>, receive the information on the third delivery server address from the third delivery server <NUM>, and transmit, when a request message including a terminal identifier or a profile ID is received from the terminal <NUM>, the information on the address of the third delivery server <NUM> to the terminal <NUM>.

A description is made hereinafter of the profile download procedure with reference to <FIG> and <FIG>.

<FIG> is a signal flow diagram illustrating a remote profile download procedure of a terminal according to an embodiment of the present invention, the procedure being characterized in that the terminal equipped with an eUICC downloads the profile via an operator terminal stationed in an office of an agent under the management of the operator.

In reference to <FIG>, at least one of an operator terminal <NUM>, a terminal <NUM>, an eUICC <NUM>, an operator server <NUM>, a relay server <NUM>, a third delivery server <NUM>, a Primary third delivery server <NUM>, a second delivery server <NUM>, and a first delivery server <NUM> may communicate signals with another entity. In an embodiment, the eUICC <NUM> may be installed in the terminal <NUM>, and a controller of the terminal <NUM> may request to the eUICC <NUM> for information and receive the corresponding information.

In an embodiment, each of the third delivery server <NUM>, the second delivery server <NUM>, and the first delivery server <NUM> may be comprised of at least one server or entity. According to an embodiment, the at least one server or entity may be an SM-DP+ server.

According to an embodiment, at least one of the first to third delivery servers <NUM>, <NUM>, and <NUM> may encrypt profile or information for use in downloading the profile.

According to an embodiment, at least one of the first to third delivery servers <NUM>, <NUM>, and <NUM> may perform a user authentication procedure for the terminal to download the profile.

According to an embodiment, the Primary third delivery server <NUM> may be an SM-DS server.

The operator terminal <NUM> may acquire at least one of the EID corresponding to the terminal <NUM> and the Primary third delivery server address through steps <NUM> to <NUM>. The at least one of the EID and Primary third delivery server address may be stored in the terminal <NUM> or the eUICC <NUM>.

The operator terminal <NUM> may transmit an information request to the terminal <NUM> at step <NUM>. The information request may include an enquiry about at least one EID of the terminal <NUM> and the third delivery server address.

The terminal <NUM> may transmit the information request to the eUICC <NUM> at step <NUM>.

The eUICC <NUM> may transmit at least one of the EID and Primary third delivery server address to the terminal <NUM> at step <NUM>.

The terminal <NUM> may transmit the at least one of the EID and Primary third delivery server address to the operator terminal <NUM> at step <NUM>.

Throughout this embodiment, the EID and Primary third delivery server address may be a value corresponding to the terminal <NUM> or the eUICC <NUM>.

According to an embodiment, the process for the operator terminal <NUM> to acquire the at least one of the EID and Primary third delivery server address through steps <NUM> to <NUM> may be elaborated as follows. Throughout this embodiment, a display device or a display unit may display the information on the operation of a system.

According to an embodiment, the information may be input to the operator terminal <NUM> by a user or through information exchange between the operator terminal <NUM> and the terminal <NUM>.

The input unit of the operator terminal <NUM> may be a camera or a scanner, and the EID and Primary third delivery server address may be printed on the box of the terminal <NUM> or the eUICC <NUM> in the form of a Quick Response (QR) code or displayed on the display unit.

The operator terminal <NUM> may transmit subscription information of the terminal <NUM> to the operator server <NUM> based on one of the EID and Primary third delivery server address at step <NUM>. In detail, the operator terminal <NUM> may transmit the subscription information of the terminal <NUM> to the operator server <NUM> through a connection pre-established with the operator server <NUM>. The subscription information includes at least one of the EID and Primary third delivery server address. The subscription information may further include a profile ID and contract code downloaded to the terminal <NUM>.

The operator server <NUM> may process the communication service subscription based on the subscription information received from the operator terminal <NUM> and transmit a profile provision request including at least part of the subscription information and the third delivery server address to the relay server <NUM> at step <NUM>. For example, the operator server <NUM> may transmit to the relay server <NUM> the profile provision request including at least one of the EID, Primary third delivery server address, and third delivery server address. The third delivery server address may be the address of the third delivery server <NUM> to which the terminal <NUM> has to establish a connection for downloading the profile.

The relay server <NUM> may transmit to the third delivery server <NUM> the information including at least part of the profile provision request received from the operator server <NUM> at step <NUM>. For example, the relay server <NUM> may transmit to the third delivery server <NUM> at least one of the EID, third delivery server address, and Primary third delivery server address.

The relay server <NUM> may transmit to the Primary third delivery server <NUM> at step <NUM> a transaction registration request including at least part of the information received from the relay server <NUM>. If the transaction registration request is received from the third delivery server <NUM>, the Primary third delivery server <NUM> may map the EID and the third delivery server address conveyed in the transaction registration request and store the mapping in the storage unit. According to an embodiment, the third delivery server address may be mapped to at least part of the information included in the transaction registration request as well as the EID or a value preconfigured in the third delivery server <NUM>.

Although not shown in the drawing, the Primary third delivery server <NUM> may notify the terminal <NUM> afterward that the registration has been completed. For example, the Primary third delivery server <NUM> may make a registration completion notification to the terminal <NUM> through an Mobile Network Operator (MNO) server.

The terminal <NUM> may transmit a third delivery server request to the Primary third delivery server <NUM> at step <NUM>. For example, the terminal <NUM> may establish a connection with the Primary third delivery server <NUM> based on the Primary third delivery server address set therein and transmit the third delivery server address request message to the Primary third delivery server <NUM>. The third delivery server address request message may include the EID.

At step <NUM>, the Primary third delivery server <NUM> may transmit to the terminal <NUM> a message including the third delivery server address based on at least part of the information received at steps <NUM> and <NUM>. For example, the Primary third delivery server <NUM> may check the EID-third delivery server address mapping information stored in a storage unit to retrieve the third delivery server address mapped to the EID and transmit the third delivery server address to the terminal <NUM>.

At step <NUM>, the terminal <NUM> may establish a connection with the third delivery server <NUM> with the third delivery server address received from the terminal <NUM> to download the profile through interoperation with the third delivery server <NUM>.

According to an embodiment, the third delivery server <NUM> may be integrated into the Primary third delivery server <NUM> and, in this case, the Primary third delivery server <NUM> may trigger the profile download immediately without transmitting the third delivery server address to the terminal <NUM>.

<FIG> is a signal flow diagram illustrating a remote profile download procedure of a terminal according to another embodiment of the present invention, the procedure characterized by the operator terminal not being needed.

In reference to <FIG>, at least one of a terminal <NUM>, an eUICC <NUM>, an operator server <NUM>, a relay server <NUM>, a third delivery server <NUM>, a primary third delivery server <NUM>, a second delivery server <NUM>, and a first delivery server <NUM> may communicate with another entity. According to an embodiment, the eUICC <NUM> may be installed in the terminal <NUM>, and a controller of the terminal <NUM> may request to the eUICC <NUM> for information and receive corresponding information.

The terminal <NUM> may acquire at least one of an EID and a Primary third delivery server address from the eUICC <NUM> at step <NUM>. The terminal <NUM> may further acquire a contract code related to the contract with the operator.

The terminal <NUM> may establish a connection with the operator server <NUM>. The terminal <NUM> may check for the operator server address at step <NUM>. The terminal <NUM> may check for the operator server address according to at least one of the following methods.

The input unit of the terminal <NUM> may be a touchscreen or a camera for scanning a QR code containing the contract code information.

The terminal <NUM> transmits to the operator server <NUM> the subscription information including at least one of the EID and Primary third delivery server address at step <NUM>. The subscription information may include the contract code information and, according to an embodiment, the operator server <NUM> may verify the validity of the contract code.

Although not shown in the drawing, instead of steps <NUM> and <NUM>, it may be possible for the terminal to transmit the EID and subscription information to the Primary third delivery server address stored in the terminal such that the Primary third delivery server extracts the operator information from the subscription information and establishes a connection with the operator server <NUM> on behalf of the terminal <NUM> to transmit the EID and subscription information.

The operator server <NUM> may process the communication service subscription based on at least part of the subscription information received from the terminal <NUM> or the Primary third delivery server and, at step <NUM>, transmit to the relay server <NUM> at least one of part of the information received at step <NUM> and the Primary third delivery server address. For example, the operator server <NUM> transmits to the delivery server <NUM> a profile request including at least one of the EID, Primary third delivery server address, and third delivery server address received from the terminal <NUM>. The third delivery server address may be the address of the third delivery server with which the terminal <NUM> establishes a connection for downloading the profile.

At step <NUM>, the relay server <NUM> may transmit to the third delivery server <NUM> at least part of the information received from the operator server <NUM>. For example, the delivery server <NUM> may transmit to the third delivery server <NUM> at least one of the EID, third delivery server address, and Primary third delivery server address received from the operator server <NUM>.

The third delivery server <NUM> may, at step <NUM>, transmit to the Primary third delivery server <NUM> a transaction registration request including at least part of the information received from the relay server <NUM>. If the transaction registration request including at least one of the EID and third delivery server address is received from the third delivery server <NUM>, the Primary third delivery server <NUM> may map the EID and the third delivery server address and store the mapping information in a storage unit. According to an embodiment, the third delivery server address may be mapped to at least part of the information included in the transaction registration request or a value set in the third delivery server <NUM> in addition to the EID.

The terminal <NUM> may establish a connection with the Primary third delivery server <NUM> based on the Primary third delivery server address set in the terminal <NUM> and, at step <NUM>, transmit a third delivery server address request message to the Primary third delivery server <NUM> along with the EID.

At step <NUM>, the Primary third delivery server <NUM> may transmit to the terminal <NUM> the third delivery server address corresponding to the EID received from the terminal <NUM> based on the EID-third delivery server address mapping information.

At step <NUM>, the terminal <NUM> may establish a connection with the third delivery server <NUM> based on the third delivery server address received from the terminal <NUM> to download the profile through interoperation with the third delivery server <NUM>.

According to an embodiment, the relay server <NUM> and the third delivery server <NUM> may be implemented as physically separated nodes or as a single node but separated logically. The relay server <NUM> and the third delivery server <NUM> may reside on the same server.

According to an embodiment, the system may include multiple third delivery servers <NUM> of the operator. In this case, one of the multiple third delivery servers is designated as the Primary third delivery server <NUM>.

Although the description is directed to the case where the terminal <NUM> connects to the operator server <NUM> directly or via the operator terminal <NUM>, it may also be possible for the terminal <NUM> to communicate signals with the operator server <NUM> via the Primary third delivery server <NUM>. In detail, the terminal <NUM> may directly transmit a profile request message to the Primary third delivery server <NUM>.

<FIG> is a block diagram illustrating a configuration of a Primary third delivery server according to another embodiment of the present invention.

In the embodiment of <FIG>, the Primary third delivery server may include at least one of a transceiver <NUM> for communication with a third delivery server and a terminal, a controller <NUM> for mapping an eUICC identifier and a third delivery server address received from the third delivery server and control transmitting the eUICC identifier to the Primary third delivery server in response to a third delivery server address request including the eUICC identifier which is transmitted by the terminal, and a storage unit <NUM> for storing the data input through the transceiver <NUM> and processing results of the controller <NUM>. The controller <NUM> may include at least one processor and control overall operations of the Primary third delivery server.

<FIG> is a block diagram illustrating a configuration of an operator terminal according to another embodiment of the present invention.

In the embodiment of <FIG>, the operator terminal may include at least one of an input unit <NUM> for receiving input of an eUICC identifier and a Primary third delivery server address, a transceiver <NUM> for transmitting the eUICC identifier and the Primary third delivery server address to an operator server, and a controller <NUM> for controlling operations of the operator terminal. The controller <NUM> may include at least one processor and control the overall operations of the operator terminal.

<FIG> is a block diagram illustrating a configuration of an operator server according to another embodiment of the present invention.

In the embodiment of <FIG>, the operator server may include at least one of a transceiver <NUM> for communication with an operator terminal and a relay server; a controller <NUM> for controlling the transceiver <NUM> to transmit the eUICC identifier, third delivery server address, and Primary third delivery server address received from at least one of an operator terminal and a user terminal; and a storage unit <NUM> for storing data input through the transceiver <NUM> and processing results of the controller <NUM>. The controller <NUM> may include at least one processor and control the overall operations of the operator server.

<FIG> is a block diagram illustrating a configuration of a relay server according to another embodiment of the present invention.

In the embodiment of the present invention, the relay server may include a transceiver <NUM> for communication with an operator server and a third delivery server; a controller <NUM> for controlling the transceiver to transmit an eUICC identifier, a third delivery server address, and a Primary third delivery server address received from the operator server; and a storage unit <NUM> for storing information related to the operations of the relay server. The controller <NUM> may include at least one processor and control the operations of the relay server.

In reference to <FIG>, at least one of an operator server <NUM>, a relay server <NUM>, a third delivery server <NUM>, a second delivery server <NUM>, a first delivery server <NUM>, an old terminal <NUM>, a target terminal <NUM>, and a Primary third delivery server <NUM> may communicate signals with another entity. Although not shown in <FIG>, the operator server <NUM> may communicate with terminals <NUM> and <NUM> via an operator terminal.

<FIG> shows a network configuration for barring an access with the profile of the legacy terminal <NUM> and permitting an access with the profile downloaded by means of the target terminal <NUM>. In detail, the old terminal <NUM> acquires a profile from the network and performs communication based on the acquired profile, while the target terminal <NUM> may be a terminal acquiring the profile after the legacy terminal <NUM> has acquired the profile. The profile information may correspond to at least one of a contract code, a profile ID, a terminal-specific EID, and a Primary third delivery server. A more detailed description thereof is made hereinafter with reference to <FIG> and <FIG>.

<FIG> is signal flow diagram illustrating a procedure for swapping terminals while maintaining a contract according to another embodiment of the present invention.

In reference to <FIG>, at least one of an old terminal <NUM>, a target terminal <NUM>, an eUICC <NUM>, an operator server <NUM>, a relay server <NUM>, a third delivery server <NUM>, a Primary third delivery server <NUM> , a second delivery server <NUM>, and a first delivery server <NUM> may communicate signals with another entity. In an embodiment, the eUICC <NUM> may be installed in the target terminal <NUM>, and the controller of the target terminal <NUM> may request to the eUICC <NUM> for information and receive the information from the eUICC <NUM>.

The target terminal <NUM> may transmit an information request message to the eUICC <NUM> at step <NUM> and receive a response message including the EID and Primary third delivery server address from the eUICC <NUM> at step <NUM>. The target terminal <NUM> may display the acquired EID and Primary third delivery server address on a display of the target terminal <NUM> at step <NUM>. According to an embodiment, the above steps may be performed selectively.

The old terminal <NUM> may, at step <NUM>, receive an input for selection of a menu item provided by the old terminal <NUM> for swapping the old terminal <NUM> for a new one while maintaining the current contract and may, at step <NUM>, receive an input for confirming the terminal swapping.

If the terminal swapping conformation menu item is selected, the old terminal <NUM> may scan the screen of the target terminal <NUM> by means of an input unit at step <NUM> to acquire the EID and Primary third delivery server address at step <NUM>. The old terminal <NUM> may acquire the above information through communication with the target terminal <NUM>.

The old terminal <NUM> may check the contract code stored therein or received from a server or the previously stored information for the operator server address at step <NUM> and establish a connection with the operator server <NUM> using the operator server address.

Steps <NUM> to <NUM> may be performed in a different order or simultaneously.

The old terminal <NUM> may transmit subscription information of the target terminal <NUM> to the operator server <NUM> at step <NUM>. The subscription information may include at least one of the EID of the target terminal <NUM>, a Primary third delivery server address of the target terminal <NUM>, a profile ID, and a contract code stored in the legacy terminal <NUM>. According to an embodiment, the EIDs of the old and target terminals <NUM> and <NUM> may be transmitted.

Although not shown in the drawing, instead of steps <NUM> and <NUM>, it may be possible for the old terminal <NUM> to transmit the EID and subscription information to the Primary third delivery server address stored in the terminal such that the Primary third delivery server <NUM> extracts the operator information from the subscription information and establishes a connection with the operator server <NUM> on behalf of the old terminal <NUM> to transmit the EID and subscription information. Meanwhile, the operator server <NUM> may receive the subscription information from the old terminal <NUM> or the Primary third delivery server <NUM> at step <NUM> and block the access of the old terminal <NUM> to the communication service. The step of blocking the access to the communication service may include updating the K value stored in the operator server <NUM> to a new value. The operator server <NUM> may perform the communication service update process in order for the target terminal <NUM> to connect to the network and transmit a profile request including at least part of the subscription information and the third delivery server address to the relay server <NUM>. For example, the operator server <NUM> transmits to the relay server <NUM> the profile request including the EID, Primary third delivery server address, and third delivery server address. The third delivery server address may be the address of the third delivery server <NUM> to which the target terminal <NUM> has to connect for profile download.

The relay server <NUM> may transmit to the third delivery server <NUM> at least part of the received information. For example, the relay server <NUM> may transmit to the third delivery server <NUM> at least one of the EID, third delivery server address, and Primary third delivery server address.

The third delivery server <NUM> may, at step <NUM>, transmit to the Primary third delivery server <NUM> a transaction request including at least part of the received information. If the transaction registration request including at least one of the EID and third delivery server address is received from the third delivery server, the Primary third delivery server <NUM> maps the EID and the third delivery server address and stores the mapping in a storage unit.

The target terminal <NUM> may establish a connection with the Primary third delivery server <NUM> based on the Primary third delivery server address set therein and, at step <NUM>, transmit to the Primary third delivery server <NUM> a third delivery server address request message including the EID corresponding to the target terminal <NUM>.

The Primary third delivery server <NUM> may check the EID-third delivery server address mapping information stored in a storage unit to retrieve the third delivery server address mapped to the EID and transmit the third delivery server address to the target terminal <NUM> at step <NUM>, and the target terminal <NUM> may establish a connection with the third delivery server <NUM> with the third delivery server address and download the profile through the interoperation with the third delivery server at step <NUM>.

<FIG> is a signal flow diagram illustrating a procedure for swapping terminals while maintaining a contract according to another embodiment of the present invention.

In reference to <FIG>, at least one of an old terminal <NUM><NUM>, a target terminal <NUM>, an eUICC <NUM>, an operator server <NUM>, a relay server <NUM>, a third delivery server <NUM>, a Primary third delivery server <NUM>, a second delivery server <NUM>, and a first delivery server <NUM> may communicate signals with another entity. According to an embodiment, the eUICC <NUM> may be installed in the target terminal <NUM>, and a controller of the target terminal <NUM> may request to the eUICC <NUM> for information and receive corresponding information.

In the embodiment of <FIG>, unlike the embodiment of <FIG>, the target terminal <NUM> may directly establish a connection with the operator server <NUM> to transmit subscription information.

For this purpose, the old terminal <NUM> may provide a menu item for terminal swapping. If an input for selecting the menu item is received at step <NUM>, the old terminal <NUM> may provide a menu item for confirming the terminal swapping. If an input for selecting the terminal swapping menu item is received at step <NUM>, the old terminal <NUM> may display a contract code received from the operator server <NUM> on its display. The contract code may include a communication server address information.

Also, the target terminal <NUM> may provide the terminal swapping menu item on its screen and, if the swapping menu item is selected at step <NUM>, the target terminal <NUM> may request to the UICC <NUM> for information at step <NUM> and receive the EID and Primary third delivery server address in reply at step <NUM>. At least one of the EID and Primary third delivery server address may be previously included in the target terminal <NUM>. The target terminal <NUM> may scan the screen of the old terminal by means of an input unit at step <NUM> to acquire the contract code of the old terminal <NUM> at step <NUM>. The target terminal <NUM> may acquire the contract code through communication with the old terminal <NUM>.

At step <NUM>, the target terminal <NUM> may check the contract code stored therein or acquired from the operator server <NUM> for an operator server address and establish a connection with the operator server <NUM> using the operator server address.

The target terminal <NUM> may transmit its subscription information to the operator server <NUM> at step <NUM>. The subscription information may include at least one of the EID of the target terminal <NUM>, the Primary third delivery server address, and the contract code stored in the old terminal <NUM>.

Although not shown in the drawing, instead of steps <NUM> and <NUM>, it may be possible for the target terminal <NUM> to transmit the EID and subscription information to the Primary third delivery server address stored in the target terminal such that the Primary third delivery server extracts the operator information from the subscription information and establishes a connection with the operator server <NUM> on behalf of the terminal target terminal <NUM> to transmit the EID and subscription information. At step <NUM>, the operator server <NUM> may receive the subscription information from the target terminal <NUM> or the Primary third delivery server <NUM> and block the access of the old terminal <NUM> to the communication service. The step of blocking the access to the communication service may include updating the K value stored in the operator server <NUM> to a new value. The operator server <NUM> may perform the communication service update process in order for the target terminal <NUM> to access a communication network and the operator server <NUM> may transmit to the relay server <NUM> a profile request including at least one of the EID, Primary third delivery server address, and third delivery server address received from the target terminal <NUM>. The third delivery server address may be the address of the third delivery server <NUM> to connect for profile download.

At step <NUM>, the relay server <NUM> may transmit to the third delivery server <NUM> at least one of the EID, third delivery server address, and Primary third delivery server address received from the operator server <NUM>.

The third delivery server <NUM> transmits to the Primary third delivery server <NUM> a transaction registration request including the EID and third delivery server address at step <NUM>, and the Primary third delivery server <NUM> maps the EID and the third delivery server address and stores the mapping in a storage unit.

The target terminal <NUM> may establish a connection with the Primary third delivery server <NUM> based on the Primary third delivery server address set therein and, at step <NUM>, transmit to the Primary third delivery server <NUM> a third delivery server address request message including the EID.

The Primary third delivery server <NUM> may check the EID-third delivery server address mapping information stored in a storage unit to retrieve the third delivery server address mapped to the EID and transmit the third delivery server address to the target terminal <NUM>, and the target terminal <NUM> may establish a connection with the third delivery server <NUM> with the third delivery server address at step <NUM> and download the profile through the interoperation with the third delivery server at step <NUM>.

It is obvious that operation of each step in the procedures of <FIG> and <FIG> can be applied to other embodiments.

<FIG> is a block diagram illustrating a configuration of an old terminal or a target terminal according to an embodiment of the present invention.

In reference to <FIG>, each of the old and target terminals may include at least one of an input unit <NUM> for receiving an input made by a user or received from a server and a display unit <NUM> for displaying information. In the case of the old terminal, the terminal may receive the EID and Primary third delivery server address input by means of the input unit <NUM> and display a contract code on the display unit <NUM>. In the case of the target terminal, it may receive the contract code of the old terminal that is input by means of the input unit <NUM> and display the EID and Primary third delivery server address of the target terminal on the display unit <NUM>. Each terminal may include at least one of an eUICC <NUM> for storing the EID and Primary third delivery server address and a transceiver <NUM> for communicating information with the terminal and a server.

Each terminal may also include a controller <NUM> for controlling the terminal operation according to an embodiment of the present invention. The controller <NUM> may include at least one processor and control other components to accomplish the terminal operation according to an embodiment of the present invention.

According to an embodiment, the profile installed in a terminal may be deleted in various situations. For example, a profile of which subscription to the operator has expired may be deleted. In the case that the user is allowed to delete the profile from the terminal, the profile may be deleted by mistake and cause significant inconvenience; thus, there is a need of configuring a profile deletion policy rule in the eUICC. A description is made in detail hereinafter of the procedure for configuring a profile deletion policy rule in the eUICC and deleting the profile from the terminal based on the profile deletion policy rule.

<FIG> is a signal flow diagram illustrating a procedure for downloading policy information to an eUICC according to an embodiment of the present invention.

In reference to <FIG>, a MNO Over-The-Air (MNO OTA) server <NUM> and the eUICC <NUM> may communicate signals.

In more detail, the MNO OTA server <NUM> may transmit policy rule configuration information to the eUICC <NUM> at step <NUM>. According to an embodiment, the policy rule configuration information may include at least one of a profile deletion operation identifier, a rule configuration value code, and server address.

According to an embodiment, the MNO may use the OTA server <NUM> to install an applet or file in a UICC. In detail, the MNO may set up a profile-related policy rule in the eUICC <NUM>. According to an embodiment, the MNO OTA server <NUM> may patch or update the information stored in the eUICC <NUM>. Also, the MNO OTA server <NUM> sets up or updates an applet or file in the profile stored in the eUICC <NUM>. The profile deletion policy rule may include generating or updating one or more Elementary Files (EFs) in the profile. If a specific EF is designated, it may be possible to store the file using a SELECT command. It may be possible to update the designated EF using an UPDATE BINARY or UPDATE RECORD command. It may be possible to generate the EFusing a CREATE FILE command.

In this case, the file may store the information as follows.

Profile Deletion Policy Rule Code value: This value may indicate profile information setup-related policy information and be set to <NUM>, <NUM>, <NUM>, or <NUM>. This code value may be interpreted in association with the eUICC as follows: (<NUM>: Deletion not allowed, <NUM>: Deletion allowed, <NUM>: Deletion allowed only with server authorization, <NUM>: Deletion allowed only with user authorization).

Notification Server Address value: This value may include a URL or IP address server, which informs profile information setup-related operations.

Authorization Server information: This information may include an address of a server for authorizing the right of profile information setup-related operations. In detail, this information may include at least one of a storage address of an L3 server for authorizing the profile deletion right, L3 server and L2 server address values, and a public key of the right authorization server.

The terminal and the eUICC may operate as follows according to the Profile Deletion Policy Rule Code value stored in the EF.

<FIG> is a signal flow diagram illustrating a profile deletion procedure according to an embodiment of the present invention.

In reference to <FIG>, the terminal <NUM> and the eUICC <NUM> may delete a specific profile through signal communication.

The embodiment of <FIG> is directed to the case where the Profile Deletion Policy Rule Code contained in the Profile is set to a value indicating "Deletion now allowed".

The terminal <NUM> may transmit to the eUICC <NUM>, at step <NUM>, a message for deleting the profile. The profile deletion message may include the ID of the profile to delete (Profile ID). In detail, the terminal <NUM> may transmit to the eUICC <NUM> a Delete Profile Command in the form of an Application Protocol Data Unit (APDU) command. The Delete Profile Command may include the Profile ID.

The eUICC <NUM> may check the received message and transmit a response message to the terminal <NUM> in reply at step <NUM>. In detail, the eUICC <NUM> transmits an error message to the terminal <NUM> without deleting the profile because the Profile Deletion Policy Rule inside the profile in the eUICC corresponding to the Profile ID is set to "Deletion not allowed. " The error message may be a "Not OK message. " The error message may be a response message corresponding to the Delete Profile Command including a predetermined Status byte (SW1 or SW2) indicating the error.

<FIG> is a signal flow diagram illustrating a profile deletion procedure according to another embodiment of the present invention.

In reference to <FIG>, a Notification Server <NUM>, a terminal <NUM>, and an eUICC <NUM> may communicate signals therebetween. The embodiment of <FIG> is directed to the case where the Profile Deletion Policy Rule Code configured in the Profile is set to a value indicating "Deletion allowed. " However, this embodiment may be applied to a case where the Profile Deletion Policy Rule Code is set to a different value.

The terminal <NUM> may transmit a profile deletion message to the eUICC <NUM> at step <NUM>. The profile deletion message may include an ID of the profile to delete (Profile ID). In detail, the terminal <NUM> may transmit to the eUICC <NUM> a Delete Profile Command in the form of an APDU command. The Delete Profile Command may include the Profile ID as a factor.

The eUICC <NUM> may check the information on the profile identified based on the received message and perform an operation according to the check result at step <NUM>. In detail, the eUICC <NUM> checks the Profile Deletion Policy Rule information included in the profile stored in the eUICC based on the Profile ID and performs an operation according to the check result. In this embodiment, the Profile Deletion Policy Rule for the profile identified based on the Profile ID is set to "Deletion allowed", and the eUICC <NUM> may delete the profile identified by the Profile ID.

The eUICC <NUM> may transmit a response message to the terminal <NUM> at step <NUM>. In detail, the eUICC <NUM> may transmit a Deletion OK message as the response message in reply to the APDU command. The Deletion OK message may be a Response message corresponding to the Delete Profile Command and include a predetermined Status byte (SW1 or SW2) to identify the Deletion OK. The response message may include the information on a notification server <NUM> to which profile update is reported. In this embodiment, the information on the notification server <NUM> may include the address of the server. The server address may be preconfigured and stored in the terminal <NUM>.

According to an embodiment, the terminal <NUM> may transmit, at step <NUM>, to the notification server <NUM> a message including the information indicating that a specific profile has been successfully deleted. In detail, if the EF corresponding to the Profile Deletion Policy Rule contained in the profile stored in the eUICC <NUM> includes the notification server address, the eUICC <NUM> may include the notification server address in the Deletion OK message being transmitted to the terminal <NUM>. The Deletion OK message may include a signature value encrypted with a private key stored in the eUICC <NUM>.

At step <NUM>, the terminal <NUM> may transmit to the Notification server <NUM> at least part of the information included in the Deletion OK message received from the eUICC <NUM>. In detail, if the information received at step <NUM> includes a notification server address, the terminal <NUM> may transmit the whole or part of the information included in the Deletion OK message to the Notification server <NUM> identified by the notification server address.

According to an embodiment, the terminal <NUM> may transmit to the Notification server <NUM> the information related to the profile deletion result based on the message received from the eUICC <NUM> regardless of a specific profile deletion result.

In reference to <FIG>, a third/second delivery server <NUM>, a terminal <NUM>, and an eUICC <NUM> may communicate messages for deleting a profile. According to an embodiment, the third/second delivery server <NUM> may be formed as logically separate nodes in a single server and referred to just as third delivery server.

This embodiment is directed to the case where the Profile Deletion Policy Rule Code contained in the Profile as a deletion target is set to a value indicating "Deletion allowed only with server authorization". The technical features of this embodiment may be applicable to the case where the code is set to a different value.

The terminal <NUM> may transmit a profile deletion message to the eUICC <NUM> at step <NUM>. The profile deletion message may include the ID of the profile as a deletion target (Profile ID). In detail, the terminal <NUM> may transmit to the eUICC <NUM> the Delete Profile Command in the form of an APDU command. The Delete Profile Command may include a Profile ID.

The eUICC <NUM> may check the information on the profile identified based on the received message and perform an operation according to the check result at step <NUM>. In detail, the eUICC <NUM> may transmit to the terminal <NUM> a message for triggering a related operation for the case where the Profile Deletion Policy Rule for the Profile ID is set to "Deletion allowed only with server authorization". In more detail, the eUICC <NUM> may transmit to the terminal <NUM> a Deletion Request message including a random challenge value, an eUICC certificate or a public key, and a signature for use by an external server with right authorization. In more detail, the Deletion Request message may include at least one of a corresponding Profile ID, generated random challenge, eUICC certificate, server address, and signature encrypted in the eUICC <NUM>. The Deletion Request message may be a response message corresponding to the Delete Profile Command and include a predetermined Status byte (SW1 or SW2) to identify the information related to the Deletion Request. The Deletion Request message may include the address of a server for performing authorization on the Profile Deletion as part of the EF value corresponding to the Profile Deletion Policy Rule contained in the profile in the eUICC. According to an embodiment, the random challenge may be referred to just as challenge.

If the Deletion Request message is received, the terminal <NUM> may transmit, at step <NUM>, the whole or part of the information included in the Deletion Request message to the third delivery server <NUM> identified by the server address. According to an embodiment, a third delivery server address may be included in the received message or pre-stored in the terminal <NUM>. According to an embodiment, the terminal <NUM> may check the message received at step <NUM> for the server address and transmit to the server identified by the server address a message including part or all of the information contained in the Deletion Request message. The server identified by the server address may be the third delivery server <NUM>.

The third delivery server <NUM> may determine at step <NUM> whether it can delete the profile based on the received message. In detail, the third delivery server <NUM> may check the Deletion Request message to determine whether it can delete the profile identified by the profile ID included therein and perform a right authentication process based on a preconfigured value or information received from an external server. Here, the third delivery server <NUM> may check at least part of the information included in the received message to verify the Deletion Request message and determine whether it is possible to delete the profile based on at least one of the eUICC certificate and signature value included in the message.

If it is determined at step <NUM> that the third delivery server <NUM> can delete the profile, the third delivery server <NUM> may generate and transmit a Delete Profile (OK) message to the terminal <NUM> at step <NUM>. The Delete Profile (OK) message may include at least one of the Profile ID, random challenge, third delivery server certificate or public key, and signature value. This message may also include an authorization success indicator (e.g., OK). According to an embodiment, the Delete Profile (OK) message may include at least one of an OK indicator, a Profile ID, a random challenge, a third delivery server public key, a third delivery server signature value, a second delivery server public key, and a second delivery server signature value. In this case, the third delivery server <NUM> may transmit the Deletion Request message to the second delivery server such that both the second and third delivery servers perform the profile deletion authorization in a distributed manner.

At step <NUM>, the terminal <NUM> may transmit to the eUICC <NUM> at least part of the information included in the Delete Profile (OK) message received from the terminal <NUM>.

The eUICC <NUM> may verify at least one of the random challenge value and server signature value included in the message at step <NUM>; delete, if the values are successfully verified, the profile at step <NUM>; and transmit a Delete OK message to the terminal <NUM> at step <NUM>. According to an embodiment, the Deletion OK message may be a response message corresponding to the Delete Profile Command and include a predetermined Status byte (SW1 or SW2) value for identifying the Deletion OK message. The Deletion OK message may include a signature encrypted with the private key stored in the eUICC <NUM>.

The terminal <NUM> may, at step <NUM>, transmit to the third delivery server <NUM> a message including the whole or part of the information included in the Deletion OK message.

Although this embodiment is directed to the case where the Profile Deletion Policy Rule Code configured in the Profile as a deletion target is set to a value indicating "Deletion allowed only with server authorization", the code value may include the information related to the signal transmitted/received when the third delivery server <NUM> fails authorization. The technical features of this embodiment may be applicable to the case where the code is set to a different value. However, the technical features of this embodiment may be applicable in a similar way to the case where the code is set to another value or the authorization result at third delivery server <NUM> is different.

The terminal <NUM> may transmit a profile deletion message to the eUICC <NUM> at step <NUM>. The profile deletion message may include the ID of the profile as an identifier of the profile to be deleted (Profile ID). In detail, the terminal <NUM> may transmit to the eUICC <NUM> the Delete Profile Command in the form of an APDU command. The Delete Profile Command may include a Profile ID.

The eUICC <NUM> may check the information on the profile identified based on the received message and perform an operation according to the check result at step <NUM>. In detail, the eUICC <NUM> may transmit to the terminal <NUM> a message for triggering a related operation for the case where the Profile Deletion Policy Rule for the Profile ID is set to "Deletion allowed only with server authorization". In more detail, the eUICC <NUM> may transmit to the terminal <NUM> a Deletion Request message including a random challenge value, an eUICC certificate or public key, and a signature for use by an external server with right authorization. In more detail, the Deletion Request message may include at least one of a corresponding Profile ID, generated random challenge, eUICC certificate, server address, and signature encrypted in the eUICC <NUM>. The Deletion Request message may be a response message corresponding to the Delete Profile Command and include a predetermined Status byte (SW1 or SW2) to identify the information related to the Deletion Request. The Deletion Request message may include the address of a server for performing authorization on the Profile Deletion as part of the EF value corresponding to the Profile Deletion Policy Rule contained in the profile in the eUICC.

The third delivery server <NUM> may determine, at step <NUM>, whether it can delete the profile based on the received message. In detail, the third delivery server <NUM> may check the Deletion Request message to determine whether it can delete the profile identified by the profile ID included therein and perform a right authentication process based on a preconfigured value or information received from an external server. Here, the third delivery server <NUM> may check at least part of the information included in the received message to verify the Deletion Request message and determine whether it is possible to delete the profile based on at least one of the eUICC certificate and signature value included in the message.

If it is determined that the third delivery server <NUM> can delete the profile, the third delivery server <NUM> may generate and transmit a Delete Profile (Not OK) message to the terminal <NUM> at step <NUM>. The Delete Profile (Not OK) message may include at least one of the Profile ID, random challenge, third delivery server certificate or public key, signature value, and an authorization failure indicator (e.g., Not OK).

According to an embodiment, the Delete Profile (Not OK) message may include at least one of a Not OK indicator, a Profile ID, a random challenge, a third delivery server public key, a third delivery server signature value, a second delivery server public key, and a second delivery server signature value. In this case, the third delivery server <NUM> may transmit the Deletion Request message to the second delivery server such that both the second and third delivery servers perform the profile deletion authorization in a distributed manner.

At step <NUM>, the terminal <NUM> may transmit to the eUICC <NUM> at least part of the information included in the Delete Profile (Not OK) message received from the terminal <NUM>.

The eUICC <NUM> may verify at least one of the random challenge value and server signature value included in the message at step <NUM>; skip, at step <NUM>, if the values are successfully verified, executing the Profile Deletion command based on the received information; and transmit a Deletion Not Done message to the terminal <NUM> at step <NUM>. According to an embodiment, the Deletion Not Done message may be a response message corresponding to the Deletion Profile Command message and include one of Status bytes (SW1 and SW2) for identifying the Deletion Not Done message. The Deletion Not Done message may include a signature encrypted with the private key stored in the eUICC <NUM>. According to an embodiment, if it is determined that the profile deletion is not allowed based on the information included in the message received from the third delivery server <NUM>, it may be possible to update the Profile Deletion operation indicator stored in the eUICC <NUM> with the information received from the third delivery server <NUM>.

The terminal <NUM> may, at step <NUM>, transmit to the third delivery server <NUM> a message including the whole or part of the information included in the Deletion Not Done message.

In reference to <FIG>, a terminal <NUM> and an eUICC <NUM> may communicate signals for deleting a certain profile. In this embodiment, it may be possible to delete a profile by entering a User Credential. Although this embodiment is directed to the case where the Profile Deletion Policy Rule Code contained in the profile is set to a value indicating "Deletion allowed only with user authorization", the features of the present invention are applicable in a similar way to other cases.

The terminal <NUM> may, at step <NUM>, transmit to the eUICC <NUM> a message for deleting the profile. The profile deletion message may include an ID of the profile as a target of deletion. In detail, the terminal <NUM> may transmit to the eUICC <NUM> a Delete Profile Command in the form of an APDU command. The Delete Profile Command may include the Profile ID.

The eUICC <NUM> may check the received message and transmit a response message to the terminal <NUM> in reply at step <NUM>. In detail, if Profile Deletion Policy Rule configured in the profile identified by the Profile ID in the eUICC <NUM> is set to a value indicating "Deletion allowed only with user authorization", the eUICC <NUM> may transmit to the terminal <NUM> a Deletion Request message for authorization. The Deletion Request message may include an indicator indicating necessity of User authorization and information on the type of User Credential. For example, the User Credential may include a Personal Identification Number (PIN), a Password, and fingerprint information. The User Credential may be included in the eUICC <NUM> or a separate storage device. The User Credential may be contained in the profile in the form of a file and generated and updated by an OTA of the operator as described with reference to <FIG> or may be stored in the eUICC or separate storage device in such a way that the user enters an APDU command into the terminal <NUM>. Although this embodiment is directed to the case where the User Credential is stored in the eUICC <NUM> for convenience of explanation, it is obvious that the technical feature of the present invention is applicable to other cases.

The terminal <NUM> may collect information related to a User Credential based on the information included in the received message at step <NUM>. In detail, the terminal <NUM> may display the information indicating the necessity of the User Credential on the display, i.e., the terminal <NUM> may display a screen prompting the user to enter the User Credential. The terminal <NUM> may receive the User Credential, which the user enters by means of an input unit of the terminal <NUM>. The User Credential may include at least one of a user ID, a password (or PIN), and a fingerprint.

The terminal <NUM> may transmit to the eUICC <NUM> a Delete Profile Command including the User Credential at step <NUM>. The User Credential may include a PIN or Password or a hash value thereof. If the User Credential is a fingerprint or other biometric authentication information, it is converted into a value capable of being verified and then contained in the Delete Profile Command being transmitted to the eUICC <NUM>.

The eUICC <NUM> may compare the User Credential contained in the Delete Profile Command and the User credential stored in the eUICC <NUM> and, if the User Credentials match, delete the profile at step <NUM>.

The eUICC <NUM> may transmit a Deletion OK message to the terminal <NUM> at step <NUM>. If the User Credentials do not match, the eUICC <NUM> may transmit a Deletion Not OK message to the terminal <NUM>.

In reference to <FIG>, a terminal <NUM> and an eUICC <NUM> may communicate signals for deleting a certain profile. In this embodiment, it may be possible to delete a profile by entering a User Credential. This embodiment is directed to the case where the Profile Deletion Policy Rule Code contained in the profile is set to a value indicating "Deletion allowed only with user authorization".

The terminal <NUM> may transmit to the eUICC <NUM> a message for deleting the profile at step <NUM>. The profile deletion message may include an ID of the profile as a target of deletion. In detail, the terminal <NUM> may transmit to the eUICC <NUM> a Delete Profile Command in the form of an APDU command. The Delete Profile Command may include the Profile ID.

The eUICC <NUM> may check the received message and transmit a response message to the terminal <NUM> in reply at step <NUM>. In detail, if Profile Deletion Policy Rule configured in the profile identified by the Profile ID in the eUICC <NUM> is set to a value indicating "Deletion allowed only with user authorization", the eUICC <NUM> may transmit to the terminal <NUM> a Deletion Request message for authorization. The Deletion Request message may include an indicator indicating necessity of User authorization, information on the type of User Credential, and a random challenge value for replay attack protection. The User Credential may include a PIN, a Password, and fingerprint information. The User Credential may be included in the eUICC <NUM> or a separate storage device. The information to be included in the Deletion Request message may be selectively determined. The UCredential may be contained in the profile in the form of a file and generated and updated by an OTA of the operator as described with reference to <FIG> or may be stored in the eUICC <NUM> or in a separate storage device in such a way that the user enters an APDU command into the terminal <NUM>. Although this embodiment is directed to the case where the User Credential is stored in the eUICC <NUM> for convenience of explanation, it is obvious that the technical feature of the present invention is applicable to other cases.

The terminal <NUM> may collect information related to a User Credential based on the information included in the received message at step <NUM>. In detail, the terminal <NUM> may display the information indicating the necessity of the User Credential on the display, i.e., the terminal <NUM> may display a screen prompting the user to enter the User Credential. The terminal <NUM> may receive the User Credential that the user enters by means of an input unit of the terminal <NUM>.

The terminal <NUM> may transmit to the eUICC <NUM> a Delete Profile Command including the User Credential at step <NUM>. The delete Profile Command may include information generated based on at least one of the random challenge value and User Credential information received from the eUICC <NUM>, e.g., a hash value generated based on at least part of the received information. If the User Credential is a fingerprint or other biometric authentication information, such information is converted into a value capable of being verified and then contained in the Delete Profile Command being transmitted to the eUICC <NUM>. In the case of using the biometric authentication information, the random challenge value may be used as a factor of a function of processing the biometric authentication information.

The eUICC <NUM> may compare the User Credential contained in the Delete Profile Command and the User Credential stored in the eUICC <NUM> at step <NUM> and, if the User Credentials match, delete the profile at step <NUM> and transmit a Deletion OK message to the terminal <NUM> at step <NUM>. If the User Credentials do not match, the eUICC <NUM> may transmit a Deletion Not OK message to the terminal <NUM>.

In the case of a terminal equipped with an eUICC, it may be necessary to perform a factory reset on the terminal in various situations such as device repair and swapping at a customer center. In this case, it may be necessary to initialize the profile and settings stored in the eUICC. The settings may include an eUICC platform Policy Rule. The eUICC platform Policy Rule may be a Policy Rule that is not included in the profile and that is stored in an eUICC Issuer Security Domain-Root (ISD-R) region, an eUICC Profile Manager region, or an eUICC OS region.

According to an embodiment, it may be possible to configure whether the eUICC factory reset can be performed with a Manufacturer Credential or a User Credential using the eUICC platform Policy Rule.

<FIG> is a signal flow diagram illustrating a factory reset procedure according to an embodiment of the present invention.

In reference to <FIG>, a terminal <NUM> and an eUICC <NUM> communicate signals for a factory reset. In detail, <FIG> shows a factory reset procedure of a case where a platform Policy Rule stored in the eUICC <NUM> is configured to allow factory reset with a User Credential.

The terminal <NUM> transmits a Factory Reset Command to the eUICC <NUM> at step <NUM>. The Factory Reset Command may include an identifier for identifying the eUICC <NUM>, e.g., EID.

The eUICC <NUM> may transmit to the terminal <NUM> a Factory Reset Request message for additional authentication at step <NUM>. According to an embodiment, the Factory Reset Request message may include at least one of the EID, random challenge value generated by the eUICC <NUM>, eUICC certificate, and eUICC signature. The Factory Reset Request message may be a response message transmitted in reply to the Factory Reset Command. The response message may be identified as the Factory Reset Request message by means of one of Status bytes (SW1 and SW2) included therein. The Factory Reset Request message may include at least one of an indicator indicating necessity of a User Credential and an indicator indicating the type of the User Credential.

Although this embodiment is directed to the case where the type of User Credential is set to a value indicating User Password, the technical features of the present invention are applicable in a similar way to other cases.

If it is identified that the User Credential type included in the Factory Reset Command is set to the value indicating User Password, the terminal <NUM> may display a screen prompting entry of the User Password on its display and receive the User Credential at step <NUM>. The user may input the password by means of an input unit of the terminal <NUM>. The User Credential for factory reset may be collected in other ways.

The terminal <NUM> may transmit to the eUICC <NUM> the Factory Reset Command generated based on the received information at step <NUM>. The Factory Reset Command may include part or all of the information (including challenge value) generated by the eUICC <NUM> and a hash value calculated with the User Password as an additional factor. The Factory Reset Command may include authentication information rather than calculated hash value.

The eUICC <NUM> may check the Factory Reset Command to verify the hash value with the User Password stored in its storage at step <NUM>.

If the User Credential verification succeeds, the eUICC <NUM> transmits a Factory Reset OK message to the terminal <NUM> at step <NUM>. If the User Credential verification fails, the eUICC <NUM> transmits a Factory Reset Not OK message to the terminal <NUM>. One of the Factory Reset OK and Factory Reset Not OK messages is transmitted as a response message corresponding to the Factory Reset Command. The response message may be identified as the Factory Reset OK or Factory Reset Not OK message by means of one of the Status bytes (SW1 and SW2) included therein.

In the case that the User Credential verification succeeds, the eUICC <NUM> may perform factory reset at step <NUM>. According to an embodiment, the Factory Reset OK message may be transmitted after the eUICC <NUM> has completed the factory reset process. In this case, the eUICC <NUM> may continue to hold the information for use in transmitting the Factory Reset OK message after completing the factory reset.

According to an embodiment, the terminal <NUM> may include the User Credential in the Factory Reset Command, and the eUICC <NUM> may verify the User Credential to perform factory reset only when factory reset is allowed.

<FIG> is a signal flow diagram illustrating a factory reset procedure according to another embodiment of the present invention.

In reference to <FIG>, a manufacturer device <NUM>, a terminal <NUM>, and an eUICC <NUM> may communicate signals for a factory reset. In detail, <FIG> shows a factory reset procedure for a case where a platform Policy Rule stored in the eUICC <NUM> is configured to allow factory reset with a terminal manufacturer credential. In this embodiment, the manufacturer device <NUM> may be a host device associated with the terminal <NUM> or a mobile operator and entrusted to guarantee reliability of a factory reset process.

First, the terminal <NUM> generates a Factory Reset Command to the eUICC <NUM>.

The terminal <NUM> may transmit the Factory Reset Command to the eUICC <NUM> at step <NUM>. The Factory Reset Command may include an identifier for identifying the eUICC <NUM>, e.g., EID.

The eUICC <NUM> may transmit to the terminal <NUM> a Factory Reset Request message for additional authentication at step <NUM>. According to an embodiment, the Factory Reset Request message may include at least one of the EID, a random challenge value generated by the eUICC <NUM>, an eUICC certificate, and an eUICC signature. The Factory Reset Request message may be a response message transmitted in reply to the Factory Reset Command. The response message may be identified as the Factory Reset Request message by means of one of Status bytes (SW1 and SW2) included therein. The Factory Reset Request message may also include an indicator indicating the necessity of the terminal manufacturer credential. This indicator may be defined separately or be analogized from one of the Status bytes (SW1 and SW2). The manufacturer credential may be a manufacturer certificate or a private key corresponding thereto.

The terminal <NUM> may transmits the Factory Reset Request message to the manufacturer device <NUM> at step <NUM>. The terminal <NUM> and the manufacturer device <NUM> may communicate signals through a wired or wireless connection such as a Universal Serial Bus (USB) connection, Serial connection, Bluetooth connection, and Wi-Fi connection.

The manufacturer device <NUM> may verify the eUICC signature included in the Factory Reset Request message for authorization at step <NUM>. The manufacturer device <NUM> may perform authorization on the Factory Reset Request with various means such as IP/PW or RFID assigned to service center staff.

If the authorization succeeds, the manufacturer device <NUM> may transmit to the terminal <NUM>, at step <NUM>, a Factory Reset Command including a signature value acquired by encrypting the challenge value included in the Factory Reset Request message and part or all of the information included in the Factory Reset Command with a private key corresponding to the manufacturer certificate. The Factory Reset Command may include the manufacturer certificate. The Factory Reset Command may also include a high level certificate of the manufacturer certificate. Examples of the certificate may include at least one of all certificates belonging to the certificate chain including the manufacturer certificate with the exception of the highest root certificate. The Factory Reset Command may further include an OK indicator indicating that factory reset is allowed.

If the Factory Reset Command is received from the manufacturer device <NUM>, the terminal <NUM> may transmit, at step <NUM>, a Factory Reset Command including part or all of the information included in the Factory Reset Command message received from the manufacturer device <NUM>.

The eUICC <NUM> may perform authorization on the Factory Reset Request at step <NUM> based on at least part of the received information. Meanwhile, the eUICC <NUM> may store the highest root certificate or public key. The root certificate or public key may be used to verify the manufacturer certificate included in the Factory Reset Command received from the terminal <NUM>. If the manufacturer certificate is valid, the eUICC <NUM> may check the challenge values included in the manufactured certificate and Factory Reset Command for verification of the signature value.

If the verification succeeds, the eUICC <NUM> transmits a Factory Reset OK message to the terminal <NUM> at step <NUM>. Otherwise if the verification fails, the eUICC <NUM> transmits a Factory Reset Not OK message to the terminal <NUM>. One of the Factory Reset OK and Factory Reset Not OK messages is transmitted as a response message corresponding to the Factory Reset Command. The response message may be identified as the Factory Reset OK or Factory Reset Not OK message by means of one of the Status bytes (SW1 and SW2) included therein.

In the case that the verification succeeds, the eUICC <NUM> may perform the factory reset at step <NUM>. According to an embodiment, the Factory Reset OK message may be transmitted after completing the factory reset. In this case, the eUICC <NUM> has to continue holding the information for use in transmitting the Factory Reset OK message during the factory reset.

In addition to the function for initializing all the information stored in the eUICC, such as the Factory Reset function, there may be a need of a function for deleting a specific profile. In detail, it may be necessary to make it possible to delete a profile regardless of the profile deletion indicator of the corresponding profile.

<FIG> is a signal flow diagram illustrating a Master Delete Procedure according to an embodiment of the present invention.

In reference to <FIG>, a manufacturer device <NUM>, a terminal <NUM>, and an eUICC <NUM> may communicate signals for Master Delete. In this embodiment, the Master Delete Procedure is performed using the terminal manufacturer credential.

The terminal <NUM> transmits a Master Delete Command message to the eUICC <NUM> at step <NUM>. The Master Delete Command message may include a Profile ID for identifying the profile as a target for deletion.

The eUICC <NUM> may transmit a Master Delete Request message to the terminal <NUM> for authorization at step <NUM>. The Master Delete Request message may include at least one of the profile ID, EID, random challenge value generated in the eUICC <NUM>, eUICC certificate, and eUICC signature. The Master Delete Request message may be a response message corresponding to the Master Delete Command. The response message may include an SW value for use in identifying the Master Delete Request message. The Master Delete Request message may include an indicator indicating the necessity of a terminal manufacturer credential. This indicator may be transmitted separately or derived from one of the Status bytes (SW1 and SW2). The manufacturer credential may be a manufacturer certificate or a private key corresponding thereto.

The terminal <NUM> may transmit the Master Delete Request message to the manufacturer device <NUM> at step <NUM>. The terminal <NUM> and the manufacturer device <NUM> may communicate signals through a wired or wireless connection such as a Universal Serial Bus (USB) connection, Serial connection, Bluetooth connection, and Wi-Fi connection.

The manufacturer device <NUM> may verify the eUICC signature contained in the Master Delete Request at step <NUM>. The manufacturer device <NUM> may perform authorization on the Master Delete Request with various means such as IP/PW or RFID assigned to service center staff.

If the authorization succeeds, the manufacturer device <NUM> may transmit to the terminal <NUM>, at step <NUM>, a Master Delete Command including a signature value acquired by encrypting the challenge value included in the Master Delete Request and part or all of the information contained in the Master Delete Command with a private key corresponding to the manufacturer certificate. The Master Delete Command may include the manufacturer certificate. The Master Delete Command may also include a high-level certificate of the manufacturer certificate. Examples of the certificate may include at least one of all certificates belonging to the certificate chain including the manufacturer certificate with the exception of the highest root certificate.

The Master Delete Command may further include an OK indicator indicating that the Master Delete is allowed.

If the Master Delete Command is received from the manufacturer device <NUM>, the terminal <NUM> may transmit to the eUICC <NUM> a Master Delete Command including part or all of the information contained in the received Master Delete Command at step <NUM>.

The eUICC <NUM> may perform authorization on the Master Delete Request at step <NUM> based on at least part of the received information. Meanwhile, the eUICC <NUM> may store the highest root certificate or public key. The root certificate or public key may be used to verify the manufacturer certificate included in the Master Delete Command received from the terminal <NUM>. If the manufacturer certificate is valid, the eUICC <NUM> may check the challenge values included in the manufacturer certificate and Master Delete Command for verification of the signature value.

If the verification succeeds, the eUICC <NUM> deletes, at step <NUM>, the profile identified by the Profile ID contained in the Master Delete Command and transmits a Master Delete Done message to the terminal <NUM> at step <NUM>. If the verification fails, the eUICC <NUM> may transmit a Master Delete Failed message to the terminal <NUM>. One of the Master Delete Done and Master Delete Failed messages is transmitted as a response message corresponding to the Master Delete Command. The response message may be identified as the Master Delete Done Master Delete Failed message by means of one of the Status bytes (SW1 and SW2) included therein.

The methods specified in the claims and specification can be implemented by hardware, software, or a combination of them.

In the case of being implemented in software, it may be possible to store at least one program (software module) in a computer-readable storage medium. The at least one program stored in the computer-readable storage medium may be configured for execution by at least one processor embedded in an electronic device. The at least one program includes instructions executable by the electronic device to perform the methods disclosed in the claims and specifications of the present invention.

Such a program (software module or software program) may be stored in a non-volatile memory such as random access memory (RAM) and flash memory, Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), a magnetic disc storage device, a Compact Disc-ROM (CD-ROM), Digital Versatile Discs (DVDs) or other type of optical storage device, and a magnetic cassette. It may also be possible to store the program in a memory device implemented in combination of part or all of the aforementioned media. The storage unit may include a plurality of memories.

The program may be stored in an attachable storage device accessible through a communication network implemented as a combination of Internet, intranet, Local Area Network (LAN), Wireless LAN (WLAN), and Storage Area Network (SAN). The storage device may be attached to the device performing the methods according to embodiments of the present invention by means of an external port. It may also be possible for a separate storage device installed on a communication network to attach to the device performing the methods according to embodiments of the present invention.

In the embodiments of the present invention, the components are described in singular or plural forms depending on the embodiment. However, the singular and plural forms are selected appropriately for the proposed situation just for explanatory convenience without any intention of limiting the present invention thereto; thus, the singular form includes the plural forms as well, unless the context clearly indicates otherwise. Although the embodiments have been described independently, the present invention includes a combination of two or more embodiments.

Claim 1:
A method by a system including a terminal (<NUM>), a subscription manager - data preparation, SM-DP+ (<NUM>) and a subscription manager - discovery server, SM-DS (<NUM>), the method comprising:
obtaining (<NUM>), by the SM-DP+ (<NUM>), an embedded universal integrated circuit card, eUICC, identifier, EID, of the terminal (<NUM>) and an address of the SM-DS (<NUM>);
receiving (<NUM>), from the SM-DP+ (<NUM>) by the SM-DS (<NUM>), a first message including an embedded universal integrated circuit card, eUICC, identifier, EID, of the terminal (<NUM>) and an address of the SM-DP+ (<NUM>);
storing (<NUM>), by the SM-DS (<NUM>), the EID of the terminal (<NUM>) and the address of the SM-DP+ (<NUM>);
receiving (<NUM>), from the terminal (<NUM>) by the SM-DS (<NUM>), a second message including the EID of the terminal (<NUM>);
retrieving (<NUM>), by the SM-DS (<NUM>), the address of the SM-DP+ (<NUM>) based on the second message including the EID of the terminal (<NUM>);
transmitting (<NUM>), to the terminal (<NUM>) by the SM-DS (<NUM>), the address of the SM-DP+ (<NUM>) for the terminal (<NUM>); and
establishing, by the terminal (<NUM>), a connection with the SM-DP+ (<NUM>) with the address of the SM-DP+ (<NUM>) received from the SM-DS (<NUM>) to download a profile associated with the eUICC of the terminal (<NUM>).