CN118339864A - Management of subscriber profiles on eUICC - Google Patents

Abstract

The present invention relates to methods, apparatus, and computer program products for managing subscriber profiles on an eUICC 130. In this context, a method for managing subscriber profiles stored in the eUICC 130 includes implementing an ISD-R131 and an API 132 on the eUICC 130, the API 132 preparing for performing profile management operations on subscriber profiles of the eUICC 130 via the ISD-R131 or performing profile management operations on subscriber profiles of the eUICC 130 via the ISD-R131. Further, the application 133 installed on the eUICC 130 instructs the API 132 to perform profile management operations with respect to the subscriber profile. The present invention also relates to a corresponding eUICC 130, a device 150 in which the eUICC 130 is embedded, and a computer program product that represents the API 132 and the application 133.

Description

Management of subscriber profiles on eUICC

The present invention relates to embedded secure elements, such as embedded universal integrated circuit card euiccs, and more particularly to managing subscriber profiles on euiccs.

Background

Recently, mobile devices configured to employ electronic subscriber profiles for communicating over mobile networks have emerged. Such mobile devices are typically equipped with electronic/embedded secure element devices, such as electronic/embedded universal integrated circuit cards (euiccs), configured to store one or more electronic subscriber profiles, such as electronic subscriber identity module (eSIM) profiles that may allow the mobile device to connect to one or more mobile networks. A subscriber profile (e.g., eUICC or eSIM profile) can be generated by a Mobile Network Operator (MNO), installed on a secure element of a mobile device, and used for communication by the mobile device over a corresponding mobile network.

The management of profiles installed on the eUICC (including, for example, the downloading, installation, content updating, or security checking of the profiles) is performed by the various instances and through the different interfaces of the infrastructure shown in fig. 1. It shows a simplified representation of the architecture of the remote eUICC provisioning system described in sgp.02"Remoter Provisioning Architecture for Embedded UICC Technical Specification (remote provisioning architecture of embedded UICC technical specification)" version 4.2, published by the GSM society. The eUICC provisioning system 100 is organized around several elements: SM-DP (subscription manager data preparation server 110), SM-SR (subscription manager secure routing server 140), and eUICC 130, the latter being part of an end-user's mobile device 150. The eUICC 130 is manufactured by an EUM (eUICC manufacturer, 160) (also known as a card vendor) that installs ISD-R (issuer security domain root, 131) as an on-card interface to the off-card SM-SR 140 and an on-card interface on behalf of the off-card SM-SR 140 during manufacture of the euuicc 130.

The SM-DP 110 is responsible for downloading, while the SM-SR 140 is responsible for creation, remote management (enabling, disabling, updating, deleting) and protection of subscriber profiles provided by MNOs (mobile network operators, 120). The M2M-SP (machine-to-machine service provider server 170) relies on the MNO 120 to provide the subscriber profile to the eUICC 130 and interacts with the SM-SR 140 to also provide some remote profile management capabilities, which, however, do not affect profile content updates.

The profile is loaded into the eUICC 130 by the SM-DP 110 and managed in the eUICC 130 by the SM-SR 140 (e.g., through appropriate commands) either directly through the channel or interface ES8 (i.e., into the channel 111 of the eUICC 130) or indirectly through, for example, the channel or interface ES3 (i.e., into the channel 113 of the SM-SR 140) and the channel or interface ES5 (i.e., further into the continuation 114 of the ES3 of the eUICC 130). Furthermore, the MNO 120 can also initiate a change to the profile loaded onto the eUICC 130 through the channel or interface ES6 identified by reference numeral 115 in fig. 1.

The profile management options proposed so far are initiated by or through an external server, and none of these capabilities are under the control of the eUICC 130 with profile or the device 150 in which the eUICC 130 is embedded and/or are not at the discretion of the EUM 160 or the vendor of such eUICC 130. In particular, the profile management function 114 provided over the ES5 interface needs to be triggered by the off-card SM-SR 140.

An additional option provided by the above-mentioned GSMA sgp.02 specification to enable profile management through or via the device 150 is through a channel or interface ESx identified by reference numeral 116 in fig. 1. However, such profile management/switching capability on the device side is very limited and includes only enabling/disabling emergency profiles or test profiles.

In addition, the GSMA sgp.02 specification neither defines any other profile switching options based on device inputs nor provides for the EUM/eUICC provider 160 to implement an automatic profile switching routine based on which definitions to address lack or loss of connectivity, resulting in UICC manufacturer/provider 160 implementing a separate non-standard automatic profile switching routine, which has the usual negative consequences of proprietary solutions.

On the other hand, customers increasingly require UICC manufacturers/suppliers 160 to implement custom profile switching routines, which require re-authentication of functions that have been authenticated by a CI (authentication issuer), identified by reference numeral 180 in fig. 1.

It is therefore desirable to provide an update mechanism for eUICC profiles that addresses the above-described drawbacks.

Disclosure of Invention

The invention solves the above object by the subject matter covered by the independent claims. Preferred embodiments of the invention are defined in the dependent claims.

According to a first aspect of the present invention, there is provided a method for managing subscriber profiles stored in an embedded universal integrated circuit card eUICC, which eUICC includes, among other standard components, an issuer security domain root component ISD-R. An application programming interface API is implemented on the eUICC that provides for or performs profile management operations on the subscriber profile of the eUICC via ISD-R. The profile management operations are then performed by the ISD-R through an operating system OS that accesses the eUICC.

Thus, the API acts as an on-card interface to the ISD-R through which profile management operations may be directed or requested by any entity, particularly by entities other than the remote SM-DP or SM-SR servers specified by the GSMA sgp.02 specification. Such entities that can indicate profile management operations by addressing IDS-R via an API are applications installed (in particular) on the eUICC or on the device in which the eUICC is embedded. Thus, an API in accordance with the present invention provides at least one method or routine that can be invoked by an entity (e.g., by an application installed on the eUICC) to perform profile management operations with respect to a subscriber profile of the eUICC.

While the profile management capabilities of ISD-R are only accessible through off-card servers such as SM-SR according to GSMA sgp.02 specifications, the present invention opens another way to access profile management capabilities provided by ISD-R, namely through an on-card API that represents an interface through which an application can instruct profile management operations to be performed by ISD-R. Thus, the proposed solution provides alternative, more flexible and widely accessible options for profile management as allowed by the GSMA sgp.02 specification. In particular, the API allows new functionality to be implemented based on new use cases and existing functionality to be adjusted or customized to meet changing customer expectations without requiring reauthentication through the CI. The API allows, even to some extent, the repair of errors in the behavior of the OS without having to re-authenticate the OS.

According to some embodiments of the invention, the API is implemented on the eUICC as a JavaCard interface that is accessible by a JavaCard applet installed as an application on the eUICC. This allows the JavaCard applet to be provided access to any profile management operations provided by the ISD-R in accordance with the GSMA sgp.02 specification.

According to the GSMA SGP.02 specification, certain profile management functions are accessible by SM-SR via an ES5 interface, by MNO via a SE6 interface, by SM-DP via an ES8 interface, and by a device in which the eUICC is embedded via an ESx interface. Through the APIs according to the invention, these profile management functions can be potentially accessed by applications installed on the eUICC (such as the JavaCard applet). That is, since these profile management functions are so far only available to limited entities specified by the GSMA SGP.02 specification, such as SM-SR, SM-DP, or MNO, the present invention makes them available to applications installed locally on the eUICC or on the device that can instruct the API to perform profile management operations that perform those profile management functions that were so far only accessible to the specified remote entity/server.

This provides, inter alia, new and/or more flexible profile management operations under control of the device in which the eUICC is embedded and/or at the disposal of the EUM or the issuer or vendor of the eUICC. Thus, for example, the device is no longer limited to enabling/disabling emergency or test profiles, but gain access to any profile management (including profile switching) with respect to the operating profile. In this regard, the present invention also provides EUM and eUICC providers with access to automated profile management, which is not provided by the GSMA sgp.02 specification.

In accordance with the present invention, the profile management operations provided by the API include, inter alia, activation and deactivation of subscription profiles. In addition, the API provides for retrieval of the status of the subscription profile and provides for changes to the content of the profile or switching of the profile stored in the eUICC.

In particular, those profile management functions (e.g., enable or disable profiles) that are accessible via the ES5 interface and must be triggered by the SM-SR according to the GSMA sgp.02 specification are available to the API to be triggered by applications installed locally on the eUICC in accordance with the present invention.

In addition, the API provides profile switching operations that are automatically triggered by events detected on the eUICC or by the eUICC instead of by the remote server. Such automatic switching operations include, for example, a ROLLBACK (FALLBACK) operation when connection with an active profile is lost, a ROLLBACK (ROLLBACK) operation when connection with a just-enabled profile is absent, a ROLLBACK based ROLLBACK (FALLBACK FROM ROLLBACK) operation when connection is absent after the ROLLBACK operation, and a ROLLBACK (SWITCHBACK) operation for restoring a profile disabled by the ROLLBACK operation.

By providing profile switching operations via an API, the present invention facilitates standardizing how eUICC providers and manufacturers implement automatic profile switching operations, e.g., by means of separate applications provided on the eUICC. Furthermore, eUICC vendors and manufacturers can implement their automatic switching operations based on device inputs without requiring re-authentication.

In some embodiments, an application is installed on the eUICC that instructs the API to perform profile management operations with respect to subscriber profiles stored on the eUICC according to whether predetermined criteria are met or whether an event occurs. If such criteria are met or an event occurs, the application instructs the API to perform a profile change operation with respect to the subscriber profile as a profile management operation. In this way, an application or JavaCard applet may trigger, for example, a profile change request based on criteria implemented in or controlled by the application or applet itself, such that the application itself (and thus the provider of the application) rather than a remote server controls conditions under which automatic profile changes may be performed.

In some embodiments, the application is provided by and/or installed on the eUICC by the issuer or manufacturer of the eUICC or by the issuer or manufacturer of the device in which the eUICC is embedded. This allows new use cases involving such application providers, as they can control profile management and profile switching operations via the provided applications and control conditions under which the API is instructed to perform such operations.

According to particular embodiments, an application that instructs an API to perform a profile switching operation may to some extent re-implement the functionality of the auto-switching functionality provided by the ISD-R and/or OS. For example, depending on the particular use case, the application may add further conditions under which to perform a rollback operation in order to resolve errors in the behavior of the OS.

In some embodiments, two or more applications are installed on the eUICC, for example, because the eUICC issuer and the mobile device manufacturer in which the eUICC is embedded each provide a separate application that implements a particular use case. Such applications may independently instruct the API to perform different profile management operations with respect to different subscriber profiles in order to handle the corresponding use cases.

In some embodiments, the device with the eUICC embedded therein requests that the application instruct profile management operations via an API. After the operation has been processed by the ISD-R and the eUICC's operating system, the application receives a response from the API to the indicated profile management operation and forwards the response and/or data derived from the response to the device. The data derived from the response provided by the API may, for example, include a profile or card status, such as the current subscription management card status required for the device to operate itself.

In this case, the device and the application establish a direct communication via which the device may trigger a profile switch, for example, by requesting the application (e.g., by sending a corresponding command) to instruct the API to perform a corresponding profile switch operation.

According to a second aspect of the present invention, there is provided an embedded universal integrated circuit card eUICC comprising an issuer security domain root component ISD-R and having stored therein at least one subscriber profile. An application programming interface API is implemented on the eUICC that is configured to prepare for or is configured to perform profile management operations with respect to at least one subscriber profile via ISD-R. An application can be installed on the eUICC, the application configured to instruct the API to perform profile management operations with respect to at least one subscriber profile.

In general, the API is configured to implement or relate to a method according to the first aspect, and the application is further configured to implement or relate to a method according to the first aspect.

The API is configured to handle profile management operations indicated by the application, which involve the retrieval of activation or deactivation or status of subscription profiles or the switching of subscriber profiles, while the application is configured to indicate such profile change operations if predetermined criteria implemented in the application itself are met.

According to a practical use case, an application is installed on an eUICC embedded in a device, and the application is configured to be functionally dedicated to or related to a use case defined by an issuer or manufacturer of the eUICC or the issuer or manufacturer of the device. To implement the use case within the setting, the application is preferably configured to process, on the one hand, a command received from the device by which the device requests the application to indicate a profile management operation via the API, and, on the other hand, to receive a response to the indicated profile management operation from the API and to forward the response or data derived therefrom to the device.

According to a third aspect of the present invention, there is provided a device having embedded therein an eUICC according to the second aspect, the eUICC being configured to implement the method according to the first aspect. Preferably, such a device is a mobile or terminal device, such as an M2M device, a telecommunication device or mobile phone, a personal or tablet computer, or the like.

According to a fourth aspect of the present invention, there is provided a computer program product representing an API that can be implemented on the eUICC according to the second aspect. The computer program product comprises instructions that, when executed on the eUICC, enable runtime behavior of an API that is involved in and/or causes the eUICC to perform the method according to the first aspect of the invention. Preferably, the computer program product according to the fourth aspect is a JavaCard interface.

According to a fifth aspect of the present invention, there is provided a computer program product representing an application implementable on an eUICC according to the second aspect. The computer program product comprises instructions that, when executed on the eUICC, enable runtime behavior of the eUICC that is involved in and/or causes the eUICC to execute an application of the method according to the first aspect. Preferably, the computer program product according to the fifth aspect is a JavaCard applet.

It must be noted that all the devices, elements, units, entities and means described in the present application may be implemented in software or hardware elements or a combination thereof. All steps performed by the various entities described in this application, as well as functions described, are intended to mean that the respective entity is adapted or configured to perform the respective steps and functions.

Other aspects, features and advantages of the present invention will become apparent to those ordinarily skilled in the art upon review of the following detailed description of preferred embodiments and variations of the invention in conjunction with the accompanying figures.

Drawings

Reference will now be made to the accompanying drawings, in which,

FIG. 1 illustrates a schematic block diagram of an eUICC profile management system;

Fig. 2 shows a schematic diagram of a device and eUICC according to the present invention; and

Fig. 3 shows a flowchart of a method for managing subscriber profiles stored in an eUICC, according to the present invention.

Detailed Description

A detailed description of the invention is given below with reference to the accompanying drawings, which illustrate specific embodiments of the invention. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments without departing from the scope of the invention. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.

Throughout the specification, the term "eUICC" is understood to be an integrated circuit IC, which is intended to securely store at least one subscription profile with profile data. The subscription profile in the eUICC can host an international mobile subscriber identity, IMSI, a unique serial number, ICCID, cryptographic encryption/decryption keys, security authentication and encryption information, temporary information related to the local network, a list of services that can be accessed by a user, and at least two passwords: a Personal Identification Number (PIN) for general use and a personal unlocking code (PUK) for PIN unlocking, which are used to uniquely identify and authenticate a subscriber on a terminal device, such as an M2M device, a mobile phone, a personal or tablet computer, etc. Further, the profile in the eUICC can contain a profile name or identifier.

The present invention proposes a mechanism for managing subscriber profiles stored in an embedded universal integrated circuit card eUICC 130, the eUICC 130 comprising an issuer security domain root component ISD-R131 and an application programming interface API 132. The capabilities of ISD-R131 are defined in the GSMA sgp.02 specification set forth above.

The API 132 is implemented on the eUICC 130 and forms an interface to the ISD-R131. It provides for performing profile management operations via ISD-R131 with respect to subscriber profiles stored in the eUICC 130 or for performing profile management operations via ISD-R131 with respect to subscriber profiles stored in the eUICC 130. In this context, "preparing for performing an operation" means that the API provides a method or routine to be called by an application or a function to be accessed by an application, which when called or accessed, causes execution of the operation implemented by the method, routine or function. On the other hand, the term "performing an operation" means performing the operation as a result of the interaction of the API 132 with one or more other components of the eUICC 130 (e.g., the ISD-R131 and/or the operating system 135 of the eUICC 130).

Fig. 2 illustrates a device 150 having the eUICC 130 embedded therein, which is configured to perform the profile management method according to the present invention as illustrated in fig. 3. The eUICC 130 embodying the present invention in the manner described below can operate within a profile management framework according to fig. 1.

Referring to fig. 2, the euicc 130 includes an ISD-R131 as an on-card delegate off-card subscription manager data preparation (SM-SR) 140. Via the SM-SR 140 and the channel ES5, the mobile network operator MNO 120 can trigger profile management functions 114, such as "enable profile", "disable profile", "delete profile", according to the GSMA sgp.02 specification, the profile management functions 114 do not affect the content of the profile and are then executed by the IDS-R131 in cooperation with the operating system OS135 of the eUICC 130.

Further, the eUICC 130 includes an application programming interface API 132 that is implemented as a separate entity and as an interface that provides one or more applications 133 (APPx) with access to the functions and capabilities of the ISD-R131. Since the eUICC 130 and the OS135 operate under JavaCard, the API 132 is implemented as a JavaCard interface, and the application 133 is installed as a JavaCard applet. Regarding interactions between the API 132 and the application 133, the API 132 implements methods and routines that may be invoked by the application 133.

The plurality of applications 133 (APPx) depicted in fig. 2 and the single application 133 (APPLET) depicted in fig. 3 are both external applications that use the APIs 132 and can be installed on the eUICC 130 or loaded onto the eUICC 130 and deleted from the eUICC 130 by different external entities, such as the issuer or manufacturer of the eUICC or the device in which the eUICC 130 is embedded. In addition, the applications 133 can be developed and installed on the eUICC 130 by other entities, such as by the MNO 130, by a customer of the eUICC/device issuer or manufacturer, or by other service providers, to provide these entities with case-dependent, individual access to profile management operations. Thus, development of the application 133 will generally be specific to a particular use case defined by or related to the application developer.

Examples of use cases for the device manufacturer are as follows: the device 150, such as a mobile phone or other communication device, typically includes GPS capability and thus constantly stores information regarding the quality of coverage of the network area by different MNOs 120. Thus, when network coverage requires switching of an active profile, a device 150 comprising an eUICC 130 according to the present invention can send corresponding commands to the device manufacturer's application 133, e.g., through a device application 151 installed thereon, to be able to operate under an MNO 120 with optimal coverage at the current location.

Referring to fig. 3, steps S1 and S2 represent implementing an API 132 on the eUICC 130 and installing one or more applications 133, respectively. While the API 132 is implemented by the issuer of the eUICC 130 or the manufacturer EUM160 (step S1), the application 133 indicating profile management operations via the API 132 and ISD-R131 may be installed by various entities, such as by the eUICC issuer or manufacturer 160, the issuer or manufacturer of the device 150, the MNO 120, or even by commercial service providers (such as banks, ioT operators, etc.), depending on the actual use case of the operation.

Further steps S3 to S14 show a process loop for performing a profile management operation according to the present invention. In step S8 the actual manipulation or access of the profile in response to the profile management operation PMO is performed, whereas steps S3 to S7 relate to the execution of the instruction and PMO, and steps S9 to S14 relate to processing the response received in response to the actual profile manipulation or access in step S8.

In accordance with the present invention, performing profile management operations via the API 132 can be initiated by an application 133 (APPLET) installed on the eUICC 130 or a device application 151 (D-APP) installed on the device 150 by a device issuer or manufacturer. In the former case, the processing cycle starts from step S4 and ends with step S12, while in the latter case, the processing cycle starts from step S3 and ends with step S14.

Another possible processing loop, not shown in fig. 3, may start from step S3 and end with step S14, but omit steps S4, S5, S11 executed by the application 133. According to this embodiment, the device application 151 completely replaces the eUICC application 133 and interacts directly with the API 132. In this case, the step of checking the condition for indicating PMO (step S4) may be performed by the device application 151 before actually indicating PMO with respect to the API 132 in step S3.

In step S3, the device application 151 requests the application 133 to instruct a specific profile management operation PMO. As described above, if the profile management operation is started by the application 133 without involving the device, this step and steps S13 and S14 are omitted.

In step S4, the application 133 checks whether certain conditions are satisfied, and if they are satisfied, instructs the API 132 to perform PMO in step S5. While the API 132 prepares for execution of the PMO by a method or routine to be called or a function to be accessed, the application 133 calls such a method or routine of the API 132 to indicate execution of the PMO. Through the condition check in step S4, the application 133 triggers the PMO based on criteria implemented in the application 133 itself (i.e., based on criteria that the application 133 or a local component of the eUICC 130 (e.g., the OS 135) controls, can detect, and/or can adjust).

In this regard, the indication of the profile management operation in step S5 may also be subject to the determination of the occurrence of the predetermined OS event in step S4. In this case, the corresponding application 133 registers an OS event such that the OS135 notifies the application 133 when one or more specific events occur, so as to end step S4 based on the detected event.

The profile switching operation may be indicated as a profile management operation, for example, through step S5. According to the GSMA sgp.02 specification, the local profile switching function 116 triggered by the device 150 is limited to emergency and test profiles and does not cover switching of actual operational profiles. However, the present invention allows for automatic and/or conditional switching of the operational profile as instructed by the application 133 in step S5. Such profile switching operations may include

(A) Rollback (FALLBACK): upon losing connection with the activity profile;

(b) ROLLBACK (ROLLBACK): in the absence of a connection to the just-enabled profile;

(c) Rollback-based rollback (FALLBACK FROM ROLLBACK): in the absence of a connection after rollback; or (b)

(D) Back cut (SWITCHBACK): for restoring the profile disabled by rollback.

The handover operations (a) through (d) are all triggered by the application 133 installed on the eUICC 130, overcoming the drawbacks of the solution provided by the GSMA sgp.02 specification.

Since several applications 133 may be installed on the eUICC 130, for example, one application 133 per available MNO 120 in particular, each of these applications 133 may apply different conditions for indicating a profile switch in step S4. For example, rollback may be indicated in step S5 only if it is verified in step S4 that a predetermined number of status requests have failed or an unexpected result is delivered.

Likewise, the application 133 may apply different conditions in step S4 to indicate rollback in step S5, such as the following:

APP1, rollback when the timer expires;

APP2: rollback when a specific state X is detected;

APP3: if the MNO's master profile is active, there is no rollback;

APP 4-unconditionally rollback to a different profile each time.

In step S6, the API 132, which is the interface to the ISD-R131, executes the called method or routine and thereby causes the ISD-R131 to finally perform PMO in step S7 using certain capabilities of the OS135, while performing the actual profile manipulation or profile access in step S8.

In step S9, the response of OS135 to the profile manipulation/access is received by ISD-R131 and forwarded to API 132 in step S10.

In step S11, the API 132 extracts information or export data from the response received from the ISD-R131. The exported data is processed by the application 133 in step S12 or forwarded to the device application 151 in step S13 and then processed by the device application 151 in step S14.

In the case where the application 133 indicates one of the aforementioned profile switching operations in step S5, the response provided to the application 133 by steps S9 and S10 may include a flag indicating whether the profile switching was successful or data related to the newly activated profile, such as an identifier, its operation state, a time stamp, etc. In this case, the application 133 derives such data from the response in step S11 and processes it in step S12, for example, because the data is used as a basis for an instruction of another conditional operation of steps S4 and S5.

For example, if a PMO is indicated by the application 133 (or requested by the device application 151) in step S5 (according to which the current subscription management state is to be retrieved), such a state is derived from the response in step S11, and then processed by the application 133 in step S12 (or forwarded in step S13 and processed by the device application 151 in step S14).

The methods provided by the API 132 and invoked by the application 133 are particularly directed to requesting PROFILE INFORMATION, such as GET INFORMATION (GET INFORMATION), GET emergency PROFILE (GET EMERGENCY PROFILE), GET fallback PROFILE (GET FALLBACK PROFILE), and the like. If such a method is invoked by the application 133 in step S5, the application 133 will obtain a profile state or attribute in step S11 revealing which profiles are active and may then form the basis for a decision on which profiles are to be deactivated, activated or switched by the indication according to step S5 based on the data processing in step S12.

The method provided by the API 132 also involves operations such as ENABLE (ENABLE), cut back (SWITCHBACK), rollback (FALLBACK) based on which the application 133 may force the profiling operation in step S5. Methods provided by API 132 include, but are not limited to, the following:

deregistration (DEREGISTER) -deregistration event;

E invoke OFF (ecall OFF) -disable emergency profile and enable previous profile;

e CALL ON (E CALL ON) -enable emergency profile;

ENABLE PROFILE (ENABLE PROFILE) -ENABLE PROFILE;

fall back (FALLBACK) -fall back to a given profile;

acquiring a currently enabled profile (GET CURRENT ENABLED PROFILE) -acquiring a currently enabled profile;

obtaining a current mode (GET CURENT MODE) -obtaining a mode currently operated by the eUICC;

obtaining an EID (GET EID) -retrieving the EID of the eUICC;

Acquiring an emergency PROFILE (GET EMERGENCY PROFILE) -retrieving the emergency PROFILE;

Acquiring a rollback profile (GET FALLBACK PROFILE) -retrieving a current rollback profile

Acquire instance (GET INSTANCE) -retrieve instance to access API methods;

acquiring a last confirmed profile (GET LAST CONFIRMED PROFILE) -retrieving the last confirmed profile;

acquiring a NEXT PROFILE (GET NEXT PROFILE) -iterating along the list of PROFILEs;

Acquiring a TEST PROFILE (GET TEST PROFILE) -retrieving the TEST PROFILE;

REGISTER-REGISTER event to notify the requestor when the event is triggered;

Cut back (SWITCHBACK) -cut back operation on a given profile.

In summary, the options provided by the above disclosed invention overcome the limitations of profile management of the GSMA sgp.02 specification. The present invention and related embodiments provide an API 132 that provides profile management operations so that an application 133 or applet can perform any of profile management, profile change, and profile switching operations based entirely on-card conditions and independent of any remote entity. Thus, any use case can be defined by accessing the API 132, and can be implemented under full control of the applications 133 and applets installed in the eUICC 130.

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader scope of the invention. For example, the above-described process flows are described with reference to a particular sequence of process actions. However, the order of many of the described process actions may be changed or additional process actions may be involved without affecting the scope or operation of the present invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims (17)

1. A method for managing subscriber profiles stored in an embedded universal integrated circuit card eUICC (130), the universal integrated circuit card eUICC (130) comprising an issuer security domain root component ISD-R (131), characterized by implementing an application programming interface API (132) on the eUICC (130), the application programming interface API (132) providing for performing profile management operations on subscriber profiles of the eUICC (130) via the ISD-R (131) or performing profile management operations on subscriber profiles of the eUICC (130) via the ISD-R (131).

2. The method according to claim 1, characterized in that the API (132) is implemented on the eUICC (130) as an interface to the ISD-R (131) and provides for performing profile management operations via the ISD-R (131) that perform profile management functions defined in GSMA sgp.02 specification "remote provisioning architecture of embedded UICC", wherein the profile management functions are indicated via ES5 interface (114) and/or via ES8 interface (111) and/or via ESx interface (116) according to GSMA sgp.02 specification.

3. The method according to claim 1 or claim 2, wherein the API (132) prepares for performing profile management operations via the ISD-R (131) or performs profile management operations via the ISD-R (131) that activate or deactivate subscription profiles, retrieve status or switch subscriber profiles stored in the eUICC (130).

4. The method according to any of the preceding claims, wherein the API (132) prepares for or performs profile management operations related to rollback operations, rollback operations or rollback-based rollback operations that address connection loss on the subscriber profile, or related to a rollback operation that activates the subscriber profile.

5. The method of any of the preceding claims, wherein an application (133) is installed on the eUICC (130), the application (133) instructing the API (132) to perform the profile management operation with respect to the subscriber profile.

6. The method according to claim 5, characterized in that the application (133) checks whether a predetermined criterion is fulfilled and in the affirmative instructs the API (132) to perform a profile change operation in respect of the subscriber profile as the profile management operation.

7. The method of claim 5 or claim 6, wherein at least one further application is installed on the eUICC (130), the application (133) and the at least one further application instructing the API (132) to perform different profile management operations with respect to one or more subscriber profiles stored in the eUICC (130).

8. The method of any of claims 5 to 7, wherein the application (133) is associated with an issuer or manufacturer (160) of the eUICC (130) or with an issuer or manufacturer of a device (150) in which the eUICC (130) is embedded and instructs the API (132) to perform a profile management operation associated with a use case defined by the issuer or manufacturer (160) of the eUICC (130) or the issuer or manufacturer of the device (150) or a use case related to the issuer or manufacturer (160) of the eUICC (130) or the issuer or manufacturer of the device (150).

9. The method according to any one of claims 5 to 8, wherein the application (133) as a JavaCard applet invokes a method provided by the API (132) as a JavaCard interface, instructing the API (132) to perform the profile management operation.

10. The method according to any one of claims 5 to 9, wherein a device (150) in which the eUICC (130) is embedded requests that the application (133) indicate the profile management operation via the API (132), and the application (133) receives a response to the indicated profile management operation from the API (123) and forwards the response and/or data derived from the response to the device (150).

11. An embedded universal integrated circuit card eUICC (130) in which at least one subscriber profile is stored, said eUICC (130) comprising an issuer security domain root component ISD-R (131), characterized in that an application programming interface API (132) is implemented on said eUICC (130), said API (132) being configured to perform profile management operations with respect to said at least one subscriber profile via said ISD-R (131) in preparation for or via said ISD-R (131).

12. The eUICC (130) of claim 11, wherein an application (133) is installed on the eUICC (130), the application (133) configured to instruct the API (132) to perform the profile management operation with respect to the at least one subscriber profile.

13. The eUICC (130) of claim 12, wherein the application (133) is associated with or with an issuer or manufacturer (160) of the eUICC (130) or a device (150) in which the eUICC (130) is embedded and is configured to be functionally dedicated to or related to use cases defined by the issuer or manufacturer (160) of the eUICC (130) or the issuer or manufacturer of the device (150) or use cases of the issuer or manufacturer (160) of the eUICC (130) or the issuer or manufacturer of the device (150).

14. The eUICC (130) according to any one of claims 11-13, wherein the API (132) is configured to implement or relate to a method according to any one of claims 1-10, and/or the application is configured to implement or relate to a method according to any one of claims 5-10.

15. A device (150) in which an embedded universal integrated circuit card eUICC (130) according to any one of claims 11 to 14 is embedded, the eUICC (130) being configured to implement the method according to any one of claims 1 to 10, the device (150) preferably being a mobile device or a terminal device.

16. A computer program product representing an application programming interface, API, (132) implementable on the embedded universal integrated circuit card, eUICC, (130) according to any of claims 11 to 14, the computer program product comprising instructions which, when executed on the eUICC (130), cause the eUICC (130) to perform the steps of the method according to any of claims 1 to 10, the computer program product preferably being a JavaCard interface.

17. A computer program product representing an application (133) installable on an embedded universal integrated circuit card eUICC (130) according to any one of claims 11 to 14, the computer program product comprising instructions which, when executed on the eUICC (130), cause the eUICC (130) to perform the steps of the method according to any one of claims 5 to 10, preferably a JavaCard applet.