RF transaction system and method for storing user personal data

Information

  • Patent Grant
  • 9024719
  • Patent Number
    9,024,719
  • Date Filed
    Friday, October 15, 2004
    20 years ago
  • Date Issued
    Tuesday, May 5, 2015
    9 years ago
Abstract
A system and method for a RF transaction device for storing user personal data is disclosed. The invention includes a system and method for facilitating a healthcare transaction using a transponder system configured to store different healthcare information in different storage areas on a database. The invention includes providing account information in ISO/IEC 7816 magnetic stripe Track 1/Track 2 format. The invention also includes an RFID reader for transmitting account and database information. In one embodiment the invention provides an RFID reader as a free standing or a computer implemented device. In another embodiment, biometric security measures are used in conjunction with the transponder system. In another embodiment, the transponder system communicates with one or more third-party healthcare providers to facilitate the transfer of healthcare and personal information.
Description
FIELD OF INVENTION

This invention generally relates to systems and methods for storing and accessing personal information on a Radio Frequency (RF) transponder, more specifically, to storing and accessing healthcare information.


BACKGROUND OF INVENTION

The U.S. Department of Health and Human Services has recently launched a new plan to convert the present healthcare information infrastructure to a nationwide, electronic network for healthcare information. Currently, only thirteen percent of hospitals nationwide have electronic systems, and only 14 to 28 percent of other physicians maintain electronic systems.


Electronic healthcare systems provide many challenges. For example, oftentimes, physicians and hospitals use computer systems for billing, while they use manual filing systems for tracking medical records. Therefore, information can be lost, mislaid, or inputted incorrectly for billing purposes. Recently, different software systems, such as CareRevolution by Electronic Healthcare Systems, have provided single point-of-care products that provide one database for both billing and medical information.


Nevertheless, medical and billing information must still be transferred from the patients to the physicians manually. Further, with patients moving and increased traveling, often the patient may not have all his medical information in one place and/or on hand when he needs medical attention. While current healthcare systems allow information to be maintained and held by the healthcare provider, it is desirable for such information to be portable and held with the patent instead.


Having the proper patient medical history has been shown to improve medical care and reduce medical errors. Further, improvements in health information technology have been estimated to produce savings of up to ten percent. Therefore, there is a need for a portable device for healthcare information.


SUMMARY OF INVENTION

A system and method for a RF transaction device for storing user personal data is disclosed. The invention includes a system and method for facilitating a healthcare transaction comprising an RF transponder system configured to store different healthcare information in different storage areas on a database. For example, medical insurance information may be stored in one type of format, while dental insurance information may be stored in a different format. The system and method for facilitating a healthcare transaction provides account information in ISO/IEC 7816 magnetic stripe Track 1/Track 2 format. The invention includes an RFID reader for transmitting account and database information.


In one exemplary embodiment the invention provides an RFID reader as a free standing or a computer implemented device. In another embodiment, biometric security measures are used in conjunction with the transponder system. The biometric security measures include pre-registration of biometric information and proffering biometric samples at biometric sensors configured with the transponder system.


In another exemplary embodiment, the transponder system communicates with one or more third-party healthcare providers to facilitate the transfer of healthcare and personal information. In another embodiment, the transponder system is configured with a GPS device to monitor and track locational information to provide local healthcare information and services.


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.





BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, wherein like numerals depict like elements, illustrate exemplary embodiments of the present invention, and together with the description, serve to explain the principles of the invention. In the drawings:



FIG. 1A illustrates an exemplary RFID-based system in accordance with the present invention, wherein exemplary components used for fob healthcare information are depicted;



FIG. 1B illustrates an exemplary personalization system in accordance with the present invention;



FIG. 2 is a schematic illustration of an exemplary fob in accordance with the present invention;



FIG. 3 is a schematic illustration of an exemplary RFID reader in accordance with the present invention;



FIG. 4 is an exemplary flow diagram of an exemplary authentication process in accordance with the present invention;



FIG. 5 is an exemplary flow diagram of an exemplary decision process for a protocol/sequence controller in accordance with the present invention;



FIGS. 6A-B are an exemplary flow diagram of a fob personalization process in accordance with the present invention;



FIGS. 7A-B are an exemplary flow diagram of a RFID reader personalization process in accordance with the present invention;



FIG. 8 is a flow diagram of an exemplary healthcare information process in accordance with the present invention;



FIG. 9 includes a flowchart illustrating an exemplary healthcare engine system configured to facilitate storing, accessing and transmitting user information;



FIG. 10 includes a flowchart illustrating an exemplary method for enrolling and managing multiple data set owners in accordance with the present invention;



FIG. 11 includes a depiction of an exemplary data set management system in accordance with the present invention;



FIG. 12 illustrates a general overview of an exemplary data set management method in accordance with the present invention;



FIG. 13 illustrates an exemplary method of adding a data set to a fob in accordance with the present invention;



FIG. 14 is a depiction of an exemplary biometrics process in accordance with the present invention;



FIG. 15 is another schematic illustration of an exemplary fob in accordance with the present invention;



FIG. 16 another schematic illustration of an exemplary fob in accordance with the present invention;



FIG. 17 is an exemplary layout of the data stored in track 2 format; and



FIG. 18 is an example of a conventional magnetic stripe track 2 layout for MasterCard;



FIG. 19 illustrates an exemplary data set management method for deleting data sets in accordance with an exemplary embodiment of the present invention;



FIG. 20 illustrates an exemplary method for user self-management of data sets in accordance with an exemplary embodiment of the present invention;



FIG. 21 illustrates an exemplary method for issuer management of data sets in accordance with the present invention; and



FIG. 22 illustrates an exemplary data set selection method for use in completing a transaction.





DETAILED DESCRIPTION

The detailed description of exemplary embodiments of the invention herein makes reference to the accompanying block diagrams and flowcharts, which show the exemplary embodiment by way of illustration and its best mode. While these exemplary embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, it should be understood that other embodiments may be realized and that logical and mechanical changes may be made without departing from the spirit and scope of the invention. Thus, the detailed description herein is presented for purposes of illustration only and not of limitation. For example, the steps recited in any of the method or process descriptions may be executed in any order and are not limited to the order presented.


Moreover, it should be appreciated that the particular implementations shown and described herein are illustrative of the invention and its best mode and are not intended to otherwise limit the scope of the present invention in any way. Indeed, for the sake of brevity, certain sub-components of the individual operating components, conventional data networking, application development and other functional aspects of the systems may not be described in detail herein. Furthermore, the connecting lines shown in the various figures contained herein are intended to represent exemplary functional relationships and/or physical couplings between the various elements. It should be noted that many alternative or additional functional relationships or physical connections may be present in a practical system.


The present invention may be described herein in terms of block diagrams, screen shots and flowcharts, optional selections and various processing steps. Such functional blocks may be realized by any number of hardware and/or software components configured to perform to specified functions. For example, the present invention may employ various integrated circuit components (e.g., memory elements, processing elements, logic elements, look-up tables, and the like), which may carry out a variety of functions under the control of one or more microprocessors or other control devices. Similarly, the software elements of the present invention may be implemented with any programming or scripting language such as C, C++, Java, COBOL, assembler, PERL, extensible markup language (XML), smart card technologies with the various algorithms being implemented with any combination of data structures, objects, processes, routines or other programming elements. Further, it should be noted that the present invention may employ any number of conventional techniques for data transmission, signaling, data processing, network control, and the like.


In addition, many applications of the present invention could be formulated. The exemplary network disclosed herein may include any system for accessing, storing, exchanging and/or otherwise manipulating user information, such as a distributed system, a thin cable network, an Ethernet, a token ring network, the Internet, an intranet, an extranet, wide area network (WAN), local area network (LAN), satellite communications, and/or the like. It is noted that the network may be implemented as other types of networks, such as an interactive television network (ITN).


The system user may interact with the system via any input device such as, a keypad, keyboard, mouse, kiosk, personal digital assistant, handheld computer (e.g., Palm Pilot®, Blueberry®), cellular phone and/or the like). For example, any input device may also be a “pervasive computing device,” such as a traditionally non-computerized device that is embedded with a computing unit, such as, for example, watches, Internet-enabled kitchen appliances, restaurant tables embedded with RF readers, wallets or purses with imbedded transponders, etc. Similarly, the invention could be used in conjunction with any type of personal computer, network computer, work station, minicomputer, mainframe, or the like running any operating system such as any version of Windows, Windows NT, Windows 2000, Windows 98, Windows 95, MacOS, OS/2, BeOS, Linux, UNIX, Solaris, MVS or the like. Moreover, although the invention may frequently be described as being implemented with TCP/IP communications protocol, it should be understood that the invention could also be implemented using SNA, IPX, Appletalk, IPte, NetBIOS, OSI or any number of communications protocols. Moreover, the system contemplates, the use, sale, or distribution of any goods, services or information over any network having a similar functionality described herein.



FIG. 1A illustrates an exemplary RFID personal data system 100A that may include fob 102 having a transponder 114 and a RFID reader 104 in radio frequency (RF) communication with fob 102. In general, fob 102 may comprise one or more user databases 214 configured to store user information. These user databases 214 will be described in greater detail herein.


System 100A may be configured to provide access and/or to store user information in databases 214 in order to facilitate healthcare transactions, financial transactions, and/or any other type of transaction.


Fob 102 in accordance with this invention may be used to provide healthcare information, provide user information, pay for medical care, obtain healthcare access, provide identification, pay an amount, receive a payment, redeem reward points and/or the like. In the radio frequency (“RF”) embodiments of fob 102, instrument to instrument transactions may also be performed. See, for example, Sony's “Near Field Communication” (“NFC”) emerging standard which is touted as operating on 13.56 MHz and allowing the transfer of any kind of data between NFC enabled devices across a distance of up to twenty centimeters. See also, Bluetooth chaotic network configurations; described in more detail at http://www.palowireless.com/infotooth/whatis.asp, which is incorporated herein by reference. Furthermore, data on a first RF device may be transmitted directly or indirectly to another RF device to create a copy of all or part of the original device.


Although the present invention is described with respect to fob 102, the invention is not to be so limited. Indeed, system 100A may include any device having a transponder which is configured to communicate with a RFID reader 104 via RF communication. Typical devices may include, for example, a key ring, tag, card, cell phone, wristwatch, clothing or any such form capable of being presented for interrogation. System 100A may also include any non-transponder device configured to facilitate information transactions, such as, for example, credit cards, debit cards, loyalty cards, and the like.


RFID reader 104 may be configured to communicate using a RFID internal antenna 106. Alternatively, RFID reader 104 may include an external antenna 108 for communications with fob 102, where the external antenna may be made remote to RFID reader 104 using a suitable cable and/or data link 120. RFID reader 104 may be further in communication with a healthcare system 130 via a data link 122. System 100A may include a point-of-interaction device such as, for example, a healthcare point-of-interaction (POI) device 110 or a computer interface (e.g., user interface) 134. In one exemplary embodiment system 100A may include healthcare system 130 including POI device 110 in communication with RFID reader 104 (via data link 122). As described more fully below, system 100A may include the user interface 134 connected to a network 136 and to the transponder via a USB connector 132.


As used herein, a user may include any person, resource, product, employee, employer officer, nurse, doctor, health practitioner, hospital administrator, dentist, chiropractor, entity, manager, business, client, corporation, customer, contractor, administrator, operator, pet, equipment, supply, package, hardware and/or software.


The phrase “user information” as used herein, may include any user information such as transaction account information; personal information such as names, addresses, dates of birth, social security numbers, passport numbers, and employment information; healthcare information such as medical history, allergies, medical insurance information, dental insurance information; mortgage information; loyalty point information; membership information and/or any other type of information corresponding to a user. While the invention contemplates the communication, transfer, access and/or storage of any type of user information, the communication, transfer, access and/or storage of healthcare information may be used throughout for exemplary purposes.


Although the point-of-interaction device is described herein with respect to a healthcare point-of-interaction (POI) device, the invention is not to be so limited. Indeed, a healthcare POI device is used herein by way of example, and the point-of-interaction device may be any device capable of receiving fob account data. In this regard, the POI may be any point-of-interaction device enabling the user to complete a transaction and/or transfer information using fob 102. POI device 110 may be in further communication with a user interface 118 (via data link 128) for entering at least a customer's identity verification information. In addition, POI device 110 may be in communication with a healthcare host network 112 (via data link 124) for processing any transaction and/or user information request. In this arrangement, information provided by RFID reader 104 is provided to the POI device 110 of healthcare system 130 via data link 122. POI device 110 may receive the information (and alternatively may receive any identity verifying information from user interface 118 via data link 128) and provide the information to host system 112 for processing.


A variety of conventional communications media and protocols may be used for data links 120, 122, 124, and 128. For example, data links 120, 122, 124, and 128 may be an Internet Service Provider (ISP) configured to facilitate communications over a local loop as is typically used in connection with standard modem communications, cable modems, dish networks, ISDN, Digital Subscriber Lines (DSL), or any wireless communication media. In addition, healthcare system 130, including POI device 110 and host network 112, may reside on a local area network which interfaces to a remote network (not shown) for remote authorization of an intended transaction. Healthcare system 130 may communicate with the remote network via a leased line, such as a T1, D3 line, or the like. Such communications lines are described in a variety of texts, such as, “Understanding Data Communications,” by Gilbert Held, which is incorporated herein by reference.


An account number, as used herein, may include any identifier for an account (e.g., insurance, credit, charge debit, checking, savings, reward, loyalty, or the like) which may be maintained by a healthcare and/or transaction account provider (e.g., payment authorization center) and/or which may be used to complete a transaction. A typical account number (e.g., account data) may be correlated to an insurance account, a credit or debit account, loyalty account, or rewards account maintained and serviced by such entities as American Express®, Visa® and/or MasterCard® or the like. For ease in understanding, the present invention may be described with respect to a medical insurance account.


In addition, the account number (e.g., account data) may be associated with any device, code, or other identifier/indicia suitably configured to allow the user to interact or communicate with the system, such as, for example, authorization/access code, personal identification number (PIN), Internet code, digital certificate, biometric data, and/or other identification indicia. The account number may be optionally located on a medical insurance card, rewards card, charge card, credit card, debit card, prepaid card, telephone card, smart card, magnetic stripe card, bar code card, loyalty card and/or the like. The account number may be distributed and stored in any form of plastic, electronic, magnetic, audio device and/or optical device capable of transmitting or downloading data to a second device. A user account number may be, for example, a sixteen-digit credit card number, although each credit provider has its own numbering system, such as the fifteen-digit numbering system used by American Express®. Each company's credit card numbers comply with that company's standardized format such that the company using a sixteen-digit format will generally use four spaced sets of numbers, as represented by the number “0000 0000 0000 0000”. In a typical example, the first five to seven digits are reserved for processing purposes and identify the issuing bank, card type and, etc. In this example, the last sixteenth digit is used as a sum check for the sixteen-digit number. The intermediary eight-to-ten digits are used to uniquely identify the customer.


In various exemplary embodiments of the present invention, one or more transaction accounts may be used to satisfy or complete a transaction. For example, the transaction may be only partially completed using the transaction account(s) correlating to the application tenant information stored on fob 102 with the balance of the transaction being completed using other sources. Cash may be used to complete part of a transaction and the transaction account associated with a user and fob 102, may be used to satisfy the balance of the transaction. Alternatively, the user may identify which transaction account, or combination of transaction accounts, stored on fob 102 the user desires to complete the transaction. Any known or new methods and/or systems configured to manipulate the transaction account in accordance with the invention may be used.


The account number may be stored as Track 1 and Track 2 data as defined in ISO/IEC 7813, and further may be made unique to fob 102. In one exemplary embodiment, the account number may include a unique fob serial number and user identification number, as well as specific application applets. The account number may be stored in fob 102 inside a database 214, as described more fully below. Database 214 may be configured to store multiple account numbers issued to fob 102 user by the same or different account providing institutions. Where the account data corresponds to a loyalty or rewards account, the database 214 may be configured to store the attendant loyalty or rewards points data.



FIG. 2 illustrates a block diagram of the many functional blocks of an exemplary fob 102 in accordance with the present invention. Fob 102 may be a RFID fob 102 which may be presented by the user to facilitate an exchange of personal information such as medical information for facilitating healthcare services. As described herein, by way of example, fob 102 may be a RFID fob which may be presented for facilitating healthcare payment and/or services.


Fob 102 may include an antenna 202 for receiving an interrogation signal from RFID reader 104 via antenna 106 (or alternatively, via external antenna 108). Fob antenna 202 may be in communication with a transponder 114. In one exemplary embodiment, transponder 114 may be a 13.56 MHz transponder compliant with the ISO/IEC 14443 standard, and antenna 202 may be of the 13 MHz variety. The transponder 114 may be in communication with a transponder compatible modulator/demodulator 206 configured to receive the signal from transponder 114 and configured to modulate the signal into a format readable by any later connected circuitry. Further, modulator/demodulator 206 may be configured to format (e.g., demodulate) a signal received from the later connected circuitry in a format compatible with transponder 114 for transmitting to RFID reader 104 via antenna 202. For example, where transponder 114 is of the 13.56 MHz variety, modulator/demodulator 206 may be ISO/IEC 14443-2 compliant.


Modulator/demodulator 206 may be coupled to a protocol/sequence controller 208 for facilitating control of the authentication of the signal provided by RFID reader 104, and for facilitating control of the sending of fob 102 account number and/or other user information. In this regard, protocol/sequence controller 208 may be any suitable digital or logic driven circuitry capable of facilitating determination of the sequence of operation for fob 102 inner-circuitry. For example, protocol/sequence controller 208 may be configured to determine whether the signal provided by RFID reader 104 is authenticated, and thereby providing to RFID reader 104 the account number stored on fob 102.


Protocol/sequence controller 208 may be further in communication with authentication circuitry 210 for facilitating authentication of the signal provided by RFID reader 104. Authentication circuitry 210 may be further in communication with a non-volatile secure memory database 212. Secure memory database 212 may be any suitable elementary file system such as that defined by ISO/IEC 7816-4 or any other elementary file system allowing a lookup of data to be interpreted by the application on the chip.


Database 212 and any other database discussed herein may be any type of database, such as relational, hierarchical, graphical, object-oriented, and/or other database configurations. Common database products that may be used to implement the databases include DB2 by IBM (White Plains, N.Y.), various database products available from Oracle Corporation (Redwood Shores, Calif.), Microsoft Access or Microsoft SQL Server by Microsoft Corporation (Redmond, Wash.), or any other suitable database product. Moreover, the databases may be organized in any suitable manner, for example, as data tables or lookup tables. Each record may be a single file, a series of files, a linked series of data fields or any other data structure. Association of certain data may be accomplished through any desired data association technique such as those known or practiced in the art. For example, the association may be accomplished either manually or automatically. Automatic association techniques may include, for example, a database search, a database merge, GREP, AGREP, SQL, and/or the like. The association step may be accomplished by a database merge function, for example, using a “key field” in pre-selected databases or data sectors.


More particularly, a “key field” partitions the database according to the high-level class of objects defined by the key field. For example, certain types of data may be designated as a key field in a plurality of related data tables and the data tables may then be linked on the basis of the type of data in the key field. In this regard, the data corresponding to the key field in each of the linked data tables may be preferably the same or of the same type. However, data tables having similar, though not identical, data in the key fields may also be linked by using AGREP, for example. In accordance with one aspect of the present invention, any suitable data storage technique may be utilized to store data without a standard format. Data sets may be stored using any suitable technique, for example, storing individual files using an ISO/IEC 7816-4 file structure; implementing a domain whereby a dedicated file may be selected that exposes one or more elementary files containing one or more data sets; using data sets stored in individual files using a hierarchical filing system; data sets stored as records in a single file (for example, compression, SQL accessible, hashed via one or more keys, numeric, alphabetical by first tuple, etc.); block of binary (BLOB); stored as ungrouped data elements encoded using ISO/IEC 7816-6 data elements; stored as ungrouped data elements encoded using ISO/IEC Abstract Syntax Notation (ASN.1) as in ISO/IEC 8824 and 8825; and/or other proprietary techniques that may include fractal compression methods, image compression methods, etc.


In one exemplary embodiment, the ability to store a wide variety of information in different formats may be facilitated by storing the information as a Block of Binary (BLOB). Thus, any binary information may be stored in a storage space associated with a data set. The BLOB method may store data sets as ungrouped data elements formatted as a block of binary via a fixed memory offset using either fixed storage allocation, circular queue techniques, or best practices with respect to memory management (e.g., paged memory, least recently used, etc.). By using BLOB methods, the ability to store various data sets that have different formats facilitates the storage of data associated with a wide variety of system components by multiple and unrelated owners of the data sets. For example, a first data set which may be stored may be provided by a first issuer, a second data set which may be stored may be provided by an unrelated second issuer, and yet a third data set which may be stored, may be provided by a third issuer unrelated to the first and second issuer. Each of these three exemplary data sets may contain different information that may be stored using different data storage formats and/or techniques. Further, each data set may contain subsets of data which also may be distinct from other subsets.


Information may be stored, accessed, and/or transmitted on database 214 and/or any other database described herein. For example the present invention provides a system and method for a RF operable transaction instrument configured to manage multiple data sets (e.g., “application tenants”) of differing formats associated with a plurality of distinct transaction and/or healthcare account issuers. In this context, an “application tenant” may include all or any portion of any data sets which are substantially correlated to an account issuer, which the issuer may additionally use to substantially identify an instrument user or related account.


For example, where the account issuer provides application tenant information, the application tenant may include, for example, a healthcare identifier associated with a user enrolled in an issuer provided transaction account program, and all related subsets of data stored on fob 102. Where multiple application tenants are referred to herein, each tenant may constitute its own distinct data set, independent of any other application tenant data sets. For example, each application tenant may include a unique healthcare identifier and all associated subsets of data. Alternatively, an application tenant may include a healthcare identifier and an application for processing all data owned by an issuer. Thus, the data set or subset may include the processing application. Moreover, differing formats, as discussed herein, include differences in all or any portion of the formats. As such, “application tenant” and “distinct data set,” and data set “owner,” “healthcare issuer” and account “issuer” may be used interchangeably herein. Moreover, while reference may be made to healthcare, one skilled in the art will appreciate that the application similarly applies to other information.


As noted, in accordance with the invention, fob 102 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 fob 102 itself, or on a remote database, as described below. The data sets stored with regard to fob 102 may be modified, deleted, added or augmented, as required by the healthcare issuer or the user. For example, as owner of the data, a healthcare issuer may modify a data set at the healthcare issuer's discretion. The healthcare 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 fob 102 is next presented.


In one exemplary embodiment, fob 102 itself is configured to store at least two data sets. In other exemplary embodiments, data sets may be stored in one or more databases and the data sets are affiliated with fob 102. For example, a central database on fob 102 may store multiple distinct data sets correlated with a unique healthcare provider. The data sets stored on the remote database may be stored thereon in such a manner as to mimic the corresponding data sets stored on fob 102. The multiple distinct data sets may be accessed, for example, by a healthcare system, whether stored on fob 102 or remote database stand alone device, and/or a computer user interface, via a network. In this example, fob 102 may include one or more user identifiers (e.g., insurance identifiers), which may be used to provide access to a subset of data included on fob 102.


Although all data sets associated with a particular fob 102 may be owned by the same owner, it is contemplated that in general, some of the data sets stored on fob 102 have different owners. Furthermore, the storage of data sets is configured to facilitate independent storage and management of the data sets on fob 102. Further still, the data sets may be stored in distinct differing formats provided by the distinct issuer or data set owner (also called “issuer” herein). The owners of data sets may include different individuals, entities, businesses, corporations, software, hardware, and/or the like. However, one skilled in the art will appreciate that the owners may also include different divisions or affiliates of the same corporation or entity.


A data set may contain any type of information stored in digital format. For example, a data set may include account numbers, programs/applications, scripts, cookies, instruments for accessing other data sets, and/or any other information.


As discussed above, many issuers of existing healthcare transaction instruments utilize predetermined formats for medical information, insurance numbers, account data, personal data and/or applications stored in association with fob 102. Similarly, the data storage media associated with these healthcare transaction instruments are typically configured to accommodate specific predetermined data formats. Thus, since the data format associated with a first issuer is often different from a data format of a second issuer, storage of multiple distinct data of differing formats on a single device provides complications for conventional systems. This is often true since, each issuer typically maintains an account processing system that uses a processing protocol different from other issuers, and the information stored on the transaction card relative to the issuer must be formatted accordingly. As such, to ensure the security and integrity of the issuer-owned data, the loading of data on fob 102 is typically performed by a healthcare provider, issuer or a third-party provider who typically uploads all related and similarly formatted data sets onto fob 102. However, since the third party may typically only be authorized by the issuer and/or healthcare provider to load issuer-owned data of similar format onto an issuer-provided fob 102, including differently formatted data sets on a single transaction device by the third party is often not permitted. More particularly, independent owners of data sets are often reluctant to conform their data set formats to a “standard format” because of the security advantages of maintaining a separate, distinct, often secreted format.


As stated above, in various embodiments of the present invention, the data may be stored without regard to a common format. However, in one exemplary embodiment of the present invention, the data set (e.g., BLOB) may be annotated in a standard manner when provided for manipulating the data onto the network. The annotation may comprise a short header, trailer, or other appropriate indicator related to each data set that may be configured to convey information useful in managing the various data sets. For example, the annotation may be called a “condition header,” “header,” “trailer,” or “status,” herein, and may comprise an indication of the status of the data set or may include an identifier correlated to a specific issuer or owner of the data. In one example, the first three bytes of each data set BLOB may be configured or configurable to indicate the status of that particular data set (e.g., LOADED, INITIALIZED, READY, BLOCKED, REMOVABLE, or DELETED). Subsequent bytes of data may be used to indicate for example, the identity of the user, user, account identifier or the like. Each of these condition annotations are further discussed herein.


The data may be used by protocol/sequence controller 208 for data analysis and used for management and control purposes, as well as security purposes. Authentication circuitry may authenticate the signal provided by RFID reader 104 by association of the RFID signal to authentication keys stored on database 212. Encryption circuitry may use keys stored on database 212 to perform encryption and/or decryption of signals sent to or from the RFID reader 104. Separate authentication keys may be used for each data set owner. The data set may consist of a directory file and/or an elementary file as defined in the ISO/IEC 7813 specification. A separate authentication key may be required to access the directory file and/or another key may be required for authentication to access the elementary file. The authentication keys may be supplemented with keys used to encrypt the data stored in the data set. The authentication and encryption keys may also be unique to the data set owner to prevent unauthorized access to the data. The RFID reader 104 and/or the terminal that is connected to the RFID reader 104 may contain the keys used to authenticate access to the data sets. The reader may also contain the encryption keys to decrypt the data in the data sets.


The data may be used by protocol/sequence controller 208 for data analysis and used for management and control purposes, as well as security purposes. Authentication circuitry may authenticate the signal provided by RFID reader 104 by association of the RFID signal to authentication keys stored on database 212. Encryption circuitry may use keys stored on database 212 to perform encryption and/or decryption of signals sent to or from RFID reader 104. For a basic introduction on cryptography, review a text written by Bruce Schneier entitled “Applied Cryptography: Protocols, Algorithms, and Source Code in C,” published by John Wiley & Sons (second edition, 1995), herein incorporated by reference.


In addition, protocol/sequence controller 208 may be in communication with a database 214 for storing at least fob 102 transponder account data, and a unique fob 102 identification code. Protocol/sequence controller 208 may be configured to retrieve the account identifier from database 214 as desired. Database 214 may be of the same configuration as database 212 described above. The fob transponder account data and/or unique fob identification code stored on database 214 may be encrypted prior to storage. Thus, where protocol/sequence controller 208 retrieves the account data, and or unique fob identification code from database 214, the transponder account identifier may be encrypted when being provided to RFID reader 104. Further, the data stored on database 214 may include, for example, an unencrypted unique fob 102 identification code, a user identification, Track 1 and Track 2 data, as well as specific application applets.


For example, in accordance with another exemplary embodiment, the account number may be stored in magnetic stripe format. That is, where the account number may be in magnetic stripe format, the account number portions are governed by the International Standards Organization ISO/IEC 7811, et al. standard, which are hereby incorporated by reference. The standard requires the magnetic stripe information to be encoded in three “tracks” (i.e., track 1, track 2, and track 3).


Data stored in track 1 may be typically used to verify the user's identity. Track 1 may be reserved for encoding the transaction account identifier, the name of the accountholder, and at least the expiration date of the transaction account or the transaction device. The information encoded in track 1 may be alphanumeric and may be encoded at about 7 Bits/Character. In an exemplary layout of the data stored in track 1, track 1 may be segmented into several distinct predetermined portions (e.g., “fields”) for encoding the various account identifying information. The following table may be useful for determining the field definitions of the information provided.













TABLE 1








Table of Field Codes for Track 1











SS = Start Sentinel “%”





FC = Format Code





PAN = Primary Acct. # (19 digits max)





FS = Field Separator “{circumflex over ( )}”





Name = 26 alphanumeric characters max.





Additional Data = Expiration Date, offset, encrypted PIN, etc.





ES = End Sentinel “?”





LRC = Longitudinal Redundancy Check










Track 2 may be the track most commonly used by the American Banking Association associated banking institutions. Track 2 may be typically reserved for a duplicate version of the transaction account identifier and the expiration date of the transaction account or the transaction device stored in track 1. In addition, track 2 may include an encrypted Personal Identification Code, and other discretionary data. However, the data in track 2 may be encoded at a lower Bit per Character density than the data encoded in track 1. The data in track 2 may be numeric only and may be encoded at about 5 Bits/Character. The lower density ratio in track 2 may be designed to ensure compatibility with older technology readers and to provide redundancy when reading with newer technology readers. FIG. 17 illustrates an exemplary layout of the data stored in track 2, wherein track 2 may be segmented into several distinct predetermined portions for encoding the various account identifying information. As shown, the following table may be useful for determining the definitions of the information provided.













TABLE 2








Table of Field Codes for Track 2











SS = Start Sentinel “%”





SS = Start Sentinel “;”





PAN = Primary Acct. # (19 digits max)





FS = Field Separator “=”





Additional Data = Expiration Date, offset, encrypted PIN, etc.





ES = End Sentinel “?”





LRC = Longitudinal Redundancy Check










Track 3 may be of similar description as Track 2. With the International Standards Organization adoption of standard ISO/IEC 4909, track 3 of the magnetic stripe format was no longer used by the banking industry. However, other transaction devices including a magnetic stripe, such as drivers licenses, use track 3, which may include both numeric only and alphanumeric characters. Track 3 may be unique in that track 3 was intended to have data read and WRITTEN on it. Cardholders would have account information UPDATED right on the magnetic stripe. The present invention anticipates that a fob user's travel-related information profile and/or account information may be updated using track 3. Unfortunately, track 3 may be almost an orphaned standard, since most readers currently in operation are not configured to write data from track 3. The original design of track 3 was to control off-line ATM transactions by recording transaction data for later reference by the banking institution. But since ATMs are now on-line, the usage of track 3 has been drastically reduced.


The most common technique used to encode data in magnetic stripe format may be known as Aiken Biphase, or ‘two-frequency coherent-phase encoding.’ The American National Standards Institute (ANSI) and the International Standards Organization (ISO) have chosen two standards to guide the encoding process. The ISO encoding protocol specifies that each of tracks 1, 2 and 3 must begin and end with a length of all Zero bits, called CLOCKING BITS. These are used to synch the self-clocking feature of bi-phase decoding. In addition, most transaction devices which use magnetic stripe encoding protocol use either the ANSI/ISO ALPHA Data format or the ANSI/ISO BCD Data format. For example, track 1 may be typically encoded in ANSI/ISO ALPHA Data format which may be a 7 bit, 6 data bits+1 parity bit (odd) format, where the data may be read least significant bit first. The ANSI/ISO ALPHA format character set contains 64 characters, 43 alphanumeric, 3 framing/field characters and 18 control/special characters. On the other hand, tracks 2 and 3 are typically encoded in ANSI/ISO BCD Data format, which may be a 5 bit, 4 data bits+1 parity bit(odd) format. The character set for the ANSI/ISO BCD Data format character set contains 16 characters, 10 alphanumeric, 3 framing/field characters and 3 control/special characters.


Ordinarily, a proxy account number (e.g., a portion of the transaction account number) includes essential identifying information, such as, for example, any information that may be common to the account provider. The common information (also called “common character,” herein) may include the account provider routing number, or common source indicator such as the character spaces reserved to indicate the identification of the issuing bank. Thus, where the proxy transaction account identifier corresponds to an American Express account, the proxy transaction account identifier may include the common prefix number 3715, encoded the field location where such common character may be ordinarily encoded in traditional magnetic stripe format. The prefix 3715 is an example of the required set of digits in the account number required to identify the issuer as American Express. Each credit card issuer has a unique set of digits commonly agreed upon between institutions that identifies the issuer.



FIG. 18 illustrates the encoding of which would ordinarily be done by an entity, such as, for example, MasterCard in track 2 format. FIG. 18 shows the encoding of a MasterCard account number 3111 2222 3333 4444 with expiration date 12/99 in traditional track 1 format. Since MasterCard uses the number 3111 to identify its transaction accounts, the proxy account identifier may also use the number 3111 so that the receiving system (e.g., RFID reader 104 or merchant system 130, or account provider) further recognizes that the proxy account identifier may be from a MasterCard transaction device. It should be noted that in this example, the “3” and the “101” may be common characters to all MasterCard transaction accounts. For a more detailed explanation of magnetic stripe format data exchange, see U.S. patent application Ser. No. 10/810,473, filed Mar. 26, 2004, entitled “SYSTEM AND METHOD FOR ENCODING INFORMATION IN MAGNETIC STRIPE FORMAT FOR USE IN RADIO FREQUENCY IDENTIFICATION TRANSACTIONS,” incorporated herein by reference.


Fob 102 may be configured to respond to multiple interrogation frequency transmissions provided by RFID reader 104. That is, as described more fully below, RFID reader 104 may provide more than one RF interrogation signal. In this case, fob 102 may be configured to respond to the multiple frequencies by including in fob 102 one or more additional RF signal receiving/transmitting units 226. RF signal receiving/transmitting unit 226 may include an antenna 218 and transponder 220 where the antenna 218 and transponder 220 are compatible with at least one of the additional RF signals provided by RFID reader 104. For example, in one exemplary embodiment, fob 102 may include a 134 KHz antenna 218 configured to communicate with a 134 KHz transponder 220. In this exemplary configuration, an ISO/IEC 14443-2 compliant modulator/demodulator may not be required. Instead, the 134 KHz transponder may be configured to communicate directly with the protocol/sequence controller 208 for transmission and receipt of authentication and account number signals as described above.


In another embodiment, fob 102 may further include a universal serial bus (USB) connector 132 for interfacing fob 102 to a user interface 134. User interface 134 may be further in communication with a POI device 110 via a network 136. Network 136 may be the Internet, an intranet, or the like as is described above with respect to network 112. Further, the user interface 134 may be similar in construction to any conventional input devices and/or computing systems aforementioned for permitting the system user to interact with the system. In one exemplary embodiment, fob 102 may be configured to facilitate online Internet payments. A USB converter 222 may be in communication with a USB connector 232 for facilitating the transfer of information between the modulator/demodulator 206 and USB connector 132. Alternatively, USB converter 222 may be in communication with protocol/sequence controller 208 to facilitate the transfer of information between protocol/sequence controller 208 and USB connector 132.


Where fob 102 includes a USB connector 132, fob 102 may be in communication with, for example, a USB port on user interface 134. The information retrieved from fob 102 may be compatible with credit card and/or smart card technology enabling usage of interactive applications on the Internet. No RFID reader may be required in this embodiment since the connection to POI device 110 may be made using a USB port on user interface 134 and a network 136.


Fob 102 may include means for enabling activation of the fob by the user. In one exemplary embodiment, a switch 230 which may be operated by the user of fob 102. The switch 230 on fob 102 may be used to selectively or inclusively activate fob 102 for particular uses. In this context, the term “selectively” may mean that switch 230 enables the user to place fob 102 in a particular operational mode. For example, the user may place fob 102 in a mode for enabling purchase of a good or of a service using a selected account number. Alternatively, the fob may be placed in a mode as such that the fob account number is provided by USB port 132 (or serial port) only and fob transponder 114 is disabled. In addition, the term “inclusively” may mean that fob 102 is placed in an operational mode permitting fob 102 to be responsive to the RF interrogation and interrogation via the USB connector 132. In one particular embodiment, switch 230 may remain in an OFF position ensuring that one or more applications or accounts associated with fob 102 are non-reactive to any commands issued by RFID reader 104. As used herein, the OFF position may be termed the “normal” position of activation switch 230, although other normal positions are contemplated.


In another exemplary embodiment, when switch 230 is moved from the OFF position, fob 102 may be deemed activated by the user. That is, switch 230 may activate internal circuitry in fob 102 for permitting the fob to be responsive to RF signals (e.g., commands from RFID reader 104). In this way, switch 230 may facilitate control of the active and inactive states of fob 102. Such control increases the system security by preventing inadvertent or illegal use of fob 102.


In one exemplary embodiment, switch 230 may be a simple mechanical device in communication with circuitry which may electrically prevent the fob from being powered by a RFID reader. That is, when switch 230 is in its normal position, switch 230 may provide a short to fob 102 internal circuitry, preventing fob 102 from being responsive to interrogation by RF or via the USB connector 132. In this arrangement, switch 230 may be, for example, a “normally closed” (NC) configured switch, which may be electrically connected to antenna 202 at the interface of antenna 202 and transponder 114. Switch 230 may be depressed, which may open switch 230 fully activating antenna 202.


In yet another exemplary embodiment, fob 102 may include a biometric sensor and biometric membrane configured to operate as switch 230 and activate fob 102 when provided biometric signal from fob 102 user. Such biometric signal may be the digital reading of a fingerprint, thumbprint, or the like. Typically, where biometric circuitry is used, the biometric circuitry may be powered by an internal voltage source (e.g., battery). In this case, the switch may not be a simple mechanical device, but a switch which is powered. In yet another exemplary embodiment, switch 230 may be battery powered though no biometric circuitry is present in fob 102.


In yet another embodiment, switch 230 may be a logic switch. Where switch 230 is a logic switch 230 control software may be read from sequence controller 208 to selectively control the activation of the various fob 102 components.



FIG. 3 illustrates an exemplary block diagram of RFID reader 104 in accordance with an exemplary embodiment of the present invention. RFID reader 104 includes, for example, an antenna 106 coupled to a RF module 302, which is further coupled to a control module 304. In addition, RFID reader 104 may include an antenna 108 positioned remotely from RFID reader 104 and coupled to RFID reader 104 via a suitable cable 120, or other wire or wireless connection.


RF module 302 and antenna 106 may be suitably configured to facilitate communication with fob 102. Where fob 102 is formatted to receive a signal at a particular RF frequency, RF module 302 may be configured to provide an interrogation signal at that same frequency. For example, in one exemplary embodiment, fob 102 may be configured to respond to an interrogation signal of about 13.56 MHz. In this case, RFID antenna 106 may be 13 MHz and may be configured to transmit an interrogation signal of about 13.56 MHz. That is, fob 102 may be configured to include a first and second RF module (e.g., transponder) where the first module may operate using a 134 kHz frequency and the second RF module may operate using a 13.56 MHz frequency. RFID reader 104 may include two receivers which may operate using the 134 kHz frequency, the 13.56 MHz frequency or both. When RFID reader 104 is operating at 134 kHz frequency, only operation with the 134 kHz module on fob 102 may be possible. When RFID reader 104 is operating at the 13.56 MHz frequency, only operation with the 13.56 MHz module on fob 102 may be possible. Where RFID reader 104 supports both a 134 kHz frequency and a 13.56 MHz RF module, fob 102 may receive both signals from RFID reader 104. In this case, fob 102 may be configured to prioritize selection of the one or the other frequency and reject the remaining frequency. Alternatively, RFID reader 104 may receive signals at both frequencies from fob 102 upon interrogation. In this case, RFID reader 104 may be configured to prioritize selection of one or the other frequency and reject the remaining frequency.


Further, a protocol/sequence controller 314 may include an optional feedback function for notifying the user of the status of a particular healthcare information transaction. For example, the optional feedback may be in the form of an LED, LED screen and/or other visual display which is configured to light up or display a static, scrolling, flashing and/or other message and/or signal to inform a user using fob 102 that a healthcare information transaction is initiated (e.g., fob is being interrogated), the fob is valid (e.g., fob is authenticated), a healthcare information transaction is being processed, (e.g., fob transponder account identifier is being read by RFID reader 104) and/or the transaction is accepted or denied (e.g., account identifiers approved or disapproved). Such an optional feedback may or may not be accompanied by an audible indicator (or may present the audible indicator singly) for informing fob 102 user of the healthcare information transaction status. The audible feedback may be a simple tone, multiple tones, musical indicator, and/or voice indicator configured to signify when fob 102 is being interrogated, the healthcare information transaction status, or the like.


RFID antenna 106 may be in communication with a transponder 306 for transmitting an interrogation signal and receiving at least one of an authentication request signal and/or an account data from fob 102. Transponder 306 may be of similar description as transponder 114 of FIG. 2. In particular, transponder 306 may be configured to send and/or receive RF signals in a format compatible with antenna 106 in similar manner as was described with respect to fob transponder 114. For example, where transponder 306 is 13.56 MHz RF rated antenna 106 may be 13.56 MHz compatible. Similarly, where transponder 306 is ISO/IEC 14443 rated, antenna 106 may be ISO/IEC 14443 compatible.


RF module 302 may include, for example, transponder 306 in communication with authentication circuitry 308 which may be in communication with a secure database 310. Authentication circuitry 308 and database 310 may be of similar description and operation as described with respect to authentication circuitry 210 and secure memory database 212 of FIG. 2. For example, database 310 may store data corresponding to fob 102 which may be used to authorize the tracking of user performance over system 100. Database 310 may additionally store RFID reader 104 identifying information and/or provide such information to fob 102 for use in authenticating whether RFID reader 104 is authorized to be provided the fob transponder account identifier stored on fob database 214.


Authentication circuitry 308 may be of similar description and operation as authentication circuitry 210. That is, authentication circuitry 308 may be configured to authenticate the signal provided by fob 102 in a similar manner that authentication circuitry 210 may be configured to authenticate the signal provided by RFID reader 104. As is described more fully below, fob 102 and RFID reader 104 engage in mutual authentication. In this context, “mutual authentication” may mean that operation of the system 100 may not take place until fob 102 authenticates the signal from RFID reader 104, and RFID reader 104 authenticates the signal from fob 102.



FIG. 4 depicts a flowchart of an exemplary authentication process in accordance with the present invention. The authentication process is depicted as one-sided. That is, the flowchart depicts the process of RFID reader 104 authenticating fob 102, although similar steps may be followed in the instance that fob 102 authenticates RFID reader 104.


As noted, database 212 may store security keys for encrypting or decrypting signals received from RFID reader 104. In an exemplary authentication process, where RFID reader 104 is authenticating fob 102, RFID reader 104 may provide an interrogation signal to fob 102 (step 402). The interrogation signal may include a random code generated by the RFID reader authentication circuit 210, which is provided to fob 102 and which is encrypted using an unique encryption key corresponding to the unique fob 102 identification code. For example, protocol/sequence controller 314 may provide a command to activate the authentication circuitry 308. Authentication circuitry 308 may provide from database 310 a fob interrogation signal including a random number as a part of the authentication code generated for each authentication signal. The authentication code may be an alphanumeric code which is recognizable (e.g., readable) by RFID reader 104 and fob 102. The authentication code may be provided to fob 102 via the RFID RF interface 306 and antenna 106 (or alternatively antenna 108).


Fob 102 receives the interrogation signal (step 404). The interrogation signal including the authorization code may be received at RF interface 114 via antenna 202. Once fob 102 is activated, the interrogation signal including the authorization code may be provided to the modulator/demodulator circuit 206 where the signal may be demodulated prior to providing the signal to protocol/sequence controller 208. Protocol/sequence controller 208 may recognize the interrogation signal as a request for authentication of fob 102, and provide the authentication code to authentication circuit 210. Fob 102 may then encrypt the authentication code (step 406). In particular, encryption may be done by authentication circuit 210, which may receive the authentication code and encrypt the code prior to providing the encrypted authentication code to protocol/sequence controller 208. Fob 102 may then provide the encrypted authentication code to RFID reader 104 (step 408). That is, the encrypted authentication code may be provided to RFID reader 104 via modulator/demodulator circuit 206, RF interface 114 (e.g., transponder 114) and antenna 106.


RFID reader 104 may then receive the encrypted authentication code and decrypt it (step 410). That is, the encrypted authentication code may be received at antenna 106 and RF interface 306 and may be provided to authentication circuit 308. Authentication circuit 308 may be provided a security authentication key (e.g., transponder system decryption key) from database 310. The authentication circuit may use the authentication key to decrypt (e.g., unlock) the encrypted authorization code. The authentication key may be provided to the authentication circuit based on the unique fob 102 identification code. For example, the encrypted authentication code may be provided along with the unique fob 102 identification code. The authentication circuit may receive the unique fob 102 identification code and retrieve from database 310 a transponder system decryption key correlative to the unique fob 102 identification code for use in decrypting the encrypted authentication code.


Once the authentication code is decrypted, the decrypted authentication code is compared to the authentication code provided by RFID reader 104 at step 402 (step 412) to verify its authenticity. If the decrypted authorization code is not readable (e.g., recognizable) by the authentication circuit 308, fob 102 is deemed to be unauthorized (e.g., unverified) (step 418) and the operation of system 100 is terminated (step 420). Contrarily, if the decrypted authorization code is recognizable (e.g., verified) by fob 102, the decrypted authorization code is deemed to be authenticated (step 414), and the transaction is allowed to proceed (step 416). In one particular embodiment, the proceeding transaction may mean that fob 102 may authenticate RFID reader 104 prior to RFID reader 104 authenticating fob 102, although, it should be apparent that RFID reader 104 may authenticate fob 102 prior to fob 102 authenticating RFID reader 104.


It should be noted that in an exemplary verification process, authorization circuit 308 may determine whether the unlocked authorization code is identical to the authorization code provided in step 402. If the codes are not identical then fob 102 is not authorized to access system 100. Although the verification process is described with respect to situations where identical codes are used, in other embodiments identical codes are not required. For example, authentication circuit 308 may verify the decrypted code through any protocol, steps, or process for determining whether the decrypted code corresponds to authorized fob 102.


Authentication circuitry 308 may additionally be in communication with protocol/sequence controller 314 of similar operation and description as protocol/sequence controller 208 of FIG. 2. That is, protocol/sequence device controller 314 may be configured to determine the order of operation of RFID reader 104 components. For example, FIG. 5 illustrates an exemplary decision process under which protocol/sequence controller 314 may operate. Protocol/sequence controller 314 may command the different components of RFID reader 104 based on whether fob 102 is present (step 502). For example, if fob 102 is not present, then protocol/sequence controller 314 may command RFID reader 104 to provide an uninterrupted interrogation signal (step 504). That is, protocol/sequence controller 314 may command authentication circuit 308 to provide an uninterrupted interrogation signal until the presence of fob 102 is realized. If fob 102 is present, the protocol/sequence controller 314 may command RFID reader 104 to authenticate fob 102 (step 506).


As noted above, authentication may mean that protocol/sequence controller 314 may command authentication circuit 308 to provide fob 102 with an authorization code. If a response is received from fob 102, protocol/sequence controller may determine if the response is a response to RFID reader 104 provided authentication code, or if the response is a signal requiring authentication (step 508). If the signal requires authentication, then protocol/sequence controller 314 may activate the authentication circuit as described above (step 506). On the other hand, if fob 102 signal is a response to the provided authentication code, then protocol/sequence controller 314 may command RFID reader 104 to retrieve the appropriate security key for enabling recognition of the signal (step 510). That is, protocol/sequence controller 314 may command authentication circuit 308 to retrieve from database 310 a security key (e.g., transponder system decryption key), unlock the signal, and compare the signal to the signal provided by RFID reader 104 in the authentication process (e.g., step 506). If the signal is recognized, protocol/sequence controller 314 may determine that fob 102 is authorized to access system 100. If the signal is not recognized, then fob 102 is considered not authorized (step 512), in which case, protocol/sequence controller 314 may command the RFID controller to interrogate for authorized fobs (step 504).


Once protocol/sequence controller 314 determines that fob 102 is authorized, protocol/sequence controller 314 may seek to determine if additional signals are being sent by fob 102 (step 514). If no additional signal is provided by fob 102, then protocol/sequence controller 314 may provide all the components of RFID reader 104 to remain idle until such time as a signal is provided (step 516). Contrarily, where an additional fob 102 signal is provided, protocol/sequence controller 314 may determine if fob 102 is requesting access to engine 130 POI terminal 110 or if fob 102 is attempting to interrogate RFID reader 104 for return (e.g., mutual) authorization (step 518). Where fob 102 is requesting access to engine 130 POI terminal 110, protocol/sequence controller 314 may command RFID reader 104 to open communications with POI terminal 110 (step 524). In particular, protocol/sequence controller 314 may command POI terminal communications interface 312 to become active, permitting transfer of data between RFID reader 104, engine 130, and POI terminal 110.


On the other hand, if protocol/sequence controller 314 determines that fob 102 signal is a mutual interrogation signal, then protocol/sequence controller 314 may command RFID reader 104 to encrypt the signal (step 520). Protocol/sequence controller 314 may command encryption authentication circuit 318 to retrieve from database 320 the appropriate encryption key in response to fob 102 mutual interrogation signal. Protocol/sequence controller 314 may then command RFID reader 104 to provide the encrypted mutual interrogation signal to fob 102. Protocol/sequence controller 314 may command authentication circuit 318 to provide an encrypted mutual interrogation signal for fob 102 to mutually authenticate (step 522). Fob 102 may then receive the encrypted mutual interrogation signal and retrieve from authentication circuitry 212 a RFID reader 104 decryption key.


Although an exemplary decision process of protocol/sequence controller 314 is described, it should be understood that a similar decision process may be undertaken by protocol/sequence controller 208 in controlling the components of fob 102. Indeed, as described above, protocol/sequence controller 314 may have similar operation and design as protocol/sequence controller 208. In addition to the above, protocol/sequence controllers 208 and 314 may incorporate in the decision process appropriate commands for enabling USB interfaces 222 and 316, when the corresponding device is so connected.


Encryption/decryption component 318 may be further in communication with a secure account identifier database 320 which stores the security keys necessary for decrypting the encrypted fob account identifier. Upon appropriate request from protocol/sequence controller 314, encryption/decryption component (e.g., circuitry 318) may retrieve the appropriate security key, decrypt the fob account identifier and forward the decrypted account identifier to protocol/sequence controller 314 in any format readable by any later connected POI terminal 110. In one exemplary embodiment, the account identifier may be forwarded in a conventional magnetic stripe card format compatible with the ISO/IEC 7813 standard. That is, in accordance with the invention, there is no need to translate or correlate the account identifier to traditional magnetic stripe format as is done with the prior art. The invention processes the user and/or healthcare information request directly, as if the card associated with the account has been presented for storing user and/or healthcare information.


Upon receiving the account identifier in magnetic stripe format, protocol/sequence controller 314 may forward the account identifier to POI terminal 110 via communications interface 312 and data link 122, as best shown in FIG. 1A. POI terminal 110 may receive the decrypted account identifier and forward the magnetic stripe formatted account identifier to host network 112 for processing under the employer's business as usual standard. In this way, the present invention eliminates the need of a third-party server. Further, where POI terminal 110 receives a response from host network 112 (e.g., healthcare information authorized or denied), protocol/sequence controller 314 may provide the network response to RF module 302 for optically and/or audibly communicating the response to fob 102 user.


RFID reader 104 may additionally include USB interface 316, in communication with the protocol/sequence controller 314. In one embodiment, the USB interface may be a RS22 serial data interface. Alternatively, RFID reader 104 may include a serial interface such as, for example, a RS232 interface in communication with protocol/sequence controller 314. USB connector 316 may be in communication with a personalization system 116 (shown in FIG. 1B) for initializing RFID reader 104 to system 100 application parameters. That is, prior to operation of system 100, RFID reader 104 may be in communication with personalization system 116 for populating database 310 with a listing of security keys belonging to authorized fobs 102, and for populating database 320 with the security keys to decrypt fob 102 account identifiers placing the account identifiers in ISO/IEC 7813 format. In this way, RFID reader 104 may be populated with a unique identifier (e.g., serial number) which may be used by fob authentication circuitry 210 to determine if RFID reader 104 is authorized to receive fob 102 encrypted account identifier.



FIG. 1B illustrates an exemplary personalization system 100B, in accordance with the present invention. In general, typical personalization system 100B may be any system for initializing RFID reader 104 and fob 102 for use in system 100A. With reference to FIG. 1B, the similar personalization process for fob 102 may be illustrated. For example, personalization system 116 may be in communication with fob 102 via RF ISO 14443 interface 114 for populating fob database 212 with the security keys for facilitating authentication of the unique RFID reader 104 identifier. In addition, personalization system 116 may populate on database 212 a unique fob 102 identifier for use by RFID reader 104 in determining whether fob 102 is authorized to access system 100. Personalization system 116 may populate (e.g., inject) the encrypted fob 102 account identifier into fob database 214 for later providing to an authenticated RFID reader 104.


In one exemplary embodiment, personalization system 116 may include any standard computing system as described above. For example, personalization system 116 may include a standard personal computer containing a hardware security module operable using any conventional graphic user interface. Prior to populating the security key information account identifier and unique identifying information into fob 102 or RFID reader 104, the hardware security module may authenticate fob 102 and RFID reader 104 to verify that the components are authorized to receive the secure information.



FIGS. 6A-B illustrate an exemplary flowchart of a personalization procedure which may be used to personalize fob 102 and/or RFID reader 104. Although the following description discusses mainly personalization of fob 102, RFID reader 104 may be personalized using a similar process. The personalization process, which occurs between personalization system 116 and the device to be personalized (e.g., fob 102 or RFID reader 104), may begin, for example at step 602. Mutual authentication may occur between personalization system 116 and the device to be authenticated in much the same manner as was described above with regard to fob 102 mutually authenticating with RFID reader 104. That is, personalization system 116 may transmit a personalization system 116 identifier to the device to be authenticated which is compared by the device authentication circuitry 210, 308 against personalization system identifiers stored in the device database 212, 310. Where a match does not occur (step 604), the personalization process may be aborted (step 612). Where a match occurs (step 604), personalization system 116 may prepare a personalization file to be provided to the device to be personalized (step 606). If personalization system 116 is operated manually, the personalization file may be entered into personalization system 116 using any suitable system interface such as, for example, a keyboard (step 606). Where personalization system 116 operator elects to delay the preparation of the personalization files, personalization system 116 may abort the personalization process (step 610). In this context, the personalization file may include the unique fob 102 or RFID reader 104 identifier, security key for loading into database 212 and 310, and/or security keys for decrypting a fob transponder account identifier which may be loaded in database 320.


Fob 102 may be personalized by direct connection to personalization system 116 via RF ISO/IEC 14443 interface 114, or fob 102 may be personalized using RFID reader 104. Personalization system 116 and RFID reader 104 may engage in mutual authentication and RFID reader 104 may be configured to transmit the fob personalization file to fob 102 via RF. Once fob 102 is presented to RFID reader 104 (steps 608, 614) for personalization, fob 102 and RFID reader 104 may engage in mutual authentication (step 614). Where fob 102 is not presented to RFID reader 104 for personalization, the personalization process may be terminated (step 610).


If fob 102 is detected, personalization system 116 may create as a part of the personalization file, a unique identifier for providing to fob 102 (step 616). The identifier is unique in that one identifier may be given only to a single fob. That is, no other fob may have that same identifier. Fob 102 may then be configured and loaded with that identifier (step 618).


The encrypted fob 102 transponder account identifier may be populated into fob 102 in the same manner as is described with respect to the unique fob 102 identifier. That is, personalization system 116 may pre-encrypt the account data (step 620) and inject the encrypted account into fob database 214 (step 622). The encrypted account data may be loaded (e.g., injected) into fob 102 using RFID reader 104 as discussed above.


Once the personalization file is populated into fob 102, the populated information is irreversibly locked to prevent alteration, unauthorized reading and/or unauthorized access (step 624). Personalization system 116 may then create a log of the personalization file information for later access and analysis by the personalization system 116 resource (step 626).


It should be noted that in the event the personalization process is compromised or interrupted (step 628), personalization system 116 may send a security alert to the user (step 630) and the personalization process may be aborted (step 612). On the other hand, where no such compromising or interruption exists, personalization system 116 may be prepared to begin initialization on a second device to be personalized (step 632).



FIGS. 7A-B illustrate another exemplary embodiment of a personalization process which may be used to personalize RFID reader 104. RFID reader 104 may be in communication with personalization system 116 via RFID reader USB connection 316 (step 702). Once connected, personalization system 116 may establish communications with RFID reader 104 and RFID reader 104 may provide personalization system 116 any RFID reader 104 identification data presently stored on RFID reader 104 (step 704). In accordance with step 708, where RFID reader 104 is being personalized for the first time (step 706), RFID reader 104 and personalization system 116 may engage in mutual authentication as described above with respect to FIGS. 6A-B. After the mutual authentication is complete, personalization system 116 may verify that RFID reader 104 is properly manufactured or configured to operate within system 100A. The verification may include evaluating the operation of RFID reader 104 by determining if the RFID reader will accept predetermined default settings. That is, personalization system 116 may then provide RFID reader 104 a set of default settings (step 708) and determine if RFID reader 104 accepts those settings (step 712). If RFID reader 104 does not accept the default settings, personalization system 116 may abort the personalization process (step 714).


If the personalization system 116 determines that the personalization process is not the first personalization process undertaken by RFID reader 104 (step 706), personalization system 116 and RFID reader 104 may engage in a mutual authentication process using the existing security keys already stored on RFID reader 104 (step 710). If authentication is unsuccessful (step 712), personalization system 116 may abort the personalization process (step 714).


Where personalization system 116 and RFID reader 104 successfully mutually authenticate, personalization system 116 may update RFID reader 104 security keys (step 716). Updating the security keys may take place at any time as determined by a system 100 manager. The updating may take place as part of a routine maintenance or merely to install current security key data. The updating may be performed by downloading firmware into RFID reader 104 (step 718). In the event that personalization system 116 determines in step 706 that RFID reader 104 is undergoing an initial personalization, the firmware may be loaded into RFID reader 104 for the first time. In this context, “firmware” may include any file which enables the RFID reader 104 to operate under system 100 guidelines. For example, such guidelines may be directed toward the operation of RFID reader protocol/sequence controller 314.


Personalization system 116 may then determine if the personalization keys (e.g., security keys, decryption keys, RFID identifier) need to be updated or if RFID reader 104 needs to have an initial installation of the personalization keys (step 720). If so, then personalization system 116 may download the personalization keys as appropriate (step 722).


Personalization system 116 may then check RFID reader 104 to determine if fob 102 identifiers and corresponding security keys should be updated or initially loaded (step 724). If no updating is necessary personalization system 116 may end the personalization procedure (step 732). Contrarily, if personalization system 116 determines that fob 102 identifiers and corresponding keys need to be updated or installed, personalization system 116 may download the information onto RFID reader 104 (step 726). The information (e.g., fob security keys and identifiers) may be downloaded in an encrypted format and RFID reader 104 may store the information in RFID reader database 310 as appropriate (step 728). Personalization system 116 may then create or update a status log cataloging for later use and analysis by personalization system 116 user (step 730). Upon updating the status log, the personalization process may be terminated (step 732).


It should be noted that, in some instances it may be necessary to repeat the RFID reader personalization process in a similar manner as described above. In that instance, the personalization process described in FIGS. 7A and 7B may be repeated.



FIG. 8 illustrates an exemplary flow diagram for the operation of system 100A. The operation may be understood with reference to FIG. 1A, which depicts the elements of system 100A which may be used in an exemplary transaction. The process is initiated when a user desires to present fob 102 for storing and/or accessing user information such as healthcare information (step 802). Upon presentation of fob 102, a healthcare provider initiates the RF healthcare information transaction via RFID reader 104 (step 804). In particular, RFID reader 104 sends out an interrogation signal to scan for the presence of fob 102 (step 806). The RF signal may be provided via RFID reader antenna 106 or optionally via external antenna 108. The RF interrogation signal then activates fob 102 (step 808).


Fob 102 and RFID reader 104 may then engage in mutual authentication (step 810). Where the mutual authentication is unsuccessful, an error message may be provided to the user via the RFID optical and/or audible indicator (step 814) and the healthcare information transaction may be aborted (step 816). Where the mutual authentication is successful (step 812), a transaction will be initiated. That is, RFID reader 104 may provide the user with an appropriate optical and/or audible message (e.g., “healthcare information processing” or “wait”) (step 818). Fob protocol/sequence controller 208 may then retrieve from database 214 an encrypted fob account identifier and provide the encrypted account identifier to RFID reader 104 (step 820).


RFID reader 104 may then decrypt the account identifier and convert the account identifier into magnetic stripe (ISO/IEC 7813) format (step 822) and provide the unencrypted account identifier to engine 130 (step 824). In particular, the account identifier may be provided to POI terminal 110 for transmission to host network 112 for processing (step 828). Processing healthcare information will be discussed in greater detail herein. Upon processing, POI terminal 110 may then send an optical and/or audible healthcare information transaction status message to RFID reader 104 (step 830) for communication to the user (step 832). Once the user receives the status message, the transaction is completed (step 834.)


Processing user information may be achieved by several methods and systems. For example, in accordance with another aspect of the present invention, and with reference to FIG. 9, user 102 may access a remote personal information engine 130 through user interface 118 to facilitate the managing, storing, accessing, and/or other manipulation of user information such as healthcare information.


More particularly, engine 130 may comprise a variety of subprograms and/or databases that facilitate managing, storing, accessing, and/or other manipulation of user information such as healthcare information. Engine 130 may interface with various subprograms or databases, wherein the subprograms may be part of host network 112 and/or network 136. One skilled in the art will appreciate that engine 130 may additionally interface with components directly, through a LAN network or indirectly via any other system or network.


The databases and/or data sets comprising engine 130 may be interconnected such that information from one database and/or data set may be accessed by one, two, three or more other databases and/or data sets. By the term “access,” the databases may transmit, receive, obtain, link, view, connect, associate, interface, share, route, acquire, ascertain, retrieve, and/or gain information from one database to another. Thus, any information updated, received and/or sent to one database such as, for example, healthcare database 930, may be automatically updated throughout all or any portion of the other databases that are accessed by healthcare database 930. In addition, the databases comprising engine 130 may be configured with limited access rights/privacy rights. That is, a database owner may permit and/or prohibit other users, owners, issuers, and/or other third parties from accessing information stored on the database.


In general, systems and methods disclosed herein, are configured to facilitate the management of multiple distinct data sets associated with fob 102. Management of data sets may include such steps as adding, augmenting, updating and/or deleting data sets associated with fob 102. Such manipulations of the data may occur without replacing or reissuing fob 102. With reference to FIG. 10, an exemplary method 1000 according to the present invention is shown. Method 1000 may include issuing a healthcare fob 102 to a fob user (step 1010), enrolling multiple data set owners in a multiple account on fob 102 program (step 1012), and managing data sets associated with fob 102 (step 1020). In managing the data, method 1000 may determine, for example, whether the data should be added to a data set (step 1030), modified (step 1040) or deleted (step 1050), as described more fully below. Once the data is appropriately managed, fob 102 user may present the data contained on fob 102 to a healthcare system for completion of a transaction.


The system may be further configured such that, during an exemplary transaction, data sets associated with fob 102 may be managed. For example, the user may be prompted (e.g., on a screen, by electronic voice, by a store clerk, by a signal and/or the like) as to the possibility of adding, for example, a loyalty account to the same healthcare fob 102 and the user may also be presented with terms and/or conditions in a similar or different manner. The prompt may be configured to activate after the transaction terminal checks for a loyalty account, and discovers that none is present. The user may be prompted at any time during the transaction, and in one embodiment, the user is prompted at the completion of the transaction. If the user accepts the invitation to add data to fob 102, a new data set may be added (step 1030) and/or an existing data set is updated (step 1040). For example, if data is to be updated, the stand alone device may locate appropriate data to be updated on fob 102, and execute the updates (“modifications”) in accordance with data owner instructions, and the user, or clerk, may use the POS terminal for the transaction by selecting from a menu. If the data is to be added, the stand alone device may be configured to provide any account information (e.g., account identifier, security code, data owner routing number, etc.) to fob 102 for storage thereon. The stand alone may locate an appropriate (i.e., unused) database location on transaction instrument for storing the added data. The stand alone device facilitates storage of the data in a distinct location on fob 102 database, where the data is stored independently of any other data. In one embodiment of the invention, the data is added to a database location on fob 102 which may be reserved for independently storing all data owned by a particular data set owner (e.g., a BLOB), associated with a key for general data storage. Alternatively, the data may be stored in a distinct location on fob 102, which may be a separate location that is used to store any other data set. Further still, the data set may be stored in accordance with any storage format, and permitting the data to be stored and retrieved independently of other data.


The adding and updating of the data may be verified by the issuer, prior to executing the modifications. That is, the transaction location may be configured to send a message to the issuer, and then the issuer may apply its edit rules before sending a verification (or non-verification). If verified, all databases containing the data set to be updated or a mirror image of the data set to be updated, are modified in accordance with the user or issuer provided instructions, and/or the issuer defined data storage protocol or format.


In one exemplary embodiment, multiple account issuers may be enrolled in a multiple account management program using fob 102 in accordance with the invention (step 1012). That is, one or more issuers may supply the account number that they are using for the user, along with any other data (either ISO or BLOB). Permission for adding account issuer owned data may be obtained from the data set owner. The data set owner may then be requested to provide account information to be stored on a transaction instrument. The data set owner may then provide account information relative to a distinct user account for loading onto fob 102 in accordance with the present invention. The issuers may be enrolled prior to issuance of fob 102 or the issuers may be enrolled after issuance. By enrolling in the management program, the issuer may provide authorization for including the issuer-owned data on fob 102. The issuer-owned data may be included (e.g., added, deleted, modified, augmented, etc.) on fob 102 using a stand alone interaction device, POI 110, or user personal computer interface upon presentment of fob 102 to the POI 110 (step 1014). POI 110 may manipulate the issuer-owned data while preserving a format recognizable by an issuer account management system (step 1016). For example, POI 110 may identify the appropriate header or trailer associated with the data and add, delete or modify the data accordingly. POI 110 may manipulate the data using any manipulation instruction or protocol as provided by the data set owner so that the resulting manipulated data is still in a format recognizable by the data set owner system. POI 110 may be configured to manipulate the data based on the header. That is, POI 110 may be configured to recognize the format required by the data (e.g. the header describes the format of the data). In this way, POI 110 may manipulate the data while maintaining the data set owner's format. Alternatively, POI 110 may store the issuer-owned data on the fob 102 in any format, provided that the issuer-owned data is provided to the issuer system (or to healthcare system) in an issuer system (or healthcare system) recognizable format.


It should be noted that fob 102 may be issued with or without one or more data sets stored thereon. Fob 102 may be issued using various techniques and practices now known or hereinafter developed wherein an instrument is prepared (e.g., embossed and/or loaded with data) and made available to a user for effecting transactions. Although the present invention may contemplate managing data sets (step 1020) before issuing fob 102 (step 1010), in various exemplary embodiments, by way of illustration, the data sets are described herein as being managed (step 1020) after issuance (step 1010).


At any time after issuance (step 1010) of the healthcare fob 102, fob 102 may be used in a healthcare and/or commercial transaction. In one exemplary embodiment, a user communicates with a healthcare provider, indicates a desire to participate in a issuer/healthcare provided healthcare program. The user may communicate with the healthcare provider by, for example, presenting fob 102 to the healthcare provider and indicating a desire to complete a healthcare transaction. The healthcare data may be preloaded on fob 102. The user may indicate his desire to complete a transaction using any conventional process used by the healthcare provider. The user may further indicate that the user wishes to complete the transaction using fob 102. During completion of the transaction, the user may present fob 102 to a healthcare provider system (step 1022). Fob 102 is configured to communicate with the healthcare provider, using any conventional method for facilitating a transaction over a network.


In various exemplary embodiments, the steps of adding, deleting, augmenting and/or modifying data sets may be repeated. For example, first, second, and additional data sets may be added (step 1030) to fob 102 in any order. In one exemplary embodiment of the present invention, the first data set is owned by a first data set owner (i.e., first issuer) and the second data set is owned by a second data set owner (i.e., second issuer). Furthermore, the system may include replacing any portion of a first data set with any portion of a subsequent data set by deleting any portion of a data set (step 1050), then adding any portion of a data set (step 1030).


With reference now to FIG. 11, in one exemplary embodiment, a data set management system (“management system”) 1100 comprises a healthcare system 1120, various healthcare issuer systems 1130, and fob 102. Management system 1100 may further be accessed by a user 1101 on a self-service interaction device, such as, for example, user computer 134 or via a transaction device such as, for example, one or more POls 110, kiosk 1170, stand-alone interaction device 1190, automated teller, or the like. Healthcare issuer systems 1130 are configured to interact with fob 102 to receive and/or exchange data facilitating a transaction. Healthcare system 1120 may be operated, controlled and/or facilitated by any hospital, healthcare provider, medical entity, or merchant that facilitates the transfer of data and/or payment to fob 102.


The self-service user interaction device may be any device suitable for interacting with fob 102, and receiving information from fob 102 user and providing the information to a healthcare provider, insurance carrier, merchant, account issuer, account manager, data set owner, hospital point-of-interaction and the like. For example, a user may use a self-service device configured with a PC to provide healthcare information to a physician via a website (e.g., WebMD®) to obtain medical care. In one example, the self-service user interaction device may be configured to communicate information to and from the transaction device and to manipulate the data sets stored thereon. The self-service interaction device may be in communication with the various components of the invention using any suitable communications protocol.


The self-service interaction device may be initialized prior to use. For example, the self-service interaction device may be any system which may be initialized (“configured”) to communicate with healthcare system 1120. Where the self-service interaction device is not initialized prior to attempting communications with the healthcare system 1120 or fob 102, the self-service interaction device may be initialized at the healthcare system 1120 location. The interaction device may be initialized using any conventional method for configuring device communication protocol.


User 1101 may communicate with the healthcare provider and/or healthcare system 1120 in person (e.g., at the hospital), or electronically (e.g., from a user computer 134 via network 136 and/or network 112). During the interaction, the healthcare provider and/or healthcare system 1120 may offer healthcare services and/or products to user 1101 and/or transmit and/or receive information from user 1101. The healthcare provider and/or healthcare system 1120 may also offer user 1101 the option of completing the transaction using fob 102. The healthcare provider and/or healthcare system 1120 may provide the options to user 1101 using interactive user interface, suitable website or other Internet-based graphical user interface that is accessible by users.


Healthcare issuer systems 1130 may be configured to manipulate a transaction account associated with the corresponding issuer-owned data stored on fob 102 (or database 214, discussed herein) in accordance with a related transaction. For example, healthcare issuer system 1130 may receive “transaction information” and manipulate an account status or balance in accordance with the information received. In accordance with the transaction amount, healthcare issuer system 1130 may, for example, diminish a value available for completing a transaction associated with the account, or healthcare issuer system 1130 may alter the information relative to the account user (e.g., medical insurance information, personal information, etc.).


It should be noted that healthcare issuer systems 1130 may also be configured to interact with fob 102, directly or indirectly via database 214, POI 110, and/or interaction device 1190 to individually manage data sets on fob 102. For example, healthcare issuer systems 1130 may manage data sets on database 214. In some embodiments, the data sets on database 214 may then be stored on fob 102 when fob 102 is presented. In other embodiments, healthcare issuer systems 1130 may store data set information within their own systems which may communicate with fob 102 via user computer 134, kiosk 1170, or healthcare system 1120. In such embodiments, healthcare issuer system 1130 may be configured to push the data set to the fob 102 via the POI 110, or healthcare system 1120, kiosk 1170, interaction device 1190 or computer 134 which may be configured to pull such information from healthcare issuer system 1130.


POI 110 and/or interaction device 1190 may provide instructions to the healthcare issuer systems 1130 for requesting receipt of issuer-owned data, such as for example, account data, user identification data, user demographic data, user insurance data or the like, which the issuer wishes to store on fob 102. POI 110 and/or interaction device 1190 may communicate with healthcare issuer systems 1130 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 POI 110 and/or interaction device 1190 from healthcare issuer systems 1130, and stored onto the fob 102. In one exemplary embodiment, the issuer-owned data is stored using healthcare issuer system 1130 format which may be later formatted in healthcare system 1120 recognizable protocol when provided to the healthcare system 1120. In one embodiment, the issuer-owned information is stored on fob 102 in the identical format with which it was provided by healthcare issuer system 1130.


In a typical example of healthcare issuer modification of the data sets, one or more data sets may be modified by healthcare issuer system 1130 directly via the healthcare issuer systems 1130, upon presentment of fob 102 to system 1130. That is, user 1101 may present fob 102 to healthcare issuer system 1130, and healthcare issuer system 1130 may modify the issuer data stored thereon, using any issuer defined protocol. Alternatively, the modifications, or instructions for modification, may be initiated at healthcare issuer system 1130, and provided to network 136. The modifications and/or modification instructions may additionally be provided to a suitable device configured to communicate with fob 102, receive information regarding the data stored on fob 102, and to write or overwrite the information contained on fob 102. For example, as noted, POI 110 and/or interaction device 1190 may be suitable interaction devices which may be used to provide information to fob 102 to modify the information stored thereon. POI 110 and/or interaction device 1190 may be any devices capable of receiving data management instructions from healthcare issuer systems 1130 and for updating the data stored on fob 102, in accordance with the instructions received. In this regard, POI 110 and/or interaction device 1190 may include any electronic components, databases, processors, servers and the like which may be used to modify the data stored on fob 102 using any suitable data modification protocol as is found in the art. Preferably, POI 110 and/or interaction device 1190 is configured to modify the data on fob 102 in accordance with a data owner defined protocol.


In one exemplary embodiment, POI 110 and/or interaction device 1190, may be configured to modify fob's 102 issuer-owned data when fob 102 is initially configured, prior to providing fob 102 to user 1101. POI 110 and/or interaction device 1190 may additionally be configured to modify the issuer data on fob 102 when fob 102 is next presented, for example, to POI 110. In this regard, POI 110 and/or interaction device 1190 may receive from multiple distinct healthcare issuer systems 1130, via the network 136, the issuer provided modifications/instructions and may update fob 102 in real-time or substantially real-time. The modifications may be provided to POI 110 and/or interaction device 1190 for storage and later use when fob 102 is next presented. Alternatively, POI 110 and/or interaction device 1190 may be configured to retrieve the instructions from healthcare issuer system 1130 when fob 102 is next presented to POI 110 and/or interaction device 1190. Further, where other devices, such as, for example, kiosk 1170, or the like, are likewise configured to modify the issuer data on fob 102, 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 POI 110 and/or interaction device 1190.


Alternatively, the device to which fob 102 may be presented, may not be equipped for updating or modifying the data stored on fob 102. For example, healthcare system 1120 may be any conventional healthcare provider system which communicates to healthcare issuer system 1130, and which permits user 1101 to complete a financial transaction, but which is not configured to modify the healthcare issuer data contained on fob 102. In general, conventional healthcare provider systems are not configured to write or overwrite data included on fobs 102 presented to the healthcare provider system for processing. That is, healthcare system 1120 may include little or no additional software to participate in an online transaction supported by network 136. Management of the data sets on fob 102 may be performed independent of the operation of healthcare system 1120 (e.g., via healthcare issuer system 1130 or interaction device 1190). As such, the present invention may require no retrofitting of healthcare system 1120, to accommodate system 1100 operation. Thus, where healthcare system 1120 is not configured to modify the data on fob 102, such modifications may be executed as described above with respect to modifications being executed at interaction device 1190, POI 110 and/or by the issuer at healthcare issuer 1130 system.


Healthcare system 1120, kiosk 1170, interaction device 1190, and/or POI 110 may include additional systems and methods for permitting fob 102 user 1101 to self-manage the data stored on fob 102. In this case, the systems 1120, 1170, 1190 and 110 may include an additional user interface for use by user 1101 to identify the modification action to be taken. Where the systems 1120, 1170, 1190 and/or 110 are configured to communicate with fob 102 and to modify the data thereon, the modifications may be completed or substantially completed in real-time or substantially real-time. For example, user 1101 may present fob 102 to one of systems 1120, 1170, 1190 and 110, provide instructions to systems 1120, 1170, 1190 and/or 110 for modifying the data on fob 102. The instructions may include, for example, “ADD,” “DELETE,” MODIFY,” and systems 1120, 1170, 1190 and/or 110 may modify the data stored on fob 102 in accordance therewith. These instructions will be described in greater detail herein. The modifications may be made on fob 102 in real-time or substantially real-time, for example, prior to permitting fob 102 to be used by user 1101. Alternatively, the modifications or instructions for modification may be provided by user 1101 to healthcare system 1120 or kiosk 1170, and healthcare system 1120 or kiosk 1170 may further provide the modifications/instructions to network 136 for use in later modifying the data. For example, the modifications/instructions may be provided by system 1120 and/or 1170 to healthcare issuer system 1130 managed by the issuer owning the data to be modified. Healthcare issuer system 1130 may provide the modifications to, for example, interaction device 1190, for updating fob 102 when next presented. The modifications/instructions may additionally be provided from network 136 to a remote database, where the issuer-owned data corresponding to fob 102 and the issuer may be additionally stored (i.e., on engine 130, described herein). In one exemplary embodiment, the modifications/instructions may be stored at healthcare issuer system 1130, until such time as fob 102 is next presented to a device configured to modify the data on fob 102. Once presented, the modifications/instructions may be provided to the device (e.g., computer 134, interaction device 1190, etc.) for modifying fob 102 data.


In another exemplary embodiment, user 1101 may self-manage the data sets by, for example, modifying the data sets using a conventional computer system 134, which may be in communication with network 136. Computer system 134 may or may not be configured to interact with fob 102. Where computer system 134 is not configured to interact with fob 102, user 1101 may provide modifications or instructions to healthcare issuer system 1130 for later use in modifying the corresponding fob 102 data, for example, when fob 102 is next presented in similar manner as described above. Where computer 134 is configured to interact with fob 102 to modify the data stored thereon, user 1101 may provide modifications/instructions to computer 134 for modifying the data on the financial instrument in real-time or substantially real-time. That is, computer 134 may be configured to interact with, read, add, delete, and/or modify the data sets on fob 102. Consequently, computer 134 may receive modifications/instructions from user 1101 and perform the modifications accordingly, and may modify the data in real-time or substantially real-time. User computer 134 may additionally be configured to receive authorization of the modifications/instructions from healthcare issuer system 1130 prior to executing user 1101 requested changes. In one exemplary arrangement, user 1101 may provide the modifications/instructions via network 136 which may be additionally provided to healthcare issuer system 1130. Healthcare issuer system 1130 may receive user 1101 modifications/instructions and verify whether the identified updates are available to user 1101 or if the identified updates are valid. If the identified updates are authorized, healthcare issuer system 1130 may update a data storage area associated with fob 102. For example, healthcare issuer system 1130 may update an issuer database (not shown) containing data corresponding to the issuer-owned data associated with fob 102. Alternatively, healthcare issuer system 1130 may provide modifications/instructions to a database positioned remotely to healthcare issuer system 1130 for use in modifying the data stored thereon, which is associated to fob 102. As such, in accordance with the present invention, user 1101 may self-manage the data via, for example, user computer 134, kiosk 1170, healthcare system 1120, and/or a POI 110.


In one exemplary method of self-management, user 1101 logs onto a website via user computer 134, or onto a stand alone device, such as, for example, interaction device 1190 or kiosk 1170, and selects options for configuring data sets on fob 102. The changes may be transmitted to fob 102 RFID reader 104 configured to communicate the data to fob 102. In this context, RFID reader 104 may be any conventional transponder device reader or writer.


As noted, modifications to the data stored on fob 102 may be made in real-time, substantially real-time or batch process when fob 102 is presented to interaction device 1190, POI 110 and/or to RFID reader 104. However, as noted, various embodiments of the invention include a remote database 930 on engine 130 in communication with healthcare issuer system 1130 via network 136. The remote database 930 may additionally be in communication with one of user computer 134, kiosk 1170, healthcare system 1120 and/or interaction device 1190, for variously receiving modifications or instructions for performing modifications to the data stored thereon. In addition, database 930 may contain a data storage area which “mirrors” the data stored on fob 102. In this context “mirrored” or “mirror” may mean that the data is stored on database 930 in substantially identical configuration and format as stored on fob 102. As such, the present invention may be configured to permit modifications made to fob 102 data to be mimicked on corresponding data locations on database 930. For example, user 1101 may self-manage the data on database 930 via a user interface in communication with database 930 via network 136. In one exemplary embodiment, user 1101 may communicate with a “website” which is used to manage database 930, wherein database 930 is a database including unique locations for storing the issuer provided data and data sets correlative to the data and data sets stored on fob 102. The website may include an account management application which permits user 1101 to select which user accounts to add, delete, or modify with respect to fob 102. That is, user 1101 may provide unique identifying information to user computer 134 which may be recognized by the system (e.g., healthcare issuer system 1130 and/or remote system managing database 930) thereby permitting user 1101 to access the data corresponding to the unique identifying information stored on database 930. Further, prior to permitting modifications to database 930, the issuer owning the data may require authorization that such modifications may be performed. Further still, the present invention contemplates that database 930 may be self-managed by user 1101 in a similar manner, where healthcare system 1120, kiosk 1170 and/or interaction device 1190 are configured to provide modifications/instructions to the healthcare issuer systems 1130 and database 930.


As noted, in some exemplary embodiments of the invention, authorization must be obtained from healthcare issuer systems 1130 prior to executing any modifications to the data contained on fob 102 and/or database 930. Authorization may be obtained by requesting the authorization during the modification process. Authorization may be given where user 1101 provides the more appropriate security information, which is verified by healthcare issuer system 1130. The security information may be, for example, a security code granting access to the issuer-owned data on fob 102 or database 930. For example, POI 110 and/or RFID reader 104 may be configured to allow the input of a code, or an answer to a prompt which is provided to and verified by healthcare issuer system 1130. Once verified the modification requested may be made to the data contained on fob 102.


It should be noted that the authorization code may be used to permit user 1101 to select which issuer provided data to utilize for completion of a transaction. For example, POI 110 and/or RFID reader 104 may be programmed to search fob 102 for a data set containing a particular insurance data set, or to locate all available data sets for providing to user 1101 display available data sets to user 1101, thereby permitting user 1101 to select which data set to use to complete a healthcare transaction. If no data set is found, POI 110 and/or RFID reader 104 may alert user 1101 or prompt the healthcare provider to alert user 1101 of the possibility of adding issuer-owned data to fob 102. A positive response to this alert may cause POI 110 and/or RFID reader 104 to add an issuer data set to fob 102.


It is noted that user 1101 may already be a carrier of a certain type of insurance and/or healthcare program managed by a healthcare issuer system 1130 in which case the associated user 1101 insurance data may be assigned to user 1101 for inclusion on fob 102. As such, user 1101 may be permitted to add the insurance data set to fob 102. Alternatively, the user may become an insurance holder by selecting to add the insurance information to fob 102, using, for example, interactive device 1190. In some embodiments, changes made to the data sets stored on fob 102 may be updated to fob 102 in real-time or substantially real-time, where device 1190 is in communication with fob 102. Or the changes may be made the next time user 1101 presents fob 102 to POI 110, RFID reader 104 or to kiosk 1170, healthcare system 1120, or the like.


In another exemplary embodiment of the present invention, healthcare system 1120, kiosk 1170, and/or user computer 134 may be configured to interact with fob 102 via RFID reader 104.


In 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 fob 102, but remains dormant. For example, an insurance account may have been added to fob 102 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 hospital in a chain of hospitals, the identification of user's 1101 primary care physician, or to reflect user's 1101 medical allergies. In another example, a particular healthcare program may be added in association with fob 102, and the data set marked LOADED. In another example, user 1101 may interact with kiosk 1170 or the like to input personal information and configure the healthcare 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, user 1101 may enter a secret code to indicate that user 1101 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 receive a healthcare service. 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 fob 102. 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 RFID reader 104 may be 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, user 1101 may desire to remove a data set from fob 102. User 1101 may, for example, desire to use the available space on fob 102 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 fobs 102, such as when a insurance program 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 fob 102 and marked DELETED. A DELETED status indicator may be used to indicate that a portion of fob 102 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 fob 102 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 fob 102. 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.



FIG. 12 illustrates a general overview of an exemplary data set management method 1200 comprising the steps of: loading a data set (step 1210), initializing a data set (step 1220), verifying availability of data set (step 1230), and deleting a data set (step 1240). In this manner, a data set may be added to fob 102 and utilized until it is deleted. The adding and deleting steps are described in further detail with reference to FIGS. 13 and 19. Furthermore, the ability to update, modify, replace and/or delete a data set may be subject to security requirements.


In one embodiment, the various processes may include user 1101 facilitating the input of information into a data management system to cause the data set to be loaded. The information may be inputted by fob 102, keypad, magnetic stripe, smart card, electronic pointer, touchpad and/or the like, into a user computer 134, POI terminal 110, kiosk 1170, ATM terminal and/or directly into healthcare system 1120 via a similar terminal or computer associated with healthcare provider server 1122. The information may be transmitted via any network 136 discussed herein to healthcare system 1120 or healthcare issuer systems 1130. In another embodiment, the healthcare provider may enter the information into healthcare issuer system 1130 on behalf to user 1101. This may occur, for example, when user 1101 and/or healthcare issuer system 1130 authorizes the management of data sets on fob 102 over a telephone and the service representative inputs the information. In this embodiment, fob 102 may be updated at the next presentment opportunity such as when user 1101 attempts to compete a transaction using fob 102.


Any suitable procedures may be utilized to determine whether a data set is currently ready for use and available (step 1230). In one example, when fob 102 is presented, the availability of the data set is verified by checking whether the data set has been corrupted or blocked (step 1232), or deleted (step 1233). 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 fob 102 (“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 1234). If the data is corrupted or blocked, subroutines may be used to attempt to retry reading the data (step 1236). If the data set is marked deleted or removable, subroutines will prevent access to the data set (step 1235) and remove the data set (step 1240). 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 healthcare transaction. The data set may then be marked for deletion and deleted from fob 102 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 healthcare transaction. The marker may be a header or trailer as discussed herein.


Various methods may be used to add a data set to fob 102 or to replace a data set on fob 102. FIG. 13 illustrates an exemplary method of adding a data set to fob 102, including the general steps of presenting fob 102 (step 1310), verifying the addition of the data set to fob 102 (step 1320), placing the data set in a temporary holding area (step 1330), and adding the data set (step 1340).


More particularly, user 1101 presents fob 102 (step 1310) to RFID reader 104 configured to communicate with fob 102. User 1101 may present fob 102 at a point-of-purchase or to an interaction device 1190 and/or kiosk 1170. For example, user 1101 may wave fob 102 in front of POI 110 in a hospital, which is configured to receive data from fob 102. Alternatively, user 1101 may present fob 102 at a self-service location such as a kiosk 1170 in a mall. Moreover, user 1101 may present fob 102 to a peripheral device associated with a personal computer, or the like.


User 1101 is then given the opportunity to add a data set to fob 102. For example, RFID reader 104 may detect the absence of a particular data set on fob 102 by searching fob 102 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, user 1101 may be prompted to confirm the addition of this data set to fob 102 (step 1320). The user may be prompted via an interactive user interface displaying the option to add the data set. In one example, when user 1101 presents fob 102 to a healthcare provider, RFID reader 104 may detect the absence of an insurance data set and provide a message on a display to user 1101 or the hospital clerk indicating that the insurance data set can be added if desired. User 1101 may answer in the negative and complete the healthcare transaction using typical transaction methods (step 1125). Alternatively, if user 1101 provides an affirmative response, the algorithm may prepare a data set for communication with fob 102 (step 1130). The process may determine whether the data set (or information that could be used to create the data set) exists in some form or on some device other than on fob 102 (step 1132). Determining whether a data set exists may involve querying a healthcare issuer system 1130, database 930, or the like. For example, healthcare issuer system 1130 may compare the data set to other data sets healthcare issuer system 1130 has assigned to a particular user 1101. If the data set is not assigned to a particular user, then issuer system may determine that the data set is available for adding to fob 102. Determining whether a data set exists may also take place when a store clerk verbally asks (or a screen prompts) user 1101 to present an insurance card containing the information. For example, the data set may exist on a an insurance card, it may be 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 1336). In this example, user 1101 may present the insurance card and the data read from the insurance card may then be stored in a data set associated with fob 102. For example, user 1101 may desire to add a dental insurance card to the user's 1101 fob 102. User 1101 may swipe, scan or otherwise present the dental insurance card such that the data set from the dental insurance card is captured. The system may be further configured such that the healthcare provider, kiosk 1170, or computer system may access healthcare issuer system 1130 to obtain information for creating the data set. Thus, if user 1101 does not have the insurance card on user's 1101 person, system 1130 may prompt the clerk to request identifying/security information and to access the user's 201 account and therefore facilitate adding an insurance data set associated with user's 1101 fob 102. 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 1334) for inclusion on fob 102. 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 930, local memory or the like) for transfer to fob 102 (step 1338). Additional data sets may be prepared for transmittal to fob 102 (step 1339).


In this exemplary embodiment, fob 102 is presented again to RFID reader 104 (step 1342). RFID reader 104 is configured to attempt to transfer the data set(s) to fob 102 (step 1344). For example, existing RFID reader 104 may be configured with software and/or hardware upgrades to transmit data to fob 102. 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, user 1101 may wave fob 102 past RFID reader 104 one or more times during the addition process. The transaction may be completed (step 1325) 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 healthcare transaction takes place along with the addition of data sets. It should also be noted that under appropriate circumstances, user 1101 could add data sets at a point-of-interaction without actually completing a transaction.


In various exemplary embodiments, user 1101 and/or the owner of the data set may manage the data set (i.e., steps 1332-1339) in advance of presenting fob 102. For example, user 1101 on user computer 134 may choose to add or delete data sets via a website configured for management of data sets. In another example, healthcare issuer system 1130 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 fob 102. The transmission of the data sets may be transparent to user 1101. For example, user 1101 may present fob 102 (step 1342) to complete a healthcare transaction and the waiting data sets may automatically be added to the user's 1101 fob 102 (step 1340).


Similar steps may be taken to replace or update data sets with new information. For example, user 1101 at a point-of-interaction 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. 13, the existing data set on fob 102 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 fob 102.


Furthermore, data sets may be deleted using any suitable techniques. For example, FIG. 19 illustrates an exemplary data set deletion method 1900. User 1101 presents fob 102 at a point-of-interaction 110, self-service location, or the like (step 1910). POI 110 may be configured to facilitate user 1101 providing input regarding deletion of a data set (step 1920). For example, POI 110 may ask user 1101, via a test screen, whether user 1101 desires to manage the data sets on fob 102. Through a series of menus and/or questions, user 1101 may identify data sets that user 1101 desires to delete.


Furthermore, POI 110 may be configured to interrogate database 214 or specific healthcare issuer systems 1130 to determine whether the deletion of a data set has been requested earlier. If user 1101 requests deletion of one or more data sets, the data sets are then identified (step 1930). It will be noted that step 1930 may occur concurrently with step 1920 or user 1101 may request deletion of a specific account at this step. In other embodiments, accounts may be deleted per predefined rules or policies, and/or the like. Upon presenting fob 102 again, the identified data set(s) are removed from fob 102 (steps 1940 and 1950). Other methods of deleting data sets may also be used to manage data sets on fob 102.


In an exemplary embodiment, management of the data sets may further include selecting preferences for use of the data sets. For example, user 1101 may indicate a desire to use data set A, associated with a primary insurance carrier, as a first option, but to use data set B, associated with a secondary insurance carrier when data set A is not available. In another example, one data set may be used for hospital transactions while another data set may be used for private physician transactions. User's 1101 data set preferences may be stored on fob 102 as a data set. In this example, when fob 102 is presented, all available data sets are read and RFID reader 104 determines which data sets are to be used based in part on the preferences stored on fob 102, which preferences may be updated from time to time.


In another embodiment, fob 102 may be configured to comprise two or more antennae that are both configured to send and receive information and fob 102 may be responsive to different RF frequencies. In this exemplary embodiment, each antenna may be configured to communicate using a particular protocol and/or frequency. Thus, fob 102 may be configured to communicate with two or more RFID readers 104 that each communicate with fob 102 using different transmission frequencies. For more information on dual antenna fobs, see U.S. patent application Ser. No. 10/192,488, filed Jul. 9, 2002, by inventors Michael J. Berardi, et al., and entitled “SYSTEM AND METHOD FOR PAYMENT USING RADIO FREQUENCY IDENTIFICATION IN CONTACT AND CONTACTLESS TRANSACTIONS” and its progeny, which are hereby incorporated by reference.


As noted, the data associated with fob 102 may be modified by user 1101 and/or by healthcare issuer system 1130. FIGS. 20 and 21 respectively, depict exemplary methods for user 1101 and healthcare issuer system 1130 data management. For example, with respect to user 1101 self-management, healthcare issuer system 1130 may provide user 1101 with fob 102 (step 2002). Fob 102 may be provided with pre-stored issuer-owned data, or fob 102 may be configured to permit user 1101 to add the data at a later date. User 1101 may the present fob 102 to RFID reader 104 for initiating the self-management process (step 2004). RFID reader 104 may then read the data on fob 102, and provide the data to interaction device 1190 and/or POI 110 for displaying to user 1101 (step 2006). Alternatively, interaction device 1190 and/or POI 110 may provide user 1101 a list of available data to be added to fob 102.


User 1101 may then be permitted to identify which data user 1101 wishes to modify (step 2008). Identification of the data may include providing the data with a trailer or header indicating the action to be taken (e.g., add, delete, augment, overwrite, etc.). The header and an indicator of the data to be modified may then be provided to healthcare issuer system 1130 (step 2010) for verification as to whether such desired modifications are available to user 1101 (step 2012). If the desired modifications are not available, the modifications will not be made and user 1101 is notified accordingly (step 2014). User 1101 may then be permitted to identify whether other data is to be modified (step 2016). If so (step 2008), interaction device 1190 and/or POI 110 may provide a request for modification to healthcare issuer system 1130 (step 2010) and the verification process is repeated.


Alternatively, where healthcare issuer system 1130 verifies that the modifications may be made (step 2012), interaction device 1190 and/or POI 110 may make the modifications to the appropriate data on fob 102 (step 2018). Additionally, where the system 1100 includes a remote database 930 for storing a mirror image of the data contained on fob 102 (step 2020), interaction device 1190, POI 110 and/or healthcare issuer system 1130, may facilitate modification of remote database 930 (step 2022). User 1101 may then be permitted to select other data sets to modify (step 2016), in similar manner as was described above.


In either case, where the modifications are complete, user 1101 may then present fob 102 to a healthcare provider for use in completing a transaction.



FIG. 21 depicts an exemplary method 2100 wherein healthcare issuer system 1130 manages the data contained on fob 102. For example, the issuer may identify on healthcare issuer system 1130 which data sets are to be modified (step 2102). The modifications may then be made to the corresponding data set stored on healthcare issuer system 1130 (step 2104). Where system 1100 includes remote database 930, healthcare issuer system 1130 may provide the modifications/instructions to database 214 for updating database 930 accordingly (step 2106).


In addition, healthcare issuer system 1130 may query as to whether healthcare issuer system 1130 is in possession of fob 102 for executing the modifications to the data set on fob 102 in real-time or substantially real-time (step 2108). If so, the modifications are made accordingly (step 2110) and fob 102 may then be provided to user 1101 for use in completing a healthcare transaction using the distinct data sets modified (step 2112).


Where healthcare issuer system 1130 is not in possession of fob 102 at the time the healthcare issuer determines that modifications to the data on fob 102 are to be made (step 2108), the modifications may be made on healthcare issuer system 1130 (step 2104), and may be placed in queue, for uploading to fob 102 when it is next presented to healthcare issuer system 1130 or to the appropriate RFID reader 104 (step 2114). When fob 102 is presented thusly (step 2116), healthcare issuer system 1130 may be notified that fob 102 is available for modifying, and healthcare issuer system 1130 may then provide the instructions for modification (e.g., modified data including headers) to the appropriate RFID reader 104 for modifying fob 102 (step 2118). Fob 102 may then be provided to user 1101 for use in completing a transaction (step 2112).


As noted, fob 102 may include multiple data sets which correspond to distinct healthcare issuer systems 1130, and which may be used to complete a healthcare transaction. User 1101 may be permitted to choose which data set to use for healthcare transaction completion. FIG. 22 illustrates an exemplary method 2200 by which user 1101 may choose which of the data sets to use to complete a healthcare transaction. For example, user 1101 may present fob 102 to healthcare system 1120 for use in completing a healthcare transaction (step 2202). Healthcare system 1120 may then read the data stored on fob 102 and report to user 1101 all distinct data sets which may be used to complete a healthcare transaction (2204). User 1101 may then select the appropriate data set (step 2206) and the healthcare transaction is completed accordingly (step 2208).


It should be noted that completion of a healthcare transaction may be performed under any business as usual standard employed by the healthcare provider and/or healthcare issuer system 1130. For example, the healthcare provider server 1122 may be configured to communicate transaction data to the appropriate healthcare issuer system 1130, in real-time or substantially real-time, or by using batch processing at the end of each day. Any suitable means for delivering the transaction data to the healthcare issuer systems 1130 may be used. In one exemplary embodiment of the present invention, the transaction data may be delivered to healthcare issuer system 1130 via network 136. Healthcare issuer system 1130 may receive the transaction information and process the transaction under issuer defined protocol independent of any other protocol used by other issuers to process a transaction. Healthcare issuer system 1130 may receive the transaction data and provide the healthcare provider with the appropriate satisfaction for the transaction.


In another exemplary embodiment of the present invention, system 100A may be configured with one or more biometric scanners, processors and/or systems. A biometric system may include one or more technologies, or any portion thereof, such as, for example, recognition of a biometric. As used herein, a biometric may include a user's voice, fingerprint, facial, ear, signature, vascular patterns, DNA sampling, hand geometry, sound, olfactory, keystroke/typing, iris, retinal or any other biometric relating to recognition based upon any body part, function, system, attribute and/or other characteristic, or any portion thereof. Certain of these technologies will be described in greater detail herein. Moreover, while some of the examples discussed herein may include a particular biometric system or sample, the invention contemplates any of the biometrics discussed herein in any of the embodiments.


The biometric system may be configured as a security system and may include a registration procedure in which a user of transaction instrument (e.g., fob 102) proffers a sample of his fingerprints, DNA, retinal scan, voice, and/or other biometric sample to an authorized sample receiver (ASR). An ASR may include a local database, a remote database, a portable storage device, a host system, an issuer system, a healthcare provider system, a fob issuer system, a healthcare system, an employer, a financial institution, a non-financial institution, a loyalty point provider, a company, the military, the government, a school, a travel entity, a transportation authority, a security company, and/or any other system or entity that is authorized to receive and store biometric samples and associate the samples with specific biometric databases and/or transaction instruments (e.g., fobs 102). As used herein, a user of a fob, fob user, or any similar phrase may include the person or device holding or in possession of the fob, or it may include any person or device that accompanies or authorizes the fob owner to use the fob.



FIG. 14 illustrates an exemplary registration procedure in accordance with the present invention. In one embodiment, a fob user may contact an ASR to submit one or more biometric samples to an ASR (step 1401). The fob user may contact the ASR and submit a sample in person, through a computer and/or Internet, through software and/or hardware, through a third-party biometric authorization entity, through a kiosk and/or biometric registration terminal, and/or by any other direct or indirect means, communication device or interface for a person to contact an ASR.


A fob user may then proffer a biometric sample to the ASR (step 1403). As used herein, a biometric sample may be any one or more of the biometric samples or technologies, or portion thereof, described herein or known in the art. By proffering one or more biometric samples, a biometric may be scanned by at least one of a retinal scan, iris scan, fingerprint scan, hand print scan, hand geometry scan, voice print scan, vascular scan, facial and/or ear scan, signature scan, keystroke scan, olfactory scan, auditory emissions scan, DNA scan, and/or any other type of scan to obtain a biometric sample. Upon scanning the sample, the system may submit the scanned sample to the ASR in portions during the scan, upon completing the scan or in batch mode after a certain time period. The scanned sample may include a hardcopy (e.g., photograph), digital representation, an analog version or any other configuration for transmitting the sample. The ASR receives the sample and the ASR may also receive copies of a fob user's biometric data along with the sample or at a different time (or within a different data packet) from receiving the sample.


The ASR and/or fob user 102 may store the sample in digital and/or any storage medium known in the art and correlate and/or register the sample with fob user information. By storing the sample in digital format, the ASR may digitize any information contained in one of the biometric scans described herein. By storing the sample in any storage medium, the ASR may print and/or store any biometric sample. Hardcopy storage may be desirable for back-up and archival purposes. As used herein, registered samples may include samples that have been proffered, stored and associated with user information.


The biometric sample may also be associated with user information (step 1405). The sample may be associated with user information at any step in the process such as, for example, prior to submission, during submission and/or after submission. In one embodiment, the user may input a PIN number or zip code into the POI terminal, then scan the biometric to create the biometric sample. The local POI system may associate the biometric sample data with the PIN and zip code, then transmit the entire packet of information to the ASR. In another embodiment, the POI may facilitate transmitting the sample to an ASR, and during the transmission, the sample may be transmitted through a third system which adds personal information to the sample.


The information associated with the biometric sample may include any information such as, for example, fob user information, fob 102 information, fob 102 identifier information, fob 102 vender information, fob 102 operability information, and/or fob 102 manufacturing information. Fob 102 information is not limited to transponder information and may include information related to any healthcare information and/or any transaction instrument such as smart cards, credit cards, debit cards, healthcare provider-specific cards, loyalty point cards, cash accounts and any other transaction instruments and/or accounts. The fob user information may also contain information about the user including personal information—such as name, address, and contact details; financial information—such as one or more financial accounts associated with the fob user; loyalty point information—such as one or more loyalty point accounts (e.g., airline miles, charge card loyalty points, frequent diner points) associated with the fob user; and/or non-financial information—such as employee information, employer information, medical information, family information, and/or other information that may be used in accordance with a fob user.


For example, fob user may have previously associated a medical insurance account and a dental insurance account with his biometric sample which is stored at an ASR. Later, when fob user desires to access healthcare information stored on the fob, fob user may submit his biometric sample while using fob 102 for accessing information at the POI. The POI may facilitate sending the biometric sample to the ASR such that the ASR authorizes the biometric sample and checks a look-up table in the ASR database to determine if any information is associated with the sample. If information (e.g., insurance accounts) is associated with the sample, the ASR may transmit the information to the POI terminal. The POI terminal may then present fob user with a list of the two accounts associated with the biometric sample. Fob user and/or a healthcare administrator may then chose one of the accounts in order to continue and finalize the information transaction.


In another embodiment, fob user may associate each account and/or type of information with a different biometric sample. For example, during registration, fob user may submit a sample of his right index fingerprint, and request that the system primarily associate this sample with a particular credit card and/or account. Fob user may additionally submit a sample of his left index fingerprint and request that the system primarily associate the sample with a particular medical insurance account. Additionally, fob user may submit his right thumbprint and request that the system primarily associate that sample with a particular dental insurance account. By “primarily” associating a sample with an account, the system initially associates the sample with that account. For example, fob user submitting his right index fingerprint for a financial transaction may have money for a healthcare transaction taken from his credit card account. Fob user may additionally specify which accounts should be secondarily associated with a sample. For example, fob user may have a medical insurance account secondarily associated with his right index fingerprint. As a result, if fob user submits his right index fingerprint for a transaction, and the primary account associated with the sample may be used to pay the account, while the secondary account may be accessed in order to provide further information for the transaction.


While primary and secondary account association is described herein, any number of accounts may be associated with a sample. Moreover, any hierarchy or rules may be implemented with respect to the association. For example, the fob user may instruct the system to access a medical insurance account when it receives a right index fingerprint sample, the transaction involves the use of a debit card and the transaction involves paying a co-pay amount. While fingerprint samples are discussed herein, any biometric sample may have one or more accounts associated with it and may be used to facilitate a transaction using any of the routines discussed herein.


The ASR and/or fob user may associate a specific fob 102 identifier with the biometric sample by any method known in the art for associating an identifier (e.g., through the use of software, hardware and/or manual entry.) The ASR may additionally verify the fob user and/or fob 102 by using one or more forms of the user's secondary identification (step 1407). For example, the ASR may verify the fob user by matching the fob information to information retrieved from scanning information from a fob user's driver's license, medical insurance card, and/or other form of secondary identification. The ASR may verify fob 102 by contacting the vendor of fob 102 to confirm that fob 102 was issued to a specific fob user. In another embodiment, the ASR may activate fob 102 during the registration procedure to confirm that fob 102 transponder identifier and other information is properly associated with the fob user and the fob user's specific biometric samples. The ASR may additionally employ one or more verification methods to confirm that the biometric sample belongs to the user, such as, for example, the ASR may request from the user demographic information, further biometric samples and/or any other information. As used herein, “confirm”, “confirmation” or any similar term includes verifying or substantially verifying the accuracy, existence, non-existence, corroboration, and/or the like of the information, component, or any portion thereof. The ASR may additionally employ one or more additional processing methods in order to facilitate association of a biometric sample. As used herein, the term processing may include scanning, detecting, associating, digitizing, printing, comparing, storing, encrypting, decrypting, and/or verifying a biometric and/or a biometric sample, or any portion thereof.


Upon association, authentication and/or verification of the biometric sample and fob 102, the system may store the sample and fob 102 identifier (step 1409) in one or more databases on and/or in communication with system 100 via a network, server, computer, or any other means of communicating as described herein. The database(s) may be any type of database described herein. For example, a biometric sample stored on fob 102 may be stored in database 212 and/or on databases found in engine 130. The database(s) may be located at or operated by any of the entities discussed herein such as, for example, the ASR and/or by a third-party biometric database operator.


The information stored in the database may be sorted or stored according to one or more characteristics associated with the sample in order to facilitate faster access to the stored sample. For example, fingerprint samples may be stored in a separate database than voice prints. As another example, all fingerprints with certain whirl patterns may be stored in a separate sub-database and/or database from fingerprints with arch patterns.


The biometric samples may also be stored and/or associated with a personal identification number (PIN) and/or other identifier to facilitate access to the sample. The PIN may be fob user selected or randomly assigned to the biometric sample. The PIN may consist of any characters such as, for example, alphanumeric characters and/or foreign language characters.


The system may further protect the samples by providing additional security with the sample. The security may include, for example, encryption, decryption, security keys, digital certificates, firewalls and/or any other security methods known in the art and discussed herein. One or more security vendors may utilize the security methods to store and/or access the biometric samples. The present invention anticipates that storage of the biometric samples may be such that a sample is first encrypted and/or stored under a security procedure, such that the sample may only be accessed by a vendor with the proper level of access or security which corresponds to or provides access to the stored sample. The samples may be accessible by certain vendors such as, for example, fob 102 transaction account provider system, a healthcare system, an issuer system, a healthcare provider system, a fob issuer system, an employer, a financial institution, a non-financial institution, a loyalty-point provider, a company, the military, the government, a school, a travel entity, a transportation authority, and/or a security company.


The fob of the invention may include a particular security system wherein the security system incorporates a particular biometric system. As shown in FIG. 15, fob 102 includes a biometric security system 1502 configured for facilitating biometric security using, for example, fingerprint samples. Alternatively, as shown in FIG. 16, RFID reader 104 includes a biometric security system 1602 configured for facilitating biometric security using biometric samples. As used herein, fingerprint samples may include samples of one or more fingerprints, thumbprints, palmprints, footprints, and/or any portion thereof. Biometric security system 1502, 1602 may include a biometric sensor 1504, 1604 which may be configured with a sensor and/or other hardware and/or software for acquiring and/or processing the biometric data from the person such as, for example, optical scanning, capacitance scanning, or otherwise sensing the portion of fob user. In one embodiment, biometric sensor 1504, 1604 of the security system 1502, 1602 may scan a finger of a fob user in order to acquire his fingerprint characteristics into fob 102. Biometric sensor 1504, 1604 may be in communication with a sensor interface/driver 1506, 1606 such that sensor interface 1506, 1606 receives the fingerprint information and transmits a signal to controller 208, 308 to facilitate activating the operation of fob 102. A power source (e.g., battery 1503) may be in communication with biometric sensor 1504, 1604 and sensor interface 1506, 1606 to provide the desired power for operation of the biometric security system components.


In one exemplary application of fob 102 incorporating biometric security system 1502, the user may place his finger on the biometric sensor to initiate the mutual authentication process between fob 102 and RFID reader 104, and/or to provide verification of the user's identity. Fob 102 may digitize the fingerprint and compare it against a digitized fingerprint stored in a database (e.g., security database 212) included on fob 102. The fingerprint information may additionally be compared with information from one or more third-party databases communicating with fob 102 through any communication software and/or hardware, including for example, RFID reader 104, a USB connection, a wireless connection, a computer, a network and/or any other means for communicating. This transfer of information may include use of encryption, decryption, security keys, digital certificates and/or other security devices to confirm the security of the sample. Fob 102 may additionally communicate with third-party databases to facilitate a comparison between fob 102 identifier and other fob identifiers stored with the biometric samples. As used herein, “compare,” “comparison” and similar terms may include determining similarities, differences, existence of elements, non-existence of elements and/or the like.


Protocol/sequence controller 208 may facilitate the local comparison to authenticate the biometric and authentication circuit 210 may validate the information. Any of the embodiments may alternatively or additionally include remote comparisons performed or controlled by one or more third-party security vendors. One or more comparison techniques and/or technologies may be used for comparisons. For example, for fingerprint comparisons, protocol/sequence controller 208 may utilize an existing database to compare fingerprint minutia such as, for example, ridge endings, bifurcation, lakes or enclosures, short ridges, dots, spurs and crossovers, pore size and location, Henry System categories such as loops, whorls, and arches, and/or any other method known in the art for fingerprint comparisons.


Fob 102 may additionally be configured with secondary security procedures to confirm that fake biometric samples are not being used. For example, to detect the use of fake fingers, fob 102 may be further configured to measure blood flow, to check for correctly aligned ridges at the edges of the fingers, and/or any other secondary procedure to reduce biometric security fraud. Other security procedures for ensuring the authenticity of biometric samples may include monitoring pupil dilation for retinal and/or iris scans, pressure sensors, blinking sensors, human motion sensors, body heat sensors and/or any other procedures known in the art for authenticating the authenticity of biometric samples.


After verifying the biometric information, fob 102 and RFID reader 104 may begin mutual authentication, and the information and/or financial transaction may proceed accordingly. However, the invention contemplates that the verification of biometric information may occur at any point in the transaction such as, for example, after the mutual authentication. At any point in the transaction, the system may additionally request fob user to enter a PIN and/or other identifier associated with the transaction account and/or biometric sample to provide further verification of fob user's identification. As part of the transaction, fob user payor may be requested to select from one of the insurance accounts, healthcare accounts, financial accounts, loyalty accounts, credit accounts, debit account, and/or other accounts associated with the biometric sample. The user may be presented with a list of account options on a display associated with RFID reader 104, fob 102, a third-party security device and/or any other financial or transaction device association with a transaction. In another embodiment, a payee may select one of the accounts. For example, a hospital payee may manually and/or automatically select a specific medical insurance account, if available, for a transaction.


RFID reader 104 may also be configured with secondary security procedures biometric to confirm that fake biometric samples are not being used. For example, RFID reader 104 may be further configured to measure blood flow, body heat and/or any other secondary procedure to reduce biometric security fraud. Other security procedures for ensuring the authenticity of biometric samples may include monitoring pupil dilation for retinal and/or iris scans, pressure sensors, blinking sensors, human motion sensors, and/or any other procedures known in the art for authenticating the authenticity of biometric samples. After verifying the biometric information, fob 102 and RFID reader 104 may begin mutual authentication, and the transaction may proceed accordingly.


While the biometric safeguard mechanisms describe fob 102 and/or RFID reader 104 configured with a biometric safeguard mechanism, any part of system 100 may be equipped with a biometric safeguard system. For example, the invention contemplates receiving a biometric sample only at the reader, only at the fob, at both the fob and the reader, or at any other combination of location or device. As such, any scanner or database discussed herein may be located within or associated with another device. For example, the fob may scan a user biometric, but the database used for comparison may be located within the reader or healthcare server. In other embodiments, the biometric security device may be located away from the point-of-interaction device and/or provide other functions. In one embodiment, the biometric security device may be located outside of an emergency room intake area to allow a user to not only start the authentication process before check-in, but also to allow expedited insurance authentication of a patient for medical procedures. In this regard, the biometric security device may communicate the information to the point-of-interaction device so the POI may verify that the person that checked into the hospital is the same person that is now receiving medical attention. In another embodiment, any portion of system 100 may be configured with a biometric security device. The biometric security device may be attached and/or free-standing. Biometric security devices may be configured for local and/or third-party operation. For example, the present invention contemplates the use of third-party fingerprint scanning and security devices such as those made by Interlink Electronics, Keytronic, Identix Biotouch, BIOmetriclD, onClick, and/or other third-party vendors.


In yet another embodiment, the database used for comparison may contain terrorist and/or criminal information. As used herein, terrorists and/or criminals may include terrorists, felons, criminals, convicts, indicted persons, insurgents, revolutionaries and/or other offenders. The information may include biometric information, personal information as described herein, arrest records, aliases used, country of residence, affiliations with gangs and terrorist groups, and/or any other terrorist and/or criminal information.


As an example of a secondary security procedure in accordance with the present invention, the biometric sensor 1504, 1604 and/or RFID reader 104 may be configured to allow a finite number of scans. For example, biometric sensor 1504, 1604 may be configured to only accept data from a single scan. As a result, biometric sensor 1504, 1604 may turn off or deactivate fob 102 and/or RFID reader 104 if more than one scan is needed to obtain a biometric sample. Biometric sensor 1504, 1604 may also be configured to accept a preset limit of scans. For example, biometric sensor 1504, 1604 may receive three invalid biometric samples before it turns off and/or deactivates fob 102 and/or RFID reader 104.


The sensor or any other part of system 100 may also activate upon sensing a particular type or group of biometric samples. The activation may include sending a signal, blinking, audible sound, visual display and/or the like. For example, if the sensor detects information from a specific insurance holder, the system may display a special information on the POI terminal. In another embodiment, the system may send a signal to a primary account holder or any other person or device to notify them that the fob is being used or that a condition or rule is being violated (e.g., certain user information is being accessed).


Any of the biometric security systems described herein may additionally be configured with a fraud protection log. That is, a biometric security system, such as biometric security system 1502, 1602 may be configured to log all biometric samples submitted on fob 102 and/or RFID reader 104 and store the log information on databases on and/or communicating with system 1502, 1602. If a new and/or different biometric sample is submitted that differs from the log data, biometric security system 1502, 1602 may employ a security procedure such as deactivation, warning authorities, requesting a secondary scan, and/or any other security procedure.


Biometric security system 1502, 1602 and/or the biometric security system configured with system 100 may also be configured to obtain a plurality of biometric samples for verification and/or other security purposes. For example, after biometric security system 1502, receives a first biometric sample (e.g., scans one finger), it may be configured to receive a second biometric sample (e.g., scans a second finger). The first and second biometric samples may be compared with stored biometric samples by any of the methods disclosed herein. The second biometric sample may be the only sample compared with stored biometric samples if the first sample is unreadable or inadequate.


While the biometric safeguard mechanisms described herein use fingerprint scanning and retinal scanning for biometric sample verification for exemplification, any biometric sample may be submitted for verification, authorization and/or any other safeguard purpose. For example the present invention contemplates the use of voice recognition, facial and/or ear recognition, signature recognition, vascular patterns, DNA sampling, hand geometry, auditory emissions recognition, olfactory recognition, keystroke/typing recognition, iris scans, and/or any other biometric known in the art.


In yet another exemplary application of the present invention, fob 102 may be configured for use with global positioning technologies. For example, fob 102 may include any combination of positioning technology such as global position system (GPS), wireless assisted GPS, wireless assisted protocol (WAP) based location, geography markoff language (GML) based location, differential GPS, enhanced observed time difference (E-OTD), enhanced cell identification, and uplink time difference of arrival (U-TDOA) technologies. Fob 102 may be configured to communicate its positional information to one or more servers on network 136 and/or engine 130 to provide information based on the location of fob 102. For example, a user may be use a GPS-enabled fob 102 to determine the nearest location of a healthcare provider.


The preceding detailed description of exemplary embodiments of the invention makes reference to the accompanying drawings, which show the exemplary embodiment by way of illustration. While these exemplary embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, it should be understood that other embodiments may be realized and that logical and mechanical changes may be made without departing from the spirit and scope of the invention. For example, the steps recited in any of the method or process claims may be executed in any order and are not limited to the order presented. Further, the present invention may be practiced using one or more servers, as necessary. Thus, the preceding detailed description is presented for purposes of illustration only and not of limitation, and the scope of the invention is defined by the preceding description, and with respect to the attached claims.


Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as critical, required, or essential features or elements of any or all the claims. As used herein, the terms “comprises,” “comprising,” or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, no element described herein is required for the practice of the invention unless expressly described as “essential” or “critical.”

Claims
  • 1. A method comprising: receiving, at a Radio Frequency (RF) reader, a transaction request from an RF Transaction device configured to store a first data set associated with a first data set owner in a first data storage area on the RF transaction device;searching the RF transaction device to determine if at least one of the first data set or a second data set is available for use in connection with the transaction request;receiving an add request from the RF transaction device to add the second data set to the RF transaction device in response to the second data set not being available for use;allocating a second data storage area on the RF transaction device in response to the add request from the RF transaction device and in response to an issuer system indicating that the first data set is available for addition to the RF transaction device;receiving, at the RF reader, the second data set from a point of interaction terminal of the merchant system, wherein the second data set is inputted into the point of interaction terminal by a transaction device distinct from the RF transaction device;adding, by the RF reader, the second data set to the RF transaction device in the second data storage area, wherein the second data storage area is reserved for use by a second data set owner distinct from the first data set owner; andprocessing the transaction request in response to the adding the second data set.
  • 2. The method of claim 1, further comprising displaying a message on a user interface of the RF Identification (RFID) reader in response to the second data set not being available.
  • 3. The method of claim 1, further comprising storing a first transaction device account code in the first data storage area, and storing a second transaction device account code in the second data storage area.
  • 4. The method of claim 2, further comprising receiving the add request in response to the displaying the message on the RFID reader user interface.
  • 5. The method of claim 1, wherein at least one of the first data set or the second data set includes healthcare information to facilitate a healthcare transaction.
  • 6. The method of claim 1, further comprising enrolling the first data set owner and the second data set owner in multiple transaction accounts on the RF transaction device.
  • 7. The method of claim 1, wherein the processing the transaction request comprises processing the transaction request with a first account identifier stored in the first data set.
  • 8. The method of claim 1, wherein the processing the transaction request comprises processing the transaction request with a second account identifier stored in the second data set.
  • 9. The method of claim 5, wherein the healthcare information includes at least one of personal information, medical history, medical information, insurance information, and financial information.
  • 10. The method of claim 1, wherein the first data set includes multiple healthcare transaction accounts associated with a single healthcare account identifier.
  • 11. The method of claim 1, further comprising receiving the second data set from the issuer system.
  • 12. A non-transitory memory element having stored thereon a plurality of instructions for execution by a processor, the plurality of instructions comprising: instructions to receive, at a Radio Frequency identification (RFID) reader, a transaction request from an RF transaction device configured to store a first data set associated with a first data set owner in a first data storage area on the RF transaction device;instructions to search the RF transaction device to determine if at least one of the first data set or a second data set is available for use in connection with the transaction request;instructions to receive an add request from the RF transaction device to add the second data set to the RF transaction device in response to the second data set not being available for use;instructions to allocate a second data storage area on the RF transaction device in response to the add request from the RF transaction device and in response to an issuer system indicating that the first data set is available for addition to the RF transaction device;instructions to receive, at the RF reader, the second data set from a point of interaction terminal of the merchant system, wherein the second data set is inputted into the point of interaction terminal by a transaction device distinct from the RF transaction device;instructions to add, by the RF reader, the second data set to the RF transaction device in the second data storage area, wherein the second data storage area is reserved for use by a second data set owner distinct from the first data set owner; andinstructions to process the transaction request in response to the instructions to add the second data set.
  • 13. The method of claim 1, further comprising modifying the first data set without involving the second data set owner.
  • 14. The method of claim 1, wherein the transaction device includes at least one of a credit card, a debit card, and an insurance card.
  • 15. The method of claim 1, wherein the first data storage area is not accessible by the second data set owner, and wherein the second data storage area is not accessible by the first data set owner.
  • 16. The method of claim 1, further comprising instructing a control device on the RF transaction device to allocate the second data storage area on the RF transaction device.
CROSS-REFERENCE TO RELATED APPLICATIONS

This application (the “'964 application”) is a non-provisional of U.S. Provisional Application No. 60/512,297, filed Oct. 17, 2003, entitled “IMPROVED TRANSPONDER SYSTEM AND METHOD.” The '964 application is also a continuation-in-part U.S. patent application Ser. No. 10/340,352, filed Jan. 10, 2003, entitled “SYSTEM AND METHOD FOR INCENTING PAYMENT USING RADIO FREQUENCY IDENTIFICATION IN CONTACT AND CONTACTLESS TRANSACTIONS.” The '352 application is a non-provisional of U.S. Provisional Application No. 60/396,577 filed Jul. 16, 2002. The '352 application is also a continuation-in-part of U.S. patent application Ser. No. 10/192,488, entitled “SYSTEM AND METHOD FOR PAYMENT USING RADIO FREQUENCY IDENTIFICATION IN CONTACT AND CONTACTLESS TRANSACTIONS,” filed on Jul. 9, 2002, and now issued as U.S. Pat. No. 7,239,226 on Jul. 3, 2007. The '488 application is a non-provisional of U.S. Provisional Patent Application No. 60/304,216, filed Jul. 10, 2001. The '352 application is also a continuation-in-part of U.S. patent application Ser. No. 10/318,432, entitled “SYSTEM AND METHOD FOR SELECTING LOAD OPTIONS FOR USE IN RADIO FREQUENCY IDENTIFICATION IN CONTACT AND CONTACTLESS TRANSACTIONS,” filed Dec. 13, 2002[;] The '432 application is a non-provisional of U.S. Provisional Application No. 60/396,577, filed Jul. 16, 2002. The '352 application is also a continuation-in-part of U.S. patent application Ser. No. 10/318,480, entitled “SYSTEM AND METHOD FOR PAYMENT USING RADIO FREQUENCY IDENTIFICATION IN CONTACT AND CONTACTLESS TRANSACTIONS,” filed Dec. 13, 2002, and issued as U.S. Pat. No. 7,249,112 on Jul. 24, 2007. The '480 application is also a non-provisional of U.S. Provisional Patent Application No. 60/396,577, filed Jul. 16, 2002. All of the foregoing applications are incorporated herein by reference.

US Referenced Citations (1464)
Number Name Date Kind
D61466 Foltz Sep 1922 S
2767756 Niles Oct 1956 A
3376661 Hulett Apr 1968 A
3446260 Osher May 1969 A
3536894 Travioli Oct 1970 A
3573731 Schwend Apr 1971 A
3725647 Retzky Apr 1973 A
3763356 Berler Oct 1973 A
3829662 Furahashi Aug 1974 A
3838252 Hynes et al. Sep 1974 A
3873813 Lahr et al. Mar 1975 A
3894756 Ward Jul 1975 A
3914762 Klensch Oct 1975 A
3929177 Reis Dec 1975 A
3955295 Mayer May 1976 A
4044231 Beck et al. Aug 1977 A
4048737 McDermott Sep 1977 A
4056139 Murt Nov 1977 A
4058839 Darjany Nov 1977 A
4066873 Schatz Jan 1978 A
4119361 Greenaway Oct 1978 A
4202491 Suzuki May 1980 A
4206965 McGrew Jun 1980 A
4222516 Badet et al. Sep 1980 A
4277863 Faneuf Jul 1981 A
4303904 Chasek Dec 1981 A
4318554 Anderson et al. Mar 1982 A
4356646 Johnson, Jr. Nov 1982 A
4361757 Ehrat Nov 1982 A
D270303 Zautner Aug 1983 S
D270546 Malmberg Sep 1983 S
4421380 McGrew Dec 1983 A
4436991 Albert et al. Mar 1984 A
4443027 McNeely et al. Apr 1984 A
4450535 dePommery et al. May 1984 A
4453074 Weinstein Jun 1984 A
4475308 Heise et al. Oct 1984 A
4504084 Jauch Mar 1985 A
4507652 Vogt et al. Mar 1985 A
D280214 Opel Aug 1985 S
4538059 Rudland Aug 1985 A
4547002 Colgate, Jr. Oct 1985 A
4558211 Berstein Dec 1985 A
4563024 Blyth Jan 1986 A
4581523 Okuno Apr 1986 A
4582985 Lofberg Apr 1986 A
4583766 Wessel Apr 1986 A
4589686 McGrew May 1986 A
4593936 Opel Jun 1986 A
4597814 Colgate, Jr. Jul 1986 A
4639765 dHont Jan 1987 A
4641017 Lopata Feb 1987 A
4643452 Chang Feb 1987 A
4656463 Anders et al. Apr 1987 A
4663518 Borror et al. May 1987 A
4672021 Blumel et al. Jun 1987 A
4684795 Colgate, Jr. Aug 1987 A
4692394 Drexler Sep 1987 A
4694148 Diekemper et al. Sep 1987 A
4697073 Hara Sep 1987 A
4697363 Gamm Oct 1987 A
4700055 Kashkashian, Jr. Oct 1987 A
4711690 Haghiri-Tehrani Dec 1987 A
4717221 McGrew Jan 1988 A
4725719 Oncken et al. Feb 1988 A
4736094 Yoshida Apr 1988 A
4739328 Koelle et al. Apr 1988 A
4744497 O'Neal May 1988 A
4747147 Sparrow May 1988 A
4768811 Oshikoshi et al. Sep 1988 A
4779898 Berning et al. Oct 1988 A
4794142 Alberts et al. Dec 1988 A
4795894 Sugimoto et al. Jan 1989 A
4801790 Solo Jan 1989 A
4816653 Anderl et al. Mar 1989 A
4829690 Andros May 1989 A
4837422 Dethloff et al. Jun 1989 A
4839504 Nakano Jun 1989 A
4841570 Cooper Jun 1989 A
4849617 Ueda Jul 1989 A
4852911 Hoppe Aug 1989 A
4853525 Vogt et al. Aug 1989 A
4863819 Drexler et al. Sep 1989 A
4868849 Tamaoki Sep 1989 A
4884507 Levy Dec 1989 A
4889366 Fabbiani Dec 1989 A
4897533 Lyszczarz Jan 1990 A
4897947 Kass-Pious Feb 1990 A
4910521 Mellon Mar 1990 A
4917292 Drexler Apr 1990 A
4918432 Pauley et al. Apr 1990 A
D307979 Purvis May 1990 S
4937963 Barnes Jul 1990 A
D310386 Michels et al. Sep 1990 S
4961142 Elliott et al. Oct 1990 A
4984270 LaBounty Jan 1991 A
4993068 Piosenka et al. Feb 1991 A
4998753 Wichael Mar 1991 A
5004899 Ueda Apr 1991 A
5010243 Fukushima et al. Apr 1991 A
5015830 Masuzawa et al. May 1991 A
5016274 Micali et al. May 1991 A
5023782 Lutz et al. Jun 1991 A
5023908 Weiss Jun 1991 A
5025372 Burton et al. Jun 1991 A
5052328 Eppenbach Oct 1991 A
5053774 Schuermann et al. Oct 1991 A
5068894 Hoppe Nov 1991 A
5096228 Rinderknecht Mar 1992 A
5099226 Andrews Mar 1992 A
5101200 Swett Mar 1992 A
5106125 Antes Apr 1992 A
5111033 Fujita et al. May 1992 A
5125356 Galante Jun 1992 A
5142383 Mallik Aug 1992 A
5171039 Dusek Dec 1992 A
5175416 Mansvelt et al. Dec 1992 A
5180902 Schick et al. Jan 1993 A
5192947 Neustein Mar 1993 A
5193114 Moseley Mar 1993 A
5197140 Balmer Mar 1993 A
5198647 Mizuta Mar 1993 A
5202826 McCarthy Apr 1993 A
5206488 Teicher Apr 1993 A
5208110 Smith et al. May 1993 A
5212777 Gove et al. May 1993 A
5217844 Fukushima et al. Jun 1993 A
5221838 Gutman et al. Jun 1993 A
5222282 Sukonnik et al. Jun 1993 A
5226989 Sukonnik Jul 1993 A
5234624 Bauer et al. Aug 1993 A
5239654 IngSimmons et al. Aug 1993 A
5245329 Gokcebay Sep 1993 A
5247304 dHont Sep 1993 A
5251937 Ojster Oct 1993 A
5256473 Kotani et al. Oct 1993 A
5257656 McLeroy Nov 1993 A
5259649 Shomron Nov 1993 A
5272326 Fujita et al. Dec 1993 A
5274392 dHont et al. Dec 1993 A
5276311 Hennige Jan 1994 A
5279019 Knickle Jan 1994 A
5285100 Byatt Feb 1994 A
5288978 Iijima Feb 1994 A
5300764 Hoshino et al. Apr 1994 A
5304789 Lob et al. Apr 1994 A
5305002 Holodak et al. Apr 1994 A
5308121 Gunn May 1994 A
5311679 Birch, Sr. May 1994 A
5321751 Ray et al. Jun 1994 A
5326964 Risser Jul 1994 A
5329617 Asal Jul 1994 A
5331138 Saroya Jul 1994 A
5339447 Balmer Aug 1994 A
5349357 Schurmann et al. Sep 1994 A
5351052 D'Hont et al. Sep 1994 A
5351142 Cueli Sep 1994 A
5355411 MacDonald Oct 1994 A
5359522 Ryan Oct 1994 A
5365551 Snodgrass et al. Nov 1994 A
5371896 Gove et al. Dec 1994 A
5373303 dHont Dec 1994 A
5383687 Suess et al. Jan 1995 A
5397881 Mannik Mar 1995 A
5407893 Koshizuka et al. Apr 1995 A
5408243 dHont Apr 1995 A
5410142 Tsuboi et al. Apr 1995 A
5410649 Gove Apr 1995 A
5412192 Hoss May 1995 A
5428363 dHont Jun 1995 A
5438184 Roberts et al. Aug 1995 A
5453747 D'Hont et al. Sep 1995 A
5461217 Claus Oct 1995 A
5461219 Cronvall Oct 1995 A
5471592 Gove et al. Nov 1995 A
5477038 Levine et al. Dec 1995 A
5477040 Lalonde Dec 1995 A
5478629 Norman Dec 1995 A
5479494 Clitherow Dec 1995 A
5479530 Nair et al. Dec 1995 A
5485510 Colbert Jan 1996 A
5488376 Hurta et al. Jan 1996 A
5489411 Jha et al. Feb 1996 A
5489908 Orthmann et al. Feb 1996 A
5490079 Sharpe et al. Feb 1996 A
5491483 dHont Feb 1996 A
5491484 Schuermann Feb 1996 A
5491715 Flaxl Feb 1996 A
5493312 Knebelkamp Feb 1996 A
5497121 dHont Mar 1996 A
5500513 Langhans et al. Mar 1996 A
5500651 Schuermann Mar 1996 A
5503434 Gunn Apr 1996 A
5504808 Hamrick, Jr. Apr 1996 A
5506395 Eppley Apr 1996 A
5513272 Bogosian, Jr. Apr 1996 A
5513525 Schurmann May 1996 A
5514860 Berson May 1996 A
5516153 Kaule May 1996 A
5518810 Nishihara et al. May 1996 A
5519381 Marsh et al. May 1996 A
5520230 Sumner, III May 1996 A
5521966 Friedes et al. May 1996 A
5522083 Gove et al. May 1996 A
5525992 Froschermeier Jun 1996 A
5525994 Hurta et al. Jun 1996 A
5528222 Moskowitz et al. Jun 1996 A
5530232 Taylor Jun 1996 A
5533656 Bonaldi Jul 1996 A
5534857 Laing et al. Jul 1996 A
5537314 Kanter Jul 1996 A
5539825 Akiyama Jul 1996 A
5541582 Wagner et al. Jul 1996 A
5541604 Meier Jul 1996 A
5543798 Schuermann Aug 1996 A
5544246 Mandelbaum et al. Aug 1996 A
5548291 Meier et al. Aug 1996 A
5550536 Flaxl Aug 1996 A
5550548 Schuermann Aug 1996 A
5552789 Schuermann Sep 1996 A
5555877 Lockwood et al. Sep 1996 A
5557279 dHont Sep 1996 A
5557516 Hogan Sep 1996 A
5559504 Itsumi et al. Sep 1996 A
5559887 Davis et al. Sep 1996 A
5561430 Knebelkamp Oct 1996 A
5563582 dHont Oct 1996 A
5569187 Kaiser Oct 1996 A
5569897 Masuda Oct 1996 A
5572226 Tuttle Nov 1996 A
5572815 Kovner Nov 1996 A
5575094 Leake et al. Nov 1996 A
5577109 Stimson et al. Nov 1996 A
5577120 Penzias Nov 1996 A
5577121 Davis et al. Nov 1996 A
5577609 Hexter Nov 1996 A
5578808 Taylor Nov 1996 A
5581630 Bonneau, Jr. Dec 1996 A
5585787 Wallerstein Dec 1996 A
5590038 Pitroda Dec 1996 A
5590197 Chen et al. Dec 1996 A
5592150 dHont Jan 1997 A
5592405 Gove et al. Jan 1997 A
5592767 Treske Jan 1997 A
5594227 Deo Jan 1997 A
5594233 Kenneth et al. Jan 1997 A
5594448 dHont Jan 1997 A
5597534 Kaiser Jan 1997 A
5600175 Orthmann Feb 1997 A
5602538 Orthmann et al. Feb 1997 A
5602918 Chen et al. Feb 1997 A
5602919 Hurta et al. Feb 1997 A
5604342 Fujioka Feb 1997 A
5604801 Dolan et al. Feb 1997 A
5606520 Gove et al. Feb 1997 A
5606594 Register et al. Feb 1997 A
5607522 McDonnell Mar 1997 A
5608203 Finkelstein et al. Mar 1997 A
5608406 Eberth et al. Mar 1997 A
5608778 Partridge, III Mar 1997 A
5611965 Shouji et al. Mar 1997 A
5613001 Bakhoum Mar 1997 A
5613131 Moss et al. Mar 1997 A
5613146 Gove et al. Mar 1997 A
5614703 Martin et al. Mar 1997 A
5619207 dHont Apr 1997 A
5621199 Calari et al. Apr 1997 A
5621396 Flaxl Apr 1997 A
5621411 Hagl et al. Apr 1997 A
5621412 Sharpe et al. Apr 1997 A
5625366 dHont Apr 1997 A
5625370 dHont Apr 1997 A
5625695 MRaihi et al. Apr 1997 A
5629981 Nerlikar May 1997 A
5638080 Orthmann et al. Jun 1997 A
5640002 Ruppert et al. Jun 1997 A
5641050 Smith et al. Jun 1997 A
5646607 Schurmann et al. Jul 1997 A
5649118 Carlisle et al. Jul 1997 A
5657388 Weiss Aug 1997 A
5660319 Falcone et al. Aug 1997 A
5665439 Andersen et al. Sep 1997 A
5668876 Falk et al. Sep 1997 A
5673106 Thompson Sep 1997 A
D384971 Kawan Oct 1997 S
5675342 Sharpe Oct 1997 A
5677953 Dolphin Oct 1997 A
5686920 Hurta et al. Nov 1997 A
5689100 Carrithers Nov 1997 A
5691731 vanErven Nov 1997 A
5692132 Hogan Nov 1997 A
5694596 Campbell Dec 1997 A
5696913 Gove et al. Dec 1997 A
5697649 Dames et al. Dec 1997 A
5698837 Furuta Dec 1997 A
5699528 Hogan Dec 1997 A
5700037 Keller Dec 1997 A
5701127 Sharpe Dec 1997 A
5704046 Hogan Dec 1997 A
5705101 Oi et al. Jan 1998 A
5705798 Tarbox Jan 1998 A
5705852 Orihara et al. Jan 1998 A
5710421 Kokubu Jan 1998 A
5715399 Bezos Feb 1998 A
5720500 Okazaki et al. Feb 1998 A
5721781 Deo et al. Feb 1998 A
5724424 Gifford Mar 1998 A
5725098 Seifert et al. Mar 1998 A
5727140 Ohtomo et al. Mar 1998 A
5727696 Valiulis Mar 1998 A
5729053 Orthmann Mar 1998 A
5729236 Flaxl Mar 1998 A
5731957 Brennan Mar 1998 A
5732579 dHont et al. Mar 1998 A
5734838 Robinson et al. Mar 1998 A
5737439 Lapsley et al. Apr 1998 A
5739512 Tognazzini Apr 1998 A
5742756 Dillaway et al. Apr 1998 A
5742845 Wagner Apr 1998 A
5745571 Zuk Apr 1998 A
5748137 dHont May 1998 A
5748737 Daggar May 1998 A
5757917 Rose et al. May 1998 A
5758195 Balmer May 1998 A
5761306 Lewis Jun 1998 A
5761493 Blakeley et al. Jun 1998 A
5764789 Pare, Jr. et al. Jun 1998 A
5768385 Simon Jun 1998 A
5768609 Gove et al. Jun 1998 A
5769457 Warther Jun 1998 A
5770843 Rose et al. Jun 1998 A
5773812 Kreft Jun 1998 A
5774882 Keen et al. Jun 1998 A
5777903 Piosenka Jul 1998 A
5778067 Jones et al. Jul 1998 A
5778069 Thomlinson Jul 1998 A
5778173 Apte Jul 1998 A
5785680 Niezink et al. Jul 1998 A
5786587 Colgate, Jr. Jul 1998 A
5789733 Jachimowicz et al. Aug 1998 A
5791474 Hansen Aug 1998 A
5792337 Padovani et al. Aug 1998 A
5793324 Aslanidis et al. Aug 1998 A
5794095 Thompson Aug 1998 A
5796831 Paradinas et al. Aug 1998 A
5797060 Thompson Aug 1998 A
5797085 Buek et al. Aug 1998 A
5797133 Jones et al. Aug 1998 A
5798709 Flaxl Aug 1998 A
5799087 Rosen Aug 1998 A
5806045 Biorge et al. Sep 1998 A
5808758 Solmsdorf Sep 1998 A
5809142 Hurta et al. Sep 1998 A
5809288 Balmer Sep 1998 A
5809633 Mundigl et al. Sep 1998 A
5815252 Price-Francis Sep 1998 A
5815657 Williams et al. Sep 1998 A
5823359 Harris et al. Oct 1998 A
5825007 Jesadanont Oct 1998 A
5825302 Stafford Oct 1998 A
5826077 Blakeley et al. Oct 1998 A
5826241 Stein et al. Oct 1998 A
5826242 Montulli Oct 1998 A
5826243 Musmanno et al. Oct 1998 A
5828044 Jun et al. Oct 1998 A
5834756 Gutman et al. Nov 1998 A
5835894 Adcock et al. Nov 1998 A
5838257 Lambropoulos Nov 1998 A
5838720 Morelli Nov 1998 A
5838812 Pare, Jr. et al. Nov 1998 A
5841364 Hagl et al. Nov 1998 A
5842088 Thompson Nov 1998 A
5844218 Kawan et al. Dec 1998 A
5844230 Lalonde Dec 1998 A
5845267 Ronen Dec 1998 A
5851149 Xidos et al. Dec 1998 A
5852812 Reeder Dec 1998 A
5854891 Postlewaite et al. Dec 1998 A
5856048 Tahara et al. Jan 1999 A
5857079 Claus et al. Jan 1999 A
5857152 Everett Jan 1999 A
5857709 Chock Jan 1999 A
5858006 Van der AA et al. Jan 1999 A
5859419 Wynn Jan 1999 A
5859587 Alicot et al. Jan 1999 A
5859779 Giordano et al. Jan 1999 A
5862325 Reed et al. Jan 1999 A
5864306 Dwyer et al. Jan 1999 A
5864323 Berthon Jan 1999 A
5864830 Armetta et al. Jan 1999 A
5865470 Thompson Feb 1999 A
5867100 dHont Feb 1999 A
5869822 Meadows et al. Feb 1999 A
5870031 Kaiser et al. Feb 1999 A
5870915 dHont Feb 1999 A
5875432 Sehr Feb 1999 A
D406861 Leedy, Jr. Mar 1999 S
5878138 Yacobi Mar 1999 A
5878141 Daly et al. Mar 1999 A
5878215 Kling et al. Mar 1999 A
5878337 Joao et al. Mar 1999 A
5878403 DeFrancesco et al. Mar 1999 A
5880675 Trautner Mar 1999 A
5881272 Balmer Mar 1999 A
5883377 Chapin, Jr. Mar 1999 A
5883810 Franklin et al. Mar 1999 A
5884271 Pitroda Mar 1999 A
5884280 Yoshioka et al. Mar 1999 A
5884292 Baker et al. Mar 1999 A
5884310 Brichta et al. Mar 1999 A
5886333 Miyake Mar 1999 A
5887266 Heinonen et al. Mar 1999 A
5889941 Tushie et al. Mar 1999 A
5890137 Koreeda Mar 1999 A
D408054 Leedy, Jr. Apr 1999 S
5892211 Davis et al. Apr 1999 A
5897622 Blinn et al. Apr 1999 A
5898783 Rohrbach Apr 1999 A
5898838 Wagner Apr 1999 A
5900954 Katz et al. May 1999 A
5901239 Kamei May 1999 A
5903830 Joao et al. May 1999 A
5903875 Kohara May 1999 A
5903880 Biffar May 1999 A
5905798 Nerlikar et al. May 1999 A
5905908 Wagner May 1999 A
5907620 Klemba et al. May 1999 A
5909492 Payne et al. Jun 1999 A
5912446 Wong et al. Jun 1999 A
5912678 Saxena et al. Jun 1999 A
5913203 Wong et al. Jun 1999 A
5914472 Foladare et al. Jun 1999 A
5915016 Savalle et al. Jun 1999 A
5915023 Bernstein Jun 1999 A
5915973 Hoehn-Saric et al. Jun 1999 A
5917168 Nakamura et al. Jun 1999 A
5917913 Wang Jun 1999 A
5917925 Moore Jun 1999 A
5918216 Miksovsky et al. Jun 1999 A
5920058 Weber et al. Jul 1999 A
5920628 Indeck et al. Jul 1999 A
5920629 Rosen Jul 1999 A
5920847 Kolling et al. Jul 1999 A
5923734 Taskett Jul 1999 A
5923884 Peyret et al. Jul 1999 A
5924080 Johnson Jul 1999 A
5924624 Martin Jul 1999 A
5928788 Riedl Jul 1999 A
5929801 Aslanidis et al. Jul 1999 A
5930767 Reber et al. Jul 1999 A
5930777 Barber Jul 1999 A
5931917 Nguyen et al. Aug 1999 A
5932870 Berson Aug 1999 A
5933328 Wallace et al. Aug 1999 A
5933624 Balmer Aug 1999 A
5936226 Aucsmith Aug 1999 A
5936227 Truggelmann et al. Aug 1999 A
5938010 Osterbye Aug 1999 A
5942761 Tuli Aug 1999 A
5943624 Fox et al. Aug 1999 A
5945653 Walker et al. Aug 1999 A
5948116 Aslanidis et al. Sep 1999 A
5949044 Walker et al. Sep 1999 A
5949335 Maynard Sep 1999 A
5949876 Ginter et al. Sep 1999 A
5950174 Brendzel Sep 1999 A
5950179 Buchanan et al. Sep 1999 A
5953512 Cai et al. Sep 1999 A
5953710 Fleming Sep 1999 A
5955717 Vanstone Sep 1999 A
5955951 Wischerop et al. Sep 1999 A
5955969 dHont Sep 1999 A
5956024 Strickland et al. Sep 1999 A
5956693 Geerlings Sep 1999 A
5956699 Wong et al. Sep 1999 A
5958004 Helland et al. Sep 1999 A
5960411 Hartman et al. Sep 1999 A
5960416 Block Sep 1999 A
5963915 Kirsch Oct 1999 A
5963924 Williams et al. Oct 1999 A
5966697 Fergerson et al. Oct 1999 A
5968570 Paulucci Oct 1999 A
5969318 Mackenthun Oct 1999 A
5970148 Meier Oct 1999 A
5970470 Walker Oct 1999 A
5970471 Hill Oct 1999 A
5970472 Allsop et al. Oct 1999 A
5970473 Gerszberg et al. Oct 1999 A
5970475 Barnes et al. Oct 1999 A
5971276 Sano et al. Oct 1999 A
5973475 Combaluzier Oct 1999 A
5974238 Chase, Jr. Oct 1999 A
RE36365 Levine et al. Nov 1999 E
5978348 Tamura Nov 1999 A
5978840 Nguyen et al. Nov 1999 A
5979757 Tracy et al. Nov 1999 A
5979942 Ivicic Nov 1999 A
5982293 Everett et al. Nov 1999 A
5983200 Slotznick Nov 1999 A
5983207 Turk et al. Nov 1999 A
5983208 Haller Nov 1999 A
5984180 Albrecht Nov 1999 A
5987140 Rowney et al. Nov 1999 A
5987155 Dunn et al. Nov 1999 A
5987498 Athing et al. Nov 1999 A
5988497 Wallace Nov 1999 A
5988510 Tuttle Nov 1999 A
5989950 Wu Nov 1999 A
5991413 Arditti et al. Nov 1999 A
5991608 Leyten Nov 1999 A
5991748 Taskett Nov 1999 A
5991750 Watson Nov 1999 A
5995014 DiMaria Nov 1999 A
5996076 Rowney et al. Nov 1999 A
5999914 Blinn et al. Dec 1999 A
6000832 Franklin et al. Dec 1999 A
6002438 Hocevar et al. Dec 1999 A
6002767 Kramer Dec 1999 A
6003014 Lee et al. Dec 1999 A
6005942 Chan et al. Dec 1999 A
6006216 Griffin et al. Dec 1999 A
6006988 Behrmann et al. Dec 1999 A
6009412 Storey Dec 1999 A
6011487 Plocher Jan 2000 A
6012039 Hoffman et al. Jan 2000 A
6012049 Kawan Jan 2000 A
6012143 Tanaka Jan 2000 A
6012636 Smith Jan 2000 A
6014634 Scroggie et al. Jan 2000 A
6014635 Harris et al. Jan 2000 A
6014636 Reeder Jan 2000 A
6014645 Cunningham Jan 2000 A
6014646 Vallee et al. Jan 2000 A
6014648 Brennan Jan 2000 A
6014650 Zampese Jan 2000 A
6014748 Tushi et al. Jan 2000 A
6016476 Maes et al. Jan 2000 A
6016482 Molinari et al. Jan 2000 A
6016484 Williams et al. Jan 2000 A
6018717 Lee et al. Jan 2000 A
6018718 Walker et al. Jan 2000 A
RE36580 Bogosian, Jr. Feb 2000 E
6021943 Chastain Feb 2000 A
6023510 Epstein Feb 2000 A
6024286 Bradley et al. Feb 2000 A
6024385 Goda Feb 2000 A
6025283 Roberts Feb 2000 A
6027028 Pieterse et al. Feb 2000 A
6029147 Horadan et al. Feb 2000 A
6029149 Dykstra et al. Feb 2000 A
6029150 Kravitz Feb 2000 A
6029175 Chow Feb 2000 A
6029890 Austin Feb 2000 A
6029892 Miyake Feb 2000 A
6032136 Brake, Jr. et al. Feb 2000 A
6032866 Knighton et al. Mar 2000 A
6036100 Asami Mar 2000 A
6038292 Thomas Mar 2000 A
6038551 Barlow et al. Mar 2000 A
6038584 Balmer Mar 2000 A
6041308 Walker et al. Mar 2000 A
6041410 Hsu et al. Mar 2000 A
6041412 Timson et al. Mar 2000 A
6044360 Picciallo Mar 2000 A
6044388 DeBellis et al. Mar 2000 A
6047888 Dethloff Apr 2000 A
6050494 Song et al. Apr 2000 A
6050605 Mikelionis et al. Apr 2000 A
6052675 Checchio Apr 2000 A
6058418 Kobata May 2000 A
6060815 Nysen May 2000 A
6061344 Wood, Jr. May 2000 A
6061789 Hauser et al. May 2000 A
6064320 dHont et al. May 2000 A
6064751 Smithies et al. May 2000 A
6064981 Barni et al. May 2000 A
6065675 Teicher May 2000 A
6068184 Barnett May 2000 A
6068193 Kreft May 2000 A
6070003 Gove et al. May 2000 A
6070150 Remington et al. May 2000 A
6070154 Tavor et al. May 2000 A
6072870 Nguyen et al. Jun 2000 A
6073112 Geerlings Jun 2000 A
6073236 Kusakabe et al. Jun 2000 A
6073840 Marion Jun 2000 A
6076078 Camp et al. Jun 2000 A
6076296 Schaeffer Jun 2000 A
6078888 Johnson, Jr. Jun 2000 A
6078906 Huberman Jun 2000 A
6078908 Schmitz Jun 2000 A
6081790 Rosen Jun 2000 A
RE36788 Mansvelt et al. Jul 2000 E
6082422 Kaminski Jul 2000 A
6084967 Kennedy et al. Jul 2000 A
6085976 Sehr Jul 2000 A
6086971 Haas et al. Jul 2000 A
6088683 Jalili Jul 2000 A
6088686 Walker et al. Jul 2000 A
6088717 Reed et al. Jul 2000 A
6088755 Kobayashi et al. Jul 2000 A
6088797 Rosen Jul 2000 A
6089611 Blank Jul 2000 A
6091835 Smithies et al. Jul 2000 A
6092057 Zimmerman et al. Jul 2000 A
6092198 Lanzy et al. Jul 2000 A
6095413 Tetro et al. Aug 2000 A
6095567 Buell Aug 2000 A
6098053 Slater Aug 2000 A
6098879 Terranova Aug 2000 A
6099043 Story Aug 2000 A
6100804 Brady et al. Aug 2000 A
6101174 Langston Aug 2000 A
6101477 Hohle et al. Aug 2000 A
6102162 Teicher Aug 2000 A
6102672 Woollenweber Aug 2000 A
6104281 Heinrich et al. Aug 2000 A
6104311 Lastinger Aug 2000 A
6104922 Baumann Aug 2000 A
6105008 Davis et al. Aug 2000 A
6105013 Curry et al. Aug 2000 A
6105865 Hardesty Aug 2000 A
6107920 Eberhardt et al. Aug 2000 A
6108641 Kenna et al. Aug 2000 A
6109525 Blomqvist et al. Aug 2000 A
6112152 Tuttle Aug 2000 A
6112191 Burke Aug 2000 A
6112984 Snavely Sep 2000 A
6115040 Bladow et al. Sep 2000 A
6115360 Quay et al. Sep 2000 A
6115458 Taskett Sep 2000 A
6116423 Troxtell, Jr. et al. Sep 2000 A
6116505 Withrow Sep 2000 A
6116655 Thouin et al. Sep 2000 A
6116736 Stark et al. Sep 2000 A
6118189 Flaxl Sep 2000 A
6120461 Smyth Sep 2000 A
6121544 Petsinger Sep 2000 A
6122625 Rosen Sep 2000 A
6123223 Watkins Sep 2000 A
6125352 Franklin et al. Sep 2000 A
D432939 Hooglander Oct 2000 S
6128604 Sakamaki et al. Oct 2000 A
6129274 Suzuki Oct 2000 A
6130623 MacLellan et al. Oct 2000 A
6133834 Eberth et al. Oct 2000 A
6138913 Cyr et al. Oct 2000 A
6138917 Chapin, Jr. Oct 2000 A
6141651 Riley et al. Oct 2000 A
6141752 Dancs et al. Oct 2000 A
6144916 Wood et al. Nov 2000 A
6144948 Walker et al. Nov 2000 A
6148093 McConnell et al. Nov 2000 A
6148484 Andreae, Jr. Nov 2000 A
6154879 Pare et al. Nov 2000 A
6155168 Sakamoto Dec 2000 A
6157824 Bailey Dec 2000 A
6163771 Walker et al. Dec 2000 A
6167236 Kaiser et al. Dec 2000 A
6168083 Berger et al. Jan 2001 B1
6171138 Lefebvre et al. Jan 2001 B1
6173269 Solokl et al. Jan 2001 B1
6173272 Thomas et al. Jan 2001 B1
6173897 Halpern Jan 2001 B1
6173898 Mande Jan 2001 B1
6173899 Rozin Jan 2001 B1
6177859 Tuttle et al. Jan 2001 B1
6177860 Cromer et al. Jan 2001 B1
6179205 Sloan Jan 2001 B1
6179206 Matsumori Jan 2001 B1
6181287 Beigel Jan 2001 B1
6182895 Albrecht Feb 2001 B1
6184788 Middlemiss et al. Feb 2001 B1
6185307 Johnson, Jr. Feb 2001 B1
6188994 Egendorf Feb 2001 B1
6189779 Verdicchio et al. Feb 2001 B1
6189787 Dorf Feb 2001 B1
6192255 Lewis et al. Feb 2001 B1
6195006 Bowers et al. Feb 2001 B1
6196465 Awano Mar 2001 B1
6197396 Haas et al. Mar 2001 B1
6198728 Hulyalkar et al. Mar 2001 B1
6198762 Krasnov Mar 2001 B1
6198875 Edenson et al. Mar 2001 B1
6199079 Gupta et al. Mar 2001 B1
6199762 Hohle Mar 2001 B1
6200272 Linden Mar 2001 B1
6202927 Bashan et al. Mar 2001 B1
6205151 Quay et al. Mar 2001 B1
6206293 Gutman et al. Mar 2001 B1
6213390 Oneda Apr 2001 B1
6213391 Lewis Apr 2001 B1
6215437 Schurmann et al. Apr 2001 B1
6216219 Cai et al. Apr 2001 B1
6219439 Burger Apr 2001 B1
6220510 Everett et al. Apr 2001 B1
6222914 McMullin Apr 2001 B1
D442627 Webb et al. May 2001 S
D442629 Webb et al. May 2001 S
6223977 Hill May 2001 B1
6223984 Renner et al. May 2001 B1
6224109 Yang May 2001 B1
6226382 MRaihi et al. May 2001 B1
6227424 Roegner May 2001 B1
6227447 Campisano May 2001 B1
6230270 Laczko, Sr. May 2001 B1
6232917 Baumer et al. May 2001 B1
6233348 Fujii et al. May 2001 B1
6233683 Chan et al. May 2001 B1
6237848 Everett May 2001 B1
6239675 Flaxl May 2001 B1
6240187 Lewis May 2001 B1
6240989 Masoud Jun 2001 B1
6247030 Suzuki Jun 2001 B1
6248199 Smulson Jun 2001 B1
6248314 Nakashimada et al. Jun 2001 B1
6250554 Leo et al. Jun 2001 B1
6250557 Forslund et al. Jun 2001 B1
6255031 Yao et al. Jul 2001 B1
6257486 Teicher et al. Jul 2001 B1
6259769 Page Jul 2001 B1
6260026 Tomida et al. Jul 2001 B1
6260088 Gove et al. Jul 2001 B1
6263316 Khan et al. Jul 2001 B1
6263446 Kausik et al. Jul 2001 B1
6264106 Bridgelall Jul 2001 B1
6265977 Vega et al. Jul 2001 B1
6266754 Laczko, Sr. et al. Jul 2001 B1
6267292 Walker et al. Jul 2001 B1
6268788 Gray Jul 2001 B1
6269348 Pare, Jr. et al. Jul 2001 B1
6273335 Sloan Aug 2001 B1
6277232 Wang et al. Aug 2001 B1
6282522 Davis et al. Aug 2001 B1
D447515 Faenza, Jr. et al. Sep 2001 S
6286763 Reynolds et al. Sep 2001 B1
6289324 Kawan Sep 2001 B1
6290137 Kiekhaefer Sep 2001 B1
6293462 Gangi Sep 2001 B1
6295522 Boesch Sep 2001 B1
6296188 Kiekhaefer Oct 2001 B1
6297727 Nelson, Jr. Oct 2001 B1
6304223 Hilton et al. Oct 2001 B1
6307956 Black Oct 2001 B1
6309098 Wong Oct 2001 B1
6315193 Hogan Nov 2001 B1
6315195 Ramacchandran Nov 2001 B1
6315206 Hansen et al. Nov 2001 B1
6317721 Hurta et al. Nov 2001 B1
6317750 Tortolani et al. Nov 2001 B1
6317755 Rakers et al. Nov 2001 B1
6318636 Reynolds et al. Nov 2001 B1
6323566 Meier Nov 2001 B1
6325285 Baratelli Dec 2001 B1
6325293 Moreno Dec 2001 B1
6326934 Kinzie Dec 2001 B1
6327573 Walker et al. Dec 2001 B1
6327578 Linehan Dec 2001 B1
6329920 Morrison et al. Dec 2001 B1
6330544 Walker et al. Dec 2001 B1
6331972 Harris et al. Dec 2001 B1
6332134 Foster Dec 2001 B1
6332193 Glass et al. Dec 2001 B1
D453160 Pentz et al. Jan 2002 S
D453161 Pentz Jan 2002 S
6336095 Rosen Jan 2002 B1
6338048 Mori Jan 2002 B1
6339384 Valdes-Rodriguez Jan 2002 B1
6342844 Rozin Jan 2002 B1
D453337 Pentz et al. Feb 2002 S
D453338 Pentz et al. Feb 2002 S
D453516 Pentz Feb 2002 S
D454910 Smith et al. Mar 2002 S
6353420 Chung Mar 2002 B1
6353811 Weissman Mar 2002 B1
6360953 Lin et al. Mar 2002 B1
6364208 Stanford et al. Apr 2002 B1
6367011 Lee et al. Apr 2002 B1
6374245 Park Apr 2002 B1
6377034 Ivanov Apr 2002 B1
6378073 Davis et al. Apr 2002 B1
D457556 Hochschild May 2002 S
6386444 Sullivan May 2002 B1
6388533 Swoboda May 2002 B2
6390375 Kayanakis May 2002 B2
6400272 Holtzman et al. Jun 2002 B1
6402026 Schwier Jun 2002 B1
6402028 Graham, Jr. et al. Jun 2002 B1
6404341 Reid Jun 2002 B1
6406935 Kayanakis et al. Jun 2002 B2
6411611 Van der Tuijn Jun 2002 B1
D460455 Pentz Jul 2002 S
6415978 McAllister Jul 2002 B1
6419158 Hooglander Jul 2002 B2
6421650 Goetz et al. Jul 2002 B1
6422462 Cohen Jul 2002 B1
6422464 Terranova Jul 2002 B1
6422472 Thevenot et al. Jul 2002 B1
6424029 Giesler Jul 2002 B1
6424249 Houvener Jul 2002 B1
RE37822 Anthonyson Aug 2002 E
D461477 Pentz Aug 2002 S
6427910 Barnes et al. Aug 2002 B1
6434159 Woodward et al. Aug 2002 B1
6435415 Catte Aug 2002 B1
6438235 Sims, III Aug 2002 B2
6439455 Everett et al. Aug 2002 B1
6442532 Kawan Aug 2002 B1
D462965 Pentz Sep 2002 S
D462966 Pentz et al. Sep 2002 S
6445794 Shefi Sep 2002 B1
6446862 Mann Sep 2002 B1
6457000 Witkowski et al. Sep 2002 B1
6457996 Shih Oct 2002 B1
6460696 Meyer Oct 2002 B1
6466804 Pecen et al. Oct 2002 B1
6471127 Pentz et al. Oct 2002 B2
6473500 Risafi et al. Oct 2002 B1
6480100 Frieden et al. Nov 2002 B1
6480101 Kelly et al. Nov 2002 B1
6480825 Sharma et al. Nov 2002 B1
6480869 Fujioka Nov 2002 B1
6481621 Herrendoerfer et al. Nov 2002 B1
6481623 Grant et al. Nov 2002 B1
6481632 Wentker et al. Nov 2002 B2
6483427 Werb Nov 2002 B1
6483477 Plonka Nov 2002 B1
6483929 Murakami et al. Nov 2002 B1
6484937 Devaux et al. Nov 2002 B1
6490443 Freeny, Jr. Dec 2002 B1
6491229 Berney Dec 2002 B1
6491639 Turcott Dec 2002 B1
6494367 Zacharias Dec 2002 B1
6494380 Jarosz Dec 2002 B2
6496594 Prokoski Dec 2002 B1
6501832 Saylor et al. Dec 2002 B1
6505772 Mollett et al. Jan 2003 B1
6507662 Brooks Jan 2003 B1
6507762 Amro et al. Jan 2003 B1
6510983 Horowitz et al. Jan 2003 B2
6510998 Stanford et al. Jan 2003 B1
6513015 Ogasawara Jan 2003 B2
6519565 Clements et al. Feb 2003 B1
6520542 Thompson et al. Feb 2003 B2
6523292 Slavik Feb 2003 B2
6529880 McKeen et al. Mar 2003 B1
6535726 Johnson Mar 2003 B1
6539101 Black Mar 2003 B1
6546373 Cerra Apr 2003 B1
6547133 DeVries, Jr. et al. Apr 2003 B1
6549912 Chen Apr 2003 B1
D474234 Nelms et al. May 2003 S
6560581 Fox et al. May 2003 B1
6575361 Graves et al. Jun 2003 B1
6577229 Bonneau et al. Jun 2003 B1
6578768 Binder et al. Jun 2003 B1
6581839 Lasch et al. Jun 2003 B1
6587835 Treyz et al. Jul 2003 B1
6588660 Buescher et al. Jul 2003 B1
6588673 Chan et al. Jul 2003 B1
6589119 Orus et al. Jul 2003 B1
6591249 Zoka Jul 2003 B2
6598024 Walker et al. Jul 2003 B1
6601622 Young Aug 2003 B1
6601759 Fife et al. Aug 2003 B2
6601762 Pitrowski Aug 2003 B2
6608551 Anderson et al. Aug 2003 B1
6608995 Kawasaki et al. Aug 2003 B1
6609655 Harrell Aug 2003 B1
6609656 Elledge Aug 2003 B1
6609658 Sehr Aug 2003 B1
6623039 Thompson et al. Sep 2003 B2
6626356 Davenport et al. Sep 2003 B2
6628961 Ho et al. Sep 2003 B1
6629591 Griswold et al. Oct 2003 B1
6631849 Blossom Oct 2003 B2
6636620 Hoshino Oct 2003 B1
6636833 Flitcroft et al. Oct 2003 B1
6644551 Clayman et al. Nov 2003 B2
6650887 McGregor et al. Nov 2003 B2
6651168 Kao et al. Nov 2003 B1
6651813 Vallans et al. Nov 2003 B2
6651892 Hooglander Nov 2003 B2
6657614 Ito et al. Dec 2003 B1
6662166 Pare, Jr. et al. Dec 2003 B2
6665405 Lenstra Dec 2003 B1
6669086 Abdi et al. Dec 2003 B2
6671358 Seidman et al. Dec 2003 B1
6674786 Nakamura et al. Jan 2004 B1
6679427 Kuroiwa Jan 2004 B1
6681328 Harris et al. Jan 2004 B1
6681926 De Volpi Jan 2004 B2
6684269 Wagner Jan 2004 B2
6685089 Terranova et al. Feb 2004 B2
6686847 Mittler Feb 2004 B1
6687714 Kogen et al. Feb 2004 B1
6687875 Suzuki Feb 2004 B1
6690930 Dupre Feb 2004 B1
6693513 Tuttle Feb 2004 B2
6697947 Matyas, Jr. et al. Feb 2004 B1
6697971 Dwyer Feb 2004 B1
6703918 Kita Mar 2004 B1
6704039 Pena Mar 2004 B2
6704608 Azuma Mar 2004 B1
6705530 Kiekhaefer Mar 2004 B2
6708375 Johnson Mar 2004 B1
6711262 Watanen Mar 2004 B1
6725202 Hurta et al. Apr 2004 B1
6732919 Macklin et al. May 2004 B2
6732936 Kiekhaefer May 2004 B1
6735081 Bishop et al. May 2004 B1
6742120 Markakis et al. May 2004 B1
6747546 Hikita et al. Jun 2004 B1
6749123 Lasch et al. Jun 2004 B2
6751805 Austion Jun 2004 B1
6760581 Dutta Jul 2004 B2
6763500 Black et al. Jul 2004 B2
6764014 Lasch et al. Jul 2004 B2
6765470 Shinzaki Jul 2004 B2
6766952 Luu Jul 2004 B2
6769718 Warther et al. Aug 2004 B1
6771981 Zalewski et al. Aug 2004 B1
6786400 Bucci Sep 2004 B1
6789012 Childs et al. Sep 2004 B1
6789733 Terranova et al. Sep 2004 B2
6793141 Graham Sep 2004 B1
6799726 Stockhammer Oct 2004 B2
6816058 McGregor et al. Nov 2004 B2
6819219 Bolle et al. Nov 2004 B1
6823910 Elnekaveh Nov 2004 B1
6830193 Tanaka Dec 2004 B2
6834270 Pagani et al. Dec 2004 B1
6834795 Rasmussen et al. Dec 2004 B1
6842106 Hughes et al. Jan 2005 B2
6843415 Vogler Jan 2005 B2
6845863 Riley Jan 2005 B1
6851617 Saint et al. Feb 2005 B2
6853087 Neuhaus et al. Feb 2005 B2
6853894 Kolls Feb 2005 B1
6853987 Cook Feb 2005 B1
6857566 Wankmueller Feb 2005 B2
6859672 Roberts et al. Feb 2005 B2
6873974 Schutzer Mar 2005 B1
6877097 Hamid et al. Apr 2005 B2
6883715 Fruhauf et al. Apr 2005 B1
6895310 Kolls May 2005 B1
6898299 Brooks May 2005 B1
H2120 Cudlitz Jul 2005 H
6914517 Kinsella Jul 2005 B2
6915277 Manchester et al. Jul 2005 B1
6920560 Wallace Jul 2005 B2
6924729 Aschauer et al. Aug 2005 B1
6925439 Pitroda Aug 2005 B1
6925565 Black Aug 2005 B2
6928181 Brooks Aug 2005 B2
6931538 Sawaguchi Aug 2005 B1
6934861 Haala Aug 2005 B2
D509243 Hunter, Jr. et al. Sep 2005 S
6940461 Nantz et al. Sep 2005 B2
6944402 Baker et al. Sep 2005 B1
6944768 Siegel et al. Sep 2005 B2
6959874 Bardwell Nov 2005 B2
6961448 Nichols et al. Nov 2005 B2
6970583 Black Nov 2005 B2
6978369 Wheeler et al. Dec 2005 B2
6978933 Yap et al. Dec 2005 B2
6986099 Todd Jan 2006 B2
6990480 Burt Jan 2006 B1
6994262 Warther Feb 2006 B1
7003497 Maes Feb 2006 B2
7003501 Ostroff Feb 2006 B2
7004385 Douglass Feb 2006 B1
7006993 Cheong et al. Feb 2006 B1
7049962 Atherton et al. May 2006 B2
7051925 Schwarz, Jr. May 2006 B2
7059159 Lanigan et al. Jun 2006 B2
7068148 Shanks et al. Jun 2006 B2
7069444 Lowensohn et al. Jun 2006 B2
7070112 Beenau et al. Jul 2006 B2
7093767 Faenza et al. Aug 2006 B2
7096204 Chen et al. Aug 2006 B1
7096494 Chen Aug 2006 B1
7100821 Rasti Sep 2006 B2
7102523 Shanks et al. Sep 2006 B2
7103575 Linehan Sep 2006 B1
7108190 Burgan et al. Sep 2006 B2
7119659 Bonalle et al. Oct 2006 B2
7127672 Patterson et al. Oct 2006 B1
7131574 Sciupac et al. Nov 2006 B1
7132946 Waldner et al. Nov 2006 B2
7136835 Flitcroft et al. Nov 2006 B1
7150407 Berger et al. Dec 2006 B1
7154375 Beenau et al. Dec 2006 B2
7171662 Misara et al. Jan 2007 B1
7172112 Bonalle et al. Feb 2007 B2
7184747 Bogat Feb 2007 B2
7213748 Tsuei et al. May 2007 B2
7237121 Cammack et al. Jun 2007 B2
7239226 Berardi et al. Jul 2007 B2
7254557 Gillin et al. Aug 2007 B1
7281135 Black Oct 2007 B2
7287271 Riggins Oct 2007 B1
7287695 Wankmueller Oct 2007 B2
7299364 Noble et al. Nov 2007 B2
7303120 Beenau et al. Dec 2007 B2
7314164 Bonalle et al. Jan 2008 B2
7314165 Bonalle et al. Jan 2008 B2
7318550 Bonalle et al. Jan 2008 B2
7325724 Bonalle et al. Feb 2008 B2
7341181 Bonalle et al. Mar 2008 B2
7363504 Bonalle et al. Apr 2008 B2
7363505 Black Apr 2008 B2
7419093 Blackson et al. Sep 2008 B1
20010003071 Mansutti et al. Jun 2001 A1
20010013542 Horowitz et al. Aug 2001 A1
20010013546 Ross Aug 2001 A1
20010013551 Ramachandran Aug 2001 A1
20010017584 Shinzaki Aug 2001 A1
20010018660 Sehr Aug 2001 A1
20010022446 Klure Sep 2001 A1
20010024157 Hansmann et al. Sep 2001 A1
20010029493 Pare et al. Oct 2001 A1
20010030238 Arisawa Oct 2001 A1
20010032192 Putta et al. Oct 2001 A1
20010034565 Leatherman Oct 2001 A1
20010034623 Chung Oct 2001 A1
20010034720 Armes et al. Oct 2001 A1
20010036301 Yamaguchi et al. Nov 2001 A1
20010036835 Leedom, Jr. Nov 2001 A1
20010039617 Buhrlen et al. Nov 2001 A1
20010040507 Eckstein et al. Nov 2001 A1
20010045469 Hooglander Nov 2001 A1
20010049628 Icho Dec 2001 A1
20010053239 Takhar Dec 2001 A1
20010055411 Black Dec 2001 A1
20020002468 Spagna et al. Jan 2002 A1
20020005774 Rudolph et al. Jan 2002 A1
20020011519 Shults Jan 2002 A1
20020014529 Tanaka Feb 2002 A1
20020014952 Terranova Feb 2002 A1
20020016687 Felsenstein et al. Feb 2002 A1
20020019807 Halpern Feb 2002 A1
20020024590 Pena Feb 2002 A1
20020026419 Maritzen et al. Feb 2002 A1
20020026575 Wheeler et al. Feb 2002 A1
20020028704 Bloomfield et al. Mar 2002 A1
20020030579 Albert et al. Mar 2002 A1
20020030581 Janiak et al. Mar 2002 A1
20020035548 Hogan et al. Mar 2002 A1
20020036237 Atherton et al. Mar 2002 A1
20020038818 Zingher et al. Apr 2002 A1
20020040935 Weyant Apr 2002 A1
20020040936 Wentker et al. Apr 2002 A1
20020041093 Cox et al. Apr 2002 A1
20020042782 Albazz et al. Apr 2002 A1
20020043566 Goodman et al. Apr 2002 A1
20020046341 Kazaks et al. Apr 2002 A1
20020052839 Takatori May 2002 A1
20020062249 Iannacci May 2002 A1
20020062284 Kawan May 2002 A1
20020062291 Zoka May 2002 A1
20020066784 Segal et al. Jun 2002 A1
20020072349 Geiselman et al. Jun 2002 A1
20020073025 Tanner et al. Jun 2002 A1
20020074398 Lancos et al. Jun 2002 A1
20020077837 Krueger et al. Jun 2002 A1
20020077895 Howell Jun 2002 A1
20020077992 Tobin Jun 2002 A1
20020079367 Montani Jun 2002 A1
20020083320 Vatanen Jun 2002 A1
20020087869 Kim Jul 2002 A1
20020090117 Kramer Jul 2002 A1
20020092914 Pentz et al. Jul 2002 A1
20020095298 Ewing Jul 2002 A1
20020095343 Barton et al. Jul 2002 A1
20020095389 Gaines Jul 2002 A1
20020095587 Doyle et al. Jul 2002 A1
20020095588 Shigematsu et al. Jul 2002 A1
20020097142 Janiak et al. Jul 2002 A1
20020097144 Collins et al. Jul 2002 A1
20020099665 Burger et al. Jul 2002 A1
20020107007 Gerson Aug 2002 A1
20020107742 Magill Aug 2002 A1
20020107791 Nobrega et al. Aug 2002 A1
20020108062 Nakajima et al. Aug 2002 A1
20020109580 Shreve et al. Aug 2002 A1
20020111210 Luciano, Jr. et al. Aug 2002 A1
20020111917 Hoffman et al. Aug 2002 A1
20020111919 Weller et al. Aug 2002 A1
20020112177 Voltmer et al. Aug 2002 A1
20020113082 Leatherman et al. Aug 2002 A1
20020116274 Hind et al. Aug 2002 A1
20020120584 Hogan et al. Aug 2002 A1
20020125164 Bassinson Sep 2002 A1
20020126010 Trimble et al. Sep 2002 A1
20020128977 Nambiar et al. Sep 2002 A1
20020129248 Wheeler et al. Sep 2002 A1
20020130186 Lasch et al. Sep 2002 A1
20020130187 Berg et al. Sep 2002 A1
20020131567 Maginas Sep 2002 A1
20020133467 Hobson et al. Sep 2002 A1
20020133725 Roy et al. Sep 2002 A1
20020138351 Houvener et al. Sep 2002 A1
20020138425 Shimizu et al. Sep 2002 A1
20020138438 Bardwell Sep 2002 A1
20020139839 Catan Oct 2002 A1
20020140542 Prokoski et al. Oct 2002 A1
20020145043 Challa et al. Oct 2002 A1
20020147002 Trop et al. Oct 2002 A1
20020147600 Waters et al. Oct 2002 A1
20020147913 Lun Yip Oct 2002 A1
20020148892 Bardwell Oct 2002 A1
20020149467 Calvesio et al. Oct 2002 A1
20020152123 Giordano et al. Oct 2002 A1
20020153410 Santini Oct 2002 A1
20020153424 Li Oct 2002 A1
20020154795 Lee et al. Oct 2002 A1
20020158747 McGregor et al. Oct 2002 A1
20020163421 Wang et al. Nov 2002 A1
20020165931 Greer et al. Nov 2002 A1
20020166891 Stoutenburg et al. Nov 2002 A1
20020166897 Hooglander Nov 2002 A1
20020169673 Prorock et al. Nov 2002 A1
20020174067 Hoffman et al. Nov 2002 A1
20020175805 Armstrong et al. Nov 2002 A9
20020176522 Fan Nov 2002 A1
20020178063 Gravelle et al. Nov 2002 A1
20020178124 Lewis Nov 2002 A1
20020178369 Black Nov 2002 A1
20020179704 Deaton Dec 2002 A1
20020185543 Pentz et al. Dec 2002 A1
20020186133 Loof Dec 2002 A1
20020186838 Brandys Dec 2002 A1
20020188501 Lefkowith Dec 2002 A1
20020188854 Heaven et al. Dec 2002 A1
20020188855 Nakayama et al. Dec 2002 A1
20020190124 Piotrowski Dec 2002 A1
20020190125 Stockhammer Dec 2002 A1
20020191816 Maritzen et al. Dec 2002 A1
20020192856 Halope et al. Dec 2002 A1
20020193102 Hyyppa et al. Dec 2002 A1
20020194137 Park et al. Dec 2002 A1
20020194303 Suila et al. Dec 2002 A1
20020194503 Faith et al. Dec 2002 A1
20020196963 Bardwell Dec 2002 A1
20030001006 Lee Jan 2003 A1
20030001459 Scott Jan 2003 A1
20030001755 Tiernay et al. Jan 2003 A1
20030004866 Huennekens et al. Jan 2003 A1
20030004881 Shinzaki et al. Jan 2003 A1
20030005310 Shinzaki Jan 2003 A1
20030006901 Kim et al. Jan 2003 A1
20030009382 Arbeloff et al. Jan 2003 A1
20030014307 Heng Jan 2003 A1
20030014357 Chrisekos et al. Jan 2003 A1
20030014891 Nelms et al. Jan 2003 A1
20030018532 Dudek et al. Jan 2003 A1
20030018567 Flitcroft et al. Jan 2003 A1
20030018893 Hess Jan 2003 A1
20030025600 Blanchard Feb 2003 A1
20030028481 Flitcroft et al. Feb 2003 A1
20030033697 Hicks et al. Feb 2003 A1
20030037264 Ezaki et al. Feb 2003 A1
20030037851 Hogganvik Feb 2003 A1
20030046228 Berney Mar 2003 A1
20030046237 Uberti Mar 2003 A1
20030046540 Nakamura et al. Mar 2003 A1
20030047482 Jones et al. Mar 2003 A1
20030054836 Michot Mar 2003 A1
20030055727 Walker et al. Mar 2003 A1
20030057226 Long Mar 2003 A1
20030057278 Wong Mar 2003 A1
20030061172 Robinson Mar 2003 A1
20030069828 Blazey et al. Apr 2003 A1
20030069846 Marcon Apr 2003 A1
20030074317 Hofi Apr 2003 A1
20030086591 Simon May 2003 A1
20030093187 Walker May 2003 A1
20030097344 Chaum et al. May 2003 A1
20030106935 Burchette, Jr. Jun 2003 A1
20030112120 K. Jun 2003 A1
20030112972 Hattick et al. Jun 2003 A1
20030115126 Pitroda Jun 2003 A1
20030120554 Hogan et al. Jun 2003 A1
20030120626 Piotrowski Jun 2003 A1
20030121969 Wankmueller Jul 2003 A1
20030122120 Brazis et al. Jul 2003 A1
20030123714 O'Gorman et al. Jul 2003 A1
20030124294 Hodson et al. Jul 2003 A1
20030125054 Garcia Jul 2003 A1
20030130820 Lane, III Jul 2003 A1
20030132132 Small Jul 2003 A1
20030132284 Reynolds et al. Jul 2003 A1
20030132297 McCall et al. Jul 2003 A1
20030140228 Binder Jul 2003 A1
20030149661 Mitchell et al. Aug 2003 A1
20030149662 Shore Aug 2003 A1
20030150911 Joseph Aug 2003 A1
20030152252 Kondo et al. Aug 2003 A1
20030153356 Liu Aug 2003 A1
20030155416 Macklin et al. Aug 2003 A1
20030159044 Doyle et al. Aug 2003 A1
20030160074 Pineda Aug 2003 A1
20030163699 Pailles et al. Aug 2003 A1
20030167207 Berardi et al. Sep 2003 A1
20030173408 Mosher, Jr. et al. Sep 2003 A1
20030177102 Robinson Sep 2003 A1
20030177347 Schneier et al. Sep 2003 A1
20030178495 Jones et al. Sep 2003 A1
20030183689 Swift et al. Oct 2003 A1
20030183695 Labrec et al. Oct 2003 A1
20030183699 Masui Oct 2003 A1
20030187786 Swift et al. Oct 2003 A1
20030187787 Freund Oct 2003 A1
20030187790 Swift et al. Oct 2003 A1
20030187796 Swift et al. Oct 2003 A1
20030191949 Odagawa Oct 2003 A1
20030195037 Vuong et al. Oct 2003 A1
20030195842 Reece Oct 2003 A1
20030195843 Matsuda et al. Oct 2003 A1
20030197593 Siegel et al. Oct 2003 A1
20030200184 Dominguez et al. Oct 2003 A1
20030208439 Rast Nov 2003 A1
20030218066 Fernandes et al. Nov 2003 A1
20030220876 Burger et al. Nov 2003 A1
20030222153 Pentz et al. Dec 2003 A1
20030223625 Hillhouse et al. Dec 2003 A1
20030225623 Wankmueller Dec 2003 A1
20030225713 Atkinson et al. Dec 2003 A1
20030226041 Palmer et al. Dec 2003 A1
20030227550 Manico et al. Dec 2003 A1
20030229793 McCall et al. Dec 2003 A1
20030230514 Baker Dec 2003 A1
20030233334 Smith Dec 2003 A1
20030236704 Antonucci Dec 2003 A1
20040006497 Nestor et al. Jan 2004 A1
20040006539 Royer et al. Jan 2004 A1
20040010462 Moon et al. Jan 2004 A1
20040011877 Reppermund Jan 2004 A1
20040014457 Stevens Jan 2004 A1
20040015451 Sahota et al. Jan 2004 A1
20040016796 Hanna et al. Jan 2004 A1
20040017934 Kocher Jan 2004 A1
20040019494 Ridgeway et al. Jan 2004 A1
20040019564 Goldthwaite et al. Jan 2004 A1
20040020982 Hoffman et al. Feb 2004 A1
20040021552 Koo Feb 2004 A1
20040024694 Lawrence et al. Feb 2004 A1
20040026518 Kudo et al. Feb 2004 A1
20040029569 Khan et al. Feb 2004 A1
20040030601 Pond et al. Feb 2004 A1
20040031856 Atsmon et al. Feb 2004 A1
20040039814 Crabtree et al. Feb 2004 A1
20040039860 Mills et al. Feb 2004 A1
20040041021 Nugent, Jr. Mar 2004 A1
20040041690 Yamagishi Mar 2004 A1
20040044627 Russell et al. Mar 2004 A1
20040046034 Ey Yamani et al. Mar 2004 A1
20040049687 Orsini Mar 2004 A1
20040050930 Rowe Mar 2004 A1
20040052406 Brooks Mar 2004 A1
20040059923 ShamRao Mar 2004 A1
20040061593 Lane Apr 2004 A1
20040062423 Doi Apr 2004 A1
20040073792 Noble et al. Apr 2004 A1
20040083184 Tsuei et al. Apr 2004 A1
20040083380 Janke Apr 2004 A1
20040084524 Ramachandran May 2004 A1
20040089724 Lasch et al. May 2004 A1
20040098336 Flink May 2004 A1
20040104266 Bolle et al. Jun 2004 A1
20040104268 Bailey Jun 2004 A1
20040118930 Berardi et al. Jun 2004 A1
20040124104 DeVolpi Jul 2004 A1
20040124246 Allen et al. Jul 2004 A1
20040127256 Goldthwaite et al. Jul 2004 A1
20040129787 Saito et al. Jul 2004 A1
20040131237 Machida Jul 2004 A1
20040133787 Doughty et al. Jul 2004 A1
20040136573 Sato Jul 2004 A1
20040139021 Reed et al. Jul 2004 A1
20040144841 Tsukamoto et al. Jul 2004 A1
20040144846 Lasch et al. Jul 2004 A1
20040149820 Zuili Aug 2004 A1
20040155101 Royer et al. Aug 2004 A1
20040158723 Root Aug 2004 A1
20040160310 Chen et al. Aug 2004 A1
20040161135 Sano et al. Aug 2004 A1
20040165753 Takhiri et al. Aug 2004 A1
20040169071 Burgan et al. Sep 2004 A1
20040172541 Ando et al. Sep 2004 A1
20040176071 Gehrmann et al. Sep 2004 A1
20040177045 Brown Sep 2004 A1
20040180657 Yaqub et al. Sep 2004 A1
20040188519 Cassone Sep 2004 A1
20040190757 Murphy et al. Sep 2004 A1
20040193676 Marks Sep 2004 A1
20040195314 Lee Oct 2004 A1
20040199469 Barillova et al. Oct 2004 A1
20040202354 Togino Oct 2004 A1
20040208343 Golden et al. Oct 2004 A1
20040215575 Garrity Oct 2004 A1
20040222803 Tartagni Nov 2004 A1
20040230488 Beenau et al. Nov 2004 A1
20040232220 Beenau et al. Nov 2004 A1
20040232224 Beenau et al. Nov 2004 A1
20040233039 Beenau et al. Nov 2004 A1
20040235450 Rosenberg Nov 2004 A1
20040236680 Luoffo et al. Nov 2004 A1
20040236699 Beenau et al. Nov 2004 A1
20040236700 Beenau et al. Nov 2004 A1
20040236701 Beenau et al. Nov 2004 A1
20040236819 Anati et al. Nov 2004 A1
20040239480 Beenau et al. Dec 2004 A1
20040240711 Hamza et al. Dec 2004 A1
20040255168 Murashita et al. Dec 2004 A1
20040257196 Kotzin Dec 2004 A1
20040258282 Bjorn et al. Dec 2004 A1
20050001711 Doughty et al. Jan 2005 A1
20050004921 Beenau et al. Jan 2005 A1
20050005172 Haala Jan 2005 A1
20050011776 Nagel Jan 2005 A1
20050017068 Zalewski et al. Jan 2005 A1
20050018658 Ikeda et al. Jan 2005 A1
20050020304 Shinzaki Jan 2005 A1
20050021457 Johnson et al. Jan 2005 A1
20050023157 Logan Feb 2005 A1
20050033686 Peart et al. Feb 2005 A1
20050033687 Beenau et al. Feb 2005 A1
20050033689 Bonalle et al. Feb 2005 A1
20050033992 Inabe Feb 2005 A1
20050035192 Bonalle et al. Feb 2005 A1
20050035847 Bonalle et al. Feb 2005 A1
20050036665 Higuchi Feb 2005 A1
20050038718 Barnes et al. Feb 2005 A1
20050040221 Schwarz, Jr. Feb 2005 A1
20050040272 Argumedo et al. Feb 2005 A1
20050045718 Bortolin et al. Mar 2005 A1
20050050367 Burger et al. Mar 2005 A1
20050054438 Rothschild et al. Mar 2005 A1
20050058262 Timmins et al. Mar 2005 A1
20050060233 Bonalle et al. Mar 2005 A1
20050065842 Summers Mar 2005 A1
20050065872 Moebs et al. Mar 2005 A1
20050071231 Beenau et al. Mar 2005 A1
20050087597 Gotfried et al. Apr 2005 A1
20050091325 Kuwana et al. Apr 2005 A1
20050097038 Yu et al. May 2005 A1
20050098621 deSylva May 2005 A1
20050100199 Boshra May 2005 A1
20050102524 Haala May 2005 A1
20050103839 Hewel May 2005 A1
20050109836 Ben-Aissa May 2005 A1
20050113137 Rodriguez et al. May 2005 A1
20050116024 Beenau et al. Jun 2005 A1
20050119978 Ates Jun 2005 A1
20050121512 Wankmueller Jun 2005 A1
20050122209 Black Jun 2005 A1
20050123137 McCallum Jun 2005 A1
20050125312 Dearing et al. Jun 2005 A1
20050125317 Winkelman, III et al. Jun 2005 A1
20050125343 Mendelovich Jun 2005 A1
20050127164 Wankmueller Jun 2005 A1
20050137977 Wankmueller Jun 2005 A1
20050139669 Arnouse Jun 2005 A1
20050144133 Hoffman et al. Jun 2005 A1
20050149358 Sacco et al. Jul 2005 A1
20050149926 Saltz Jul 2005 A1
20050160271 Brundage et al. Jul 2005 A9
20050160790 Tanaka et al. Jul 2005 A1
20050165684 Jensen et al. Jul 2005 A1
20050166062 Sanchez-Cifuentes Jul 2005 A1
20050169504 Black Aug 2005 A1
20050171787 Zagami Aug 2005 A1
20050171905 Wankmueller Aug 2005 A1
20050180618 Black Aug 2005 A1
20050187883 Bishop et al. Aug 2005 A1
20050187916 Levin et al. Aug 2005 A1
20050197923 Kilner et al. Sep 2005 A1
20050203857 Friedman Sep 2005 A1
20050207002 Liu et al. Sep 2005 A1
20050211784 Justin Sep 2005 A1
20050212657 Simon Sep 2005 A1
20050216424 Gandre et al. Sep 2005 A1
20050221853 Silvester Oct 2005 A1
20050223230 Zick Oct 2005 A1
20050232471 Baer Oct 2005 A1
20050240778 Saito Oct 2005 A1
20050246292 Sarcanin Nov 2005 A1
20050251688 Nanavati et al. Nov 2005 A1
20050261972 Black Nov 2005 A1
20050275505 Himmelstein Dec 2005 A1
20050278222 Northrup Dec 2005 A1
20060000892 Bonalle et al. Jan 2006 A1
20060000893 Bonalle et al. Jan 2006 A1
20060000894 Bonalle et al. Jan 2006 A1
20060000895 Bonalle et al. Jan 2006 A1
20060000896 Bonalle et al. Jan 2006 A1
20060000897 Bonalle et al. Jan 2006 A1
20060000898 Bonalle et al. Jan 2006 A1
20060000899 Bonalle et al. Jan 2006 A1
20060005022 Wakamori et al. Jan 2006 A1
20060005042 Black Jan 2006 A1
20060016868 Bonalle et al. Jan 2006 A1
20060016869 Bonalle et al. Jan 2006 A1
20060016871 Bonalle et al. Jan 2006 A1
20060016874 Bonalle et al. Jan 2006 A1
20060016875 Bonalle et al. Jan 2006 A1
20060016877 Bonalle et al. Jan 2006 A1
20060033609 Bridgelall Feb 2006 A1
20060034492 Siegel et al. Feb 2006 A1
20060066444 Steeves Mar 2006 A1
20060069635 Ram et al. Mar 2006 A1
20060071756 Steeves Apr 2006 A1
20060077034 Hillier Apr 2006 A1
20060080552 Lauper Apr 2006 A1
20060095369 Hofi May 2006 A1
20060104485 Miller et al. May 2006 A1
20060123240 Chaiken Jun 2006 A1
20060136336 Drummond et al. Jun 2006 A1
20060156395 Fontaine Jul 2006 A1
20060158434 Zank et al. Jul 2006 A1
20060173291 Glossop Aug 2006 A1
20060173791 Mann et al. Aug 2006 A1
20060177061 Orsini et al. Aug 2006 A1
20060178937 Rau et al. Aug 2006 A1
20060190419 Bunn et al. Aug 2006 A1
20060202835 Thibault Sep 2006 A1
20060208066 Finn et al. Sep 2006 A1
20060213986 Register et al. Sep 2006 A1
20060229988 Oshima et al. Oct 2006 A1
20060237528 Bishop et al. Oct 2006 A1
20060242423 Kussmaul Oct 2006 A1
20060278723 Dan et al. Dec 2006 A1
20070008131 Doan et al. Jan 2007 A1
20070046468 Davis Mar 2007 A1
20070057797 Waldner et al. Mar 2007 A1
20070075841 Maltsev et al. Apr 2007 A1
20070112957 Shastri et al. May 2007 A1
20070119924 Register et al. May 2007 A1
20070241861 Venkatanna et al. Oct 2007 A1
20070252001 Kail et al. Nov 2007 A1
20070252010 Gonzalez et al. Nov 2007 A1
20070284432 Abouyounes Dec 2007 A1
20070296544 Beenau et al. Dec 2007 A1
20070296551 Beenau et al. Dec 2007 A1
20070299782 Beenau et al. Dec 2007 A1
20070299783 Beenau et al. Dec 2007 A1
20080006691 Bonalle et al. Jan 2008 A1
20080008359 Beenau et al. Jan 2008 A1
20080008363 Bonalle et al. Jan 2008 A1
20080010214 Bonalle et al. Jan 2008 A1
20080011830 Bonalle et al. Jan 2008 A1
20080011831 Bonalle et al. Jan 2008 A1
20080013796 Bonalle et al. Jan 2008 A1
20080013807 Bonalle et al. Jan 2008 A1
20080015941 Beenau et al. Jan 2008 A1
20080015992 Bonalle et al. Jan 2008 A1
20080015993 Bonalle et al. Jan 2008 A1
20080015994 Bonalle et al. Jan 2008 A1
20080016002 Beenau et al. Jan 2008 A1
20080033722 Beenau et al. Feb 2008 A1
20080067242 Bonalle et al. Mar 2008 A1
20080072065 Bonalle et al. Mar 2008 A1
Foreign Referenced Citations (139)
Number Date Country
689070 Aug 1998 CH
689680 Aug 1999 CH
2847756 May 1980 DE
29702538 Apr 1997 DE
0181770 May 1986 EP
0343829 Nov 1989 EP
0354817 Feb 1990 EP
0 358 525 Mar 1990 EP
0368570 May 1990 EP
0388090 Sep 1990 EP
0 424 726 Oct 1990 EP
0403134 Dec 1990 EP
0411602 Feb 1991 EP
0473998 Mar 1992 EP
0481388 Apr 1992 EP
0531605 Mar 1993 EP
0552047 Jul 1993 EP
0560318 Sep 1993 EP
0568185 Nov 1993 EP
0657297 Jun 1995 EP
0721850 Jul 1996 EP
0780839 Jun 1997 EP
0789316 Aug 1997 EP
0866420 Sep 1998 EP
0894620 Feb 1999 EP
0916519 May 1999 EP
0 933 717 Aug 1999 EP
0949595 Oct 1999 EP
0 956 818 Nov 1999 EP
0 959 440 Nov 1999 EP
0 984 404 Mar 2000 EP
1 016 947 Jul 2000 EP
1 039 403 Sep 2000 EP
1 104 909 Jun 2001 EP
1 113 387 Jul 2001 EP
1 199 684 Apr 2002 EP
1 251 450 Oct 2002 EP
1345146 Sep 2003 EP
1371254 Oct 1974 GB
2108906 May 1985 GB
2240948 Aug 1991 GB
2 347 537 Sep 2000 GB
2350021 Nov 2000 GB
62-043774 Mar 1987 JP
62-264999 Nov 1987 JP
63-071794 Apr 1988 JP
63-098689 Apr 1988 JP
63-072721 May 1988 JP
63-175987 Jul 1988 JP
64-004934 Jan 1989 JP
64-037397 Mar 1989 JP
64-087395 Mar 1989 JP
64-087396 Mar 1989 JP
02-130737 May 1990 JP
02-252149 Oct 1990 JP
03-290780 Dec 1991 JP
42-005596 Jul 1992 JP
04-303692 Oct 1992 JP
05-069689 Mar 1993 JP
05-254283 Oct 1993 JP
06-183187 Jul 1994 JP
06-191137 Jul 1994 JP
06-234287 Aug 1994 JP
07-173358 Jul 1995 JP
07-205569 Aug 1995 JP
08-244385 Sep 1996 JP
08-324163 Dec 1996 JP
09-050505 Feb 1997 JP
09-052240 Feb 1997 JP
09-274640 Oct 1997 JP
10-129161 May 1998 JP
10-289296 Oct 1998 JP
10302160 Nov 1998 JP
10-334206 Dec 1998 JP
10-340231 Dec 1998 JP
11-175640 Jul 1999 JP
11-227367 Aug 1999 JP
11-353425 Dec 1999 JP
2000-1109 Jan 2000 JP
2000-015288 Jan 2000 JP
2000-40181 Feb 2000 JP
2000-048153 Feb 2000 JP
2000-67312 Mar 2000 JP
2000-163538 Jun 2000 JP
2000-177229 Jun 2000 JP
2000-194799 Jul 2000 JP
2000-207641 Jul 2000 JP
2000-222176 Aug 2000 JP
2000-252854 Sep 2000 JP
2001-5931 Jan 2001 JP
2001-504406 Apr 2001 JP
2001-134536 May 2001 JP
2001-160105 Jun 2001 JP
2001-283122 Oct 2001 JP
2001-315475 Nov 2001 JP
2002-109584 Apr 2002 JP
2002-133335 May 2002 JP
2002-157530 May 2002 JP
2002-274087 Sep 2002 JP
2003-288646 Oct 2003 JP
WO 8100776 Mar 1981 WO
WO 8903760 May 1989 WO
WO 9008661 Aug 1990 WO
WO 9216913 Oct 1992 WO
WO 9532919 Dec 1995 WO
WO 9535546 Dec 1995 WO
WO 9618972 Jun 1996 WO
WO 9740459 Oct 1997 WO
WO 9903057 Jan 1999 WO
WO 9912136 Mar 1999 WO
WO 9914055 Mar 1999 WO
WO 9927492 Jun 1999 WO
WO 9940548 Aug 1999 WO
WO 9947983 Sep 1999 WO
WO 0010144 Feb 2000 WO
WO 0038088 Jun 2000 WO
WO 0104825 Jan 2001 WO
WO 0115098 Mar 2001 WO
WO 0143095 Jun 2001 WO
WO 0155955 Aug 2001 WO
WO 0172224 Oct 2001 WO
WO 0177856 Oct 2001 WO
WO 0180473 Oct 2001 WO
WO 0186535 Nov 2001 WO
WO 0190962 Nov 2001 WO
WO 0195243 Dec 2001 WO
WO 0201485 Jan 2002 WO
WO 0213134 Feb 2002 WO
WO 0221903 Mar 2002 WO
WO 02063545 Aug 2002 WO
WO 02065246 Aug 2002 WO
WO 02065404 Aug 2002 WO
WO 02069221 Sep 2002 WO
WO 02073512 Sep 2002 WO
WO 02086665 Oct 2002 WO
WO 02091281 Nov 2002 WO
WO 02097575 Dec 2002 WO
WO 02101670 Dec 2002 WO
WO 03007623 Jan 2003 WO
Non-Patent Literature Citations (50)
Entry
“What's New: Timex Watch Features Speedpass System”, http://www.speedpass.com/news/article.jsp?id=51 (1 page).
“Physical Reality: A Second Look”, Ken Sharp, Senior Technical Editor, http://www.idsystems.com/reader/1999—03/phys0399—pt2/phys0399—pt2.htm (6 pages).
“‘Magic Wands’ to Speed Mobile Sales”, Bob Brewin, Jan. 15, 2001, http://www.computerworld.com/mobiletopics/mobile/story/1,10801,563300.html (4 pages).
“Mobile Speedpass Goes Global as Mobil Singapore Rolls Out Asia's First RFID-Based Pay-At-The-Pump System”, Press Release, Apr. 5, 1999, http://www.ti.com/tiris/docs/news—releases/rel12.htm (3 pages).
“Speedpass Unleashed”, Jun. 4, 2002 http://www.cardweb.com/cardtrak/news/cf2—20a—97.html (2 pages).
Prophecy Central Update #9, Oct. 10, 1997, http://www.bible-prophecy.com/pcu9.htm (5 pages).
International Newsletter of the TI RFID Group, Issue 20, 2000 (12 pages).
“CES: Microsoft's SPOT Technology has Humble Origins”, by James Niccolai, Jan. 10, 2003, http://archive.inforworld.com/articles/hn/xml/03/01/10/030110hnspot.xml?s=IDGNS (3 pages).
“Microsoft: See SPOT Run on Your Wrist”, by Richard Shim, Jun. 5, 2003, http://news.com.com/2100-1041—3-1013442.html?tag=fd—top (1 page).
“Networking: Microsoft SPOT”, by Jeremy A. Kaplan, Jul. 1, 2003, http://www.pcmag.com/print—article/0,3048,a=43561,00.asp (2 pages).
“Microsoft Launches Smart Personal Object Technology Initiative”, Press Release from COMDEX Fall 2002, Nov. 17, 2002, http://www.Microsoft.com/presspass/features/2002/nov02/11-17SPOT.asp (4 pages).
http://www.semiconductors.phillips.com/news/content/file—878.html, Apr. 7, 2003.
http://www.palowireless.com/infotooth/whatis.asp, Apr. 28, 2003.
http://www.palowireless.com/infotooth/tutorial.asp, Apr. 28, 2003.
http://www.palowireless.com/infotooth/tutorial/profiles.asp, Apr. 28, 2003.
http://www.palowireless.com/infotooth/tutorial/radio.asp, Apr. 28, 2003.
http://www.polowireless.com/infotooth/tutorial/baseband.asp, Apr. 28, 2003.
http://www.palowireless.com/infotooth/tutorial/lmp.asp, Apr. 28, 2003.
http://www.palowireless.com/infotooth/tutorial/hci.asp, Apr. 28, 2003.
http://www.palowireless.com/infotooth/tutorial/12cap.asp, Apr. 28, 2003.
http://www.palowireless.com/infotooth/tutorial/rfcomm.asp, Apr. 28, 2003.
http://www.palowireless.com/infotooth/tutorial/sdp.asp, Apr. 28, 2003.
http://www.palowireless.com/infotooth/tutorialk1—gap.asp, Apr. 28, 2003.
“Sony, Phillips to Test RFID Platform”, RFID Journal, May 8, 2003.
ISO/IEC 7816-6:1996(E)—First Edition—May 15, 1996.
ISO/IEC 7816-4:1995(E)—First Edition—Sep. 1, 1995.
USBanker, Article 5, 1995, http://www.banking.com/us-banker/art5.
Financial Technology International Bulletin, V14, n1, p. 4, Sep. 1996.
Green, Thomas C., “American Express Offers temporary CC numbers for the web,” Sep. 9, 2000, The Register, www.theregister.c.uk/c.
CNN.com, U.S. News, “American Express to offer disposable credit card numbers,” Sep. 8, 2000, Associated Press, www.cnn.com.
American Express, “Private Payments (sm) ; A New Level of Security from American Express,” American Express Website, Cards.
Martin Zack, “One-Time Nos. Stop Web Hackers From Pilfering Data,” Jan. 2001, Card Marketing, Thomson Financial, www.c rdf rum.c.
The Dollar Stretcher, “Disposable Credit Card Numbers,” Jan. 2001, CardRatings.org, www.stretcher.com.
Canadian Office Action dated Apr. 25, 2008.
International Search Report and Written Opinion of the International Searching Authority, PCT/US05/26067, May 23, 2007.
“What's New: Timex Watch Features Speedpass System” http://www.speedpass.com/news/article.jsp?id=51 (1 page).
“‘Magic Wands’ to Speed Mobile Sales”, BobBrewin, Jan. 15, 2001, http://www.computerworld.com/mobiletopics/mobile/story/1,10801,563300.html (4 pages).
“Mobile Speedpass Goes Global as Mobil Singapore Rolls Out Asia's First RFID-Based Pay-At-The-Pump System”, Press Release, Apr. 5, 1999, http://www.ti.com/tiris/docs/news—releases/re112.htm (3 pages).
“Bank Extends RFID Payment Pilot: Bank of America will continue to test its Quick Wave RFID payment card for another three months”, RFID Journal, Jan. 23, 2003.
“MasterCard to Test RFID Card: Pilot will test whether consumers, merchants and credit card issuers value “contactless” payments”, RFID Journal, Dec. 20, 2002.
“Vendors Target Amusement Parks: Protecting children and enabling cashless payments make RFID an appealing option for the entertainment industry”, RFID Journal, Nov. 27, 2002.
“Inside's Next-Gen Smart Card: The French company plans to introduce an RFID card that uses a 16-bit microprocessor and new encryption technology”, RFID Journal, Oct. 29, 2002.
“Sony, Philips Creating RFID Link: Consumer electronics giants are jointly developing a new RFID standard for payments and for communication between devices”, RFID Journal, Sep. 17, 2002.
“Japan Gets Digital Ticket System: A national ticket seller and phone company are teaming up to create an electronic ticket”, RFID Journal, Aug. 31, 2002.
“Security for Wireless Java: NTRU, a startup that offers security software, has relased of Java version of its NTRU encryption algorithm”, RFID Journal, Jun. 27, 2002.
“Making RFID Payments Ubiquitous: Philips and Visa want people to be able to pay for goods and services anywhere by using RFID chips embedded in the phones and other devices”, RFID Journal, Jun. 2, 20003.
“RFID Smart Cards Gain Ground: The convenience of contactless transactions is driving widespread adoption of contactless smart cards”, RFID Journal, Apr. 9, 2003.
“TI Embarces Prox Card Standard: Texas Instruments ISO 14443 payment platform promises faster data transfer rates and more security”, RFID Journal, Mar. 6, 2003.
“Multiple Frequency Transponders: Volume production of dual-band RFID chips begins”, Frontline Solutions, Jul. 16, 2003.
Functional Specification, Standard Card IC MFI IC S50, Philips Semiconductors, Product Specification Rev. 5.1 May 2001.
Provisional Applications (3)
Number Date Country
60512297 Oct 2003 US
60304216 Jul 2001 US
60396577 Jul 2002 US
Continuation in Parts (4)
Number Date Country
Parent 10340352 Jan 2003 US
Child 10711964 US
Parent 10192488 Jul 2002 US
Child 10340352 US
Parent 10318432 Dec 2002 US
Child 10340352 US
Parent 10318480 Dec 2002 US
Child 10318432 US