Method and system to interpret and manage different smart card data architectures

As smart cards and related advanced tokens are introduced into the mainstream the lack of data architecture standards significantly limit interoperability between similar systems. This problem is compounded at the application level where it is almost impossible to read and interpret data from a smart card that has been created and issued by an unrelated source. The organization of data elements and corresponding security on a smart card is typically dictated by an application. This invention discloses a system for describing these application specific characteristics in a portable mapping file called an application template. This application template describes the structure, security, and encoding of the data on a smart card. In a similar manner, the process of formatting smart cards is made easier as multiple data models can be managed through the use of these application templates. Consider the problem that there are several approved data models for encoding cardholder information to a federal government employee ID smart card. In particular, the CAC structure is used primarily by the Department of Defense and the J8/GSA structure is preferred by most other federal government agencies. This invention would enable any federal government employee ID smart card to be read at any federal government location.

The present invention will become more fully understood from the detailed description given below. 
 DETAILED DESCRIPTION OF THE INVENTION This invention discloses a data mapping process and the corresponding system to manage smart card data architectures according to this mapping. The data mapping process will generate an application template 100 which describes what data elements are present on the card, where they are located, who owns the rights to each data element, what security provisions may be in place, and other attributes about specific encoding techniques. For each possible card layout a different application template must be generated. These application templates exist as data files external to the card. At a minimum, each application template has the following sections: &lsqb;Root Description&rsqb; Identifies the contents of the root level files 110 . &lsqb;Data Files&rsqb; This section identifies each of the card files that may contain cardholder information 130 . File size and associated security conditions are also detailed. The specific format for each data file is: AbbreviatedName(nnn)&equals;FamiliarName, FileID, Length, SecurityAccessForRead, SecurityAccessForWrite &lsqb;File nnn&rsqb; There will be a separate section for each card file identified in the Data Files section. Within each of these sections the precise organization of the data 160 is described through a TLV format. The specific format for each data element is: FamiliarName, TagIdentifier, DataType, Length By way of example a complete application template is illustrated in FIG. 2 . With this as a guide, cardholder demographic information such as name, address, phone number and other pertinent data can be extracted from any card for which a mapped application template has been created. Even existing smart card programs can make use of these application templates. An application plug-in module 300 will form the software bridge between a smart card application and the many possible smart card data formats. This module will exist as a library of compiled code with published functions that can be called from a higher level application. First, this module will establish a card and reader context 310 and then obtain some general information from the card 320 . The module will then attempt to recognize the type of card and encoding style using pattern matching against the known application templates 330 . Once the module has determined the correct match then the entire data mapping can be processed 340 . Existing programs will need to be changed only slightly in order to work with this plug-in module. New or revised card types can now be supported by simply distributing the new corresponding application template file. A code library for card formatting 400 can easily create any card structure for which there exists an application template 410 . First the basic card structure 430 is burned to the chip, followed by the security scheme 440 . Finally, the data elements are written 450 to the just created structure. By way of specific example consider that the federal government has endorsed at least two different data layout systems for smart cards. These are the CAC and GSA/J8. The disclosed invention requires that an application template mapping be created for each. These application templates are then distributed along with the a plug-in module to all smart card programs. In this manner, any federal government smart card ID (whether CAC or J8) will work at any federal government location. Even network-based programs can benefit. In a web form fill screen, cardholder information is read from a smart card and is used, in turn, to populate a survey form. By integrating the described plug-in module and application templates, any known smart card could be used to seamlessly populate the demographic data requested by the form.