AU2020101940A4 - IoT-Based Micropayment Protocol for Wearable Devices with Biometric Verification - Google Patents

Abstract

Patent Title: IoT-Based Micropayment Protocol for Wearable Devices with Biometric Verification ABSTRACT The invention" IoT-Based Micropayment Protocol for Wearable Devices with Biometric Verification "is a method for facilitating biometric security in a micropayment, smartcard reader transaction system is provided. The invented method determining if a transaction violates an established rule, such as a preset spending limit and the method also includes notifying a user to proffer a biometric sample in order to verify the identity of said user, and detecting a proffered biometric at a sensor to obtain a proffered biometric sample. The method additionally comprises verifying the proffered biometric sample and authorizing a transaction to continue upon verification of the proffered biometric sample. The invented systems and methods are configured to manage data sets associated with a transaction device. For example, a method is provided for facilitating the management of distinct data sets on a transaction device that are provided by distinct data set owners. The method includes the steps of: 1: The adding, by a read/write, a first data set to the financial transaction device. 2: Wherein the first data set is owned by a first owner. 3. The adding, by the read/write device, a second data set to the financial transaction device. 4. Wherein the second data set is owned by a second owner. 5. The storing the first data set and the second data set on the financial transaction device in accordance with an owner defined format. The first and second data sets are associated with first and second owners, respectively, and are configured to be stored independent of each other the transaction device user may be permitted to select at least one of the multiple data sets for transaction completion using a secondary identifier indicium. Where the user selects multiple accounts for transaction completion, the user may be permitted to allocate portions of a transaction to the selected transaction accounts. The transaction request may be processed in accordance with the user's allocations. 34 Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 O~TO 102 110 It p 106 106d Steve Johnson FIG. 1: IS AN EXEMPLARY SMARTCARD APPARATUS.

Description

Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17

102

110 O~TO

106 106d It p

Steve Johnson

FIG. 1: IS AN EXEMPLARY SMARTCARD APPARATUS.

Australian Government IP Australia Innovation Patent Australia Patent Title: loT-Based Micropayment Protocol for Wearable Devices with Biometric Verification Name and address of patentees(s): Dr. R. Madana Mohana (Professor, CSE) Office Address: DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING, BHARAT INSTITUTE OF ENGINEERING AND TECHNOLOGY, MANGALPALLY (VILLAGE), IBRAHIMPATNAM (MANDAL), RANGA REDDY (DISTRICT), HYDERABAD - 501510, TELANGANA, INDIA. Residential Address: S/O R KRISHNAIAH, 22-15, RASINENIVARIPALLE, NOOTHANAKALVA (VILLAGE), K. V. PALLE (MANDAL), CHITTOOR (DISTRICT), ANDHRA PRADESH - 517 213, INDIA. E-mail: rmmnaidu@gmail.com Dr. Rambabu Arjunarao Vatti (Professor, ECE) Office Address: DEPARTMENT OF ELECTRONICS AND COMMUNICATION ENGINEERING, BHARAT INSTITUTE OF ENGINEERING AND TECHNOLOGY, MANGALPALLY (VILLAGE), IBRAHIMPATNAM (MANDAL), RANGA REDDY (DISTRICT), HYDERABAD-501 510, TELANGANA, INDIA. Residential Address: S.NO.59, SAI NAGAR, KONDHWA (BK), PUNE-411048, MAHARASHTRA, INDIA. E-mail: rambabuvatti.india@gmail.com. K. S. Niraja (Assistant Professor, CSE) Office Address: DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING, MUFFAKHAMJAH COLLEGE OF ENGINEERING, MOUNT PLEASANT, 8-2-249, ROAD NO-3, BANJARA HILLS, HYDERABAD, TELANGANA- 500034, INDIA. Residential Address: L..G -49/1, PHASE 3, BESIDE VENKATESHWAR SWAMY TEMPLE LANE, K.P.H.B COLONY, KUKATPALLY, HYDERABAD- 500072, TELANGANA, INDIA. E-mail: niraja.ksvce@gmail.com Chandika Mohan Babu (Assistant Professor, ECE) Office Address: DEPARTMENT OF ELECTRONICS AND COMMUNICATION ENGINEERING, BHARAT INSTITUTE OF ENGINEERING AND TECHNOLOGY, MANGALPALLY (VILLAGE), IBRAHIMPATNAM (MANDAL), RANGA REDDY (DISTRICT), HYDERABAD-501 510, TELANGANA, INDIA. Residential Address: PLOT NO. 142, SAI BABA NAGAR COLONY, RAMPALLY VILLAGE, KEESRA MANDAL, MEDCHAL DISTRICT, HYDERABAD, TELANGANA- 501301, INDIA. E-mail: mohaniitkgp08@gmail.com C V Krishnaveni (Lecturer in Computer Science) Office Address: SKR & SKR GCW (A), KADAPA, ANDHRA PRADESH - 516 001, INDIA. Residential Address: 20/1136, COOPERATIVE COLONY, KADAPA, ANDHRA PRADESH-516001, INDIA. E-mail: cvkrishnaveni19@gmail.com Jayanthi Neelampalli (Assistant Professor, CSE) Office Address: DEPARTMENT OF COMPUTER SCIENCE ENGINEERING, INSTITUTE OF AERONAUTICAL ENGINEERING, DUNDIGAL, HYDERABAD -500043, TELANGANA, INDIA. Residential Address: FLAT #305, B- BLOCK, SRI KALKI GARDENS, MADINAGUDA, MIYAPUR, HYDERABAD -500049, TELANGANA, INDIA. E-mail: jneelampalli.office@gmail.com P. Ila Chandana Kumari (Associate Professor, CSE) Office Address: DEPARTMENT OF COMPUTER SCIENCE ENGINEERING, HYDERABAD INSTITUTE OF TECHNOLOGY AND MANAGEMENT, GOWDAVELLY (VILLAGE), MEDCHAL. HYDERABAD, TELANGANA - 502 401, INDIA. Residential Address: FLAT NO: 302, H.NO: 2-22-108/1/A, SAI BALAJI RESIDENCY, ROAD NO- 4, VIJAYANAGAR COLONY, KUKATPALLY - 500072, HYDERABAD, TELANGANA, INDIA. E-mail: ilachandana @gmail.com Prashant(Assistant Professor, ECE) Office Address: DEPARTMENT OF ELECTRONICS AND COMMUNICATION ENGINEERING, BHARAT INSTITUTE OF ENGINEERING AND TECHNOLOGY, MANGALPALLY (VILLAGE), IBRAHIMPATNAM (MANDAL), RANGA REDDY (DISTRICT), HYDERABAD-501 510, TELANGANA, INDIA. Residential Address: #46/E, KHED AT POST SANGAM KHED, TALUKA -AURAD (B), DISTRICT -BIDAR,

KARNATAKA-585417, INDIA. E-mail: prashantece403@gmail.com Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Office Address: DEPARTMENT OF ELECTRONICS & COMMUNICATION ENGINEERING, GURU NANAK DEV ENGINEERING COLLEGE, MAILOOR ROAD. BIDAR-585403, KARNATAKA, INDIA. Residential Address: REDDY NIVAS, H. NO: 15-2-85, OPP: KAILASH MOTORS, GANESH NAGAR. BIDAR 585403, KARNATAKA, INDIA. E-mail: reddysirlogin@gmail.com Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) Address: SURYADATTA INSTITUTE OF MANAGEMENT & MASS COMMUNICATION (SIMMC) SR. NO: 342, BAVDHAN, PUNE-411021, MH, INDIA. E-mail: info@suryadatta.edu.in Complete Specification: Australian Government FIELD OF THE INVENTION

My invention "IoT-Based Micropayment Protocol for Wearable Devices with Biometric Verification" is related to the use of integrated circuit cards, or "smartcards," for commercial transactions, a Micropayment, other required transition and also methods, system for using biometrics with a smartcard in the context of a distributed transaction system. BACKGROUND OF THE INVENTION

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 may be characterized by sophisticated memory management and security features. A typical smartcard may include a microcontroller embedded within the card plastic which may be electrically connected to an array of external contacts provided on the card exterior. A smartcard microcontroller generally may include 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 may be adequate to control these functions.

Thus, it may be 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: Dimensions and location of the contacts (1988); ISO 7816-3, Part 3: Electronic signals and transmission protocols (1989, Amd. 1 1992, Amd. 2 1994); ISO 7816-4, Part 4: Inter-industry commands for interchange (1995); ISO 7816-5, Part 5: Numbering system and registration procedure for application identifiers (1994, Amd. 1 1995); ISO/IEC DIS 7816-6, Inter-industry data elements (1995); ISO/IEC WD 7816-7, Part 7: Enhanced inter-industry commands (1995); and ISO/IEC WD 7816-8, Part 8: Inter-industry security architecture (1995).

These standards may be hereby incorporated by reference. Furthermore, general information regarding magnetic stripe cards and chip cards may be found in a number of standard texts, e.g., Zoreda & Oton, SMART CARDS (1994), and Rankl & Effing,

SMART CARD HANDBOOK (1997), the contents of which may be hereby incorporated by reference.

While some smartcard systems have streamlined the transaction process and provided a system for managing more information, smartcard technology has still not adequately addressed some of the authentication issues related to transactions. Moreover, while biometric technology exists with respect to certain access systems and limited financial systems, the use of biometric security in association with smartcards remains underdeveloped and scarce. As such, a need exists to integrate biometric technology advances with smartcard technology.

Some financial transaction devices, such as credit cards and loyalty program cards, are capable of accessing information related to multiple accounts. For example, a credit card may be able to access membership data associated with both a credit card account and a wholesale purchase club account. These financial transaction devices may generally include one or more applications for selecting and then securely utilizing a sub-set of specified account information. However, the systems associated with these cards typically delegate the loading of these applications and management of the related data sets to third parties on behalf of both the issuer of the instrument and "application tenants" residing on the issuer's financial transaction devices.

Managing data associated with a credit card via the issuer/third party may involve time consuming steps such as requesting permission to manage data, conforming to data standard formats, and implementing changes. Thus, traditional solutions for managing multiple application tenants are disadvantageous in that the traditional solutions leave a disproportional burden on the issuer and/or the delegated third party in terms of managing accounts on a financial transaction device.

Another disadvantage is that, in general, the financial transaction devices, which are capable of accessing information related to multiple accounts, are typically designed to access only those multiple accounts managed by the same issuer. For example, the same issuer provides both the credit card and the wholesale purchase club account to the user. As such, the issuer providing both accounts generally establish its own application tenant storage format and management protocol related to the accounts. The established format and protocol is ordinarily different from any format or protocol used by other unrelated issuers, which provides the issuer increased control over access to the account data.

Because of the differing unique protocols/formats amongst issuers, multiple issuers typically provide a transaction device corresponding to an account offered by the issuer, where the data for accessing the account is stored in that issuer's protocol/format. Thus, a user wishing to access multiple accounts managed by different issuers, must ordinarily carry at least one transaction device per issuer. Carrying multiple transaction devices can be inconvenient in that the instruments may be more easily misplaced, lost or stolen, preventing the user from accessing the account.

PRIOR ART SEARCH

S9582639B22006-08-112017-02-28University Of Tennessee Research Foundation Method and apparatus for mobile disaster victim identification. US9235733B22006-08-112016-01-12J. Douglas Birdwell Mobile biometrics information collection and identification. US8219771B2 *2006-10-192012-07-1OStmicroelectronics, Inc. Portable device for storing private information such as medical, financial or emergency information. W02008079491A2*2006-10-202008-07-03Electronic Plastics, Llc Decentralized secure transaction system. US8292741B2 *2006-10-262012-10-23Cfph, Llc Apparatus, processes and articles for facilitating mobile gaming. US9306952B2 *2006-10-262016-04-05Cfph, Llc System and method for wireless gaming with location determination. US9141956B2*2006-11-132015-09-22Ncr Corporation Using biometric tokens to pre stage and complete transactions. US8645709B2 *2006-11-142014-02-04Cfph, Llc Biometric access data encryption US8510567B22006-11-142013-08-13Cfph, Llc Conditional biometric access in a gaming environment. US9411944B2 *2006-11-152016-08-09Cfph, Llc Biometric access sensitivity JP5595434B2 *2012-03-022014-09-24 Information processing server, information processing method, information processing program, and recording medium on which information processing program is recorded. US8862181B12012-05-292014-10-14Sprint Communications Company L.P. Electronic purchase transaction trust infrastructure. US20140012704A12012-07-052014-01-09Google Inc. Selecting a preferred payment instrument based on a merchant category. US9818104B12013-01-252017-11-14Sprint Communications Company L.P. Secure online credit card transactions. US9092767B12013-03-042015-07-28Google Inc. Selecting a preferred payment instrument. US10380591B2 *2013-03-142019-08-13Nuance Communications, Inc. Pro-active identity verification for authentication of transaction initiated via non-voice channel. US9467859B22013-06-172016-10-llYale Security Inc. Virtual key ring. US20150019417A1*2013-06-262015-01-15Google Inc. Updating a digital wallet from financial account issuer US20150100497A1*2013-10-032015-04-09Nxp B.V. Article and method for transaction irregularity detection. OBJECTIVES OF THE INVENTION

1. The objective of the invention is to a method for facilitating biometric security in a micropayment, smartcard-reader transaction system is provided. The invented method determining if a transaction violates an established rule, such as a preset spending limit and the method also includes notifying a user to proffer a biometric sample in order to verify the identity of said user, and detecting a proffered biometric at a sensor to obtain a proffered biometric sample.

2. The other objective of the invention is to the method additionally comprises verifying the proffered biometric sample and authorizing a transaction to continue upon verification of the proffered biometric sample. The invented systems and methods are configured to manage data sets associated with a transaction device. 3. The other objective of the invention is to a method is provided for facilitating the management of distinct data sets on a transaction device that are provided by distinct data set owners. The method includes the steps of: 1: The adding, by a read/write, a first data set to the financial transaction device. 2: Wherein the first data set is owned by a first owner. 3. The adding, by the read/write device, a second data set to the financial transaction device. 4. Wherein the second data set is owned by a second owner. 5. The storing the first data set and the second data set on the financial transaction device in accordance with an owner defined format. 4. The other objective of the invention is to the first and second data sets are associated with first and second owners, respectively, and are configured to be stored independent of each other the transaction device user may be permitted to select at least one of the multiple data sets for transaction completion using a secondary identifier indicium. 5. The other objective of the invention is to the user selects multiple accounts for transaction completion, the user may be permitted to allocate portions of a transaction to the selected transaction accounts. The transaction request may be processed in accordance with the user's allocations. 6. The other objective of the invention is to comprising verifying said first secondary identifier indicia and also the invention is to comprising authorizing a transaction request relative to said first data set. 7. The other objective of the invention is to wherein the step of completing a transaction request using said first data set comprises allocating a first portion of said transaction request to said first data set for transaction completion. 8. The other objective of the invention is to comprising completing a transaction request using said second data set, wherein a second portion of said transaction request is allocated to said second data set for transaction complete.

SUMMARY OF THE INVENTION

The smartcard system is configured with a biometric security system. The biometric security system includes a smartcard and a reader communicating with the system. The biometric security system also includes a biometric sensor that detects biometric samples and a device for verifying biometric samples. In yet another embodiment, the present invention discloses methods for proffering and processing biometric samples to facilitate authorization of transactions.

The invention may provide methods and apparatus for a smartcard system which securely and conveniently integrates important travel-related applications with biometric security, thereby overcoming the limitations of the prior art. In accordance with one aspect of the present invention, a smartcard system may comprise 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 smartcard system further may comprise space and security features within specific applications which provide partnering organizations the ability to construct custom and secure file structures.

The invention, a dynamic smartcard synchronization system comprises access points configured to initiate a transaction in conjunction with a smartcard, an enterprise data collection unit, and a card object database update system, along with a biometric security system. An exemplary dynamic synchronization system (DSS) preferably comprises various smartcard access points, a secure support client server, a card object database update system (CODUS), one or more enterprise data synchronization interfaces (EDSI), an update logic system, one or more enterprise data collection units (EDCUs), and one or more smartcard access points configured to interoperable accept and interface with smartcards. In an exemplary embodiment, DSS comprises a personalization system and an account maintenance system configured to communicate with CODUS.

The invention, personalization of multi-function smartcards is accomplished using a biometric security system and a security server configured to generate and/or retrieve cryptographic key information from multiple enterprise key systems during the final phase of the smartcard issuance process. These features and other advantages of the system and method, as well as the structure and operation of various exemplary embodiments of the system and method, are described below.

In the context of smartcard transactions, data security has five primary dimensions: 1) data confidentiality, 2) data integrity, 3) access control, 4) authentication, and 5) non repudiation. Each of these dimensions may be addressed through a variety of security mechanisms. Data confidentiality, which deals with keeping information secret (i.e., unreadable to those without access to a key), may be substantially ensured using encryption technology. Data integrity (and data source verification) focuses on ensuring that data remains unchanged during transfer, and typically may employ 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 may be what it purports to be, and non-repudiation deals with the related task of ensuring that the source of the data or message may be authentic, i.e., that a consumer may not repudiate a transaction by claiming that it was "signed" by an unauthorized party. Cardholder verification using a biometric security system is described in greater detail below.

Authentication may be preferably performed using a "challenge/response" algorithm. In general, authentication through a challenge/response system involves: 1) generation of a random number by a first party; 2) transmission of the random number to a second party (the "challenge", 3) encryption of the random number by the second party in accordance with 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 case where the two numbers match, authentication may be successful; if not, the authentication may be unsuccessful. Note that authentication may work both ways: the external world may request authentication of a smartcard (internal authentication), and a smartcard may request authentication of the external world (external authentication). a more detailed account of an exemplary challenge/response algorithm may be found in the IBM MFC specification.

The DES algorithm (Data Encryption Standard) may be employed for the various security functions; however, it may be appreciated that any number of other symmetrical or asymmetrical techniques may be used in the context of the present invention. More particularly, there may be two general categories of encryption algorithms: symmetric and asymmetric. In one exemplary embodiment of the present invention, a system and method is provided for facilitating the management of distinct data sets of different formats on a RF operable transaction device. The system includes a RF financial transaction device for use in managing multiple distinct data sets provided by distinct issuers. The method includes the steps of: receiving, from a read/write device, at least a first data of a first format at the financial transaction device, wherein the first data set is owned by a first owner; receiving, from the read/write device, at least a second data set of a second format at the financial transaction device, wherein the second data set is owned by a second owner, and wherein the first format is different from the second format; storing the first data set and the second data set on the financial transaction device, in distinct fashion and in accordance with the first and second format respectively, where the first data set and the second data set are unique one from the other; and modifying (e.g., adding, deleting, overwriting, altering) at least the first data set, and/or adding a third data set, in accordance with instructions provided by the data set owner or user.

A financial transaction device comprises a data set management system for facilitating the management of more than one data set stored on the transaction device, the RF financial transaction device comprising at least one data storage area configured to store a first data set of a first format and a second data set of a second format different from the first format. The first data set is associated with a first data set owner (e.g., first issuer) and the first data set is configured to be stored on the financial transaction device independent of a second data set owner (e.g., second issuer); and, the second data set is associated with the second owner and the second data set is configured to be stored on the financial transaction device independent of the first data set owner, wherein the first data set and the second data set are stored in accordance with the first and second format, respectively.

A data management system comprises: a RF financial transaction device associated with a first data set of a first format and a second data set of a second format, wherein the financial transaction device is configured to facilitate management of the first data set without involvement of the first data set owner. The data management system may further comprise a read/write device configured to communicate with the financial transaction device for providing the first and second data sets to the instrument and for modifying the data sets thereon in accordance with a condition header annotated to the data sets. The read/write device may be stand alone, or the device may be connected to a transaction processing network. The read/write device may be used to load the issuer owned data onto the transaction device, and thereafter delete, augment and/or manage the information stored thereon, or to add additional distinct data sets.

As noted, exemplary embodiments of the financial transaction device of the present invention may include storing a first and second data set of differing formats on a transaction device database. Alternate exemplary embodiments of the present invention may also include a "mirror image" of the first and second data set stored on a remote database removed from the transaction device issuer and the transaction device itself. The remote database may be placed in communication with the transaction device issuer system, and the financial transaction device via, for example, electronic communication with a network. As such, in one exemplary aspect, the present invention permits changes which are made on the remote database (or transaction device) to be mimicked or synchronized on the instrument (or remote database).

The invention secures authorization from an issuer prior to loading the issuer-owned data onto the RF transaction device. Once authorization is given, the issuer may be "enrolled" in a transaction device multiple account management system, the associated issuer-owned data may then be loaded on the transaction device. The issuer-owned data may be loaded in a format recognizable by a merchant system or by a system maintained by issuer. Thus, when the transaction device is presented to complete a transaction, the data may be transferred to the issuer in an issuer recognized format, eliminating the need to carry multiple transaction devices for each issuer. That is, the issuer receives the data in an issuer recognized format and may process the accompanying transaction under issuer's already established business as usual protocols. In this way, the issuer is permitted to manage its issuer provided program at the issuer location, irrespective of the management of other programs provided by other distinct issuers enrolled in the multiple account management system.

BRIEF DESCRIPTION OF THE DIAGRAM

FIG. 1: is an exemplary smartcard apparatus.

FIG. 2: is a schematic diagram of an exemplary smartcard integrated circuit, showing various functional blocks.

FIG. 3: is an exemplary diagram of files and directories arranged in a typical tree structure.

FIG. 4:is a sets forth an exemplary database structure in accordance with an exemplary embodiment of the present invention.

FIG. 5: is a sets forth an exemplary cardholder ID data structure in accordance with the present invention;

FIG. 6: is a sets forth an exemplary payment system data structure in accordance with the present invention.

FIG. 7: is a sets forth an exemplary airline data structure in accordance with the present invention.

FIG. 8:is a sets forth an exemplary rental car data structure in accordance with the present invention.

FIG. 9: is a sets forth an exemplary hotel system data structure in accordance with the present invention.

FIG. 10: is an exemplary distributed transaction system useful in practicing the present invention.

FIG. 11: is a schematic overview of an exemplary dynamic synchronization system in accordance with various aspects of the present invention.

FIG. 12: is a schematic overview of an exemplary secure support client server;

FIG. 13: is a flowchart depicting an exemplary method for synchronizing pending transaction information.

FIG. 14: is a flowchart depicting an exemplary method for synchronizing update transaction information;

FIG. 15: is a block diagram overview of an exemplary data set management system in accordance with an exemplary embodiment of the present invention.

FIG. 16: is a more detailed exemplary data set management method in accordance with an exemplary embodiment of the present invention.

FIG. 17: is an exemplary data set management method for adding data sets in accordance with an exemplary embodiment of the present invention.

DESCRIPTION OF THE INVENTION

FIGS. 1 and 2, an exemplary smartcard system suitable for practicing the present invention may now be described. A smartcard 100 generally may comprise a card body 102 having a communication region 108 for providing contact or non-contact communication between an external device (e.g., a card reader) and an integrated circuit 110 encapsulated within card body 102. Communication region 108 preferably may comprise six conductive pads 106 whose placement and size conform to IS07816-2. More particularly, a communication region 108 in conformance with ISO-7816-2 preferably may comprise VCC contact 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 I/O contact 106(f) (data line).

VCC 106(a) may suitably provide power to IC 110 (typically 5.0 V+/-10%). CLK 106(c) may be suitably used to provide an external clock source which acts as a data transmission reference. RST 106(b) may be suitably used to transmit a reset signal to IC 110 during the booting sequence. VPP contact 106(e) may be used for programming of EEPROM 212 in IC 110. As may be known in the art, however, this contact may be generally not used since modern ICs typically incorporate a charge pump suitable for EEPROM programming which takes its power from the supply voltage (VCC 106(a)). I/O 106(f) may suitably provide a line for serial data communication with an external device, and GND 106(d) may be suitably used to provide a ground reference. Encapsulated integrated circuit 110 may be 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 may 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 may be known in the art, capacitive coupling involves incorporating capacitive plates into the card body such that data transfer with a card reader may be provided through symmetric pairs of coupled surfaces, wherein capacitance values may be typically 10-50 Pico farads, and the working range may be typically less than one millimeter. Inductive coupling may employ coupling elements, or conductive loops, disposed in a weakly-coupled transformer configuration employing phase, frequency, or amplitude modulation. In this regard, it may be appreciated that the location of communication region 108 disposed on or within card 100 may vary depending on card configuration. For additional information regarding non-contact techniques, see, for example, contactless card standards ISO/IEC 10536 and ISO/IEC 14443, which are hereby incorporated by reference.

Smartcard body 102 may be preferably manufactured from a sufficiently rigid material which may be resistant to various environmental factors, e.g., physical deterioration, thermal extremes, and ESD (electrostatic discharge). Materials suitable in the context of the present invention may include, for example, PVC (polyvinyl chloride), ABS (acrylonitrile-butadiene-styrol), PET (polyethylene terephthalate), or the like. In an exemplary embodiment, chip card 100 may conform 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 an exemplary embodiment, body 102 may be roughly the size and shape of a common credit card and substantially conforms to the ID-1 specification.

Referring now to FIG. 2, IC 110 preferably may comprise regions for Random Access Memory (RAM) 216, Read-Only Memory (ROM) 214, Central Processing Unit (CPU) 202, data bus 210, Input/output (I/0)208 and Electrically-Erasable and Programmable Read Only Memory (EEPROM) 212. RAM 216 may comprise volatile memory which may be used by the card primarily for scratch memory, e.g., to store intermediate calculation results and data encryption processes. RAM 216 preferably may comprise at least 256 bytes. EEPROM 212 may provide a non-volatile memory region which may be erasable and rewritable electrically, and which may be used to store, inter alia, user data, system data a smartcard identifier and application files. In the context of the present invention, EEPROM 212 may be suitably used to store a plurality of files related to cardholder information, including general cardholder information, payment information and/or other transaction information. In one exemplary embodiment in accordance with the present invention, EEPROM 212 may be suitably used to store travel-related information (discussed in greater detail below in conjunction with FIG. 3). EEPROM 212 preferably may comprise at least 8K bytes.

Referring now to FIG. 4, file structure 400 may be preferably used to store information 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 may comprise cardholder ID application 406, payment system application 408, airline application 410, hotel system application 412, rental car application 414, and cardholder verification data 404. It may be appreciated by those skilled in the art that the term "application" in this context refers to self-contained regions of data 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 an exemplary embodiment, cardholder verification data 404 may comprise two eight-byte cardholder verification numbers (i.e., PIN numbers) referred to as CHV1 and CHV2. Cardholder ID application 406 suitably may comprise various files related to personal information of the cardholder (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 FIG. 5. Payment system application 408 suitably may comprise information 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 may comprise a full EMV-compliant application suitable for a wide range of financial transactions. Payment system application 408 is described further below in conjunction with FIG. 6.

Airline application 410 suitably may comprise data helpful in streamlining commercial airline travel; for example, relevant personal preferences, electronic tickets, and frequent flier information. Airline application 410 is discussed in greater detail below in conjunction with FIG. 7. Hotel application 412 suitably may comprise information useful for securing and paying for hotel reservations, including an array of information and preferences associated with a list of preferred hotels as well space for electronic keys. Hotel application 412 is discussed in greater detail below in conjunction with FIG. 9. Rental car application 414 suitably may comprise data useful in expediting the process of car rental and return, including, for example, car preference and frequent rental information. Rental car application 414 is described in further detail below in conjunction with FIG. 8. In each of the above mentioned applications, sophisticated access and encryption schemes may be, in one embodiment, utilized in order to allow multiple parties to make use of certain file structures while preventing unauthorized entry into others. More specifically, partnering organizations (e.g., hotel chains, airlines, and rental car agencies) may create their own tailor-made file structures (i.e., "partner file structures") within card 100.

Referring now to FIG. 10, smartcard 100 may be suitably used in the context of a distributed transaction system. Briefly, cardholder's may employ smartcard 100 at various access points 15 which may be connected via network 19 to an issuer 10 and at least one partnering organization 12. Issuer 10 suitably may comprise various hardware and software components suitable for client host communications as well as a database system 11. In this context, the term 'issuer' refers to the organization that actually issues the smartcard and retains some high-level access to certain areas of file structure 400.

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 within smartcard 100. Each partnering organization 12 suitably may comprise a database 13 and appropriate hardware and software components necessary for completing a transaction over network 19. Network 19 may comprise the various components, databases, modules, and apparatus described above connected via a suitable data communication network. Such a network may consist of various physical connections using a variety of conventional data protocols, for example, the TCP/IP protocol. It may be appreciated that the individual connections between components of the present system may differ. For example, network 19 may comprise a wireless PCS network, a Internet TCP/IP connection, a public switched telephone network (PSTN), a digital and analog wireless networks, and the like.

Those skilled in the art may appreciate that a variety of hardware systems may be suitable for implementing the present invention. Various modems, routers, CPU's, monitors, back-up systems, power-supplies, and peripherals may be employed to realize the benefits of the present system. In one embodiment, for example, a Compaq Praline computer operating in an OS/2 environment using IBM MQ Server software may be used to implement servers used for the present invention. Further a Compaq Prolinea computer operating in a Windows/NT environment running a suitable database software package may facilitate data exchanges in accordance with the present invention.

Each access point 15 suitably may comprise an appropriate card reader 104 for interfacing with smartcard 100 as well as hardware and software suitable for interfacing with a cardholder and performing a transaction over network 19. Smartcard access points 15 allow the cardholder to gain access to the distributed transactions system through a variety of means. Such access points may include, for example, standard home telephones, various PCS wireless systems, pay phones, palmtop computers, notebook computers, Internet workstations, automated teller machines (ATMs), point of sale terminals (POS) stand-alone kiosks, network computers (NCs), personal data assistants (PDAs), or any other suitably configured communication apparatus. Access points 15 may be portable (as in the case of PDAs and cellular phones) or centrally located, for example, in airline ticketing and gate areas, rental car facilities, hotel lobbies, travel agencies, and malls. In addition, businesses may see fit to host an access point 15 to streamline their employees' business travel. In an exemplary embodiment, various access points 15 may be configured to interface with contact-based smartcards 100 in accordance with the relevant portions of the ISO-7816 standard.

Referring now to FIG. 7, airline application 410 preferably may comprise directory EF 730, common DF 702, and issuer DF 704, and additional airline applications 703(a), 703(b), and so on. Directory EF 730 preferably may include a list of application identifiers and labels as described above in the context of cardholder ID application 406. Common DF 702 generally may include data accessible to all participating airlines, while issuer DF 704 generally may include data which may only be read or written to by the smartcard issuer. Airline application 410 preferably further may comprise 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 may have similar access to DF 703(b). These partner DFs preferably conform to the relevant portions of the IATA specification.

referring now to FIG. 8, rental car application 414 preferably may comprise common DF 802, directory EF 820, and one or more rental car DFs 803 (i.e., 803(a), 803(b), and so on) corresponding to individual rental car agencies. Common DF may comprise preferences EF 805, which is described in detail below. Rental car DFs 803 each comprise a rental car id EF 807, reservation EF 809, and expenses EF 811. Directory EF 820 may include a list of application identifiers and labels for the various DFs under rental car application 414. The structure of this EF preferably conforms to that described above in the context of cardholder ID application 406. FIG. 9, hotel system application 412 preferably may comprise directory EF 920, common DF 914, one or more hotel chain DFs 902, and one or more property DFs 903. Common DF 914 may comprise reservation EF 918, expenses EF 916, key-of-the-room EF 910, and preferences EF 912. Hotel chain EFs 902(a), 902(b), and so on, comprise preferences EF 904 and stayer ID EF 906 associated with individual hotel chains. In contrast, property EFs 903(a), 903(b), and so on, comprise a similar file structure associated with individual hotel properties (i.e., independent of whether the particular hotel may be a member of a nationwide chain).

Transactions Having thus given a detailed description of an exemplary smartcard 100 and an exemplary data structure 400, the various details related to transactions involving smartcard 100 may now be described. In general, a typical smartcard session involves: (1) activation of the contacts (or comparable non-contact means); (2) card reset; (3) Answer to 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 may communicate with a card reader provided at an access point 15, and suitable connections may be made between communication region 108 on card 100 and the card reader. By "may communicate," a user may swipe card 100, insert card 100 into access point 15 and/or a reader associated with access point 15, and interact with access point 15 via communication region 108 by any suitable communication channels, such as, for example, a telephone network, an extranet, an intranet, Internet, point of interaction device, online communications, off-line communications, wireless communications, transponder communications, local area network (LAN), wide area network (WAN), networked or linked devices and/or the like. Communication may entail the use of one or more biometric security systems described in greater detail herein.

In an exemplary embodiment, physical contacts (contacts 106 in FIG. 1) may be used, and DATA, CLOCK, RESET, VDD, and GND connections may be made. These contacts may be electrically activated in a particular sequence, preferably in accordance with ISO 7816-3 (RST to low 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 string (ATR) on the DATA line, preferably in conformance with the content and timing details specified in the appropriate parts of ISO 7816. In an exemplary embodiment, the interface characters may be chosen to reflect a T=1 protocol (asynchronous, half-duplex, block-oriented mode). Further in accordance with ISO-7816 3, after the card sends an ATR string and the proper protocol may be selected (in an exemplary embodiment, the T=1 mode), host 314 and card 100 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 smartcard session, contacts 106 may be deactivated. Deactivation of contacts 106 may be 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 may be not utilized in an exemplary embodiment. In the context of the present invention, command classes and instructions may be 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 may be suitably directed at selecting, reading, and updating individual records or groups of records within files. Security commands may 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 (CHV1 and CHV2). Card management commands may suitably include commands which allow for the creation and deletion of directories (DFs) and elementary files (EFs). Miscellaneous commands may be suitably provided for modifying the baud rate and reading various card statistics (e.g., data logged during production of the card.) It may be appreciated that many different command sets could be designed for implementing these basic functions. One such command set may be provided by the IBM Multifunction Card Operating System 3.51, hereby incorporated by reference.

Referring again to FIG. 10, access point 15 preferably may comprise software which may provide a user interface (for example, a graphical user interface) and may be 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 FIG. 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 cardholder 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-through textual or graphical means, and the appropriate value may be sent to card 100 by the application program as part of a command string. This value may then be sent to the appropriate partnering organization 12 (i.e., a rental car partner) and issuer 10 over network 19 to be stored in their respective databases 13 and 11. 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 reader deployed at a suitable access point 15. After appropriate initialization procedures take place, the cardholder may be 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 exemplary programs EF 524 in cardholder ID application 406 and display these hotels first within the list of possible choices. After 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 may involve 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 may be downloaded into the confirmation number field in reservation EF 918 along with the date and the property code of the hotel. This step may require the cardholder to transmit appropriate credit card information, which may be suitably retrieved from payl EF 604. Upon arrival at the hotel, the cardholder may use smartcard 100 to access a kiosk 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 may be used primarily to streamline the check-in process initiated by personnel at the front desk. At check-in, the confirmation number information may be retrieved from reservation EF 918, and a particular room may be assigned (if not assigned previously). This step may typically involve retrieving, from the appropriate preference file (i.e., preferences EF 904 or 912), a list of preferences regarding 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 may be 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 may be then employed as part of the door lock apparatus for each room, which may be configured to open only upon receiving the correct key. At check-out time, payment may take place using payment card information stored in payment card EF 510 and payl EF 604. Again, a suitable smartcard reader (i.e., a reader configured with access point 15), may be provided in any location convenient for check out, e.g., the hotel lobby or within the individual hotel rooms themselves. The cardholder may then acquire frequent stayer points, which would involve updating one of the stayer ID

EFs 906 (or 936). During the course of his stay at the hotel, the cardholder may have incurred any number of expenses related to room-service, 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. The task of assigning a car would involve retrieving car preferences stored within preferences EF 805 and comparing them to a database of available automobiles. Upon returning the automobile, the cardholder may then be awarded frequent rental points (through update of frequent renter EF 807), and an expense record may be stored within expenses EF 811. In the airline context, card 100 could be used 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.

The system in accordance with various aspects of the present invention may include methods and apparatus for personalizing and dynamically synchronizing smartcards and associated databases in the context of a distributed transaction system. More particularly, referring now to FIG. 11, an exemplary dynamic synchronization system (DSS) preferably may comprise a secure support client server 1104, a card object database update system1106 (CODUS), one or more enterprise data synchronization may interface 1108 (EDSI), an update logic system 1110, one or more enterprise data collection units 1112 (EDCUs), and one or more smartcard access points 15 configured to interoperable accept and interface with smartcards 100. In an exemplary embodiment, DSS also suitably may comprise a personalization system 1140 and an account maintenance system 1142 configured to communicate with CODUS 1106.

More particularly, in an exemplary embodiment, secure support client server 1104 may be connected over a suitable network to EDSIs 1108 through enterprise network 1114. EDSIs 1108 may be linked to update logic system 1110, which itself may be linked to enterprise data collection units 1112. Enterprise data collection units 1112 may be linked to CODUS 1106 and secure support client server 1104. In general, as described in further detail below, each enterprise (e.g., airline partner, hotel partner, travel agency, etc.) may be preferably associated with a corresponding EDSI 1108, enterprise network 1114, and EDCU 1112. That is, EDCU 1112(a) corresponds to EDSI 1108(a) and enterprise network 1114(a), EDCU 1112(b) corresponds to EDSI 1108(b) and enterprise network 1114(b), and so on. The DSS may include an arbitrary number of such functional blocks in accordance with the number of enterprises represented.

Account maintenance system 1142 may be provided for customer service purposes and, in this capacity, acts as the point of entry for cardholder complaints, questions, and other customer input. CODUS 1106 suitably may communicate with account maintenance system 1142 in order to assist customer service representatives and/or automated systems in addressing cardholder issues. Enterprise network 1114 may be configured similarly to network 19 described above. Those skilled in the art will appreciate that a variety of hardware systems are suitable for implementing the present invention. Various modems, routers, CPU's, monitors, back-up systems, power-supplies, and peripherals may be employed to realize the benefits of the present system. In one embodiment, for example, a Compaq Prolinea computer operating in an OS/2 environment using IBM MQ Server software is used to implement secure support client server 1108, wherein the various access points comprise stand-alone smartcard kiosks, an EDCU 1112 and CODUS 1116 is then implemented on a Compaq Prolinea computer operating in a Windows/NT environment running a suitable database software package.

Referring now to FIGS. 11 and 12, an exemplary secure support client server 1104 may comprise a security engine 1202, a supplemental application support 1204, and a router 1206. Security engine 1202 may comprise suitable hardware and/or software to provide secure messaging between server 1104, EDSUs 1112, and enterprise network 1114. More specifically, security engine 1202 may utilize authentication, data encryption, and digital signature techniques in connection with incoming and outgoing message packets. A variety of conventional security algorithms may be suitable in the context of the present invention, including, for example, DES encryption, RSA authentication, and a variety of other symmetrical and non-symmetrical cryptographic techniques.

Supplemental application support 1204 preferably may comprise suitable hardware and/or software components related to a specific access point 15 functionality. More particularly, server 1104 may suitably determine the nature of access point 15 utilized during a transaction. If access point 15 does not include the appropriate software for effecting the requested transaction, then server 1104 supplies the functionality (i.e., software modules) which completes the transaction with respective EDSIs 1108 and/or EDCUs 1112. The supplemental functionality may include, inter alia, software modules for properly formatting message packets (described in further detail below) sent out over the various networks comprising the DSS. For example, where a transaction takes place via an access point 15 which may consist entirely of a stand-alone smartcard reader 2500, then nearly all functionality may be supplied by server 1104 because the smartcard reader, by itself, may be only capable of transferring messages to and from smartcard 100 in a "dumb" manner. However, when a suitably configured PC may be included for access point 15, most necessary functionality may be supplied by various software modules residing in the PC. In such a case, server 1104 may need only transfer the various message packets to and from access point 15 without supplying additional software. Added functionality may be supplied through any suitable method, for example, through the use of portable software code (e.g., Java, ActiveX, and the like), or distributed software residing within access points 15, cards 100, and/or server 1104.

Router 1206 may suitably handle routing of messages to the appropriate EDCUs 1112, enterprise network 1114, and access points 15. That is, router 1206 may be configured to identify the appropriate functional blocks within the DSS to which a given message packet should be sent. The identification of the appropriate functional blocks may take place in a number of ways. In an exemplary embodiment, the identification may be accomplished through the use of a look-up table comprising a list of appropriate destinations keyed to information extracted from requests received from access points 15.

Secure Support Client Server Secure support client server 1104 may provide, where appropriate, any functionality missing from the individual access point 15 used during a transaction. Server 1104 also may suitably handle routing of messages from access points 15 to the appropriate EDSI 1108 and/or EDCU 1112. B Referring now to FIGS. 11 and 12, an exemplary secure support client server 1104 may comprise a security engine 1202, a supplemental application support 1204, and a router 1206. Security engine 1202 may comprise suitable hardware and/or software to provide secure messaging between server 1104, EDSUs 1112, and enterprise network 1114. More specifically, security engine 1202 may utilize authentication, data encryption, and digital signature techniques in connection with incoming and outgoing message packets. A variety of conventional security algorithms may be suitable in the context of the present invention, including, for example, DES encryption, RSA authentication, and a variety of other symmetrical and non symmetrical cryptographic techniques.

Supplemental application support 1204 preferably may comprise suitable hardware and/or software components related to a specific access point 15 functionality. More particularly, server 1104 may suitably determine the nature of access point 15 utilized during a transaction. If access point 15 does not include the appropriate software for effecting the requested transaction, then server 1104 supplies the functionality (i.e., software modules) which completes the transaction with respective EDSIs 1108 and/or EDCUs 1112. The supplemental functionality may include, inter alia, software modules for properly formatting message packets (described in further detail below) sent out over the various networks comprising the DSS. For example, where a transaction takes place via an access point 15 which may consist entirely of a stand-alone smartcard reader 2500, then nearly all functionality may be supplied by server 1104 because the smartcard reader, by itself, may be only capable of transferring messages to and from smartcard 100 in a "dumb" manner. However, when a suitably configured PC may be included for access point 15, most necessary functionality may be supplied by various software modules residing in the PC. In such a case, server 1104 may need only transfer the various message packets to and from access point 15 without supplying additional software. Added functionality may be supplied through any suitable method, for example, through the use of portable software code (e.g., Java, ActiveX, and the like), or distributed software residing within access points 15, cards 100, and/or server 1104.

Router 1206 may suitably handle routing of messages to the appropriate EDCUs 1112, enterprise network 1114, and access points 15. That is, router 1206 may be configured to identify the appropriate functional blocks within the DSS to which a given message packet should be sent. The identification of the appropriate functional blocks may take place in a number of ways. In an exemplary embodiment, the identification may be accomplished through the use of a look-up table comprising a list of appropriate destinations keyed to information extracted from requests received from access points 15.

In an alternate embodiment of the present invention, a secure support client server 1104 may be not used, and the functionality of access points 15 may be suitably specified in order to obviate the need for server 1104. Alternatively, the functions of server 1104 may be allocated and distributed throughout the DSS components in any advantageous manner. Following branch 1807 in FIG. 14, the change data may be sent to and stored in the appropriate EDSI 1108 (step 1808). Update logic system 1110 then transfers this change request to the appropriate EDCU 1112-i.e., the EDCU 1112 corresponding to the particular EDSI (step 1810). This information may be suitably stored in the corresponding update database 1504. The information may be also distributed to other EDSIs. In the instant example, update logic system 1110 would identify those systems that would benefit from knowing the cardholder's smoking status. Such systems may include, for example, various hotels, rental car agencies, and the like. Alternatively, following branch 1805 in FIG. 18, the data may first be stored at the appropriate EDCU (step 1812), then distributed to other EDUCs 1112 and EDSIs 1108 as described above.

The card data change may be then transferred to CODUS 1106. Specifically, the various fields and files associated with the smartcard 100 may be updated to reflect the change stored in update database 1504. Thus, the information within CODUS 1106 conforms to that contained within smartcard 100 and the various EDCUs 1112 and EDSIs 1108. After this transfer, the corresponding change data in update database 1504 may be cleared (step 1818). FIG. 13, depending, to some extent, upon which party originates the file structure change. That is, as in step 1712, the appropriate file structure change information may be stored in EDCU 1112 (for example, in database 1502), and then transferred to smartcard 100 when the card may be used in conjunction with an on-line transaction (steps 1710 and 1712). After the file structure on smartcard 100 may be augmented or otherwise modified, CODUS 1106 (specifically, database 1116) may be similarly modified to reflect the change. The change information may be then cleared from database 1502 (step 1716).

While the example transactions set forth above are described in general terms, the particular nature of data flow to and from the appropriate memory locations within the card may be apparent to those skilled in the art. With reference now to FIG. 15, in one exemplary embodiment of the present invention, a data set management system ("management system") 200 comprises a merchant system 220, various issuer systems 230, and a financial transaction device 240. Management system 200 may further be accessed by a user 201 on a self-service interaction device, such as, for example, user computer 250 or via a transaction device such as, for example, kiosk 270, stand-alone interaction device 290, automated teller, or the like. In these examples, communications between user computer 250 or kiosk 270 and merchant system 220 or issuer systems 230 may take place via, for example, a network 260. In various embodiments, merchant system220, user computer 250 and/or kiosk270are configured to communicate with financial transaction device 240. For example, communication with the financial transaction device 240 may be facilitated by a point of read/write device 280, such as a merchant point of sale, merchant RFID reader, computer interface, or the like, configured to receive information provided by the financial transaction device 240.

In general, merchant system 220 is configured to interact with a user 201 attempting to complete a transaction, and to communicate transaction data to one or more of issuer systems 230. Issuer systems 230 are configured to interact with financial transaction device 240 to receive and/or exchange data facilitating a transaction. Merchant system 220 may be operated, controlled and/or facilitated by any merchant that accepts payment via a transaction device. Merchant system 220 is configured to facilitate interaction with user 201, which may be any person, entity, software and/or hardware. The user 201 may communicate with the merchant in person (e.g., at the box office), or electronically (e.g., from a user computer 250 via network 260). During the interaction, the merchant may offer goods and/or services to the user 201. The merchant may also offer the user 201 the option of completing the transaction using a financial transaction device. The merchant system may provide the options to the user 201using interactive user interface, suitable website or other Internet-based graphical user interface that is accessible by users.

Each user 201 may be equipped with a computing system to facilitate online commerce transactions. For example, the user 201 may have a computing unit in the form of a personal computer (e.g., user computer 250), although other types of computing units may be used including laptops, notebooks, hand held computers, set-top boxes, and/or the like. The merchant system 220 may have a computing unit 222 implemented in the form of a computer-server, although other implementations are possible. The issuer system 230 may have a computing center such as a main frame computer. However, the issuer computing center may be implemented in other forms, such as a mini-computer, a PC server, a network set of computers, or the like.

Issuer system 230 may be configured to manipulate a transaction account associated with the corresponding issuer-owned data stored on the transaction device 240 (or database 282, discussed below) in accordance with a related transaction. For example, the issuer system 230 may receive "transaction information" and manipulate an account status or balance in accordance with the information received. In accordance with the transaction amount, the issuer system 230 may, for example, diminish a value available for completing a transaction associated with the account, or the issuer system 230 may alter the information relative to the account user (e.g., demographics, personal information, etc.).

It should be noted that issuer systems 230 may also be configured to interact with financial transaction device 240, directly or indirectly via database 282 or standalone interaction device 290, to individually manage data sets on financial transaction device 240. For example, issuer systems 230 may manage data sets on database 282. In some embodiments, the data sets on database 282 may then be stored on financial transaction device 240 when the transaction device is presented. In other embodiments, issuer systems 230 may store data set information within their own systems which may communicate with the financial transaction device via user computer 250, kiosk 270, or merchant system 220. In such embodiments, the issuer system 230 may be configured to push the data set to the financial transaction device 240 via the stand alone interaction device 290, or the merchant system 220, kiosk 270, interaction device 290 or computer 250 which may be configured to pull such information from the issuer system 230.

In addition, the data may be manipulated using, for example, a standalone interaction device 290 configured to communicate with at least one of the issuer systems 230 which may or may not be configured to communicate with a merchant system 220. The interaction device 290 may communicate with the issuer systems 230 using any of the aforementioned communication protocols, techniques and data links. The communication between the stand alone interaction device 290 and the issuer system 230 may be facilitated by a network 260. In an exemplary embodiment, the network 260 may be secure against unauthorized eavesdropping.

Interaction device 290 may provide instructions to the issuer systems 230 for requesting receipt of issuer-owned data, such as for example, account data, user member identification data, member demographic data, or the like, which the issuer wishes to store on the financial transaction device 240. The interaction device 290 may communicate with the issuer systems 230 using an issuer recognizable communications protocol, language, methods of communication and the like, for providing and receiving data. In one exemplary embodiment, issuer-owned data is received by the interaction device 290 from issuer systems 230, and stored onto the financial transaction device 240. The data may be stored or manipulated in accordance with the issuer provided instructions, protocol, storage format, header or trailers received by the interaction device from issuer systems 230.

The issuer-owned data may be stored on the financial transaction device 240 in any format recognizable by a merchant system 220, and further recognizable by issuer system 230. In one exemplary embodiment, the issuer owned data is stored using a issuer system 230 format which may be later formatted in merchant system 220 recognizable protocol when provided to the merchant system 220. In one embodiment, the issuer owned information is stored on the financial transaction device 240 in the identical format with which it was provided by the issuer system 230. In that regard, interaction device 290 may be any device configured to receive issuer-owned data from an issuer system 230, and write the data to a database, such as, for example, a database on transaction device 240 or database 282. Further, as described more fully below, the issuer-owned information may also be provided by the issuer system 230 to a remote database 282 where the information is stored such that it mirrors the corresponding information stored on the transaction device 240.

Interaction device 290 may be initialized prior to use. For example, the interaction device 290 may be any system which may be initialized ("configured") to communicate with a merchant system 220. Where the interaction device is not initialized prior to attempting communications with the merchant system 220 or transaction device 240, the interaction device 290 may be initialized at the merchant system 220 location. The interaction device 290 may be initialized using any conventional method for configuring device communication protocol.

As noted, in accordance with the invention a transaction device is provided which permits the storage and presentment of at least one of a plurality of data sets for completing a transaction. The data sets may be stored on the transaction device itself, or on a remote database, as described below. The data sets stored with regard to the transaction device may be modified, deleted, added or augmented, as required by the issuer or the user. For example, as owner of the data, an issuer may modify a data set at the issuer's discretion.

The issuer may modify the data, data subsets, member identifier and/or applications or data sets associated with its transaction account program. Such modifications may be completed or substantially completed in substantially real-time or at a later date, for example, when the transaction device is next presented.

In a typical example of issuer modification of the data sets, one or more data sets may be modified by the issuer system 230 directly via the issuer systems 230, upon presentment of the financial transaction device 240 to the system 230. That is, the user 201 may present the card to the issuer system 230, and the issuer system 230 may modify the issuer data stored thereon, using any issuer defined protocol. Alternatively, the modifications, or instructions for modification, may be initiated at the issuer system 230, and provided to the network 260. The modifications and/or modification instructions may additionally be provided to a suitable device configured to communicate with the transaction device 240, receive information regarding the data stored on transaction device 240, and to write or overwrite the information contained on transaction device 240.

For example, as noted, interaction device 290 is a suitable interaction device which may be used to provide information to the transaction device 240 to modify the information stored thereon. Interaction device 290 may be any device capable of receiving data management instructions from the issuer systems 230 and for updating the data stored on the transaction device 240, in accordance with the instructions received. In this regard, the interaction device 290 may include any electronic components, databases, processors, servers and the like which may be used to modify the data stored on transaction device 240 using any suitable data modification protocol as is found in the art. Preferably, the interaction device is configured to modify the data on the transaction device in accordance with a data owner defined protocol.

In one exemplary the interaction device 290, may be configured to modify the transaction device's 240 issuer-owned data when the transaction device 240 is initially configured, prior to providing the transaction device 240 to the user 201. The interaction device 290 may additionally be configured to modify the issuer data on the transaction device 240 when the transaction device 240 is next presented, for example, to the stand alone interaction device 290. In this regard, the interaction device 290 may receive from multiple distinct issuer systems 230, via the network 260, the issuer provided modifications/instructions and may update the transaction device 240 in real-time or substantially real-time. The modifications may be provided to the interaction device 290 for storage and later use when the transaction device 240 is next presented. Alternatively, the interaction device 290 may be configured to retrieve the instructions from the issuer system 230 when the transaction device 240 is next presented to device 290. Further, where other devices, such as, for example, a kiosk 270, merchant point of sale device, or the like, are likewise configured to modify the issuer data on transaction device 240, the invention contemplates that the real-time or substantially real-time modifications noted above may be made using those devices in similar manner as is described with the interaction device 290.

Alternatively, the device to which the transaction device 240 may be presented, may not be equipped for updating or modifying the data stored on the transaction device 240. For example, merchant system 220 may be any conventional merchant system which communicates to an issuer system 230, and which permits a user 201 to complete a financial transaction, but which is not configured to modify the issuer data contained on the transaction device 240. In general, conventional merchant systems are not configured to write or overwrite data included on the payment devices presented to the merchant system for processing. That is, the merchant system 220 may include little or no additional software to participate in an online transaction supported by network 260. Management of the data sets on transaction device 240 may be performed independent of the operation of the merchant system 220 (e.g., via issuer system 230 or interaction device 290). As such, the present invention may require no retrofitting of the merchant system 220, to accommodate system 200 operation. Thus, where the merchant system 220 is not configured to modify the data on the transaction device 240, such modifications may be made as described above with respect to modifications being made at the interaction device 290 or by the issuer at the issuer system 230.

The merchant system 220, kiosk 270, interaction device 290, may include additional means for permitting the transaction device user 201 to self-manage the data stored on the transaction device 240. In this case, the systems 220, 270, and 290 may include an additional user interface for use by the user 201 to identify the modification action to be taken. Where the systems 220, 270, and 290 are configured to communicate with the transaction device 240 and to modify the data thereon, the modifications may be completed or substantially completed in real-time or substantially real-time. For example, the user 201 may present the transaction device 240 to one of the systems 220, 270, or 290, provide instructions to the system 220, 270, or 290 for modifying the data on transaction device 240. The instructions may include, for example, "ADD," "DELETE," MODIFY," and the system 220, 270, or 290 may modify the data stored on the transaction device 240 in accordance therewith. The modifications may be made on the instrument in real-time or substantially real-time, for example, prior to permitting the transaction device 240 to be used by the user 201.

Alternatively, the modifications or instructions for modification may be provided by the user 201 to the merchant system 220 or kiosk 270, and the merchant system 220 or kiosk 270 may further provide the modifications/instructions to the network 260 for use in later modifying the data. For example, the modifications/instructions may be provided by system 220 or 270 to the issuer system 230 managed by the issuer owning the data to be modified. The issuer system 230 may provide the modifications to, for example, interaction device 290, for updating the transaction device 240 when next presented. The modifications/instructions may additionally be provided from the network 260 to a remote database, where the issuer-owned data corresponding to the transaction device and the issuer may be additionally stored (i.e., database 282, described below). In one exemplary embodiment, the modifications/instructions may be stored at the issuer system 230, until such time as the transaction device 240 is next presented to a device configured to modify the data on the instrument. Once presented, the modifications/instructions may be provided to the device (e.g., computer 250, interaction device 290, etc.) for modifying the transaction device 240 data.

The user 201 may self-manage the data sets by, for example, modifying the data sets using a conventional computer system 250, which may be in communication with the network 260. Computer system 250 may or may not be configured to interact with financial transaction device 240. Where the computer system 250 is not configured to interact with the transaction device 240, the user 201 may provide modifications or instructions to the issuer system 230 for later use in modifying the corresponding transaction device 240 data, for example, when the transaction device 240 is next presented in similar manner as described above. Where the computer 250 is configured to interact with the financial transaction device 240 to modify the data stored thereon, the user 201 may provide modifications/instructions to the computer 250 for modifying the data on the financial instrument in real-time or substantially real-time. That is, the computer 250 may be configured to interact with, read, add, delete, and/or modify the data sets on the transaction device 240.

Consequently, the computer 250 may receive modifications/instructions from the user 201 and perform the modifications accordingly, and may modify the data in real-time or substantially real-time. The computer 250 may additionally be configured to receive authorization of the modifications/instructions from issuer system 230 prior to making the user 201 requested changes. In one exemplary arrangement, the user 201 may provide the modifications/instructions via the network 260 which may be additionally provided to the issuer system 230. The issuer system 230 may receive the user 201 modifications/instructions and verify whether the identified updates are available to the user 201 or if the identified updates are valid. If the identified updates are authorized, the issuer system 230 may update a data storage area associated with the transaction device 240. For example, the issuer system 230 may update an issuer database (not shown) containing data corresponding to the issuer-owned data associated with the transaction device 240. Alternatively, the issuer system 230 may provide modifications/instructions to a database positioned remotely to the issuer system 230 for use in modifying the data stored thereon, which is associated to the transaction device 230. As such, in accordance with the present invention, a user 201 may self manage the data via, for example, the user computer 250, a kiosk270, a merchant system 220, and/or a stand-alone interaction device 290.

In one exemplary method of self-management, a user 201logs onto a website via user computer 250, or onto a stand-alone device, such as, for example, interaction device 290 or kiosk 270, and selects options for configuring data sets on a financial transaction device 240. The changes may be transmitted to the transaction device 240 via a instrument reader/writer device 280 configured to communicate the data to transaction device 240. In this context, the reader/writer device 280 may be any conventional transaction device reader or writer.

As noted, modifications to the data stored on the financial transaction device 240 may be made in real-time or substantially real-time when the transaction device 240 is presented to the interaction device 290, or to a reader/writer device 280. However, as noted, various embodiments of the invention include a remote database 282 in communication with an issuer system 230 via a network 260. The remote database 282 may additionally be in communication with one of the user computer 250, kiosk 270, merchant system 220 and/or the interaction device 290, for variously receiving modifications or instructions for performing modifications to the data stored thereon.

In addition, database 282 may contain a data storage area which "mirrors" the data stored on transaction device 240. In this context "mirrored" or "mirror" may mean that the data is stored on database 282 in substantially identical configuration and format as stored on the transaction device 240. As such, the present invention may be configured to permit modifications made to transaction device 240 data to be mimicked on corresponding data locations on database 282. For example, the user 201 may self manage the data on the database 282 via a user interface in communication with the database 282 via the network 260. In one exemplary embodiment, the user 201 may communicate with a "website" which is used to manage the database 282, wherein database 282 is a database including unique locations for storing the issuer provided data and data sets correlative to the data and data sets stored on the transaction device 240.

The website may include an account management application which permits the user 201 to select which user accounts to add, delete, or modify with respect to the transaction device 240. That is, the user 201 may provide unique identifying information to the user computer 250 which may be recognized by the system (e.g., issuer system 230 or remote system managing the database 282) managing database 282, thereby permitting the user 201 to access the data corresponding to the unique identifying information stored on database 282. Further, prior to permitting modifications to the database 282, the issuer owning the data may require authorization that such modifications may be performed. Further still, the present invention contemplates that database 282 may be self-managed by the user 201 in similar manner, where the merchant system 220, kiosk 270 and/or interaction device 290 are configured to provide modifications/instructions to the issuer systems 230 and database 282.

The database 282 serves as a temporary or redundant storage space for data sets. Thus, a "mirror image" of the data sets currently on the financial transaction device 240 may be maintained and/or updated at appropriate intervals for facilitating replacement of, for example, a damaged financial transaction device 240. As such, database 282 may be used, for example, for verifying the validity or accuracy of the information stored on the transaction device 240. Also, changes to one or more data sets may be stored to database 282 pending an opportunity to update the financial transaction device 240. In various embodiments, such updating may take place in both directions similar to hot sync technology.

The invention, authorization must be obtained from issuer systems 230 prior to making any modifications to the data contained on transaction device 240 or database 282. Authorization may be obtained by requesting the authorization during the modification process. Authorization may be given where the user 201 provides the more appropriate security information, which is verified by the issuer system 230. The security information may be, for example, a security code granting access to the issuer-owned data on the transaction device 240 or database 282. For example, a point of sale (POS) machine may be configured to allow the input of a code, or an answer to a prompt which is provided to and verified by issuer system 230. Once verified the modification requested may be made to the data contained on the financial transaction device 240.

It should be noted that the authorization code may be used to permit the user 201to select which issuer provided data to utilize for completion of a transaction. For example, a Point of sale Device (POI) device may be programmed to search the financial transaction device 240 for a data set containing a particular club membership data set, or to locate all available data sets for providing to a user 201 display available data sets to the user 201, thereby permitting the user 201 to select which data set to use to complete a transaction. If no data set is found, the POS device may alert the user 201 or prompt the merchant to alert the user 201 of the possibility of adding issuer-owned data to the financial transaction device 240. A positive response to this alert may cause the POS device to add an issuer data set to the transaction device 240.

It is noted that the user 201 may already be a member of a membership program managed by an issuer system 230 in which case the associated user 201 membership data may be assigned to user 201 for inclusion on transaction device 240. As such, the user 201 may be permitted to add the membership data set to the transaction device 240. Alternatively, the user may become a member by selecting to add the membership information to the financial transaction device 240, using the interactive device 290. In some embodiments, changes made to the data sets stored on the transaction device 240 may be updated to the financial transaction device 240 in real-time or substantially real-time, where the device 290 is in communication with the transaction device 240. Or the changes may be made the next time the user 201 presents the financial transaction device 240 to stand alone interaction device 290 or to a kiosk 270, merchant system 220, or the like.

The invention, merchant system 220, kiosk 270, and/or user computer 250 may be configured to interact with financial transaction device 240 via a read/write device 280. Read/write device 280 may be any device configured to communicate with financial transaction 240. In one embodiment, read/write device 280 is configured to read and write to financial transaction device 240. For example, read/write device 280 may be a point of sale magnetic card reader/writer. In another example, where the transaction device 240 includes a RF transmitter/receiver for communicating with system 200, read/write device 280 may include a mating transponder configured to receive and transmit issuer-owned data. Read/write device 280 may be configured to select data sets for use by a merchant using any suitable selection technique including but not limited to proprietary commands or command sequences or use of ISO/IEC 7816-4 application selection sequences (e.g., GET command).

In one exemplary embodiment, management of data sets is facilitated by annotating the data set with a status indicator (e.g., condition header); (e.g., LOADED, INITIALIZED, READY, BLOCKED, REMOVABLE or DELETED). In this regard, a data set may have a LOADED status when the information related to that data set has been stored in association with the financial transaction device 240, but remains dormant. For example, a credit card account may have been added to the financial transaction device 240 that has not yet been activated. In some instances, the loaded data set needs to be further configured before it is ready to be used. For example, the data set may be modified to include a particular branch in a chain of franchise stores, the identification of a user's 201 primary care physician, or to reflect a user's 201 selection of a platinum membership status. In another example, a loyalty program may be added in association with a financial transaction device 240, and the data set marked LOADED. In another example, the user 201 may interact with a kiosk 270 or the like to input personal information and configure the loyalty program data set. Once such a data set has been configured, it may be annotated with an INITIALIZED status.

The status of a data set may be set as READY when the data set is ready to be utilized. For example, a user 201 may enter a secret code to indicate that the user 201 is ready to use the data set. In one example, the data set may be marked as READY when that data set is first accessed to perform a transaction. It will be noted that in accordance with other embodiments of the present invention, the status of a data set may be set at READY the moment it is loaded to the financial transaction device 240. Furthermore, it is possible to change the status between READY, LOADED, and INITIALIZED, under appropriate circumstances. Thus, the data sets may be managed through any one or more of these states and in various orders.

It may also be desirable to prevent use of a data set and/or the associated functionality for a period of time. Thus, the status indicator may be set to BLOCKED. The setting of the status indicator to BLOCKED may, for example, disable the use of the data set. In one exemplary embodiment, an appropriately configured financial transaction device reader is configured to recognize the BLOCKED status indicator when accessing the data set and to prevent use of that data set example.

In addition, for various reasons, a user 201 may desire to remove a data set from a transaction card 240. The user 201 may, for example, desire to use the available space on the transaction card 240 for other data sets, or may remove the data set for security reasons. Furthermore, circumstances may arise where the owner of the data set desires to remove the data set from one or more transaction devices 240, such as when a coupon expires. In these instances, the data set may be marked as REMOVABLE. Under these circumstances, the memory associated with the data set is available to receive information associated with future added data sets, but for the moment retains the old data set. A REMOVABLE data set may again be made READY under various configurations.

The REMOVABLE data set may subsequently be removed from the financial transaction device 240 and marked DELETED. A DELETED status indicator may be used to indicate that a portion of the financial transaction device 240 is available to store one or more data sets. It is noted that data sets may be directly deleted without going through the step of making the data set REMOVABLE. In one example, a data set may be removed from the financial transaction device 240 if the security of the account associated with the data set is compromised (e.g., stolen password). Furthermore, as appropriate, the status of data sets may be changed to different states. Under appropriate circumstances one or more of any of the six status indicators LOADED, INITIALIZED, READY, BLOCKED, REMOVABLE, or DELETED or other suitable status indicators may be used to annotate a BLOB or other similar data set.

Although the data sets described herein may be managed without status indicators, nevertheless, such status indicators facilitate management of data. For example, regardless of a first data set owner's ability to interpret the information stored in a data set owned by another party, the first owner may interpret the status indicator to determine whether the data set is LOADED, DELETED, or the like. The determination that a data set is DELETED facilitates the addition of new data sets by independent owners without overwriting other data sets on the financial transaction device 240. In addition, the use of tags or status indicators may facilitate the use of global rules, which may simplify operations and/or commands. Status indicators may also enhance interoperability between data sets. Nevertheless, a data set owner may chose not to use a status indicator even if the opportunity is available.

Managing of the data sets (step 120) may include one or more of the following exemplary steps: add, update, modify, replace, verify, delete and/or the like. More particularly, FIG. 16 illustrates a general overview of an exemplary data set management method 300 comprising the steps of: loading a data set (step 310), initializing a data set (step 320), verifying availability of data set (step 330), and deleting a data set (step 340). In this manner, a data set may be added to a financial transaction device 240 and utilized until it is deleted. The adding and deleting steps are described in further detail with reference to FIG. 4 Furthermore, the ability to update, modify, replace and/or delete a data set may be subject to security requirements.

The various processes may include a user 201 facilitating the input of information into a data management system to cause the data set to be loaded. The information may be inputted via keypad, magnetic stripe, smart card, electronic pointer, touchpad and/or the like, into a user computer 250, POS terminal, kiosk 270, ATM terminal and/or directly into the merchant system 220 via a similar terminal or computer associated with merchant server 222. The information may be transmitted via any network 260 discussed herein to merchant system 220 or issuer systems 230. In another embodiment, the merchant may enter the information into an issuer system 230 on behalf to the user 201. This may occur, for example, when the user 201 and/or issuer system 230 authorizes the management of data sets on financial transaction device 240 over a telephone and the service representative inputs the information. In this embodiment, the transaction device 240 may be updated at the next presentment opportunity such as when the user 201 attempts to compete a transaction using the transaction device 240.

Any suitable procedures may be utilized to determine whether a data set is currently ready for use and available (step 330). In one example, when a financial transaction device 240 is presented, the availability of the data set is verified by checking whether the data set has been corrupted or blocked (step 332), or deleted (step 333). For example, the data set may be checked to determine if the data set has been accessed or altered without permission ("corrupted") or if the data set exists or has been removed from the transaction device 240 ("deleted"). The check may be performed using any suitable protocol or comparing data. If the answer to these questions is no, then the data set is available and ready for use (step 334). If the data is corrupted or blocked, subroutines may be used to attempt to retry reading the data (step 336). If the data set is marked deleted or removable, subroutines will prevent access to the data set (step 335) and remove the data set (step 340).

For example, a suitable subroutine may place a DELETE "marker" on the data set which prevents the data from being transmitted during completion of a transaction. The data set may then be marked for deletion and deleted from the transaction device 240 at the next presentment of the device. In similar manner, where the data set is corrupted, a CORRUPTED marker may be appended to the data set and the data set is prevented from being transmitted during completion of a transaction. The marker may be a header or trailer as discussed herein. Various methods may be used to add a data set to a financial transaction device 240 or to replace a data set on a financial transaction device 240. FIG. 17illustrates an exemplary method of adding a data set to a financial transaction device 240, including the general steps of presenting the financial transaction device 240 (step 410), verifying the addition of the data set to the financial transaction device 240 (step 420), placing the data set in a temporary holding area (step 430), and addingthe dataset(step 440).

More particularly, the user 201 presents the financial transaction device 240 (step 410) to a interaction device 280 configured to communicate with transaction device 240. The user 201 may present financial transaction device 240 at a point of purchase or to an interaction device 280 or kiosk 270. For example, the user 201 may wave the RF transaction device 240 in front of a POS machine in a retail store, which is configured to receive data from the device 240. Alternatively, the user 201 may present the financial transaction device 240 at a self-service location such as a kiosk 270 in a mall. Moreover, the user 201 may present the financial transaction device 240 to a peripheral device associated with a personal computer, or the like.

The user 201 is then given the opportunity to add a data set to the transaction device 240. For example, interaction device 280 may detect the absence of a particular data set on the transaction device 240 by searching the transaction device 240 data base and comparing the existing data sets to the data set to be added. If the data set to be added is not found on the data base, the user 201 may be prompted to confirm the addition of this data set to the transaction device 240 (step 420). The user may be prompted via an interactive user interface displaying the option to add the data set. In one example, when a user 201 presents a financial transaction device 240 to a merchant, the card reader detects the absence of a loyalty data set and provides a message on a display to the user 201 or the store clerk indicating that the loyalty data set can be added if desired. The user 201 may answer in the negative and complete the purchase using typical transaction methods (step 425). Alternatively, if user 201 provides an affirmative response, the algorithm may prepare a data set for communication with the financial transaction device 240 (step 430). The process may determine whether the data set (or information that may be used to create the data set) exists in some form or on some device other than on the financial transaction device 240 (step 432). Determining whether a data set exists may involve querying an issuer system 230, database 282, or the like.

For example, the issuer system 230 may compare the data set to other data sets the issuer system 230 has assigned to a particular user 201. If the data set is not assigned to a particular user, then issuer system 230 may determine that the data set is available for adding to the transaction device 240. Determining whether a data set exists may also take place when a store clerk verbally asks (or a screen prompts) the user 201 to present another card containing the information. For example, the data set may exist on a movie rental card and stored in magnetic stripe form, bar code, and/or the like.

If the data set exists in an accessible form, the data set may be captured (step 436). In this example, the user 201 may present the movie rental card and the data read from the movie rental card may then be stored in a data set associated with the financial transaction device 240. For example, the user 201 may desire to add a shopping loyalty card to the user's 201 financial transaction device 240. The user 201 may swipe, scan or otherwise present the loyalty card such that the data set from the loyalty card is captured. The system may be further configured such that the merchant, kiosk 270, or computer system may access an issuer system 230 to obtain information for creating the data set. Thus, if a user 201 does not have the movie rental card on the user's 201 person, the system 230 may prompt the clerk to request identifying/security information and to access the user's 201account and therefore facilitate adding a movie rental data set associated with the user's 201transaction device 240. Any other suitable methods of capturing data sets may also be used.

If the data set does not exist, a new data set may be created (step 434) for inclusion on the transaction device 240. Creation of the data set may, for example, involve filling out an application, providing name and address, creating an account, and/or the like. In either event, the pre-existing or newly created data set is temporarily held in a storage area (e.g., database 282, local memory or the like) for transfer to the transaction device 240 (step 438). Additional data sets may be prepared for transmittal to transaction device 240 (step 439).

In this exemplary embodiment, the transaction device 240 is presented again to read/write device 280 (step 442). Read/write device 280 is configured to attempt to transfer the data set(s) to the transaction device 240 (step 444). For example, existing read/write device 280 may be configured with software and/or hardware upgrades to transmit data to the transaction device 240. In one exemplary embodiment, if the data sets were not transferred correctly, the process may try the transfer again. In another exemplary embodiment, data sets are added one at a time or altogether. Thus, a user 201 may pass a card through a card reader/writer one or more times during the addition process. The transaction may be completed (step 425) using the new data set or another selected method of payment. The same steps may be used in a self-service embodiment, however, in one embodiment, no financial transaction takes place along with the addition of data sets. It should also be noted that under appropriate circumstances, a user 201may add data sets at a point of purchase without actually completing a purchase.

In various exemplary embodiments, the user 201 and/or the owner of the data set may manage the data set (i.e., steps 432-439) in advance of presenting the transaction device 240. For example, a user 201 on user computer 250 may choose to add or delete data sets via a website configured for management of data sets. In another example, an issuer system 230 may add functionality to an account and may desire to update the data set associated with that account. In either example, data sets that have been prepared in advance, may be ready for transmission upon presentment of the transaction device 240. The transmission of the data sets may be transparent to the user 201. For example, the user 201 may present the transaction device 240 (step 442) to complete a purchase and the waiting data sets may automatically be added to the user's 201 card (step 440).

Similar steps may be taken to replace or update data sets with new information. For example, a user 201 at a point of sale may be informed of an upgrade in functionality associated with an account or other data set. Following similar steps as discussed with reference to FIG. 17, the existing data set on the transaction device 240 is replaced with a new data set. Moreover, depending on permission rights and/or hierarchies in place, if any, an existing data set may be replaced with an unrelated data set. Other methods of adding and replacing data sets may also be used to manage data sets on a transaction device 240.

WE CLAIMS

1. The invention" loT-Based Micropayment Protocol for Wearable Devices with Biometric Verification "is a method for facilitating biometric security in a micropayment, smartcard-reader transaction system is provided. The invented method determining if a transaction violates an established rule, such as a preset spending limit and the method also includes notifying a user to proffer a biometric sample in order to verify the identity of said user, and detecting a proffered biometric at a sensor to obtain a proffered biometric sample. The method additionally comprises verifying the proffered biometric sample and authorizing a transaction to continue upon verification of the proffered biometric sample. The invented systems and methods are configured to manage data sets associated with a transaction device. For example, a method is provided for facilitating the management of distinct data sets on a transaction device that are provided by distinct data set owners. The method includes the steps of: 1: The adding, by a read/write, a first data set to the financial transaction device. 2: Wherein the first data set is owned by a first owner. 3. The adding, by the read/write device, a second data set to the financial transaction device. 4. Wherein the second data set is owned by a second owner. 5. The storing the first data set and the second data set on the financial transaction device in accordance with an owner defined format. The first and second data sets are associated with first and second owners, respectively, and are configured to be stored independent of each other the transaction device user may be permitted to select at least one of the multiple data sets for transaction completion using a secondary identifier indicium. Where the user selects multiple accounts for transaction completion, the user may be permitted to allocate portions of a transaction to the selected transaction accounts. The transaction request may be processed in accordance with the user's allocations. 2. According to claims# the invention is to a method for facilitating biometric security in a micropayment, smartcard-reader transaction system is provided. The invented method determining if a transaction violates an established rule, such as a preset spending limit and the method also includes notifying a user to proffer a biometric sample in order to verify the identity of said user, and detecting a proffered biometric at a sensor to obtain a proffered biometric sample. 3. According to claiml,2# the invention is to the method additionally comprises verifying the proffered biometric sample and authorizing a transaction to continue upon verification of the proffered biometric sample. The invented systems and methods are configured to manage data sets associated with a transaction device. 4. According to claiml,2,3# the invention is to a method is provided for facilitating the management of distinct data sets on a transaction device that are provided by distinct data set owners. The method includes the steps of: 1: The adding, by a read/write, a first data set to the financial transaction device. 2: Wherein the first data set is owned by a first owner. 3. The adding, by the read/write device, a second data set to the financial transaction device. 4. Wherein the second data set is owned by a second owner. 5. The storing the first data set and the second data set on the financial transaction device in accordance with an owner defined format. 5. According to claim,2,4# the invention is to the first and second data sets are associated with first and second owners, respectively, and are configured to be stored independent of each other the transaction device user may be permitted to select at least one of the multiple data sets for transaction completion using a secondary identifier indicium. 6. According to claim,2,4# the invention is to the user selects multiple accounts for transaction completion, the user may be permitted to allocate portions of a transaction to the selected transaction accounts. The transaction request may be processed in accordance with the user's allocations.

7. According to claim,2,4# the invention is to comprising verifying said first secondary identifier indicia and also the invention is to comprising authorizing a transaction request relative to said first data set. 8. According to claim,2,5# the invention is to wherein the step of completing a transaction request using said first data set comprises allocating a first portion of said transaction request to said first data set for transaction completion. 9. According to claiml,2,6# the invention is to comprising completing a transaction request using said second data set, wherein a second portion of said transaction request is allocated to said second data set for transaction complete.

Date: 20/8/2020

Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus)

FOR Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) 21 Aug 2020

Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 2020101940

FIG. 1: IS AN EXEMPLARY SMARTCARD APPARATUS.

FOR Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) 21 Aug 2020

Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 2020101940

FIG. 2: IS A SCHEMATIC DIAGRAM OF AN EXEMPLARY SMARTCARD INTEGRATED CIRCUIT, SHOWING VARIOUS FUNCTIONAL BLOCKS.

FOR Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) 21 Aug 2020

Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 2020101940

FIG. 3: IS AN EXEMPLARY DIAGRAM OF FILES AND DIRECTORIES ARRANGED IN A TYPICAL TREE STRUCTURE.

FOR Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) 21 Aug 2020

Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 2020101940

FIG. 4:IS A SETS FORTH AN EXEMPLARY DATABASE STRUCTURE IN ACCORDANCE WITH AN EXEMPLARY EMBODIMENT OF THE PRESENT INVENTION.

FIG. 5: IS A SETS FORTH AN EXEMPLARY CARDHOLDER ID DATA STRUCTURE IN ACCORDANCE WITH THE PRESENT INVENTION;

FOR Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) 21 Aug 2020

Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 2020101940

FIG. 6: IS A SETS FORTH AN EXEMPLARY PAYMENT SYSTEM DATA STRUCTURE IN ACCORDANCE WITH THE PRESENT INVENTION.

FIG. 7: IS A SETS FORTH AN EXEMPLARY AIRLINE DATA STRUCTURE IN ACCORDANCE WITH THE PRESENT INVENTION.

FOR Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) 21 Aug 2020

Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 2020101940

FIG. 8:IS A SETS FORTH AN EXEMPLARY RENTAL CAR DATA STRUCTURE IN ACCORDANCE WITH THE PRESENT INVENTION.

FIG. 9: IS A SETS FORTH AN EXEMPLARY HOTEL SYSTEM DATA STRUCTURE IN ACCORDANCE WITH THE PRESENT INVENTION.

FOR Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) 21 Aug 2020

Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 2020101940

FIG. 10: IS AN EXEMPLARY DISTRIBUTED TRANSACTION SYSTEM USEFUL IN PRACTICING THE PRESENT INVENTION.

FIG. 11: IS A SCHEMATIC OVERVIEW OF AN EXEMPLARY DYNAMIC SYNCHRONIZATION SYSTEM IN ACCORDANCE WITH VARIOUS ASPECTS OF THE PRESENT INVENTION.

FOR Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) 21 Aug 2020

Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 2020101940

FIG. 12: IS A SCHEMATIC OVERVIEW OF AN EXEMPLARY SECURE SUPPORT CLIENT SERVER;

FIG. 13: IS A FLOWCHART DEPICTING AN EXEMPLARY METHOD FOR SYNCHRONIZING PENDING TRANSACTION INFORMATION;

FOR Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) 21 Aug 2020

Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 2020101940

FIG. 14: IS A FLOWCHART DEPICTING AN EXEMPLARY METHOD FOR SYNCHRONIZING UPDATE TRANSACTION INFORMATION;

FOR Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) 21 Aug 2020

Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 2020101940

FIG. 15: IS A BLOCK DIAGRAM OVERVIEW OF AN EXEMPLARY DATA SET MANAGEMENT SYSTEM IN ACCORDANCE WITH AN EXEMPLARY EMBODIMENT OF THE PRESENT INVENTION.

FOR Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) 21 Aug 2020

Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 2020101940

FIG. 16: IS A MORE DETAILED EXEMPLARY DATA SET MANAGEMENT METHOD IN ACCORDANCE WITH AN EXEMPLARY EMBODIMENT OF THE PRESENT INVENTION.

FOR Dr. R. Madana Mohana (Professor, CSE) Dr. Rambabu Arjunarao Vatti (Professor, ECE) K. S. Niraja (Assistant Professor, CSE) Chandika Mohan Babu (Assistant Professor, ECE) C V Krishnaveni (Lecturer in Computer Science) Jayanthi Neelampalli (Assistant Professor, CSE) P. Ila Chandana Kumari (Associate Professor, CSE) Prashant (Assistant Professor, ECE) 21 Aug 2020

Dr. Praveen Kumar Reddy (Assistant Professor, ECE) Prof.(Dr.) S. B. Chordiya (Director-SIMMC-Campus) TOTAL NO OF SHEET: 12 NO OF FIG: 17 2020101940

FIG. 17: IS AN EXEMPLARY DATA SET MANAGEMENT METHOD FOR ADDING DATA SETS IN ACCORDANCE WITH AN EXEMPLARY EMBODIMENT OF THE PRESENT INVENTION.