Methods and devices for profile management in eSIM

Abstract

This invention provides a method and device for profile management in eSIMs (embedded SIMs). [Solution] In a system architecture for profile management, an embedded universal integrated circuit card (eUICC 150) has a unique issuer security domain root (ISD-R 160) that receives profile management commands for both types of profiles through a first logical secure interface (45) dedicated to user API control profiles for providing a first management command dedicated to user API control profiles to the ISD-R below, or a second logical secure interface (46) dedicated to CMP control profiles for providing a second management command dedicated to CMP control profiles to the ISD-R.

Description

[Technical Field]

[0001] This invention relates to the management of different types of profiles in an eSIM (embedded SIM). More specifically, the different types of profiles include profiles controlled by a central management point (CMP) and user profiles controlled by a user application programming interface (API).

[0002] The present invention is specifically applicable to the field of mobile network devices (such as mobile phones, tablets, portable computers, security controllers, medical devices, and automobiles), and in particular to the provisioning of profiles, i.e., loading, storing, and installing profiles onto embedded universal integrated circuit cards (eUICCs), and to the editing of such installed profiles, such as enabling, disabling, deleting, updating, auditing, and renaming. [Background technology]

[0003] A mobile network operator ("MNO") is a company that provides subscribers with access to a mobile phone network. MNOs are also known as mobile phone operators, wireless service providers, mobile phone companies, and other combinations of these terms, and they provide mobile phone services in a specific geographical area, which may overlap with the specific geographical areas of other MNOs.

[0004] Each MNO has its own network, but network classifications are standardized by third-party organizations (typically 3GPP) so that people and devices can understand the types of services they can expect from the MNO. For example, 5G is the fifth generation of mobile phone networks, and for an MNO to sell 5G services, it must have all the underlying infrastructure that makes the network "5G".

[0005] Previously, consumers and Internet of Things (IoT) manufacturers contracted with a single mobile network operator (MNO), and when mobile devices were used outside the MNO's home network, the carrier typically connected those devices to a partner MNO covering that area, charging a "roaming" fee. Therefore, working directly with MNOs could make the deployment of IoT devices more complex and expensive for IoT manufacturers.

[0006] One reason why cellular connectivity is so attractive to IoT manufacturers is its superior coverage and mobility. However, IoT applications sometimes require devices to operate beyond network boundaries. IoT manufacturers want to deploy not only where their partner MNOs provide coverage, but wherever there is market potential. This can mean agreeing to multiple contracts, creating multiple SKUs (stock keeping units) for a single IoT device, and potentially having to pay extra charges when customers roam outside of their partner MNO's home network.

[0007] Mobile network operators (MNOs) built the network infrastructure for mobile phones. While IoT devices may use many of the same services, most IoT applications use cellular connectivity in ways that are significantly different from how consumers use their mobile phones.

[0008] Modern IoT manufacturers often desire global expansion. While traditional cellular connectivity allows these devices to connect to networks in multiple countries, every mobile network operator (MNO) has a limited list of partner carriers, and these devices cannot connect to networks not on that list. To connect to a wider range of cellular networks, IoT manufacturers require specialized components in their subscriber identification modules (SIMs).

[0009] First-generation SIM (Subscriber Identification Module) cards contained a Universal Integrated Circuit (UICC) that stored a single profile locked to a specific carrier. Once activated, this SIM card would only function on that carrier's "home" network and its partner networks.

[0010] Embedded UICC (e-UICC) allows multiple subscriber profiles to be stored on a SIM card, enabling carriers to provision SIMs over-the-air (OTA) and connect devices to the listed networks. However, eUICC still only loads one profile, and integrating a new MNO profile into the eUICC can cost tens of thousands of dollars. Therefore, eUICC is more effective as a safety net in case a carrier goes bankrupt or when a carrier wants to deploy to a country that requires a local carrier.

[0011] eSIM (embedded SIM) is an embedded alternative to traditional physical SIM cards, offering the same ease of use, privacy, and security while minimizing some of the drawbacks of traditional SIM cards.

[0012] The fifth-generation cellular network ("5G") broadcast standard aims to address several existing shortcomings and facilitate the operation and overall support of user equipment (UE). It is designed to support a range of new requirements, including increased data rates for high-speed travel, support for low data rates, low-power devices, and robust and strong network security.

[0013] Specifically, in the field of the Internet of Things (IoT), use cases are included that are tailored to IoT connections with requirements that differ from typical end-user connections. In addition, the aim is to eliminate the need for subscriber identification module (SIM) cards by using the concepts of virtual embedded SIMs (eSIMs) and "profiles." Unlike traditional SIM cards, which are removable and replaceable in new devices, eSIMs are permanently embedded in the device. Because eSIMs are smaller than standard nano-SIMs, they can be fitted into small devices, which is another advantage for IoT devices. eSIMs are SIMs that are soldered directly to the device, allowing for the separation of carrier profiles from the physical chipset. In the future, they tend to become even more integrated with devices, either as part of the system-on-a-chip (SOC) silicon or as a function within an enclave.

[0014] The evolution from physical SIMs to eSIMs is represented by the separation of the physical integrated circuit from the carrier profile that stores the configuration and keys. Devices can be manufactured with an eSIM that does not have a carrier profile, or they can be manufactured to have an initial profile that can be changed at a later stage. Unlike traditional SIMs, new mobile network operator (MNO) or mobile virtual network operator (MVNO) profiles can be downloaded from the internet depending on certain conditions (e.g., the user's location). Most importantly, this process can be developed remotely without requiring physical interaction with the user, which is essential for IoT deployments. To achieve this, the provisioning and download processes are standardized in a way that ensures integrity, security, and interoperability.

[0015] There are several possible methods to achieve this. For these simple reasons, eSIMs are considerably more flexible than physical SIMs and allow for rapid provisioning and reprovisioning, even in devices installed in the field. Devices may have a default profile and can download a new profile through a process called remote SIM provisioning (RSP), which contains the same data that would normally be stored on a regular SIM card.

[0016] With eSIMs, users still need a contract with a carrier, but instead of receiving a physical card, they receive an activation code. Using this code, users can download a profile ready for installation on their device, and the device can then connect to the network. This greatly increases flexibility, as carriers can provision cards instantly on demand without needing physical collateral. From an IoT deployment perspective, eSIM solutions are being proposed in the IoT field to facilitate secure machine-to-machine (M2M) communication between devices.

[0017] Within the 5G domain, the eSIM Authentication and Authorization Controller (AAC) mechanism is based on the Authentication and Key Exchange (AKA) protocol, which aims to achieve mutual authentication between the UE (User Equipment) and the carrier and establish keys to protect subsequent communications.

[0018] In the automotive sector, the number of connected and autonomous vehicles is increasing, and the vehicle-to-device (V2X) communication ecosystem is also expanding. As a result, the automotive vertical market is growing. Vehicles can exchange information of varying importance with roadside infrastructure or servers located anywhere on the internet.

[0019] Use cases for connected cars include mobility management, vehicle management, safety, entertainment, driver assistance, and driver well-being. To keep users up-to-date on environmental conditions, a system is needed that notifies users of real-time traffic information, fuel consumption data, and external hazard warnings (including the ability to make emergency calls (eCall) in the event of an accident). Furthermore, in most scenarios, some degree of driver assistance is necessary, such as autonomous driving, parking assistance, and well-being features like fatigue detection.

[0020] eSIMs can ensure the flexibility of carriers to enable authentication processes, secure identification, and resilient operations. eSIMs also offer eCall functionality, allowing vehicles to automatically contact the nearest emergency center in the event of an accident. eSIMs bring significant value across the entire automotive value chain, from manufacturers and service providers to fleet administrators and end-users, allowing everyone to benefit from more seamless operations and a deeper relationship with their vehicles and brand.

[0021] Flexible connectivity is essential for this type of system to function properly, but for autonomous vehicles, highly reliable network connectivity is a critical factor in success. In this respect, operational flexibility and slicing support are significant advantages. Furthermore, brands can customize the AAC process and enhance security.

[0022] In automotive scenarios, privacy issues must also be considered. Connected cars collect and communicate vast amounts of data, particularly regarding the user's location and behavior. Data stored in vehicles and exchanged over networks must be kept secure. It is necessary to clarify who can access the data, when, and to what extent. Transparent control flows are needed to ensure that data owners always know how their data is being processed, who is accessing it, and who can view it.

[0023] Finally, during the vehicle's usage period, if a better connectivity contract is negotiated or the vehicle is resold in the aftermarket, it is necessary to perform some changes to the MNO profile and updates and upgrades to software, firmware, and applications. Again, in this case, the eSIM provides a framework for all these operations during the vehicle's usage period, enabling it to adapt to market trends and the services offered by communication operators without requiring vehicle downtime, which is a burden for customers and an additional cost for vehicle manufacturers.

[0024] Some automotive OEMs (abbreviation for "Original Equipment Manufacturer of Other Brands") aimed to let end-users add the vehicle to an MNO contract. This was achieved by two separate cellular modems (or expensive DSDA or Dual SIM Dual Active modems), and two separate eSIMs, where eSIM M2M was used for telematics and eSIM consumer was used for installing the end-user's profile.

[0025] In the latest consumer eSIM specification phase 3 (see clause 2.12), a method for activating multiple profiles simultaneously is defined, which is interesting considering the above-mentioned automotive OEM use case. MEP (abbreviation for "Multiple Enabled Profiles") compliant devices are devices that can use multiple enabled profiles in parallel on the same eUICC. However, since consumer eSIMs cannot be remotely managed, end-users have full control over the eSIM, and OEMs cannot trigger OTA downloads of profiles.

[0026] However, even eSIM IoT (recently released) only intends for remote management of profiles. There is no solution that mixes the two use cases where OEMs manage the profiles on the eSIM and at the same time let end-users install their own profiles. Summary of the Invention

[0027] The present invention aims to improve upon all or some of the shortcomings of the prior art.

[0028] According to a first aspect, the present invention relates to a device for profile management in an eUICC-enabled SIM (eSIM) card, which has the capability to perform over-the-air (OTA) provisioning of multiple network operator profiles from a central management point (CMP), including an eSIM remote manager (eIM) and / or subscription manager data preparation extension (SM-DP+), and is configured to use multiple active profiles (MEPs) simultaneously.

[0029] The eUICC is configured to manage two types of profiles: OEM or IoT profiles controlled by CMP, and user API controlled profiles controlled by the user through the local user API. The eSIM card stores these profiles in profile memory, and the properties and / or location of the profiles in profile memory represent the profile type.

[0030] eUICC is - A first logical secure interface (LSI) dedicated to a user API control profile, configured to identify a user API control profile based on the properties and / or location of the user API control profile in profile memory, in order to provide a first management command dedicated to the user API control profile to the ISD-R, or - A second logical secure interface (LSI) dedicated to CMP control profiles, configured to identify a CMP control profile based on the properties and / or location of the CMP control profile in profile memory, in order to provide a second management command dedicated to the CMP control profile to the ISD-R. It has a unique ISD-R (Issuer Security Domain Root) configured to receive profile management commands for both types of profiles.

[0031] ISD-R is configured to execute a first management command only for the user API control profile and a second management command different from the first management command only for the CMP control profile.

[0032] The present invention allows OEMs to manage their CMP control profiles and enable end users to install their own user API control profiles using the same eSIM. These profiles are managed by two separate entities: CMP control profiles are managed via a remote server, and user API control profiles are managed via a local interface. Furthermore, different types of profiles are identified differently within the eSIM profile memory by the properties of their profiles and / or by the location of their profiles within the profile memory. End users cannot edit CMP control profiles, and CMP cannot edit user API control profiles. The proposed eSIM with embedded user API control profile provisioning allows OEMs to address both telematics and in-vehicle infotainment use cases in the automotive industry. By having only one eSIM, OEMs can save on hardware (HW) costs and minimize the printed circuit board (PCB) footprint. Profile properties are, for example, profile attributes that identify the type of profile. The location of a profile is, for example, associated with one of two databases, each dedicated to a specific profile type or partition of profile memory.

[0033] In certain embodiments, the ISD-R is further configured to execute a third management command in both the user API control profile and the CMP control profile, which is different from both the first and second management commands.

[0034] In certain embodiments, the third command includes a specific indicator not included in either the first or second management command, and the third command is sent to the ISD-R by the eSIM remote manager (eIM).

[0035] In certain embodiments, the device according to the present invention further includes a security mechanism configured to protect a third management command. This security mechanism may use a personal identification number (PIN), encryption, or authentication means.

[0036] In certain embodiments, the eUICC further includes an Internet of Things (IoT) Profile Assistant (IPA) configured to identify a first management command from a local API and a second management command from a central management point.

[0037] In certain embodiments, the IPA is embedded in a card (IPAe) and configured to identify a first or second management command based on a different transport channel associated with a local API or a central management point.

[0038] Commands sent to IPAe can be received via two different transport channels: local ISO commands for consumers and radio for OEMs. eUICC operating system OS eUICC The IPAe on this transport channel can be visualized through context variables. Therefore, the IPAe can execute these commands according to these context variables. In the case of profile loading, regardless of the origin of the initial command, the loading is performed via the Subscription Manager Data Preparation Enhanced (SM-DP+). Therefore, in order to assign the correct properties (CMP control type or user API control type) to the downloaded profile, the eUICC operating system OS eUICC It stores initial context variables (e.g., via ISD-R) and assigns properties to the downloaded profile accordingly.

[0039] In certain embodiments, the IPA is implemented in the device (IPAd) and configured to identify a first or second management command based on a different transport channel associated with a local interface or a central management point.

[0040] Similarly, IPAd receives commands locally or wirelessly. Depending on the command transmission channel, IPAd communicates with the ISD-R on the LSI for user API control profile provisioning or the ISD-R on the LSI for CMP control profile provisioning. For IPAe, the context for profile download is the eUICC operating system OS. eUICC It is stored by (for example, via ISD-R).

[0041] In certain embodiments, eUICC is configured to allow users to edit user API control profiles through a user API.

[0042] In certain embodiments, the IPA is configured to notify the CMP of at least one of the following editing actions performed on the user API control profile: enable, disable, delete, or update.

[0043] In certain embodiments, at least one editing operation is performed on the user API control profile after the IPA receives a message from CMP.

[0044] In certain embodiments, the above message follows a request sent by IPA to CMP asking whether to perform an administrative action on the above user API control profile.

[0045] In certain embodiments, eUICC is configured to use an embedded ES9+ interface to provide secure transport for the delivery of bound profile packages between the Subscription Manager Data Preparation Enhancement (SM-DP+) and the IPA. This ES9+ interface is defined in the SGP.21 architecture specification.

[0046] In certain embodiments, eUICC includes an embedded user API configured to provide users with an activation code associated with a private subscription.

[0047] In certain embodiments, the eUICC is provided with endpoint functionality that includes Constrained Application Protocol (Coap) support for the eIM-IPA (ESipa) interface, or Hypertext Transfer Protocol Secure (HTTPS) support for eIM-IPA communication.

[0048] In certain embodiments, the profile memory is divided into two databases: a first database for CMP control profiles and a second database for user API control profiles.

[0049] In certain embodiments, the profile memory is configured to store, along with each profile, an attribute indicating whether the profile is a user API control profile or a CMP control profile.

[0050] According to a second aspect, the present invention provides a method for profile management in an eUICC-enabled SIM (eSIM) card, which has the capability to perform over-the-air (OTA) provisioning of multiple network operator profiles from a central management point (CMP) including an eSIM remote manager (eIM) and / or subscription manager data preparation extension (SM-DP+), and is configured to use multiple valid profiles (MEPs) simultaneously. - The step of eUICC managing the CMP control profile provisioned by the central management point, - The eUICC manages user API control profiles controlled by the user through the local user API. This is a method that includes, The eSIM card stores the above profile in profile memory, and the properties and / or location of the profile in profile memory represent the profile type. eUICC - A first logical secure interface (LSI) dedicated to a user API control profile, configured to identify a user API control profile based on the properties and / or location of the user API control profile in profile memory, in order to provide a first management command dedicated to the user API control profile to the ISD-R, or - A second logical secure interface (LSI) dedicated to CMP control profiles, configured to identify a CMP control profile based on the properties and / or location of the CMP control profile in profile memory, in order to provide a second management command dedicated to the CMP control profile to the ISD-R. It has a unique ISD-R that receives profile management commands for both types of profiles, This describes a method in which ISD-R executes a first management command only for the user API control profile and a second management command different from the first management command only for the CMP control profile.

[0051] This method has similar advantages and specific features to the device according to the first aspect of the present invention, and therefore will not be repeated here.

[0052] In certain embodiments, the ISD-R further executes a third management command in both the user API control profile and the CMP control profile, which is different from both the first and second management commands.

[0053] In certain embodiments, the eSIM remote manager (eIM) sends a third command to the ISD-R, the third command including a specific indicator not included in either the first or second management command.

[0054] Further advantages, objectives, and specific features of the present invention will become apparent from the following non-limiting description relating to at least one specific embodiment of the methods and devices to which the present invention is covered, with reference to the accompanying drawings. [Brief explanation of the drawing]

[0055] [Figure 1] A schematic representation of a first system architecture for profile management in devices including eUICC is provided. [Figure 2] A schematic representation of the second system architecture for profile management is provided below. [Figure 3] A schematic representation of a third system architecture for profile management is provided below. [Figure 4] The first set of steps performed by the components shown in Figures 1 to 3 is illustrated. [Figure 5] Figures 1 to 3 show a second set of steps performed by the components. [Figure 6] The third set of steps is performed by the components shown in Figures 1 to 3. [Figure 7] The fourth set of steps is performed by the components shown in Figures 1 to 3. [Figure 8] The fifth set of steps is performed by the components shown in Figures 1 to 3. [Modes for carrying out the invention]

[0056] This description is provided as a non-limiting example, and each feature of one embodiment can be advantageously combined with any other feature of any other embodiment. First, please note that the figures are not to scale.

[0057] As can be understood from this description, various inventive concepts can be implemented by one or more methods or devices as described below, some examples of which are provided herein. The operations or steps performed when performing a method or device can be ordered in any suitable manner. Thus, even if they are shown as operations performed sequentially in the embodiments shown, embodiments can be constructed in which the operations or steps are performed in a different order than those shown, including performing certain operations simultaneously.

[0058] Where used herein and in the claims, the expression “and / or” should be understood to mean “either or both” of the elements thus linked, i.e., elements that exist together in some cases and separately in others. Multiple elements listed in “and / or” should be interpreted in the same way, i.e., “one or more” of the elements thus linked. Elements other than those specifically identified in the “and / or” clause may also exist, whether or not they are related to the specifically identified element. Thus, as a non-restrictive example, a reference to “A and / or B” when used in conjunction with an unrestrictive expression such as “including” may, in one embodiment, refer to A only (which may include elements other than B), in another embodiment, refer to B only (which may include elements other than A), and in yet another embodiment, refer to both A and B (which may include other elements).

[0059] As used in this description and in the claims, the expression “at least one” with respect to a list of one or more elements should be understood to mean at least one element selected from one or more elements in the list of elements, and not necessarily to mean at least one of each element specifically enumerated in the list of elements, nor to exclude any combination of elements in the list of elements. Similarly, in this definition, elements other than those specifically identified in the list of elements to which the expression “at least one” refers may also be present, whether or not they are related to the specifically identified elements. Therefore, as a non-restrictive example, “at least one of A and B” (or equivalently “at least one of A or B,” equivalently “at least one of A and / or B”) could mean, in one embodiment, at least one A (which may include multiple A's) in which B is absent (and which may include elements other than B); in another embodiment, at least one B (which may include multiple B's) in which A is absent (and which may include elements other than A); and in yet another embodiment, at least one A (which may include multiple A's) and at least one B (which may include multiple B's) (and which may include other elements).

[0060] In the claims and the following description, all transitional expressions such as “comprising, including,” “having,” “possessing,” “containing,” “accompanying,” “holding,” “composed of,” and similar expressions should be understood as unrestrictive, meaning they include but are not limited to these. Only the transitional expressions “consisting of” and “essentially becoming from” should be understood as restrictive and partially restrictive, respectively.

[0061] In this explanation, the term "server" is often omitted for clarity. For example, "MNO" refers to both the MNO itself and the MNO server. This is also true for terms such as "SM-DP+", "SM-SR", and "eIM".

[0062] The present invention relates to the management of secure chips such as eUICCs, and more particularly to the management of subscriber profiles in such eUICCs. In this specification, profile management includes, as is known to those skilled in the art, provisioning of profiles, i.e., loading and storing profiles in eUICCs, and profile editing, including enabling, disabling, deleting, updating, renaming, auditing, and other operations performed on the profiles after installation.

[0063] A secure element, known as an SE, is a tamper-resistant hardware component or platform (typically a chip) used in a host terminal that can securely host applications and data in accordance with security rules and requirements set by a trusted authority.

[0064] Of the three form factors of an operating system, UICC defines a physical chip containing applications that grant users authentication to access services (voice, data, etc.) on a mobile network. For this purpose, UICC includes applications such as a General Purpose Subscriber Identification Module (USIM) application that holds subscriber identification information and enables authentication on the mobile network.

[0065] eUICC is a UICC chip embedded in or soldered to a host terminal (or "device"). Mechanisms are envisioned for securely managing different subscriptions within the same eUICC, as specified in the SGP.02 specification for M2M mode, SGP.22 for consumer mode, and SGP.32 for the IoT (Internet of Things) eSIM IoT Technical Specification - Version 1.0 (May 26, 2023).

[0066] Figure 1 schematically shows a first system structure for profile management according to the present invention in eUICC 150 integrated with a user host terminal 130, derived from SGP.22 (consumer mode). For example, a mobile network 112 corresponding to a mobile network operator (MNO) is shown. In known methods, several mobile networks corresponding to several carriers can coexist. Therefore, several profiles can be loaded onto the user terminal 130. It should also be noted that the present invention is applicable to other mobile network architectures.

[0067] The mobile network 112 includes a secure routing unit SM-SR 113 of the subscription management server SM (not shown for readability), a data preparation unit SM-DP 111 of the same subscription management server SM, and a server 115 specific to the MNO that manages this mobile network. The well-known main functions of these units / servers are described below. The SM-SR and SM-DP+ servers 113 and 111 are located at the central management point (CMP). Although the SM-SR and SM-DP+ servers 113 and 111 are shown separately, they are preferably implemented within the same SM-DP+ server 120.

[0068] The SM-DP+ server 120, in a simplified form, includes a profile package binding function 121 and a profile package distribution function 122. If the SM-DP server 111 is accompanied by a different SM-SR server 113, the profile package distribution function 122 is performed by the SM-SR server 113.

[0069] For example, a user terminal 130 such as an IoT device, mobile phone, smartphone, computer, tablet, or automotive device includes an eUICC card 150 for securely accessing services on a mobile network 112.

[0070] Figure 1 shows only the user terminal 130 equipped with the eUICC card 150. Naturally, a mobile network generally includes multiple such mobile terminals equipped with eUICC (or SIM, UICC) cards. This description focuses on the eUICC card as an example. Generally speaking, the present invention can be implemented in any type of secure element (SE) that includes multiple subscriber profiles, such as an embedded secure element or "eSE".

[0071] The user terminal 130 is capable of controlling a communication interface (not shown) with the mobile network 112, and includes not only an operating system OS 141 capable of interfacing this communication interface with the eUICC 150, but also a user interface (e.g., a short-range communication device using the WiFi or Bluetooth protocol, a keyboard, a screen) 135 for enabling the user to interact with the user terminal (especially in consumer mode).

[0072] In embodiments relating to consumer mode, the OS 141 includes a Local Profile Assistant (LPA) that provides profile management services. For example, these services (not shown) may include a Local Discovery Service (LDS) for checking profiles present in the eUICC 150 and their enabled or disabled status, a Local Profile Download (LPD) service for performing sequential profile editing operations, and a Local User Interface (LUI) service for retrieving / acquiring profile editing operations initiated locally by the user through a user API.

[0073] In the embodiment shown in Figure 1, the Local Profile Assistant (LPA) is an IoT Profile Assistant (IPA). This is an IoT Profile Assistant (IPAd) 140 located in an IoT device, or an eUICC operating system (OS eUICC)171 includes one of the IoT Profile Assistant (IPAe) 170 located in the eUICC.

[0074] In the preferred embodiment shown in Figure 3, the embedded ES9+ function 39 allows both CMP control (e.g., IoT or OEM) profile type and user API control type profiles to be downloaded from the SM-DP+ 120, eliminating the need to implement LPAd or IPAd at the device 130 level.

[0075] The eUICC board 150 is coupled to the non-volatile memory MEM 175 (stored in non-volatile memory such as read-only memory or flash memory) eUICC operating system OS eUICC This includes 171. The eUICC operating system 171 implements the functions of the telecom framework (not shown), as well as functions for profile management (typically a profile package interpreter and a profile policy enabler). Other classic components present in the eUICC card, such as the interface (and associated controllers) for communication with the host terminal, RAM (random access memory), data bus, and processor, are not shown here for clarity.

[0076] In accordance with the standards mentioned above, the eUICC 150 card has several security domains within its non-volatile memory (MEM) 175 for managing the eUICC 150 card, as well as for managing the subscriber's CMP control profile and user API control profile, where each security domain is identified by a unique AID (Application Identifier), i.e., An embedded UICC Controlling Authority security domain ("ECASD", not shown) is responsible for the secure storage of authentication information required by the eUICC security domain, During the manufacturing of the eUICC, the issuer security domain-root ("ISD-R") 160 is defined as representing the cardholder and is therefore accessible only to the cardholder (via a specific set of cryptographic keys), and in consumer mode, the issuer security domain-root ("ISD-R") 160 includes an LPA service that can establish interaction with the IPAd 140 or IPAe 170 assistant, One or more issuer security domain-profile (ISD-P) domains 165, each dedicated to an MNO, associated with a service subscription with the corresponding MNO telecommunications carrier, and enabling access to that service, and one of the ISD-P 165s may contain a default initial profile (known as a "provisioning profile") that enables network connectivity with the SM-SR 113 unit, One or more issuer security domains-profile (ISD-P) domains 125 and dedicated to the user. Includes.

[0077] Each ISD-P domain 125 or 165 is a secure container designed to store a single subscriber profile in a safe manner (specifically protected by a set of cryptographic keys). The subscriber profile is identified by a unique ICCID (Integrated Circuit Card Identifier).

[0078] ISD-P 125 or 165 includes routines used to download and install profiles in conjunction with a profile package interpreter for decrypting and interpreting profile packages intended for installation received over a secure channel (e.g., according to SCP03t). Specifically, the profile packages conform to the "eUICC Profile Package: Interoperable Format Technical Specification" version 3.2, also known as the "TCA Specification" (an abbreviation for Trusted Connectivity Alliance).

[0079] In known terms, a communication profile includes subscription data such as an IMSI (International Mobile Subscriber Identification Number) identifier, cryptographic keys, authentication algorithms, and NAA (Network Access Application), and may also include a file system, application / applets, and / or default execution rules.

[0080] According to the standards mentioned above, the profile is: MNO-SD (Carrier Security Domain), which includes the carrier OTA key to enable the establishment of a secure OTA channel. Supplemental security domains (SSD) and security domains CASD, Applications / Applets (Apps) At least one Network Access Application (NAA), File system, Profile metadata including connection parameters ("Connec Param") and profile policy rules (e.g., "POL1") It consists of profile components, including the following.

[0081] This metadata may include an ICCID (Integrated Circuit Card Identifier) ​​that uniquely identifies the profile.

[0082] Although Figure 1 shows a single ISD-P 125 and a single ISD-P 165, an eUICC 150 card may contain multiple ISD-P security domains and thus multiple profiles, each of which may be enabled or disabled. Each profile or corresponding ISD-P is identified by its ICCID.

[0083] The root security domain ISD-R 160 is privileged in that it can create or delete ISD-P security domains in the non-volatile memory MEM 175, and can enable or disable profiles stored in ISD-P 165 of eUICC 150.

[0084] The embedded user API 114 is used by device 130 to provide the end user with a profile activation code associated with a private subscription. The user API 114 also allows the end user to control the provisioning and / or editing of user API control profiles, as shown in Figure 3.

[0085] As can be seen from the specifications mentioned above, the management of the CMP control profile is achieved by the exchange of messages (commands, responses) between the SM-SR 113 (or SM-DP+ 120) and the ISD-R 160 root domain. Different management functions and commands of the eUICC 150 are defined in the following documents, SGP.02 for M2M mode and SGP.22 for consumer mode. Communication between the SM-SR 113 (or SM-DP+ 120) and the ISD-R 160 can be performed using the http protocol (Hypertext Transfer Protocol, with https (a secure version of http) used if secure), and can be provided and / or protected by, for example, SCP80 (Secure Channel Protocol 80), SCP81 (Secure Channel Protocol 81), or the CAT-TP protocol (Card Application Toolkit Transport Protocol).

[0086] Secure loading, storage, updating, or deletion of profiles in an ISD-P 165 secure domain is achieved after the exchange of messages (commands, responses) between the SM-DP+ 120 and the respective ISD-P 125 or 165 secure domains in the eUICC 150. Specifically, the SM-DP+ 120 prepares the profile packages to be loaded into the eUICC 150 and then transmits them to the relevant ISD-P domains 125 or 165 via the SM-SR 113 and ISD-R 160. APDU messages can be used. Communication between SM-DP+ 120 and ISD-P 125 or 165 via SM-SR 113 can be conducted via the http (or https) protocol and can be protected by the SCP02, SCP03, or SCP03t protocols, which themselves are tunneled or encapsulated in the link from SM-SR 113 to ISD-R 160, which is protected by the SCP80, SCP81, or CAT-TP protocols.

[0087] In the following description, the term "provisioning a profile" means loading, storing, and finally installing a profile that can be enabled into memory. The term "editing a profile" means performing enable, disable, delete, update, rename, audit, and other administrative operations on a profile after its installation, as is known to those skilled in the art.

[0088] The following relates to the application of the present invention to loading, storing, and finally installing (i.e., provisioning) profiles into eUICC 150.

[0089] As shown in Figure 2, the system architecture can also be considered as an eIM (eSIM IoT Remote Manager) server 11 and an SM-DP+ server 120 communicating with a device 130 containing an eUICC 150. The central management point (CMP) includes the eIM server 11. Either the device implements an IPAd 140 outside the eUICC 150, or the eUICC 150 implements an IPAe 170. The eUICC 150 implements an ISD-R (Issuer Security Domain - Root) 160 and includes a profile database 17. The profile database 17 is divided into a database 20 that stores CMP control profiles 18 and a database 21 that stores user API control profiles 19. The eIM server 11 communicates with either the IPAd 140 (when the IoT Profile Assistant is located within the device) or the IPAe 170 (when the IoT Profile Assistant is located within the eUICC). Similarly, the SM-DP+ server 120 communicates with either the IPAd 140 or the IPAe 170.

[0090] In a particular embodiment of the present invention relating to an automotive device, the eUICC 150 can be configured to provide secure transport for the delivery of bound profile packages between the SM-DP+ 120 and the IPAe 170 using an embedded ES9+ interface 39. This ES9+ interface is defined in the SGP.21 architecture specification. As shown in Figure 3, the embedded ES9+ function 39 allows for the download of both CMP control type and user API control type profiles from the SM-DP+ 120. Furthermore, the embedded ES9+ function 39 eliminates the need to implement LPAd or IPAd at the device 130 level.

[0091] As shown in Figure 3, on the OEM side, the eIM 11 communicates with the eIM endpoint 37 through the LSI1 46 of the modem 145 and the MEP (Multiple Valid Profiles) function 36 for eUICC as defined in the "Consumer eSIM Specification Phase 3". For example, the modem 145 operates according to 3GPP Release 17. The end user 30 communicates with the user API 114 through the in-vehicle user interface 31, the LSI0 45 of the modem 145, and the MEP function 36. ISD-P 41~44 are similar to ISD-P 125 and 165. In this embodiment, as shown in Figure 3, the eUICC 150 is provided with an endpoint function 37 that has Constrained Application Protocol (Coap) support for the eIM-IPA (ESipa) interface or Hypertext Transfer Protocol Secure (HTTPS) support for eIM-IPA communication. Endpoint function 37 enables an entry interface to eUICC and allows communication between eIM and IPA based on a dedicated communication protocol such as Coap or HTTPS. Issuer security domain-root ("ISD-R") 160 is defined as representing the cardholder, as already stated in the main text.

[0092] Figure 4 schematically illustrates the typical data flow and steps performed by the system components to update or read database 21, which stores user API control profiles, and database 20, which stores CMP control profiles. These components are modem 145, LSI0 45, LSI1 46, and ISD-R 160. LSI is an abbreviation for logical SE interface. These communication channels are supported by both eUICC 150 and modem 145. An LSI can be thought of as a logical channel on a physical interface, enabling data transfer and communication between two entities connected by a physical interface (e.g., between a modem and an eUICC (e.g., ISD_R)). Note that the term LSI is used in ETSI102221, while the GSMA specification uses the term eSIM port for the same purpose. LSIs are assigned when a profile is enabled. Profiles are assigned to LSIs, and LSIs are assigned to profiles. When a profile is disabled, the assignment is released. LSI assignment is, - Mode 1: LPA with ISD-R securing LSI0. - Mode 2: eUICC with ISD-R reserving LSI1. - Mode 3: When a profile can be selected for LSI0 or higher, and ISD-R can be selected for any of these LSIs. It is done by [the specified method].

[0093] In a process involving updating or reading database 21, modem 145 sends command 51 to LSI0 45. LSI0 45 is a first logical secure interface (LSI) dedicated to user API control profiles. LSI0 45 is configured to identify user API control profiles based on the properties and / or location of the profiles in profile memory 17 (i.e., database 21) in order to provide ISD-R 160 with first management commands 52 dedicated to user-provisioned profiles. In step 53, ISD-R 160 updates or reads database 21 according to the received command. In step 54, ISD-R 160 sends a status response and / or data regarding the execution of the received first management command to LSI0 45.

[0094] In a process involving updating or reading the database 20, the modem 145 sends a command 55 to the LSI 1 46. The LSI 1 46 is a second logical secure interface (LSI) dedicated to the CMP control profile. The LSI 1 46 is configured to identify the CMP control profile based on the properties and / or location of the profile in the profile memory 17 (i.e., the database 20) in order to provide the ISD-R 160 with a second management command 56 dedicated to the CMP control profile. In step 57, the ISD-R 160 updates or reads the database 20 according to the received command. In step 58, the ISD-R 160 sends a status response and / or data regarding the execution of the received second management command to the LSI 1 46.

[0095] Figure 5 schematically shows the data flow and steps executed by the components of the system to perform operations on database 21 and to perform operations on database 20. These components are the user local application API 114 within the device, the eSIM IoT remote manager (eIM) 11, and the eUICC operating system OS eUICC 171 and the IPAe (Internet Profile Assistant for the things implemented on a card such as eUICC 150, etc.) 170, which is the eUICC 150.

[0096] In the process of performing operations on database 21, the API 114 sends command 61 to the OS eUICC 171. In step 62, the OS eUICC 171 updates the value of the context variable with the value of the local context variable and sends command 63 to the IPAe 170. In step 64, the IPAe 170 performs the operation described in command 63 on database 21.

[0097] In the process of performing operations on database 20, the eIM 11 sends command 65 to the OS eUICC 171. In step 66, the OS eUICC 171 updates the value of the context variable with the value of the eIM context variable and sends command 67 to the IPAe 170. In step 68, the IPAe 170 performs the operation described in command 67 on database 20.

[0098] Figure 6 schematically shows the data flow and steps executed by the components of the system to load the profiles provisioned by the user into database 21. These components are the user local application API 114 within the device, the SM-DP+ 120, and the eUICC operating system OS eUICC 171 and the IPAe 170, which is the eUICC 150.

[0099] First, API 114 sends the "Start Profile Download" command 71 to the OS eUICC Send to 171. In step 72, OS eUICC 171 updates the value of the context variable with the value of the local context variable and sends command 73 to IPAe 170. In step 74, IPAe 170 starts the profile download (according to SGP.32). During the initialization of secure communication with SM-DP+ 120, message 75 containing the encryption key is sent between IPAe 170 and SM-DP+ 120. Once secure communication is established, SM-DP+ sends command 76 to IPAe 170. In step 77, IPAe 170 sends OS eUICC The new profile is loaded into database 21 according to the value of the context variable updated by 171. Once the profile loading is complete, IPAe 170 sends a profile load notification 78 to SM-DP+ 120.

[0100] Figure 7 schematically illustrates the data flow and steps performed by the system components to load the CMP control profile into the database 20. These components are the eSIM IoT Remote Manager (eIM) 11, SM-DP+ 120, and the eUICC operating system OS. eUICC This is eUICC 150, which includes 171 and IPAe 170.

[0101] First, eIM 11 sends the "Start Profile Download" command 81 to the OS eUICC Send to 171. In step 82, OS eUICC171 updates the value of the context variable with the value of the eIM context variable and sends command 83 to IPAe 170. In step 84, IPAe 170 starts the profile download (according to SGP.32). During the initialization of secure communication with SM-DP+ 120, message 85 containing the encryption key is sent between IPAe 170 and SM-DP+ 120. Once secure communication is established, SM-DP+ sends command 86 to IPAe 170. In step 87, IPAe 170 sends OS eUICC The new profile is loaded into database 20 according to the value of the context variable updated by 171. Once the profile loading is complete, IPAe 170 sends a profile load notification 88 to SM-DP+ 120.

[0102] Figure 8 schematically illustrates the data flow and steps sequentially executed by system components for the user-local application API 114 or eIM 11 within the device to update or read database 21, or update or read database 20. These components are the user-local application API 114 within the device, IPAd (Internet of Things Profile Assistant implemented in the device) 140, LSI0 45, LSI1 46, and ISD-R 160.

[0103] If API 114 sends a “Consumer Database Update” or “Consumer Database Read” command 90 to IPAd 140, IPAd 140 sends command 91 to LSI0 45. LSI0 45 then sends command 92 to ISD-R 160. In step 93, ISD-R 160 updates or reads database 21 according to the received command and, if applicable, sends back a message 94 to LSI0 45 containing, for example, the data read from database 21 and / or the status of the execution of the received command (e.g., success of the update or read command).

[0104] If eIM 11 sends an "OEM database update" or "OEM database read" command 95 to IPAd 140, IPAd 140 sends command 96 to LSI1 46, and LSI1 46 sends command 97 to ISD-R 160. In step 98, ISD-R 160 updates or reads the database 20 according to the received command and, if applicable, sends back a message 99 to LSI1 46 containing, for example, the data read from the database 20 and / or the status of the execution of the received command (e.g., success of the update or read command).

[0105] The editing operation of the CMP control profile 18 is performed as known in the prior art.

[0106] Editing of the user API control profile 19 can be performed by CMP using the third command as described above, or by the user through the user API 114.

[0107] In this embodiment, at least one editing operation performed on the user API control profile 19, particularly its deletion, is notified to the CMP (e.g., SM-DP+ 120) by a message generated by the IPA 140 or 170.

[0108] In the embodiment, at least one editing operation is performed on the user API control profile 19 after the IPA 140 or 170 receives a message from the CMP (e.g., SM-DP+ 120). For example, this message may follow a request sent by the IPA to the CMP, which may ask whether to perform an editing operation on the profile 19. This request can be sent by the IPA to the CMP at regular time intervals.

[0109] As described above, the present invention enables OEMs to manage their CMP control profiles (e.g., enable, delete, disable) and end users to manage their own user API control profiles using the same device 130 and the same eUICC 150. The eUICC 150 manages two types of profiles in different ways: a CMP control profile 18 provisioned by the CMP and a user API control profile 19 controlled by the user through the local user API 114. These profiles are managed by two separate entities: the CMP control profile 18 is managed through the remote server eIM 11, and the user API 114 control profile 19 is managed through the local interface 31 or 135.

[0110] In the profile database 17, each profile has a property that indicates whether it is a CMP control profile 18 or a user API control profile 19.

[0111] In this embodiment, as shown in Figure 2, dedicated databases 20 and 21 are used for different profile types.

[0112] As shown in Figures 4 and 8, the ISD-R 160 receives a first profile management command dedicated to the user API control profile 19 and a second profile management command dedicated to the CMP control profile 18. To determine the profile type, a dedicated LSI (Logical Secure Interface) is assigned to each type; LSI0 45 is assigned to the user API control profile 19, and LSI1 46 is assigned to the CMP control profile 18. Consumer commands (first management commands related to the user API control profile 19, or the management of parameters associated with the user API control profile 19 and / or the database 21) are assigned to LSI0 45, so that only the consumer profile 19 can be managed and viewed through this LSI0 45. Similarly, second management commands related to the CMP control profile 18 are assigned to LSI1 46, so that only the CMP control profile 18 can be managed and viewed through this LSI1 46.

[0113] However, in order to enable the OEM to manage the entire secure element (eUICC 150), certain embodiments of the present invention enable several third management commands by eIM 11. The third management commands are different from the first and second management commands. Preferably, an indicator is added to identify the enabled third command, so that the ISD-R 160 executes the third management command without considering the profile type (CMP control or user API control). In certain embodiments, security mechanisms (e.g., PIN, encryption, authentication, etc.) are used to protect these types of third management commands from unauthorized access.

[0114] As mentioned above, one possible implementation is to adopt an eSIM based on SGP.32. In this case, the IPA needs to be able to identify the source of the command. This gives the IPA two possibilities.

[0115] Firstly, in certain embodiments, as shown in Figure 5, the IPA may be implemented on a card as an IPAe 170. Commands sent to the IPAe 170 can be received via two different transport channels (local ISO commands for consumers and radio for OEMs). The eUICC operating system 171 can visualize the IPAe 170 on these transport channels through context variables. Thus, the IPAe 170 can proceed with the execution of these commands according to these context variables. In the case of profile loading, as shown in Figure 7, loading is performed via the SM-DP+ 120 regardless of the origin of the initial command. Thus, in order to assign the correct properties to the downloaded profile (identifying whether it is a CMP control type profile or a user API control type profile), the eUICC operating system 171 stores initial context variables (e.g., via the ISD-R 160) and assigns properties to the downloaded profile accordingly.

[0116] Secondly, the IPA can be implemented in the device as IPAd 140. The IPAd 140 receives commands locally or wirelessly. Depending on the command origin channel, the IPAd 140 communicates with the ISD-R 160 on the consumer LSI0 45 or the OEM LSI1 46. The context for profile download is stored by the eUICC operating system 171 (e.g., via the ISD-R 160).

[0117] In this embodiment, the embedded user API 114 is used by device 130 to provide the end user with an activation code associated with a private subscription. Profile download can be performed by the embedded ES9+ 39 function.

[0118] In this embodiment, as shown in Figure 2, the profile database 17 in memory available for profiles is divided into two domains: partition 20 (or CMP control profile database 20) for CMP control profiles 18 (managed by CMP) and partition 21 (or user API control profile database 21) for profiles managed by end users 30. In this embodiment, the profile database 17 is configured to store, along with each profile, an attribute indicating whether the profile is a user API control profile 19 or a CMP control profile 18.

[0119] The end user 30 cannot manage profiles in the CMP control profile database 20. The eIM 11 cannot manage profiles in the user API control profile database 21. The size of each domain depends on the selected hardware (HW) platform and the size of its flash memory. However, as described above, in other embodiments, certain embodiments of the present invention enable several third management commands by the eIM 11 to allow the OEM to manage the entire secure element (eUICC 150).

[0120] As noted above regarding eUICC 150, the IPAd 140 on the device, the eIM 11, and the SM-DP+ server 120 within the network 112 communicate with each other. Since these components are supplied by different companies, a standardized protocol (interface) is needed so that any device equipped with any eUICC 150 can be used in combination with any eIM 11 and / or any SM-DP+ 120 server, as well as any mobile network operator (MNO) 115. If a user needs to download a new profile, they can use the ES9+ interface, which is an encrypted connection established by the IPA to the SM-DP+ 120.

[0121] Combined with standard MEP functionality, the present invention not only emulates multiple profile types that can be used in parallel, but also proposes the separation of memory domains for storing databases 20 and 21 of different profile types. From the perspective of the modem 145, this is not visible. The end user 30 can download the user API control profile 19, just like a standard eSIM consumer. The eIM 11 also interacts with the eUICC 150 as if it were its own dedicated eSIM. There is no risk that the end user may accidentally or unintentionally delete or disable the CMP control profile 18. Nor is there a risk that the eIM 11 may accidentally or unintentionally disable the user API control profile 19. From the perspective of the GSMA specification, an eSIM implementing the present invention is still a standard eSIM IoT, meaning that implementing the present invention has no impact on the SM-DP+ 120 side.

[0122] As is evident from the above description, the device of the present invention has the ability to perform over-the-air (OTA) provisioning of multiple network operator MNO 115 profiles from a central management point (CMP), including eIM and / or Subscription Manager Data Preparation Enhancement (SM-DP+), and manages profiles in an eUICC-enabled SIM (eSIM) card configured to use multiple active profiles (MEPs) simultaneously. According to the present invention, the eUICC 150 is configured to manage two types of profiles: a CMP-controlled profile 18 provisioned by the central management point and a user API-controlled profile 19 controlled by the user through a local user API 114. The eSIM card stores the above profiles in a profile database 17 in non-volatile memory MEM 175, and the properties and / or location of the profiles in the profile database 17 represent the profile type. The eUICC 150 - A first logical secure interface LSI0 45 dedicated to the user API control profile 19, configured to identify the user API control profile 19 based on the properties and / or location of the profile in the profile database 17 in order to provide the ISD-R 160 with first management commands dedicated to the user API control profile 19, or - A second logical secure interface LSI1 46 dedicated to the CMP control profile 18, configured to identify the CMP control profile 18 based on the properties and / or location of the profile in the profile database 17, in order to provide the ISD-R 160 with a second management command dedicated to the CMP control profile. It has a unique ISD-R 160 configured to receive profile management commands for both types of profiles.

[0123] The ISD-R 160 is configured to execute a first management command only for the user API control profile 19, and a second management command different from the first management command only for the CMP control profile 18.

[0124] In some embodiments, the ISD-R 160 is further configured to execute a third management command in both the user API control profile 19 and the CMP control profile 18, which is different from both the first and second management commands. In certain embodiments, the third command includes a specific indicator not included in either the first or second management command, and the third command is sent to the ISD-R by the eSIM remote manager (eIM).

[0125] These embodiments enable the OEM to manage the entire secure element eUICC 150 by enabling several management commands via the eSIM remote manager eIM 11. To do this, as already mentioned, indicators are added to the enabled commands, and as a result, the ISD-R 160 executes the commands without considering the properties of the profile (without identifying the CMP control profile 18 or the user API control profile 19).

[0126] In the embodiment, the device further includes a security mechanism configured to protect a third management command. The security mechanism may be, for example, PIN code verification, encryption, or authentication, which can protect these types of management commands from unauthorized access.

[0127] In this embodiment, the eUICC 150 further includes Internet of Things (IoT) profile assistants IPA 140 and 170, configured to identify a first management command from the local interface 114 and a second management command from the central management point 11.

[0128] In this embodiment, the IPA is implemented on a card (IPAe 170) and is configured to identify a first or second management command based on a different transport channel associated with a local interface 114 or a central management point 11.

[0129] In this embodiment, the IPA is implemented in the device (IPAd 140) and configured to identify a first or second management command based on a different transport channel associated with the local interface 114 or the central management point 11.

[0130] Commands sent to IPA 140 or 170 can be received via two different transport channels (local ISO commands for consumers and radio for OEMs). The eUICC operating system 171 can visualize IPA 140 or 170 on this transport channel through context variables. Therefore, IPA can execute these commands according to these context variables. In the case of profile loading, regardless of the source or channel of the initial command, loading is performed via the Subscription Manager Data Preparation Enhanced (SM-DP+) 120. Therefore, the eUICC operating system 171 stores the initial context variables (e.g., via the ISD-R 160) and assigns the properties to the downloaded profile accordingly, so that the correct properties (OEM type or user provisioning type) can be assigned to the downloaded profile.

[0131] In this embodiment, the eUICC 150 is configured to use an embedded ES9+ 39 interface to provide secure transport for the delivery of bound profile packages between the Subscription Manager Data Preparation Extension SM-DP+ 120 and the IPAe 170.

[0132] In one embodiment, the eUICC 150 includes an embedded user API 114 configured to provide the user with an activation code associated with a private subscription.

[0133] In this embodiment, the eUICC is provided with an endpoint function 37 that includes constrained application protocol (Coap) support for the eIM-IPA (ESipa) interface, or hypertext transfer protocol secure (HTTPS) support for eIM-IPA communication.

[0134] In this embodiment, the profile database 17 is divided into two domains: a first partition (or user API control profile database) 21 for user API control profiles 19 and a second partition (or CMP control profile database) 20 for CMP control profiles 18.

[0135] In this embodiment, the profile database 17 is configured to store, along with each profile, an attribute indicating whether the profile is a user API control profile 19 or a CMP control profile 18. [Explanation of Symbols]

[0136] 11 eSIM Remote Manager (eIM) 17 Profile Database 18 CMP control profiles 19. User API Control Profile 20 First Database 21 Second Database 30 End Users 31. In-vehicle user interface 36. Multiple Valid Profiles (MEPs) 37 eIM endpoints 39 Embedded ES9+ Interface 41. Issuer Security Domain Profile (ISD-P) 42. Issuer Security Domain Profile (ISD-P) 43. Issuer Security Domain Profile (ISD-P) 44. Issuer Security Domain Profile (ISD-P) 45. First Logical Secure Interface (LSI0) 46. ​​Second Logical Secure Interface (LSI1) 51 Commands 52 First Management Command 53 steps 54 steps 55 Commands 56 Second Management Command 57 steps 58 steps 61 Commands 62 steps 63 Commands 64 steps 65 Commands 66 steps 67 Commands 68 steps 71 Commands 72 steps 73 Commands 74 steps 75 Messages 76 Commands 77 steps 78 Profile Load Notification 80 Secure Channel Protocol 81 Secure Channel Protocol 81 Commands 82 steps 83 Commands 84 steps 85 Messages 86 Commands 87 steps 88 Profile Load Notification 90 commands 91 Commands 92 Commands 93 steps 94 Messages 95 Commands 96 Commands 97 Commands 98 steps 99 Messages 111 Subscription Manager Data Preparation Unit (SM-DP) 112 Mobile Network 113 Subscription Manager Secure Routing Unit (SM-SR) 114 User API 115 Mobile Network Operators (MNOs) 120 Subscription Manager Data Preparation Enhanced Version (SM-DP+) 121 Profile Package Binding Feature 122 Profile Package Distribution Function 125 Issuer Security Domain Profile (ISD-P) 130 devices 135 Local Interface 140. Internet of Things Profile Assistant (IPAd) 141 Operating Systems 145 Modem 150 Embedded Universal Integrated Circuit Cards (eUICC) 160 Issuer Security Domain Root (ISD-R) 165 Issuer Security Domain Profile (ISD-P) 170 Internet of Things Profile Assistant (IPAe) 171 eUICC Operating Systems 175 Non-volatile memory (MEM)

Claims

1. A device (130) for profile management in an eUICC-enabled SIM (eSIM) card (150), having the capability to perform wireless OTA provisioning of multiple network operator MNO (115) profiles from a central management point CMP, including an eSIM remote manager eIM (11) and / or a subscription manager data preparation extension SM-DP+ (120), and configured to use multiple valid profile MEPs simultaneously, - The eUICC is configured to manage two types of profiles: a profile controlled by the CMP (18) and a user API controlled profile (19) controlled by the user through the local user API (114), the eSIM card stores the profiles in a profile memory (17), and the properties and / or location of the profiles in the profile memory represent the profile type. - The aforementioned eUICC, - A first logical secure interface LSI0(45) dedicated to user API control profiles, configured to identify a user API control profile based on the properties of the user API control profile and / or the location of the user API control profile in the profile memory, in order to provide the ISD-R with first management commands (52, 63, 73, 92) dedicated to the user API control profile, or - A second logical secure interface LSI 1 (46) dedicated to CMP control profiles, configured to identify a CMP control profile based on the properties of the CMP control profile and / or the location of the CMP control profile in the profile memory, in order to provide the ISD-R with second management commands (56, 67, 83, 86, 97) dedicated to the CMP control profile. It has a unique issuer security domain root ISD-R(160) configured to receive profile management commands for both types of profiles, - The ISD-R is configured to execute a first management command only for the user API control profile and a second management command different from the first management command only for the CMP control profile. A device (130) characterized by the following features.

2. The device (130) according to claim 1, wherein the ISD-R (160) is further configured to execute a third management command that is different from the first management command and also different from the second management command in both the user API control profile and the CMP control profile.

3. The device (130) according to claim 2, wherein the third command includes a specific indicator not included in the first or second management command, and the third command is transmitted to the ISD-R (160) by the eSIM remote manager eIM (11).

4. The device (130) according to claim 2, further comprising a security mechanism configured to protect the third management command.

5. The device (130) according to claim 1, further comprising an Internet of Things (IoT) Profile Assistant (IPA) (140, 170) configured to identify the first management commands (63, 73) from a local user API (114) and the second management commands (67, 83) from a central management point (11).

6. The device (130) according to claim 1, wherein the eUICC (150) is configured to allow the user to edit a user API control profile through the user API (114).

7. The device (130) according to claim 5, wherein the IPA (140, 170) is configured to notify the CMP of at least one of the following editing operations performed on the user API control profile (19): enable, disable, delete, or update.

8. The device (130) according to claim 5, wherein at least one editing operation is performed on the user API control profile (19) after the IPA (140, 170) receives a message from the CMP.

9. The device (130) according to claim 8, wherein the message is followed by a request sent by the IPA (140, 170) to the CMP asking whether to perform a management operation on the user API control profile (19).

10. The device (130) according to claim 5, wherein the eUICC (150) is configured to use an embedded ES9+ interface (39) to provide secure transport for the delivery of bound profile packages between the Subscription Manager Data Preparation Enhanced Version SM-DP+ (120) and the IPA (170).

11. The device (130) according to claim 1, wherein the eUICC (150) is provided with endpoint functionality that includes constrained application protocol (Coap) support for the eIM-IPA (ESipa) interface or hypertext transfer protocol secure (HTTPs) support for eIM-IPA communication.

12. The device according to claim 1, wherein the profile memory (17) is divided into two databases: a first database (20) for CMP control profiles (18) and a second database (21) for user API control profiles (19).

13. The device according to claim 1, wherein the profile memory (17) is configured to store, along with each profile, an attribute indicating whether the profile is a user API control profile (19) or a CMP control profile (18).

14. A method for profile management in an eUICC-enabled SIM (eSIM) card (150), having the capability to perform wireless OTA provisioning of multiple network operator profiles from a central management point CMP, including an eSIM remote manager eIM (11) and / or a subscription manager data preparation extension SM-DP+ (120), and configured to use multiple valid profile MEPs simultaneously, - The eUICC manages the CMP control profile (18) provisioned by the central management point, - The eUICC manages a user API control profile (19) controlled by the user through a local user API (114) and This is a method that includes, The eSIM card stores the profile in the profile memory (17), and the properties and / or location of the profile in the profile memory represent the profile type. - The aforementioned eUICC, - A first logical secure interface LSI0(45) dedicated to user API control profiles, configured to identify a user API control profile based on the properties of the user API control profile and / or the location of the user API control profile in the profile memory, in order to provide the ISD-R with first management commands (52, 63, 73, 92) dedicated to the user API control profile, or - A second logical secure interface LSI 1 (46) dedicated to CMP control profiles, configured to identify a CMP control profile based on the properties of the CMP control profile and / or the location of the CMP control profile in the profile memory, in order to provide the ISD-R with second management commands (56, 67, 83, 86, 97) dedicated to the CMP control profile. Through this, it has a unique issuer security domain root ISD-R(160) that receives profile management commands for both types of profiles, The ISD-R executes a first management command only for the user API control profile and a second management command different from the first management command only for the CMP control profile. A method characterized by the following features.

15. The method according to claim 14, wherein the ISD-R (160) further executes a third management command in both the user API control profile (19) and the CMP control profile (18), which is different from the first management command and also different from the second management command.

16. The method according to claim 15, wherein the eSIM remote manager eIM (11) transmits a third command to the ISD-R (160), the third command including a specific indicator not included in the first or second management command.

Images