A method for executing applications in an integrated circuit card and corresponding integrated circuit card

Abstract

Described herein is a method for executing toolkit applications (TA; TAA, TAB) in a Toolkit Framework (TFW) implementing a runtime environment of an integrated circuit card (12), said integrated circuit card (12a) communicating with a device (11), in particular user equipment, to at least receive commands (AC, TP), a plurality of said toolkit applications (TAA, TAB) being registered to a same given toolkit event (E), said method comprising receiving a command (AC, TP) from said device (11) at said runtime environment (TFW), converting said command (AC, TP) to obtain said corresponding given toolkit event (E), triggering (TG) in sequence by the runtime environment (TFW, TE) said plurality of toolkit application (TAA, TAB) registered to said given toolkit event (E), upon said triggering (TG), performing a toolkit session (T10) of the triggered toolkit application (TAA, TAB) required by said command (AC, TP), said toolkit session (T10) requiring launching a corresponding set of commands to complete, wherein said triggering (TG) comprises pausing said triggering operation (TG) with respect to any subsequent application (TAB) to be triggered in said plurality of toolkit applications (TAA, TAB) registered to said given event (E), until one or more services triggered by said launched set of commands are complete (T9).

Description

[0001] "A method for executing applications in an integrated circuit card and corresponding integrated circuit card"

[0002] ★ ★ ★

[0003] Technical field

[0004] The embodiments of the present disclosure relate to techniques for executing applications in a Toolkit Framework implementing a runtime environment of an integrated circuit card, such integrated circuit card communicating with a device, in particular user equipment, to at least receive commands, said applications being configured to register to a given toolkit event, said method comprising receiving a command from said device at said runtime environment, converting said command to obtain a corresponding toolkit event, triggering by the runtime environment one or more application registered to said given toolkit event, upon said triggering, performing a session of said one or more corresponding application required by said command.

[0005] In particular, the solutions here described may be applied in the Toolkit Framework of a Java Card environment .

[0006] Description of the prior art

[0007] Integrated circuit cards, e.g. UICC (Universal Integrated Circuit Card) or eUICC (embedded UICC) or iUICC (integrated UICC) , often referred as Subscriber Identity Module (SIM) card, are widely used to enable the mobile devices to access services provided by Mobile Network Operators (MNOs) . Integrated circuit card software platforms are used, such as the Java Card™, which allow the integrated circuit card to receive and send commands e.g. APDU (Application Protocol Data Unit) , exchanging such commands with modules, e.g. reader modules, in devices, such as mobile equipment, e.g. a mobile phone or smartphone, within which the card is hosted or with which the card is operatively associated. An APDU may be thus viewed as the communication unit between a smart card reader and the card .

[0008] To this regard, in figure 1 it is described a UICC software architecture of an integrated circuit card 12, as said, for instance a UICC or eUICC (embedded UICC) , in particular according to the ETSI specifications TS 102 223 V.14.0.0.0 and TS 102 241 V9.1.0. , comprising a UICC Toolkit Framework TEW, stored in a non-volatile memory 12a, corresponding to a UICC runtime environment, comprising a JCRE (Java Card Runtime Environment) JR, a Toolkit Registry TR, a Toolkit Handler TH, a File Systems FS and a Triggering Entity TE . Preferably, the runtime environment implemented by the UICC Toolkit Framework TEW is the CAT (Card Application Toolkit) runtime environment as defined by ETSI TS 102 241, V17.1.0.

[0009] The integrated circuit card 12 comprises also in the simplified schematics shown in figure 1 a volatile memory 12d, e.g. a RAM, and a processing module 12c. Memories 12a, 12c and the processing module 12d are coupled on a bus which communicates by a physical communication interface IN with a host device, e.g. a user equipment 11, e.g. a mobile phone.

[0010] Applets such as Toolkit Applets TA, Remote Application Management Application RA, Java applets APP and Network access applications NA are also indicated stored in the non-volatile memory 12a. The difference between a Java Card™ applet APP and a Toolkit Applet TA is that the latter may not handle APDUs directly, but can handle higher level messages. A higher level message may involve multiple APDUs, can be for instance a SEND method which execution can span over multiple APDUs, i.e. the proactive protocol commands FETCH, TERMINAL RESPONSE. Furthermore the execution of a method could span over multiple APDUs .

[0011] The JCRE JR may contain the Java Card API and a Java Card Virtual Machine. The JCRE JR is configured to select any specific applet and transmit to it the process of its APDU.

[0012] The Toolkit Registry TR is configured to handle all the registration information of the toolkit applets TA, and their link to the JCRE JR registry.

[0013] The Toolkit Handler TH is configured to handle the availability of the system handler and the toolkit protocol (i.e. toolkit applet suspension) . A system handler in ETSI 102.241 for instance is a handler such as ProactiveHandler , ProactiveResponseHandler , EnvelopeHandler and EnvelopeResponseHandler .

[0014] The triggering entity TE, when an event occurs, is able to request the information from the toolkit registry TR, which toolkit applets TA are registered to the event. The triggering entity TE then triggers the toolkit applet TA.

[0015] The UICC File System FS contains the File System of the UICC 12, as for instance specified in the ETSI specification TS 102 221, and handles its own file access control. For instance, it is a JCRE owned object implementing the shareable interface uicc. access. UICCView .

[0016] Applets APP may derive from avacard . framework .Applet and provide the entry points: process, select, deselect, install as defined in the "Java Card™ 2.2 Runtime Environment Specification".

[0017] Toolkit applets TA are the Java Card based implementation of Toolkit Applications, in particular as per ETSI specification TS 101 220, these derive from avacard . framework .Applet , to provide the same entry points, and provide one object implementing the uicc . toolkit . Toolkit Interface shareable interface, so that these applets can be triggered by an invocation o f the processToolkit ( ) method . Application Identi fiers , AID, of the Toolkit Applets or Toolkit Applications are defined in the ETS I speci fication TS 101 220 .

[0018] Remote Application Management Application RA handles the loading, installation, management and removal of applets and packages as speci fied in TS 102 226 .

[0019] Thus , ETS I speci fications 102 . 223 , 102 . 241 speci fications define the Toolkit Framework of a Java Card platform and the possibility for an application to register itsel f to one or more event .

[0020] Currently, when an application is triggered a Toolkit session starts and one or more proactive commands can be sent in order to implement a given service . As soon as the triggered application has no other commands to perform the toolkit session ends and the Toolkit Framework triggers the next application registered on the same event . This however may cause problems i f the application previously triggered has still some action to complete .

[0021] Obj ect and summary

[0022] Considering the foregoing, an obj ect of various embodiments of the present disclosure is to provide solutions that are able to overcome one or more of the limits of the prior art .

[0023] According to one or more embodiments , one or more of the previous obj ects are achieved by a method for executing toolkit applications in a Toolkit Framework implementing a runtime environment of an integrated circuit card, said integrated circuit card communicating with a device , in particular user equipment , to at least receive commands , a plurality of said toolkit applications being registered to a same given toolkit event , said method comprising receiving a command from said device at said runtime environment , converting said command to obtain said corresponding given toolkit event , triggering in sequence by the runtime environment said plurality of toolkit application registered to said given toolkit event , upon said triggering, performing a toolkit session of the triggered toolkit application required by said command, said toolkit session requiring launching a corresponding set of commands to complete , wherein pausing said triggering operation with respect to any subsequent application to be triggered in said plurality of toolkit applications registered to said given event , until one or more services triggered by said launched set of commands are complete .

[0024] In variant embodiments , said method comprises said triggered application calling the Toolkit Framework to end said pausing of the triggering operation .

[0025] In variant embodiments , said method comprises that said runtime environment is provided with a first application programming interface configured to register a toolkit application to said given event in an exclusive mode , in which is paused said triggering operation with respect to any other application among the toolkit applications registered to said event , and with a second application programming interface , configured to release said registration of the toolkit application to said given event to the exclusive mode , allowing triggering of a next application among the toolkit applications registered to said event , upon occurrence of said given event triggering a toolkit application configured to register by calling with respect to said given event said first application programming interface , pausing said triggering operation with respect to any other application among the toolkit applications registered to said event , release said registration of the toolkit application to said given event to the exclusive mode , allowing triggering of a next application among the toolkit applications registered to said event , when said second application programming interface is called with respect to said given event .

[0026] In variant embodiments , said first application programming interface comprises a parameter, which when it is asserted in calling said first application programming interface registers said application to a recall event (which recalls at a given time , in particular periodically, said second application programming interface in order to release said registration of the toolkit application to said given event to the exclusive mode .

[0027] In variant embodiments , said Toolkit Framework is a Java Card Toolkit Framework .

[0028] In variant embodiments , said command is comprised in an Application Protocol Data Unit , APDU, issued by a user equipment .

[0029] In variant embodiments , said triggering comprises sending said event to a Toolkit registry, obtaining from said Toolkit registry indication of the one or more toolkit applications registered to said event and of the corresponding toolkit interfaces .

[0030] In variant embodiments , said application performs a call to said second application programming interface upon completion of said one or more services .

[0031] In variant embodiments , said plurality of toolkit applications registered to a given event is triggered according to a priority level assigned at their installation time , in particular i f two or more applications in said plurality of toolkit applications registered to a given event have the same priority level , they are triggered according to their installation time .

[0032] In variant embodiments , said one or more services triggered by said launched set of commands comprises requesting a response from an entity which is external at least to the integral circuit card, in particular an external server for the response , and pausing said triggering operation with respect to any subsequent application to be triggered in said plurality of toolkit applications registered to said given event until said toolkit application receives said response .

[0033] According to one or more embodiments , one or more of the previous obj ects are achieved also by an integrated circuit card configured to perform the method according to embodiments .

[0034] Brief description of the annexed drawings

[0035] The embodiments of the present disclosure will now be described with reference to the annexed drawings , which are provided purely by way of non-limiting example , and in which :

[0036] - Figures 1 have been described already in the foregoing;

[0037] - Figure 2 shows a block schematics representing the application triggering procedure of the Toolkit Framework;

[0038] - Figure 3 shows a protocol diagram of the operation of the Toolkit Framework;

[0039] - Figure 4 shows a protocol diagram representing the operation of the method according to embodiments .

[0040] Detailed description of embodiments

[0041] In the ensuing description, various speci fic details are illustrated, aimed at providing an in-depth understanding of the embodiments . The embodiments may be provided without one or more of the speci fic details , or with other methods , components , materials , etc . In other cases , known structures , materials , or operations are not illustrated or described in detail so that various aspects of the embodiments will not be obscured .

[0042] Reference to "an embodiment" or "one embodiment" in the framework of the present disclosure is intended to indicate that a particular configuration, structure , or characteristic described in relation to the embodiment is comprised in at least one embodiment . Hence , phrases such as " in an embodiment" or " in one embodiment" that may be present in various points o f this description do not necessarily refer to one and the same embodiment . Moreover, particular conformations , structures , or characteristics may be combined in any adequate way in one or more embodiments .

[0043] The references used herein are provided only for convenience and hence do not define the sphere of protection or the scope of the embodiments .

[0044] In figure 2 it is shown a block schematics representing the application triggering procedure of the Toolkit Framework TFW, responsible for the activation of toolkit applets TA, based on the APDU received by the integrated circuit card, by a user equipment 12 , e . g . a reader module of a device such as a mobile phone . Thus , in figure 2 an APDU command AC is sent to a Translator module TRN which converts the information from the incoming APDU command AC into a corresponding Event information E , which is supplied to the triggering entity TE , which is a module of the Toolkit Framework TFW performing a triggering operation TG of the Toolkit Application or Applications to be executed . A Toolkit Application may be an application on the UICC card which can be triggered by toolkit events issued by a terminal and which can send proactive commands to the terminal , as per the definition according to speci fication TS 102 241 V9 . 1 . G . The triggering entity TE sends the event E to the Toolkit Registry TR, requesting information from the Toolkit Registry TR, i . e . , which Toolkit Applets TA are registered to such event E . These Toolkit Applets are invoked / triggered by means of their processToolkit ( event ) method deriving from uicc . toolkit . Toolkit Interface mentioned above . Thus , there is one interface , the Toolkit Interface , which i s implemented by each toolkit applet . By implementing the Toolkit Interface a toolkit applet exposes a method processToolkit ( event ) that is invoked by the Toolkit Framework TEW each time a given event to which the application is registered, occurs . The input to the method processToolkit ( event ) is an indication of the event occurred . Once triggered the Toolkit application can manage the event E with methods of fered by the Toolkit Handler . The Triggering Entity TE then triggers , TG, the Toolkit Applet TA indicated by the Toolkit Registry . The UICC Toolkit Framework triggers a Toolkit Applet TAA by calling a process method, e . g . , processToolkit ( ) method, of the Toolkit Interface shareable interface obj ect provided by the Toolkit App let TA .

[0045] When the UICC Toolkit Framework FTW has to trigger several toolkit applets TA on the same event E , the next applet on the same event E is triggered when the previous ends the session of operations required by the APDU .

[0046] Every time an event occurs , the Toolkit Framework searches for the applications registered to that event and triggers all of them sequentially . The order by which the applications are triggered i s defined at instal l time by setting a "priority level" associated with each Toolkit Applets TA. The UICC Toolkit Framework TEW thus triggers the Toolkit Applets TA according to their priority level assigned at installation time . The priority level speci fies the order of activation of an applet compared to the other applets registered to the same event E . I f two or more applets are registered to the same event and have the same priority level , the applets are triggered according to their installation time ( i . e . the first installed applet is activated first ) .

[0047] Sometimes this may be not suf ficient and it could happen that a third-party application that starts on a given event needs that no other application is triggered by the same event for a given time .

[0048] Actually, when an application is triggered, upon receiving an APDU, a Toolkit session starts and one or more proactive commands can be sent during the Toolkit session in order to implement a given service . As soon as the triggered application has no other commands to perform the toolkit session ends and the Toolkit Framework triggers the next application registered on the same event . However, i f the triggered applet has not really finished, e . g . , it is waiting for a message coming from network, this may conflict with the Toolkit session of the next triggered Toolkit application .

[0049] By way of example , with reference to figure 3 , is shown a protocol diagram representing an example scenario , in which a toolkit application TAA and a toolkit application TAB are instal led on an eUICC card, such as card 12 , inserted in a mobile equipment , such as the user equipment 11 , and register themselves to a same event E . In the scenario shown both toolkit applications TAA and TAB are waiting for a Terminal Profile event TP , i . e . , an event originated a command AC by the (U) S IM upon receival of which the Toolkit Framework TEW stores the profile of the mobile equipment and then triggers the registered toolkit application or applications TA that may want to change their registry and / or internal state according to mobile capabilities.

[0050] The first application TAA has a priority greater than the second application TAB, so once the mobile equipment is switched on and the Terminal Profile event TP occurs (T1 indicates receiving the Terminal Profile event TP at the Toolkit Framework TFW, i.e., translated from the corresponding APDU, AC in figure 2) the Toolkit Framework TFW triggers T2 the first application TAA first, because of its greatest priority. The first application TAA sends T3 a message STA to a remote server, not shown, asking for data to be downloaded, i.e., sends proactive commands (for example OpenChannel and SendData) to request data download from remote server .

[0051] Once such message STA has been sent in action T3, the Toolkit session, indicated with T10, of the first application TAA is considered closed (T4) , i.e. completed, and the Framework TFW triggers, T5, the second application TAB registered on the Terminal Profile Event TP. The Toolkit session T10 is considered complete since the proactive commands have bene launched, or performed, including, besides other commands of the applet TAA not shown but comprised in the session T10, sending T3 the message STA to a remote server. Thus, per se, the toolkit session T10 is considered completed with respect to issuing the applet TAA commands, but there is at least an action, determined by one of this commands, which still requires completion, i.e. at least one of the services to be provided by the applet TAA is not completed .

[0052] The second application TAB in the scenario shown in figure 3 has to perform many commands, to implement its service, so a very long toolkit session, indicated by T6, takes place. In the meanwhile a message SMA from the remote server arrives for the application TAA, in particular in response to message STA, and the corresponding event is received T7 at the Toolkit Framework TFW, but it cannot be managed, e.g., the Toolkit Framework TW cannot perform triggering T8 of the first application TAA as required by the event originated by the message SMA, because the Toolkit Framework TFW is busy with the second application TAB. A timeout may for instance expire on the remote server side and the application TAA session could fail.

[0053] Therefore, it is here in the following described a solution for triggering applications in a Toolkit Framework implementing a runtime environment of an integrated circuit card, comprising managing events by a pause mechanism, defining an interface implemented with the relevant methods to allow an application to register itself in an exclusive way to a given event. For instance, the mechanism may be defined by the two APIs, a first API, void setExEvent (short event, boolean doNotPropagate ) a second API, void releaseEvent ( short event)

[0054] Preferably, the same name of the standard API can be used, adding a new parameter as input, Boolean doNotpropagate, defining the two methods, i.e. API, with the same name but a different signature, the signature being defined by the input and output parameters) . Thus the API here indicated as setExEvent can be added to the one already provided in the ETSI specifications. A toolkit application can use the standard API or the API here indicated as setExEvent depending on the procedure which is needed to adopt, in particular setExEvent to manage the Toolkit applications according to the method here described. Both methods setEvent ( short event) and setEvent ( short event, donotpropagate) , corresponding to setExEvent (short event, boolean doNotPropagate ) may thus exist, although here in the exemplary embodiments a different name, setExEvent (short event, boolean doNotPropagate) , is used to identify the API that is called .

[0055] The arguments are a variable 'event' which is 'short' , indicating an event E to be set, and a propagation variable 'doNotPropagate' , which is a boolean variable.

[0056] By calling the first API, setExEvent, a toolkit applet TA registers itself to a given event E, in order to be triggered once the given event E happens, and the triggering mechanism is paused for any other application registered on the same event E, until the event E is not released .

[0057] By calling the second API, releaseEvent ( ) , in particular by the Toolkit applet TAA, the event E previously set is released.

[0058] The pause mechanism provides also a backdoor in case the applet TA does not call the second API, releaseEvent API, in order to perform event release and allow triggering of next application (if any) by the Toolkit Framework TEW. By calling the first API setExEvent with the propagation variable doNotPropagate set to 'true' , the Toolkit Framework TEW is configured to automatically register the toolkit application TA to a proprietary event PE, e.g., EVENT_APPLICATION_RELEASE_EVENT_SET (value) . As any event E may be associated to a value argument of EVENT_APPLICATION_RELEASE_EVENT_SET, for example Terminal Profile event may have value '1' , in order to manage a new event, which is not provided by the ETSI specification, its associated value as argument shall be defined, different from the values already associated to the other events in the ETSI specification, i.e. EVENT APPLICATION RELEASE EVENT SET is to be set to a value not yet used. This proprietary event PE is to be sent by the Toolkit Framework TEW to such toolkit application TA, which session is being executed, periodically in order to request that the call of the second API, the event release API, i.e. second API releaseEvent , is performed.

[0059] Thus, in general the first application TAA (and any other application registered in the exclusive mode to the event E) may be set, e.g. programmed or coded, so that, for instance after the service triggered by the command of the completed toolkit session T10, e.g. at the end of the interval T10' of completion of the actions or services of the first application TAA, it calls the second API, releaseEvent () , e.g. subsequent the Toolkit Framework TEW triggering T9 the first application TAA as shown in figure 4. Registering the toolkit application TAA to a proprietary event PE, e.g., EVENT_APPLICATION_RELEASE_EVENT_SET (value) , implements a mechanism which periodically triggers, in particular from the the Toolkit Framework TEW, the first application TAA to call the second API, releaseEvent () , for instance for the case for some reason the application has failed to perform the call on its own.

[0060] To this regard, in figure 3 it shown a protocol diagram like in figure 2, here depicting a scenario using the described solution.

[0061] Here, the first application TAA registers to the Terminal Profile event TP in an exclusive way with the first API setExEvent, according to the solution here described. So once triggered, T2, and once the message has been sent to the remote server, T3, the first application TAA can wait for the response, message SMA to arrive, i.e. action T7, and no other application is be triggered until the second API releaseEvent has been called. With T10' is indicated the extent of the interval of completion of the actions or services of the first application TAA, which lasts until the result of sending message STA is received. Thus, after receiving T7 the message SMA at the Toolkit Framework FW, the Toolkit Framework TFW triggers T9 the first application TAA, which then can complete the action required by the command TP and in action Til is performed an application TAA release event with the call of the second API releaseEvent ( ) at the Toolkit Framework TFW.

[0062] The Toolkit Framework TFW resumes then the triggering operation, I i.e., it ends the pausing of triggering subsequent toolkit applications registered to the same event E, triggering T12 the second application TAB.

[0063] In this way the first application TAA is able to receive correctly response (SMS message SMA) from the server and manage it. Once finished, it releases the event, i.e. event TP, via the second API releaseEvent ( ) call and the Framework TFW can trigger the next application, e.g. TAB.

[0064] In general, the first application TAA which operates in exclusive mode, can be configured to call the second API releaseevent ( ) at any moment while active. Preferably, the call to the second API release event () is performed after all the responses to proactive commands issued by the first application TAA are received, i.e., until said toolkit application TAA receives the response from the server.

[0065] It is underlined that in the example described with reference to figure 4, a toolkit session, e.g. T10, of a certain applet, e.g. TAA, is registered on a certain given event E, then it is triggered by the event E and within the toolkit session T10 the application TAA requests data to a remote server. After the request the toolkit session ends, but the corresponding service is still not completed, since the card, i . e . the applet , is waiting for the network, i . e . the server to send the requested data . The data can be requested to an entity which is external to the user equipment hosting the integrated circuit card, but this may not exclude requesting data to modules in the user equipment by the application, i f this takes a long amount of time determining the risk of the interruption of the service by another application registered to the same event .

[0066] However, another case scenario may for instance involve a temporary loss of the network coverage . Thus , an application may be registered to an event E of Local Status , which is an event which reports network information, detect that there is no connection to the network, and choose to change , i . e . swap, provider, i f for instance the eUICC stores more than one profile . During such profile swap, a second application may also be registered to the Location Status event and thus be triggered, e . g . to perform a reset on the host terminal . Of course the reset would hinder the update of the profile which is being operated by the previous application and should be avoided .

[0067] The method here described thus , in the same way that it waits for the data requested to be received in the first example to complete the service , in the same way, i f the first application is registered in exclusive mode to the Local Status event , while it performs the profile swap, which includes performing a connection to new provider associated to the new profile , pause the triggering of the second application till the service is complete , i . e . till it connects to the new provider .

[0068] Thus , in general , the method here described is directed to toolkit sessions of applets , which have launched or issued the commands involved by the toolkit session, but which corresponding services or actions triggered by the commands are not completed. The service or action may involve receiving requested data, in the example from an external entity, but may be represented by any other set of commands in an applet which ends the toolkit session but leaves the service or action incomplete, such as the profile swap described above.

[0069] Thus, it is described here a method for executing applications, e.g., toolkit applications TA or TAA, TAB, in a Toolkit Framework, e.g., TFW, implementing a runtime environment of an integrated circuit card, e.g., 12, said integrated circuit card communicating with a device, e.g., 11, in particular user equipment such as mobile phone, to at least receive commands, e.g. APDU AC, TP, said applications, TA or TAA, TAB, being configured to register to a given toolkit event, E, such method comprising receiving a command, e.g., AC, TP, from said device, e.g., 11 at said runtime environment, TFW, i.e. receiving a command at the card from the host device, converting such command, e.g., AC, TP, to obtain said corresponding given toolkit event, E, e.g., by the translator TRN, triggering, e.g. operation TG, by the runtime environment, e.g., TFW, in particular the triggering entity TE, such plurality of toolkit applications, e.g., TAA, TAB registered to said given toolkit event, E, upon such triggering, e.g., TG, performing a toolkit session, e.g. the session T10, of the triggered toolkit application, in this case the first triggered application TAA, required by said command AC, TP, said toolkit session, e.g. T10, requiring launching a corresponding set of commands to complete, wherein said triggering, e.g., TG, comprises pausing said triggering operation, TG, with respect to any subsequent application, such as application TAB, to be triggered in said plurality of toolkit applications, e.g., TAA, TAB, registered to said given event E, until one or more services triggered by said launched set of commands are complete, e.g., after action T9.

[0070] In particular, if during said toolkit session, e.g. the session T10, said one or more services triggered by said launched set of commands, of such triggered toolkit application, TAA, comprises requesting, e.g., action T3, launching a command requesting a response from an external entity, i.e., an entity which is at least external to the integrated circuit card, in the example external to the user equipment, in particular a server, pausing said triggering operation, TG, with respect to any subsequent application, such as application TAB, to be triggered in said plurality of toolkit applications, e.g., TAA, TAB, registered to said given event E, until said toolkit application, e.g., TAA, receives said response, e.g. in action T9.

[0071] The triggered application, e.g., the first triggered application TAA, positively calls the Toolkit Framework, e.g., TEW, to end said pausing of the triggering operation TG.

[0072] The triggering TG as described, i.e. a triggering of a first toolkit application such as TAA which pauses triggering of further applications, e.g. TAB, in particular until it is released, e.g. after receiving the response to a command to an external entity, is implemented in that comprises that said runtime environment, e.g., TEW, is provided with a first application programming interface, in the description indicated by setExEvent ( ) , configured to register a toolkit application, e.g., TAA, to said given event E in an exclusive mode, i.e. a mode in which is paused said triggering operation TG with respect to any other application among the toolkit applications, e.g., TAA, TAB registered to said event E, and with a second application programming interface, in the description here indicated by releaseEvent ( ) , configured to release said registration of the toolkit application, e.g., TAA, to said given event, E, to the exclusive mode, allowing triggering TG of a next application, e.g., TAB, among the toolkit applications, e.g., TAA, TAB, registered to said event E, upon occurrence of said given event E triggering TG (or T3 in figure 4) a toolkit application, e.g., TAA configured to register by calling with respect to said given event E, i.e. inserting the event E as argument of the call of the API, said first application programming interface, pausing said triggering operation TG with respect to any other application among the toolkit applications, TAA, TAB, registered to said event E, release said registration of the toolkit application, e.g., TAA, to said given event E to the exclusive mode, i.e. allowing triggering TG of a next application, e.g., TAB, among the toolkit applications, e.g., TAA, TAB, registered to said event E, when the second application programming interface, e.g., releaseEvent () , is called with respect to said given event E, , e.g., in figure 4 when the action T7, receiving the message SMA, is performed.

[0073] Also, according to a relevant aspect of the method here described, said first application programming interface, e.g., setExEvent, comprises a parameter, e.g., doNotPropagate, which when it is asserted, for instance set to 'true' , in calling said first application programming interface registers said application, e.g., TAA) to a recall event, e.g.,

[0074] EVENT_APPLICATION_RELEASE_EVENT_SET as indicated above, which at a given time, or times, preferably periodically, recalls said second application programming interface, e.g., releaseEvent ( ) , in order to release said registration of the toolkit application TAA to said given event E to the exclusive mode, i.e. periodically forces the call of the release of the exclusive mode.

[0075] Thus, based on the above, the advantages of the described solution are clear.

[0076] The solution described here allows, by introducing a pause mechanism for the triggering during which an application operates in exclusive mode, avoiding that any other application is triggered by the same event for a given time, i.e. avoiding conflicts of the Toolkit session with the next triggered Toolkit application.

[0077] Also, advantageously, a periodical recall of the release API is introduced, avoiding that the pause from triggering remains active indefinitely.

[0078] Of course, without prejudice to the principle of the invention, the details of construction and the embodiments may vary widely with respect to what has been described and illustrated herein purely by way of example, without thereby departing from the scope of the present invention, as defined by the ensuing claims.

[0079] The solution here described can be applied between a first and a second host, comprising respective Secure Elements, as in the exemplary embodiment.

[0080] However, the solution here described applies in all the systems which comprise at least a host sending APDU commands to a Secure Element comprising a Java Card applet. Thus, it can apply to a host sending commands to a Secure Element of its own, rather than to Secure Elements of other hosts, or to any other exchange of APDUs and response between any host and any Secure Element .

Claims

CLAIMS1. A method for executing toolkit applications (TA; TAA, TAB) in a Toolkit Framework (TFW) implementing a runtime environment of an integrated circuit card (12) , said integrated circuit card (12a) communicating with a device (11) , in particular user equipment, to at least receive commands (AC, TP) , a plurality of said toolkit applications (TAA, TAB) being registered to a same given toolkit event (E) , said method comprising receiving a command (AC, TP) from said device (11) at said runtime environment (TFW) , converting said command (AC, TP) to obtain said corresponding given toolkit event (E) , triggering (TG) in sequence by the runtime environment (TFW, TE) said plurality of toolkit application (TAA, TAB) registered to said given toolkit event (E) , upon said triggering (TG) , performing a toolkit session (T10) of the triggered toolkit application (TAA, TAB) required by said command (AC, TP) , said toolkit session (T10) requiring launching a corresponding set of commands to complete, wherein said triggering (TG) comprises pausing said triggering operation (TG) with respect to any subsequent application (TAB) to be triggered in said plurality of toolkit applications (TAA, TAB) registered to said given event (E) , until one or more services triggered by said launched set of commands are complete (T9) .

2. Method according to claim 1, comprising said triggered application (TAA) calling the Toolkit Framework (TFW) to end said pausing of the triggering operation (TG) .

3. Method according to claim 1 or 2 wherein saidmethod comprises that said triggering (TG) comprises said runtime environment (TFW) being provided with a first application programming interface ( setExEvent ( ) ) configured to register a toolkit application (TAA) to said given event (E) in an exclusive mode, in which is paused said triggering operation (TG) with respect to any other application among the toolkit applications (TAA, TAB) registered to said event (E) , and with a second application programming interface ( releaseEvent ( ) ) , configured to release said registration of the toolkit application (TAA) to said given event (E) to the exclusive mode, allowing triggering (TG) of a next application (TAB) among the toolkit applications (TAA, TAB) registered to said event (E) , upon occurrence of said given event (E) triggering (TG) a toolkit application (TAA) configured to register by calling with respect to said given event (E) said first application programming interface, performing said pausing said triggering operation (TG) with respect to any other application among the toolkit applications (TAA, TAB) registered to said event (E) , release said registration of the toolkit application (TAA) to said given event (E) to the exclusive mode, allowing triggering (TG) of a next application (TAB) among the toolkit applications (TAA, TAB) registered to said event (E) , when said second application programming interface ( releaseEvent () ) is called with respect to said given event (E) .

4. Method according to claim 3 wherein said first application programming interface ( setExEvent () ) comprises a parameter (doNotPropagate) , which when it is asserted in calling said first application programming interface ( setExEvent () ) registers said application(TAA) to a recall event (EVENT_APPLICATION_RELEASE_EVENT_SET) which recalls at a given time, in particular periodically, said second application programming interface ( releaseevent () ) to perform said releasing said registration of the toolkit application (TAA) to said given event (E) to the exclusive mode.

5. Method according to claim 3 or 4, wherein said Toolkit Framework is a Java Card Toolkit Framework.

6. Method according to claim 3 or 4, wherein said command is comprised in an Application Protocol Data Unit, APDU, issued by a user equipment (11) .

7. Method according to claim 3 or 4, wherein said triggering (TG) comprises sending said event (E) to a Toolkit registry (TR) , obtaining from said Toolkit registry (TR) indication of the one or more toolkit applications (TAA; TAB) registered to said event (E) and of the corresponding toolkit interfaces (TI) .

8. Method according to any of the previous claims, wherein said application (TAA, TAB) performs a call to said second application programming interface ( releaseevent () ) upon completion (T9) of said one or more services.

9. Method according to any of the previous claims, wherein said plurality of toolkit applications registered to a given event (E) is triggered according to a priority level assigned at their installation time, in particular if two or more applications in said plurality of toolkit applications registered to a given event (E) have the same priority level, they are triggered according to their installation time.

10. Method according to any of the previous claims, wherein said one or more services triggered by said launched set of commands comprises requesting (T3) a response from an entity which is external at least tothe integral circuit card, in particular an external server for the response, and pausing said triggering operation (TG) with respect to any subsequent application (TAB) to be triggered in said plurality of toolkit applications (TAA, TAB) registered to said given event (E) until said toolkit application (TAA) receives (T9) said response (SMA) .

11. An integrated circuit card configured to perform the method of any of claims 1 to 10.

Images