Method and apparatus for transmitting a profile between two secure elements

Abstract

The present invention provides a method and apparatus for transmitting a profile between two secure elements. [Solution] The method includes the steps of: the source device 102 monitoring and recording changes made to the initial profile installed on the source secure element 104; the source secure element generating a difference file regarding the difference between the initial profile and the currently active profile based on the recorded changes; the SM-DP+ (Subscription Manager Data Preparation enhanced) 101 acquiring the initial profile and generating a profile to be installed on the target secure element 114; and the target device 112 loading and installing the generated profile. The profile to be installed matches the initial profile to which the generated difference file was applied.

Description

Technical Field

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

Background Art

[0002] Devices connectable to a cellular communication network, such as mobile phones, conventionally include a secure element used to authenticate it on one or more communication networks, typically a mobile phone network. This type of secure element includes Universal Integrated Circuit Cards (UICCs), particularly Subscriber Identity Module (SIM) cards, and their built-in versions are known as embedded UICCs (eUICCs), also called eSIMs. The eUICC module is typically a small and secure hardware element that can be incorporated into a host mobile terminal to use the functions of a conventional SIM card.

[0003] The eUICC can include multiple subscriptions or profiles, each corresponding to one operator. Each profile includes subscription data, such as International Mobile Subscriber Identity (IMSI) identifiers, encryption keys, and algorithms, etc., which are specific to the subscription provided by the mobile phone operator.

[0004] eUICC cards offer greater flexibility in subscription management and, in particular, in profile distribution and remote management. This is because eUICC cards are reprogrammable, and therefore multiple subscriber profiles (or communication profiles) can be loaded onto the same eUICC card over time, removed from it, and updated. Each subscriber profile is stored in a secure container (called an ISD-P (Issuer Security Domain Profile), which can only hold one profile at a time), which, like traditional SIM cards, can authenticate itself to access services (e.g., voice or data) on the corresponding cellular network if the profile is valid.

[0005] By changing the active subscriber profile within the eUICC card, it is possible to change service providers or alter access to related services.

[0006] The specification, SGP.22-RSP Technical Specification-version 2.3-June 30, 2021, hereafter referred to as SGP 22, describes technical solutions for distributing and remotely managing eUICCs, particularly those of mainstream terminals (consumer devices). The procedures described therein are typically performed by the terminal (including its eUICC) to manage the eUICC (in the sense of managing the profile status, e.g., enabled, disabled, deleted, etc.) and to initiate profile distribution (e.g., requesting the loading (or distribution) of a profile to the eUICC), and are performed as part of a technical solution for distributing (or providing, and even distributing) profiles within the eUICC by a server known as SM-DP+ (Subscription Manager Data Preparation enhanced).

[0007] The specification, SGP.02-Remote Provisioning Architecture for Embedded UICC Technical Specification-version 4.2-July 07,2022, hereinafter referred to as SGP.02, describes a technical solution for distributing and remotely managing eUICC embedded in M2M (Machine to Machine) terminals. The procedures described therein are typically performed by a pair of servers known as SM-DP (Subscription Manager Data Preparation) and SM-SR (Subscription Manager Data Secure Routing).

[0008] Typical procedures for managing eUICC as described in these specifications include, among other things, loading and installing profiles, enabling profiles, deactivating profiles, and deleting profiles.

[0009] When a user of a device capable of connecting to a cellular communication network enters into a subscription agreement with a service provider, a connection profile is generated, transmitted to the device's secure element, and installed. This profile typically includes a file system and applications linked to the user's subscription.

[0010] However, such profiles are not immutable. Some actions can change the profile. These actions can be performed by the user, for example, by changing their personal identification code (Personal Identification Number, PIN, code) or by subscribing to services included in their subscription. Other actions can be performed by the service provider, for example, by updating specific components of the profile. All of these actions change the profile over time.

[0011] Depending on the situation, users may want to transfer their subscriptions and, consequently, their profiles from one device to another. A typical use case is when someone buys a new mobile phone and wants to transfer their subscriptions from their old phone to the new one.

[0012] If the device uses a physical SIM card, this process is straightforward. The user simply removes their SIM card from their old phone and inserts it into the new phone, which then connects to the cellular network using their subscription. Since the user's profile is stored on the SIM card, this profile is transmitted along with the card in its current state. Therefore, the user can recall all customizations and updates made to their initial profile, even after time has passed.

[0013] For example, in the case of embedded secure elements such as eUICC, this transmission is clearly more complex. It is no longer possible to transmit an entire secure element, including currently active profiles, from one device to another. Only the profiles need to be transmitted from one secure element to another. This transmission involves security mechanisms introduced within the standard. In particular, a profile is linked to one secure element and typically cannot be used on another secure element. Furthermore, loading and installing a profile requires adhering to constraints on formatting, compression, and other aspects, and conforming to the installation mechanisms introduced by the aforementioned standard.

[0014] The presented invention aims to solve these problems. [Overview of the Initiative] [Means for solving the problem]

[0015] To this end, the present invention proposes a method for transmitting a profile from a source eUICC to a destination eUICC. According to this method, a source eUICC that has loaded and installed an initial profile stores a file called a delta that enumerates all changes made to the initial profile over time. The file should be understood to mean any kind of data format that ensures the traceability and recording of information about the data, which may include, but are not limited to, profile elements, specific values, stored variables, or computer language objects, memory registers, databases, etc. When a profile transmission is initiated by a source eUICC, this source eUICC obtains the identifier of the destination eUICC and notifies the SM-DP+ of the transmission to be performed. The SM-DP+ retrieves the initial profile that was loaded in the source eUICC. In the first embodiment, the source eUICC sends the delta to the SM-DP+, which can apply the delta to the initial profile to create a profile that matches the currently valid profile of the source eUICC, and then load and install it in the destination eUICC. Delta should be understood as all differences that start from the initial profile and lead to the currently active profile, or that result in differences in content or memory occupancy, for example. These differences could be, for example, application installations, changes to any values, file deletions, identifications, references, or even registration or localization of changes, without limitation and possibly cumulatively. In a second embodiment, the source eUICC also sends the Delta to the SM-DP+, but the SM-DP+ does not apply it to the initial profile. It is this initial profile that is loaded and installed in the destination eUICC. The SM-DP+ sends the Delta to the destination eUICC, which then applies it to the installed initial profile. In a third embodiment, the source eUICC sends the Delta directly to the destination eUICC, not to the SM-DP+, which then loads the initial profile obtained from the SM-DP+, installs it, and then applies its Delta.By applying the delta to the initial profile, it becomes possible, for example, to incorporate, install, and take into account any differences that have occurred in the initial profile, thereby arriving at a profile whose technical characteristics are the same as those of the current reference profile and which is desired to converge towards.

[0016] In all embodiments, SM-DP+ controls the transmission. 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 at the source eUICC before it is activated at the destination eUICC, so that the same profile cannot be activated at two different eUICCs.

[0017] Therefore, the proposal is a method for transmitting a currently valid profile from a source secure element on a source device to a target secure element on a target device, and this method involves the following steps: - The source secure element monitors and records changes made to the initial profile installed on the source secure element to obtain the currently active profile, - The source secure element generates a diff file containing the differences between the initial profile and the currently active profile based on the recorded changes, - SM-DP+ takes the step of obtaining an initial profile and generating a profile to be installed on the target secure element, - A step of loading and installing the generated profile into the target secure element, wherein the installed profile matches the initial profile to which the generated differential file was applied. Includes.

[0018] In one embodiment, the method also includes the following steps, namely, - The sending secure element sends the differential file to SM-DP+, - Step SM-DP+ applies the differential files to the initial profile to generate the profile to be installed. This also includes.

[0019] In one embodiment, the method also includes the following steps, namely, - The source secure element sends the differential file to the target secure element, - If the generated profile matches the initial profile, the target secure element applies the differential file to the post-installation initial profile. This also includes.

[0020] In one embodiment, the differential file is sent from the source secure element to the target secure element via SM-DP+.

[0021] In one embodiment, the differential file is transmitted from the source secure element to the target secure element via a direct connection between the source device and the target device.

[0022] In one embodiment, if the currently active profile includes Java Card applications, the differential file includes a data packet representing the state of each Java Card application.

[0023] The proposal also provides a method for transmitting a currently valid profile from a source secure element on a source device to a target secure element on a target device, which involves the following steps by the source secure element: - The source secure element monitors and records changes made to the initial profile installed on the source secure element to obtain the currently active profile, - A step in which the source security element generates a differential file regarding the difference between the initial profile and the currently effective profile based on the recorded changes; - A step in which the differential file is sent to the target device or the SM-DP+ server; including.

[0024] The proposal is also a method for transmitting the currently effective profile from the source security element on the source device to the target security element on the target device. This method includes the following steps by the target security element, namely: - A step in which the initial profile is loaded and installed; - A step in which a differential file regarding the difference between the initial profile and the currently effective profile is received; - A step in which the differential file is applied to the installed initial profile to obtain the currently effective profile; including.

[0025] The proposal is also a source security element including a processor. The processor performs the following steps to transmit the currently effective profile from the source security element on the source device to the target security element on the target device, namely: - A step in which the changes made to the initial profile installed in the source security element are monitored and recorded to obtain the currently effective profile; - A step in which the source security element generates a differential file regarding the difference between the initial profile and the currently effective profile based on the recorded changes; - A step in which the differential file is sent to the target device or the SM-DP+ server; configured to execute.

[0026] The proposal also includes a target secure element containing a processor, which transmits the currently valid profile from the source secure element on the source device to the target secure element on the target device by following the steps below, namely: - Steps to load and install the initial profile, - A step of receiving a difference file regarding the difference between the initial profile and the currently active profile, - Steps include applying the differential file to the installed initial profile to obtain the currently valid profile, It is configured to execute.

[0027] The present invention also covers computer programs that, when executed by a processor, include instructions for performing the methods described above.

[0028] This program may use any programming language (e.g., an object-oriented language or another) and may take the form of interpretable source code, partially compiled code, or fully compiled code.

[0029] Another aspect relates to a non-temporary storage medium for computer executable programs, which includes a dataset representing one or more programs, the one or more programs including instructions for performing all or some of the methods described above while the one or more programs are being executed by a computer which includes a processing unit operationally coupled to memory means and an input / output interface module.

[0030] Brief explanation of the drawing Other features, details, and advantages of the present invention will become apparent from the following detailed description. The above description is purely illustrative and should be read in reference to the accompanying drawings, as shown below. [Brief explanation of the drawing]

[0031] [Figure 1] The general architecture of a system for implementing the present invention is shown. [Figure 2] The key steps of a method for transmitting a profile between a source eUICC and a target eUICC according to two first embodiments of the present invention are shown. [Figure 3] The main steps of a method for transmitting a profile between a source eUICC and a target eUICC according to a third embodiment of the present invention are shown. [Figure 4] This is a schematic block diagram of an information processing device for implementing one or more embodiments of the present invention. [Modes for carrying out the invention]

[0032] Figure 1 shows a general architecture of a system for implementing the present invention.

[0033] A first device 102, called the source device, which is connectable to a cellular communication network, includes a secure element 104, for example, an eUICC. The eUICC 104, also called the source secure element 104 or more specifically, the source eUICC 104, includes an operating system and at least one connection profile that enables the source device to connect to the cellular communication network. The source device 102 also includes a module 103 (Local Profile Assistant, LPA) for local management of profiles. The LPA 103 manages the profiles of the eUICC 104. The LPA handles communication between the SM-DP+ server 101 and the eUICC 104, enabling profile loading and switching between networks. Optionally, the LPA 103 may be located within the eUICC 104 rather than in the source device 102.

[0034] The second device 112 is similar to the first device 102 and includes its LPA 113 and its secure element 114, for example, an eUICC. The second device 112 is the target device in the profile transmission method described herein, 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 the target device 112.

[0035] The SM-DP+ server is responsible for creating (or generating), distributing (or delivering, or even providing) connection profiles used by devices that can connect to a cellular communication network. AM-SP+ receives profile creation (or generation) requests from cellular communication network operators and creates (or generates) at least one profile for installation on a specific eUICC. The profile is created by SM-DP+101 based on data files or data provided by the cellular communication network operator as part of the creation request sent by the operator. This creation basically consists of, for example, describing all the files and applications of the profile, locating all the unique identifiers of the profile (e.g., IMSI (International Mobile Subscriber Identity)), defining and configuring means to ensure that the profile can be loaded into only one receiving eUICC, etc. Also, for example, SM-DP+ creates a profile packet, secures it with a profile protection key, and stores the profile protection key and the protected profile packet in a secure repository. SM-DP+ also assigns secure profile packets to a specified eUICC identifier (or a single eUICC identifier called an eID (eUICC IDentifier)). SM-DP+ also links the protected profile packets to their corresponding eUICC identifiers (i.e., eIDs) and securely downloads these linked profile packets to the LPA of the corresponding eUICC. In addition, SM-DP+ also manages the state of profiles on the eUICC (e.g., enabled, disabled, deleted, etc.). The profile is then encrypted using a key negotiated with the eUICC that received it. The profile can then be sent to the LPA, which loads the profile into the device's eUICC.

[0036] SM-DP+ also maintains the registers of installed profiles, including the link between the profile and the eUICC on which it is installed. SM-DP+ also ensures that only authorized entities can access it.

[0037] Communication between a device capable of connecting to a cellular communication network and SM-DP+ can use the cellular communication network if there is an active connection profile in the device's secure element. Alternatively, the device can also use an alternative network interface. For example, the device may include a WiFi interface for accessing the internet.

[0038] Direct communication between the source and target devices via LPA can also utilize a cellular communication network, provided that both devices have a valid connection profile in their secure elements. Alternatively, if both devices are connected to the same WiFi network, the WiFi network can be used for these communications. Alternatively, a point-to-point network can be established between the two devices, typically using Bluetooth technology. Finally, information can also be exchanged between the two devices using Near Field Communication (NFC) technology.

[0039] Exporting profiles from eUICC can be applied to various use cases. The first use case is when operations require significant memory, such as updating the eUICC operating system. In this case, it may be desirable to export the profile, perform the operation, and then re-import the profile. The second use case, as presented in the introduction of this specification, is when transferring a profile from one device to another, such as when a user changes their device.

[0040] In the first use case, the profile is imported back into the same eUICC. As a result, there are no interoperability constraints. In the second use case, the target eUICC may have been manufactured by a different manufacturer than the source eUICC, and therefore the exported profile must be interoperable with various commercially available eUICCs.

[0041] A standard interoperable profile format exists, namely the SAIP (SIMAlliance Interoperable Profile) format, which is specifically defined in the Trusted Connectivity Alliance (TCA) standard and used when creating profiles for SM-DP+ to load into eUICC, as described in the title, eUICC Profile Package, Interoperable Format Test Specification, version 3.2.1 of which was published in December 2022. However, adapting this format for exporting profiles from eUICC requires functionality linked to this format used by SM-DP+, which will be ported to eUICC. This solution faces difficulties in implementing these functions within eUICC due to its limited memory and computing resources.

[0042] The profile referred to as "currently active" within the source eUICC is the profile that needs to be exported. This currently active profile matches the initial profile loaded and installed in the source eUICC, which was modified during or while the source device was in use. According to one aspect of the present invention, the source eUICC generates a file relating to the difference between the initial profile and the currently active profile. Therefore, it is possible to recover the currently active profile using the initial profile and this difference file.

[0043] Figure 2 shows the key steps of a method for transmitting a profile between a source eUICC and a target eUICC according to two first embodiments of the present invention.

[0044] In step S201, the source eUICC monitors and records all changes made to the file system while the profile is active. This monitoring must begin as soon as the initial profile is installed and must continue as long as the profile is being used by and / or exists on the source device. Changes that can be made to the file system include deleting files, adding new files, or modifying existing files. All of these changes are recorded by the source eUICC. Similarly, the removal / addition of applications from / to the profile is monitored, as is changes to application data. Data linked to the user of an application or the use of an application is also monitored and recorded by the source eUICC as part of changes made to the profile on which the application is installed or is part of. In one embodiment, only data linked to applications in the profile is monitored and recorded as part of the monitoring and recording of all differences introduced to the file system.

[0045] In step S202, when transmission is typically requested by the user of the device, the source device requests the identifier of the target eUICC. This request is typically made from the source device's LPA to the target device's LPA. This request is typically transmitted over the WiFi network to which both devices are connected, over the Bluetooth connection between the two devices, or over the NFC connection between the two devices.

[0046] In step S203, the target device transmits the identifier of the target eUICC to the source device. This transmission is typically performed by the target device's LPA to the source device's LPA.

[0047] In step S204, the source eUICC generates a file relating to the difference between the initial profile installed on the source eUICC and the currently active profile, based on all the differences continuously recorded in step S201. This difference file is referred to herein as the delta. Advantageously, the source eUICC generates a token to verify the origin and completeness of the difference file. For example, the token may be a checksum of the delta, typically a hash value calculated with respect to the contents of the delta and signed by the source eUICC.

[0048] According to the first alternative, the entire contents of the modified or added file are added to the delta. According to the other alternative, for modified files, the modified byte ranges are indicated, and only these byte ranges are sent to the delta.

[0049] A profile may contain instances of Java Card applications. These applications are distinguished by the presence of persistent application instances in memory. Therefore, monitoring changes to the file system alone may not adequately reflect changes to the initial profile.

[0050] The standard specifies a mechanism known as Amendment H, as documented in the GlobalPlatform Technology Executable Load File Upgrade Card Specification v2.3-Amendment H Version 1.1, also known as GPC_SPE_120. This mechanism aims to facilitate updates of Java Card applications. It allows Java Card applications to export their state as data packets. Therefore, a Java Card application can export its state before being removed. A new version of the Java Card application is then installed. This new version then re-imports the state from the previously exported data packets. Using Amendment H requires that the Java Card application conform to it, that is, it implements routines that allow it to export its state as data packets in accordance with Amendment H and then import them.

[0051] If the profile to be transmitted contains one or more Java Card applications, these applications must conform to Amendment H. The mechanism of Amendment H deviates from its original purpose by generating a data packet representing the state of each Java Card application in the profile, which is then incorporated into the delta diff file. During profile installation, Java Card applications can then import these data packets and recover the state they had in the currently valid profile of the source eUICC.

[0052] In step S205, the source device notifies the SM-DP+ of the transmission initiated between the source device and the target device. This notification includes a delta file that is sent to the SM-DP+. Once the token is calculated, it is also sent to the SM-DP+, which allows for verification of the source and completeness of the delta. The notification also includes the identifier of the target eUICC.

[0053] In step S206, SM-DP+ uses the identifier of the source eUICC that sent the notification to recover the initial profile that was sent to and installed on the source eUICC.

[0054] In the first embodiment, SM-DP+, which has an initial profile and a delta difference file relating to the difference between the initial profile and the currently valid profile, applies these differences to the initial profile to create a profile that matches the currently valid profile for the target eUICC. It should be noted that data packets corresponding to the state of the Java Card application cannot be applied by SM-DP+. This is because these data packets can only be imported into the Java Card application itself after it has been installed on the target eUICC. If these packets are present in the delta, they are incorporated into the profile that SM-DP+ generates, and thus they can be used during installation on the target eUICC.

[0055] Alternatively, data packets corresponding to Java Card applications are provided to the target eUICC on the server. A URL (Uniform Resource Locator) address is then delivered to the target eUICC, allowing these data packets to be loaded using Amendment B, as described in the document referred to as GPC_SPE_011, Global Platform Technology Remote Application Management over HTTP Card Specifications v2.3-Amendment B Version 1.2.

[0056] In a second embodiment, the SM-DP+ creates a profile for the target eUICC that matches the initial profile. The initial profile is constrained by the SM-DP+ so that it cannot be directly used by the target eUICC unless a delta is first applied to it. In this embodiment, the SM-DP+ creates a profile that matches the initial profile but does not apply a delta to it. The target eUICC is responsible for applying a delta to the created profile it receives. The delta is sent to the target eUICC by the SM-DP+ along with the profile that matches the initial profile. In this embodiment, applying a delta to the initial profile is the final step in installing the received profile. Therefore, the profile to be installed is the initial profile with the delta applied.

[0057] In step S207, SM-DP+ notifies the source eUICC that the notification and delta have been properly received.

[0058] Upon receiving notification from SM-DP+, the source eUICC deletes the currently active profile and notifies SM-DP+ of this deletion in step S208. This is because the same profile cannot be installed, or at least enabled, in two different eUICCs. SM-DP+ plays a role in ensuring this restriction is enforced. Therefore, SM-DP+ will not allow the transmitted profile to be loaded and installed in the target eUICC until it has been confirmed that it has been deleted, or at least disabled, in the source eUICC. In this way, SM-DP+ ensures that a transmitted profile can only be linked to one eUICC at a time.

[0059] In step S209, the profile created by SM-DP+ is sent to the LPA of the target device to be installed on the target eUICC. In the first embodiment, if the sent profile matches a currently valid profile, it can be loaded and installed directly onto the target eUICC. In the second embodiment, the sent profile is an initial profile. Then, the delta file is sent along with the profile and, if a token has been generated, this token as well.

[0060] In step S210, the transmitted profile is loaded and installed on the target eUICC. In the second embodiment, the target eUICC installs the initial profile and then applies the delta file to obtain the installed profile, which matches the currently valid profile installed on the source eUICC. In both embodiments, at the end of step S210, the currently valid profile to be transmitted is installed on the target eUICC.

[0061] In step S211, the target eUICC provides notification that the profile has been successfully installed on 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, rather than the source eUICC.

[0062] Figure 3 shows the main steps of a method for transmitting a profile between a source eUICC and a target eUICC according to a third embodiment of the present invention.

[0063] This third embodiment of the present invention differs from the first two in that it fundamentally differs 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.

[0064] For steps that are the same as those in Figure 2, we will reuse the references in Figure 2 and will not repeat the explanation.

[0065] Step S305 corresponds to step S205, but differs in that the delta signal is not sent to SM-DP+ by the source device.

[0066] In step S306, the profile created by SM-DP+ is loaded into the source eUICC and matches the installed initial profile.

[0067] In step S309, the initial profile is sent to the target device by SM-DP+. This transmission does not include delta because delta is not sent to SM-DP+.

[0068] In step S312, the delta file is sent directly from the source device to the target device. This transmission uses a direct connection between the source device's LPA and the target device's LPA. Once a token is generated, it can be sent along with the delta so that the target device can verify the origin and integrity of that delta. Alternatively, the token can be sent to the SM-DP+ in step S305 and then sent to the target device along with the initial profile in step S309.

[0069] Step S310 corresponds to S210 in the second embodiment. That is, the LPA of the target device has an initial profile (received in step S309) and transmits it to the target eUICC for installation. The delta is also transmitted by the LPA to the target eUICC (received in step S312), which applies it to the initial profile to obtain the currently valid profile.

[0070] This third embodiment differs from the first and second embodiments in that it concerns when the currently active profile can be removed from the source eUICC. In the third embodiment, the eUICC is notified in step S313 that the currently active profile has been successfully installed on the target eUICC. Only then does the source eUICC remove the currently active profile and notify the SM-DP+ of this in step S208. It should be noted that the SM-DP+ will not activate the currently active profile in the target eUICC until it has received notification from the source eUICC that it has been removed. In one embodiment, the notification sent by the SM-DP+ in step S313 also corresponds to a series of commands to deactivate and remove the currently active profile on the source eUICC.

[0071] Therefore, according to the described method, SM-DP+ can control the transmission of profiles to keep the link information between the profile and the eUICC on 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 to create profiles, considering that an already generated initial profile will be reused.

[0072] Figure 4 is a schematic block diagram of an information processing device 400 for implementing one or more embodiments of the present invention. The information processing device 400 may be a microcomputer, a workstation, or a peripheral device such as a mobile telecommunications terminal. The device 400 includes a communication bus to which the following are connected: - A central processing unit (CPU), such as a microprocessor, 401. - A random access memory 402 called RAM for storing executable code for a method to implement the present invention, and registers suitable for recording variables and parameters necessary for performing the method according to embodiments of the present invention. The memory capacity of the device may be supplemented, for example, by an optional ROM connected to an expansion port. - A read-only memory 403 called ROM for storing a computer program for implementing an embodiment of the present invention. - A network interface 404, called NET, is typically connected to a communication network through which digital data processed is sent and received. The network interface 404 may consist of a single network interface or a group of different network interfaces (e.g., wired and wireless interfaces, or various types of wired or wireless interfaces). Data packets are sent to the network interface for transmission or read from the network interface for reception, under the control of a software application running on the processor 401. - A user interface called a GUI 405 for receiving input from the user or displaying information to the user. -A storage device 406 called an HD, as described in the present invention. - An input / output module 407, known as I / O, for sending and receiving data with external peripheral devices such as hard disks and removable storage media.

[0073] The executable code may be stored in read-only memory 403, in storage device 406, or on removable digital media such as a disk. According to one variant, the program's executable code may be received by the communication network via network interface 404 before execution and stored in one of the storage means of the communication device 400, such as storage device 406.

[0074] The central processing unit 401 is configured to control and direct the execution of instructions or segments of software code of one or more programs according to one embodiment of the present invention, the instructions being stored in one of the aforementioned storage means. When powered on, the CPU 401 can execute instructions from the main RAM memory 402 relating to the software application. When such software is executed by the processor 401, it causes the method described to be performed.

[0075] In this embodiment, the device is a programmable device that implements the present invention using software. However, alternatively, the present invention can also be implemented in hardware (for example, as an application-specific integrated circuit, i.e., an ASIC).

[0076] Naturally, those skilled in the art of the present invention may modify the above description to suit specific needs.

[0077] Although the present invention has been described in relation to specific embodiments, the present invention is not limited to these specific embodiments, and improved forms that fall within the field of application of the present invention will be obvious to those skilled in the art. [Explanation of symbols]

[0078] 101 SM-DP+ 102 Source device 103 LPA 104 Source Secure Element 112 Target Devices 113 LPA 114 Targeted Secure Elements 400 Information Processing Devices 401 Central Processing Unit 402 Random Access Memory 403 Read-Only Memory 404 Network Interface 405 User Interface 406 Storage Devices 407 Input / Output Module

Claims

1. A method for transmitting a currently valid profile from a source secure element on a source device to a target secure element on a target device, comprising the following steps: - The source secure element monitors and records changes made to the initial profile installed on the source secure element, and obtains the currently valid profile. - The sending secure element generates a difference file relating to the difference between the initial profile and the currently active profile based on the recorded changes, - The SM-DP+ obtains the initial profile and generates a profile to be installed on the target secure element, - A step of loading the generated profile into the target secure element and installing it, wherein the installed profile matches the initial profile to which the generated differential file has been applied, Methods that include...

2. The following steps, namely, - The sending secure element transmits the differential file to the SM-DP+, - Steps in which the SM-DP+ applies the differential file to the initial profile to generate the profile to be installed. The method according to claim 1, characterized in that it also includes

3. The following steps, namely, - The sending secure element sends the differential file to the target secure element, - If the generated profile matches the initial profile, the target secure element applies the differential file to the initial profile after installation. The method according to claim 1, characterized in that it also includes

4. The method according to claim 3, characterized in that the difference file is transmitted from the source secure element to the target secure element via the SM-DP+.

5. The method according to claim 3, characterized in that the difference file is transmitted from the source secure element to the target secure element by a direct connection between the source device and the target device.

6. The method according to claim 1, characterized in that, if the currently valid profile includes a Java Card application, the differential file incorporates a data packet representing the state of each Java Card application.

7. A method for transmitting a currently valid profile from a source secure element on a source device to a target secure element on a target device, comprising the following steps by the source secure element: - The source secure element monitors and records changes made to the initial profile installed on the source secure element, and obtains the currently valid profile. - The sending secure element generates a difference file relating to the difference between the initial profile and the currently active profile based on the recorded changes, - The step of sending the differential file to the target device or SM-DP+ server, Methods that include...

8. A method for transmitting a currently valid profile from a source secure element on a source device to a target secure element on a target device, wherein the target secure element performs the following steps, namely: - Steps to load the initial profile and install, - A step of receiving a difference file relating to the difference between the initial profile and the currently valid profile, - The steps of applying the differential file to the installed initial profile to obtain the currently valid profile, Methods that include...

9. A source secure element including a processor, wherein the processor performs the following steps to transmit a currently valid profile from the source secure element on the source device to the target secure element on the target device: - A step of monitoring and recording changes made to the initial profile installed in the source secure element, and obtaining the currently valid profile, - The sending secure element generates a difference file relating to the difference between the initial profile and the currently active profile based on the recorded changes, - The step of sending the differential file to the target device or SM-DP+ server, A source secure element configured to perform the following actions.

10. A target secure ensemble including a processor, wherein the processor transmits a currently valid profile from a source secure element on a source device to a target secure ensemble on a target device by following the steps below, namely: - Steps to load the initial profile and install, - A step of receiving a difference file relating to the difference between the initial profile and the currently valid profile, - The steps of applying the differential file to the installed initial profile to obtain the currently valid profile, A targeted secure element configured to perform the following actions.

Images