Technical field This invention concerns the management of byte transmission in a smartcard. The example chosen to illustrate the invention is that of transmission of the response message known as the ATR (Answer-To- Reset) message defined in ISO (international standardisation organisation) standards 7816-3 and 7816-4. This message is transmitted by the smartcard to the card reader to which it is connected when the smartcard is powered up by the reader. The invention concerns the smartcard as well as the system including the smartcard and the associated card reader.

Note that in the context of the invention, a reader is a device which can exchange information with the smartcard.

The invention also concerns a method for the management of byte transmission by the smartcard and the resulting computer program.

State of the art technology Generally, powering up the card consists of applying an action received as an interrupt by the microprocessor. This action is generally called"RESET'. It has an interrupt vector or code sequence located at a certain address in memory. This address also generally contains a jump instruction to a start sequence.

Communication with a smartcard is carried out via a reader.

Note that standard ISO 7816-3 defines the communication protocol which must be used by the cards to communicate with the exterior.

This section describes the electrical signals and the information which is exchanged during all communications. The currents, voltages and signal frequencies are standardised, as well as the

format of the data exchanged during a communication between a card and a card reader.

When the smartcard is powered up, it transmits a message to the reader. This message from the card on start-up is generally called the ATR (Answer-To-Reset) in compliance with standards OSI 7816-3 and 7816-4. This message includes information indicating, in particular, to the reader the smartcard's abilities concerning the communication protocols. For example, the card indicates to the reader : <BR> <BR> - its protocol type (T=0, T=1, etc. )<BR> - the transmission speed (e. g.: 9600 baud, 38400 baud, etc. ) - the command execution time-out - etc.

The ATR message also includes historical information. This information includes the product identification, version, type of chip used, card status, etc.

The ATR message consists of a number of bytes. In most smartcards with microcontroller, the bytes in this message are transmitted sequentially. Generally, since card operating systems are becoming more and more complicated and since security is increasingly important, during transmission of an ATR message the operating system must carry out a certain number of processing operations before allowing the user to take control. In concrete terms, the operating system transmits a first byte of the ATR and then carries out a first processing operation. After this processing operation, the operating system transmits a second byte and then carries out a second processing operation. After this second processing operation, the operating system transmits a third byte and so on. The processing operations can be more or less complicated, with variable

execution times. Due to this variable execution time, it is therefore very difficult to determine the time interval between each transmission of bytes in an ATR message.

Standards exist, however, which define in particular, - a maximum time interval which must not be exceeded between the transmissions of two bytes in the ATR message, - a maximum global transmission duration for the ATR message which must not be exceeded.

These standards must be respected so that the reader can communicate with the smartcard. When these time intervals are not respected, the reader fails to recognise the card and most often, a mechanism included in the reader ejects the card from its housing.

Ejection of the card is a disadvantage for the card user.

Summarv of the invention One ; objective is therefore to improve the satisfaction of the card user.

To achieve this objective, according to the invention, a module external to the operating system is planned, to trigger byte transmission.

The. external module acts as assistant by monitoring the operating system. In its role as assistant, it can force the operating system to trigger byte transmission. Consequently, the inter-byte time intervals are better respected. The invention therefore avoids ejection of the card, improving the satisfaction of the card user.

It will be easier to understand the invention on reading the description below, given as an example and referring to the attached drawings.

In the drawings :

- figure 1 is a diagrammatic view of the architecture to which the invention can be applied, - figure 2 is a diagrammatic view of a smartcard, this architecture showing in particular the module external to the operating system.

- Figures 3A and 3B are algorithms illustrating the various steps of a first example of realisation.

- Figure 4 is a diagrammatic view of the information flow resulting from this first example of realisation, illustrating the exchange of information between a card reader, the operating system and the external module according to this solution.

- Figure 5 is an algorithm illustrating a variant of this first example of realisation.

- Figure 6 is a diagrammatic view of the information flow resulting from the variant of the first example of realisation, illustrating the exchange of information between the card reader, the operating system and the external module.

- figure 7 is an algorithm illustrating a second example of realisation of the invention in which the external module is a software agent.

Detailed description of examples illustrating the invention To simplify the description, the same elements illustrated in the drawings have the same references.

Figure 1 shows a system SYS to which this invention can be applied. This system SYS includes a smartcard CAR and a smartcard reader LEC connected together via communication links LIA.

Communication messages transit on these links preferably using a format in compliance with standard ISO 7186-4.

Figure 2 shows a diagrammatic view of the architecture of a smartcard CAR. The smartcard CAR includes an electronic module MOD. The module MOD includes a microcontroller MIC and contacts to comrnunicate with the exterior. Generally, a microcontroller includes: - a microprocessor CPU to execute the commands, - non volatile memories ROM (Read Only Memory), whose content is burnt in in the factory and therefore cannot be modified. An encryption algorithm, the operating system SE, application programming interfaces (API), etc. can therefore be written in the ROM; - non volatile memories, for example EEPROM (electrically erasable programmable read only memory). It is generally used to store data specific to each card, for example the cardholder identity, the access rights to the services, the file systems, all the application programs of the card, etc.

- volatile memories RAM, work space to execute the card commands, - security units CRYP for data encryption, - units taking into consideration the power supply voltage, clock speed, etc., - an input/output port, of type UART (Universal Asynchronous Receiver Transmitter) for example, known by those skilled in the art, for communication between the card CAR and the reader LEC.

- a series of buses BUS connecting the various parts together for data, address and command exchange.

The module also includes contacts to communicate with the reader, in particular, - input-output I/O contacts,

- electrical contacts VCC and VPP, and the ground GND (the electrical contact VPP is generally used to supply a voltage for programming, whereas the contact VCC is used to power the card), - a contact RES to reset the card or power it up.

The operating system has a command set which it can execute upon request. It manages the communication with the exterior, using a standardised and secured communication protocol. The commands given are validated by the operating system before being executed.

When the card CAR is powered up, it transmits a message to the reader LEC. This message is generally called the ATR (Answer-To- Reset) message. This ATR message generally consists of a number of bytes.

The problem, as mentioned in the introduction, concerns the time interval between two byte transmissions in the ATR message.

According to a first example of realisation, the solution consists of using a timer device, such as a programmable clock TIM (Timer). A programmable clock is a circuit using a clock to generate interrupt signals every"n"clock cycles. This clock is said to be programmable since its clock frequency can be modified.

This programmable clock TIM can either be located on the card CAR or on an external device connected directly or indirectly to the card. For example, this clock TIM can be a component of the read device. An example of a device connected indirectly would be a computer to which the reader LEC is connected.

In our example of realisation, the programmable clock TIM is included in the smartcard CAR.

To illustrate the invention, so that it is easier to understand, we will refer to the steps of algorithms ALG1 and ALG2 on figures 3A and 3B, respectively.

These two algorithms ALG1 and ALG2 interact. In other words, when the operating system caries out processing operations, the algorithm ALG1 can at any time be interrupted by an interrupted triggered by the programmable clock so that ATR bytes can be transmitted.

In our example of realisation, the first algorithm ALG1 includes the following main steps: - A first step ET11 consists of powering up the card.

- During a second step ET21, the operating system activates the programmable clock TIM so that it triggers interrupts for transmission of ATR bytes.

- During a third step ET31, the operating system performs a series of processing operations (Tl-Tn). In our example, the parameter"n"is the number of processing operations to be performed.

Steps ET21 and ET31 can be executed in any order. Obviously, other steps may be implemented. For example, activation may not take place directly after powering up. Processing steps may be planned between steps ET11 and ET31.

The second algorithm ALG2 illustrates the steps in transmission of ATR bytes Oj (j=l,..., m). This algorithm ALG2 is implemented after being activated in the second step ET12 of the first algorithm.

This algorithm ALG2 is a programming loop including the following steps: - During a first step ET12, the programmable clock triggers an interrupt 11 which can interrupt the operating system. The operating system interrupts its current work, for example a processing operation (Tl-Tn) in progress if it had already started.

- In step ET22, after receiving the interrupt 11, the operating system jumps to a code sequence planned for transmission of ATR bytes and starts the transmission of a first ATR byte O 1.

- Then, a step ET42 consists of determining whether the ATR message includes other bytes to be transmitted. In our example of realisation, this step consists of determining the number L (ATR) of bytes still to be transmitted in the ATR message and of decrementing this number by one unit (L (ATR)-1) after each transmission of one byte.

-During a step ET52, the number of bytes still to be transmitted is checked. There are now two possibilities: 1 possibility : If the number of bytes L (ATR) still to be transmitted is greater than one, step ET12 is repeated. During a step ET12, the programmable clock automatically triggers a new interrupt I2 which can interrupt the execution of algorithm ALG 1 again. Further to this new interrupt I2, the operating system transmits a second byte 02.

The process continues, the value of the number of bytes L (ATR) not yet transmitted is decremented by one unit and the index j is also incremented by one unit. When all bytes have been transmitted, preferably a message informs the operating system that transmission of the bytes in the ATR message has finished.

2nd possibility : If the check carried out in step ET52 shows that there are no more bytes to be transmitted, the processing operations can continue until they are finished.

Preferably, after transmitting a byte On, the operating system starts a processing operation during a step ET32, or continues it if it had started before the interrupt I1. For example, during the check in step ET52 to determine the number of bytes still to be transmitted,

the operating system can continue the processing it had interrupted previously until a new interrupt is triggered.

Figure 4 illustrates the exchange of information with time between the reader LEC, the operating system and the programmable clock TIM. This figure indicates more clearly the time when the transmission of bytes in the ATR message is triggered. On this figure, the delays for transmission of an interrupt or a byte A On are far removed from reality. To obtain a better understanding of the correspondence between figures 3A-3B and 4, in the remainder of the description, the steps of figures 3A and 3B are written between parentheses.

After powering up (ET11), the operating system transmits a first message to activate the programmable clock (ET21) Once activated, the programmable clock transmits an interrupt I1 to the operating system so that it interrupts its current processing operations (ET12).

After receiving the interrupt, the operating system transmits a first byte O1 to the card reader (ET22). The transmission time is for example. A 01.

The process continues, a second interrupt I2 is transmitted to the operating system, and after reception of the interrupt the operating system transmits a second byte 02 to the card reader. The transmission time is for example A 02.

This figure shows the time interval ARm between the end of transmission of a byte O (m-l) and the time when transmission of the next byte O (m) is triggered. This interval is approximately reduced to the time required to transmit an interrupt.

Another variant of the invention could consist of transmitting at least two bytes after each interrupt. Instead of transmitting one byte

after an interrupt, the programmable clock can be programmed to allow, after each interrupt, transmission of k bytes. The programmable clock must be programmed for this variant so that there is sufficient time between two interrupts to transmit these k bytes. Figure 5 is a view of an algorithm ALG3 illustrating this variant. A step ET72 has been added on this figure as compared with the algorithm ALG2 shown on figure 2. This step ET72 includes a step to check the number of bytes transmitted successively after an interrupt. There are two possibilities: lst possibilitv If the number of bytes transmitted is not equal to k, the operating system transmits another byte in step ET22. The number k is then incremented by one unit and the index j incremented by one unit.

2nd possibility If the number of bytes transmitted is equal to k, the operating system transmits an interrupt and step ET12 is carried out. The parameter k is then reset so that the check in step ET72 can be carried out.

Figure 6 illustrates the flow of information with time t between the reader LEC, the operating system and the programmable clock TIM. This figure is an example in which three bytes have been transmitted after each interrupt (k=3). This figure clearly shows that between two interrupts, the bytes are transmitted successively without-a break. Obviously, as on figure 4, the delays for transmission of an interrupt or a byte are far removed from reality.

Figure 7 is an algorithm ALG4 illustrating a second example of realisation in which an agent external to the operating system is created. In this example of realisation, it is no longer necessary to interrupt the operating system, which was the case in the first

example of realisation. This agent is a software program whose function is to trigger the transmission of bytes in the ATR message as well as to transmit these bytes.

This agent can be, for example, the UART component described above. It would be programmed to periodically transmit a certain number of bytes. An agent may also be a module including a second microprocessor which would be responsible for triggering byte transmission and transmitting bytes.

The algorithm ALG4 illustrating this second example of realisation includes the following steps: In step ET13 of the algorithm ALG4, the smartcard is powered up.

In step ET23, the microprocessor receives this command RESET and activates the agent. Activation consists of starting the agent.

In step ET33, the operating system transmits all bytes of the ATR message to the agent.

In step ET43, the bytes of the ATR message are stored in a memory, for example a buffer memory associated with the agent.

After activation and reception of the bytes in the ATR message, the agent becomes responsible for triggering byte transmission and transmitting these bytes. The operating system can then concentrate, possibly in parallel, in step 53, on other tasks such as the processing operations (Tl-Tn). The transmission method may be that described in figure 3B. Byte transmission then consists, during a step ET63, of transmitting a byte as in step ET22 on figure 3B. Another step ET73 consists, as in step ET42 on figure 3B, of determining whether the ATR message includes other bytes to be transmitted. In our example of realisation, this step consists of determining the number L (ATR) of bytes still to be transmitted in the ATR message and of decrementing

this number by one unit after each transmission of one byte. Another step ET83, identical to step ET52 on figure 3B, consists of checking the number of bytes still to be transmitted. There are now two possibilities: 1st possibilitv : If the number of bytes L (ATR) still to be transmitted is greater than one, step ET63 is repeated. The agent transmits a second byte 02. The process continues, the value of the number of bytes not yet transmitted is decremented by one unit. When all bytes have been transmitted, preferably a message informs the operating system that transmission of the bytes in the ATR message has finished.

2nd possibility : If the check carried out in step ET83 shows that there are no more bytes to be transmitted, a message informs the operating system during a step ET93 that transmission of bytes in the ATR message has finished.

Note that the transmission process chosen to illustrate this second example corresponds to algorithm ALG2 on figure 3B, but could have just as easily been algorithm ALG3 on figure 5.

Note also that, in step ET33 described previously, the operating system can transmit to the agent all bytes of the ATR message in several goes depending on both the size of the buffer memory and the number of bytes in the ATR message to be transmitted.

Note that the agent described previously may be located either on the card, on the reader or on any other device connected directly or indirectly, via a bus, to the card. In our example, we consider that the reader is connected directly to the card. An example of a device connected indirectly would be the computer managing the card reader.

Generally, the invention concerns a smartcard CAR, wherein it comprises a module (TIM) external to the operating system to manage the triggering of byte transmission. In our example of realisation, the module triggers the transmission of each byte in the series of bytes forming the ATR message. Obviously, the invention is not limited to a card comprising one module, but applies to any card comprising at least one module. We have seen that this module (TIM) includes a program which is activated by the operating system before use.

We have seen in a first example of realisation that the module TIM is a programmable clock which generates, after its activation, interrupts which can interrupt any processing operation in progress of the operating system and which can force the operating system to trigger byte transmission.

In this first example of realisation, we have seen that this programmable clock can be located either: - on the smartcard CAR, - or on a device connected, directly or indirectly, to the smartcard CAR.

An example of a device connected directly would be the card reader LEC.

We have also seen in the description that this module TIM could be an agent including a program responsible, after its activation, for both triggering byte transmission and transmitting the bytes. To implement this example, the agent requires a memory, for example a buffer memory. The agent stores in this memory all or some of the bytes transmitted by the operating system. Preferably, this memory is large enough to contain all the bytes of the ATR message.

As we have seen previously, the invention applies especially to the reset bytes known as the ATR (Answer-To-Reset) bytes by those skilled in the art. These ATR bytes are transmitted by the card after it is powered up.

The solution also concerns the smartcard system including a smartcard and a smartcard reader. We have seen that this system includes one (or several) module (s) (TIM) external to the card's operating system to manage the triggering of byte transmission. The location of this module is unimportant in the sense that it can either be on the card, on the reader or on any other device connected directly or indirectly, via at least one command line, to the card.

The solution also concerns the reader LEC of the smartcard CAR. This reader includes a module (TIM) to manage the triggering by the operating system of byte transmission. The module (TIM) is a programmable clock which generates, after its activation, interrupts which can interrupt any processing operation in progress of the operating system and which can force the operating system to transmit the bytes.

The invention also concerns the method of communication in a system comprising a smartcard CAR including a microcontroller and a smartcard reader (LEC), said device comprising a module (TIM) external to the operating system to manage the triggering of byte transmission, the method including a step to activate the module so that it triggers the transmission of at least one byte from the card to the reader (LEC).

To perform the triggering step, in our first example of realisation, the module (TIM) generates interrupts which can interrupt any processing operation in progress of the operating system included in the card and which can trigger the transmission, by the operating

system, of at least one byte (ATR) by the operating system to the reader.

In the second example of realisation, we have seen that the module could be an"intelligent"software agent. After activation of this agent, the method comprises a step to load all or some of the bytes in a memory associated with this agent, this agent triggering transmission of the bytes loaded in memory to the reader.

The triggering is carried out by a program. This program includes program code instructions to execute a step to activate said module so that it triggers the transmission of bytes from the card to the reader (LEC). This data processing device may be, as we have seen, the smartcard or a device connected, directly or indirectly, to the smartcard CAR.

Lastly, the invention concerns a microcontroller including an operating system, wherein it comprises a module (TIM) external to the operating system to trigger byte transmission.

We now see that this invention offers other clear advantages. As well as providing perfect control of the times when bytes of the ATR message are triggered, we have seen that the interrupts can be triggered by a module present in some smartcards, i. e. a programmable clock, thereby reducing the cost of implementing the method of the invention according to the first mode of realisation. A second example of realisation has also shown that the notion of interrupt can be avoided by creating a software agent external to the operating system. The advantage provided by this software is that, after activation by the operating system, it manages not only the triggering of byte transmission but also transmission of the bytes.

Moreover, this invention offers other non negligible advantages.

By fully controlling the triggering times, control is also provided of the global duration required for transmission of all bytes in the ATR message. Through the method of the invention, the global duration required to transmit the ATR message is controlled and can therefore be modulated, so that the end of transmission of the ATR message can be synchronised with the time when the operating system is ready to receive an APDU command from the reader.