WO2008104601A2

WO2008104601A2 - Method of managing command execution in an electronic token

Info

Publication number: WO2008104601A2
Application number: PCT/EP2008/052457
Authority: WO
Inventors: Xinyu Luo
Original assignee: Axalto SA
Current assignee: Axalto SA
Priority date: 2007-03-01
Filing date: 2008-02-28
Publication date: 2008-09-04
Anticipated expiration: 2009-09-01
Also published as: CN101256616A; WO2008104601A3

Abstract

The invention is a method of managing command execution in an electronic token ET connected to a host machine. Said token comprises a time manager TM, a microprocessor and a memory comprising at least one applicative command. Said method comprises a step of- initializing El the time manager TM with a predefined threshold; a step of receiving E2 an first command AC; a step of activating E3 the time manager; a step of executing E4 said first command AC until the execution is completed or the predefined threshold is reached by the time manager,- and when the predefined threshold is reached, a step of sending E5 a second applicative command DA to the host machine, and going back to activating E3 step.

Description

METHOD OF MANAGING COMMAND EXECUTION IN AN ELECTRONIC

TOKEN

(Field of the invention)

The present invention relates to methods of managing command execution in an electronic token. It relates particularly to methods of managing command execution where time measurement constraints are severe, for example for communication between a handset and a SIM (Subscriber Identity Module) card.

(Prior art)

The majority of smart cards, such as a SIM telephone subscriber card or credit card, are electrically connected during operation to terminals such as mobile phones or readers. These cards exchange, with terminals, data according to dedicated communication protocols such as ISO standard 7816-3. According to this standard, during a process of exchanging data blocks in case of the T=O or T=I transmission protocol at application layer level, the time between the leading edge of the last character of a block received by the card and the leading edge of the first character of a following data block transmitted by the card may not exceed a predetermined maximum time BWT (Block Waiting Time) . If, during the sequence of operations of the application process, the card knows that the processing of the received block will exceed the predetermined maximum time then the card should transmit a specific protocol request to the reader. This specific protocol request is referred to as "Waiting Time extension" WTX before expiry of the maximum time BWT.

If, following a received block, the card does not send another block normally before expiry of the time BWT, or a specific protocol request, before expiry of the allocated time, the terminal interprets this absence of a block as a time-out and may consider the card is mute.

Two types of management of waiting time extension WTX requests are known according to the prior art for solving this problem. In a first type of management, the waiting time extension WTX requests are managed by an application embedded in the card. This software solution is not portable because the times to be managed are dependent on the executed sub-programs. Moreover, is not applicable when the application calls a service having a long processing time like complex cryptography algorithm that does not take into account duration issue .

A second type of management is described in the EP1264288 patent application. Waiting time extension WTX requests are supplied by a time manager interfacing with the protocol layer. The time manager periodically sends, at the expiry of a waiting time, a waiting time extension protocol request transmitted to the terminal through the protocol layer as long as the data process in under progress in the embedded application of the card.

However some commands received by a card need a particularly long time for the entire execution, in particular for treatment performed through interpreted language like Java bytecode . Some mobile phones do not support such long time waiting and cut the communication even if they duly receive waiting time extension protocol request sent by the card. Another time management method is known according to the prior art for solving this problem. Additional calls to the More Time proactive command may be manually added in the application software itself. This method has several weaknesses. Since it is not possible to locate the optimal inserting points of the More Time command, the right number of commands to be inserted cannot be planned by the developer. If too many More Time commands are added then time is wasted during the command treatment. If the number of added More Time commands is too small then a communication break will occur. If the place of the inserting points is not relevant then a communication break will still occur.

(Summary of the Invention)

The invention aims at allowing execution of applications that require long internal execution phase in an electronic token connected to a host machine. The invention aims at allowing the automatic sending of the relevant number of commands to the connected host machine at the relevant time.

The object of the present invention is a method of managing command execution in an electronic token connected to a host machine. The token comprises a microprocessor, a time manager and a memory. The memory comprises an operating system and elementary instructions for performing at least one applicative command. Said method comprises the step of initializing the time manager with a predefined threshold, the step of receiving a first applicative command from the host machine, a step of activating the time manager, in response to the receipt of the first applicative command, a step of executing said first applicative command until the execution is completed or the predefined threshold is reached by the time manager, a step of sending, when the predefined threshold is reached, a second applicative command to the host machine, and going back to activating step.

When the predefined threshold is reached, the sending of the second applicative command to the host machine may be performed by means of the operating system or by means of the time manager. The electronic token may comprise a flag. The flag may be set to an activate state when the second applicative command is sent to the host machine. During the execution of the first applicative command, the token may keep on said first applicative command execution without waiting for a response to the sent second applicative command. The flag may be set to a deactivate state after the completion of the execution of the first applicative command. Said method may comprise a further step of deactivating the time manager when the first applicative command execution is completed.

The memory may comprise a virtual machine and an application. The first applicative command may be executed by both means of the virtual machine and the application.

The electronic token may have SIM features. The virtual machine may be a Java virtual machine. The sent second applicative command may be a proactive command. The predefined threshold may be a number of Waiting Time Extension procedure bytes sent by the token.

The second applicative command may be a Display Text proactive command. Another object of the invention is an electronic token which is intended to be connected to a host machine. Said token comprises a microprocessor, a time manager and a memory. The time manager is initialized with a predefined threshold. The memory contains an application, an operating system and a virtual machine. Said operating system activates the time manager in response to a first applicative command received from the host machine. Said virtual machine executes the first applicative command until the execution is completed or the predefined threshold is reached by the time manager. When the predefined threshold is reached, the operating system sends a second applicative command to the host machine, then the operating system activates the time manager and keeps on executing the first applicative command. The token may comprise a flag. Said flag may be set to an activate state when the second applicative command is sent to the host machine. Said flag may be set to a deactivate state after the completion of the execution of the first applicative command. The electronic token may be a smart card.

(Brief description of the drawings)

Other characteristics and advantages of the present invention will emerge more clearly from a reading of the following description of a number of preferred embodiments of the invention with reference to the corresponding accompanying drawings in which:

- Figure 1 depicts schematically the interaction between a handset and a SIM card when executing long time commands without the invention;

- Figure 2 depicts schematically the architecture of an electronic token of smart card type according to the invention; - Figure 3 is an algorithm for managing time constraint during a command execution according to the invention; and - Figure 4 depicts schematically the interaction between a handset and a SIM card when executing long time commands with the invention.

(Detailed description of the preferred embodiments)

The invention may apply to any types of electronic token connected to a host machine. In this specification, the electronic token is a SIM card but it could be any other kind of smart card or portable device performing a processing for a host device.

An advantage of the invention is to allow an automatic treatment of time constraint during the execution of command in an electronic token like a SIM card. It frees developer of software programs from the management of time relating to data exchanges. This is particularly interesting in but not limited to the case of applications software written in interpreted language like Java, such as an applet, that is assumed to be independent of any target platform.

As shown in Figure 1, a complex applicative command sent by the mobile phone ME can require a long time for execution completion in the SIM card. After receipt of a Terminal Response command, the SIM card send several waiting time extension procedure bytes 0x60 in order to inform the mobile phone that an additional time is required by the SIM card for the execution finalization. After receipt of a predefined number of waiting extension time procedure bytes the mobile phone ME cut the communication even though the card duly sent waiting time extension protocol request. The predefined number of waiting extension time procedure bytes depends on the mobile phone type. Some mobile phones cut the communication before receiving the fourth waiting extension time procedure byte.

Figure 2 shows the architecture of a SIM card as an example of an electronic token according to a preferred embodiment of the invention. The SIM card ET contains a microprocessor MP, a time manager TM, a communication interface CI and a memory MEM. The memory MEM contains an operating system OS, a virtual machine VM, a software application AP and a flag FL. The virtual machine VM may be a Java virtual machine or a .net virtual machine. The microprocessor MP cooperates with the memory MEM and is intended to run the operating system OS, the virtual machine VM, and the software application AP. The smart card is connected to a terminal ME such as a card reader or a mobile radiotelephone terminal by a communication link with or without electrical contacts.

The memory MEM may consist of a unique circuit or several circuits that may be of different types.

The time manager TM may consist of a hardware circuit, a software program or a combination of a hardware circuit and a software program.

Figure 3 shows an algorithm for managing time constraint during a command execution according to the invention. After a card initialization done by a connected mobile phone ME, the time manager TM of the SIM card is initialized to a predefined threshold during a first step El. Then the SIM card remains in standby mode, waiting for a command from the mobile phone ME .

After receipt of a first applicative command AC during a second step E2 , the time manager TM is activated by the operating system OS during a third step E3. Then the SIM card starts execution of the first applicative command AC. This command may be a "SEND SHORT MESSAGE" proactive command for example. Such a command prepares data and sends it to the mobile phone ME. The treatment for preparing data may be long into the card, especially when the data is encrypted using a non-standard algorithm. Since this kind of algorithm is implemented in JAVA, a lot of time is required for execution. The first applicative command AC corresponds to a feature provided by the application AP. Since the application AP is written in an interpreted language like Java, this execution is performed by means of the Java virtual machine VM of the SIM card. The execution of the first applicative command AC goes on until one event occurs among the two possibilities showed in test step E4 : either the command execution is completed or the predefined threshold is reached by the time manager TM.

If the predefined threshold is reached, step E5 is performed by the time manager TM. In step E5, the time manager TM warns the operating system OS that the predefined threshold has been reached. This warning can be made by an interruption sent by the time manager to the microprocessor. This lead the operating system OS to send a second applicative command DA to the mobile phone ME. This second applicative command may be a proactive command like a Display Text command or a More Time command. After receipt of the Display Text command, the mobile phone may display a message saying, for example, that the application is under progress for warning the user. After sending the second applicative command DA to the mobile phone, the SIM card may set a flag FL to an activate state, in step E6. By default this flag FL has been previously set at a deactivated state.

Then, in step E3 , the time manager TM is reactivated by the operating system OS.

Then the SIM card goes on the first applicative command AC execution without waiting for the response corresponding to the second command DA sent to the mobile phone. When the first applicative command AC execution is completed in the SIM card, the flag FL may be set to a deactivate state. Such a flag allows the SIM card to distinguish the kind of command sent to the host machine. If the flag has been set to a deactivate state then the card waits for a response after sending a command to the host machine ME. In other words, the card turns in a sleeping mode until data is received from the host machine ME. If the flag has been set to an activate state then the card does not wait for the response after sending a command to the host machine ME and continues the previously received first command execution. Finally, in step E8, the time manager TM is deactivated by the operating system OS when the first applicative command AC execution is completed.

Alternately, in step E5, the second applicative command DA may be sent by the time manager TM itself to the mobile phone ME.

Since a SIM card according to the invention is able to execute a received first command while waiting for the response of another command sent to the reader, time is saved for the user.

Alternately, the SIM card may not manage any flag. The card may use another mechanism having a function equivalent to the flag in order to preserve time execution performance. Such a mechanism may be a variable storing the execution context. The card may also manage neither any flag nor any replacement mechanism. In this case, the card waits for the answer to the second applicative command DA before continuing the first command AC execution.

Alternately, the flag FL may be stored in the memory MEM or in a register of the microprocessor MP.

As shown in Figure 4, a complex applicative command sent by the mobile phone ME may require a long time for execution completion in the SIM card. For example, the mobile phone ME may send a Menu Selection command then a Fetch and several Terminal Response commands . During the execution of a long-execution-time command by the SIM card, the SIM card send several waiting time extension procedure bytes 0x60 to the mobile phone ME. After the sending of the third waiting time extension procedure byte, the card OS automatically send a Display Text proactive command to the mobile phone ME and continues the long term command execution without waiting for a response for the Display Text command. Thanks to this automatic sending, the mobile phone ME does not cut the communication with the SIM card. The communication between the SIM card and the mobile phone remains alive. The SIM card can then fully execute the long-time command and send a Status Word byte 0x9IXX corresponding to the end of the long-time command execution.

An additional advantage of the invention is to allow the entire execution of applications that require long internal execution steps in an electronic token even if the application does not take care of time constraint. An electronic token according to the invention guarantees that the communication with the host machine will not be cut for time constraint reason during any application execution in the token.

Claims

1. A method of managing command execution in an electronic token (ET) connected to a host machine (ME) , said token (ET) having a microprocessor (MP) , a time manager (TM) and a memory (MEM) comprising an operating system (OS) and elementary instructions for performing at least one applicative command, said method comprises the following steps:

- initializing (El) the time manager (TM) with a predefined threshold, - receiving (E2) a first applicative command (AC) from the host machine (ME) , activating (E3) the time manager (TM), in response to the receipt of the first applicative command (AC) , - executing (E4) said first applicative command (AC) until the execution is completed or the predefined threshold is reached by the time manager (TM) , characterized in that said method comprises the further step of sending (E5) , when the predefined threshold is reached, a second applicative command (DA) to the host machine (ME) , and going back to activating

(E3) step.

2. A method according to claim 1, wherein the sending (E5) of the second applicative command (DA) to the host machine (ME) , is performed by means of the operating system (OS) or by means of the time manager

(TM), when the predefined threshold is reached.

3.A method according to claim 1 or 2, wherein the electronic token (ET) comprises a flag (FL) , and wherein the flag (FL) is set (E6) to an activate state when the second applicative command (DA) is sent (E5) to the host machine (ME) , and during the execution (E4) of the first applicative command (AC) , the token (ET) keep on said first applicative command (AC) execution without waiting for a response to the sent second applicative command (DA) .

4. A method according to claim 3 wherein the flag (FL) is set (E7) to a deactivate state after the completion of the execution of said first applicative command (AC) .

5.A method according to claim 1, 2, 3 or 4 wherein said method comprises the further step: deactivating (E8) the time manager (TM) when the first applicative command (AC) execution is completed.

6. A method according to claim 1, 2, 3, 4 or 5 wherein the memory (MEM) comprises a virtual machine

(VM) and an application (AP) , the first applicative command (AC) being executed by both means of the virtual machine (VM) and the application (AP) .

7. A method according to claim 6 wherein the electronic token (ET) has SIM features and the virtual machine (VM) is a Java virtual machine and the sent second applicative command (DA) is a proactive command.

8. A method according to claim 6 or 7 wherein the predefined threshold is a number of Waiting Time Extension procedure bytes sent by the token (ET) .

9. A method according to claim 7 or 8 wherein the second applicative command (DA) is a Display Text proactive command.

10. An electronic token (ET) intended to be connected to a host machine (ME) , said token (ET) containing

- a microprocessor (MP) , a time manager (TM) initialized with a predefined threshold,

- a memory (MEM) containing an application (AP) , an operating system (OS) and a virtual machine (VM) , where said operating system (OS) activates the time manager (TM) in response to a first applicative command (AC) received from the host machine (ME) , and said virtual machine (VM) executes the first applicative command (AC) until the execution is completed or the predefined threshold is reached by the time manager (TM) , said token (ET) being characterized in that, when the predefined threshold is reached, the operating system (OS) sends a second applicative command (DA) to the host machine (ME) , then the operating system (OS) activates the time manager (TM) and keep on executing the first applicative command (AC) .

11. An electronic token (ET) according to claim 10, the token (ET) comprising a flag (FL), wherein said flag (FL) is set to an activate state when the second applicative command (DA) is sent to the host machine (ME) , and the flag (FL) is set to a deactivate state after the completion of the execution of the first applicative command (AC) .

12. An electronic token (ET) according to claim 10 or 11, characterized in that the token is a smart card.