Method and device for profile transfer between two secure elements

Abstract

The present invention relates to a method for transferring a current profile from a source secure element within a source device to a target secure element within a target device, the method comprising the following steps: monitoring and recording by the source secure element of the modifications made to an initial profile installed in the source secure element to obtain the current profile; generation of a difference file between the initial profile and the current profile by the source secure element based on the recorded modifications; obtaining the initial profile and generating a profile to be installed on the target secure element by an SM-DP+; and loading and installing the generated profile in the target secure element, the installed profile corresponding to the initial profile to which the generated difference file was applied. [Fig. 2]

Description

Title of the invention: Method and device for profile transfer between two secure elements

[0001] The invention relates to the management of connection profiles in a secure element of a device connectable to a cellular network.

[0002] A device connectable to a cellular communication network, such as a mobile phone, traditionally includes a secure element used for authentication on the communication network(s), typically mobile telephony. Such secure elements include Universal Integrated Circuit Cards (UICCs), notably SIM cards (Subscriber Identity Modules), and their embedded version known as eUICCs (embedded UICCs), also called eSIMs. An eUICC module is a secure hardware element, generally small in size, that can be integrated into a host mobile terminal to implement the functions of a traditional SIM card.

[0003] eUICCs can include several subscriptions or profiles, each corresponding to an operator. Each profile includes subscription data, for example an IMSI (for "International Mobile Subscriber Identity"), cryptographic keys and algorithms, specific to a subscription provided by a mobile phone operator.

[0004] eUICC cards offer greater flexibility in subscription management, particularly in the provision and remote management of profiles. eUICC cards are reprogrammable and therefore allow, over time, the loading, deletion, and updating of multiple subscriber profiles (or communication profiles) within the same eUICC card. Each subscriber profile is contained in a secure container (noted ISD-P for "Issuer Security Domain Profile," which can only contain one profile) that, like a conventional SIM card, contains the data enabling authentication with a corresponding mobile network to access a service (e.g., voice or data) when the profile is active.

[0005] By changing the active subscriber profile in the eUICC card, it is possible to change operators or modify access to associated services.

[0006] The specification "SGP.22 - RSP Technical Specification - Version 2.3 - 30 June 2021", hereinafter "SGP.22", describes, in particular, a technical solution for the remote provisioning and management of eUICCs in consumer devices. The procedures described are typically initiated by the device. (including the eUICC) for the management of eUICCs (in the sense of administering the states of profiles, for example activated, deactivated, deleted, ...) and the initiation of a profile provision (for example, a request to load or (provision) a profile on an eUICC) and at the initiative of a server, called SM-DP+ (for "Subscription Manager Data Preparation enhanced"), within the framework of a technical solution for providing (or provisioning, or even distributing) profiles in eUICCs.

[0007] The specification "SGP.02 - Remote Provisioning Architecture for Embedded UICC Technical Specification - Version 4.2 - 07 July 2022", hereinafter "SGP.02", describes a technical solution for the remote provisioning and management of eUICCs embedded in M2M ("machine to machine") terminals. The procedures described are typically initiated by a pair of servers, designated SM-DP (for "Subscription Manager Data Preparation") and SM-SR (for "Subscription Manager Data Secure Routing").

[0008] Typical procedures for managing eUICCs as described in these specifications include, among others, profile loading and installation, profile activation, profile deactivation, and profile deletion.

[0009] When a user of a device connectable to a cellular communication network subscribes to a service provider, a connection profile is generated, transferred, and installed within the secure element of the device. This profile typically contains a file system and applications related to the user's subscription.

[0010] However, such a profile is not immutable. Certain operations result in modifications to the profile. These operations may be initiated by the user, such as changing their Personal Identification Number (PIN) or subscribing to an additional service. Other operations may be initiated by the operator, such as updating certain components of the profile. All these operations result in modifications to the profile over time.

[0011] In certain circumstances, the user may wish to transfer their subscription, and therefore their profile, from one device to another. The typical use case is a person acquiring a new mobile phone and wishing to transfer their subscription from their old phone to the new one.

[0012] When devices use physical SIM cards, this operation is simple. The user removes their SIM card from their old phone and inserts it into the new one, which can then use the user's subscription to connect to the cellular network. Since the user's profile is stored on the SIM card, this profile is transferred with the card in its current state. The user therefore retains all the customizations and updates made to their initial profile over time.

[0013] In the case of embedded secure elements, such as eUICCs for example, the transfer is significantly more complex. It is no longer possible to transfer the entire secure element, including the current profile, from one device to another. Only the profile needs to be transferred from one secure element to another. This transfer conflicts with the security mechanisms implemented in the standard. In particular, a profile is linked to a secure element and it is not normally possible to use it on another secure element. Furthermore, loading and installing a profile requires adherence to constraints on format, compression, and other aspects to comply with the installation mechanisms established by the aforementioned standards.

[0014] The invention presented aims to solve these problems. Description of the invention

[0015] To this end, the invention proposes a method for transferring a profile from a source eUICC to a destination eUICC. According to this method, the source eUICC, having loaded and installed an initial profile, maintains a file, called a delta, which records all the modifications made over time to the initial profile. The term "file" should be understood to mean any type of data format that ensures traceability and records information relating to data, for example, but not limited to, a profile element, a specific value, a stored variable, or a computer language object stored in electronic memory, a memory register, a database, etc. When the profile transfer is initiated by the source eUICC, this source eUICC obtains the identifier of the destination eUICC and notifies the SM-DP+ of the upcoming transfer. The SM-DP+ then retrieves the initial profile that had been loaded onto the source eUICC.In a first embodiment, the source eUICC transmits a delta to the SM-DP+, which applies it to the initial profile to prepare a profile corresponding to the current profile of the source eUICC. This profile can then be loaded and installed on the destination eUICC. A delta is understood to mean any difference from the initial profile that leads to the current profile or that results in, for example, a difference in content or memory size. These differences can include, but are not limited to, and potentially cumulative, application installations, modifications to values, file deletions, identification, referencing, or the recording or location of a modification. In a second embodiment, the source eUICC also transmits the delta to the SM-DP+, but the SM-DP+ does not apply it to the initial profile. Instead, this initial profile is loaded and installed in the destination eUICC.The SM-DP+ transmits the delta to the destination eUICC, which applies it to the initially installed profile. In a third embodiment, the source eUICC does not transmit the delta to the SM-DP+ but directly to the destination eUICC, which can then apply it after having... The initial profile obtained from SM-DP+ was loaded and installed. Applying a delta to an initial profile allows, for example, the integration, installation, and consideration of all differences that have occurred on the initial profile to result in a profile whose technical characteristics are identical to those of a current reference profile and towards which convergence is desired.

[0016] In all embodiments, the SM-DP+ controls the transfer. It updates the link information between the profile and the eUICC on which the profile is installed. It also ensures that the profile is deactivated in the source eUICC before any activation of the profile in the destination eUICC, in order to ensure that the same profile cannot be active in two different eUICCs.

[0017] A method for transferring a current profile from a source secure element within a source device to a target secure element within a target device is thus proposed, the method comprising the following steps: - monitoring and recording by the source secure element of the changes made to an initial profile installed in the source secure element to obtain the current profile; - generation of a file of differences between the initial profile and the current profile by the source secure element based on the recorded modifications; - obtaining the initial profile and generating a profile to be installed on the target secure element by an SM-DP+; and - loading and installation of the generated profile in the target secure element, the installed profile corresponding to the initial profile to which the generated differences file was applied.

[0018] In one embodiment, the process further comprises the following steps: - transmission of the difference file from the source secure element to the SM-DP+; and - application of the difference file to the initial profile by the SM-DP+ to generate the profile to be installed.

[0019] In one embodiment, the method further comprises the following steps: - transmission of the difference file from the source secure element to the target secure element; and - the generated profile corresponding to the initial profile, application of the difference file to the initial profile after its installation by the target secure element.

[0020] In one embodiment, the transmission of the difference file from the source secure element to the target secure element is done via the SM-DP+.

[0021] In one embodiment, the transmission of the difference file from the source secure element to the target secure element is done by a direct connection between the source device and the target device.

[0022] In one embodiment, the current profile comprising “Javacard” applications, the difference file integrates for each “Javacard” application a data packet representing the state of the “Javacard” application.

[0023] A method for transferring a current profile from a source secure element within a source device to a target secure element within a target device is also proposed, the method comprising the following steps by the source secure element: - monitoring and recording by the source secure element of the changes made to an initial profile installed in the source secure element to obtain the current profile; - generation of a difference file between the initial profile and the current profile by the source secure element based on the recorded changes; and - transmission of the difference file to the target device or to an SM-DP+ server.

[0024] A method for transferring a current profile from a source secure element within a source device to a target secure element within a target device is also proposed, the method comprising the following steps by the target secure element: - loading and installing an initial profile; - receipt of a file showing the differences between the initial profile and the current profile; and - application of the differences file to the initial installed profile to obtain the current profile.

[0025] A source secure element comprising a processor is also proposed, the processor being configured to perform the following steps for transferring a current profile from the source secure element within a source device to a target secure element within a target device: - monitoring and recording of changes made to an initial profile installed in the source secure element to obtain the current profile; - generation of a difference file between the initial profile and the current profile by the source secure element based on the recorded changes; and - transmission of the difference file to the target device or to an SM-DP+ server.

[0026] A target secure element comprising a processor is also proposed, the processor being configured to perform the following steps for transferring a current profile from a source secure element within a source device to the target secure element within a target device: - loading and installing an initial profile; - receipt of a file showing the differences between the initial profile and the current profile; and - application of the differences file to the initial installed profile to obtain the current profile.

[0027] The present invention also relates to a computer program comprising instructions for implementing the process described above, when this program is executed by a processor.

[0028] This program may use any programming language (for example, an object-oriented language or other), and may be in the form of interpretable source code, partially compiled code or fully compiled code.

[0029] Another aspect relates to a non-transient storage medium for a computer-executable program, comprising a set of data representing one or more programs, said one or more programs comprising instructions for, when said one or more programs are executed by a computer comprising a processing unit operationally coupled to memory means and an input / output interface module, to execute all or part of the process described above. Brief description of the drawings

[0030] Other features, details, and advantages of the invention will become apparent from the detailed description below. This description is purely illustrative and should be read in conjunction with the accompanying drawings, in which: Fig. 1

[0031] [Fig.1] illustrates the general architecture of a system for implementing the invention; Fig. 2

[0032] [Fig.2] illustrates the main steps of a profile transfer process between a source eUICC and a target eUICC according to two first embodiments of the invention; Fig. 3

[0033] [Fig.3] illustrates the main steps of a profile transfer process between a source eUICC and a target eUICC according to a third embodiment of the invention; Fig. 4

[0034] [Fig.4] is a schematic block diagram of an information processing device for the implementation of one or more embodiments of the invention; Detailed description

[0035] Fig. 1 illustrates the general architecture of a system for implementing the invention.

[0036] A first device 102 connectable to a cellular communication network, called the source device, includes a secure element 104, for example an eUICC. The eUICC 104, also called the source secure element 104 or simply eUICC source 104, includes an operating system and at least one connection profile that allows the source device to connect to the cellular communication network. The source device 102 also includes a Local Profile Assistant (LPA) module 103. The LPA 103 manages the profiles of the eUICC 104. The LPA supports communication between an SM-DP+ server 101 and the eUICC 104 to enable profile loading and network failover. Optionally, the LPA 103 can be located within the eUICC 104 instead of the source device 102.

[0037] A second device 112, similar to the first device 102, comprises its LPA 113 and its secure element 114, for example, an eUICC. The second device 112 is the target device in the profile transfer process described in this document, and the secure element 114 is the target secure element, also called the target eUICC 114. Optionally, the LPA 113 may be located in the target secure element 114 instead of in the target device 112.

[0038] The SM-DP+ server is responsible for preparing (or generating), distributing (or providing), and managing the connection profiles used by devices connectable to a cellular communication network. The SM-DP+ receives a profile preparation (or generation) request from the cellular communication network operator and prepares (or generates) at least one profile for an installation within a particular eUICC. The profiles are prepared by the SM-DP+ 101 based on data files or data provided by the cellular communication network operator as part of the preparation request sent by the operator.This preparation essentially consists of, for example, but not limited to, describing all the files and applications in the profile, setting all the unique identifiers of the profile (for example, the IMSI (International Mobile Subscriber Identity)), defining and implementing the means so that the profile can only be loaded on a specific recipient eUICC, etc. Also, for example, the SM-DP+ prepares the profile packages, secures them with a profile protection key, securely stores the profile protection keys and the protected profile packages in a secure repository. The SM-DP+ also allocates the secure profile packages to the specified eUICC identifiers (or to an eUICC identifier, called elD, for "eUICC IDentifier").The SM-DP+ also links the protected profile packets to the corresponding eUICC identifier (or elD) and securely uploads these linked profile packets to the corresponding eUICC's LPA. Furthermore, the SM-DP+ is also responsible for managing the profile status (e.g., enabled, disabled, deleted, etc.) on the eUICC. The profile is then encrypted using keys negotiated with the recipient eUICC. The profile can then be transmitted to the LPA, which will load it into the device's eUICC for installation.

[0039] The SM-DP+ also maintains a register of installed profiles containing the link between the profile and the eUICC in which the profile is installed. The SM-DP+ also ensures that only authorized entities can access it.

[0040] Communications between a device connectable to a cellular communication network and the SM-DP+ can use the cellular communication network when an active connection profile is present in the device's secure element. Alternatively, an alternative network interface of the device can be used. For example, the device may include a Wi-Fi interface enabling access to the Internet.

[0041] Direct communication between the LPAs of the source and target devices can also use the cellular communication network when an active connection profile is present in the secure element of both devices. Alternatively, when both devices are connected to the same Wi-Fi network, the latter can be used for these communications. Alternatively, a point-to-point network, typically using Bluetooth technology, can be established between the two devices. Finally, it is also possible to use Near Field Communication (NFC) technologies to exchange information between the two devices.

[0042] Exporting a profile from an eUICC can be applied in various use cases. One use case is when an operation, such as updating the eUICC's operating system, requires a significant amount of memory. In this case, it may be desirable to export a profile, perform the operation, and then re-import the profile. A second use case, as presented in the introduction to this document, involves transferring a profile from one device to another, for example, when a user changes their device.

[0043] In the first use case, the profile is re-imported into the same eUICC. Therefore, it does not present any interoperability constraints. In the second use case, the target eUICC may be produced by a different manufacturer than the one that produced the source eUICC; the exported profile must therefore be interoperable with the various eUICCs on the market.

[0044] A standard interoperable profile format exists, namely the SAIP format (for SIMAlliance Interoperable Profile), notably defined by the Trusted Connectivity Alliance (TCA) standard and entitled "eUICC Profile Package: Interoperable Format Test Specification", for example in its version 3.2.1 published in December 2022, used by the SM-DP+ when preparing profiles for loading onto an eUICC. However, the adoption of this format for exporting a The profile of an eUICC requires porting the functionalities used by SM-DP+, which are linked to this format, into the eUICC. This solution faces the difficulty of implementing these functionalities in the eUICC due to the limited memory and computing resources of eUICCs.

[0045] A so-called "current" profile, present in the source eUICC, is the profile to be exported. This current profile corresponds to an initial profile loaded and installed in the source eUICC, which has undergone modifications during or in the course of using the source device. According to one aspect of the invention, a file of differences between the initial profile and the current profile is generated by the source eUICC. Thus, it is possible to use the initial profile and this difference file to retrieve the current profile.

[0046] Figure 2 illustrates the main steps of a profile transfer process between a source eUICC and a target eUICC according to two first embodiments of the invention.

[0047] During step S201, the source eUICC monitors and records all changes made to the file system during the profile's lifetime. This monitoring must begin as soon as the initial profile is installed and continue as long as the profile is used by, and / or present on, the source device. Changes that may be made to the file system include deleting a file, adding a new file, or modifying an existing file. All such changes are recorded by the source eUICC. Similarly, the deletion and addition of applications to the profile are also monitored, as well as changes to application data. Data related to an application user or application usage is also monitored and recorded by the source eUICC as part of the changes made to the profile in which the application is installed or forms part of it.In one embodiment, only data related to an application of a profile is monitored and recorded as part of monitoring and recording all differences made to the file system.

[0048] During step S202, when the transfer is requested, typically by the device user, the source device requests the identifier of the target eUICC. This request is typically made by the source device's LPA to the target device's LPA. This request is typically transmitted via a Wi-Fi network to which both devices are connected, or via a Bluetooth connection between the two devices, or via an NFC connection between the two devices.

[0049] During step S203, the target device transmits the target eUICC identifier to the source device. The transmission is typically made from the LPA of the target device to the LPA of the source device.

[0050] During step S204, the source eUICC generates a difference file between the initial profile installed in the source eUICC and the current profile, based on all the differences continuously recorded during step S201. This difference file is referred to as the Delta in this document. Advantageously, the source eUICC generates a token that allows verification of the origin and integrity of the difference file. For example, the token could be a checksum of the Delta, typically a hash value calculated on the contents of the Delta, signed by the source eUICC.

[0051] According to a first alternative, the complete content of the modified or added files is added to the Delta. According to another alternative, with regard to modified files, the modified byte ranges are indicated and only these byte ranges are transmitted in the Delta.

[0052] It may happen that the profile contains "Javacard" type applications. These applications are distinguished by the existence of persistent application instances in memory. Monitoring file system changes is then insufficient to reflect the evolutions of the initial profile.

[0053] The standard provides a mechanism known as "Amendment H," specified in the document "GlobalPlatform Technology Executable Load File Upgrade Card Specification v2.3 - Amendment H Version 1.1" under reference GPC_SPE_120. This mechanism is designed to facilitate the updating of Javacard applications. It allows a Javacard application to export its state as a data packet. Thus, a Javacard application can export its state before being deleted. A new version of the Javacard application is then installed. This new version then re-imports the state from the previously exported data packet. The use of Amendment H requires that the Javacard application be compatible, that is, that it implements the routines enabling the export and subsequent import of its state as a data packet in accordance with Amendment H.

[0054] When the profile to be transferred includes one or more Javacard applications, these applications must be compatible with Amendment H. The mechanism of Amendment H is repurposed to generate, for each Javacard application in the profile, a data packet representing its state, which is integrated into the Delta difference file. During profile installation, the Javacard applications can then import these data packets and restore the state they had in the current profile within the source eUICC.

[0055] During step S205, the source device notifies the SM-DP+ of the transfer initiated between the source device and the target device. This notification includes the Delta file, which is transmitted to the SM-DP+. When a token is calculated, it is also transmitted to the SM- DP+ can then verify the origin and integrity of the Delta. The notification also includes the identifier of the target eUICC.

[0056] During step S206, the SM-DP+ retrieves, using the identifier of the source eUICC, which initiated the notification, the initial profile that was transmitted and installed in the source eUICC.

[0057] In a first embodiment, the SM-DP+, having the initial profile and the Delta difference file between this initial profile and the current profile, applies these differences to the initial profile and prepares a profile corresponding to the current profile for the target eUICC. It should be noted that the data packets corresponding to the state of a Javacard application cannot be applied by the SM-DP+. Indeed, these data packets can only be imported by the Javacard application itself after its installation within the target eUICC. These packets, when present in the Delta, are then integrated by the SM-DP+ into the profile it generates for use during installation within the target eUICC.

[0058] Alternatively, the data packets corresponding to the state of a "Javacard" application are made available to the target eUICC on a server. A URL (Uniform Resource Locator) address is then provided to the target eUICC to allow the loading of these data packets using the mechanism known as Amendment B and described in the document "GlobalPlatform Technology Remote Application Management over HTTP Card Specification v2.3 - Amendment B Version 1.2" under reference GPC_SPE_011.

[0059] In a second embodiment, the SM-DP+ prepares a profile corresponding to the initial profile for the target eUICC. This initial profile is restricted by the SM-DP+ to prevent it from being used directly by the target eUICC without first applying the Delta. In this embodiment, the SM-DP+ prepares a profile corresponding to the initial profile but does not apply the delta to it. The target eUICC will be responsible for applying the delta to the received prepared profile. The delta will be sent, along with the profile corresponding to the initial profile, by the SM-DP+ to the target eUICC. In this embodiment, applying the delta to the initial profile constitutes the final step in the installation of the received profile. The installed profile is therefore the initial profile to which the delta has been applied.

[0060] During step S207, the SM-DP+ notifies the source eUICC of the successful receipt of the notification and the Delta.

[0061] Upon receiving notification from the SM-DP+, the source eUICC deletes the current profile and notifies the SM-DP+ of this deletion during step S208. Indeed, the same profile cannot be installed, or at least activated, in two different eUICCs. The SM-DP+ is responsible for ensuring compliance with this constraint. As such, the SM-DP+ only allows the loading and installation of the transferred profile in the target eUICC once. The SM-DP+ ensures that the profile is deleted, or at least deactivated, in the source eUICC. This also ensures that the transferred profile is linked to only one eUICC at a time.

[0062] During step S209, the profile prepared by the SM-DP+ is transmitted to the LPA of the target device for installation in the target eUICC. In the first embodiment, the transmitted profile corresponds to the current profile; it can be directly loaded and installed in the target eUICC. In the second embodiment, the transmitted profile is the initial profile. The Delta file is then transmitted with the profile, as well as the token if one has been generated.

[0063] During step S210, the transmitted profile is loaded and installed in the target eUICC. In the second embodiment, the target eUICC installs the initial profile and then applies the Delta file to obtain an installed profile corresponding to the current profile that was installed in the source eUICC. In both embodiments, at the end of step S210, the current profile that was to be transferred is installed in the target eUICC.

[0064] During step S211, the target eUICC notifies the successful installation of the profile in the target eUICC. The SM-DP+ can then update the link information between the profile and the eUICC on which it is installed. The initial profile is then linked to the target eUICC and no longer to the source eUICC.

[0065] Figure 3 illustrates the main steps of a profile transfer process between a source eUICC and a target eUICC according to a third embodiment of the invention.

[0066] This third embodiment of the invention differs from the first two primarily in the method of transmitting the Delta difference file between the source eUICC and the target eUICC. In this third embodiment, the Delta is transmitted directly from the source device to the target device. This transmission uses a direct connection between the LPAs of the source and target devices.

[0067] The steps identical to the steps in [Fig.2] take up the references of [Fig.2] and will not be described again.

[0068] Step S305 corresponds to step S205 with the difference that the Delta is not transmitted by the source device to the SM-DP+.

[0069] During step S306, the profile prepared by the SM-DP+ corresponds to the initial profile that was loaded and installed in the source eUICC.

[0070] During step S309, the initial profile is transmitted by the SM-DP+ to the target device. This transmission does not include the Delta, as the latter was not transmitted to the SM-DP+.

[0071] The Delta file is transmitted directly from the source device to the target device during step S312. This transmission uses the direct connection between the LPA of the source device and the LPA of the target device. When the token is generated, it can The token can be transmitted along with the Delta to allow the target device to verify the origin and integrity of that Delta. Alternatively, the token can be transmitted to the SM-DP+ during step S305 and retransmitted to the target device along with the initial profile during step S309.

[0072] Step S310 corresponds to step S210 according to the second embodiment. That is to say, the LPA of the target device has the initial profile (received in step S309) which it transmits to the target eUICC for installation. The Delta is then also transmitted, by the LPA (received in step S312), to the target eUICC which applies it to the initial profile to obtain the current profile.

[0073] This third embodiment also differs from the first and second embodiments with respect to when the current profile can be deleted from the source eUICC. In the third embodiment, the eUICC is notified at step S313 of the successful installation of the current profile in the target eUICC. Only then does the source eUICC delete the current profile and notify the SM-DP+ at step S208. It should be noted that the SM-DP+ only allows activation of the current profile in the target eUICC after receiving notification of its deletion in the source eUICC. In one embodiment, the notification sent by the SM-DP+ at step S313 also corresponds to a sequence of commands for deactivating and deleting the current profile on the source eUICC.

[0074] Thus, the described method allows the SM-DP+ to control the profile transfer and keep the link information between the profile and the eUICC in which it is installed up to date. The described method reduces the need for direct communication between the source and target devices. It also reduces the need for profile preparation due to the reuse of the already generated initial profile.

[0075] Figure 4 is a schematic block diagram of an information processing device 400 for implementing one or more embodiments of the invention. The information processing device 400 may be a peripheral device such as a microcomputer, a workstation, or a mobile telecommunications terminal. The device 400 includes a communication bus connected to:

[0076] - a central processing unit 401, such as a microprocessor, denoted CPU;

[0077] - a 402 random access memory, denoted RAM, for storing the executable code of the method for carrying out the invention as well as registers adapted to record variables and parameters necessary for the implementation of the method according to embodiments of the invention; the memory capacity of the device can be supplemented by an optional RAM memory connected to an expansion port, for example;

[0078] - a read-only memory 403, denoted ROM, for storing computer programs for the implementation of the embodiments of the invention;

[0079] - a network interface 404, denoted NET, is normally connected to a network communication interface on which digital data to be processed is transmitted or received. The 404 network interface can be a single network interface, or composed of a set of different network interfaces (e.g., wired and wireless, or different types of wired or wireless interfaces). Data packets are sent over the network interface for transmission or are read from the network interface for reception under the control of the software application running in the 401 processor;

[0080] - a 405 user interface, denoted GUI, for receiving input from a user or to display information to a user;

[0081] - a storage device 406 as described in the invention and denoted HD;

[0082] - an input / output module 407, denoted IO, for receiving / sending data to / from external devices such as hard drives, removable storage media or others.

[0083] The executable code can be stored in read-only memory 403, on the storage device 406, or on a removable digital medium such as, for example, a disk. According to one embodiment, the executable code of the programs can be received via a communication network, through the network interface 404, in order to be stored in one of the storage means of the communication device 400, such as the storage device 406, before being executed.

[0084] The central processing unit 401 is adapted to command and direct the execution of instructions or portions of software code of the program or programs according to one of the embodiments of the invention, instructions which are stored in one of the aforementioned storage means. After power-up, the CPU 401 is capable of executing instructions from the main RAM 402, relating to a software application. Such software, when executed by the processor 401, causes the execution of the processes described.

[0085] In this embodiment, the device is a programmable device that uses software to implement the invention. However, alternatively, the present invention can be implemented in hardware (for example, in the form of an application-specific integrated circuit, or ASIC).

[0086] Naturally, to satisfy specific needs, a person competent in the field of the invention may apply modifications to the preceding description.

[0087] Although the present invention has been described above with reference to specific embodiments, the present invention is not limited to embodiments specific, and the modifications which fall within the scope of the present invention will be obvious to a person versed in the art.

Claims

Demands

1. A method for transferring a current profile from a source secure element within a source device to a target secure element within a target device, the method comprising the following steps: - monitoring and recording by the source secure element of the changes made to an initial profile installed in the source secure element to obtain the current profile; - generation of a difference file between the initial profile and the current profile by the source secure element based on the recorded changes; - obtaining the initial profile and generating a profile to be installed on the target secure element by a subscription management and data preparation server named SM-DP+; and - loading and installing the generated profile in the target secure element, the installed profile corresponding to the initial profile to which the generated difference file was applied.

2. Method according to claim 1, characterized in that the method further comprises the following steps: - transmission of the difference file by the source secure element to the SM-DP+; and - application of the difference file to the initial profile by the SM-DP+ to generate the profile to be installed.

3. Method according to claim 1, characterized in that the method further comprises the following steps: - transmission of the difference file by the source secure element to the target secure element; and - the generated profile corresponding to the initial profile, application of the difference file to the initial profile after its installation by the target secure element.

4. Method according to claim 3, characterized in that the transmission of the difference file from the source secure element to the target secure element is done via the SM-DP+.

5. Method according to claim 3, characterized in that the transmission of the difference file from the source secure element to the target secure element is done by a direct connection between the source device and the target device.

6. Method according to claim 1, characterized in that the current profile includes “Javacard” applications, the difference file integrates for each “Javacard” application a data packet representing the state of the “Javacard” application.

7. Method of transferring a current profile from a source secure element within a source device to a target secure element within a target device, the method comprising the following steps by the source secure element: - monitoring and recording by the source secure element of changes made to an initial profile installed in the source secure element to obtain the current profile; - generation of a difference file between the initial profile and the current profile by the source secure element on the basis of the recorded changes; and - transmission of the difference file to the target device or to a subscription management and data preparation server named SM-DP+.

8. Method of transferring a current profile from a source secure element within a source device to a target secure element within a target device, the method comprising the following steps by the target secure element: - loading and installing an initial profile; - receiving a difference file between the initial profile and the current profile; and - applying the difference file to the installed initial profile to obtain the current profile.

9. Source secure element comprising a processor, the processor being configured to perform the following steps for transferring a current profile from the source secure element within a source device to a target secure element within a target device: - monitoring and recording changes made to an initial profile installed in the source secure element to obtain the current profile; - generating a difference file between the initial profile and the current profile by the source secure element based on the recorded changes; and - transmission of the difference file to the target device or to a subscription management and data preparation server named SM-DP+.

10. Target secure element comprising a processor, the processor being configured to perform the following steps for transferring a current profile from a source secure element within a source device to the target secure element within a target device: - loading and installing an initial profile; - receipt of a file showing the differences between the initial profile and the current profile; and - application of the differences file to the initial installed profile to obtain the current profile.

Images