EP1019801A4

EP1019801A4 - Smartcard terminal

Info

Publication number: EP1019801A4
Application number: EP98946168A
Authority: EP
Inventors: Simon Buchwald
Original assignee: Individual
Current assignee: Individual
Priority date: 1997-10-03
Filing date: 1998-10-02
Publication date: 2000-12-20
Also published as: EP1019801A1; WO1999018494A1

Abstract

This invention concerns a smartcard terminal, that is a device that is able to read information from a smartcard and write information to a smartcard. The terminal includes a smartcard reader and a data assembly and transmissions means to receive position data from a computer display pointing device having a serial communications capability, and from the smartcard reader. The data assembly and transmission means is able to transmit position information from the pointing device, and smartcard information from the smartcard reader to an associated computer, and to receive information which is to be written to the smartcard from the computer. The data assembly and transmission means assemble position information and smartcard information into separate frames before transmitting them serially, and it labels each frame depending on whether it contains position information or smartcard information. A smartcard terminal is typically provided as a peripheral for a computer, such as a personal computer, a workstation, a network server or a network computer.

Description

SMARTCARD TERMINAL Technical Field

This invention concerns a smartcard terminal, that is a device that is able to read information from a smartcard and write information to a smartcard. A smartcard terminal is typically provided as a peripheral for a computer, such as a personal computer, a workstation, a network server or a network computer.

Background Art For many years communication with a smartcard has involved the use of standalone smartcard terminal devices. The smartcard terminal devices have been used to write information to smartcards and to read information from smartcards. The terminal devices have been connected to computer terminals, and more recently to personal computers, by the standard serial communications port using the standard RS232 interface. The devices have been powered separately by means of a discrete power supply.

Recently smartcard terminals have been integrated into computer keyboards. In one variant the existing legacy keyboard interface remains, and the bidirectional smartcard information is communicated between the keyboard and the computer by an additional standard serial communications port using the standard RS232 interface. There are generally only two serial ports on a personal computer. The first serial port is usually dedicated to a mouse or trackball, and the second to a modem. Consequently in order to connect such a smartcard terminal a third serial port must be added. In an alternative, the bidirectional smartcard information is communicated using new commands which have been added to the existing half duplex legacy keyboard interface. However, in this variant while bidirectional smartcard transactions are in progress, keyboard strokes may be ignored. Summary of the Invention

The invention is a smartcard terminal including a smartcard reader and a data assembly and transmission means to receive position data from a computer display pointing device having a serial communications capability, and from the smartcard reader. The data assembly and transmission means is able to transmit position information from the pointing device, and smartcard information from the smartcard reader to an associated computer, and to receive information which is to be written to the smartcard from the computer. The data assembly and transmission means assembles position information and smartcard information into separate frames before transmitting them serially, and it labels each frame depending on whether it contains position information or smartcard information.

In one embodiment the smartcard reader and the data assembly and transmission means are housed together in a housing which includes a serial data port to receive the position data.

The smartcard terminal may include a housing that houses both the smartcard reader and the computer display pointing device. In this case the only port required on the terminal is the port required for communication with the computer. In this way the invention may provide a solution to the many users who may wish to use a smartcard in conjunction with a computer without requiring an additional serial port, and without compromising the functionality of the keyboard.

Such use may include offline and online access control, offline and online smartcard initialisation, online authentication, online certification, online end to end public and private key encryption, online bidirectional non- financial transactions, online bidirectional financial transactions, including purchase transactions, and withdrawals which reload an electronic purse on the smartcard for later offline payments. The terminal may be capable of communicating with many smartcards at the same time by being equipped with several smartcard readers which are accessed through respective slots in the housing.

The smartcard terminal may include a keypad for keypad information entry, in which case the data assembly and transmission means may assemble the position information, the smartcard information and any keypad information into separate frames before transmitting them serially

The terminal may incorporate a mouse, but it could also incorporate a trackball, joystick, any other pointing device, a secure PINpad capability, an insecure keypad capability or a modem. The terminal may be in a notebook computer specifically integrated with an electronic stylus pointing device.

The terminal may be used with a personal computer, but it could also be used with a workstation, a network server, a network computer or a computer terminal. The terminal may employ a cable to communicate with the computer, and the cable could also supply power to the smartcard reader. The cable could also replaced by an optical transport medium or a radio frequency transport medium.

The communications means may assemble the information into frames which start with a start of text character (STX) to identify the start of the frame. The next byte following the start of frame character may be a Protocol Control Byte (PCB). If the PCB is any other than an X-Y position code, for instance code 0x7F and or below, then the next bytes following are the data length characters (LEN). The data length characters specify the length of the subsequent information bytes. After receiving the LEN characters the personal computer waits to receive the subsequent bytes until the number of bytes received equals to the number of information bytes specified in the LEN byte plus 2 bytes (ETX and BCC). The format is shown in the following Table:

The following definitions apply:

The Protocol Control Byte in the frames between the terminal and the computer contains a one byte value chosen from those available shown in the following table:

The information block in the frame may contain the terminal current status, data from the smartcard, secure keypad, keypad or X-Y position information.

Brief Description of the Drawings

An example of the invention will now be described with reference to the accompanying drawings, in which:

Figure 1 is a pictorial view of a smartcard terminal. Figure 2 is a pictorial view of the underside of the terminal of Figure 1. And

Figure 3 is a schematic diagram of an alternative terminal. The same reference numerals have been used throughout the drawings to refer to corresponding features.

Best Modes for Carrying out the Invention

The integrated smartcard terminal device 1 has an external plastics casing 2 shaped like a mouse with two buttons 3 and 4 on the top and a roller ball 5 underneath. An horizontal slot 6 along the front can receive a smartcard.

The roller ball 5 engages two roller bearings with optical shaft encoders and an opposing spring loaded roller bearing. The shaft encoders are orthogonal to each other perpendicular in the same plane to record movement of the roller ball in conventional mouse fashion.

Within the device 1 there are also conventional smartcard reading and writing heads 7 together with associated circuitry. The information being read from the smartcard is transmitted to a personal computer together with X-Y position input control information along a cable 8. Information to be written to the smartcard is also transmitted back along the same cable 8.

A bicolour, red and green, LED 9 is provided for indicating the logical status of the smartcard interface of the terminal device 1.

A keypad 10 is positioned in the underside of the casing 2 to enable key entry. A thumbscanner 11 is also incorporated into the side of the housing to verify the identity of the user.

A bidirectional communications transport protocol is duplicated at either end of the cable, both in the terminal device 1 and at the device driver level of the personal computer (not shown).

The core of the bidirectional communications transport protocol comprises of a set of control commands. By use of the control commands the terminal device is capable of reading from a smartcard, writing to a smartcard and providing X-Y position input control information to the personal computer.

The communications protocol is defined in two sections. The first section consists of frame level processing between the personal computer (PC) and the terminal device 1 (TERMINAL). The second section comprises application messages transmitted between the TERMINAL and the PC.

Message frames can originate at either the PC or the TERMINAL. Message frames originating from the PC are either D-frames (data frames), or L- frames (link control frames). Message frames originating from the TERMINAL are either D-frames (data frames), N-frames (negative acknowledgment frames), E-frames (event frames) or M- frames (mouse event frames). All message frames originating from the PC are acknowledged by the TERMINAL with a corresponding message frame. All frames start with a start of text character (STX) to identify the start of the frame. Any other characters received by the terminal device 1 are ignored and are flushed from the receive buffer. The next byte following the start of text character is the Protocol Control Byte (PCB). The following bytes are the data length characters (LEN). The data length characters specify the length of the subsequent information bytes. After receiving the LEN bytes the terminal device waits to receive the subsequent bytes until the number of bytes received is equal to the number of information bytes specified in the LEN byte plus 2 bytes (ETX and BCC). All message frames originating at either device (except for M-frames) contain a block checksum. A message sequence is included in D-frames . The format is shown in the following Table 1:

Table 1.

The Protocol Control Byte in the frames between the terminal and the computer contains a one byte value chosen from those available shown in Table 2

Table 2 D-frames

D-frames are data frames and are sent in both directions between the PC and the TERMINAL. D-frames sent by the PC to the TERMINAL contain commands. The command code and any relevant data is contained within the I-block. A D-frame sent by the TERMINAL to the PC is always in direct response to a PC to TERMINAL D-frame. The TERMINAL never sends unsolicited D-frames. The I-block of D-frames sent by the TERMINAL contains the response code and any relevant data.

The s bit is the message sequence number as shown in the following table, and the value of this bit sent for a particular D-frame is equal to the current message sequence number as maintained internally by the sender's data link software. This internal message sequence number is set to 0 on protocol initialisation. This sequence number is incremented module 2 on receipt of a D-frame with a sequence number equal to the current internal sequence number. For every D-frame received, the sequence number bit in the PCB byte is compared against the receiver's internally maintained sequence number. If the sequence numbers are the same, the D-frame is considered valid and processed by the receiver. Also, the receiver's internally maintained sequence number is incremented module 2.

L-frames

L-frames are link control frames used by the data link layer for managing the communications link between the PC and TERMINAL. At present there is a single L-frame command defined:

N-frames

N-frames are negative acknowledgment frames or NAK frames, signalling a negative acknowledgment of a received frame. The TERMINAL sends this frame after receiving an invalid frame (incomplete or bad checksum) from the PC. The LEN for such frames is 0.

E-frames

E-frames are frames containing event messages from the TERMINAL. The I-block consists of a type byte and any relevant data. M-frames

M-frames are event frames and are sent by the TERMINAL when it detects a change in the state of its buttons or when sufficient X-Y movement has occurred. M-frames are the only frames not to conform to the frame structure above. Each M-frame is a fixed 4 bytes in length, and has the following format:

D-Frame Command Full Functional Definitions

GetDeviceCharacteristics

This command queries the TERMINAL for device. This enables the PC to query for such parameters as the TERMINAL serial number and default ICC clock rate. Command Format:

Command Description:

Response Format:

I-block

ResultCode Data

Response Description:

GetlCCState

This command queries the TERMINAL for the ICC. This enables the PC to query for such parameters as card presence and the last ATR string. Command Format:

I-block

Command Tag Command Description:

Response Format:

I-block

ResultCode Data

Response Description:

GetProtocolState

This command queries the TERMINAL for current protocol This enables the PC to query for such parameters as the current IFSC and IFSD. Command Format:

I-block

Command Tag Command Description:

Response Format:

I-block

ResultCode Data

Response Description:

SetProtocolState

This command is used to set protocol parameters used in the TERMINAL'S interaction with the smartcard. This enables the PC to change such parameters as the current IFSD. Command Format:

I-block

Command Tag Data

Command Description:

Response Format:

I-block

ResultCode

Response Description:

SetTerminalMode

This command may be used to set the mode of the integrated smartcard terminal device. The integrated smartcard terminal device may operate in either standard mode, or full-integrated smartcard terminal device mode. This command may also set a new communications baud rate. Command Format:

I-block

Command Mode Baudrate

Command Description:

Response Format:

I-block

ResultCode

Response Description:

DefineCardType

This command may be used to set the integrated smartcard terminal device to operate on a specific smartcard type. By default, an asynchronous card type is selected. Command Format:

I-block

Command CardType

Command Description:

Response Format:

I-block

ResultCode

Response Description:

EnableSmartcardPort

All commands received by the TERMINAL are either port specific or non-port specific.

This command enables one of the smartcard ports on the TERMINAL. For all commands received after this command that are port specific, the TERMINAL will interact with the smartcard in the port specified by this command. On reset, smartcard port 0 is enabled.

Command Format:

I-block

Command Port

Command Description:

Response Format:

I-block

ResultCode

Response Description:

PowerOnlCC

This command powers on and resets the card in the currently selected smartcard port. The reset function is described in ResetlCC. Command Format:

I-block

Command Command Description:

Response Format:

I-block

ResultCode ICCType CurrentProtocolType ATRString

Response Description:

ResetlCC

This command resets the card in the currently selected smartcard port. Command Format:

I-block

Command

Command Description:

Response Format:

I-block

ResultCode [ICCType CurrentProtocolType ATRString]

Response Description:

The following data items are only present if ResultCode is RESULT_SUCCESS:

PowerOfflCC

This command will power off the card in the currently selected smartcard port. It is good practice to always power off the card before removing it from the TERMINAL device. Command Format:

I-block

Command

Command Description:

Response Format:

I-block

ResultCode

Response Description:

ISOInput

On receipt of this command, the TERMINAL sends a command to the inserted smartcard together with any optional data. The TERMINAL does not expect any data to be returned from the card except for the two ME result bytes for async cards. This command can be used for synchronous cards and T=0 asynchronous cards. Use the ISOTl command for T=l asynchronous cards. Command Format:

I-block

Command Class Instruction Pi P2 Length Data

Command Description:

Response Format:

I-block

ResultCode [MEl ME2]

Response Description:

The following data items are only present if ResultCode is RESULT SUCCESS:

ISOOutput

On receipt of this command, the TERMINAL sends a command to the inserted smartcard and reads back the resulting data from the card. This command can be used for synchronous cards and T=0 asynchronous cards. Use the ISOTl command for T= l asynchronous cards. Command Format:

I-block

Command Class Instruction Pi P2 Length

Command Description:

Response Format:

I-block

ResultCode [[Data] MEl ME2]

Response Description:

The following data item is only present if ResultCode is RESULT SUCCESS:

The following data items are only present if ResultCode is RESULT SUCCESS or RESULT DATA NOT AVAILABLE:

ISOTl

On receipt of this command, the TERMINAL sends a command to the inserted smartcard together with any optional data using the T=l protocol. The TERMINAL reads the response from the card, which may include data. Due to the nature of the T=l protocol, it is not necessary to distinguish between data going to the card or data coming out of the card. The protocol is capable of handling data in either or both directions in the same command cycle. This command can only be used for asynchronous cards using the T= l asynchronous protocol. Use the ISOInput/ISOOutput commands for all other cards. Command Format:

I-block

Command TlData

Command Description:

Response Format:

I-block

ResultCode [TlData]

Response Description:

The following data item is only present if ResultCode is RESULT SUCCESS:

L-Frame Command Full Functional Definitions

For such commands, the LEN is 2 and the I-block is Command I-block format:

I-block

Major Minor

Data Description:

Response I-block format:

I-block

Major Minor

Data Description:

E-Frame Command Full Functional Definitions

All application layer event notifications sent by the TERMINAL to the PC are placed within E-frames. These are frames that are unsolicited by the PC, and are sent by the TERMINAL when certain events occur. The format of the I- block of each E-frame is:

This section defines each event notification.

Smartcard Insertion

This event occurs when the TERMINAL detects a smartcard insertion into the specified smartcard port. Event format:

Data Description:

Smartcard Removal This event occurs when the TERMINAL detects a smartcard removal from the specified smartcard port. Event format:

Data Description:

M-Frame Command Full Functional Definitions

The following definitions apply:

Where:

L-BTN The current state of the left mouse button, 1 = pressed

R-BTN The current state of the right mouse button, 1 = pressed x X7... XO; 8 bit signed number reflecting the mouse movement along the horizontal axis since the last M-frame. The positive X axis is to the right

Y7... YO; 8 bit signed number reflecting the mouse movement along the vertical axis since the last M-frame. The positive Y axis is upwards

The personal computer arbitrates, at the device driver level, between the reception of the X-Y position input control information and the smartcard information which is transmitted from the terminal device, and the smartcard information which is received by the terminal device. The arbitration ensures correct extraction of the relevant information and correct passing of the information to the appropriate higher level.

The key mechanism which enables the device driver of the personal computer to extract the relevant information from the terminal device communications protocol is the addition of a distinct per frame slave command field. This mechanism allows the device driver of the personal computer to distinguish between commands which are intended for a higher level smartcard application, or commands which are intended to control the X- Y position of the cursor of the personal computer.

For example Table 5 below shows an example of a method by which the personal computer arbitrates messages between smartcard terminal commands and X-Y position information commands. If the command is less than a certain value, then the command is a smartcard terminal command. If the command is greater than or equal to a certain value, then the command is an X-Y position information command.

Table 5.

Power is provided to the terminal device by utilising the existing power supplies of the personal computer. The source of power for the terminal device is the keyboard port of the personal computer. A special cable is used that routes the raw keyboard power source, to be then stepped down, and back up to power the smartcards. Although the invention has been described with reference to a preferred embodiment it should be appreciated that it could be embodied in other forms. For instance, the terminal device may be capable of communicating with many smartcards at the same time by being equipped with several smartcard readers which are accessed through respective slots in the housing.^" The mouse may also include a biometric sensor, such as a thumbscanner, built into the side of the housing.

The invention has been described with reference to a mouse, but it could also be incorporated in a trackball, joystick or any other pointing device. The invention has been described with reference to a personal computer, but it could also be used with a workstation, a network server, a network computer or a computer terminal. The cable could also replaced by an optical transport medium or a radio frequency transport medium. It is also envisaged that the terminal could be constructed without the mouse (or other pointing device) being integrated into the same housing as the remainder of the terminal. This arrangement will allow the terminal to be retrofitted to existing systems at lower cost. The arrangement is shown in Figure 3. In Figure 3 the integrated smartcard terminal device 12 comprises an external plastics casing 2. An horizontal slot 6 along the front can receive a smartcard. A socket 13 will accept a plug from a standard mouse.

Within the device 12 there are also conventional smartcard reading and writing heads (not shown) together with associated circuitry. The information being read from the smartcard is transmitted to a personal computer together with X-Y position input control information along a cable 8. Information to be written to the smartcard is also transmitted back along the same cable 8.

The device 12 has a keypad 10 which may include a standard keyscanning mechanism or a secure keyscanning mechanism. A bicolour, red and green, LED 9 is provided for indicating the logical status of the smartcard interface of the terminal device 12.

A bidirectional communications transport protocol is duplicated at either end of the cable 8, both in the terminal device 12 and at the device driver level of the personal computer (not shown).

In addition the example arbitration mechanism described is not necessarily the only way to arbitrate the signals, and they could for instance be arbitrated by having a code allocated to them.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

1. A smartcard terminal, including: a smartcard reader; and a data assembly and transmission means to receive position data from a computer display pointing device having a serial communications capability and from the smartcard reader, and to transmit position information from the pointing device, and smartcard information from the smartcard reader to an associated computer, and to receive information which is to be written to the smartcard from the computer; wherein the data assembly and transmission means assembles the position information and the smartcard information into separate frames before transmitting them serially, and it labels each frame depending on whether it contains position information or smartcard information.

2. A smartcard terminal according to claim 1, wherein the smartcard reader and the data assembly and transmission means are housed together in a housing which includes a serial data port to receive the position data.

3. A smartcard terminal according to claim 1, wherein the terminal includes a housing that houses both the smartcard reader and the computer display pointing device.

4. A smartcard terminal according to any preceding claim, when used for offline and online access control, offline and online smartcard initialisation, online authentication, online certification, online end to end public and private key encryption, online bidirectional transactions, including purchase transactions and withdrawals which reload an electronic purse on the smartcard for later offline payments.

5. A smartcard terminal according to any preceding claim, able to communicate with many smartcards at the same time by being equipped with several smartcard readers.

6. A smartcard terminal according to any preceding claim 1, that includes keypad for keypad information entry, and wherein the data assembly and transmission means assembles the position information, the smartcard information and any keypad information into separate frames before transmitting them serially

7. A smartcard terminal according to claim 3, wherein the terminal incorporates a mouse.

8. A smartcard terminal according to any preceding claim, wherein the terminal is used with a personal computer.

9. A smartcard terminal according to any preceding claim, wherein the terminal employs a cable to communicate with the computer.

10. A smartcard terminal according to any preceding claim, wherein the communications means assembles the information into frames which start with a start of text character (STX) to identify the start of the frame.

11. A smartcard terminal according to claim 10, wherein the next byte following the start of frame character is a protocol control byte (PCB).

12. A smartcard terminal according to claim 11, wherein if the protocol control byte (PCB) is any other than an X-Y position then the next byte following is a data length character (LEN) which specifies the length of the subsequent information bytes.

13. A smartcard terminal according to claim 12, wherein the format is shown in the following Table:

The following definitions apply: