Smart card apparatus and method of programming same

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

The present invention relates to a smart card apparatus and a method for programming the same. More particularly, the present invention relates to a smart card apparatus and method for programming same with an open architecture approach.

Substantially flat, thin plastic articles such as credit cards, bank cards, driver licenses, membership cards, etc., are currently in widespread use. Recently, manufacturers of these cards have provided such cards with their own microcomputer. Such cards are commonly being referred to as smart cards. The potential uses for such smart cards are tremendous. For example, a smart card might contain a person's entire medical history, financial information, etc. In addition, such cards might be used to automatically debit one's bank account when purchasing items such as groceries, clothes, etc. In view of the large potential use of the smart card, a smart card and method for programming the same is required which will allow rapid mass production and personalization of such smart cards. Moreover, there is a need for a smart card wherein the data may be readily stored, altered, retrieved, and protected. In addition, there is a need for a smart card which can be readily adapted to different applications as they arise. Also, there is a need for a smart card which is very secure and resistant to tampering. The present invention solves this problem and many other problems associated with smart cards.

SUMMARY OF THE INVENTION

The present invention relates to a smart card apparatus including a microcomputer. The microcomputer is programmed to include a smart card control program. In addition, the microcomputer is programmed to include a data dictionary and personalized, user data.

The present invention also relates to a method of making a smart card as described above. The method includes the steps of programming the microcomputer with the smart card control program. Programming a data dictionary for defining the data, security and feature requirements of the smart card control program. Programming the microcomputer with application specific data and personalized user data.

The present invention provides a smart card that can be treated similar to a disk device wherein data may be stored, altered, retrieved and protected. The application developer (card issuer) defines the data environment as part of the application development and this definition resides in the smart card as a data dictionary along with the associated data elements. The present invention provides a smart card whose data can be accessed and used much in the same way that a disk based filing system is used.

Additionally, the present invention provides a generic smart card and associated utilities and development tools to the application community to assist in development of smart card application. The tools will be in the form of standard message formats and protocols to address the smart card. The message formats and protocols will preferably be ISO compatible.

The present invention provides a generic smart card apparatus which will be cheaper overall since there is one standard product.

Additionally, the present invention avoids the need for special masks which will result in better response time from suppliers of the microcomputer.

Yet another advantage of the present invention is that the time and cost of programming an application is reduced and therefore will facilitate use of smart card apparatus.

In a preferred embodiment of the present invention, the use of electrically erasable programmable read only memory (EEPROM) will enhance the logical lifespan of smart card apparatus by reusing memory resources.

Yet another advantage of the EEPROM embodiment of the present invention is that the EEPROM will allow modification of smart card apparatus in a much cheaper and faster manner than with EPROM based products, although EPROM might be used in certain applications.

Yet another advantage is that there is less risk in application development by the card issuer because the technical functions are already included. Moreover, this translates into reduced development time and cost.

Still another advantage of the present invention is its transparency to the actual microcomputer features. The microcomputer can be changed and such change will be transparent to the user. As prices and features change this is important since microcomputer products are quickly outdated.

A particularly advantageous feature of the present invention is that it enables the rapid, mass production of smart card apparatus. The microcomputers can be programmed with the smart card program prior to being associated with the smart card apparatus. Subsequently, the smart card apparatus can then be programmed for the particular application and programmed with personalized user data.

Another particular advantage of the present invention is the open ended architecture approach of the present invention which makes the smart card apparatus of the present invention very flexible and adaptable to different applications. The present invention utilizes predefined interfacing rules and a data dictionary which facilitates the open ended nature of the present invention.

Additionally, the present invention provides a smart card with increased security. Varying levels of security can be readily built into the smart card; for example, certain fields of data might be required to match; i.e., PIN number, or the smart card will be deactivated.

These and various other advantages and features of novelty which characterize the invention are pointed out with particularity in the claims annexed hereto and forming a part hereof. However, for a better understanding of the invention, its advantages, and objects obtained by its use, reference should be made to the drawings which form a further part hereof and to the accompanying descriptive matter, in which there is illustrated and described a preferred embodiment of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, in which like reference numerals and letters indicate corresponding parts throughout the several views,

FIG. 1 is a diagrammatic top plan view of a smart card apparatus in accordance with the principles of the present invention;

FIG. 2 i a view similar to that of FIG. 1 with a portion of the smart card apparatus broken away so as to disclose the microcomputer and its interconnection to exposed contacts;

FIG. 3 is a diagrammatic view illustrating the general arrangement of microprocessor memory in accordance with the principles of the present invention; and

FIG. 4 diagrammatically illustrates an arrangement for programming of the microprocessor and memory in accordance with the principles of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Diagrammatically illustrated in FIG. 1 is an embodiment of a smart card apparatus in accordance with the principles of the present invention, the smart card being generally referred to by the reference numeral 20. In the embodiment illustrated, the smart card includes an encoded magnetic strip 22. Exposed are eight contacts 31-38 which enable access to a microcomputer 40 embedded in the smart card 20 on a support media 42. This is more clearly illustrated in FIG. 2 wherein a portion of the smart card has been broken away so as to illustrate the interconnections between the contacts 31-38 and the microcomputer 40. In the embodiment shown, the microcomputer is enclosed by a layer 44 so as to provide protection therefore. As illustrated, the smart card 20 might have written indicia 46 on the surface thereof; for example, the user's name and address.

An example of a microcomputer which might be utilized is the Motorola MC68HC805C4, a CMOS chip with approximately 4K EEPROM memory, 172 bytes of RAM, a timer, and a serial port (UART) through which all communication with the smart card reader will take place. CMOS and EEPROM are chosen for the preferred embodiment for a variety of reasons, most primarily are their adaptability to the concepts of the present invention and the extended life of the smart card.

The microcomputer 40 is programmed with a smart card control program 50, a data dictionary 52 which defines the data, security and feature requirements of the smart card program 50 and the particular application and personalized data.

The smart card program 50 and the microprocessor 40 follow the International Standard Organization (ISO standards; i.e. (ISO/TC 97/SC 17/WG 4N97 electronic signals and exchange protocalls, ISO/TC 97/SC 17/WG N166 dimension and location of contacts, and ISO/TC 97/SC 17/WG N105 physical characteristics).

The external card contacts 31-38 follow the ISO standards. The contexts are defined as follows: 31=VCC circuit supply voltage. 32=RST reset signal. 33=CLK clock signal. 34=RFU reserved. 35=GND ground. 36=VPP programming voltage. 37=I/O data I/O. 38=RFU reserved.

The EEPROM memory is divided into two zones referred to as Zone A and Zone B. Zone A will be used for volatile data storage such as transaction data 56 and Zone B will be used for code, data dictionary and storage of nonvolatile data. Data fields in Zone A of the preferred embodiment are stored in memory, from the low address to the high address and are formatted as data, field ID and length. (In this application, volatile data includes data subject to change when the smart card is in use.)

Data=Data value of field, trailing spaces truncated.

Field=The field identifiers defined in the data dictionary.

Length=The length of the field.

A data dictionary 52 is used to define the data stored in the smart card memory to the smart card program. The data dictionary defines for each data element how the data element is structured and if it is volatile or nonvolatile. This data will include both system data relating to manufacture of the card, application data relating to the specific smart card application; and personalized data relating to the end user of the smart card. The data dictionary 52 thus serves a template for the data stored in each smart card. This information is then included in each smart card that is created. The data dictionary will include a fixed portion 52a defined at the time the smart card control program 50 is programmed and a variable portion 52b containing definations of personalized data used in each application which will be defined when the smart card is personalized. The fixed portion, including both system and application data definitions, of the data dictionary might be defined as follows:

______________________________________ USAGE SOURCE ______________________________________ Total size of dictionary/ System data Card Provider Code Application Application Code (internal) Application Application Code (ISO message) Application Internal Security Code System Manufacturing Batch Application Card Manufacture Date System Extended Commands (Y or N) Application Watchdog for dictionary System DCC application verification Application Unused Application Threshold of consecutive bad commands or field identifiers Action taken on threshold Application (I=Ignore, S=Sleep, K-Erase card) Number of variable fields in System dictionary Watchdog for personalization System ______________________________________

The application specific portion of the data dictionary will include definition of personalized data fields such as user data 54 and will be defined as follows:

______________________________________ USAGE ______________________________________ Data Field ID (x`00`-x`FE`) Length of Field Data Attribute (Volatile/non-volatile/match) Reader Permissions (2 types) Writer Permissions (2 types, ignored if non-volatile) ______________________________________

(It will be appreciated that the data dictionary may taken on varying contents and structure and still be in keeping with the principles of the present invention.)

Memory is reserved for the data defined by data dictionary when the microcomputer is programmed with the smart card control program 50. Moreover, the structure of the data dictionary will be predefined and the smart card program 50 will know the location of each of the elements of the data dictionary. A utility program, which might be used in a personal computer or other terminal, is used by the application user to interface with the smart card control program and define the data dictionary for personalized and application specific data and write the system data, application data, and personalized user data into the microcomputer memory. The utility program will include the data dictionary template and will query the user to define the application data of the fixed portion and the personalized data of the variable portion. Once the user has accomplished this at a personal computer terminal, the smart card can be personalized by writing the user data 54 to the smart card.

It will be appreciated that the above description is of a preferred embodiment and that alternate embodiments may take on different configurations in keeping with the principles of the present invention.

The smart card control program 50 performs command processing, service routines such as memory management, I/O driver, and specialized code for handling miscellaneous commands from the programming equipment of the application user. The smart card control program will contain logic to load/reload cards so as to allow refreshing or updating of a smart card. This will enable new code, and new data to be introduced to a previously used smart card as a command, rather than through various boot strap procedures as is done at initial load time. Communication with the smart card program will be accomplished by predefined interfacing rules.

Service functions are those routines which address diagnostic and technical issues rather than the execution of specific commands; for example,

1. INITIALIZATION

The initialization process is invoked at power up or following a Reset. The functions performed are:

initialize hardware states

check if "BOOT2" present (live vs personalized)

if "BOOT2" present do card personalization

check watchdogs for card validity

find the next volatile write location in Zone A.

find the end of the non-volatile data in Zone B.

2. SECURITY VALIDATION

If application security verification has been activated for this application it is done immediately after the initialization. This involves putting the I/O into read status, accepting the verification message and validating against the values in the Data Dictionary. The values are returned as in the data portion of the "V" recorded. If successful the terminal type is saved for field verification. Also a message is returned to the application as a positive response to the security validation. If there is a `Match` field defined in the dictionary this fields data must be included as additional information is the verification record and is compared with the data in the card. If there is no match a bad status is returned to the application.

3. DICTIONARY SEARCH

From the field identifier in the message locate the field in the dictionary and stash the address for further usage (save the index value).

4. MEMORY SEARCH

The memory search will be supplied with a field ID and a command (next, most recent etc.). If application validation is active the field security is checked to determine if the user may access the field. With the supplied arguments memory will be searched for the data field and the data placed into the RAM buffer in the data portion of the buffer area. If data is not found a status message is stored in buffer area.

On the first request of a field the dictionary is inspected to determine whether the field is volatile or non-volatile and the address generated will be either the address of the next available byte minus one in Zone A, or the end of the Zone B personalized data.

On multiple requests of a field the address will be that of the last occurrence accessed minus one.

A block move routine is used to move the data to the buffer from the address of the located data field.

When the last field of the supplied ID has been found, and a next read command is issued, the status message is stored in the buffer area.

5. WRITE TO MEMORY

The Data Dictionary attributes are checked to ascertain that the field is not a non-volatile field, and if the application validation is specified that the user may write this data. Having done the validations the routine will write the data portion of the RAM buffer into the EEPROM volatile memory and update address pointers to the next available area to write. Appended to the data will be the field identifier and length.

7. MEMORY REFRESH

Memory Refresh is part of the `reorg` of the card at the time the card is approaching full. A `reorg` command from the appropriate terminal will cause the data Zone A to be erased.

The actual erase is a routine which is furnished zone id and may also be used to intentionally destroy the card on request.

In use, predefined commands are passed from the application terminal such as an automatic teller terminal (ATM) and are requests for some form of action. The commands fall into several major categories:

Application: Those which are issued by the application for a file request. Normally an ASCII alphabetic value.

System: Proprietary commands used to perform diagnostic functions.

Response: A card response back to the application conveying a status or acknowledgment. Normally ASCII numeric.

Reader: These commands instruct the device reading/writing to the smart card. These commands are ignored by the smart card.

Sample commands are:

______________________________________ R Read applic. Reads the most recent field value from the card to the application. W Write applic. Writes the data for the spe- cified into memory from the application. M Memory applic. a request for amount of remaining memory in Zone A. This is returned as a two byte data value in the data portion of the record in hex format. N read Next applic. reads the next oldest occurrence of a field from the card to the application (First command gets the most recent, subsequent commands get next oldest, etc. The requests must be contiguous on a request for another field terminates the sequence). V validate applic. This command request contains the necessary security data to identify the reader and appli- cation to the card (required if application verification is set). D destroy applic. The application requests the total destruction of the card. The data portion contains the application and the Card Provider code. These must match the data dictionary values before this is allowed to happen. C clear applic. arbitrarily clear Zone A. Follows same rules as `D`, used as step in reorganizing a full card. S stop applic. orderly stop, required for bat- tery powered products. l status applic. a response to the application from the card on an exception. The data portion of the mesaage will have the status returned. Examples are card full, field not found, I/O error, or an 'OK' acknowledgment. P program reader turns on programming voltage if applicable. L lock door reader locks door on reader to keep card. U unlock reader unlocks the door. Z reset reader issue a hardware reset. x`EO` set mode system a preliminary command required to set system mode. No other system commands can be recognized unless sytem mode