Browse Prior Art Database

Caching and Replaying of Responses to Speed up Smart card Communication

IP.com Disclosure Number: IPCOM000005053D
Original Publication Date: 2001-Aug-01
Included in the Prior Art Database: 2001-Aug-01
Document File: 5 page(s) / 64K

Publishing Venue

Motorola

Related People

Colin Gould: AUTHOR [+2]

Abstract

This document explains an algorithm implemented in a smart card driver software which speeds up communication with a smart card when a number of commands in certain patterns are sent to that smart card.

This text was extracted from a Microsoft Word 97 document.
This is the abbreviated version, containing approximately 43% of the total text.

Caching and Replaying of Responses to Speed up Smart card Communication

Colin Gould, Morris Bahrami

ABSTRACT

This document explains an algorithm implemented in a smart card driver software which speeds up communication with a smart card when a number of commands in certain patterns are sent to that smart card.

BACKGROUND

In some smart card enabled devices such as GSM mobile phones, read or update of data in the smart card usually happens in a predefined set of commands. The response from the smart card would be the same and can be known to the smart card driver. A substantial saving in time can be gained by storing the response from the smart card to the commands in such predefined patterns and replaying them later when commands matching that pattern are requested to be sent to the card.

DESCRIPTION

An algorithm called "cache_or_replay" implemented as part of smart card driver, looks at the incoming messages requested to be sent to the smart card and detects certain patterns. It then sends those commands to the smart card and records the smart card's response to those commands. The next time a command belonging to that same pattern is sent to the smart card driver to be sent to the smart card, the smart card driver only replays the smart card response and does not actually send that command to the smart card. This can substantially speed up communication with a smart card especially if the smart card is slow in response.

An example of a set of commands sent to a smart card in a predefined pattern is when a GSM phone tries to read the phone book entries from its SIM card. An application may send commands such as:

SELECT (particular DF)

SELECT (particular EF)

GET RESPONSE

READ/UPDATE (record)

Only the fourth command in the above example (READ/UPDATE (record)) changes because of reference to different records. By recording the smart card response to the first three commands listed as an example above, the smart card driver will only replay the smart card response whenever the same SELECT DF (dedicated File) command is sent to it. Likewise if after selection of that DF the next command sent to the smart card driver is the a SELECT for the same EF (Elementary File), the smart card driver only replays the smart card response. This process is repeated for GET RESPONSE command as well. The only command in this example which is sent to the smart card is the last READ or UPDATE command.

If at anytime a command is sent to the smart card driver which does not match the pattern, or stored command, the algorithm restarts its search for a new pattern and forwards any stored commands to the SIM to ensure the SIM and higher layer applications remain synchronised.

For a smart card with a slow response time this can lead to a substantial performance increase. For instance, a phone book update that previously took 6 minutes took only 1 minute after applying the above algorithm. method.

DESCRIPTION OF THE PROCEDURE IN PESUDO-CODE

The following pseudo-code shows the sequence of operat...