Patent Description:
A Universal Integrated Circuit Card (UICC) is a smart card inserted and used in a mobile terminal. The UICC stores personal information of a mobile communication subscriber, such as authentication information for network access, phonebook data, and text messages. When the mobile terminal connects to a mobile communication network such as a Global System for Mobile Communications (GSM), Wideband Code Division Multiple Access (WCDMA) or Long Term Evolution (LTE) network, the UICC performs subscriber authentication and traffic security key generation to thereby enable secure mobile communication. The UICC may store communication applications including a Subscriber Identity Module (SIM), Universal Subscriber Identity Module (USIM), and IP Multimedia Services Identity Module (ISIM) according to the type of a mobile communication network to which the subscriber connects. In addition, the UICC provides a high level security function to install a variety of applications such as electronic wallets, tickets and passports.

A typical UICC is manufactured as a proprietary smart card of a specific mobile network operator according to requests of the mobile network operator. At the time of shipment, such a UICC is pre-embedded with authentication information for access to the corresponding mobile operator network (e.g. USIM application, International Mobile Subscriber Identity (IMSI), and key value (K)). Hence, the mobile network operator receives a manufactured UICC and provides the received UICC to a subscriber, and, later if necessary, performs management of the UICC by installing, modifying and removing an application through over-the-air programming (OTA) or the like. After inserting the UICC into a mobile terminal, the subscriber may manipulate the mobile terminal to use network and application services of the corresponding mobile network operator. For change of terminal, the subscriber may pull out the UICC from the existing terminal and insert the same into a new terminal. Hence, authentication information, mobile phone number and phonebook data stored in the UICC may be used as is in the new terminal.

The European Telecommunications Standards Institute (ETSI) has defined physical configurations and logical functions of UICCs to maintain worldwide compatibility.

In addition, unlike an existing UICC card that is manufactured and distributed as a proprietary card of a particular mobile network operator, a new embedded secure element should enable authentication information of various mobile network operators to be installed and managed in a secure and flexible manner when a user having purchased a corresponding mobile terminal subscribes to a mobile network operator, unsubscribes from a mobile network operator, or changes mobile network operators. According to various usage scenarios such as purchase of a new terminal, the new embedded secure element should also enable configured authentication information and stored user data to be securely transferred to a new mobile terminal. <CIT> proposes several embodiments related to the management of secure elements, like UICCs embedding Sim applications, these secure elements being installed, fixedly or not, in terminals, like for example mobile phones. In some cases, the terminals are constituted by machines that communicate with other machines for M2M (Machine to Machine) applications.

The above description is provided to assist in a comprehensive understanding of various embodiments of the present disclosure.

In accordance with an embodiment of the present disclosure, a method for setting profiles for a profile server is provided as defined in the appended claims. In accordance with another embodiment of the present disclosure, a profile server is provided as defined in the appended claims. In accordance with another embodiment of the present disclosure, a method of setting profiles in a communication system is provided as defined in the appended claims. In accordance with another embodiment of the present disclosure, a communication system is provided as defined in the appended claims.

In a feature of the present disclosure, it is possible to effectively configure a profile in a mobile terminal.

Hereinafter, embodiments of the present disclosure are described in detail with reference to the accompanying drawings.

Descriptions of functions and constructions that are well-known in the relevant art and are not directly related with the present disclosure may be omitted to avoid obscuring the subject matter of the present disclosure.

In the drawings, some elements are exaggerated, omitted or only outlined in brief, and thus may be not drawn to scale. The same reference symbols are used throughout the drawings to refer to the same or like parts. The invention is defined in the independent claims <NUM>, <NUM>, <NUM> and <NUM>.

<FIG> illustrates an architecture of a communication system according to an embodiment of the present disclosure.

Referring to <FIG>, the communication system may include mobile terminals <NUM> and <NUM>, embedded Secure Elements (eSEs) <NUM> and <NUM> installed respectively in the mobile terminals <NUM> and <NUM>, a profile provider <NUM>, profile managers <NUM> and <NUM>, and an address search server <NUM>. In one embodiment, the address search server <NUM> may be omitted.

The embedded secure element <NUM> or <NUM> may be one of various types of embedded secure elements that can be attached to the substrate of the mobile terminal <NUM> or <NUM> or installed therein by some means. The embedded UICC (eUICC) is a type of a secure element embedded in a terminal. Profiles <NUM> and <NUM> are installed as a software item in the embedded secure elements <NUM> and <NUM>. The profile <NUM> or <NUM> is a software package containing information corresponding to one or more existing removable UICCs. For example, the profile may be defined as a software package that contains user data, such as one or more applications, subscriber authentication information and phonebook data, embedded in one UICC.

The profile provider <NUM> may be directly operated by a Mobile Network Operator (MNO) or may be operated by an agent fully trusted by the MNO. The profile provider <NUM> generates a profile for a subscriber subscribing to the corresponding mobile network operator, encrypts the profile, and sends the encrypted profile to the profile managers <NUM> and <NUM>. The profile provider <NUM> may be implemented as, for example, a profile providing server.

The profile managers <NUM> and <NUM> manage profiles for the embedded secure elements <NUM> and <NUM>. Due to characteristics of secure elements based on smart card technology, the same security key information is to be configured in both the embedded secure element <NUM> or <NUM> and the profile manager <NUM> or <NUM> before the mobile terminal <NUM> or <NUM> is sold to a user (typically, at the time of terminal manufacture). Hence, the profile manager <NUM> or <NUM> may be operated by the manufacturer of the embedded secure element <NUM> or <NUM> or the mobile terminal <NUM> or <NUM>. The profile manager <NUM> or <NUM> may be implemented as, for example, a profile management server.

The profile manager <NUM> or <NUM> receives an encrypted profile from the profile provider <NUM> and safely sends the same to the corresponding embedded secure element <NUM> or <NUM>, which decrypts and installs the profile. Thereafter, the profile manager <NUM> or <NUM> performs profile management including profile activation, deactivation, backup or deletion. According to the terminal state of subscription to mobile network operators, the embedded secure element <NUM> or <NUM> may store multiple profiles. In this case, if the mobile terminal <NUM> or <NUM> connects to a mobile communication network, one of the profiles stored in the embedded secure element <NUM> or <NUM> is selected and used.

<FIG> is a flowchart of a profile setting procedure according to an embodiment of the present disclosure.

<FIG> describes a procedure in which, in response to a request for profile transfer from the first embedded secure element <NUM> to the second embedded secure element <NUM>, profile information of the first embedded secure element <NUM> is backed up and is reconfigured so as to be installable in the second embedded secure element <NUM>, the reconfigured profile is installed in the second embedded secure element <NUM>, and processing is continued according to the results of installation and Authentication Center (AuC) update.

Referring to <FIG>, at operation <NUM>, the profile provider <NUM> or profile manager <NUM> receives a profile transfer request from a user or user terminal. The profile transfer request message may include an identifier of the first mobile terminal <NUM> or first embedded secure element <NUM> and an identifier of the second mobile terminal <NUM> or second embedded secure element <NUM>. When multiple profiles are stored in the first embedded secure element <NUM>, the profile transfer request message may further include, to indicate a desired profile, at least one of a profile identifier, Mobile Subscriber Integrated Services Digital Network-Number (MSISDN, phone number), and IMSI. Then, the profile manager <NUM> sends a profile backup request message to the first mobile terminal <NUM>.

At operation <NUM>, the first profile <NUM> stored in the first embedded secure element <NUM> is backed up, and is encrypted and sent to the profile providing server. Here, the first embedded secure element <NUM> of the first mobile terminal <NUM> may encrypt the first profile <NUM> using the public key in the certificate of the profile provider <NUM>. Alternatively, the first embedded secure element <NUM> of the first mobile terminal <NUM> may directly generate a symmetric key for encryption and decryption and encrypt the first profile <NUM> using the symmetric key, and may encrypt the symmetric key using the public key in the certificate of the profile provider <NUM> and send the encrypted symmetric key to the profile provider <NUM>.

For example, the first mobile terminal <NUM> may encrypt the entire contents of the first profile <NUM> for transfer. As another example, the first mobile terminal <NUM> may encrypt only user data of the first profile <NUM> (such as phonebook data) excluding security-sensitive data (such as the USIM authentication key K) and send the encrypted data. In this case, the profile provider <NUM> may add data corresponding to the unsent contents at operation <NUM> (described later). As another example, if necessary, the user may select a portion of applications and data constituting the first profile <NUM> to be transferred to the second embedded secure element <NUM>.

<FIG> illustrates a structure of data in a mobile terminal according to an embodiment of the present disclosure.

Referring to <FIG>, the mobile terminal <NUM> has a terminal ID <NUM>. The eSE <NUM> embedded in the mobile terminal <NUM> has an eSE ID <NUM>. The eSE <NUM> stores a profile <NUM>.

The profile <NUM> has a profile ID <NUM>. The profile <NUM> includes a USIM <NUM>. The USIM <NUM> includes an IMSI <NUM> and K <NUM>. The profile <NUM> further includes supplementary values <NUM> and <NUM>, which are used to deactivate the profile <NUM> when the profile <NUM> is illegitimately copied or cloned to another eSE. The profile <NUM> may further include an eSE ID <NUM> indicating the identifier of the eSE in which the profile <NUM> is to be installed. Here, terminal ID may be used instead of eSE ID, eSE ID and terminal ID may be used together, or a combination of eSE ID and terminal ID may be used. Later, for ease of description, it is assumed that only eSE ID is used in the field <NUM>.

The profile <NUM> may further include a signature <NUM>. The signature <NUM> may be used to detect illegitimate modification of the eSE ID <NUM> or USIM <NUM> by a third party attempting to clone the eSE <NUM>. The profile provider may generate the signature <NUM> by applying a digital signing procedure to the profile ID <NUM>, eSE ID and/or terminal ID <NUM>, and IMSI <NUM> and/or K <NUM> of the USIM <NUM>.

For example, the signature <NUM> may be generated using the following equation <NUM>.

When the signature <NUM> is generated using all of the profile ID <NUM>, eSE ID <NUM> and IMSI <NUM>, it is possible to prevent illegitimate copy of both the profile <NUM> and the USIM <NUM> through examination of the signature <NUM>.

As another example, the signature <NUM> may be generated using only the profile ID <NUM> and eSE ID <NUM>. That is, the signature <NUM> may be generated using the following equation <NUM>.

In this case, illegitimate copy of the profile <NUM> can be prevented while illegitimate copy of the USIM <NUM> cannot be prevented.

As another example, the signature <NUM> may be generated using only the profile ID <NUM> and IMSI <NUM>. That is, the signature <NUM> may be generated using the following equation <NUM>.

In this case, while illegitimate copy of the profile <NUM> cannot be prevented, illegitimate copy of the USIM <NUM> can be prevented.

<FIG> is a flowchart of a profile activation procedure according to an embodiment of the present disclosure. The mobile terminal <NUM> may activate the profile according to the procedure of <FIG>, and may detect illegitimate copy of the profile and/or the USIM through the procedure.

Referring to <FIG>, at operation <NUM>, the embedded secure element (eSE) <NUM> selects a profile. For example, the eSE <NUM> may select a profile according to user selection through the touchscreen or keypad. As another example, when the mobile terminal <NUM> boots or transitions from flight mode to communication mode, the eSE <NUM> may automatically select a profile. The eSE <NUM> may select at least one of stored profiles in a suitable way.

At operation <NUM>, the eSE <NUM> verifies the eSE ID in the selected profile. As described before, the terminal ID may be used instead of the eSE ID, or a combination of the eSE ID and terminal ID may be used.

If the eSE ID is not correct, the eSE <NUM> proceeds to operation <NUM> at which the eSE <NUM> does not utilize the selected profile. Here, the eSE <NUM> may discard the selected profile. Thereafter, the eSE <NUM> may select another profile and repeat the above procedure. Here, a profile having an incorrect identifier is not utilized. If the eSE ID is correct, the eSE <NUM> proceeds to operation <NUM>.

At operation <NUM>, the eSE <NUM> verifies the signature in the selected profile. If the signature is correct, the eSE <NUM> proceeds to operation <NUM> at which the eSE <NUM> utilizes the selected profile. If the signature is not correct, the eSE <NUM> proceeds to operation <NUM> at which the eSE <NUM> does not use the selected profile and may discard the same.

Referring back to <FIG>, at operation <NUM>, the profile provider <NUM> reconfigures the second profile <NUM> using data in the received first profile <NUM>.

For profile reconfiguration with reference to a scheme for illegitimate copy prevention described in <FIG> and <FIG>, the profile provider <NUM> should replace the identifier of the first embedded secure element <NUM> in the first profile <NUM> with the identifier of the second embedded secure element <NUM> and regenerate the signature correspondingly.

In addition, if the reconfigured second profile <NUM> is successfully installed in the second embedded secure element <NUM>, the existing first profile <NUM> installed in the first embedded secure element <NUM> must be removed or invalidated. IF the first profile <NUM> is not removed owing to a technical error or malicious intent, to prevent illegitimate use of the first profile <NUM>, the profile provider <NUM> may generate the second profile using the USIM authentication key K of the second profile <NUM> to be installed in the second embedded secure element <NUM> at operation <NUM>. The K of the second profile <NUM> may differ from that of the first profile <NUM>. Alternatively, the profile provider <NUM> may send the AuC of the corresponding mobile network operator a request for updating the K of the first profile <NUM> with that of the second profile <NUM>. Then, the AuC may update the K in accordance with the profile. Hence, although the first profile <NUM> is not removed from the first embedded secure element <NUM>, as the K of the AuC is changed, the first mobile terminal <NUM> is unable to connect to a 3GPP network by use of the USIM of the first profile <NUM>. In other words, when a connection approval request is received from the first mobile terminal <NUM> using the first profile <NUM>, the AuC performs authentication using the K stored in the AuC. In this case, as the K stored in the AuC has been updated with the K corresponding to the second profile <NUM>, the connection approval request made by the first mobile terminal <NUM> using the old K is rejected.

At operation <NUM>, the reconfigured second profile <NUM> is installed in the second embedded secure element <NUM>. The installation result is sent to the profile provider <NUM> and the profile managers <NUM> and <NUM>.

If installation of the second profile <NUM> is unsuccessful, the procedure ends. Hence, the first profile <NUM> installed in the first mobile terminal <NUM> remains in the same state as before the profile transfer request was made.

If installation of the second profile <NUM> is successful, the profile provider <NUM> proceeds to operation <NUM> at which the profile provider <NUM> sends an update K request to the AuC. The AuC updates the K and sends the update result to the profile provider <NUM>.

If update of the K is successful, the profile provider <NUM> proceeds to operation <NUM> at which the profile provider <NUM> sends a request message for deleting the first profile <NUM> to the first mobile terminal <NUM>. Then, the first mobile terminal <NUM> deletes the first profile <NUM>. As described before, although the first profile <NUM> is not removed at operation <NUM> owing to a technical error or malicious intent, as the AuC has updated the K at operation <NUM>, the first mobile terminal <NUM> using the first profile <NUM> is not allowed to access the network.

If update of the K is unsuccessful at operation <NUM>, the profile provider <NUM> proceeds to operation <NUM> at which the profile provider <NUM> sends a request message for deleting the second profile <NUM> to the second mobile terminal <NUM>. Then, the second mobile terminal <NUM> deletes the second profile <NUM> and returns to the state before the profile transfer request was made. Here, although the second profile <NUM> is not removed owing to a technical error or malicious intent, as the AuC has failed to update the K at operation <NUM>, the second mobile terminal <NUM> using the second profile <NUM> is not allowed to access the communication network.

Through the procedure described above, the profile may be transferred from the first mobile terminal <NUM> to the second mobile terminal <NUM> in a safe way. If a failure occurs at one operation of the procedure, the initial state is recovered as in the case of transaction processing.

<FIG> is a sequence diagram illustrating a profile setting procedure according to a first embodiment of the present disclosure.

The embodiment described in <FIG> may be realized on the system described in <FIG>.

Referring to <FIG>, at operation <NUM>, the MNO <NUM> receives a profile transfer request message from a user <NUM>. As described in connection with <FIG>, the profile transfer request message may include an identifier of the first mobile terminal <NUM> or first embedded secure element <NUM> and an identifier of the second mobile terminal <NUM> or second embedded secure element <NUM>. If multiple profiles are stored in the first embedded secure element <NUM>, the profile transfer request message may further include, to indicate a desired profile, at least one of a profile identifier, MSISDN and IMSI.

At operation <NUM>, user authentication is performed between the MNO <NUM> and user <NUM>. This is to reject a request from an unauthorized user. If user authentication is successfully performed, the procedure is continued.

At operation <NUM>, the MNO <NUM> forwards the received profile transfer request message to the profile provider <NUM>.

At operation <NUM>, to find the address of a profile manager related to the first embedded secure element <NUM> of the first mobile terminal <NUM> at which the profile to be transferred is stored, the profile provider <NUM> sends a query to the address search server <NUM> and receives a corresponding response therefrom. Instead of the address search server <NUM>, another type of address search interface or address storage device may be utilized. The address search server <NUM> may be implemented as a distributed server such as a Domain Name Service (DNS) server. Alternatively, the profile provider <NUM> may directly store and manage addresses corresponding to individual embedded secure elements. In this case, the profile provider <NUM> may find the address of the first profile manager <NUM> without external communication. Here, the address may be in the form of an IP address and/or a domain address.

At operation <NUM>, the profile provider <NUM> sends a profile backup request message to the first profile manager <NUM>, using the found address. Here, the profile backup request message may include an identifier of the first profile <NUM> to be transferred, an identifier of the first embedded secure element <NUM> (or the first mobile terminal <NUM>), and a certificate of the profile provider <NUM>. The certificate of the profile provider <NUM> includes an identifier of the MNO <NUM> as a field, and signing can be performed based thereon.

At operation <NUM>, the first profile manager <NUM> forwards the profile backup request message to the first mobile terminal <NUM>. The first profile manager <NUM> may extract the identifier of the first mobile terminal <NUM> or first embedded secure element <NUM> from the received profile backup request message, and identify the destination to which the profile backup request message is to be forwarded. In particular, if an MSISDN is delivered through operation <NUM>, an SMS message may be sent as a profile backup request message to the desired terminal. Here, the profile backup request message may include an identifier of the first profile <NUM> and a certificate of the profile provider <NUM>.

Upon reception of the profile backup request message, at operation <NUM>, the first mobile terminal <NUM> performs profile encryption. The first embedded secure element <NUM> of the first mobile terminal <NUM> may identify the identifier of the target profile <NUM> from the received profile backup request message. The first embedded secure element <NUM> encrypts at least a portion of the target profile <NUM>. Profile encryption is described in detail with reference to <FIG>.

At operation <NUM>, the first mobile terminal <NUM> sends the encrypted profile to the first profile manager <NUM>. Only when the MNO ID contained in the certificate of the profile provider is identical to the MNO ID contained in the profile <NUM> and the certificate is valid, operation <NUM> (encryption) and operation <NUM> (transfer) are performed.

At operation <NUM>, the first profile manager <NUM> forwards the backed-up profile to the profile provider <NUM>.

At operation <NUM>, the profile provider <NUM> configures a second profile <NUM> on the basis of the received profile and a new K. Description on how to configure the second profile <NUM> is given with reference to <FIG>.

At operation <NUM>, the profile provider <NUM> finds the address of the profile manager <NUM> related to the second embedded secure element <NUM> that will receive the second profile <NUM> through communication with the address search server <NUM>. Address search is similar to that at operation <NUM>. As described before, when the profile provider <NUM> directly maintains address information, it may find a desired address without external communication.

At operation <NUM>, the profile provider <NUM> installs the second profile <NUM> in the second embedded secure element <NUM> of the second mobile terminal <NUM> via the second profile manager <NUM>. The second profile <NUM> may be encrypted as in the case of the first profile <NUM>. If installation is successful, the procedure is continued.

At operation <NUM>, the profile provider <NUM> sends the AuC of the MNO <NUM> a request message for updating the K of the corresponding profile.

At operation <NUM>, the AuC notifies the profile provider <NUM> of the update result.

If update of the K is successful, at operation <NUM>, the profile provider <NUM> sends a request message for deleting the first profile <NUM> to the first mobile terminal <NUM>. If update of the K is unsuccessful, the second profile <NUM> will be deleted.

<FIG> is a sequence diagram illustrating a profile setting procedure according to a second embodiment of the present disclosure.

The embodiment of <FIG> is similar to that of <FIG>, but differs in that profile transfer is triggered by the first mobile terminal <NUM>.

Referring to <FIG>, according to user input or the like, the first mobile terminal <NUM> attempts to transfer the first profile <NUM> to the second embedded secure element <NUM> of the second mobile terminal <NUM>. At operation <NUM>, the first mobile terminal <NUM> finds the address of a profile manager related to the first embedded secure element <NUM> through communication with the address search server <NUM>. As described before, when the first mobile terminal <NUM> directly maintains such addresses, operation <NUM> may be skipped.

At operation <NUM>, the first mobile terminal <NUM>, using the found address, sends a profile transfer request message to the first profile manager <NUM>. The profile transfer request message may include an identifier of the first embedded secure element <NUM>, an identifier of a profile to be transferred (e.g. Profile ID, MSISDN or IMSI), and an identifier of the second embedded secure element <NUM>.

At operation <NUM>, the first profile manager <NUM> finds the address of a profile provider <NUM> related to the first embedded secure element <NUM> through communication with the address search server <NUM>. As described before, when the first profile manager <NUM> directly maintains such addresses, operation <NUM> may be skipped.

At operation <NUM>, the first profile manager <NUM> forwards the received profile transfer request message to the profile provider <NUM>.

Subsequently, operations <NUM> to <NUM> are identical or similar to operations <NUM> to <NUM> of <FIG>, and hence a detailed description thereof is omitted.

<FIG> is a block diagram of a profile provider according to an embodiment of the present disclosure.

Referring to <FIG>, the profile provider may include a communication unit <NUM> and a control unit <NUM>.

The communication unit <NUM> sends and receives signals, which are needed to realize at least part of the embodiments described in connection with <FIG>. For example, the communication unit <NUM> may receive a profile transfer request message and send a profile backup request message. The communication unit <NUM> may send an update request message for the K to the AuC and receive a corresponding result message. In addition, the communication unit <NUM> may send and receive encrypted profiles.

The control unit <NUM> performs processing needed to realize at least part of the embodiments described in connection with <FIG> and controls individual components of the profile provider accordingly. In particular, the control unit <NUM> may decrypt an encrypted profile and encrypt a plaintext profile.

<FIG> is a block diagram of a profile manager according to an embodiment of the present disclosure.

Referring to <FIG>, the profile manager may include a communication unit <NUM> and a control unit <NUM>.

The communication unit <NUM> sends and receives signals, which are needed to realize at least part of the embodiments described in connection with <FIG>. For example, the communication unit <NUM> may send and receive a profile transfer request message and a profile backup request message. In addition, the communication unit <NUM> may send and receive encrypted profiles.

The control unit <NUM> performs processing needed to realize at least part of the embodiments described in connection with <FIG> and controls individual components of the profile manager accordingly.

<FIG> is a block diagram of a mobile terminal according to an embodiment of the present disclosure.

Referring to <FIG>, the mobile terminal may include a communication unit <NUM> and a control unit <NUM>. The control unit <NUM> may include an embedded secure element <NUM>.

The control unit <NUM> performs processing needed to realize at least part of the embodiments described in connection with <FIG> and controls individual components of the mobile terminal accordingly. In particular, the control unit <NUM> may install a profile in the embedded secure element <NUM> or uninstall a profile therefrom. The control unit <NUM> may encrypt or decrypt a profile. Among operations performed by the embedded secure element <NUM>, some operations suitable for external processing may be performed by an entity external to the embedded secure element <NUM>.

In a related art technique employing a removable UICC, for terminal change from a first terminal to a second terminal, the UICC may be removed from the first terminal and be inserted into the second terminal. In this case, as a physical card is transferred, the problem of card copy or duplication between two terminals does not arise.

On the other hand, in a usage environment wherein a software profile corresponding to one existing UICC is transferred between two embedded secure elements of different terminals, the problem of illegitimate copy or duplicated usage of a profile may arise. Additionally, in the event that a failure occurs while the profile of a first mobile terminal is copied to a second mobile terminal and is removed, both of the first mobile terminal and the second mobile terminals may utilize the profile or neither thereof may use the profile. This is an erroneous situation.

According to various embodiments of the present disclosure, when a user purchases a new mobile terminal or replace an existing mobile terminal, the existing profile of the first mobile terminal can be safely transferred to the second mobile terminal. Moreover, after the profile is successfully transferred, only the second profile of the second mobile terminal is usable. When a failure occurs during profile transfer, the initial state is restored and only the first profile of the first mobile terminal is usable. Hence, characteristics of transaction processing (all or nothing) are achieved. In addition to applications provided initially by the MNO, applications added later to the profile (e.g. NFC banking/card application) and data added by the user (e.g. phonebook) may be transferred. In one embodiment, unlike an existing removable UICC (which carries all stored data when removed from or inserted into a terminal), it is possible to back up and transfer all or a portion of the contents of a profile according to user or MNO selection.

The backed-up first profile is reconfigured by the profile providing server into a second profile through data addition or modification so that the second profile is installable in the second embedded secure element. When a profile is backed up, security information such as USIM key (K) is excluded from the backup target. Hence, the security risk can be minimized even when the backed-up profile is leaked.

During profile reconfiguration, the first eSE ID is replaced with the second eSE ID so that the second profile is operable only in the second embedded secure element, preventing illegitimate profile copy. In addition, when the second profile is generated, the K managed by the AuC is changed. Hence, even when the first profile is not removed from the first embedded secure element, the first profile cannot be illegitimately used. Thereby, a security mechanism is provided.

In one embodiment of the present disclosure, security sensitive information (e.g. authentication key K of the USIM application) in the contents of a profile is not backed up, and the profile providing server adds corresponding data during profile reconfiguration, thereby minimizing the risk due to leakage. In the present disclosure, it is possible for the user or manager to designate applications and data to be backed up or transferred.

As described before, when a profile is successfully copied to the new embedded secure element, the profile is to be deleted from the old embedded secure element. It is necessary to cope with the possibility that two copies of the same profile are present in two mobile terminals because one copy is not deleted owing to an error or malicious intent. In one embodiment of the present disclosure, when a new profile is configured, the profile provider changes the USIM K and updates the AuC accordingly, preventing access to the communication network using the old profile.

As described above, it is necessary to prevent a profile from being copied to another embedded secure element without permission.

In one embodiment of the present disclosure, a profile is configured to include the identifier of the embedded secure element in which the profile is to be installed (eSE ID) and an associated signature, so that the profile is not installable or inoperable in a different embedded secure element. The signature prevents the eSE ID from being modified. The signature may be generated on the basis of a concatenation of important parameters in the profile (e.g. profile ID, eSE ID and IMSI) and a public key of the certificate of the profile providing server. Other similar schemes may be used to generate the signature. When the profile is normally transferred, the profile provider may change necessary values and then regenerate a signature.

Meanwhile, it is known to those skilled in the art that blocks of a flowchart (or sequence diagram) and a combination of flowcharts may be represented and executed by computer program instructions. These computer program instructions may be loaded on a processor of a general purpose computer, special purpose computer or programmable data processing equipment. When the loaded program instructions are executed by the processor, they create a means for carrying out functions described in the flowchart. As the computer program instructions may be stored in a computer readable memory that is usable in a specialized computer or a programmable data processing equipment, it is also possible to create articles of manufacture that carry out functions described in the flowchart. As the computer program instructions may be loaded on a computer or a programmable data processing equipment, when executed as processes, they may carry out steps of functions described in the flowchart.

A block of a flowchart may correspond to a module, a segment or a code containing one or more executable instructions implementing one or more logical functions, or to a part thereof. In some cases, functions described by blocks may be executed in an order different from the listed order. For example, two blocks listed in sequence may be executed at the same time or executed in reverse order.

In the description, the word "unit", "module" or the like may refer to a software component or hardware component such as an FPGA or ASIC capable of carrying out a function or an operation. However, "unit" or the like is not limited to hardware or software. A unit or the like may be configured so as to reside in an addressable storage medium or to drive one or more processors. Units or the like may refer to software components, object-oriented software components, class components, task components, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays or variables. A function provided by a component and unit may be a combination of smaller components and units, and may be combined with others to compose large components and units. Components and units may be configured to drive a device or one or more processors in a secure multimedia card.

The above description is provided to assist in a comprehensive understanding of various embodiments of the present disclosure. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope of the present disclosure.

Claim 1:
A method of setting profiles for a profile server, the method comprising:
receiving (<NUM>), from a first terminal (<NUM>), a first message that requests transfer of a portion or a whole of a first profile from a first secure element of the first terminal to a second secure element of a second terminal (<NUM>), the first message including an identifier of the first secure element and an identifier of the second secure element;
transmitting (<NUM>), to the first terminal, a second message requesting the portion or the whole of the first profile;
receiving (<NUM>), from the first terminal, the portion or the whole of the first profile; and
generating (<NUM>) a second profile using the portion or the whole of the first profile and using a Universal Subscriber Identity Module authentication key of the second profile, which is different from an authentication key of the first profile, the second profile including a signature which is obtained based on the identifier of the second secure element;
transmitting (<NUM>), to the second terminal, the generated second profile; and
transmitting (<NUM>), if the second profile is successfully installed in the second secure element, a third message requesting update of the authentication key of the first profile with that of the second profile to an authentication center.