JP5643854B2 - Systems and methods for motivating payments using radio frequency identification in contact and contactless transactions - Google Patents

Description

(Field of Invention)
The present invention relates to a system and method for completing a transaction, and more particularly, completing a financial transaction using radio frequency identification (RFID) in a contact and contactless environment.

(Background of the Invention)
RFID, such as bar code and voice data entry, is a contactless information collection technology. RFID systems are wireless and are particularly effective in bad environments where conventional collection methods usually do not work. RFID is well established in a wide range of markets such as, for example, high speed readout of railway containers, tracking of moving objects such as livestock or cars, and merchandise inventory management applications. Thus, RFID technology is central to automatic data collection, identification, and analysis systems worldwide.

  Recently, companies are incorporating RFID data collection technology in the form of fobs or tags for use in completing financial transactions. A typical fob is a device that includes a transponder and incorporates all the necessary functions that can usually be included in any portable form factor. In some examples, a battery may be included with the fob to power the transponder. Alternatively, the fob can be present independent of the internal power source. In this case, the fob's internal circuitry (including the transponder) can draw its operating power from the battery power supply. Alternatively, the fob can be present independent of the internal power source. In this case, the fob's internal circuitry (including the transponder) can obtain its operating power directly from the RF interrogation signal. US Pat. No. 5,053,774 issued to Schuermann describes a typical transponder RF interrogation system that can be found in the prior art. The Schuermann patent generally describes power delivery techniques for conventional transponder structures. U.S. Pat. No. 4,739,328 describes how a conventional transponder can respond to an RF interrogation signal. Other typical modulation techniques that may be used include, for example, ISO / IEC 14443.

  In the conventional fob power supply technology used, the fob is typically activated when the fob is provided with an interrogation signal. In this regard, the fob can be activated regardless of whether the user desires such activation. Inadvertent provision of fobs can lead to undesired transaction initiation and completion. Accordingly, there is a need for a fob system that allows fob users to control fob activation and limit transactions from being completed unnecessarily.

  One of the more obvious uses of RFID technology is found in the introduction of Exxon / Mobil's Speedpass® and Shell's EasyPay® product. These products use a transponder placed on the fob or tag. The fob or tag allows the user to be automatically identified when the fob is provided to a point of sale (POS) device. The fob identification data is typically passed to a third-party server database, where the identification data is queried for a customer (eg, user) credit or debit account. For the exemplary processing method, the server seeks transaction authorization by passing transaction and account data to an authorization entity. Once authorization is received by the server, a clearance is sent to the point of sale information management device to complete the transaction. Thus, conventional transaction processing methods include an indirect path that causes unreasonable overhead to use a third party server.

  While a fob transaction is authorized, there is a need for a transaction authorization system that allows the costs associated with using a third party server to be eliminated.

  Further, conventional fobs are limited in that they must be used in the vicinity of point-of-sale information management devices. That is, to activate the fob, the conventional fob must be placed within the transmission range cast by the RF interrogation signal. More specifically, conventional fobs are not effective for use in situations where a user desires to conduct transactions at a point of two-way communication such as a computer interface.

  Accordingly, there is a need for a fob that embodies RFID collection technology that can be used at the point of a two-way communication device and that can facilitate transactions via a computer interface connected to a network (eg, the Internet). .

  Existing transponder-reader payment systems are further limited in that conventional fobs used in the system respond to only one interrogation signal. If multiple interrogation signals are used, the fob will only respond to interrogation signals that it is configured to respond to. Thus, if the system's RFID reader only provides an interrogation signal that is not compatible with the fob, the fob will not be properly activated.

  Therefore, there is a need for a fob that responds to one or more interrogation signals.

  Existing transponder-reader payment systems are further limited in that the payment system is typically linked to a funding source associated with a transponder that includes a predetermined payment limit. Thus, no flexibility is provided when a payment is requested that exceeds a predetermined payment limit. This is usually done by traditional methods of processing the requested transaction, comparing the payment limit or amount stored in the preloaded value data file before providing the transaction authorization to the customer. It is true in that it includes.

  Accordingly, there is a need for a system that processes transponder-leader payment requests regardless of the payment limit assigned to the associated transponder-leader payment system funding source.

  Furthermore, traditional transponder-reader systems do not allow users to manage system user account data. This may be the case when the user wishes to change the transponder-reader system funding source to one that provides room for available payment limits, or changes to the user's status (eg, address, phone number, e-mail, etc.), and this is very problematic when the transponder-reader account provider only wants to update the user's account.

  Accordingly, there is a need for a transponder-reader system that allows a user limited access to a transponder-reader account to manage account data.

  Further, existing transponder-reader systems typically do not allow a means to automatically motivate the use of the fob associated with the system, unlike credit cards or charge cards associated with the fob. That is, conventional transponder-reader systems do not provide a means to motivate the use of transponder-reader systems by motivating the use of fob products. This is because the system does not make a sufficient distinction between a system transponder and a charge card or credit card account associated with the transponder.

  Therefore, there is a need for a transponder reader that can determine when a system transponder is used and provide the motivation for such use.

  In addition, the systems are limited in that they cannot track credit or charge card usage and fob usage if there is a single funding source. For example, in a typical prior art system, a fob can be linked to a predetermined funding source (eg, American Express, MasterCard, Visa, etc.) that can be used to provide funds to satisfy a transaction request. The funding source may further include a consumer credit or charge card that may be associated with the fob and used for contact transactions. If a credit card or charge card is used, a statement reporting card usage is provided to the card user. However, the report statement includes a report of fob product usage. Thus, the fob user is unable to properly chart, analyze or compare the fob usage with the associated card usage. This is the case when a funding source is used by one or more entities (eg, spouse, multiple employees, etc.) or one entity may use a fob and a separate entity is associated with that fob Are particularly problematic.

  Therefore, there is a need for a transponder-reader payment system that allows fob usage and credit card usage to be reported in a single file.

(Summary of the Invention)
Described herein are systems and methods for initiating and completing financial transactions using RFID technology. The transponder-reader payment system described herein provides an RF challenge for powering a transponder system, receiving a transponder system RF signal, and providing transponder system account data in connection with the transponder system RF signal. An RFID reader operable to provide a signal may be included. The transponder-reader payment system includes an RFID protocol / sequence controller in electrical communication with one or more interrogators for providing interrogation signals to the transponder, an RFID authentication circuit for authenticating signals received from the transponders, and RFID A USB or serial interface may be provided for use in personalizing the reader and / or transponder. The transponder-reader payment system includes one or more transponders (eg, modules) that are responsive to one or more interrogation signals and that the transponder and / or RFID reader is authorized to operate within the transponder-reader payment system. It may further comprise a fob for providing an authentication signal for verifying what has been done. In this way, the fob can respond to multiple interrogation signals provided at different frequencies. In addition, the fob may include a USB or serial interface for use with a computer network or RFID reader.

  The RFID system and method according to the present invention may be embodied in a fob, tag, card, or any other form factor (eg, watch, keychain, cell phone, etc.) and provided for interrogation May include a transponder that may be possible. In this regard, although the transponder is described herein as being embodied in a fob, the present invention is not so limited.

  The system further comprises an RFID reader configured to transmit a stationary RFID recognition signal that can be transmitted from the RFID via radio frequency (or electromagnetic) propagation. The fob can be placed in the vicinity of the RFID reader so that the RFID signal can call the fob and initiate a fob identification procedure.

  In an exemplary embodiment, as part of the identification process, the fob and RFID reader may be involved in mutual authentication. The RFID reader may identify the fob when it receives encrypted information and includes an authorized system transponder for storing that information in the fob memory. Similarly, the fob, when challenged by an RFID reader, may identify the RFID reader as authorized to receive encrypted and stored information. If the RFID reader and fob successfully authenticate, the fob may transmit specific information to the RFID reader that identifies the trading account (s) with which the fob is associated. The RFID reader may receive information and pass information to facilitate the completion of the transaction. In one exemplary embodiment, the RFID reader may transfer information to a point on the intercommunication device (eg, POS or computer interface) to complete the transaction. The mutual authentication process disclosed herein helps to ensure transponder-reader payment system security.

  In another exemplary embodiment, a fob according to the present invention includes means for completing a transaction via a computer interface. The fob can be connected to the computer using a USB or serial interface, and fob account information can be transferred to the computer for use in completing transactions over a network (eg, the Internet).

  In yet another exemplary embodiment of the present invention, a system is provided that facilitates the use of a transponder-reader system transponder (eg, a fob). This system distinguishes between the use of a fob that shares the same funding source as a fob and the use of a charge or credit card. If a fob is used, the system may provide motivation to the user based on criteria predetermined by the fob issuer. Furthermore, if a preloaded fob system is used, the present invention recognizes when funds are loaded or reloaded into the associated fob preload value data file. The present invention may further provide reward points based on criteria associated with loading or reloading actions. Furthermore, the system according to the present invention may motivate the customer's special provisions. In this case, the system may receive a fob trading request based on a marker or other identifier associated with the trading partner and motivates the fob user. The marker may be included in the transaction identification, the supplier identification provided by the transaction, or a combination of both.

  In yet another exemplary embodiment of the present invention, a system is disclosed that allows a fob user / owner to manage an account associated with the fob. For example, users may have full or partial fob account information stored in an account provider database to update demographic information, account funding sources, and / or account constraints (eg, payment limits, personal identification numbers, etc.) Provided to. Access to the full or partial account may be provided to the user by telephone via a network (eg, online) or via offline communication. For example, a fob user may be provided access to a system that has delayed communication with an account provider database, where such a system may include, for example, a kiosk that provides batch transmission to the account provider system. In this way, the fob user / owner may update the account information in real time (eg, over the phone or online) or at a time when the account provider receives updated information (eg, offline).

  In a further exemplary embodiment, the present invention provides a method of processing a transaction request, whereby an amount is available before requesting funding from a funding source and / or to complete a transaction. The amount of transaction request can be approved before verifying that it is. In this way, a transaction may be approved if the transaction and / or account meets certain predetermined authorization criteria. Once the criteria are met, the transaction is authenticated and authentication is provided to the requesting agent (eg, the trading partner). In one example, payment for a transaction is requested from a funding source at the same time as or immediately after providing authentication to the business partner. In another example, payment for a transaction is requested at a later time period than when authorization is provided to the business partner.

  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.

  The accompanying drawings, in which like numerals indicate like elements, illustrate exemplary embodiments of the invention and, together with the description, serve to explain the principles of the invention.

FIG. 1A illustrates an exemplary RFID-based system according to the present invention, where exemplary components used to complete a fob transaction are shown. FIG. 1B shows an exemplary personalization system according to the present invention. FIG. 2 is a schematic diagram of an exemplary fob according to the present invention. FIG. 3 is a schematic diagram of an exemplary RFID reader according to the present invention. FIG. 4 is an exemplary flowchart of an exemplary authentication process according to the present invention. FIG. 5 is an exemplary flowchart of an exemplary determination process of a protocol / sequence controller according to the present invention. FIG. 6A is an exemplary flowchart of a fob personalization process in accordance with the present invention. FIG. 6B is an exemplary flowchart of a fob personalization process in accordance with the present invention. FIG. 7A is an exemplary flowchart of an RFID reader personalization process according to the present invention. FIG. 7B is an exemplary flowchart of an RFID reader personalization process according to the present invention. FIG. 8 is a flowchart of an exemplary payment / transaction process according to the present invention. FIG. 9 is another schematic diagram of an exemplary fob according to the present invention. FIG. 10 is a diagram of an exemplary preloaded fob payment / transaction process in accordance with the present invention. FIG. 11A is a diagram of an exemplary preloaded fob account reload process in accordance with the present invention. FIG. 11B is a diagram of an exemplary preloaded fob account reload process in accordance with the present invention. FIG. 12 is a diagram of an exemplary direct link payment / transaction process in accordance with the present invention. FIG. 13 is a diagram of another exemplary payment / transaction process in accordance with the present invention.

(Detailed explanation)
The present invention may be described in the following with respect to functional block components, screen shots, optional selections, and various processing steps. Such functional blocks may be implemented by any number of hardware and / or software components configured to perform specific functions. For example, the present invention provides various integrated circuit components such as memory elements, processing elements, logic elements, look-up tables, etc. that can perform various functions under the control of one or more microprocessors or other control devices. Can be used. Similarly, the software element of the present invention can be any program or script in any language such as C, C ++, Java (R), COBOL, assembler, PERL, Extensible Markup Language (XML), Java (R) Card, and MULTIS. And various algorithms can be implemented by any combination of data structures, objects, processes, routines or other program elements. Furthermore, it should be noted that the present invention can use any number of conventional techniques such as data transmission, signaling, data processing, network control, and the like. For basic guidance on encryption methods, a text called “Applied Cryptography: Protocols, Algorithms, and Source Code in C” written by Bruce Schneier (John Wiley & Sons Publishing (2nd edition), 1996). ) (Incorporated herein by reference).

  In addition, multiple applications of the present invention may be defined. Exemplary networks disclosed herein may include any system for data exchange or business transactions such as the Internet, intranet, extranet, WAN, LAN, satellite communications, and the like. Note that the network may be implemented as other types of networks, such as an interactive television network (ITN).

  If desired, the system user can connect via any input device such as a keypad, keyboard, mouse, kiosk, personal digital assistant, handheld computer (eg, Palm Pilot®, Blueberry®), mobile phone, etc. Two-way communication with the system. Similarly, the present invention works with any type of personal computer, network computer, workstation, minicomputer, mainframe, etc., in any version of Windows (R), Windows (R) NT, Windows (R). Any operating system such as 2000, Windows (R) 98, Windows (R) 95, MacOS, OS / 2, BeOS, Linux, UNIX (R), Solaris, etc. can be operated. Further, although the present invention may be described as being implemented with a TCP / IP communication protocol, the present invention may be described using SNA, IPX, Appletalk, IPte, NetBIOS, OSI or any number of communication protocols. It should be understood that can also be realized. In addition, the system takes into account the use, sale or delivery, service or information of any product over any network with similar functionality as described herein.

  FIG. 1A illustrates an exemplary RFID trading system 100A according to the present invention, where exemplary components for use in completing a fob transaction are shown. In general, operation of system 100A may begin when fob 102 is provided for payment and is interrogated by RFID reader 104 or interface 134. The fob 102 and RFID reader 104 may then be engaged in mutual authentication, after which the transponder 102 may provide the transponder identification and / or account identifier to the RFID reader 104, which in turn provides information to the trading partner system 130POS. Device 110 may be provided.

  System 100A may include a fob 102 having a transponder 114 and an RFID reader 104 in RF communication with fob 102. Although the present invention will be described with respect to fob 102, the present invention should not be so limited. Indeed, system 100 may include any device having a transponder configured to communicate with RFID reader 104 via RF communication. Exemplary devices may include, for example, key rings, tags, cards, cell phones, watches, or any such form that can be provided for interrogation.

  RFID reader 104 may be configured to communicate using RFID internal antenna 106. Alternatively, the RFID reader 104 can include an external antenna 108 for communicating with the fob 102, where the external antenna can be remote from the RFID reader 104 using a suitable cable and / or data link 120. The RFID reader 104 may further communicate with the customer system 130 via the data link 122. System 100A may include a transaction completion system that includes a point of interactive communication device, such as, for example, a point-of-sale point of sale (POS) device 110 or a computer interface (eg, user interface) 134. In an exemplary embodiment, the transaction completion system may include a customer system 130 that includes a POS device 110 (via data link 122) that communicates with the RFID reader 104. As described in detail below, the transaction completion system may include a user interface 134 connected to the network 136 and the transponder via the USB connector 132.

  Although the point of a two-way communication device is described herein with respect to a point of sale (POS) device, the present invention may not be limited to this. In fact, a merchant POS device is used illustratively herein, and the point of a two-way communication device can be any device capable of receiving fob account data. In this regard, the POS can be any point on the two-way communication device that allows the user to complete a transaction using the fob 102. The POS device 110 may further communicate with a customer interface 118 (via data link 128) for entering at least one customer identification verification information. Further, the POS device 110 may communicate with a trading partner host network 112 (via the data link 112) for processing any trading request. With this configuration, the information provided by the RFID reader 104 is provided to the POS device 110 of the customer system 130 via the data link 122. The POS device 110 may receive the information (or may receive any identification verification information from the customer interface 118 via the data link 128) and provide it to the host system 112 for processing.

  A variety of conventional communication media and protocols may be used for data links 120, 122, 124, and 128. For example, data links 120, 122, 124 and 128 are typically local loops used in connection with standard modem communications, cable modems, dish networks, ISDN, digital subscriber lines (DSL), or any wireless communication medium. May be an Internet Service Provider (ISP) configured to facilitate communication over the Internet. In addition, trading partner system 130, including POS device 110 and host network 112, may reside in a local area network that interfaces with a remote network (not shown) for remote authorization of intended transactions. The supplier system 130 can communicate with a remote network via a dedicated line such as a T1 or D3 line. Such communication lines are described in various documents such as "Understandning Data Communications" by Gilbert Held (incorporated herein for reference).

  As used herein, an account number may be maintained by a trading account provider (eg, a payment authorization center) and used to complete a financial transaction (eg, credit, charge debit, current, normal, Rewards, special offers, etc.) may be included. Typical account numbers (eg, account data) are credit or debit accounts, contract accounts, or rewards maintained and serviced by entities such as American Express®, Visa® and / or MasterCard®. Can correlate with account. For ease of understanding, the present invention may be described for credit accounts. However, it is noted that the present invention is not so limited, and that other accounts that allow the exchange of goods and services related to account data values are considered within the scope of the present invention. I want.

  Further, an account number (eg, account data) can be obtained by any device, code or consumer, for example, an authorization / access code, personal identification number (PIN), internet code, digital certificate, biometric data, and / or Or may be associated with other identifiers / marks suitably configured to allow bi-directional communication or communication with the system, such as other identification marks. The account number can optionally be placed on a reward card, charge card, credit card, debit card, prepaid card, telephone card, smart card, magnetic strip card, barcode card, etc. as appropriate. The account number may be distributed and stored on any form of plastic, electronic, magnetic and / or optical device capable of transmitting or downloading data to the second device. The customer account number can be, for example, a 16-digit credit card number, but each credit provider has a unique numbering system, such as the 15-digit numbering used by American Express®. Each company's credit card number depends on the company's standardized format, which means that companies using the 16-digit format are typically four spaced apart numbers represented by the number "0000 0000 0000 0000" Use a set of In a typical example, the first 5-7 digits are specified to identify the processing purpose and issuing bank, card type, etc. In this example, the last 16th digit is used as a 16 digit number sum check. The middle 8-10 digits are used to uniquely identify the customer. Account numbers and the like stored as Track 1 and Track 2 data defined in ISO / IEC 7813 can be uniquely created in the fob 102. In one exemplary embodiment, the account number may include a unique fob serial number and user identification number, and a specific application applet. The account number may be stored in the fob 102 within the database 214 as will be described in more detail below. Database 214 may be configured to store multiple account numbers issued to users of fob 102 by the same or different account providers. If the account data corresponds to a special offer or reward account, the database 214 may be configured to store incidental reward or reward point data.

  FIG. 2 is a block diagram illustrating many functional blocks of an exemplary fob 102 according to the present invention. The fob 102 may be an RFID fob 102 that may be presented by a user to facilitate receipt of goods or services and exchange for funds or points or the like. As described herein by way of example, fob 102 may be an RFID fob that may be presented to facilitate payment for goods and / or services.

  The fob 102 may include an antenna 202 that receives an interrogation signal from the RFID reader 104 via the antenna 106 (or external antenna 108). The fob antenna 202 can communicate with the transponder 114. In one embodiment, the transponder 114 may be a 13.56 MHz transponder that conforms to the ISO / IEC 14443 standard, and the antenna 202 may be a 13 MHz type. Transponder 114 may communicate with a modulator / demodulator 206 that is compatible with the transponder. The modulator / demodulator 206 is configured to receive the signal from the transponder 114 and is configured to modulate the signal into a format readable by a later connected circuit. Further, modulator / demodulator 206 formats (eg, modulates) a signal received from a later connected circuit into a format compatible with transponder 114 that transmits to RFID reader 104 via antenna 202. Can be configured as follows. For example, if the transponder 114 is of the 13.56 MHz type, the modulator / demodulator 206 may be compliant with ISO / IEC 14443-2.

  Modulator / demodulator 206 may be connected to protocol / sequence controller 208. The protocol / sequence controller 208 facilitates control of authentication of signals provided by the RFID reader 104 and facilitates control of transmission of the account number of the fob 102. In this regard, the protocol / sequence controller 208 can be any suitable digital or logic drive circuit that can facilitate the determination of the sequence of operation of the fob 102 internal circuitry. For example, the protocol / sequence controller 208 may be configured to determine whether a signal provided by the RFID reader 104 is authenticated, thereby supplying the RFID reader 104 with an account number stored in the fob 102. To do.

  The protocol / sequence controller 208 may further communicate with an authentication circuit 210 that facilitates authentication of signals provided by the RFID reader 104. The authentication circuit may further communicate with the non-volatile secure memory database 212. The secure memory database 212 may be any suitable basic file system as defined by ISO / IEC 7816-4, or any other that allows data lookup tables to be interpreted by the application on the chip. Can be a basic file system. Database 212 may be any type of database, such as correlated, hierarchical, and / or object oriented. A common database product that can be used to run a database is DB2 by IBM (White Plains, NY), any database product available from Oracle Corporation (Redwood Shores, CA), Microsoft Corporation (Rodwood, WA) It may be Microsoft Access or MSSQL, or any other database product. Database 212 may be organized in any suitable manner including data tables or lookup tables. Associating certain data can be accomplished by any data-related technique known and practiced in the art. For example, the association can be accomplished manually or automatically. Automatic association techniques may include, for example, database search, database merge, GREP, AGREP, and / or SQL. The associating step can be accomplished by a database merge function, for example, by using a “key field” for each of the manufacturer and vendor data tables. The “key field” divides the database according to the high-level class of objects defined by the key field. For example, a class can be designated as a key field in both the first data table and the second data table. The two data tables can then be merged based on the class data in the key field. In this embodiment, the data corresponding to each key field of the merged data table is preferably the same. However, data tables with similar, if not identical, data in the key field can also be merged using, for example, AGREP.

  In addition to security purposes, the data can be used by the protocol / sequence controller 208 for data analysis, and can also be used for management and control purposes. The authentication circuit may authenticate the signal provided by the RFID reader 104 by associating the RFID signal with an authentication key stored in the database 212. The encryption circuit may use a key stored in the database 212 to encrypt and / or decrypt signals sent to or from the RFID reader 104.

  In addition, the protocol / sequence controller 208 may communicate with a database 214 that stores at least fob 102 account data and a unique fob 102 identification code. Protocol / sequence controller 208 may be configured to retrieve the account number from database 214 as desired. The database 214 may have the same configuration as the database 212 as described above. The fob account data and / or unique fob identification code stored in database 214 may be encrypted prior to storage. Thus, if the protocol / sequence controller 208 retrieves account data or a unique fob identification code from the database 214, the account number can be encrypted when provided to the RFID reader 104. Further, the data stored in the database 214 may include, for example, unique unencrypted fob 102 identification code, user identification, track 1 and 2 data, in addition to the specific application applet.

  The fob 102 may be configured to respond to multiple interrogation frequency transmissions provided by the RFID reader 104. That is, as will be described in more detail below, the RFID reader 104 may provide more than one RF interrogation signal. In this case, the fob 102 may be configured to respond to multiple frequencies by including one or more additional RF signal receiving / transmitting units 226 in the fob 102. The RF signal receiving / transmitting unit 226 may include an antenna 218 and a transponder 220 that are compatible with at least one additional RF signal provided by the RFID reader 104. For example, in one embodiment, the 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. Alternatively, a 134 KHz transponder can be configured to communicate directly with the protocol / sequence controller 208 for authentication and account number signal transmission and reception as described above.

  In another embodiment, the fob 102 may further include a universal serial bus (USB) connector 132 that interfaces the fob 102 to the user interface 134. The user interface 134 may further communicate with the POS device 110 via the network 136. Network 136 may be the Internet, an intranet, etc. as described above with respect to network 112. Further, the user interface 134 may have a configuration similar to any conventional input device and / or computing system that allows the system user described above to interact with the system. In one embodiment, the fob 102 may be configured to facilitate online payment over the Internet. USB converter 222 may communicate with USB connector 232 that facilitates the transfer of information between modulator / demodulator 206 and USB connector 132. Alternatively, USB converter 222 may communicate with protocol / sequence controller 208 to facilitate the transfer of information between protocol / sequence controller 208 and USB connector 132.

  If the fob 102 includes a USB connector 132, the fob 102 may communicate with a USB port on the user interface 134, for example. Information retrieved from the fob 102 may be compatible with credit card and / or smart card technology that allows the use of interactive applications on the Internet. In this embodiment, an RFID reader may not be necessary. This is because the connection to the POS device 110 can be made using the user interface 134 and the USB port on the network 136.

  The fob 102 may include means that allow the user to activate the fob. In one embodiment, switch 230 may be operated by a user of fob 102. A switch 230 on the fob 102 is used to selectively or comprehensively activate the fob 102 for a particular application. In this case, the term “selective” may mean that the switch 230 allows the user to put the fob 102 into a particular mode of operation. For example, the user may place the fob 102 in a mode that allows the purchase of goods or services using the selected account number. Alternatively, the fob can be put into a mode in which the fob account number is provided only by the USB port 132 (or serial port) and the fob transponder 114 is disabled. Further, the term “inclusive” may mean that the fob 102 enters an operating mode that allows the fob 102 to respond to RF interrogation via the USB connector 132. In one embodiment, the switch 230 may remain in the OFF position, thereby confirming that one or more applications or accounts associated with the fob 102 do not respond to commands issued by the RFID reader 104. In this specification, the OFF position may be defined as the “normal” position of the activation switch 230, although other normal positions are also contemplated.

  In another embodiment, fob 102 may be considered activated by the user when switch 230 moves from the OFF position. That is, the switch 230 may activate internal circuitry within the fob 102 to allow the fob to respond to RF signals (eg, commands from the RFID reader 104). In this way, switch 230 may facilitate control of the active and inactive states of fob 102. Such control increases system security by preventing inadvertent or illegal use of the fob 102.

  In one embodiment, the switch 230 can be a simple mechanical device that communicates with circuitry that can electrically prevent the fob from being powered by the RFID reader. That is, when the switch 230 is in its normal position, the switch 230 may provide a short circuit to the internal circuitry of the fob 102, thereby allowing the fob 102 to respond to interrogation by RF or via the USB connector 230. To prevent. In this configuration, the switch 230 may be, for example, a switch configured in a “normally closed state” (NC). A switch configured in “normally closed” may be electrically connected to the antenna 202 at the interface between the antenna 202 and the transponder 114. The switch 230 can be pushed, which can cause the switch 230 to be open, thereby fully activating the antenna 202.

  In a further embodiment, the fob 102 may include a biometric sensor and a biometric membrane configured to operate as the switch 230 and activates the fob 102 when provided with a biometric signal from a user of the fob 102. Such a biometric signal can be a digital reading such as a fingerprint or thumbprint. Typically, when a biometric circuit is used, the biometric circuit can be powered by an internal voltage source (eg, a battery). In this case, the switch can be a powered switch rather than a simple mechanical device. In yet another embodiment, there is no biometric circuit in the fob 102, but the switch 230 can be powered by a battery.

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

  FIG. 3 is an exemplary block diagram of an RFID reader 104 according to an embodiment of the present invention. The RFID reader 104 includes, for example, an antenna 106 coupled to the RF module 302, and the antenna 106 is further coupled to the control module 304. Further, the RFID reader 104 may include an antenna 108 that is located remote from the RFID reader 104 and coupled to the RFID reader 104 via a suitable cable 120 or other wired or wireless connection.

  The RF module 302 and the antenna 106 may be suitably configured to facilitate communication with the fob 102. If the fob 102 is formatted to receive a signal at a particular RF frequency, the RF module 302 may be configured to provide an interrogation signal at the same frequency. For example, in one embodiment, the fob 102 may be configured to respond to an approximately 13.56 MHz interrogation signal. In this case, the RFID antenna 106 may be 13 MHz and may be configured to transmit an interrogation signal of about 13.56 MHz. That is, the fob 102 can be configured to include first and second RF modules (eg, transponders). The first module may operate using a frequency of 134 kHz and the second RF module may operate using a frequency of 13.56 MHz. The RFID reader 104 may include two receivers that may operate using a frequency of 134 kHz, a frequency of 13.56 MHz, or both. If the reader 104 is operating at a frequency of 134 kHz, the fob 102 may only be able to operate with a 134 kHz module. When reader 104 is operating at a frequency of 13.56 MHz, fob 102 may only be able to operate with a 13.56 MHz module. If the reader 104 supports both a 134 kHz frequency and a 13.56 MHz RF module, the fob 102 may receive both signals from the reader 104. In this case, the fob 102 may be configured to prioritize selection of one or the other frequency and reject the remaining frequencies. Alternatively, reader 104 may receive signals at both frequencies from the fob when called. In this case, the reader 104 may be configured to prioritize selection of one or the other frequency and reject the remaining frequencies.

  In addition, the protocol / sequence controller 314 may include an optional feedback function that informs the user of the status of a particular transaction. For example, the optional feedback may be in the form of LEDs, LED screens, and / or other visual displays. These are configured to light up or display static, scrolling, flashing, and / or other messages and / or signals. This tells the user that the transaction has started (eg, the fob has been called), that the fob is valid (eg, that the fob has been authenticated), and that the transaction is being processed (eg, Signals that the fob account number has been read by the RFID reader) and / or that the transaction has been accepted or rejected (eg, the transaction has been approved or not approved). Such optional feedback may or may not be accompanied by an audible indicator that informs the user of the fob 102 of the transaction status (or may present only the audible indicator). The audible feedback may be a single tone, multiple tones, a music indicator, and / or a voice indicator configured to represent when the fob 102 is being called, transaction status, and the like.

  The RFID antenna 106 may communicate with a transponder 306 that transmits an interrogation signal and receives at least one of an authentication request signal and / or account data from the fob 102. The transponder 306 may have a configuration similar to the transponder 114 of FIG. In particular, transponder 306 may be configured to transmit and / or receive RF signals in a format compatible with antenna 202 in a manner similar to that described with respect to fob transponder 114. For example, if the transponder 306 is at a 13.56 MHz RF rate, the antenna 202 may be compatible with 13.56 MHz. Similarly, antenna 106 may be compatible with ISO / IEC 14443 if transponder 306 is at ISO / IEC 14443 rate.

  The RF module 302 can include, for example, a transponder 306 that communicates with an authentication circuit 308 that can communicate with a secure database 310. Authentication circuit 308 and database 310 may have similar configurations and operate in the same manner as described above with respect to authentication circuit 210 and secure memory database 212 of FIG. For example, the database 310 may store data corresponding to the fob 102 that has been authorized to conduct transactions on the system 100. Database 310 may further store RFID reader 104 for use in authenticating whether RFID reader 104 is authorized to be provided with a fob account number stored in fob database 214. Identify the information to provide to the fob 102.

  The authentication circuit 308 has the same configuration as the authentication circuit 210 and can operate similarly. That is, the authentication circuit 308 may be configured to authenticate the signal provided by the fob 102 in a manner similar to the authentication circuit 210 may be configured to authenticate the signal provided by the RFID reader 104. As described in more detail below, the fob 102 and RFID reader 104 authenticate each other. In this case, “mutual authentication” means that the system 100 may not operate until the fob 102 authenticates the signal from the RFID reader 104 and the RFID reader 104 authenticates the signal from the fob 102. Can do.

  FIG. 4 is a flowchart of an exemplary authentication process according to the present invention. One aspect of the authentication process is shown. That is, the flowchart shows the process of the RFID reader 104 authenticating the fob 102, and similar steps may follow if the fob 102 authenticates the RFID reader 104.

  As described above, the database 212 may store a security key that encrypts or decrypts a signal received from the RFID reader 104. In the exemplary authentication process, if the RFID reader 104 is authenticating the fob 102, the RFID reader 104 may provide an interrogation signal for the fob 102 (step 402). The interrogation signal may include a random code generated by the RFID reader authentication circuit 210. The RFID reader authentication circuit 210 is provided to the fob 201 and is encrypted using a unique encryption key corresponding to an identification code unique to the fob 102. For example, the protocol / sequence controller 314 may provide instructions that activate the authentication circuit 308. Authentication circuit 308 may provide a fob interrogation signal from database 310 that includes a random number as part of the authentication code generated for each authentication signal. The authentication code may be an alphanumeric code that is recognizable (eg, readable) by the RFID reader 104 and the fob 102. The authentication code may be provided to the fob 102 via the RFID reader RF interface 306 and the antenna 106 (or antenna 108).

  The fob 102 receives the interrogation signal (step 404). An interrogation signal including an authentication code may be received at the RF interface 114 via the antenna 202. Once the fob 102 is activated, an interrogation signal including an authentication code can be provided to the modulator / demodulator circuit 206 where the signal can be modulated before being provided to the protocol / sequence controller 208. . The protocol / sequence controller 208 may recognize the interrogation signal as a request for authentication of the fob 102 and may provide an authentication code to the authentication circuit 210. The fob 102 may then encrypt the authentication code (step 406). In particular, encryption can be performed by the authentication circuit 210. The authentication circuit 210 can receive the authentication code, encrypt the code, and then provide the encrypted authentication code to the protocol / sequence controller 208. The fob 102 may then provide the encrypted authentication code to the RFID reader 104 (step 408). That is, the encrypted authentication code can be provided to the RFID reader 104 via the modulator / demodulator 206, the RF interface 114 (eg, transponder 114), and the antenna 202.

  RFID reader 104 may then receive the encrypted authentication code and decrypt it (step 410). That is, the encrypted authentication code can be received by the antenna 106 and the RF interface 306 can be provided to the authentication circuit 308. The authentication circuit 308 may be provided with a security authentication key (eg, a transponder system decryption key) from the database 310. The authentication circuit may use the authentication key to decrypt (eg, unlock) the encrypted authentication code. The authentication key may be provided to the authentication circuit based on the fob 102 specific identification code. For example, an encrypted authentication code may be provided along with a unique fob 102 identification code. The authentication circuit may receive the fob 102 unique identification code and retrieve from the database 310 a transponder system decryption key that correlates to the unique fob 102 identification code. This extracted authentication code is used to decrypt the encrypted authentication code.

  Once the authentication code is decrypted, in step 402, the decrypted authentication code is compared with the authentication code provided by the RFID reader 104 (step 412) to verify its validity. If the decrypted authentication code is not readable (eg, recognizable) by the authentication circuit 308, the fob 102 is deemed not authorized (eg, not verified) (step 416) and the operation of the system 100 ends (step 418). Conversely, if the decrypted authentication code is recognizable (eg, verified) by the fob 102, the decrypted authentication code is considered authenticated (step 412) and the transaction can proceed. It becomes possible (step 414). In one particular embodiment, proceeding with a transaction may mean that the fob 102 may authenticate the RFID reader 104 before the RFID reader 104 authenticates the fob 102. However, it should be apparent that the RFID reader 104 can authenticate the fob 102 before the fob 102 authenticates the RFID reader 104.

  Note that in the exemplary verification process, the authentication circuit 308 may determine whether the unlocked authentication code is the same as the authentication code provided in step 402. If the codes are not identical, the fob 102 is not authorized to access the system 100. Although the verification process is described in terms of identity, identity is not required. For example, the authentication circuit 308 may verify the decrypted code via any protocol, step or process that determines whether the decrypted code corresponds to an authorized fob 102.

  The authentication circuit 308 may further communicate with a protocol / sequence controller 314 that operates similarly to the protocol / sequence controller 208 of FIG. That is, the protocol / sequence device controller 314 can be configured to determine the order of operation of the components of the RFID reader 104. For example, FIG. 5 illustrates an exemplary decision process in which protocol / sequence controller 314 may operate. Protocol / sequence controller 314 may instruct different components of RFID reader 104 based on whether fob 102 is present (step 502). For example, if fob 102 is not present, protocol / sequence controller 314 may instruct RFID reader 104 to provide an uninterrupted interrogation signal. (Step 504). That is, the protocol / sequence controller may instruct the authentication circuit 308 to provide an interrogation signal that is not interrupted until the presence of the fob 102 is recognized. If fob 102 is present, protocol / sequence controller 314 may instruct RFID reader 104 to authenticate fob 102. (Step 506).

  As described above, authentication may mean that the protocol / sequence controller 314 may instruct the authentication circuit 308 to provide the fob 102 with an authorization code. If a response is received from the fob 102, the protocol / sequence controller determines whether the response is a response to the RFID reader 104 given the authentication code or whether the response is a signal that requires authentication. May be determined (step 508). If the signal requires authentication, the protocol / sequence controller 314 may activate the authentication circuit as described above (step 506). On the other hand, if the fob 102 is a response to the provided authentication code, the protocol / sequence controller 314 may instruct the RFID reader 104 to retrieve an appropriate security key that enables signal recognition. (Step 510). That is, the protocol / sequence controller 314 extracts the security key (eg, transponder system decryption key) from the database 310 in the authentication process (eg, step 506) to the authentication circuit 308, unlocks the signal, And a signal provided by the RFID reader 104 may be commanded. If the signal is recognized, the protocol / sequence controller 314 may determine that the fob 102 has been authorized to access the system 100. If the signal is not recognized, the fob 102 is considered unauthorized. In this case, the protocol / sequence controller 314 may instruct the RFID controller to call an authorized fob. (Step 504).

  Once the protocol / sequence controller determines that the fob 102 has been authorized, the protocol / sequence controller 314 may attempt to determine whether additional signals are being sent by the fob 102 (step 514). If additional signals are not provided by fob 102, protocol / sequence controller 314 may provide all components of RFID reader 104 to be idle until the signal is provided (step 516). Conversely, if an additional fob 102 signal is provided, the protocol / sequence controller 314 determines whether the fob 102 is requesting access to a trading point at a sales terminal 110 (eg, a POS device), or the fob 102 It may be determined whether 102 is about to call the RFID reader 104 for return (eg, mutual) authentication (step 518). If the fob 102 is requesting access to a merchant point at the sales terminal 110, the protocol / sequence controller 314 may instruct the RFID reader 104 to open communication with the point at the sales terminal 110. (Step 524). In particular, the protocol / sequence controller 314 may instruct the sales terminal point communication interface 312 to become active, thereby transmitting data between the RFID reader 104 and the trading point of the sales terminal 110. to enable.

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

  Although an exemplary decision process for protocol / sequence controller 314 has been described, it should be understood that a similar decision process can be taken by protocol / sequence controller 208 in controlling the components of fob 102. In fact, as described above, protocol / sequence controller 314 operates similarly to protocol / sequence controller 218 and may have a similar design. In addition to the above, the protocol / sequence controllers 208 and 314 may incorporate appropriate instructions to enable the USB interfaces 222 and 316 in the decision process, if the corresponding device is so connected. is there.

  The encryption / decryption component 318 may further communicate with a secure account number database 320 that stores the security keys necessary to decrypt the encrypted fob account number. With an appropriate request from protocol / sequence controller 314, the encryption / decryption component (eg, circuit 318) can retrieve the appropriate security key, decrypt its fob account number, and any subsequent connected POS device. The account number decrypted in an arbitrary format readable by 110 is transferred to the protocol sequence controller 314. In one exemplary embodiment, the account number may be transferred in a conventional magnetic stripe format compatible with the ISO / IEC 7813 standard. That is, according to the present invention, there is no need to convert or correlate the account number to a conventional magnetic stripe format as is done using the prior art. The present invention processes the transaction request directly as if the card associated with the account was presented for payment.

  Upon receipt of the magnetic stripe format account number, the protocol / sequence controller 314 may transfer the account number to the POS device 110 via the communication interface 312 and the data link 122 as best shown in FIG. The POS device 110 may receive the decrypted account number and transfer the magnetic stripe formatted account number to the customer network 112 for processing as normal in the business of the customer. Thus, the present invention eliminates the need for a third party server. Further, if the POS device 110 receives a response from the network 112 (eg, an authorized transaction or a rejected transaction), the protocol / sequence controller 314 may visually and / or respond to the fob 102 user. A network response may be provided to the RF module 302 for audible communication.

  The RFID reader 104 further includes a USB interface 316 that communicates with the protocol / sequence controller 314. In one embodiment, the USB interface may be an RS22 serial data interface. Alternatively, RFID reader 104 may include a serial interface, such as an RS232 interface that communicates with protocol / sequence controller 314, for example. The USB controller 316 may communicate with a personalization system 116 (shown in FIG. 1B) for initializing the RFID reader 104 to the application parameters of the system 100. That is, prior to system 100 operation, RFID reader 104 communicates with personalization system 116 to collect a list of security keys belonging to authorized fob 102 in database 310 and to collect security keys in database 320. The account number of the fob 102 in which the account number in ISO / IEC7813 format is arranged can be decrypted. In this way, the RFID reader 104 can be filled with a unique identifier (eg, a serial number) and the RFID reader 104 can determine whether the fob 102 is authorized to receive the encrypted account number. It can be used by the authentication circuit 210.

  FIG. 1B illustrates an exemplary personalization system 100B in accordance with the present invention. In general, exemplary personalization system 100B can be any system for initializing RFID reader 104 and fob 102 for use in system 100A. Referring to FIG. 1B, a similar personalization process for fob 102 may be shown. For example, the personalization system 116 may communicate with the fob 102 via the RF ISO 14443 interface 114 to collect security keys in the fob database 212 to facilitate authentication of the unique RFID reader 104 identifier. Further, in determining whether the fob 102 is authorized to the access system 100, the personalization system 116 may collect a unique fob 102 identifier on the database 212 for use by the RFID reader 104. The personalization system 116 may subsequently collect (eg, inject) the encrypted fob 102 account number in the fob database 214 for provision to the 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 that includes a hardware security module operable with any conventional graphic user interface. Prior to collecting the security key information account number and unique identification information into the fob 102 or RFID reader 104, the hardware security module authenticates the fob 102 and RFID reader 104 and authorizes the component to receive secure information. Can be verified.

  6A-6B show an exemplary flowchart of a personalization procedure that may be used to personalize the fob 102 and / or RFID reader 104. FIG. Although the following description primarily describes personalization of the fob 102, the RFID reader 104 can be personalized using a similar process. The personalization process that occurs between the personalization system 116 and the device to be personalized (eg, the fob 102 or RFID reader 104) may be initiated, for example, at step 602. Mutual authentication may occur in exactly the same manner as described above for the fob 102 that cross-authenticates with the RFID reader 104 between the personalization system 116 and the device being authenticated. That is, the personalization system 116 may send the personalization system 116 identifier to the device to be authenticated, which is compared by the device authentication circuitry 210 308 with the personalization system identifier stored in the device database 212, 310. If not (step 604), the personalization process may be abandoned (step 612). If matched (step 604), the personalization system may prepare a personalization file to be provided to the device to be personalized (step 606). If the personalization system is operated manually, the personalization file may be input to the personalization system 116 using any suitable system interface, such as a keyboard (step 606). If the operator of personalization system 116 chooses to delay the preparation of the personalization file, system 116 may abandon the personalization process (step 610). In this regard, the personalization file includes a unique fob 102 or RFID reader 104 identifier, a security key for loading into databases 212 and 310, and / or a security key for decrypting a fob account number that can be loaded into database 320. Can be included.

  The fob 102 may be personalized by connecting directly to the personalization system 116 via the RF ISO / IEC 14443 interface 114, or the fob 102 may be personalized using the RFID reader 104. The personalization system 116 and the RFID reader 104 may work together during mutual authentication, and the RFID reader 104 may be configured to send a fob personalization file to the fob 102 via RF. Once the fob 102 is presented to the RFID reader 104 for personalization (steps 608, 614), the fob 102 and the RFID reader 104 may cooperate during mutual authentication (step 614). If the fob 102 is not presented to the RFID reader 104 for personalization, the personalization process may be abandoned (step 610).

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

  The encrypted fob 102 account number may be collected in the fob 102 in the same manner as described with respect to the fob 102 unique identifier. That is, the personalization system 116 may pre-encrypt the account data (step 640) and inject the encrypted data account into the fob database 214 (step 622). Encrypted account data can be loaded (eg, injected) into the fob 102 using the RFID reader 104 as described above.

  Once the personalization file is collected in the fob 102, the collected information is irreversibly locked to avoid modification, unauthorized reading and / or unauthorized access (step 624). The personalization system 116 may then create a log of personalization file information for subsequent access and analysis by the personalization system 116 user (step 626).

  Note that if the personalization process is arbitrated or disrupted (step 628), the personalization system 116 may send a security alert to the user (step 630) and the personalization process may be abandoned (step 612). On the other hand, if there is no such arbitration or jamming, personalization system 116 may be prepared to initiate initialization on the second device to be personalized (step 632).

  FIGS. 7A-7B illustrate another exemplary embodiment of a personalization process that may be used to personalize the RFID reader 104. The RFID reader 104 may communicate with the personalization system 116 via the RFID reader USB connection 316 (step 702). Once connected, the personalization system 116 can establish communication with the RFID reader 104, which identifies the RFID reader 104 currently stored on the RFID reader 104 to the personalization system 116. Data may be provided (step 704). If RFID reader 104 is personalized for the first time according to step 708 (step 706), RFID reader 104 and personalization system 116 may cooperate in mutual authentication, as described above with respect to FIGS. 6A-6B. After the mutual authentication is complete, the personalization system 116 may verify that the RFID reader 104 is properly manufactured or configured to operate within the system 100. Verification may include evaluating the operation of RFID reader 104 by determining whether the RFID reader accepts predetermined default settings. That is, personalization system 116 may then provide a set of default settings to RFID reader 104 (step 708) and determine whether RFID reader 104 accepts these settings (step 712). If the RFID reader 104 does not accept the default settings, the personalization system 116 may abandon the personalization process (step 714).

  If the personalization system 116 determines that the personalization process is not the first personalization process performed by the RFID reader 104 (step 706), the personalization system 116 and the RFID reader 104 may have existing security already stored on the RFID reader 104. A key may be used to cooperate in the mutual authentication process (step 710). If the authentication is unsuccessful (step 712), the personalization system 116 may abandon the personalization process (step 714).

  If personalization system 116 and RFID reader 104 successfully authenticate each other, personalization system 116 may update the security key of RFID reader 104 (step 716). Updating the security key can occur at any time as determined by the manager of the system 100. This update can occur as part of routine maintenance, or simply to install current security key data. This update may be performed by downloading firmware to the RFID reader 104 (step 718). If the personalization system 116 determines in step 706 that the RFID reader 104 will cause an initial personalization, the firmware may be loaded into the RFID reader 104 for the first time. In this regard, “firmware” may include any file that allows RFID reader 102 to operate under the guidelines of system 100. For example, such guidelines may relate to the operation of the RFID reader protocol / sequence controller 314.

  The personalization system 116 then determines whether the personalization key (eg, security key, decryption key, RFID identifier) needs to be updated or whether the RFID reader 104 needs to have an initial installation of the personalization key. It can be determined (step 720). If so, personalization system 116 may download the personalization key if appropriate (step 722).

  The personalization system 116 may then determine whether the fob 102 should update or first load the identifier and corresponding security key (step 724). If no update is required, the personalization system 116 may end the personalization procedure (step 732) (step 732). In contrast, the personalization system 116 may download information to the RFID reader 104 if the fob 102 identifier and the corresponding key need to be updated or installed (step 726). Information (eg, fob security key and identifier) may be downloaded in an encrypted format, and RFID reader 104 may store the information in RFID reader database 310, if appropriate (step 728). Personalization system 116 may then create or update a status log catalog for subsequent use and analysis by the personalization system 116 user (step 730). In response to the status log update, the personalization process may end (step 732).

  It should be noted that in some instances it may be necessary to re-personalize the RFID reader in a similar manner as described above. In this example, the personalization process shown in FIGS. 7A and 7B can be repeated.

  FIG. 8 shows an exemplary flowchart for the operation of system 100A. The operation can be understood with reference to FIG. 1A, which illustrates elements of system 100A that can be used in an exemplary transaction. If the customer wants to represent the fob 102 for payment, the process begins (step 802). Upon presentation of the fob 102, the business partner initiates an RF payment procedure via the RFID reader 104 (step 804). In particular, the RFID reader transmits an interrogation signal to be scanned for presentation of the fob 102 (step 806). The RF signal may be supplied via the RFID reader antenna 106 or optionally the external antenna 108. The customer may then present the fob 102 for payment (step 808), which is activated by the supplied RF interrogation signal.

  The fob 102 and RFID reader 104 may then cooperate in mutual authentication (step 810). If mutual authentication is unsuccessful, an error message may be provided to the customer via the RFID visual and / or audible indicator (step 814) and the transaction may be abandoned (step 816). If mutual authentication is successful (step 814), the RFID reader 104 may provide the customer with a visual and / or audible message appropriate to the customer (eg, “transaction processing” or “wait”) (step 818). The fob protocol / sequence controller 208 may then retrieve the encrypted fob account number from the database 214 and provide the encrypted account number to the RFID reader 104 (step 820).

  The RFID reader 104 then decrypts the account number, converts the account number to magnetic stripe (ISO / IEC 7813) format (step 822), and provides the unencrypted account number to the customer system 130 (step). 828). In particular, the account number may be provided to the POS 110 for transfer to the customer network 112 for processing. Exemplary processing methods according to the present invention are discussed with respect to FIGS. 10-13 shown below. During processing, POS device 110 may then send a visual and / or audible transaction status message to RFID reader 104 (step 830) for communication to the customer (step 832).

  A method for processing a transaction may include one of several formats required by a fob issuer. For example, one processing method involves processing a transaction under a preloaded fob format, and payment values (eg, instantaneous values, reward point values, barter point values, etc.) allow the use of fobs. Can be preloaded into a preloaded value account or data file. In this way, the user may be able to use the fob to accumulate payments for transactions for goods and services. During transaction processing, transaction approval may include comparing the transaction amount with the amount stored (remaining) in the preloaded value data file. The comparison may be made by a preloaded value processing system, which may compare the transaction amount being processed with a data file of preloaded values. If the transaction amount exceeds the amount stored in the preloaded value account, the preloaded value processing system refuses authorization to complete the transaction and requests that the user increase the value in the data file. , Another form of payment that satisfies all or part of the transaction amount, and / or any other means for satisfying the payment of the associated financial institution may be requested. If the transaction amount does not exceed the amount stored in the preloaded value data file account, the preloaded value processing system may provide authorization for the transaction.

  An exemplary preloaded value processing system 1000 is shown with respect to FIG. The preloaded value processing system 1000 may include a fob 102 that includes a transponder 114, which transponder 114 may be connected to a trading partner system 130 via the RFID reader 104 or computer interface 134, as described with reference to FIG. 1A. Communicate with. The trading partner system may communicate with an issuer system 1010, which may be any entity (eg, non-financial or financial institution (American Express®, Visa®, and / or MasterCard®). Etc.)), and any entity can be stored in a preloaded value account (eg, a data file) maintained by the user of the fob 102 on the publisher database 1012 configured the same as the database 212. Makes it possible to store the amount of money. Issuer system 1000 may further include one or more process servers for processing fob transactions. As shown, POS device 110 (included in trading partner system 130) may communicate with issuer account server (IAS) 1014 to receive fob account information from POS device 110. The IAS 1014 may further communicate with a preloaded value authorization server (PLAS) 1016 to process a transaction that includes a preloaded value fob. PLAS 1016 may be further in communication with issuer database 1012 to retrieve funds from a preloaded value data file (not shown). The preloaded value data file is used to satisfy the preloaded fob or trading partner request. In this example, the preloaded value data file may be included on the database 1012 as one or more subfiles, for example.

  As used herein, the term “issuer” or “account provider” may refer to any entity that facilitates payment of transactions with fobs, including preloaded and unpreloaded fobs. A system that enables payment using at least one of the above may be included. Typical issuers can be, for example, American Express®, MasterCard®, Visa, Discover®, and the like. In terms of preloaded value processing, exchangeable values (eg money, reward points, barter points, etc.) are stored in the preloaded value data file for use in completing the requested transaction. obtain. In one embodiment, the exchange value is not stored on the fob itself. Further, the preloaded value data file may debit the transaction amount. Thereby, the account of the preloaded value can be corrected. As described more fully below, a preloaded value system platform can be used to complete a “direct link transaction”. In this case, the preloaded value account may act as a placeholder and store a zero value.

  The preloaded value data file may be any conventional data file structure for storing values (eg, money, reward points, barter points, etc.). This value can be exchanged for goods or services. In this regard, the preloaded value data file may have any configuration as determined or desired by the issuer system 1010.

  In an exemplary operation, fob identification information (eg, account number or fob marker) may be provided to POS device 110 in a manner similar to that described with respect to FIG. 1A. That is, the fob 102 can be presented to the trading partner system 130 via the RFID reader 104 or computer interface 134 and the fob identification information can be recognized by the track 1 or track 2 format, or by the POS device 110 and / or issuer system 1001. Can be provided in any format. The POS device 110 included in the supplier system 130 can receive the identification information of the fob 102 and issue the identification information of the fob 102 together with the transaction identification information (eg, amount, quality, supplier identification, etc.) for authorization. To the user system 1010. Trading partner system 130 may further include a trading partner system marker or identifier to indicate a trading partner system identity. The trading partner system 130 combines the fob 102 identification information, trading partner identification information, and / or trading identification information into a trading partner request for provision to the issuer system 1010.

  The IAS 1014 may receive the transaction and fob identification information (or counterparty transaction request) and properly recognize that the transaction is requested for a preloaded value account associated with the preloaded fob. That is, the IAS 1014 may recognize that the user has presented the fob 102 preloaded for payment. Recognition of the fob 102 as a preloaded fob may mean that the fob identification information includes a marker or identifier that indicates that the fob is associated with a preloaded value data file. Upon recognition of the marker, IAS 1014 may forward the transaction and fob identification information to PLAS 1016 for processing. PLAS 1016 may compare the transaction amount with the value stored or remaining in the preloaded value to determine whether authorization should be granted or denied. If the trading account exceeds the value stored in the preloaded value data file, PLAS 1016 may forward the rejected trading message to IAS 1014 for provision to trading partner system 130, and PLAS may The user may be prompted to increase the value in the data file, satisfy another form of payment to satisfy all or part of the transaction amount, and / or satisfy the current or future payment of the related financial institution Any other means for doing so may be requested. Alternatively, if the transaction amount is less than the value stored in the preloaded value data file, PLAS 1016 may deduct the amount required for transaction satisfaction from the preloaded value data file.

  As indicated above, in an exemplary embodiment of the invention, PLAS 1016 may provide a message for which a transaction has been denied to IAS 1014 for various financial security reasons. For example, if the amount stored in the preloaded value account is less than the value needed to satisfy the trading partner or fob trading request. In this example, if the preloaded value falls below a predetermined minimum level (eg, minimum decrease level), the fob user may need to reload the preloaded value data file. Reloading the preloaded value account may occur manually (eg by phone or online by a fob user), and the value stored in the preloaded value data file is reduced to a pre-defined level. May occur automatically in some cases. If the reload occurs automatically, the reload can occur under rules established by the fob issuer or owner. For example, if the stored value is less than a predetermined amount, the reload is performed at a predetermined time interval until the maximum number of reloads occurs at a predetermined time interval, or until the maximum reload amount is reached at a predetermined period. Can occur.

  In another exemplary operation, the processing system 1000 may be operated offline. For example, customer system 130 may be offline with respect to issuer system 1010. That is, the transaction may be authorized at the customer system 130 before the transaction identification information is transferred to the issuer system. Instead, the merchant system 130 may provide an authorization protocol for use in evaluating a merchant transaction request. For example, if the transaction is less than a predetermined amount, includes a specific business partner, or product or service, and is requested from a specific location, etc., the certification protocol may provide a transaction authorization. Once an offline transaction has been completed, the account may seek satisfaction of the transaction in subsequent periods by submitting the transaction to the issuer individually, under a batch or any presentation process determined by the account .

  For offline transactions, the fob 102 may include a counter (not shown) that may track the number of offline transactions. Once a predetermined number of transactions have been attempted, the counter can be used to facilitate disabling the use of the fob 102. At any point, the fob 102 user may be required to perform an online transaction, thereby resetting the counter and again allowing the fob to be used offline. As can be appreciated, requiring online usage after a predetermined number of offline usages can serve as an additional security method.

  11A and 11B illustrate an exemplary preloading and reloading process that can be performed in accordance with the present invention. The preloading and reloading process may be performed using one or more servers (eg, PLAS 1016) in communication with funding source 1104. Although the process is illustrated using PLAS 1016, it is contemplated that any server configured to establish and manage data files can be used. However, to facilitate a further understanding of the present invention, the preloading and reloading aspects of the present invention are described with respect to PLAS 1016.

  PLAS 1016 may be used to establish (1106) an account (eg, a data file) of preloaded values on a server or database (eg, database 1012). Preloaded value accounts can be funded or maintained by a fob issuer / account provider so that fees or credit cards (eg, Visa, MasterCard, American Express, Discover, etc.), debit, or direct debit A credit, fee, debit, reward value account, loyalty account, etc. may be established with an authorization (DDA) system.

  An account with a preloaded value may be established for at least a predetermined minimum preload amount or value (eg, a minimum preload level) as determined by the account provider and / or fob user or owner. In this regard, a predetermined minimum value (e.g., a minimum preload value) required to establish a preloaded value account may be changed for a particular fob user. A preloaded value account may be loaded (eg, preloaded or reloaded) from funds received from one of funding sources 1104 (American Express, Visa, MasterCard, Discover, fuel card). In addition, a preloaded value account may be loaded with a value received from a loyalty or reward point provider. To facilitate an understanding of the present invention, a loyalty or reward point provider may be referred to herein as a funding source. Accordingly, PLAS 1016 may communicate with funding source 1104 to obtain funds or values to load or reload a preloaded value account (1108).

  FIG. 11B illustrates an exemplary reload process according to the present invention. In operation, the customer may present the prepaid fob 102 for the purpose of purchasing goods or services (1110) to the trading partner system 130. The preloaded value account then reduces the amount of value paid to the trading partner system 130. The process for purchasing a product may be repeated until the value stored in the preloaded value account is below a minimum level balance (eg, a minimum reduction level). The minimum reduction level may be determined by the fob user or fob publisher and may be the minimum value that allows the file to be stored in the preloaded value account before being reloaded.

  Once the preloaded value data is consumed, the minimum depletion level is reached and PLAS 1016 can trigger an automatic reload and reload the preloaded value account from funds retrieved from funding source 1104. (1112). The amount of funds withdrawn may be sufficient to load the account with the value preloaded to the minimum amount described above or some other predetermined reload value. In one exemplary embodiment, PLAS 1016 may trigger automatic reloading that is achieved to a predetermined minimum wear level (eg, “minimum level balance”). That is, a preloaded value account cannot be totally exhausted to zero before automatic reloading occurs. In this illustration, PLAS 1016 may charge the funds required for automatic reloading against the funds available at funding source 1104. In another exemplary embodiment, automatic reloading may occur if the transaction exceeds the amount stored in the preloaded value account or the amount remaining. In this way, pre-loaded value accounts can be secured in the amount required to complete the transaction. For example, if automatic reloading stores a preloaded value account to a value appropriate for transaction completion, the preloaded value account may still be automatically reloaded to process the transaction.

  In another exemplary embodiment, automatic reloading may occur based on different user or issuer automatic reloading criteria. Other automatic reload criteria include, but are not limited to, reload until a predetermined maximum load amount is achieved for a predetermined period, or reload at a selected reoccurrence time interval (eg, once a month). It encompasses loading, permitted reloading until a predetermined maximum number of reloads is achieved in a specific period, or reloading until a predetermined maximum reload amount is achieved in a specific period. In some cases, for example, when a fob user contacts the issuer by phone or via the user interface and provides specific funding decisions and funding sources when reloading pre-reloaded value accounts, Reloading can be done manually.

  In yet another exemplary embodiment, the pre-reloaded value transaction processing system permits transaction approval if the transaction value exceeds the amount of pre-loaded value stored in the pre-loaded value account. obtain. That is, the preloaded fob is provided that the fee presented by the trading partner is less than or equal to the maximum reload amount allowed to be added to the amount stored on the card when the fee is presented Can be used for purchases that exceed the amount of value made.

  In another exemplary embodiment, the preloaded value system may approve a transaction based on a particular customer's transaction processing protocol. When the issuer reviews and / or authenticates the trading method of the trading partner, the system may take a method that considers the decision to approve the trading request of the trading partner. For example, a merchant's transaction processing method may include a merchant presenting a transaction request that exceeds the amount of preloaded values, but the actual fee may be less than or equal to the amount of preloaded values. Based on this transaction processing method, for example, a business partner such as a gasoline business partner may seek its own approval of a promising gasoline amount. In particular, when a consumer decides whether to fill an automobile's gasoline tank or purchase an item that does not require fuel, the final exact value of the purchase is neither known to the consumer nor the business partner. . Accordingly, the trading partner may present a trading request that may be higher than the final volume of the trading. The merchant may submit the transaction request in real time or later in a similar manner as described above for offline transaction request processing. In either online processing or offline processing, the preloaded value transaction processing system may be further configured to approve the transaction request. Since the approval protocol may contain information that the customer sends a transaction request that exceeds the actual fee, the processing system will use a predetermined approval protocol that the transaction comes from and correlates to that customer. It can be recognized that it is provided.

  The transaction processing system may use any one of acceptable techniques for recognizing a business partner, such as, for example, recognizing a business partner ID or a marker added to a business transaction. The processing system may correlate the merchant ID with the merchant protocol to request a greater amount of transaction approval than the preloaded value (or reloaded value), thereby approving the merchant request.

  In accordance with an alternative exemplary embodiment of the preloaded value processing system 1000, upon receiving a transaction request from the IAS 1014, the PLAS 1016 may determine a number of risks defined by the issuer for either online or offline transactions. Transaction requests can be evaluated based on criteria. If all criteria are successfully met, PLAS 1016 may then send a transaction authorization (eg, “authorized transaction”) to IAS 1014 for provision to transaction system 130. Concurrently with or subsequent to providing transaction authorization to IAS 1014, PLAS 1016 may seek transaction sufficiency from a fob value account maintained on account provider database 1012. A transaction request may be provided to the IAS 1014 for processing. That is, the IAS 1014 may determine a transaction value deduction from the balance of the amount stored in the preloaded value account.

  FIG. 12 illustrates an exemplary embodiment of another transaction processing system (“direct link” system) 1200 in accordance with the present invention. More particularly, FIG. 12 describes a direct link system 1200 that may be used to process a trading request for a trading partner. In this context, a direct link system is a fob or other presentable medium (credit card, credit card, etc.) linked directly to an account that stores exchange values (eg, money, credits, or fees, or prize points). It can be any system that uses a charge card, debit card, etc. to encourage fulfillment of a transaction request. In this case, the preloaded value account cannot be preloaded as described above. Further, preloaded value accounts can be linked to contact financial products such as credits, debits, and / or DDA cards, which can be credited for payment of goods or services. In this regard, the fob (referred to herein as “direct link fob”) and the card are associated with the same funding source, and the user or business partner can fund the fund regardless of whether the direct link fob or card is used. You can ask for the satisfaction of the transaction. In the exemplary direct link system 1200, the direct link fob 102 user may not define a pre-loaded value account with the value. Alternatively, a preloaded value account may store a zero value permanently if the account can be a credit, debit, or loyalty account, etc., or the fob 102 may be It can be associated with a fob trading account that can be used to provide payment.

  In accordance with an exemplary embodiment of the present invention, a transaction request associated with direct link fob 102 may be processed using the preloaded value transaction system process described above. However, as described, in this case, the preloaded value account is used as a placeholder to store the zero value. A trading account that includes a trading account value associated with a direct link fob is treated as a funding source to satisfy a direct link transaction. In this case, the transaction may be satisfied according to the fob user or issuer for which the protocol or criteria are predefined.

  As shown, trading partner system 130 may be in communication with issuer system 1010 for receiving trading partner trading requests. More specifically, the POS device 110 may be in communication with an issuer's server, such as, for example, an issuer account server (IAS) 1014 for receiving trading partner and / or transaction identification information. The IAS 1014 can be further in communication with the PLAS 1016 to process the trading request of the trading partner. In some cases, if one or more existing servers can perform the IAS 1202 functions described below, the second IAS 1202 may not be required, but the PLAS 1016 will be further in communication with the second IAS 1202. obtain. However, IAS 1202 is included herein to facilitate an understanding of the operation of this exemplary embodiment.

  In an exemplary operation of system 1200, a direct link fob (eg, fob identifier or account number) that identifies information may be provided in POS device 110 in a manner similar to that described in connection with FIG. 1A. That is, the direct link fob 102 may be presented to the trading partner system 130 via an RFID reader or computer interface 134 that may be provided with a direct link fob 102 that identifies information in Track1 or Track2 format. The POS device 110 included in the trading partner system 130 receives the direct link fob 102 that identifies the information, and the direct link fob 102 along with trade identification information (eg, quantity, quantity, customer identification number, etc.) for authorization. Identification information may be provided to issuer system 1010.

  The IAS 1014 receives the transaction and fob identification information and recognizes that the requested transaction is associated with the direct link fob 102. Recognition of the direct link fob 102 in this case may mean that the direct link fob 102 identification information includes a marker or identifier that indicates that the fob is associated with a pre-loaded value account of zero value. Upon recognition of the marker, IAS 1014 may forward the transaction and fob identification information to PLAS 1016 for processing.

  In a manner similar to that described in connection with the operation of the preloaded value processing system of FIG. 10, PLAS 1016 may evaluate the transaction request based on a number of risk criteria defined by the issuer. Exemplary risk criteria include, but are not limited to, trading volume limits for a specific period, fob user usage history, funding or funding limits, predetermined funding rules, user-defined limits, or any similar criteria Can be included. If all criteria are successfully met, PLAS 1016 may send a transaction authorization (eg, transaction authorization) to IAS 1014 for provision to trading partner system 130. Transaction authorization may be provided to counterparty system 130 based on risk criteria evaluation and not based on values contained in a direct link trading account or a preloaded value account that stores values related to direct link fobs. .

  After providing transaction authorization to IAS 1014, PLAS 1016 may authorize the transaction for a direct link fob account (eg, a trading account) held in issuer database 1012 and stored by a value received from funding source 1104. Can ask for. An authorization request may be provided to the IAS 1202 for authorization that may retrieve the required value from the direct link fob account. For example, if the direct link fob account is a fee or credit account, the PLAS 1016 may request authorization from the second IAS 1202 and the IAS 1202 may estimate the transaction volume for the direct link fob account on the database 1012. The IAS 1202 may require a record of the amount of transactions in the direct link fob usage history data file for payment at the end of the billing cycle (eg, fee account), or the amount may be less than the end of the billing cycle. It may be recorded in a fob direct link fob usage data file (eg, a credit account) for later payment.

  In an alternative operation, PLAS 1016 may estimate the transaction volume for the direct link fob account without using the second IAS 1202. It should be understood that whether a transaction is processed using the second IAS 1202, the value cannot be immediately transferred from the direct link fob account to the trading system to satisfy the transaction. Instead, the issuer of the direct link fob may guarantee the satisfaction of the counterparty's transaction, for example, by a request until the reference value is retrieved from the direct link fob account at the end of the billing cycle or thereafter. That is, PLAS 1016 cannot retrieve the value necessary to satisfy the transaction until the business partner has provided a settlement request to the issuer system, but may provide transaction authorization.

  In yet another example transaction processing system 1300 shown in FIG. 13, the trading partner system 130 is processed by the process server 1302 when multiple fob transactions include both preloaded values and direct link transaction requests. Can provide a batch file containing multiple fob transactions. System 1300 can include a processing server 1302 that distinguishes between preloaded values and direct link transaction requests. That is, the processing server 1302 can be used to separate fob transactions associated with a preloaded fob account and fob transactions not associated with a preloaded fob account, as described more fully below. Processing server 1302 may be further in communication with IAS 1014 to seek transaction settlement. The IAS 1014 may process the transaction request according to the preloaded value trading platform or direct link transaction processing described above.

  In an exemplary operation of system 1300, processing server 1302 may receive a payment file and identify the file according to the type of transaction request. For example, the processing server 1302 may place a marker on the received file to make transactions related to the type of fob used for the transaction (eg, preloaded fob and direct link fob associated with a fee or credit account). A request subfile may be generated. The process server may generate a subfile associated with the file marker. The processing server 1302 may generate a first fob transaction file for the customer's debt and a second fob transaction file for the receivable account that is transferred to the IAS 1014 for processing. If the subfile includes the customer's debt, the processing server 1302 may fund the customer for payment of the transaction. Here, the funds provided can be equivalent to the transaction volume minus the discounted revenue. Funds may be taken from a funding source for providing to a trading partner. Alternatively, the processing server 1302 may generate a second fob transaction file for receivable payment of the account and transfer the second fob transaction file to the IAS 1014. The IAS 1014 may then process the transaction request by the process described in FIGS. That is, the IAS 1014 can distinguish between preloaded fob transaction requests and requests related to direct link fobs and, as a result, process the transaction.

In view of the operation of the various transaction processing systems described above, the transaction processing system described can be used when a preloaded fob is used, when a card associated with the fob is used, or when a preloaded fob is used. It can be seen that it can be distinguished whether the associated account is reloaded. In that regard, the present invention can be used for reward points that depend on the characteristics of fob usage. Points (eg, loyalty points) may be stored in a point account or reward account held in an issuer database (eg, database 1012). The reward points can then be redeemed later from the reward account for the exchange of goods and services as desired by the user of the fob. For further information on loyalty systems and trading systems, see, for example, US patent application Ser. No. 09 / 836,213, filed April 17, 2001 by the inventor Voltmer et al., Named System And Method For Narrowed Royalty Program. No. 10 / 027,984, filed Dec. 20, 2001, filed Dec. 20, 2001 by the inventor, Ariff et al., And filed Nov. 6, 2001 by the inventor Haines et al. United States Partial Application No. 10 / 010,947 entitled System And Method For Networked Loyalty Program September 5, 2000 is the Shop ^AMEX TM system, No. 60 / 197,296 No., filed April 14, 2000 according to No. 60 / 230,190, filed April 28, 2000 No. 60 / 200,492 filed on May 2, MR as Currency ^TM and loyalty rewards systems described in No. 60 / 201,114 filed May 2, 2000, filed Feb. 1, 1999 Facilitated transactions using the stored value card described in 09 / 241,188, the number of secondary transactions described in 09 / 800,461 filed on March 7, 2001 System and related provisional application 60 / 187,620 filed March 7, 2000, April 2000 No. 60 / 200,625 No., filed 8 days, and with reference to No. 60 / 213,323, filed May 22, 2000, incorporated all of these reference herein. Other examples of online membership reward systems include Netcentives US Pat. No. 5,774,870, published June 30, 1998, and US Pat. No. 6,009, issued December 29, 1999. , 412, both of which are incorporated herein by reference.

  As mentioned, in one example, points can be provided not only when the card associated with the fob is used, but also when the fob is used. For example, the IAS 1014 may recognize that the fob is being used, giving points (eg, loyalty points) to a reward account assigned to or associated with the fob user. Loyalty points can be awarded based on any criteria as determined by the fob issuer. Exemplary reward criteria include, for example, fob usage, individual purchases using the fob, total purchases over a given time period, customer location, customer type, or any fob to trigger fob usage Such reference reward points may be included.

  If the fob is associated with, for example, a preloaded value account as described with respect to FIG. 10, points may be awarded for account reloading. That is, the IAS 1014 may determine the reward account privilege points for the amount loaded or reloaded on demand. Further, the IAS 1014 may determine reward points in a reward account for fob usage at a particular business partner or fob usage for a particular transaction.

  A trading account associated with the fob 102 may include usage restrictions such as, for example, per purchase spending limit, hourly usage, weekly usage, and / or usage of a particular account. Here, further verification is required when using fobs outside of the limits. Limits may be assigned individually to fob 102 users or account providers. For example, in one exemplary embodiment, an account is established and purchases that exceed $ X (ie, spending limits) need to be verified by the consumer. Such verification is correlated with an appropriate personal identification number (PIN) that can be recognized by a payment authorization center (not shown), such as is specific to the fob 102 or fob 102 holder (eg, customer). It may be provided using the fob 102 trading account number. If the requested purchase exceeds the spending limit established for each purchase, the consumer is required to provide, for example, a PIN, biometric sample, and / or similar secondary verification and Can be completed. That is, for example, the fob 102 may enter a unique PIN on a conventional keypad in the trading partner system 130 or RFID reader 104. The PIN can be provided to the authorization center for comparison with the relevant PIN stored in the issuer system. Alternatively, the PIN can be provided to the fob 102 via the RFID reader 104. The fob 102 may verify the PIN by comparing this PIN with, for example, an associated PIN stored in the secure memory 212.

  If the verification PIN is used as a secondary verification, the verification PIN may be checked for accuracy against a secure PIN associated with the fob 102 trading account number. The secure PIN can be stored locally (eg, on the fob 102) or stored in a database (1012) at the payment authorization center. The payment authorization center database may be any database 1012 maintained and operated by the fob 102 trading account provider.

  The verification PIN is POSed using a conventional business partner (eg, POS) PIN keypad 118 that is in communication with the POS device 110 or an RFID keypad that is in communication with the RFID reader 104 as shown in FIG. Device 110 may be provided. The PIN keypad may be in communication with the POS device 110 (or RFID reader 104) using any conventional data link described above. Upon receipt of the verification PIN, RFID reader 104 may determine a positive PIN and PIN match stored in RFID reader 104 in database 310 or 320. Alternatively, a verification PIN may be provided to the payment authorization center to determine if the PIN matches a PIN stored in the payment authorization center database associated with the fob 102 account. If there is a match, the purchase can no longer be restricted and the transaction can be allowed to complete.

  In an alternative embodiment, verification of purchases that exceed established spending limits may include biometric circuitry included in fob 102. FIG. 9 is a schematic diagram of an exemplary fob 102 that includes a biometric security system 902. Biometric security system 902 can include a biometric sensor 904 for detecting a fingerprint of a user of fob 102. The biometric sensor 902 can be in communication with the sensor interface / driver 906 to receive the sensor's fingerprint and to activate the operation of the fob 102. Biometric sensor 904 and sensor interface 906 may be in communication with a battery 903 that provides the necessary power for operation of the biometric security system component.

  In one exemplary application of a fob 102 that includes a biometric security system 902, a customer places a customer's finger on a biometric sensor and initiates a mutual authentication process between the fob 102 and the RFID reader 104. Or provide secondary verification of the user's identity. The sensor fingerprint may be digitized and compared to a digitized fingerprint stored in a database (eg, secure database 212) included in the fob 102. Such a comparison step can be controlled by the protocol / sequence controller 208 and verified by the authentication circuit 210. If such verification is made, mutual authentication between the fob 102 and the RFID reader 104 can be initiated, and thus the transaction can proceed. Alternatively, the comparison can be made using digitized fingerprints stored in a database maintained by fob 102's trading account provider system (not shown). The digitized fingerprint can be verified in a manner similar to that described above for PIN.

  In one exemplary application of a fob 102 that includes a biometric security system 902, the system 902 can be used to authorize purchases that exceed established per-purchase spending limits. In this case, if the customer's intended purchase exceeds the spending limit, the customer may be required to provide a guarantee that the purchase has been authorized. Thus, the customer may provide such verification by placing the customer's finger on the biometric sensor 904. Biometric sensor 904 may then digitize the fingerprint and provide a digitized fingerprint for verification as described above. Once verified, the fob 102 may provide an authorized signal for the transaction to the RF transponder 202 (or to the transponder 220) for transfer to the RFID reader 104. The RFID reader 1014 may then provide an authorized signal for transaction to the POS device 110 in a manner similar to that performed using a conventional PIN drive system, and the POS device 110 may Transactions can be processed based on business.

  In another exemplary embodiment of the present invention, fob users are provided limited access to fob user data files maintained in the issuer system to manage fob usage and fob user information. Users can access via phone, online, or offline. The fob user may, for example, have demographic information (eg, fob user address, phone number, email address, etc.), funding sources associated with the fob (eg, credit account, fee account, reward account, barter account, etc.) ) To access the fob user data file to view the transaction history. Further, the fob user may be allowed to load or reload the account or modify automatic reload parameters (eg, amount to reload, duration for reloading, etc.). If more than one fob 102 is associated with a trading account, the user may be provided with similar access to the data file corresponding to the additional fob.

  Referring to FIG. 1A, a fob user may connect the computer interface 134 and the fob 102 via the USB interface 132. The fob user may then access the fob user data file over the network 136 using the computer interface 134. In particular, the network 136 may be in communication with an issuer system (eg, system 1010 of FIG. 10) and limited access may be provided to an issuer server (eg, server 1014) to manage fobs. The issuer server 1014 may be in communication with an issuer system database (eg, 1012) that stores information to be managed in connection with the user data file of the user's fob. Changes made to the fob user data file by the fob user can be made in real time, after a short delay, or after a longer delay. In one example, the changes may be stored in a batch change file on the issuer database for later batch processing.

  The foregoing detailed description of exemplary embodiments of the invention has been made in connection with the accompanying drawings, which are shown in the exemplary embodiments for purposes of illustration. While these exemplary embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, other embodiments may be implemented and logical and mechanical changes may be made to the invention. It should be understood that this can be done without departing from the spirit and scope of the invention. For example, the steps recited in any method or process claims may be performed in any order and are not limited to the order presented. Further, the present invention can be implemented using one or more servers, if necessary. Thus, the foregoing detailed description may be presented for purposes of illustration only and not limitation, the scope of the present invention being defined with respect to the foregoing description and the appended claims.

Claims (21)

A transponder device,
With a transponder,
The transponder device authentication signal received from the reader is encrypted using a transponder device authentication key to generate an encrypted transponder device authentication signal, and further the encrypted reader authentication received from the reader An encryption circuit configured to decrypt the signal using a reader authentication key to generate a decrypted reader authentication signal;
A protocol / sequence controller configured to send the encrypted transponder device authentication signal to the reader via the transponder ;
An authentication circuit configured to authenticate the reader in response to the decrypted reader authentication signal that matches a reader authentication signal transmitted from the transponder device to the reader ;
The protocol / sequence controller further transmits an account code to the reader via the transponder to proceed with a payment transaction in response to the decrypted reader authentication signal that matches the reader authentication signal. Configured,
The account code is configured to identify at least one of a preloaded value account and a trading account, and is configured to be changeable via the transponder;
Transponder device.   The transponder device according to claim 1, wherein the transponder device authentication key and the reader authentication key are the same key. It said encryption circuit further encrypts the account code with the account code key is configured to generate an account code encrypted,
The protocol / sequence controller further transmits the encrypted account code to the reader, configured to proceed the payment transaction,
The transponder device according to claim 1.   The transponder device of claim 1, further comprising a switch configured to activate a transponder device communication interface in response to the decrypted reader authentication signal that matches the reader authentication signal.   The transponder device according to claim 3, wherein at least one of the transponder device authentication key, the reader authentication key, and the account code key is a security key unique to at least one of the transponder device and the reader.   The transponder device according to claim 3, wherein the transponder device authentication key, the reader authentication key, and the account code key are the same key.   The transponder device according to claim 3, wherein the account code key is the same key as at least one of the transponder device authentication key and the reader authentication key.   The transponder device according to claim 3, wherein the reader authentication key is the same key as at least one of the transponder device authentication key and the account code key. The transponder comprises a first transponder that is configured to receive a first radio frequency (RF) interrogation signal from the reader, the transponder device of claim 1. The transponder further comprises a second transponder configured to receive the first 2RF interrogation signal from the reader, the transponder device of claim 9.   The transponder device of claim 10, wherein the authentication circuit is further configured to communicate with at least one of the first transponder and the second transponder.   The protocol / sequence controller is further configured to communicate with at least one of the first transponder, the second transponder, the authentication circuit, and a transponder device universal serial bus (USB) interface; The transponder device of claim 11, configured to activate the authentication circuit in response to at least one of the first RF interrogation signal and the second RF interrogation signal.   The apparatus further comprises at least one of a first transponder antenna and a second transponder antenna, wherein the first transponder antenna is configured to receive the first RF interrogation signal, and the second transponder antenna is the second RF interrogation. The transponder device of claim 10, configured to receive a signal.   The transponder device according to claim 3, wherein the account code is in a magnetic stripe format.   The transponder device of claim 1, further comprising a switch configured to enable and / or disable the transponder device.   The transponder device of claim 15, wherein the switch is configured to place the transponder device in at least one of a selective mode and a generic mode.   The transponder device of claim 15, wherein the switch is a biometric switch configured to enable and / or disable the transponder device.   The transponder device of claim 3, further comprising a personalization system configured to personalize at least one of the transponder device authentication key, the reader authentication key, the account code key, the account code, and a transponder device database. A computer-readable medium having instructions stored thereon, wherein when the instructions are executed by a transponder device having a transponder , the transponder device
Encrypting the transponder device authentication signal received from the reader using a transponder device authentication key to generate an encrypted transponder device authentication signal;
Sending the encrypted transponder device authentication signal to the reader via the transponder for authentication of the transponder device by the reader;
Decrypting the encrypted reader authentication signal received from the reader using a reader authentication key to generate a decrypted reader authentication signal;
Authenticating the reader in response to the decrypted reader authentication signal that matches a reader authentication signal transmitted from the transponder device to the reader;
In response to the decrypted reader authentication signal matching the reader authentication signal, sending an account code to the reader via the transponder to advance a payment transaction;
To perform operations including,
The account code is configured to identify at least one of a preloaded value account and a trading account, and is configured to be changeable via the transponder;
Computer readable medium.   The transponder device of claim 1, further comprising a circuit including a biometric sensor configured to identify an authorization to enable a function of the authentication circuit. 21. The transponder device of claim 20 , wherein the circuit including the biometric sensor is further configured to identify authorized transactions that exceed a set limit.

Images