GB2351379A - Smart card with business partner scheme or travel application - Google Patents

Abstract

A smart card comprises a common application, e.g. a cardholder identification application 404, 406, and at least one second application concerned with a travel related and/or business partnering scheme application. Preferably, the second application is either a payment system 408, with stored account number and expiry date (Figure 6), an airline flight and ticket application 410, a hotel reservation application 412, or a hire car application 414 having details of the card holder's preferred car (Figure 8). Preferably all of the business partners involved in the partnering scheme have access to the common application, containing the card holder name and address (Figure 5), but each business partner can only utilise the second application with which it is associated, e.g. a hotel chain may only access the hotel reservation application. Other cardholder details may also be stored on the smart card, e.g. insurance, biometrics data, driving licence, passport, and social security. A business partnering organisation (Figure 10), having a partnering organisation server and a transmission network (19, Figure 10), for use with the smart card are also disclosed.

Description

2351379 Smart Card with Business Partner Scheme or Travel Applications The

present invention relates generally to the use of integrated circuit cards, or "smartcards", for commercial transactions and, more particularly, to methods and apparatus for conveniently storing, retrieving, and updating data related to a cardholder's travel information in the context of a distributed transaction system.

Despite advances in information technology and process streamlining with respect to travel arrangements, the modem traveller is often subjected to unnecessary delays, petty inconveniences, and oppressive paperwork. These travel burdens are most evident in the airline, hotel, and rental car industries, where arranging and paying for services and accommodations can involve significant time delays due to miscommunication, poor recordkeeping, and a host of other administrative inefficiencies.

Smartcard technology, as described below, has had limited success in addressing some of these problems. The term "smartcard" refers generally to wallet-sized or smaller cards incorporating a microprocessor or microcontroller to store and manage data within the card. More complex than magnetic-stripe and stored-value cards, smartcards are characterized by sophisticated memory management and security features. A typical smartcard includes a microcontroller embedded within the card plastic which is electrically connected to an array of external contacts provided on the card exterior. A smartcard microcontroller generally includes an electrically-erasable and programmable read only memory (EEPROM) for storing user data, random access memory (RAM) for scratch storage, and read only memory (ROM) for storing the card operating system. Relatively simple microcontrollers are adequate to control these functions. Thus, it is not unusual for smartcards to utilize 8-bit, 5 MHZ microcontrollers with about 8K of EEPROM memory (for example, the Motorola 6805 or Intel 8051 microcontrollers).

A number of standards have been developed to address general aspects of integrated circuit cards, e.g. ISO 7816-1, Part 1: Physical characteristics (1987); ISO 7816-2, Part 2: DimensionT and location of the contacts (1988); ISO 7816- 3, Pori 3., Electronic signals and transmission protocols (1989, Arrid. 1 1992, Amd. 2 1994); ISO 78164, Part 4: Inter-induytry commondsfor interchange (1995); ISO 7816-5. Port 5:

Ali4mbering -ysiem and registration procedurefor application identifiers (1994, A md. I 1995); 1SO11E C DIS 7816-6, Inier-industry data elements ( 1995); 1SOI]EC HID 7816- 7, Part 7: Enhanced inier-industry commands (1995); and IS011EC WD 7816-8, Pori 8:

Inter-industry security architecture (1995). These standards are hereby incorporated by reference. Furthermore, general information regarding magnetic stripe cards and chip cards can be found in a number of standard texts, e.g., Zoreda & Oton, SMART CARDS (1994), and Rank] & Effing, SMART CARD HANDBOOK (1997), the contents of which are hereby incorporated by reference.

Various attempts have been made to alleviate travel-related inconveniences through the use of smartcard technology. In 1995, for example, the U.S. airline industry led an effort to reduce ticket distribution costs by developing standards for "ticketless travel."

Soon thereafter, a joint conference of IATA and ATA adopted a set of specifications entitled Specificotionsfor Airline Industry Integrated Circuit Cords (hereinafter, "IATA standard'. Similarly, in the field of financial payment systems, a standard has been developed entitled EW Version 2.0, Integrated Circuit Card Specificationsfor Payment

Systems, Parts 1-3 (1995). Both of these specifications are hereby incorporated by reference.

Notwithstanding widespread promulgation of these standards, smartcard efforts tend to remain fragmented, and the resultant benefit to consumers - particularly consumers who travel - has been quite Triinimal. One recent study estimates that approximately nine million smaricards were issued in the transportation and travel industry in 1996, yet, for the most part, these cards remain incompatible; that is, due to differing file structures and/or communication protocols employed, card data typically can not easily be shared across applications or between industry panicipants.

Systems and methods 'are therefore needed in order to overcome these and other shortcomings in the prior art.

2 The present invention provides methods and apparatus for a smartcard system which securely and conveniently integrates important travel-related applications, thereby overcoming the limitations of the prior art. In accordance with one aspect of the present invention, a smartcard system comprises a cardholder identification application and various additional applications useful in particular travel contexts; for example, airline, hotel, rental car, and payment-related applications. In accordance with another aspect of the present invention, a SMar1C3rd system further comprises space and security features within specific applications xvhich provide partnering organizations the ability to construct custom and secure file structures.

The present invention Nvill hereinafter be described in conjunction with the appended drawing z figures,,vherein like n0merals denote like elements, and:

Figure I illustrates an exemplary smaricard apparatus; Figure 2 is a schematic diagram of an exemplary smartcard integrated circuit, 0 C, showing various functional blocks; Figure 3 is an examplant diagram of files and directories arranged in a typical tree structure; Figure 4 sets forth an e\emplary database structure in accordance with a preferred embodiment of the present invention; Figure 5 sets forth a preferred cardholder ID data structure in accordance with the present invention; Figure 6 sets forth a preferred payment system data structure in accordance with the present invention; Figure 7 sets forth a preferred airline data structure in accordance with the present invention; Figure 8 sets forth a preferred rental car data structure in accordance with the present invention; Figure 9 sets forth a preferred hotel system data structure in accordance with the present invention; and 3 Figure 10 illusirates '111 eNeMplary disiribUted transaction system useful ill practicina the present invention.

Referring now to Figures 1 and 2, an e%emplary smartcard systern suitable I-or practicing the present invention will now be described. A smartcard 100 generally compnses a card body 102 having a communication region 104 for providing contact or non-contacl communication bemeeii all external device (e.g., a card reader) and an integrated circuit I 10 encapsulated within card body 102. Communication region 104 preferably comprises six conductive pids 106 whose placement and size conform to IS07816-2. More particularlly, a cammunication region 104 in conformance with ISO 7816-2 preferably comprises VCC contrict 106(a) (power supply), RST contact 106(b) (reset), CLK contact 106(c) (external clock), GND Contact 106(d) (ground), VPP contact 106(e) (programming voltage), and 1/0 contact 106(f) (data line).

VCC 106(a) suitably provides power 10 IC I 10 (typically 5.0 V +/- 10%). CLK 106(c) is suitably used to provide an external clock source which acts as a data transmission reference. RST 106(b) is suitably used to transmit a reset signal to IC I 10 during the booling sequence. VPP contact 106(e) may be used for programming of EEPROm 212 in IC I 10. As is known in the art, however, this'contact is generally not used since modem lCs typically incorporate a charge pump suitable for EEPROM programming which takes its power from the supply voltage (VCC 106(a)). 1/0 106(0 suitably provides a line for serial data communication with an external device, and GND 106(d) is suitably used to provide a ground refeience. Encapsulated integrated circuit is configured to communicate electrically with contacts 106 via any number of known packaging techniques, including, for example, thermosonically- bonded gold wires, tape automated bonding (TAB), and the like.

While an exemplary smartcard is discussed above in the context of a plurality of external contacts, it vAll be appreciated that contactless cards may also be utilized to practice this invention. That is, non-contact communication methods may be employed using such techniques as capacitive coupling, inductive coupling, and the like. As is known in the art, capacitive coupling involves incorporating capacitive plates into the card body such that data transfer with a card reader is provided through symmetric pairs 4 ' Of COUIDled surfaces. Nvhercin cipacitance V.11LIeS ire typically 10-50 picofarads, and the vvorkinL, range is typically less than one millimeter. Inductive coupling employs coupling elements, or conduciive loops, disposed in a weakly-coupled transformer configuration employing phase, frequency. or implitude modulation. In this regard, it will be appreciated that the location of communication region 104 disposed on or within card may vary depending on card configuration. For additional information regarding non-conlact techniques, see, for example, contactless card standards I SOAEC 10536 and ISO/JEC 14443, which are hereby incorporated by reference.

Smaricard body 102 is preferibly manufactured from a sufficiently rigid material \vhich is resistant to various environmental factors, e.g., physical deterioration, thermal extremes, and ESD (electrostatic discharge). Materials suitable in the context of the present invention include, for example, PVC (polyvinyl chloride), ABS (acrylonitrile butacliene-slyrol), PET (polyethylene terephihalate), or the like. In a preferred embodiment, chip card 100 conforms to the mechanical requirements set forth in ISO 7810, 7813, and 7816. Body 102 may comprise a variety of shapes, for example, the rectangular ID-1, ID-00. or ID-000 dimensions set forth in ISO-7810. In a preferred embodiment, body 102 is roughly the size and shape of a common credit card and substantially conforms to the ID-1 specification.

Referring now to Figure 2, IC 110 preferably comprises regions for Random Access Memory (RAM) 216, Read-Only Memory (ROM) 214, Central Processing Unit (CPU) 202. data bus 210, Input/Output (1/0) 208 and Electfically-Erasable and Pro-,rarnmable Read Only Memonp (EEPROM) 212.

RAM 216 comprises volatile memory which is used by the card pfimarily for scratch memory, e.g., to store intermediate calculation results and data encryption processes. RAM 216 preferably comprises at least 256 bytes.

EEPROM 212 provides a non-volatile memory region which is erasable and revnitable electrically, and which is used to store, inter alia, user data, system data and application files. In the context of the present invention, EEPROM 212 is suitably used to store a plurality of files related to cardholder travel information (discussed in greater ses; at least detail b10'w in conjunction with Figure 3). EEPROM 212 preferably compri 8K bytes.

I n a prefierred embodiment- CPU 202 implements the instniction set stored in ROM 202, handles mernor), management (i.e., RAM 216 and EEPROM 212), and coordinates input/output activities (i.e., 1/0 208), ROM 214 preferably contains, or is "masked" with, the smart card operating system (SCOS). That is, the SCOS is preferably implemented as hard-wired logic in ROM 2 14 using standard mask design and serniconductor processing methods well known in the art (e.p _ photolithography, diffusion, oxidation, ion implantation, etc.).

Accordingly, ROM 2 14 cannot generally be altered afier fabrication. The purpose of such an implementation is to take advantage of the fast access times provided by masked ROMs. ROM 214 suitably comprises about 4K-20K bytes of memory, preferably at least 16K bytes. In this regard, it will be appreciated that alternate memory devices may be used in place of ROM 214. 1 ndeed, as semiconductor technology progresses, it may be advantageous to employ more compact forms of memory, for "ample, flash- EEPROMs.

The SCOS controls information flow to and from the card, and more particularly facilitates storage and retrieval of data stored within EEPROM 212. As with any operating system, the SCOS operates according to a well-defined command set. In 1his regard, a variety of known smart card operating systems ate suitable for the purpose of this invention, for example, IBM's Multi-Function Card (MFC) Operating System 3).5 1.

the specification of which is hereby incorporated by reference. While the IBM MFC operating system employs the standard tree structure of files and directories substantially in accordance with IS078164 (as detailed below), it will be appreciated by those skilled in the arl that wher operating system models would be equally suitable for implementation of the present invention. Moreover, it may be advantageous to allow certain aspects of operating sys(em functionality to exist outside the card, i.e., in the form 2 of blocks of executable code which can be downloaded and executed by the smaricard during a transaction (for example, Java applets, ActiveX objects, and the like).

Given the general characteristics of smaricard 100 as outlined above, it Mll be apparent that a wide range of microcontrollers and contact-based smaricard products known in the art may be used to implement various embodiments of the present jo invention. Suitable smartcards include, for example, the model ST16SF48 card, manufactured by SGS-Thomson Microelectronics, which incorporates a Motorola 6805 MiCTOContTOller with 16K ROM, 8K EEPROM, and 384 bytes of RAM. It will be 6 appreciated, however. that particular embodiments of the present invention might require I-norc advanced microcontrollers with greater EEPROM capacity (i.e., In tile range of about 12-1 6K). Such systems are well known in the art.

Having thus described ail exemplar), smartcard 100 and IC I 10, an overview ofa smaricard file strucitire in accordance with the present invention will now be described.

Referring now to Figure 4, file structure 400 is preferably used to store information b related to card-holder preferences and various data useful for securing and paying for air travel, rental cars, hotel reservations and the like. More particularly, file structure 400 preferably comprises cardholder ID application 406, payment system application 408, air-line application 4 10. hotel system application 412, rental car application 414, and cardholder verification data 404. It will be appreciated by those skilled in the art that the term "application" in this context refers to self-contained regions ofdata all directed at a particular function (e.g., airline, hotel, etc.) rather than a block of executable software code, although the use of executable modules as part of any particular application falls within the scope of the present invention.

Cardholder verification data 404 preferably houses data useful in verifying cardholder identity during a transaction. In a preferred embodiment, cardholdeT verification data 404 comprises two eight-byte cardholder verification numbers (i.e., PIN numbers) referred to as CHV I and CHV2.

CardholdeT ID application 406 suitably compfises various files related to personal information of the cardho)der (e.g., name, addresses, payment cards, driver's license, personal preferences and the like). Cardholder ID application 406 is described in greater detail below in conjunction with Figur.e 5.

Payment system application 408 suitably comprises informition useful in effecting commercial transactions, e.g., account number and expiration date information traditionally stored on a magnetic-stripe credit card. Alternatively, Payment system application 408 comprises a full EMV-compliant application suitable for a wide range of financial transactions. Payment system application 408 is described further'below in conjunction with Figure 6.

Airline application 4 10 suitably comprises data helpful in streamlin"ing commercial airline travel; for example, relevant personal preferences, electronic tickets, and frequent 7 flier information. Airline applicillo:1 410 Is dISCLIssed in -rcater detail be-low ill conjunction with Figure 7.

Hotel application 4 12 sultabiv comprises information useful for securing and paying for hotel reservations, Including;in 3rr3y of Information and preferences r - associated wilh a list of' preferred hotels as ivell space for electronic keys. Hotel application 412 is discussed in greater detail below in conjunction with Figure 9.

Rental car application 414 suitably comprises data useful in expediting tile process of car rental and return, including, for example, car preference and frequent rental b information. Rental car application 414 is described in further detail below in conjunction with Figure S.

in each of tile above mentioned applications, sophisficafed access and encryption schemes are preferably utilized in order to allow multiple parties to make use of certain file structures while preventing unauthorized entry into others. More specifically, pannering organizations (e.g., hotel chains, airlines, and rental car agencies) may create their own tailor-made file structures (i.e., "partner file siructures' within card 100.

Details of the various security measures employed are described in further detail below in conjunc(ion with Table 40.

Referring now to Figure 10, smancard 100 is suitably used in the context of a 0 distributed transaction system. Briefly. cardholder's may employ smancard 100 at various access points 15 which are connected via network 19 to an issuer 10 and at least one parinering organizanon 12. Issuer 10 suitably comprises various hardware and C sofiware components suitable for client host communications as well as a database -n issuer' refers to the organization that actually issues system I.L In this context, the ten I b the smartcard and retains some high-level access to certain areas of file structure 400 (detailed below).

Partnering organizations 12(a), 12(b), and so on, comprise the various hotel chains, rental-car agencies, airlines, and the like, who have access to appropriate data regions wi thin smaTicaTd 100. Each partnering organization 12 suitably comprises a database 13 and appropriate hardware and software components necessary for completing a transaction over network 19. Network 19 may comprise one or more comniunication modes, e.g., the public switched telephone network (PSTN), the Internet, digitW and analog wireless networks, and the like.

8 Iach access point 15 suitably comprises an appropriate card reader for interfacin-, with smaricard 100 as weil as hirdware and software suitable for interfaciri2 with a cardholder and perforniing a trinsiction over network 19. Access points 15 are preferably located in areas providing convcnient access for traveling cardholder-s or cardholder's preparing travel arrangernerils. Such access points 15 may be located. for example, in airline ticketing and ple areas, rental car facilities, hotel lobbies. travel agencies, and stand-alone kiosks in malls. In addition, businesses might see fit to host an access point to strearriline their employees' btisiness travel. Furthermore, all individual cardholder might configure his or her personal computer to act as an access point using 2PPTOpriate I o soffivare and peripheral hardware.

In a preferred embodiment of the present invention-, data files and directories are stored in i "trec" stnicturc as illusuved in Figure 3. That is. the smaricard file structure resembles the %veil known MS-DOS (Microsoft Disk Operating System) file structure wherein files are logically organized within a hierarchy of directories. Specifically, three types of files are defined in ISO 7816-4: dedicated files (DF), elementary files (EF), and a master file (Mr-). The master file is analogous to the MS-DOS "root" directory, and contains till other files and directories. Dedicated files are actually directories or "folders" for holding other DFs or EFs. Tlius, MF _302 may contain an arbitrary number of DFs 306, and these DFs (e.g., DF ')06(a)) may or may not contain other DFs (e. g., DF 308).

Elementary files are used to store user data, and may exist within a dedicated file (e.g., EF'I 0 within DF 306(a)), or within the master file (e.g., EF304 within MF 302). Higher level DFs (i.e., DFs: which house particular applications) are often referred to as application dedicated files (ADFs).

The MF and each of the DFs and EFs are assigned a unique two-byte file identifier (FJD). By convention,.the MF is traditionally assigned an FID of ")FOO'hex. Selection of an EF or DF by the operating system may then be peiformed by tracing its entire path starting at the MF. Thus, if the MF contains a DF with a FID 'A 100', and this DF in turn contains an EF with a FID 'A101', then this EF could be referenced absolutely by successive selection of FIDs V00,A100, and AJOL It will be appreciated that the FID n is essentially a file name used by the operating system to select directories and files; it is not intended lo indicate a physical address within EEPROM 212. As will be 9 appreciatcd by those skilled in the art. low-level EEPROM addressing is preferably handled by the SCOS in con. Junction with CPU 202.

Each file prefcrably hasanassociated Jile header containing various indicia of the panicular E-F. DF, or MF'. More particularly, the file lic3der associated with a particular J.1le preferably includes the file identifier (FID), file size, access conditions, and file structure. In this re-ard, sniaricard 100 suitably employs one of four file structures: transparent, linear fixed. linear variable. or cyclic. For the sake completeness, the nature of these file structures will be briefly reviewed.

A transparent file structure consists of a string of bytes accessed by specif,ing an V offset and byte count. I-or example. Nvith reference to Table I below, given a n-byte string of data, bytes 7 through 10 would be accessed usinn an offset of six and a length C> of four.

Table 1: Transparent file structure A linear fixed file structure comprises a plurality of records of equal length (e.g., a list of phone numbers), wherein access to an individual record is achieved through reference to a record number. In addition. it is possible to refer to the 'next' or 'previous' record relative to the 'current' record (i.e., the most recently accessed record). In contrast, a linear variable file structure comprises records of arbitrary but known length, and is therefore typically more compact than linear fixed data structures.

A cyclic file structure is a type of linew fixed file wherein a pointer is used to point to the last data set written to. After the last data record is written to, the pointer returns to the first record. That is, a cyclic file comprises a series of records arranged in a 'ring'.

A data structure particularly important with regard to storing records as well as secure messaging in smancard applications is the BER tag-length-value or "TLV" structure in accordance with ISOAEC 8825, hereby incorporated by reference. In a TLV ob-ccl, Information regarding the ty-pe and length of the information is included along with the actual data. Thus. a TLIV ob C.>I Ject comprises a tao which identifies the type of data (as called out by the appropriate specification), a length field which indicates the length in bvies ofthe data to follow, and a value field, which comprises the primary data. For example, the TLV object illustrated in Table 2 below encodes the text phoenix", which has a length of 7 bytes, and corresponds to a the "city" tag of 'SC' hex (a hypothetical tag designation).

C Too eng1h Value d 1 07' p h o C _n 8C, TA13LE 2: Exemplary primitive TLV object it will be appreciated that the meaning of the various tag values must be known to the system o priori. That is, in order for the tag field to be useful, the smartcard and any external systems communicating with the smaricard must conform to the same tag specification. In this regard, ISO/IEC 7816-6 defines a series of tags useful in the context of the present invention, as does the IBM MFC 3.2 specification. ISO/IEC 8825 sets forth the basic encoding rules for a TLV system and defines a "template" data object which can be used as a container for multiple TLV objects. That is, it is often advantageous to encapsulate primitive TLV objects within a larger template which is itself a TLV object.

Referring now to Figure 4, a preferred smancard date structure in accordance with the present invention will now be described in detail. Data structure 400 preferably comprises a MF 402 and five DFs: Cardbolder ID application 406, Payment system application 408, Airline application 410, Hotel application 412, and Rental car application 414.

in the detailed description to follow, various acronyms and abbreviations will be used to refer to particular data types, formats, and The like. A key to these acronyms and abbreviations is presented in Table 3 below.

AN Alphanumeric N Numeric B. Boolean C Convention M Matrix D Data AR Bits array BIN Binary RJ Right-justified U Left-justified BCD Binary coded decimal TABLE 3: Key to acronyms In the discussion that follows, the various features of a preferred data structure are in some cases described using particular file structure types (i.e., transparent, fixed, etc.). Those skilled in the art will realize, however, that any of the common smartcard file structure types are typically suitable for implementing any particular data structure. For example, when a file structure is described as including "a plurality of records," it will be understood that such a structure may be designed, for example, using a list of records assembled in a linear fixed file wherein each record is itself a transparent file (and offset values correspond to the various fields). Alternatively, such a structure may be designed using TLV strings assembled in a linear fixed file or C within a larger template TLV. This is the case notwithstanding the fact that particular tag values -- which are for the most part arbitrary are not explicitly listed in the tables t hat follow.

Cardholder ID Application Referring now to Figure 5, Cardholder ID applicai.ion 406 is used to store various information related to the cardholder. Portions of this information are freely available to the partnering, organizations, thereby preventing the storage of redundant information.

More particularly, cardholder ID application 406 preferably comprises directory EF 532, holder-ID DF 502 and miscellaneous DF 530. Holder-ID DF 502 preferably comprises ID EF 504, home EF 506, business EF 508, preferences EF 514, passport EF 516, authentication EF 520, biometric EF 522, and driver EF 518. Miscellaneous EF 530 preferably comprises payment card EF 5 10, sequence EF 512, issuance EF 5 11, prefen-ed 12 programs EF 528, and card number EF 526. These filcs and their respective functions are discussed in detail below.

Directory EF 532 providesa list of application identifiers and labels for tile various hwh-level DFs existing under cardholder ID application 406. That is, this file serves the function of a high-level director\, listing which specifies tile location (i.c., FID) and application label for each DF -- in this case, holder-ID DF 502 and miscellaneous DF 5' W. In a parlicularly preferred embodiment, directory EF 5')2 is structured in accordance with EMV 3.0 as shown in Table 4 below. Preferably, each major application (e.g., hotel, airline, etc.) has an associated directory file with a substantially same file structure.

Record descril)(ion I-xicriml Format Internal fo rina Oyles) Size Type Size Type Application ID for holder-ID DF 16 AN 16 ASCII Application label 16 AN 16 ASCII Application ID for miscellaneous DF 16 AN 16 ASCII L Application label 16 AN 16 ASCII Table 4: Exemplar), cardholder ID directory EF ID E-F 504 preferably inchides personal inforniation related to the cardholder, e.g., name, date of binh, emergency contact, ceneral preferences, and the like. In a panicularly preferred embodiment, member EF 504 comprises the fields set forth in Table 5 below.

Italicized field names indicate a subcategory within a particular field. Record description External formal Internal formal(bytes)

Size Type' Size Type Last Name 30 AN 30 ASCII First Name 20 AN 20 ASCII Middle Name 8 AN 8 ASCII Honorary Title 8 AN 8 ASCII NameSuffix 4 AN 4 ASCII Date of Birth 8 D 4 BCD I J c AN 10 ASCII S c lSocill Security Nmlibcr 10 C Erricrgency Contici c E n C Lost Name 120 AN 20 ASCII IV e I I s First Nome /0 AN 10 ASCII r-Vt 7 Relolion C BIA1 Phone 120 A, /0 BCD Gender I AN I ASCII e Special Personal Requirements 12 AN 12 M Language Preference (ISO 639) 2 C 2 ASCII Ta ble 5: Exciliplary I D EF data structure In the above table, and ffic tables to follow, both internal and external data formats are listed. As the conservation of EEPROM space is of paramount importance, the "internal" formal of data (i.e., within EEPROM 212) may be different from the "external" format of the data (i.e., as read by the card reader at an access point 15). Thus, for example, a date field might consist of a fOUT-byle

BCD record within the card, but upon reading and processing by the terminal, this data might be converted to an eight-byte decimal value for more convenient processing.

Home EF 506 preferably includes data related to one or more of the cardholder's home addresses. In a particularly preferred embodiment, home EF 506 cornpriising the fields set forth in Table 6 below. The personal travel charge account pointer is preferably used to designate a preferred payment card, and consists of a number corresponding to one of the payment card records within payment card EF 10 (detailed below).

Record description External formal Internal formal(bytes)

Size Type Size Type Jqome Address 1 40 AN 40 ASCII - home Address 2 40 AN 40 ASCII lJorne AddrM City 25 AN 25 ASCII 1 14 Home Address Stile 5 AN 5 ASCII Home Country (ISO 3166) 2 AN 2 ASCII Home Address Zip Code 10 AN 10 ASCII Home Address Telephone 20 N 10 BCD Hoine Address FAX 20 N 10 BCD Home E-mail address 40 AN 40 ASCII Personal travel charge account number 2 N I BCD pointer Table 6: ExcmPlary home EF file structure Business EF 508 prefcrably includes v3rious data related to the cardholder's business (i.e., addresses, phone numbers, and the like). In a particularly preferred embodiment, business EF 508 comprising the fields set forth in Table 7 below. In this regard, the credit card pointer field is preferably used to point to a payment card record within payment card EF 510 (detailed below). The cost center, dept., division, and employee ID fields are ernployer-specific, and may or may not apply in a given c2SC.

Record descriPliOn Exiernal formal Internal fortna(ftles) Size Type Size Type Business Address 1 40 AN 40 ACSII Business Address 2 40 AN 40 ASCII Business Address City 25 AN 25 ASCII Business Address State 5 AN 5 ASCII Business Country (ISO 3 166) 2 AN 2 ASCII Business Address Zip Code 10 AN 10 ASCII Business Telephone No. 20 N 10 BCD Business Address Fax 20 N 10 BCD Business E-mail Address 40 AN 40 ASCII professioral Title 10 AN 10 ASCII Employee ID 10 AN 10 ASCII )i"'i n 20 AN 20 ASCII De 20 AN 20 ASCII Dept pi Cost Center 12 AN 12 ASCII EDivision 2 N 2 BCD Professional travel account number I I pointer Professional license data 20 N 20 ASCII [Credit Card pointer 2 N I Company Narne 1A A 1, %, 20 Table 7: Exemplar), business EF file structure Preferences EF 514 preferably comprises data related to the cardholder's default personal preferences. In a particularly preferred embodiment, preferences EF 514 includes a field comprising an array of preferences as set forth in Table 8 below. Preference values are PTCferablY chosen from a list of preference tags as set forth in Table 39. 15

Record description ENternal formal Internal formal(byles)

Size ype Size Type Preferences Array 20 C 20 C Table 8: Ex3mplary preferences EF file structure Passport EF 516 is preferably used to store cardholder passport information.

In a particularly preferred embodiment, passport EF 516 comprises the fields set forth in T2ble 9 below.

Record description External formal -lnttrnal format(byles) -

Size Type Size Type Passport Number 20 AN 20 ASCII.

passport Country - ISO 3166 2 AN 2 ASCII issuance Date- 8 D 4 BCD 16 City of issuance 0 AN 20 A N Expiration Date 8 D 4 BCD I'able 9: Examplary passport EF file structure Driver EF 516 preferably comprises cardholder driver license data. In a particularly preferred embodiment, driver EF 518 comprising the fields set forth in

Table 10 below.

Record dcscriplion ExIcrnal forina( Internal format(bytes) Size Type Size Type Driver's License No. 20 a 20 ASCII FDriver's License Issuing Staie/Country 2 a 2 BCD License Expiration Date 8 D 4 ASCII LLic T 2 C 4 BCD icense Type Table 10: Exemplary driver EF file structure Biornetric EF 522 is used to store biometric data (preferably encod ed) such as fingerprint data, retina scan data, or any other sufficiently unique indicia the cardholder's physical or behavioral characteristics. In a particularly preferred embodiment, biometric EF 522 comprises a single data strin- as set forth in Table n below.

Record description External forM2t Internal format (bytes)

Size Type size Type 1 Biornetrics template 100 AN 100 BIN I Table 11: Exemplary biometric EF file structure Authentication EF 520 preferably comprises information for static authentication of the cardholder ID 406 application. This data is unique for each 17 card, ind is sufficlently comple.\ such that counterfelt values cannot feasibly bc created. This prevents creation of "new" counterfeit cards (i. e., cards VAth new authentication data), but does not prevent creation of multiple copies of the current card- In a particularly preferred embodiment, authentication EF 520 includes public key certificate fields as shown in Table 12 below, wherein the external formal is identical to the internal format. Preferably, the issuer RSA key is 640 bits long, and the CA key is 768 bits long.

C Record description Internal forinat(bytes)

I Size Type Signed Static Applicniion Data 80 B Z, Static Data Authentication Tog List 16 B Issuer Public Key Certificate 96 B Issuer public Key Exponent I B Issuer Public Key Remainder 20 B Table 12: Exemplary authentication EF Turning now to files under miscellaneous DF 5.3 W, preferred programs EF 528 preferably comprises data related to the cardholder's preferences as to airline companies, hotels, and rental car agencies. Specifically, this EF, in a particularly preferred embodiment, comprises a plurality of records (e.g., three) indicating preferred companies for each type of travel panner as shown in Table 13. The actual data values conform to an arbitrary convention; that is, each airline, hotel, and rental car agency is assigned an arbitrary three-byte code.

Record description External format Internal format(bytes)

Size Type Size Type Preferred Airlines 9 (30) C 9 C Preferred Hotels 9 C 9 C Prefemd Rental Cars 9 C 9 - C is Ta ble 13: ExemplM proggrams EF Payment card EF 5 10 is preferably used to catalog information related to the cardholder's various payment cards. i.e., debit cards. charge cards, and the like. In a particularly preferred embodiment. payment card EF comprises card numbers and expiration dates for two cards as shown in Table 14. The "ISO" and "non- ISO" designations refer to ISO-78 13, which specifies a pardCUlar'payment card number formal. Thus, in a prefer-red embodiment, either an ISO or non-ISO card number scheme may be used. Moreover, it will be appreciated that this data set is sufficient only for "card not present" transaclions, for example, transactions taking place remotely where only the card number and expiration date are required to effect a transaction. Data stored within payment system application 408 (described below) must be used to effect a "card present" transaction.

Reco'rddcscription External formal Internal format(bytes) sc' Size Type Size Type irsi Payment Card # (ISO) 19 N 10 BCD Fi'st Paym First Payment Card Expiration Dale 8 D 4 BCD Second Payment Card # (non-ISO) 20 AN 20 ASCII Second Payment Card Expiration Date 8 D 4 BCD Table 14: Exemplary payment card EF file structure Sequence EF 512 preferably includes information used to provide synchroni7lition of the host and smaricard databases. In a particularly preferred embodiment, sequence EF 512 comprises a plurality of records comprising the field set forlb in Table 15 below. This number is analogous to a "version" number for the data stored in the application.

Record description External format Internal format(bytes)

I Size -FT;;- size 19 Scqucncc Number 16 16 ASCII I AN. I Table IS: Exemplan, sequence EF file stnicture I Card number EF 526 is used to record a unique number identifying the sninricard, and may also be used for key derivation (as described in funher detail below). Preferably, card number EF 526 comprises a eight-byte string as set forth in Table 16 below.

11ccord description External formal Internal formw(byles)

Size Type Size Type Cird Number 3 H X 8 HEX Table 16: Exemplary card number EF Issuance EF 5 11 is used to record various details related to the manner in which the application (i.e., cardholder ID DF 406) was created. This file includes information related to the identhy of the organ-zation that created the application, as well as information related to the application itself. In a partic.ularly preferred embodiment, issuance EF 511 comprises fields as set forth in Table 17 below.

Field External formal Internal format (bytes)

Size Type Size Type Country Authority IS03166 2 Issuer Authority to RID ISO 5 HEX 7816-5 Application vasion 5 XX.YY 2 BCD Application expiration dote 8 YYYYMM 4 BCD DD Application effective date 8 YYYYMM 4 BCD DD Personal izer Code I AN ASCII Personalization Location I AN I ASCII Table 17: Exemplary issuance EF file structure The personalizer code field shown in TAble 17 refers to the organintion that actually "Persona I izes" the file. That is, before a smartcard may be issued to the cardholder, the database structure must be created within EEPROM 212 (Figure 2), and the initial data values (i.e., dcfault preferences, cardholder name, pin numbers, etc.) must be Iaced in the appropfiate fields within the various

EFs. it will be appreciated that, given the nature of the present invention, the SManC2Td "issuer" and "personal izer" for any given application may not be the same. Therefore. it is advantageous to record various details of the per.sonaliz.qtion process within smaricard 100 itself. Similar issuance file structures may be provided for the other major applications.

Payment Syslem Application Referring now to Figure 6, payment system application 408 preferably comprises a directory EF 610, issuer DF 602, and a number of optional DFs 6033(a) (n) for use by partnering financial organizations.

Directory EF 610 preferably includes a list of application identifiers and labels as described above in the context of cardholder ID application 406.

Issuer DF 602 Comprises pay] Dr- 604, which includes data that would traditionally be siored within tracks on a magnetic stripe card (i.e., debit cards, charg e cards, and the like). In a Preferred exemplary embodiment, pay] DF 604 comprises a plurality of records having commonly known magnetic-stripe fields as specified in Table IS below.

Record description External formal Internal format(bytes)

Size Type size Type Fo at Code ( Track I I AN I ASCII 21 2 8 BCDF rack P PAN (Track, 2) 15 AN L E4da T right padding Trac 2 2 BCD Expiration 4date ( Track I or 2 14 YYMM e E n 0 or x P cti(I 2 BCD Effective date ( Track I or 2 14 YYMM c d ack I or2 r v ate Tr fe_ f _ji a r, d' III Track I C 3 BCDF Discretionary data Track I or"2 5 N Discre a on right padding 1 26 ASCII. U I T. L Name Track 1 26 AN blank Tablc 18: Ewniplary Payl EF file structure Airline Application -ReferTing now to Figure 77, airline application 410 preferably comprises directory EF 7")0, common DF 702, and issuer DF 704, and additional airline applications 703(a), 7030), and so on.

Directory EF 730 prefer3bly includes a list of application identifiers and labels as described above in the context of cairdholder ID application 406.

Common DF 702 generally includes data accessible to all participating airlines, while issuer DF 704 generally includes data which can only be read or written to by the smaricard issuer. Airline application 410 preferably further comprises at least one (preferably three) additional DF 703 for use by airline partnering organizations. That is, one airline partner may have access to and specify the structure of data stored within DF 703(a) (as well as common EF 702), while another airline might have similar access to DF 703(b). These partner DFs preferably conform to the relevant portions of the IATA specification.

Common DF 702 suitably comprises common data which would be of use io any of the various partnering airlines. i.e., passenger EF 706, frequent flier EF 708, JET EF 710, boarding EF 712, and biometric EF 714.

22 Issuer DF 704, in conirist, comprises inforniation readable by all-, bUt updatable only by the card issuer, i.e., preferences EF 716. PIN EF 718, and issuance E F 720. ' Referring now to information stored within comnion EF 702, passenger ET 706 preferably cornprises various records related to the passenger as specified in cp Table 19 below.

Record description External formal Internal formal (bytes)

Size Type Size Type Passenger Name 49 AN 49 ASCII Gender I A I BIN Language Preference 2 AN 2 ASCII Unique ID 24 AN 24 ASCII Airline ID (3 letters code) 3 AN 3 ASCII Type code (2 letiers) 2 AN 2 ASCII Unique ID 19 AN 19 Applicalion version 2 N 2 Table 19: Exemplary passenger EF file structure In a particularly preferred embodiment, frequent flyer EF 708 comprises a plurality of frequent flier numbers (e.g., ien numbers) having the structure specified in Table 20 below.

Record description External formal. Internal format (bytes)

Size Type Size Type Airline Customer ID 22 AN 22 ASCII Table 20: Exemplary frequent Oyer EF file structure 2 3 I ET EF 710 prefcrabhl comprises a plurality of electronic ticket records as set forth in Table 21 below The I-bri-nat ofthesc electronic tickets preferably confornis to the IATA Standard.

Description of Me records E-%ternal format Internal formal (bytes)

Size 77- Size Type Type Dc-sc''P' ion JET 1 14 AN 14 BIN IC-T 2 14 AN 14 BIN IET P3 14 AN 14 BIN cr 'd BIN JET 4 14 AN 14 JET 5 14 AN 14 BIN Ta ble 2 1: Exemplary IET file structure In a particularly preferred embodiment, boarding EF 712 comprises boarding data to be used during check in as specified in Table 22. The format of this data ID preferably conforms to the JATA specification.

Record description External formal Internal format (bytes)

Size Type Size Type Boarding data 40 AN 40 ASCII Table 22: Exemplary boarding EF file structure Biornetric EF 714 is suitably used to store biometric data associated with the cardholder, e.g., retina scan data, fingerprint data, or any othcr sufficiently unique indicia of the cardholder's physical or behavioral characteristics. In a particularly preferred embodiment, biometric EF 714 comprises data as specified in Tablic 23 below.

ffRecord description External formal Internal formal (bytes) t Size 24 - I Bionictrics data -T 100 1 AN 1 1001 BIN TabIc 23: Exeniplary biometric EF file structure Issuince EF 720 is suitibly used to hold data related to the issuance of the various applic3lions. hi it p.-irtiCLI]arly preferred embodiment, issuance EF 720 comprises a data structure as specified in Table 24 below.

FFicid External formal Internal forma((bytes) Size Typc size Type Country A ulhority ( 2 Icitcrs IS03166 2 Eic'd 10 RID - ISO 5 HEX Issiter Authority ?8 16-5 Application version 5 XX.YY 2 BCD Application expiration date 8 YYYYMM 4 BCD DD Application effective date 9 YYYYMM 4 BCD DD Persons I izer Codc I AN I ASCII Ir I AN I C11 Personalization LocDlion (custom code) Table 24: Exemplary issuance EF file structure PIN EF 718 is suitably used to store PIN values corresponding to each of the participating airline partners. In a particularly preferred embodiment, PIN EF 718 comprises a plurality of records having the structure specified in Table 25 below, wherein each record is related to the corresponding entry in frequent flyer EF 708 (i.e., record one in EF 718 corresponds to record one in EF 708, and so on.) Record description External format Internal formal (bytes)

Size Type Size Type PIN 8 AN 8 BIN Expiration date 8 D 4 BCD Tnblc 25: Exemplary PIN EF file structure preferences EF 716, In a particularly preferred embodiment, comprises a preferences ar-ray as shown in Table 26 below. The preference values stored in this file correspond to those discussed below in conjunction with Tabic 38.

Table 26: Exemplary preferences EF 716 file structure Rental Car Application Referring now to Figure 8, rental car application 414 preferably comprises common DF 802, directory EF 820, and one or more Tental-car DFs 803 (i.e., 803(a), 803(b), and so on) corresponding to individual rental car agencies.

Common DF comprises preferences EF 805, which is described in detail below. Rental-car DFs 803 each comprise a Tental-car-id EF 807, reservation EF 809, and expenses EF 81 L Directory EF 820 includes a list of application identifiers and labels for the various DFs tinder rental-car application 414. The structure of this EF preferably conforms to that described above in the context of cardholdcr ID application 406.

In a particularly preferred embodiment, preferences EF 805 comprises a set of preferences arrays file structure as shown in Table 27 below. A preferred list of preference codes for use in each of these arrays is described below in conjunction %kith Table 38.

Record description Exiernnl formal Internal format (bytes)

Size Type Size Type Preferences Array 8 C 8 BIN Record description External format internal format( bytes) preferences Array (Default) 8 C 8 BIN Preferences Array (No. 2) 8 C 8 BIN Preferences Array (No. 3) 8 C 8 BIN p refeffed limousine company 12 AN 12 ASCII Table 27: Exemplary prefeTences EF 26 Rental car id S07 is used 10 Store frequent rent3l Infon-nation, uperrade information, insurance information, and the like. In a particularly preferred embodiment, rental-car-id 807 comprises a file structure as shown in Table 28 below.

Record description External formal Internal formal( bytes) on Re 0 rd c5cript ta IV 22 A 22 ASCII Frequent no 3 A 3 ASCII n Company name Unique Customer ID 19 A 19 ASCII s pRentallD# 10 A 10 ASCII i Sc. Pro CDP (Contract Disc. Pro;ram) cram) Accumulated points S N 3 BIN ccum u 'a' po' 's A Rental features AR 2 BIN ire Rental fealt _s C40 I bit 8 or Type Upgrade nedn Week-endlyacotion Spechol B I bit B Guaranteed Late Reaservation B I bit B insurance Array 2 BIN Loss Damage Waiver (LDW) B I bit B 0 Personal Automobile Insurance B I bit B Personal Effects Coverckee B bit B personal Insurance B I bit B corporate Insurance B / bit B Table 28: Exemplary rental_car-id EF Reservation EF 809 is used to store confirmation numbers corresponding to one or more rental car reservations. In a particularly preferred embodiment, reservation EF 809 comprises a plurality of records (e.g., two) having a file s1ruc lure as shown in Tsible 29 below.

Record description External format Internal format( bytes)

Rental Car COMPanY 3 1 A 3 ASCII 27 I-oc3iion 3 A ASCII on I 3 c elm Date 8 D BCD D e a Time 4 T 2 BCD im T Nu A 15 ASCII ti Reservation Number 15 b, c r s [R rva Fli,-ht Number 5 M 5 BIN orn I.., AA-' 3 ASCII(RJ) Airlines 3 Fi v" A' 2 BCD lighl number 4 Ile C ASCII Preferred profile I p of Table 29: Exemplary reservation EF E-xpenscs EF 8 11 is uscd to record expenses incurred by the c3rdholdcr during car rental (e.g., flie toml rental charge). In a particularly preferred embodiment, expenses EF 8 11 comprises a plurality of records (e.g., five) having a file structure as shown in Table 30 below.

Record description External format Internal format( bytes)

Type of expense I C I ASCII Date 8 D 4 BCD Location code 3 AN 3 ASCII Amount 7 N 3 BIN Tnble 30: Exemplary expenses EF Hotel Application Referring now to Figure 9, hotel system application 412 preferably comprises directory EF 920, common DF 914, one or more hotel chain DFs 902, and one or more property DFs 903.

Common DF 914 comprises reservation EF 918, expenses EF 916, key-of the-room EF 910, and preferences EF 912.

28 - Hotel chain Us 902(a), 902(b). and so on, comprise preferences EF 904 and St231eT ID EF 906 associated with individual hotel chains. In contrast, property EFs go-(-,,), 903)(b). and so on, comprise a similar file structure associated with individual holel properties (i.e., independent of whether the particular hotel is a member of a nationwide chain).

In a parilcularly prcferred embodiment, reservation EF 918 comprises a pluralitV of records having the struciure shown in Table 31 below. In general, this EF is used to store confirmation numbers transmitted to smartcard 100 when the cardholder makes 2 reservation at a given hotel (designated in the property code field). The date field stores the date on which the confirmation number was dispensed.

Record description External formal Internal foriniii(bytes)

S ize Type Size Type Property Code 3 AN 3 ASCII Date S D 4 BCD Confirmation Number 15 AN 15 ASCII Table 31: Exemplary Tesei-vation EF Preferences EF 912 preferably comprises three sets of array preferences. The particular codes used in these arrays are discussed below in conjunction with Table 38.

Record description External format Internal formsit(byies)

Size Type Size Type Preferences Array (default) 8 C 8 BIN Preferences Array (number 2) 8 C 8 BIN Preferences Array (number 3) S C 8 BIN Table 32: Exemplary preferences EF 29 Expenses EF 916 preferably comprises a list of recent hotel expenses, for example, room costs, dinner expenses, and the like. In a particularly preferred embodiment, expenses EF 916 comprises a plurality of records (for example, fifieen) arranged in a cyclic file structure and comprising the fields "Shown in Table

33 below. Thus, the cardholder is able to examine and print a list of recently incurred expenses by type (a code fixed by convention), date, amount, and property code.

Rec rd d Internal format(bytts) Record description External formal on size Type Size Type Type I C I ASCII Date 8 D 4 BCD rAmoa AN 3 ASCII PropeM Code 3 r r i 7 N 3 BIN unt Table 33: Exemplary expenses EF Key-of-the-room EF 910 preferably comprises electronic key values that can be used in conjunction vrith card readers to provide access to particular hotel rooms.

In a particularly preferred embodiment, key-of-the-room EF 910 comprises a plurality of alphanumeric key values as shown in Table 34 below.

Record description External format Internal format(bytes)

Size Type Size Type Key value 40 AN 40 BIN Table 34: Exemplary key-of-the-room EF Stayer ID EF 906 preferably comprises frequent stayer data for a particular hotel chain. In a particularly prefen-ed embodiment, Stayer ID EF 906 comprises frequent slayer information as shown in Table 35 below.

Record description Externol form-it Internal formal(byles) Size Type Size Type Frequent stayer number 19 AN 19 ASCII Frequent Stayer Level Code I AN I ASCII Frequent Stayer Level Expiration Date 6 YYYYMM 3 BCD CDP 10 AN 10 ASCI I Event Counter 3 N I BIN Hotel Frequent Stayer PIN 8 AN 8 BIN, Table 35: Exemplary slayer ID EF Preferences EF 904 preferably comprises three sets of array preferences as shown in Table 36. Tle particular codes used in these arrays are discussed below in conjunction with Table 38.

Record description Exiern2l format Internal format(byies)

Size Type Size Type Preferences Array (default) 8 C 8 BIN Preferences Array (number 2) 8 C 8 BIN Preferences Array (number 3) 8 C 8 BIN Table 36: Exemplary prefffences EF Property DFs 903)(a), 903(b), etc., are used in cases where the parinefing hotel is not part of a major chain, or when the hotel chooses to employ its own data set independent of its affiliation. In one embodiment, these property DFs are identical in structure to hotel chain DFs 902, except that much of the frequent stayer ID infon-nation is removed. More specifically, a typical property DF 903 comprises a preferences EF 938 identical to preferences 904 described above, along with a stayer ID EF 934 which includes only the CDP, event counter, and hotel frequent stayer PIN fields described in conjunction with Table 33 above. Alternatively, a

31 particular hotel chain or property might choose to implement a different file structure than that described above.

Preference Co(Jes As mentioned brielly above, a preferred embodiment is configured such that preferences are located in several filcs distributed throughout smartcard 100; i.e., in preferences EF 514, airline preferences EF 716, hotel preferences EF 912 and 904, and car preferences EF 8 10. This allo%%,s apparently conflicting preferences to coexist within the card dcpendint) on context. For example, it is possible to opt for non-smoking in the cardholder ID application while choosing the smoking option within the hotel application. In the case of conflict, preferences are read from the top level to the bottom level, and each level SUPCI'sedes the previous one.

An exemplary set of codification rules are Set forth in Table 37 below:

049 General purpose (Cardholder ID 406) 50-99 Hotel application 412 100-149 Rental car application 414 150-199 Airline application 410 200-255 Other Table 37: Exemplary Preferences Code Ranges More specifically, in a preferred exemplary embodiment, preference flags are coded as set forth in Table 38 below.

Preference Code (decimal) GENERAL PURPOSE Smoking 00 Non-smoking 01 Home as preferred address 02 Work as preferred address 03 Handicapped 04 32 Home as preferred e-mlij address 05 "' 2' pre WWor 06 ork as preferred c-mail address k as pref OTEL PREFERENCES HT Kine-size bed so Queen-size bed 51 Double bed 52 iii-li floor room 53 Low floor room 54 L( FNear elevator room 55 AW231 from elevator room 56 RENTAL CAR PREFERENCES Compact car 100 Standard car 101 Mid-size car 102 Luxury car 103 AIRLINE PREFERENCES Window seat preferred 150 Aisle seal preferred 151 Low caloric 152 Ve!!etarian 153 Diabetic 154 Low sodium 155 rKosher 156 Table 38: Exemplary preference codes Security In the context of smaricard transactions, data security has five primary dimensions: 1) data confidendality, 2) data integrity, 3) access control, 4) 33 authentication, and 5) non-repildiailon. Each of these dimensions is addressed throuoh a variety of security mechanisms. Data confidentiality, which deals with keeping information secret (i.e., unread3ble to those without access to a key), is substantially ensured using encryption iechnolo-. Data integrity (and data source Z7 ey verification) focuses on ensuring that da13 remains unchanged during transfer, and typically employs message authentication techniques. Access control involves card holder verification and other requirements necessary in order for a party to read or update a particular file. Authentication involves ensuring that the card and/or the external device is what it purports to be. and non-repudiation deals with the related task of ensurino that the source of the data or message is OUthentic, i.e. , that a consumer may not repudiate a transaction by claiming that it was "signed" by an tinatithorized party.

Authentication is preferably performed using a "challenge/response' aloorithm. In -neneral, authentication through a challenge/response system involves:

1) generation of a random number by a first party; 2) transmission of the random number 10 a second party (the "challenge", 3) encryption of the random number by the second party in accordance Nvith a key known to both parties, 4) transmission of the encrypted random number to the first party (the "response"), 5) encryption of the random number by the first party, and 6) comparison by the first party of the two resulting numbers. In the cise Nkhere the two numbers match, authentication is successful; if not,the authentication is unsuccessful. Note that authentication can work both ways: the external world might request authentication of a smartcard (internal authentication), and a smaricard might request authentication of the external world (external authentication). a more detailed account of a preferred challenge/response algorithm can be found in the IBM MFC specification.

In a preferred e mbodiment, the DES algorithm (Data Encryption Standard) is employed for the various security functions; however, it will be appreciated that any number of other symmetrical or asymmetrical techniques may be used in the context of the present invention. More particularly, there are two general categories o4o of encryption algorithms: symmetric and asymmetric. Symmetric algorithms use the same key for encryption and decryption, for example, DEA (data encryption algorithm) which uses a 56-bit key to encrypt 64-bit blocks of data. Asymmetric 34 aloorithn-is- in contrast, use zwo different keys: one Secret key and one public key.

The RSA a]-onthm, for example, uses two such keys and exploits the computational complexity of factoring very large prime numbers. Additional information these and other cryptographic principles can be found in a number of standard texts, for example: Seberry & Pleprzyk, CRYPTOGRAPHY: AN INTRODucTiON TO COMPUTER SECURITY (1989); Rhee, CRYPTOGRAPHY. AND

SECURE COMMUNICATIO14S (1994); Stinson, CRYPTOGRAPHY: THEORY AND PRACTICE (1995); CONTEMPORARY CRYPTOGRAPHY: THE SCIENCE OF INFORMATION INTEGRITY (1992); and Schneier, APPLIED CRYPTOGRAPHY (2d ed. 1996), the contents of which are hereby incorporated by reference.

Access control is suitably provided by including access conditions Nkithin the header of each EF and DF. This prevents a particular operation (e.g., reading or updating) from being performed on a file unless the required access conditions have been fulfilled. Many different access conditions are appropriate in a smart card context. For example, the smaricard might require cardholder verification (i.e., request that the cardholder enter a PIN) before a file operation is allowed. Similarly, intemal and/or external authentication as described above might be required.

Another important access condition (referTed to herein as the SIGN condition) corresponds to the case where a particular file is "protected" and where updating of a record requires "signing" of the data using a message authentication code (MAC).

a MAC ran be thought of as a form of electronic sea] used to authenticate the content of the message. In a paradigmatic signing procedure, a shortened, encrypted representation of the message (the MAC) is created using a message authentication algorithm (MAA) in conjunction with a key known to both the card and external devicie. The MAC is then appended onto the message and sent to the card (or external device, depending on context), and the card itself generates a MAC based on the received message and the known key. The Card then compares the received MAC with the its own internally-generated MAC. If either the message or MAC was altered during transmission, or the sending party did not use the correct key, 0 then the two MACs will not match, and the access condition will not be fulfilled.

If the two MACs correspond, then the access condition is fulfilled, and the parficular file operation can proceed.

A MAC may be generated usinn a variety of MAAs, for example, the ANSI Z X9.9 method using an eight-byte key, or the ANSI X9.19 method using a sixteen byte key. Furthermore, the actual key may be "diversified" through encryption 0 a random number or other appropriate value. These and other details regarding Z MAC generation can be found in the references cited above as well as tile IBM

MITC specification.

Two other important access conditions are the NEVER and FREE conditions.

The NEVER condition corresponds to the case where a certain file operation (typicall y updating) is never allowed. The FREE condition, on the other hand, corresponds to the case where either updating or reading a file record is always allowed, without any additional preconditions for access.

In contrast to the MAC techniques discussed briefly above, nonrepudiation is necessarily performed using asymmetrical techniques. That is, as symmetrical techniques such as MAC "sealing" use a key known to more than one party, such techniques can not be used by a third party to ascertain whether the source of the message is COrTect. Thus, non-repudiation typically employs a public key encryption scheme (e.g., the ZimmerTnan's PGP system), wherein the sender uses a secret key to-sign" the message, and the receiving party uses the corresponding public key to -authenticate the signature. In the context of the present invention, this function is suitably performed by allocating an EF for public and secret key rings, which are well known in the ail, along with suitable encryption software resident in the card for assembling the signed message.

Having thus given a brief overview of typical smaricard security procedures, an exemplWy set of access conditions is set forth below in Table 40. In this regard, the various access conditions for each EF are tabulated with regard to whether the file is being read or updated. In each case, the access condition (FR.EE, SIGN, etc.), key "owner" (issuer, partner, user, etc.), and key name are listed. In this regard, it will be appreciated that thi key name is arbitrary, and is listed here for the sake of completeness.

36 IZEADING UPDATINC Access Owner Key Access Owner Key condition con,dition CaErdholdr rM EF ID 406 DF lio c, I F Holder _ ID H2 EF ID 504 FREE SIGN ISSUER KEYI CF I-lome 506 FREE SIGN ISSUER KEYI EF Business 508 FREE SIGN ISSUER KEY I EF Preferences 514 FREE SIGN ISSUER KEY I EF pmpon 516 FREE SIGN ISSUCR KEYI EF Biomcirics 522 FR EE SIGN ISSUER K EY I EF Driver 5 18 I.-REE SIGN ISSUER KEY I DF Miscellaneous Ir.

EF Payment card 5 10 FREE SIGN ISSUER KEYI EF Sequence 512 PEE FREE EFCrdNumber526 FREE SIGN ISSUER KEYI DF ppyrnenj System 408 DF Issuer 602 EF Pay] 604 FREE FREE DF Airline 4 10 DF Common 702 EF Passenger 706 REE SIGN ISSUER KEY2 EF Frequent flier 708 FREE SIGN ISSUER KEY2 EF IET 710 FREE FREE EF Boarding 712 FREE FREE EF Biometric 714 FREE FREE DF Issuer 704 EF Preferences 716 FREE SIG'N ISSUER KEY2 EF PIN 718 FREE SIGN ISSUER KEY2 EF issuance 720 FREE SIGN ISSUER KEY2 DF Rental car 414 DF Common 802 EF Preferences 805 FREE USER]DENT PIN 1 DF Rentail-car 803 37 LL:T Rcmil car 11) 107 FRO' SIGN IZENTCAR - - I I I KEY6 EF Rcscrvation 809 FREE FREE R 'r "a'-c' cE rF Rcscrvtion 9( P E-F EA pcnscs 8 11 FREE SIGN RENTCAR KEY6 (append) (append) (append) I I IDENT USER PIN (erase) (Crasc) (crasc) DF Holcl system 412 DF Common 914 Er Re-,crvntion 919 FREE FREE EF Expenses 916 FREE FREE USER PIN (append) icrase) (cnisc) IDEW jcrasc) CF Key-of-111c-roorn 910 FR C E FREE CF Prcrerences 912 FREE SIGN ISSUER KEYI Dr Holcl_chain 902 CF preferences 904 FREE SIGN ISSUER KEY] EF Stayer I D 906 FREE SIGN HOTEL KEYS I I L ------- Table 40: Exemplary access conditions Transactions Having thus given a detailed description of an exemplary smaricard 100 and C a preferred data structure 400, the various details related to transactions involving smaricard 100 will now be described. In general, a typical smaricard session involves: (1) activation of the contacts (or comparable non-contact means); (2) card reset; (33) Answer 10 reset (ATR) by card; (4) Information exchange between card and host; and, at the conclusion of a session, (5) deactivation of contacts.

First, card 100 is inserted in a card reader Provided at an access point 15, and suitable connections are made between corturiunication region 104 on card 100 and the card reader. In a preferred embodiment.

physical contacts (contacts 106 in 25 Figure 1) are used, and DATA, CLOC& RESET, VDD, and GND connections are 38 made. These contacts are electricafly activated in a particular sequence, preferably in accordance with ISO 7816-3) (RST to lom, state, VDD powered, DATA to reception mode, then CLK applied).

The card reader then initiates a reset (i.e., RST to high state), and the card returns an answer to reset st-ring (ATR) on the DATA line, preferably in c onformance with the content and timing details specified in the appropriate parts of ISO 7816. In a preferred embodiment, the interface characters are chosen to reflect a T=1 protocol (asynchronous, half-duplex, block-orienled mode). Further in accordance with ISO-7816-3, after the card sends an ATR string and the proper protocol is selected (in a preferred embodiment, the T=l mode), host 314 and card begin the exchange of commands and responses that comprise a particular transaction. The nature of these commands is discussed in further detail below.

At the end of a smaricard session, contacts 106 are deactivated. Deactivation of contacts 106 is preferably performed in the order specified in ISO 7816-3 (i.e., RST to low state, CLK to low state, DATA to low state, VDD to inactive state). As mentioned above, the VPP contact is not utilized in a preferred embodiment.

In the context of the present invention, command classes and instructions are provided for 1) working with application data (i.e., files stored within the various applications), 2) ensuring data security, 3) card management, and 4) performing miscellaneous functions.

Application data commands are suitably directed at selecting, reading, and updating individual records or groups of records within files..Security commands suitably include commands for performing the challenge/response authentication process, generating random numbers, loading or updating cryptographic keys, and changing and verifying the card-holder verification codes (CHV I and CHV2). Card management commands suitably include commands wWch allow for the creation and deletion of directories (DFs) and elementary files (EFs). Miscellaneous commands are suitably provided for modifying the baud rate and reading various card statistics (e.g., data logged during production of the card.) It will be appreciated that many different command sets could be designed for implementing these basic functions. One such command set is provided by the IBM Multifunction Card Operating System 3.5 1, hereby incorporated by reference.

39 Referring again to Figure 10. access point 15 preferably comprises sof ware 01 t which provides a user interface (for example, a graphical user interface) and is capable of executing the appropriate SCOS commands in accordance with the particular transaction being effected. For example, consider the case where a cardholder wishes to add a preference in car preferences EF 810 within rental car application 414 (shown in Figure 8). In this instance, a cardholder would locate a convenient access point 15 (for example, a stand-alone kiosk in a mall) and insert card 100 in a provided card reader in order to initiate a transaction. After suitable handshaking between card 100 and the card reader has taken place, and after the cirdholder has been properly authenticated (i.e., the correct access conditions for updating car preferences EF 810 have been fulfilled), the application Program at access point 15 queries the user with a choice of preference codes (for example, those listed in Table 39 above). The user then indicates a choice -- thr:)ugh textual or graphical means, and the appropriate value is sent to card 100 by the application program as pan of a command string. This value may then be sent to the appropriate partnering organization 12 (i.e., a rental car pariner) and issuer 10 over network 19 to be stored in their respective databases 13 and I I - Alternatively, this data may be sent later as part of a card/database synchronization procedure, e.g., when the original transaction proceeds off-line.

Consider, as another example, the typical hotel transaction. As detailed above, the cardholder inserts card 100 into a card r"der deployed at a suitable access point 15. After appropriate initiaiization procedures take place, the cardholder is presented, through the use of a graphical user interface, the option to make -a hotel reservation. Upon choosing this option, the software may interrogate the hotel preferences field in preferred programs EF 524 in cardholder ID application 406 and display these hotels first within the list of possible chbices.

Afier the cardholder selects a specific hotel property, the software contacts the appropriate partner 12 over network 19 and requests a hotel room for a particular set of dates. This step might involv an interrogation of the various files within hotel system application 412 to which the particular hotel has access (i. e., a hotel chain-DF 902 or property DF 903), or this step may be deferred until check-in (as described below).

once a reservation has been made. the associated confirmation number supplied by the hotel is downloaded Into the confirmation number field in reservation EF 918 alonv with the date and the propeny code of the hotel. niis step mip ht require the ca.Tdholder to transmit appropriate credit card information. which is suitably retrieved from pay I EF 604.

Upon arrival at the hotel, the cardholder m3v use smartcard 100 to access a w kjosk or other convenient access point provided for check-in. Thus, check- in may take place unassisted by hotel personnel, or may involve a more traditional person to-person interaction where card 100 is used primarily to streamline the check-in Process initiated by personnel at the front desk.

At check-in, the confirmation number information is retrieved from reservation EF 918., and a particular room isissigned (if not assigned previously).

1 10 nis step will typically involve retrieving, from the appropriate preference file (i.e., preferences EF 904 or 912), a list of preferences renarding bed size, room type, and the like. This list may be matched against the hotel's database of available rooms, thereby helping to streamline the room assignment process. - Once a room is assigned, a digital key corresponding to the assigned room (e.g., a numeric value or alphanumeric string) may be stored in key-of- the-room EF 910. Card readers are then employed as part of the door lock apparatus for each room, which are configured to open only upon rec eiving the correct key.

At check-out time, payment may take place using payment card information stored in payment card EF 510 and pay I EF 604. A-ain, a suitable smartcard reader (i.e., an acces. s point 15). may be provided in an), location convenient for check out, e.g., the hotel lobby or within the individual hotel rooms themselves. The cardholder may then acquire frequent slayer points, which would involve updating one of the slayer ID EFs 906 (or 936). During the courst of his stay at the hotel, the cardholder may have incurred any number of expenses related to roomservice, on site dining, film viewing, and the like. These expenses, or a subset thereof, may be conveniently downloaded into expenses EF.916 for later retrieval, printout, or archiving.

Use of card 100 in a rental car context would necessarily involve many of the same steps described above. 'ne task of assigning a car would involve reuieving 41 car preferences s(orcd within preferences EF 805 and comparing them to a database C of-'available automobiles. Upon returning the awomobile, the cardholder might then be awarded frequeni rental points (through update of frequent renter EF 807), and an expense record might be stored within expenses EF 8 11 In the airline context, cird 100 could be osed to make reservations, record.

preferences, and provide a payment means as described above. In addition, electronic tickets may be downloaded (EF IET 710), and boarding information may be supplied via boarding EF 712. Frequent flyer EF 708 may then be used to update the cardholder's frequent flyer miles.

While the example transactions set forth above tire described in general terms, the particular nature of data flow to and from the appropriate memory locations within the card will be apparent to those Ctilled in the art.

Moreover, although the inventions set forth herein have been described in conjunction with the appended drawing figures, those skilled in the art will appreciate that the scope of the invention is not so limited. For example, although the preferred embodiment of the invention is discussed in the context of a standard, credit card-sized smaricard with external contacts, it will be appreciated that virtually any portable memory device suitably configured may be utilized to practice this invention, for example, contactless Cards, optical cards, minicards, "super-smarl" cards, and the like. Hence, various modifications in the design and arrangement of the components and steps discussed herein may be made without departing from the scope of the invention as set forth in the appended claims.

42 43

Claims (22)

CLAIMS:

1. A smartcard apparatus of the type configured to communicate with an external device to perform a transaction, said smartcard apparatus comprising: a smartcard body; an integrated circuit device disposed within said smartcard body and configured to communicate with said external device, said integrated circuit device including a cardholder ID application for storing information related to a cardholder's identity, and a payment system application, said payment system application including fields for storing indicia of at least one credit account associated with a partnering organization; and communication means for providing data communication between said integrated circuit device and said external device.

2. The smartcard apparatus of claim 1, wherein said integrated circuit device further comprises an airline application, said airline application including a common airline file and a second airline file associated with a partnering organization.

3. The smartcard apparatus of claim 1, wherein said integrated circuit device fin-ther comprises a rental car application, said rental car application including a common car file and a second car file associated with a partnering organization.

4. The smartcard apparatus of claim 2, wherein said integrated circuit device further comprises a hotel application, said hotel application including a common hotel file and a second hotel file associated with a partnering organization.

5. A smartcard apparatus of the type configured to communicate with an external device to perform a transaction, said smartcard apparatus comprising: a smartcard body; an integrated circuit device disposed within said smartcard body, said integrated circuit device comprising:

44 (a) a cardholder identification application; (b) at least one second application for storing travel related information, said second application comprising a common file structure and at least one partner file structure; a communication means for providing data communication between said integrated circuit device and said external device.

6. A smartcard apparatus in accordance with claim 5, wherein said communication means comprises a plurality of external contacts disposed upon said smartcard body.

7. A smartcard apparatus in accordance with claim 5, wherein said second application comprises: a payment system application; an airline application; a hotel application; or a rental car application.

8. A smartcard apparatus of the type configured to communicate with an external device to perform a transaction, said smartcard apparatus comprising: a smartcard body; an integrated circuit device disposed within said smartcard body and configured to communicate with said external device, said integrated circuit device comprising a common application and a second application, said second application being configured to store travel-related information associated with a cardholder; and communication means for providing data communication between said integrated circuit device and said external device.

9. The smartcard apparatus of claim 8, wherein said communication means comprises a plurality of external contacts disposed on a surface of said smartcard body.

10. The smartcard apparatus of claim 8, wherein said second application comprises a payment system application.

11, The smartcard apparatus of claim 10, wherein said payment system application is configured to store an account number and an expiry date associated with a payment account.

12. The smartcard apparatus of claim 8, wherein said second application comprises an airline application.

13. The smartcard apparatus of claim 12, wherein said airline application is configured to store an electronic ticket.

14. The smartcard apparatus of claim 8 wherein said second application comprises a hotel application.

15. The smartcard apparatus of claim 14, wherein said hotel application is configured to store data associated with a hotel reservation,

16. The smartcard apparatus of claim 8, wherein said second application comprises a rental car application.

17. The smartcard apparatus of claim 16, wherein said rental car application is configured to store data associated with a car preference.

18. The smartcard apparatus of claim 8, wherein said conunon application comprises an application configured to store indicia of said cardholder's identity.

19. The smartcard apparatus of claim 18, wherein said indicia of said cardholder's identity includes a name and an address.

46

20. The smartcard apparatus of claim 8, wherein said common application provides general read access.

21. The smartcard apparatus of claim 8, wherein said second application comprises a common file structure and a partner file structure, wherein said partner file structure provides write access to a field within said partner file structure for a first partnering organization and denies write access to said field for a second partnering organization, and said common file structure provides write access for both said first and second partners to at least one field in said common file structure.

22. A distributed transaction comprising: a network for transmitting transaction information; a partnering organization having an associated partnering organization server, said partnering organization server being configured to send and receive said transaction information over said network; a smartcard access point, said smartcard access point being configured to interface with a smartcard and to accept user input, wherein said access point is further configured to send and receive said transaction information over said network in response to said user input, said smartcard comprising: a smartcard body; an integrated circuit device disposed within said smartcard body and configured to communicate with said smartcard access point, said integrated circuit device comprising a common application and a second application, said second application being configured to store travel-related information associated with a cardholder; and communication means for providing data communication between said integrated circuit device and said smartcard access point.