Method and apparatus for updating secure element operating system

By encapsulating eUICC OS updates within TCA packages and using existing MNO profile distribution mechanisms, the complexity of secure element OS updates is reduced, achieving efficient and standardized updates for secure elements like eUICC.

JP2025096244APending Publication Date: 2025-06-26IDEMIA FRANCE SAS
View PDF 0 Cites -1 Cited by

Patent Information

Application Number
JP2024218605
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-12-15
Filing Date
2024-12-13
Publication Date
2025-06-26

Smart Images

  • Figure 2025096244000001_ABST
    Figure 2025096244000001_ABST
Patent Text Reader

Abstract

To provide a method and apparatus for updating a secure element operating system.SOLUTION: A method of updating a secure element OS, integrated in a device of an original equipment manufacturer (OEM), the secure element being manufactured by a secure element manufacturer (EUM), comprises: generating a secure element OS update; encapsulating the secure element OS update in a file; providing the file to the secure element, the file having a format of a Trusted Connectivity Alliance (TCA) package dedicated for mobile network operator (MNO) profile encapsulation, the file comprising indication indicating that it contains a secure element OS update, the file being provided to the secure element using mechanisms dedicated to MNO profile distribution; and identifying, by the secure element, the received file as a secure element OS update; and executing the secure element OS update.SELECTED DRAWING: Figure 2
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to a method and a device for updating an operating system of a secure element (separate or embedded), such as an eUICC (embedded universal integrated circuit card, also called eSIM (embedded subscriber identity module)), eSE (embedded secure element), ieUICC (integrated eUICC) or iUICC (integrated UICC). Within the scope of the present disclosure, the terms update, upgrade or patch application are equivalent and used interchangeably.

Background Art

[0002] Wireless user terminals, smartphones, connected objects or any computer device having communication capabilities using a communication network (e.g., a mobile (telephone) network, a wireless network, a wireless communication network) conventionally comprise a secure element (removable, embedded, separate or integrated). Such secure elements include universal integrated circuit cards, UICCs, such as subscriber identity modules, SIM cards and their embedded versions known as embedded UICCs or eSIMs (embedded SIMs), and their integrated versions known as iUICCs (integrated UICCs) or ieUICCs (integrated eUICCs). The eUICC module is typically a small hardware secure element that can be embedded or integrated into a communication device such as a smartphone or a TCU (telematics control unit used for connected vehicles) to provide the same functionality as a conventional SIM card. The eUICC is also incorporated into many different communication devices related to the so-called Internet of Things, IoT.

[0003] The eUICC is usually manufactured by the eUICC manufacturer, the EUM, to be provided to the OEM for incorporation into devices manufactured by the counterparty trademark manufacturing company, the OEM. To enable connection to and communication with the mobile network, subscription to a mobile network operator, the MNO, is required. All parameters related to the subscription are stored in the eUICC as the MNO profile. The eUICC may contain several MNO profiles corresponding to different subscriptions to one or several MNOs.

[0004] The eUICC is provided by the eUICC manufacturer to an operating system, the OS, that implements the functionality of the eUICC. These functionalities include the implementation of application protocol data units, APDU commands, defined in the standard ISO / IEC 7814 part4 used to communicate with the eUICC. The operating system of the eUICC should not normally be confused with the operating system that runs the device in which the eUICC is incorporated.

[0005] During the lifespan of an eUICC-equipped device, which can range from several years to a maximum of 10 - 15 years, technology evolves and the functionality of the eUICC may require some updates to continue to execute efficiently within its environment. Current methods for updating the eUICC operating system involve different operations in either the IoT or consumer environment. First, before mass production of the device, the OEM incorporates the EUM-specific software used to update the eUICC operating system. This specific software is usually called the OS update agent and runs on the device within the device operating system environment. This OS update agent is developed by the EUM and is dedicated to updating the eUICC OS provided by this EUM by cooperating with the corresponding update functionality within the eUICC OS.

[0006] The eUICC OS update package is generated by the EUM and provided to the OEM. Next, the OEM requires a firmware over the air (FOTA) platform to provide the update package for download. The target devices that need updates are triggered by the OEM to download the update package from the OEM's FOTA platform. Once downloaded onto the device, the OS update agent on the device processes the update package and collaborates with the eUICC to implement the update.

[0007] This is a complex process that requires very close cooperation and integration between the EUM and the OEM. Furthermore, some OEMs do not have a FOTA platform. Delivering the update package to the devices is an issue because a dedicated transport mechanism needs to be implemented. This process enforces some modem-specific requirements because it requires proprietary non-standard APDUs.

Prior Art Documents

Non-Patent Documents

[0008]

Non-Patent Document 1

Non-Patent Document 2

Summary of the Invention

[0009] The present invention was devised to address one or more of the aforementioned problems.

[0010] According to a first aspect of the present invention, a method for updating an operating system of a secure element incorporated in a device of a partner trademark manufacturing company, an OEM, wherein the secure element is manufactured by a secure element manufacturer, an EUM, the method comprising: - generating a secure element OS update; - encapsulating the secure element OS update in a file; - providing this file to the secure element In a method, - this file has a format of a dedicated Trusted Connectivity Alliance, TCA package for mobile network operator, MNO profile encapsulation, - this file contains an indication indicating that it contains a secure element OS update, - this file is provided to the secure element using a dedicated mechanism for MNO profile distribution, The method further comprises, by the secure element, - identifying the received file as a secure element OS update; - executing the secure element OS update and is characterized in that it further comprises.

[0011] In one embodiment, this file is typically provided for download by the EUM on a dedicated platform for downloading the MNO profile.

[0012] In one embodiment, the EUM generates a group activation code that identifies the platform and the secure element OS update file and transmits it to the OEM.

[0013] In one embodiment, the group activation code is distributed to the device by the OEM to trigger the download of the file.

[0014] In one embodiment, this instruction includes a new ProfileClass value indicating that the profile is a secure element OS update.

[0015] In one embodiment, this instruction includes a new ProfileHeader flag indicating that the profile is a secure element OS update.

[0016] In one embodiment, the method - further includes sending a notification indicating the success of the update from the device to the platform. and further includes.

[0017] In one embodiment, the platform maintains a database of secure elements having the associated secure element OS version.

[0018] In one embodiment, the embedded or separate secure element is one of an embedded universal integrated circuit card, eUICC, embedded subscriber identity module, eSIM, embedded secure element, eSE, integrated eUICC, ieUICC or integrated UICC, iUICC.

[0019] According to another aspect of the present invention, there is provided a program for a programmable device, the program including a series of instructions for implementing the method according to the present invention when loaded onto and executed by the programmable device.

[0020] According to another aspect of the present invention, there is provided a computer-readable storage medium storing computer program instructions for implementing the method according to the present invention.

[0021] At least a part of the method according to the present invention can be computer-implemented. Accordingly, the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining a software aspect and a hardware aspect, all of which may generally be referred to herein as a "circuit", "module", or "system". Further, the present invention can take the form of a computer program product embodied in any tangible medium having computer-usable program code embodied therein.

[0022] Since the present invention can be implemented in software, the present invention can be embodied as computer-readable code for providing to a programmable device on any suitable carrier medium. Tangible non-transitory carrier media can include storage media such as floppy disks, CD-ROMs, hard disk drives, magnetic tape devices, or solid state memory devices, etc. Transitory carrier media can include electrical signals, electronic signals, optical signals, acoustic signals, magnetic signals, or electromagnetic signals, such as signals like microwaves or RF signals.

[0023] Here, embodiments of the present invention will be described by way of example only and with reference to the following drawings.

Brief Description of the Drawings

[0024]

Fig. 1a

Fig. 1b

Fig. 2

Fig. 3

Modes for Carrying Out the Invention

[0025] The main idea of the invention described is to reuse the dedicated mechanism for the installation of the MNO profile to provide an eUICC OS update mechanism. This is usually a dedicated one for encapsulating the MNO profile and means generating an eUICC OS update package in the form of a Trusted Connectivity Alliance (TCA) package, a format standardized by the document (Non-Patent Document 1) (referred to as the TCA standard in the rest of the text). The TCA package is a file compliant with the TCA standard as described above. These packages are usually provided for download using the SM-DP+ platform, which is a dedicated platform for providing the MNO profile for download. The download is enabled by using a group activation code derived from the activation code used to trigger the download of the MNO profile. When downloaded, the eUICC OS recognizes that the package is an OS update package and not a standard MNO profile package and installs this OS update into the eUICC. This process is detailed below.

[0026] Figure 1a shows the general architecture of the aforementioned solution dedicated to consumer products.

[0027] EUM is the manufacturer and provider of the eUICC. Frame 101 shows the EUM domain including the EPS (eSIM Patch Application Server) platform 102. The EPS platform is the platform used to provide the eUICC OS update package for download. The EPS platform is based on the known SM-DP+ platform provided by the EUM to the MNO (Mobile Network Operator) for processing the download of the MNO profile. The main difference is that the EPS remains under the control of the EUM instead of the OEM.

[0028] The EPS platform communicates with the backend platform 104 of the OEM domain 103. The backend platform 104 is used by the OEM to manage a group of devices 106 including an eUICC 108 for communication with a mobile network (not shown). To communicate with the mobile phone network, the devices 106 need to subscribe to a mobile network operator, MNO. All parameters related to the subscription, all parameters required to connect to the mobile network, are stored in the eUICC as an MNO profile. The MNO profile can be replaced or updated on the eUICC 108. The download of the MNO profile is processed by a local profile assistant 107, LPA, which is a software module running within the device 106. The LPA 107 is responsible for downloading the MNO profile provided to the eUICC 108 for installation of the new MNO profile within the eUICC 108. The LPA 107 is also responsible for managing the state of the profile (e.g., activation, deactivation, deletion, etc.). These MNO profiles are provided for download by the LPA 107 on the SM-DP+ platform (not shown) and are managed by the MNO. The actual download of the MNO profile is triggered by an end user (not shown in the attached drawings) who uses the device 106. The end user uses an activation code, AC, and provides it to the device 106, more precisely to the LPA 107, to request the download and installation of the profile. Alternatively, the LPA 107 can retrieve the activation code AC from an SM-DS ("Subscription Management Discovery Service") server. The SM-DS server is responsible for providing the LPA with the address of one or more SM-DP+s. The activation code is delivered to the end user by the MNO and consists of two parts. The first part is the address of the SMDP+ platform in the form of the fully qualified domain name, FQDN, of the SM-DP+ platform.The second part is a unique identifier that refers to the MNO profile downloaded onto the SM-DP+ platform. Since the MNO profile contains parameters related to subscription, it includes device and / or eUICC parameters and / or user personal parameters. Therefore, a unique MNO profile must be generated for each user and can be linked to a specific eUICC embedded within the device.

[0029] In connection with the eUICC OS update described herein, under the OEM's request, the EUM generates an eUICC OS update package dedicated to a given version of the eUICC OS. This package is not specific to a particular eUICC embedded within the device and can thus be downloaded by multiple devices that have the same OS version and include eUICCs. The eUICC OS update package is encapsulated within the TCA package. The format of the TCA package is adapted to include information indicating that the TCA package is actually an eUICC OS update package and not an MNO profile. In one embodiment, the OS update is encapsulated within a non-standard profile element, the PE, within the TCA package. It is proposed to introduce a new type within the metadata defined by the SGP.22 standard in order for the LPA106 to be able to identify the package as an OS update rather than an MNO profile normally. "Metadata" is understood to be data or a data structure that represents and / or describes features, another value, or other values in an abstract form, regardless of its support, implementation, or realization. For example, the types defined by the standard can be (using the ASN.1 ("Abstract Syntax Notation One") notation)

Number

[0030] Here, the new type OS update (3) value has been introduced to indicate that the package contains an eUICC OS update.

[0031] In some embodiments, the metadata related to the profile may include additional data describing the OS update. For example, the serviceProvideName field may identify the EUM providing the OS update. The profileName field may also be used to provide an identifier for the OS update, for example, by including the OSUpdateProfileVersionID value.

[0032] New NotificationEvent values may also be defined to notify of new OS update types of operations or executions. When linked to this new NotificationEvent, new NotificationEventStatus values may be defined, which may be based on standard ones that are actually already defined within, for example, the SGP.22 standard. These new values may be "Executed-Success" and / or "Failed".

[0033] New notificationConfigurationInfo values may also be introduced.

[0034] In one embodiment, the syntax of the metadata is modified as follows, and the modifications introduced in accordance with the present disclosure are shown emphasized.

Number

[0035] Optionally, the profile header defined by the TCA standard may be modified as follows.

Number

[0036] When set to value 1, the osupdateflag signals that the package contains an eUICC OS update. Accordingly, the eUICC searches for non-standard profile elements, PEs, and encapsulates the binary code of the OS update within the package. Accordingly, the list of profile elements recognized within the package is enhanced by the PE35 NonStantard value to identify such non-standard profile elements. For example, it is as shown below.

Number

Number

[0037] When a package containing an OS update is sent by the LPA107 to the eUICC108, this update is applied by the eUICC. Applying the OS update may require the eUICC OS to restart for completion.

[0038] When the update of the eUICC OS is completed, this is notified by the eUICC108 to the LPA107, and the LPA107 itself notifies the EPS102 of the update result (success or failure of the update process).

[0039] Advantageously, the EPS102 maintains the database of all deployed eUICCs having the version of the running OS in an up-to-date state. This database is initially initialized using the initial OS version of the deployed eUICC. Next, receipt of a notification of successful OS update by the EPS platform enables the database to be updated with the current values.

[0040] Figure 1b shows a similar process in relation to an IoT (Internet of Things) environment. In this regard, device 106 is no longer a consumer device but an IoT device. An IoT device is typically a communication device implied by machine-to-machine communication. This process is very similar to that described in relation to Figure 1a, but with the difference that the OEM typically uses an eIM (eSIM IoT Remote Manager) module 105 responsible for the management of the eUICC deployed within the IoT device 106. The eIM is responsible for the remote profile state management operation (PSMO) on a single IoT device or a group of IoT devices. The LPA agent 107 within the consumer device is replaced by an IoT profile agent IPA109 incorporated into the IoT device 106 and having the same dedicated function for the installation of the MNO profile within the eUICC, which is also responsible for the management of the profile state (e.g., activation, deactivation, deletion, etc.).

[0041] The communication between the eIM module 105 and the IPA agent 109 is standardized by a standard document (Non-Patent Document 2). According to the prior art, it is possible for the eIM module 105 to search for an eUICC OS update package and push this to the eUICC. According to some embodiments, in order to receive a group activation code GAC for the download of the eUICC OS update package, the IPA109 sends a standardized GetEimPackageRequest message including at least the identifier of the eUICC (i.e., EID), and it is assumed that an eIM package is requested for this identifier and retrieved by the eIM module 105. In response, the IPA109 receives a GetEimPackageResponse and internally retrieves new non-standard output data from among other current standardized output data, which can be identified according to the following new output data name OSUpdateDownloadTriggerRequest.

[0042] [Table 1]

[0043] (1) Only one of EuiccPackageRequest, IpaEuiccDataRequest, ProfileDownloadTriggerRequest, or OSUpdateDownloadTriggerRequest may exist.

[0044] MOC: Mandatory, Optional, or Conditional

[0045] This new GetEimPackageResponse may also be introduced as follows.

Number

[0046] OSUpdateDownloadTriggerRequest is used by the eIM module 105 to notify the IPA 109 that there is a waiting OSUpdate package waiting for a search on the EPS platform 102. The waiting OSUpdate package may be used instead of profileDownloadTriggerRequest because, for example, some devices may require entering maintenance mode before the eUICC OS update to avoid updates during critical device operation (both serve a similar role).

[0047] The download of the eUICC OS update package can be performed in the same way as either a method for consumer products (Option 1 in Figure 1b: direct profile download between IPA 109 and EPS 102) or a method for network and resource-constrained devices following an indirect profile download (Option 2 in Figure 1b: between IPA 109, eIM 105, and EPS 102).

[0048] New tags may also be introduced to notify the eIM module 105 that an eUICC OS update has been executed. In one embodiment, the tag may take the following form.

Number

[0049] Upon being notified, the eIM may send the corresponding notification to the OEM backend platform 104.

[0050] In both consumer and IoT environments, the EPS platform 102 may advantageously match the received eUICC identifier within the requirements for the package to verify the eligibility of the eUICC for the OS update. This is particularly useful when the EPS platform 102 is used with multiple OEMs to manage its eUICC OS updates.

[0051] Advantageously, the EPS platform 102 generates an update report to the OEM to report the updated eUICC identifier. This enables the OEM to manage its fleet of devices.

[0052] Advantageously, the eUICC stores a record of all updates and an identifier of the current version of its OS. For example, the EUICCInfo2 euiccFirmwareVer field is updated with a value corresponding to the last update installed within the eUICC.

[0053] Figure 2 shows the main steps of a method for updating the eUICC OS of multiple devices in some embodiments of the present invention. Some of the foregoing steps may be optional and thus may not be essential in all embodiments of the present invention.

[0054] Typically, this process is initiated by an OEM that manages a group of devices equipped with an eUICC for communication with a mobile network. Alternatively, this process can be initiated by an EUM to push an eUICC OS update to the eUICC. In the latter case, step 200 is not executed.

[0055] In a first step 200, the OEM sends a request for an eUICC OS update to the EUM. This request typically includes the current version of the eUICC OS that needs to be updated. Optionally, this request may include the eUICC identifiers (eIDs) of all target eUICCs embedded within the OEM device. This enables the EUM to check the eligibility of the eUICCs for the update against its database of all deployed eUICCs related to that OS version.

[0056] In step 201, the EUM generates an eUICC OS update package as described in relation to FIGS. 1a and 1b. Once generated, the eUICC OS update package is made available for download on the EUM's EPS platform. The eUICC OS update package corresponds to a TCA profile package that has been modified to include information indicating that the package actually contains an eUICC OS update rather than a normal MNO profile.

[0057] In process 202, the EUM typically generates a Group Activation Code, GAC, that uses a fully qualified domain name to identify the EPS platform and identify the eUICC OS update package. This group activation code enables the LPA / IPA to generate the correct requests to the EPS platform for the actual download of the package. This GAC is unique and can be used by all devices that include the eUICC that needs to be updated. This is different from the normal activation code used for the download of the normal MNO profile that has to be personalized per device / eUICC. Next, this GAC is sent to the OEM. Advantageously, the GAC enables the reporting of the OS update campaign on all target devices.

[0058] In process 203, the OEM distributes the GAC to all target devices. This distribution can be done directly in relation to the consumer or can be done using the eIM module in relation to IoT. The GAC is received within the device by the LPA / IPA agent that is responsible for the processing of the MNO profile of the eUICC.

[0059] In process 204, the LPA / IPA agent within the device generates a request to download the package. This request is sent to the EPS platform identified within the GAC for the download of the package identified within the GAC. In some embodiments, this request is sent from the IPA agent via the eIM module 105 to the ESM platform. Advantageously, this request includes the eUICC identifier. This enables the EPS platform to check the eligibility of the eUICC for the update against its database of all eUICCs deployed by the EUM along with their current OS version. In response to this request and if the eligibility is checked, the LPA / IPA agent of the device receives the requested eUICC OS update package.

[0060] In step 205, the LPA / IPA agent of the device sends this package to the eUICC. The eUICC OS recognizes this package as an OS update and executes this update. The result of the OS update is notified to the LPA / IPA agent when it is executed.

[0061] In step 206, the notification of the OS update result is returned to the EPS platform directly or via the eIM module 105.

[0062] In step 207, the EPS platform updates its database that stores the deployed eUICC with the new version of the OS of the updated eUICC based on the received notification. Advantageously, the EPS platform generates a report of all updated eUICCs to be sent to the OEM.

[0063] It is possible to use the MNO profile download mechanism for updating the eUICC OS by encapsulating the eUICC OS update within an MNO profile package with information indicating that the content of the package is an OS update rather than an MNO profile. This method is simpler and more effective than the known methods of the prior art. This method reuses the existing and reliable ecosystem without significant impact on the device architecture.

[0064] FIG. 3 is a schematic block diagram of a computing device 300 for the implementation of one or more embodiments of the present invention. The computing device 300 can be a device such as a microcomputer, a workstation, or a lightweight portable device. The computing device 300 includes a communication bus connected to the following: - A central processing unit 301 such as a microprocessor represented as a CPU, - A random access memory 302 represented as a RAM for storing executable code of the method according to an embodiment of the present invention, the memory capacity of which can be expanded, for example, by an optional RAM connected to an expansion port, and registers adapted to record variables and parameters necessary for implementing the method according to an embodiment of the present invention. - A read-only memory 303 represented as a ROM for storing a computer program for implementing an embodiment of the present invention. - A network interface 304 connected to a communication network through which digital data to be processed is normally transmitted or received. The network interface 304 can be a single network interface or can be composed of a combination of different network interfaces (for example, a wired and a wireless interface or different types of wired or wireless interfaces). Data packets are written to the network interface for transmission or read from the network interface for reception under the control of a software application executed within the CPU 301. - A graphic user interface 305 can be used to receive input from a user or display information to the user. - A hard disk 306 represented as an HD can be provided as a mass storage device. - An I / O module 307 can be used to receive data from an external device such as a video source or a video display and / or transmit data to an external device such as a video source or a video display.

[0065] The executable code can be stored in any of the read-only memory 303, on the hard disk 306, or on a removable digital medium such as a disk. According to a variant, the executable code of the program can be received through the network interface 304 by a communication network so as to be stored in one of the storage means of the communication device 300, for example, within the hard disk 306, before being executed.

[0066] The central processing unit 301 is adapted to control and direct the execution of instructions or the execution of a part of a program or software code of a program group according to an embodiment of the present invention, and these instructions are stored in one of the aforementioned storage means. After power-on, the CPU 301 can execute instructions from the main RAM memory 302 related to the software application after its instructions are loaded from, for example, the program ROM 303 or the hard disk (HD) 306. When such a software application is executed by the CPU 301, it causes the steps of the flowchart of the present invention to be performed.

[0067] Any step of the algorithm of the present invention can be implemented in software by the execution of a set of instructions or a program by a programmable computing machine, such as a PC ("personal computer"), a DSP ("digital signal processor") or a microcontroller, or otherwise can be implemented in hardware by a machine or a dedicated component, such as an FPGA ("field programmable gate array") or an ASIC ("application specific integrated circuit").

[0068] Although the present invention has been described above with reference to specific embodiments, the present invention is not limited to these specific embodiments, and modifications falling within the scope of the present invention will be apparent to those skilled in the art.

[0069] Many further modifications and variations will occur to those skilled in the art in view of the foregoing exemplary embodiments, which are given for illustration only and are not intended to limit the scope of the present invention specifically defined by the appended claims. In particular, different features from different embodiments can be exchanged as needed.

[0070] Each of the above-described embodiments of the present invention can be implemented alone or in combination with a plurality of embodiments. Also, features from different embodiments can be combined as needed or when a combination of elements or features from individual embodiments within a single embodiment is beneficial.

[0071] In the claims, the term "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality of elements. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be used advantageously.

Explanation of Reference Signs

[0072] 101 EUM domain 102 EPS platform 103 OEM domain 104 Back-end platform 105 eIM module 106 Device 107 LPA 108 eUICC 109 IPA Steps 200 to 207 301 CPU 302 RAM 303 ROM 304 Network interface 305 GUI 306 HD 307 IO module

Claims

1. 1. A method for updating a secure element operating system, OS, embedded in an original equipment manufacturer, OEM, device, the secure element being manufactured by a secure element manufacturer, EUM, the method comprising: - generating a secure element OS update; - encapsulating said secure element OS update in a file; providing said file to said secure element; A method comprising: - the file has the format of a dedicated Trusted Connectivity Alliance, TCA package for Mobile Operator, MNO profile encapsulation; - the file includes an indication that it contains a secure element OS update; - said file is provided to said secure element using a dedicated mechanism of MNO profile distribution; The method further comprises the steps of: - identifying the received file as a secure element OS update; - executing said secure element OS update; and further comprising:

2. The method of claim 1 , wherein the file is typically provided for download by the EUM on a platform dedicated to downloading MNO profiles.

3. The method of claim 2 , wherein the EUM generates a group activation code that identifies the platform and the secure element OS update file and sends it to the OEM.

4. The method of claim 3 , wherein the group activation code is distributed to the device by the OEM to trigger the download of the file.

5. The method of claim 1 , wherein the indication includes a new ProfileClass value that indicates that the profile is a secure element OS update.

6. The method of claim 1 , wherein the indication includes a new ProfileHeader flag indicating that the profile is a secure element OS update.

7. - sending a notification from said device to said platform indicating the success of said update; The method of claim 2 further comprising:

8. The method of claim 7 , wherein the platform maintains a database of secure elements with associated secure element OS versions.

9. 2. The method of claim 1, wherein the embedded or separate secure element is one of an embedded universal integrated circuit card, eUICC, embedded subscriber identity module, eSIM, embedded secure element, eSE, integrated eUICC, ieUICC or integrated UICC, iUICC.

10. A program for a programmable device, comprising a series of instructions for carrying out a method according to any one of claims 1 to 9, when loaded into and executed by said programmable device.

11. A computer readable storage medium storing computer program instructions for carrying out the method according to any one of claims 1 to 9.