KR20040028939A - System and method for incenting payment using radio frequency identification in contact and contactless transactions - Google Patents

Abstract

The transponder payment system includes a fob that includes a transponder and an RFID reader that calls the transponder. The payment system may further comprise a payment device separate from the fob, but associated with a payment account shared with the fob. In a typical operation, the fob identification or payment device information may be provided to an RFID reader to complete a transaction request. The process server may receive the transaction request and satisfy the transaction request according to a predetermined payment criterion. In addition, the process server may encourage use of the fob as an example and encourage use of the payment device as an example by increasing the reward account based on the use of the fob or payment device.

Description

Payment incentive system and method using wireless identification of contact and contactless transaction {SYSTEM AND METHOD FOR INCENTING PAYMENT USING RADIO FREQUENCY IDENTIFICATION IN CONTACT AND CONTACTLESS TRANSACTIONS}

Like barcode and voice data input, RFID system is a non-contact information acquisition technology. RFID systems are wireless and are very effective in hostile environments where conventional acquisition methods usually fail. RFID has been established in a wide range of markets, for example high-speed reading of railroad containers, tracking of moving objects such as livestock or cars, and retailing of inventory. As such, RFID technology has been a primary focus throughout automated data collection, identification and analysis systems.

Recently, companies are increasingly incorporating RFID data acquisition technology into fobs and tags for use in completing financial transactions. A typical fob is a normal self-contained device that includes a transponder and can be included in any portable form of element. In some cases, a battery may be included with the fob to power the transponder. In other cases, the internal circuitry of the fob (including transponders) may draw operating power from battery power. Alternatively, the fob can be present independently of the internal power source. In this case, the internal circuit of the fob (including the transponder) can obtain its operating power directly from the RF call signal. U. S. Patent No. 5,053, 774 to Schurmann describes a typical transponder RF calling system that can be found in the prior art. The Schermann patent generally describes a technique for powering the periphery of conventional transponder structures. U.S. Patent No. 4,739,328 describes how a conventional transponder can respond to an RF call signal. Other typical modulation techniques that may be used may include, for example, ISO / IEC 14443 and the like.

In the conventional fob powering technique used, the fob is normally activated when it is provided to the fob as a call signal. In this regard, the fob can be activated regardless of whether the user wants such activation. Unintended provision of an unwanted transaction may begin and complete. Thus, the fob system needs to allow the fob user to control the activation of the fob to limit the unwanted completion of the transaction.

One of the more visible uses of the RFID technology is found in the introduction of Exxon / paths of the mobile speed (Exxon / Mobil's Seedpass ^ⓡ) and not pay (Shell's EasyPay ^ⓡ) of the shell product. These products use transponders located within the fob or tag, which enables the user to automatically identify when the fob is provided to a Point of Sale (POS) device. Forbe identification data is typically sent to a third party's server database where the identification data is referred to as the customer's (eg, user's) credit account or debit account. In a typical process, the server seeks to authenticate the transaction by sending the transaction and account data to an authorizing entity. Once authentication is received by the server, a clearance is sent to the POS device to complete the transaction. In this way, the conventional transaction processing method includes an indirect path, which incurs excessive overhead due to the use of a third party server.

There is a need for a transaction authentication system to authenticate for Forbe transactions while eliminating the costs associated with using third party servers.

In addition, conventional fobs have limitations in that they must be used in close proximity to the POS device. That is, in order to activate the fob, the conventional fob must be located in the transmission area of the RF call signal. More specifically, conventional fobs are not affected by use in situations where a user wishes to trade in an interaction such as a computer interface.

Thus, there is a need for a fob that can implement RFID acquisition technology that can be used in interaction devices and additionally facilitates transactions via a computer interface connected to a network (eg, the Internet).

Existing transponder-reader payment systems are also limited in that the conventional fobs used within the system only respond to one call signal. If multiple call signals are used, the fob responds only to the call signals it constitutes. Therefore, if the RFID reader of this system only supplies a call signal that is not compatible with the fob, the fob will not activate properly.

Therefore, there is a need for the presence of a fob in response to one or more paging signals.

Existing transponder-reader payment systems have additional limitations in that they are typically linked to a funding source associated with a transponder that includes a predetermined spending limit. Therefore, it is not possible to apply flexibly when payments exceeding a predetermined spending limit are required. This is usually true in that traditional methods for processing the required transactions involve comparing the transaction with the spending limit or the amount stored in the preload value data file before providing the transaction authorization to the merchant.

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

Moreover, traditional transponder-reader systems do not allow users to manage system user account data. This means that if the user wants to change the transponder-reader system funding source to a funding source that provides more free spending, or if the transponder-reader account provider wants to easily renew his account, the user's status changes. If you want to do so (for example, change your address, change your phone number, change your e-mail, etc.), this is a significant problem.

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

Furthermore, existing transponder-reader systems usually do not allow a means to automatically encourage the use of a fob associated with the system as opposed to a credit or charge card associated with the fob. That is, conventional transponder-reader systems encourage transponder-readers by encouraging the use of Forbes products because current systems do not sufficiently distinguish between the use of system transponders and the charge or credit card accounts associated with them. It does not provide a means to encourage the use of the system.

As a result, there is a need for a transponder-reader system that can determine when a system transponder is used and can provide incentives for such use.

In addition, the current system is still limited in that the system cannot use credit cards or charge cards for a single funding source and can not use fobs. For example, in a typical conventional system, the fob can be linked to a particular funding source (eg, American Express, MasterCard, Visa, etc.), which can be used to provide funds for the satisfaction of the transaction request. This funding source can also be associated with a fob and has a consumer credit or charge card that can be used for contact transactions. If a credit or charge card is used, a bill is reported to the cardholder that reports card use. However, this statement does not include reporting of Forbes product use. Therefore, Forbes users cannot chart, analyze, or compare the use of related cards and the use of Forbes properly. This is especially a problem when funding sources are used for more than one entity (eg couples, employees of multiple companies, etc.) or where one entity can use a fob and each entity can use a card associated with the fob. It becomes

Thus there is a need for a transponder-reader payment system that can report the use of fobs and credit card usage in one file.

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

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, in which like reference numerals designate like elements, illustrate exemplary embodiments of the invention and together with the description serve to explain the principles of the invention. In the drawing,

1A illustrates a typical RFID basic system in accordance with the present invention, illustrating typical components used to complete a fob transaction.

1b shows an exemplary individualization system according to the invention.

2 is a schematic diagram illustrating an exemplary fob according to the present invention.

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

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

5 is a flow diagram of an exemplary decision process for a protocol / sequence controller according to the present invention.

6A and 6B are flow charts of an exemplary fob individualization process in accordance with the present invention.

7A and 7B are flow charts of an exemplary RFID reader personalization process in accordance with the present invention.

8 is a flow diagram of an exemplary payment / transaction process in accordance with the present invention.

9 is a schematic representation of another exemplary fob in accordance with the present invention;

10 is an explanatory diagram of an exemplary preloaded fob payment / transaction process in accordance with the present invention.

11A and 11B illustrate an exemplary preloaded Forb account reeled process in accordance with the present invention.

12 is an illustration of an exemplary direct link payment / transaction process in accordance with the present invention.

Figure 13 is an illustration of another exemplary payment / transaction process in accordance with the present invention.

This section describes a system and method using RFID technology to initiate and complete a financial transaction. The transponder-reader payment system described herein may include an RFID reader, which powers the transponder system, receives the transponder system RF signal, and transmits a transponder associated with the transponder system RF signal. It is operable to provide an RF call signal for providing the fender system accounting data. The transponder-reader payment system includes an RFID protocol / sequence controller in electrical communication with one or more interrogators for supplying a call signal to the transponder, an RFID authentication circuit for authenticating signals received from the transponder, and an interaction device. Serial or parallel interface for interfacing with a USB, and USB or serial interface for use in personalizing an RFID reader and / or transponder. The transponder-reader payment system may respond to one or more call signals to provide one or more transponders (e.g., to provide an authentication signal confirming that the transponder and / or RFID reader is authorized to operate within the transponder-reader payment system). For example, the module may further include a fob including a module). As such, the fob can respond to multiple call signals provided at different frequencies. The fob can also 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 implemented in a fob, tag, card or any other type of element (e.g., watch, key pack, cellular phone, etc.) and may be provided for calling. It may include a fender. In this regard, although the transponder is mentioned as being implemented in the fob, the present invention is not limited thereto.

The RFID system may further include an RFID reader. The RFID reader is configured to transmit an RFID recognition signal that can be transmitted via radio (or electromagnetic) radio waves from the RFID reader. The fob can be placed in proximity to the RFID reader so that the RFID signal can invoke the fob and initiate the fob identification procedure.

In one exemplary embodiment, as part of the identification process, the fob and the RFID reader may be combined by mutual authentication. The RFID reader may identify the fob as including an authentication system transponder that receives the encrypted information and stores the information in the fob memory. Similarly, when there is a call by RFID, the fob can identify the RFID reader as being authorized to receive encrypted and stored information. If the fob is successfully mutually authenticated with the RFID reader, the fob can send specific information identifying the trading account or the fob related account to the RFID reader. The RFID reader receives the information and sends it to facilitate the completion of the transaction. In one exemplary embodiment, the RFID reader may transmit the information to an interaction device (eg, a POS or computer interface) for completing a transaction. The mutual authentication process described herein helps to ensure the security of the Forbes Transponder-Reader Payment System.

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

In another exemplary embodiment of the present invention, a system is provided that encourages the use of a transponder (eg, a fob) of a transponder-reader system. The system distinguishes between using a fob and using a charge or credit card that shares the same funding source as the fob. If a fob is used, the system may provide incentives to the user based on criteria predetermined by the fove issuer. In addition, when a preloaded fob system is used, the present invention recognizes when the data file of the preloaded value of the relevant fob was loaded or reloaded with the funding source. The invention may award reward points according to criteria associated with loading or reloading behavior. In addition, the system according to the present invention can give incentives to regular customers of merchants. In this case, the system may receive a Forbe transaction request and incentivize a Forbe user based on a marker or other identifier associated with the merchant. The marker may be included in the transaction identification, the merchant identification provided by the transaction, or both.

In another exemplary embodiment of the present invention, a system is provided for a fob user / owner to manage an account associated with a fob. The user restricts access to all or part of Forbes account information stored in the account provider database, for example, to update statistical information, account funding sources and / or account restrictions (e.g. spending limits, personal identification numbers, etc.). can do. Access to all or part of an account may be provided to the user via telephone, network (eg, online) or offline communication. For example, a Forbe user may provide access to a system that may be in delayed communication with an account provider database, where such a system may, for example, create a kiosk capable of batch transmissions to an account provider system. It may include. In this way, the Forbe user / owner can update his account information in real time (eg, by phone or online) or when the account provider receives the updated information (eg, offline).

In another exemplary embodiment, the present invention provides a method for processing a transaction request. By doing so, the amount of the transaction request can be approved before requesting funds from the funding source and / or confirming that the amount to complete the transaction can be used. In this way, a transaction can be approved if the transaction and / or account meet certain predetermined certification criteria. Once the criteria are met, the transaction is authenticated and authentication is provided to the requesting broker (eg merchant). In one example payment for a transaction is requested from the funding source at the same time or immediately after, and authentication is provided to the merchant. In another example, payment for a transaction is requested at a later time than authentication is provided to the merchant.

The structure and operation of the various exemplary embodiments as well as the above-described features and other advantages of this system and method are described below.

The invention can be described in terms of components of the functional block, screenshots, any selection, and various processing steps. Such functional blocks may be realized by any number of hardware and / or software configurations that are configured to perform specific functions. For example, the present invention may utilize various integrated circuit components. That is, the present invention can use various integrated circuit components that can execute various functions under one or more microprocessors or other control devices, for example, memory devices, processing devices, logic devices, lookup tables, and the like. Similarly, the software components of the present invention are C, C ++, Java, COBOL, assembler, PERL, and EX, with various algorithms executed in combination with data structures, objects, processes, routines or other program elements. It can be executed in programming languages such as eXtensible Markable Language (XML), Java Card, and MULTOS and scripting languages. It should also be noted that the present invention may utilize prior art such as data transmission, signaling, data processing, network control, and the like. "Application of Encryption: Protocols, Algorithms, and C's Source Code (Applied Cryptography), written by Bruce Schneier for a basic introduction to encryption and published by John Wiley & Sons. Protocols, Algorithms, and Source Code in C) "(2nd edition, 1996). This content is incorporated herein by reference.

In addition, many applications of the present invention can be devised. Typical networks disclosed herein may include any system for data exchange or commerce, such as the Internet, intranets, extranets, WANs, LANs, satellite communications, and the like. It should be noted that this network may be implemented as another kind of network, such as an Interactive Television Network (ITN).

If required, the system user keypad, keyboard, mouse, kiosk, PDA, hand-held computers can be (for example, Palm Pilot ^ⓡ, Blueberry ^ⓡ), systems and inreo Rotaract through any input device such as a cellular phone. Similarly, the present invention relates to any type of personal computer, network computer, operating on any version of the operating system such as Windows, Windows NT, Windows 2000, Windows 98, Windows 95, Mac OS, OS / 2, BeOS, Linux, Unix, Solaris, It can also be used in connection with workstations, minicomputers, mainframes, and the like. It is also to be understood that the present invention may also be practiced using SNA, IPX, Appletalk, IPte, NetBIOS or any other communication protocol, although the invention has been frequently described as being implemented as a TCP / IP communication protocol. Moreover, the system contemplates using, selling, or distributing any product, service or information over any network having similar functionality described herein.

1A illustrates an exemplary RFID trading system 100A in accordance with the present invention. 1 illustrates typical components used to complete a fob transaction. In general, operation of system 100A may begin when fob 102 is provided for payment and is called by RFID reader 104 or interface 134. The fob 102 and the RFID 104 may be combined by mutual authentication after the transponder 114 provides the transponder identification and / or account identifier to the RFID reader 104. The RFID reader 104 may also provide the supplied information to the POS device 110 of the merchant system 130.

System 100A may include a fob 102 having a transponder 114 and an RFID reader 104 in RF communication with the fob 102. Although the present invention has been described in connection with the fob 102, the present invention is not limited thereto. In fact, system 100A may include any device having a transponder configured to communicate with RFID reader 104 via RF communication. Typical devices may include, for example, key rings, tags, cards, cellular phones, wrist watches or any form that may be provided for calling.

The RFID reader 104 may be configured to communicate using the RFID internal antenna 106. Alternatively, the RFID reader 104 may include an external antenna 108 for communicating with the fob 102. This external antenna 108 can be made apart from the RFID reader 104 using suitable cables and / or datalinks 120. The RFID reader 104 may communicate with the merchant system 130 via the data link 122. System 100A may comprise a transaction completion system including an interaction device, such as, for example, a point of business of point of sale device 110 or computer interface (eg, user interface) 134. In an exemplary embodiment, a transaction completion system may include a merchant system 130 that includes a POS device 110 that communicates with an RFID reader 104 (via data link 122). As described in more detail below, the transaction completion system may include a user interface 134 connected to the network 136 and to the transponder 114 via the USB connector 132.

Although the point of the interaction device has been described herein in connection with the merchant's POS device, the invention is not limited thereto. In fact, the merchant POS device is used here as an example, and the interaction device may be any device capable of receiving Forbes account data. In this regard, the POS device may be any interaction device that allows a user to complete a transaction using the fob 102. The POS device 110 may communicate (via data link 128) with a customer interface 118 for entering at least customer identification authentication information. The POS device 110 may also communicate (via the data link 124) with the merchant's host network 112 to process any transaction request. In this configuration, the information provided by the RFID reader 104 is provided to the POS device 110 of the merchant system 130 via the data link 122. The POS device 110 may receive the information and provide the information to the host system 112 for processing (in contrast, receiving identification information from the customer interface 118 via the data link 128). You can).

Various conventional communication media and protocols may be used for the data links 120, 122, 124, 128. For example, data links 120, 122, 124, and 128 are local loops when commonly used in connection with standard modem communications, cable modems, satellite networks, ISDN, Digital Subscriber Lines (DSL), or other wireless communications media. It may be an Internet Service Provider (ISP) configured to facilitate communication via. Merchant system 130, including POS device 110 and host network 112, may also be located on a LAN that interfaces to a remote network (not shown) for remote authentication of the intended transaction. Merchant system 130 may communicate with the remote network via leased lines, such as T1, D3 lines, and the like. Such lines of communication are described in documents such as "Understanding Data Communication" by Gilbert Held, which is incorporated herein by reference.

Account numbers as used herein may be maintained by a trading account provider (e.g., a payment verification center) and may be used to complete a financial transaction (e.g., credit, charge debit). ), Checks, savings, rewards, loyalty, etc.). Typical account numbers (e.g., account data) are credit or debit accounts, royalty accounts, or reward accounts maintained and serviced by entities such as American Express, Visa, and / or MasterCard. Can be correlated with To facilitate understanding, the present invention will be described with reference to a credit account. It should be noted, however, that the present invention is not limited thereto and that other accounts allowing for the exchange of goods and services for account data values may be considered within the scope of the present invention.

In addition, the account number (e.g., account data) may be any device, code, or authentication / access code, personal identification number (PIN) that is properly configured to allow a customer to interact or communicate with the system. ), Other identifiers / indicia such as internet codes, digital certificates, biometric data, and / or other identifications. The account number may optionally be located on a reward card, charge card, credit card, debit card, prepaid card, phone card, smart card, magnetic strip card, barcode card. The account number may be distributed and stored in any form, such as plastic, electronic, magnetic, and / or optical devices, which may transmit or download data to a second device. The customer account number may be, for example, a 16 digit credit card number, although each credit card provider has its own numbering system, such as American Express using the system from a 15 digit number. Each company's credit card number matches the company's standardized format so that companies using the 16-digit format typically use four sets of numbers, such as marking the numbers "0000 0000 0000 0000". In a typical example, the first five to seven digits are reserved for processing purposes and identify the issuing bank, card type, and the like. In this example, the last 16th digit is used as the sum to check the 16 digits. The middle 8 to 10 digits are used to identify the customer. As defined in ISO / IEC 7813, account numbers are stored as track 1 and track 2 data and can be made unique to the fob 102. In a typical embodiment, the account number may include a unique fob serial number and user identification as well as a particular application applet. This account number may be stored in the fob 102 inside the database 214 as described in more detail below. Database 214 may be configured to store multiple account numbers issued to users of Forbes 102 by the same or different accounting agencies. If the account data corresponds to a loyalty or reward account, the database 214 may be configured to store member loyalty or reward point data.

2 is a block diagram illustrating the functional blocks of a typical fob 102 in accordance with the present invention. The fob 102 may be an RFID fob 102 that may be provided by a user to facilitate exchanging funds or points for receipt of goods or services. As mentioned herein, for example, the fob 102 may be an RFID fob that may be provided to facilitate payment for goods and / or services.

The fob 102 may include an antenna 202 that receives a call signal from the RFID reader 104 via an antenna 106 (or an external antenna 108). The fob antenna 202 can communicate with the transponder 114. In one exemplary embodiment the transponder 114 may be 13.56 MHz conforming to the ISO / IEC 14443 standard, and the antenna 202 may vary by 13 MHz. The transponder 114 is configured to receive a signal from the transponder 114 and is compatible with a modulator / demodulator 206 configured to modulate the received signal into a format readable by circuitry that is later connected. Communicate with the transponder. The modulator / demodulator 206 is also configured to format a signal received from a circuit that is later connected, in a format compatible with the transponder 114, for transmission via the antenna 202 to the RFID reader 104. To demodulate). For example, if the transponder 114 is inconsistent with 13.56 MHz, the modulator / demodulator 206 may conform to ISO / IEC 14443-2.

The modulator / demodulator 206 may be coupled to the protocol / sequence controller 208 to facilitate the authentication of the signal provided by the RFID reader 104 and to facilitate the transmission of the Forbe 102 account number. . In this regard, the protocol / sequence controller 208 may be any suitable digital or logic drive circuit that can readily determine the sequence of operations for 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 providing the RFID reader 104 with an account number stored in the fob 102. do.

The protocol / sequence controller 208 may also communicate with the authentication circuit 210 to facilitate authentication of the signal provided by the RFID reader 104. The authentication circuit may be in communication with the nonvolatile secure memory database 212. Secure memory database 212 may be any suitable elementary file system. This file system is another elementary file system defined by ISO / IEC 7816-4 or whose lookup of data is interpreted by applications on the chip. The database 212 may be any type of database, such as relational, hierarchical, or object oriented. Common database products that can be used to implement the database include DB2 at IBM (White Plains, NY), database products available from Oracle (Redwood, CA), and Microsoft (Redmond, WA). Soft access or MSSQL, or any other database product. Database 212 may be organized in a suitable manner including data tables, lookup tables, and the like. Combining specific data can be accomplished through data combining techniques that are known and practiced in the past. For example, data association can be accomplished manually or automatically. Automated joining techniques may include, for example, database searching, database merging, GREP, AGREP, SQL, and the like. The joining step can be accomplished, for example, by a database synthesis function using "key fields" in each of the manufacturer's and seller's data tables. The "key field" partitions the database according to the high-level class of the object defined by the key field. For example, a particular class may be designated as a key field in both the first data table and the second data table, and the two data fields may be merged based on the class data in the key field. In this embodiment, the data corresponding to the key field in each merged data table is preferably the same. However, although not identical to the data in that key field, data tables with similar data can be merged, for example by using AGREP.

The data may be used by the protocol / sequence controller 208 for data analysis and may be used for management and control purposes as well as for security purposes. The authentication circuit may authenticate the signal provided by the RFID reader 104 by coupling the RFID signal to an authentication key stored in the database 212. The encryption circuit can use the key stored in the database 212 to encrypt and / or decrypt the signal sent to or received from the RFID reader 104.

In addition, the protocol / sequence controller 208 may communicate with at least one fob 102 account data and a database 214 for storing a unique fob 102 identification code. The protocol / sequence controller 208 may be configured to retrieve account numbers from the database 214 as desired. Database 214 may be configured identically to database 212 as described above. The fob account data and / or the unique fob identification code stored in the 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 may be encrypted when provided to the RFID reader 104. The data stored in the database 214 may also include, for example, unique unencrypted fob 102, identification code, user identification, track 1 and 2 data, as well as specific application applets.

The fob 102 may be configured to respond to multiple call frequency transmissions provided by the RFID reader 104. That is, as described in more detail below, the RFID reader 104 may provide one or more RFID call signals. In this case, the fob 102 can 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, wherein the antenna 218 and transponder 220 may be additional at least one RF provided by the RFID reader 104. It is appropriate for the signal. For example, in one exemplary embodiment, the fob 102 may include a 134 KHz antenna 218 configured to communicate with the 134 KHz transponder 220. In this typical configuration no modulator / demodulator conforming to ISO / IEC 14443-2 is required. Instead, the 134 KHz transponder may be configured to communicate directly with the protocol / sequence controller 208 for the transmission and reception of authentication and account numbers as described above.

In another embodiment, the fob 102 may include a universal serial bus (USB) connector 132 that interfaces the fob 102 to the user interface 134. The user interface 134 can communicate with the POS device 110 via the network 136. The network 136 may be the Internet, an intranet, or the like as described above with respect to the network 112. The user interface 134 may also be similar in configuration to the conventional input devices and / or computing systems described above that allow the system to interact with the system user. In a typical embodiment, the fob 102 may be configured to facilitate online internet payments. The USB converter 222 communicates with the USB connector 232 to facilitate the transfer of information between the modulator / demodulator 206 and the USB connector 132. This month USB converter 222 communicates 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 can communicate with a USB port on the user interface 134, for example. The information retrieved from the fob 102 may be compatible with credit card and / or smart card technologies that enable the use of interactive applications on the Internet. In this embodiment, an RFID reader is not needed because the connection to the POS device 110 is made using the USB port on the user interface 134 and the network 136.

The fob 102 may include means for enabling activation of the fob by a user. In a typical embodiment, the switch 230 may be operated by the user of the fob 102. The switch 230 on the fob 102 can be used to selectively or comprehensively activate the fob 102 for a particular use. In this context, the term " optionally " means that the switch 230 allows the user to position the fob 102 in a particular mode of operation. For example, the user can place the fob 102 in a mode for purchase of a product or service using the selected account number. Alternatively, the fob can be placed in a mode where the fob account number is provided only by the USB port 132 (or serial port) and the fob transponder 114 is disabled. The term “inclusively” also means that the fob 102 is positioned in an operating mode that causes the fob 102 to respond to an RF call through the USB connector 132. In one particular embodiment, the switch 230 may maintain an off position to ensure that one or more applications or accounts associated with the fob 102 do not respond to commands issued by the RFID reader 104. As used herein, the off position may be named the "normal" position of the activation switch 230, although other normal positions are considered.

In another exemplary embodiment, the fob 102 may be considered to be activated by the user when the switch 230 is moved in the off position. That is, the switch 230 may activate the internal circuitry within the fob 102 to cause the fob to respond to an RF signal (eg, a command from the RFID reader 104). In this manner, the switch 230 can easily control the active and inactive states of the fob 102. This control enhances the security of the system by preventing the fob 102 from unintended or illegal use.

In a typical embodiment, the switch 230 may be a simple mechanical device that communicates with circuitry that may prevent the fob from being powered by an RFID reader. That is, if the switch 230 is in its normal position, the switch 230 shorts the internal circuitry of the fob 102 to prevent the fob 102 from responding to calls by RF or via the USB connector 230. Do it. In this configuration, the switch 230 is a switch of the "normally closed" (NC) configuration, which may be electrically connected to the antenna 202 at the interface of the antenna 202 and the transponder 114, for example. Can be. The switch 230 can be pressed in which the switch 230 opens to fully activate the antenna 202.

In another exemplary embodiment, the fob 102 operates as a switch 230 and may include a biosensor and a biomembrane configured to activate the fob 102 when a biosignal is provided from the fob 102 user. The biosignal may digitally read a fingerprint, a thumb fingerprint, and the like. Typically, where a biocircuit is used, the biocircuit may be powered by an internal voltage source (eg, a battery). In this case, the switch is not a simple mechanical device but a powered switch. In another exemplary embodiment, the switch 230 may be powered by a battery even though there is no biocircuit in the fob 102.

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

3 illustrates a typical block diagram of an RFID reader 104 in accordance with an exemplary embodiment of the present invention. The RFID reader 104 includes, for example, an antenna 106 coupled to the RF module 302, which is coupled to the control module 304. The RFID reader 104 may also include an antenna 108 located remotely from the RFID reader 104 and coupled to the RFID reader 104 by an appropriate cable 120 or other wired or wireless connection.

The RF module 302 and antenna 106 may be suitably configured to facilitate communication with the fob 102. When the fob 102 is formatted to receive a signal at a particular RF frequency, the RF module 302 may be configured to provide a call signal at the same frequency. For example, in one exemplary embodiment, the fob 102 may be configured to respond to a call signal of about 13.56 MHz. In this case, the RFID antenna 106 may be 13 MHz and may be configured to transmit a call signal of about 13.56 MHz. That is, the fob 102 may be configured to include first and second RF modules (eg, transponders). Here, 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 can operate using a frequency of 134 Khz, a frequency of 13.56 MHz, or both. If the RFID reader 104 operates at a frequency of 134 KHz, it can only operate as a module of 134 KHz on the fob 102. If the RFID reader 104 operates at a frequency of 13.56 MHz, it can only operate as a module of 13.56 MHz on the fob 102. If the RFID reader 104 supports both 134 KHz and 13.56 MHz RF modules, the fob 102 may receive both signals from the RFID reader 104. In this case, the fob 102 may be configured to preferentially select one of both frequencies and reject the remaining frequencies. Alternatively, the RFID reader 104 may receive both signals at both frequencies from the fob in the call. In this case, the RFID reader 104 may be configured to preferentially select one of both frequencies and reject the remaining frequencies.

The protocol / sequence controller 314 may also include an optional feedback function that notifies the user of the status of a particular transaction. For example, optional feedback may be in the form of LEDs, LED screens, and / or other visual displays, which tells the Forb user that a transaction has been initiated (eg, a fob is called), and the fob is valid (eg, Stop, scroll, flash or brighten other messages and / or signals that indicate that the Forbes account number has been read by the RFID reader) and / or that the transaction has been accepted or rejected (e.g., the transaction has been approved or rejected); Configured to display. This optional feedback may or may not be accompanied by an audible indicator that informs the fob user of the transaction status (or may provide only an audible indicator). The audible feedback may be a single tone, multiple tone, musical indicator and / or voice indicator to inform the transaction status, etc., when the fob 102 receives a call.

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

The RF module 302 may include a transponder 306 in communication with an authentication circuit 308, which may communicate with the security database 310, for example. The authentication circuit 308 and the database 310 may be described as operating similarly to those described with respect to the authentication circuit 210 and the secure memory database 212 of FIG. 2. For example, database 310 may store data in fob 102 that authenticates commerce via system 100. The database 310 further adds the RFID reader 104 identification provided to the fob 102 for use in authenticating whether the RFID reader 104 is authorized to provide a fob account number stored in the fob database 214. Can be stored.

The authentication circuit 308 may be described as operating similarly to the authentication circuit 210. That is, the authentication circuit 308 may be configured to authenticate the signal provided by the fob 102 in a manner similar to that which enables the authentication circuit 210 to be configured to authenticate the signal provided by the RFID reader 104. Can be. As will be described in more detail below, the fob 102 and the RFID reader 104 combine by mutual authentication. In this context, " mutual authentication " means that the operation of the system 100 until the fob 102 authenticates the signal from the RFID reader 104 and the RFID reader 104 authenticates the signal from the fob 102. It means not to happen.

4 is a flow chart of an exemplary authentication process in accordance with the present invention. The authentication process is described on only one side. That is, the flowchart shows only the process of the RFID reader 104 authenticating the fob 102, although similar steps may follow in the example where the fob 102 authenticates the RFID reader 104.

As mentioned, the database 212 may store a security key that encrypts or decrypts the signal received from the RFID reader 104. In a typical authentication process, when the RFID reader 104 authenticates the fob 102, the RFID reader 104 may provide a call signal to the fob 102 (step 402). The call signal may include a random code generated by the RFID reader authentication circuit 210 and is provided to the fob 102 and encrypted using a unique encryption key corresponding to the unique identification code of the fob 102. For example, protocol / sequence controller 314 may provide instructions for activating authentication circuit 308. The authentication circuit 308 may provide a fob call signal including a random number from the database 310 as part of an authentication code generated for each authentication signal. The authentication code may be an alphanumeric code 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 RF interface 306 and antenna 106 (or antenna 108).

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

The RFID reader 104 receives and decrypts the encrypted authentication code (step 410). That is, the encrypted authentication code may be received at the antenna 106 and the RF interface 306 and supplied to the authentication circuit 308. The authentication circuit 308 may be provided with a secure authentication key (eg, transponder system decryption key) from the database 310. The authentication circuit can use the authentication key to decrypt (eg, unlock) the encrypted authentication code. The authentication key may be supplied to the authentication circuit based on the unique identification code of the fob 102. For example, the encrypted authentication code may be provided with an identification code of the unique fob 102. The authentication circuit receives the unique identification code of the fob 102 and retrieves a transponder system decryption key from the database 310 that correlates to the identification code of the unique fob 102 for use in decrypting the encrypted authentication code.

Once the authentication code is decrypted, the decrypted authentication code is compared with the authentication code supplied by the RFID reader 104 in step 402 to confirm its authentication (step 412). If the decrypted authentication code is unreadable by the authentication circuit 308 (e.g., recognizable), the fob 102 is determined to be unauthenticated (step 418) and the operation of the system 100 is terminated. (Step 420). Conversely, if the decrypted authentication code is recognizable by the fob 102 (e.g., verified), the decrypted authentication code is determined to be authenticated (step 414) and the transaction is allowed to continue (step 416). In one particular embodiment, the procedure of the transaction is that although the RFID reader 104 authenticates the fob 102 before the fob 102 authenticates the RFID reader 104, the RFID reader 104 may not have the fob ( This means that the fob 102 can authenticate the RFID reader 104 before authenticating 102.

In a typical authentication process, it should be noted that the authentication circuit 308 may determine whether the undecrypted authentication code is the same as the authentication code provided in step 402. If the codes are not the same, the fob 102 is not authorized to access the system 100. Although the verification process has been described in terms of identity, identity is not required. For example, the authentication circuit 308 can verify the decrypted code through a process of determining whether any protocol step or decrypted code corresponds to the authenticated fob 102.

Authentication circuit 308 may also be in communication with protocol / sequence controller 314, which may be described as operating similar to protocol / sequence controller 208 of FIG. 2. That is, the protocol / sequence controller 314 may be configured to determine the order of operation of the components of the RFID reader 104. For example, FIG. 5 illustrates a typical decision process in which protocol / sequence controller 314 may operate. The protocol / sequence controller 314 may instruct other components of the RFID reader 104 based on whether or not the fob 102 is present (step 502). For example, if the fob 102 does not exist, the protocol / sequence controller 314 may instruct the RFID reader 104 to provide an uninterrupted call signal (step 504). That is, the protocol / sequence controller may instruct the authentication circuit 308 to provide an uninterrupted call signal until the presence of the fob 102 is realized. If fob 102 is present, protocol / sequence controller 314 may instruct RFID reader 104 to authenticate fob 102 (step 506).

As described above, authentication means that the protocol / sequence controller 314 can instruct the authentication circuit 308 to supply the authentication code to the fob 102. If a response is received from the fob 102, the protocol / sequence controller may determine whether the response is a response to the supplied authentication code of the RFID reader 104 or whether the response is a signal requiring authentication (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 signal from the fob 102 is in 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 recognition of the signal. That is, the protocol / sequence controller 314 retrieves a security key (e.g., transponder system decryption key) from the database 310, decrypts the signal, and RFID in the authentication process (e.g., step 506). The authentication circuit 308 may be instructed to compare with the signal provided by the reader 104. If the signal is recognized, protocol / sequence controller 314 may determine that fob 102 is authorized to access system 100. If the signal is not authenticated, the fob 102 is considered not authenticated. In this case, the protocol / sequence controller 314 may instruct the RFID controller to call the authenticated fob (step 504).

Once the protocol / sequence controller determines that the fob 102 has been authenticated, the protocol / sequence controller 314 can determine whether an additional signal has been sent by the fob 102. If no additional signal is provided by the fob 102, the protocol / sequence controller 314 may control all components of the RFID reader 104 to remain idle until the time the signal is supplied (step 516). On the contrary, when the additional signal of the fob 102 is supplied, the protocol / sequence controller 314 determines whether the fob 102 requests access to the merchant's POS terminal 110 (eg, the POS device) or the fob ( 102 may determine whether to call RFID reader 104 for return (eg, mutual) authentication (step 518). When the fob 102 requests access to the merchant's POS terminal 110, the protocol / sequence controller 314 may instruct the RFID reader 104 to open communication with the POS terminal 110 (step 524). . In particular, the protocol / sequence controller 314 instructs the POS terminal communication interface 312 to be activated to allow the transfer of data between the RFID reader 104 and the POS terminal 110.

On the other hand, if the protocol / sequence controller determines that the fob 102 signals are mutual call signals, it instructs the RFID reader 104 to encrypt the signals (step 520). The protocol / sequence controller 314 may instruct the cryptographic authentication circuit 318 to retrieve the appropriate encryption key from the database 320 in response to the cross call signal of the fob 102. The protocol / sequence controller 314 may instruct the RFID reader 104 to provide an encrypted cross-call signal to the fob 102. The protocol / sequence controller 314 may instruct the authentication circuit 318 to supply an encrypted mutual call signal for the fob 102 for mutual authentication. The fob 102 may receive an encrypted mutual paging signal and retrieve an RFID reader decryption key from the authentication circuit 212.

Although a typical decision process of the protocol / sequence controller 314 has been described, it should be understood that a similar decision process may be taken by the protocol / sequence controller 208 when controlling the components of the fob 102. In fact, as described above, protocol / sequence controller 314 has a similar operation and design to protocol / sequence controller 208. The protocol / sequence controller 208, 314 may also include appropriate instructions in the decision process to enable the USB interface 222, 316 when the corresponding device is connected.

The encryption / decryption component 318 can communicate with a security account number database 320 that stores the security key needed to decrypt the encrypted fob account number. On proper request from the protocol / sequence controller 314, the encryption / decryption component (e.g., circuit 318) retrieves the appropriate security key, decrypts the Forbe account number, and later accesses the decrypted account number. May be transmitted to the protocol / sequence controller 314 in a format readable by the POS device 110. In an exemplary embodiment, the account number may be sent in a conventional magnetic strip format that is compatible with the ISO / IEC 7813 standard. In other words, according to the present invention there is no need to translate account numbers or correlate them to traditional magnetic strip formats as has been done in the prior art. The present invention deals directly with transaction requests even if a card associated with the account is provided for payment.

Upon receiving the account number in magnetic strip format, the protocol / sequence controller 314 may transmit the account number to the POS device 110 via the communication interface and data link 122 as best shown in FIG. 1. . The POS device 110 may receive the decrypted account number and send the account number formatted as a self strip to the host network 112 for processing under the merchant's commerce as a normal standard. In this way, the present invention eliminates the need for a third party server. In addition, when the POS device 110 receives a response from the network 112, the protocol / sequence controller 314 may communicate with the RF module (selectively and / or audibly) to respond to the fob 102 user. Provide a network response to 302).

The RFID reader 104 may further include a USB interface 316 in communication with the protocol / sequence controller 314. In one embodiment, the USB interface may be an RS22 serial data interface. Alternatively, the RFID reader 104 may include a serial interface, such as an RS232 interface, for example, in communication with the protocol / sequence controller 314. The USB connector 316 can communicate with an individualization system 116 (shown in FIG. 1B) to initialize the RFID reader 104 for system 100 application parameters. That is, prior to the operation of the system 100, the RFID reader 104 populates the database with a list of security keys belonging to the authenticated fob 102, and enters the fob 102 account number in the ISO / IEC 7813 format. Communicate with personalization system 116 to populate database 320 with a security key to decrypt. In this way, the RFID reader 104 may be populated with a unique identifier (eg, a serial number), which is authorized to allow the RFID reader 104 to receive a Forbe 102 encrypted account number. Can be used by the fob authentication circuit 210 to determine whether or not.

1B is a diagram illustrating an exemplary individualization system 100B in accordance with the present invention. In general, typical personalization system 100B may be any system that initializes RFID reader 104 and fob 102 for use in system 100A. Referring to FIG. 1B, a similar individualization process for the fob 102 may be shown. For example, personalization system 116 may communicate with fob 102 via RF ISO 14443 interface 114 that populates fob database 212 with security keys to facilitate authentication of unique RFID reader 104 identifiers. In addition, the personalization system 116 may populate the database 212 with a unique fob 102 identifier for use by the RFID reader 104 in determining whether the fob 102 is authorized to access the system 100. Can be. The personalization system 116 populates (eg, introduces) the fob 102 account number with the encrypted fob 102 account number for later provision to the authenticated RFID reader 104.

In one exemplary embodiment, the individualization system 16 may include any standard computing system as described above. For example, the personalization system 116 may include a standard personal computer having a hardware security module operable using any conventional Graphical User Interface (GUI). Security Key Information Before populating the fob 102 or RFID reader 104 with an account number and unique identification information, the hardware security module may verify that the component is authorized to receive security information. The reader 104 may be authenticated.

6A and 6B are exemplary flow diagrams of an individualization procedure that may be used to personalize the fob 102 and / or the RFID reader 104. Although the following description primarily describes individualization of the fob 102, the RFID reader 104 may also be individualized using a similar process. The individualization process that occurs between the individualization system 116 and the device to be individualized (eg, the fob 102 or the RFID 104) begins, for example, at step 602. Mutual authentication may occur between the individualization system 116 and the device to be authenticated in the same manner as described above with respect to the fob 102 that mutually authenticates with the RFID reader 104. That is, the individualization system 116 may send the individualization system 116 identifier to the device to be authenticated, which is compared with the individualization system identifier stored in the device database 212, 310 by the authentication circuits 210, 308. If the comparison does not match (step 604), the individualization process may stop processing (step 612). If the comparison results match (step 604), the individualization system may create a personalization file to be supplied to the device to be individualized (step 606). If the individualization system is interoperable, the personalization file will be entered into the personalization system 116 using any suitable system interface, such as, for example, a keyboard (step 606). If the individualization system 116 operator is selected to delay creation of the individualization file, the system 116 may abort the individualization process (step 610). In this description, the personalization file decrypts a unique fob 102 or RFID reader 104 identifier, a security key for loading the databases 212, 310, and / or a fob account number that can be loaded into the database 320. It includes a security key for.

The fob 102 can be individualized by direct connection to the individualization system 116 via the RF ISO / IEC 14443 interface 114 or by using the RFID reader 104. The personalization system 116 and the RFID reader 104 are combined with mutual authentication and the RFID reader 104 may be configured to transmit the fob personalization file to the fob 102 via RF. Once the fob 102 is provided to the RFID reader 104 for individualization (steps 608, 614), the fob 102 and the RFID reader 104 may be combined with each other (step 614). If the fob 102 is not provided to the RFID reader 104 for personalization, the personalization process is stopped (step 610).

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

The encrypted fob 102 account number may be populated into the fob 102 in the same manner as described with respect to the unique identifier of the fob 102. That is, the individualization system 116 encrypts the account data in advance (step 640) and introduces the encrypted account into the fob database 214 (step 622). The encrypted account data may be loaded (eg, introduced) using the RFID reader 104 as described above.

Once the personalization file has been populated in the fob 102, the filled information is locked to prevent cancellation (step 624) to prevent alteration, unauthorized reading, and / or unauthorized access. Personalization system 116 may generate a log of individualization file information for later access and analysis by the user of personalization system 116 (step 626).

Note that if the individualization process is corrupted or blocked (step 628), the personalization system 116 may send a security alert to the user (step 630) and the personalization process may be stopped (step 612). On the other hand, in the absence of such damage or interruption, the individualization system 116 may be prepared to initiate initialization at the second device to be individualized (step 632).

7A and 7B illustrate another exemplary embodiment of a personalization process that can be used to personalize the RFID reader 104. The RFID reader 104 may be communicated with the personalization system via the RFID reader USB connection 316 (step 702). Once connected, the personalization system 116 establishes communication with the RFID reader 104, which can provide the personalization system 116 with RFID reader 104 identification data currently stored in the RFID reader 104. May be step 704. If the RFID reader 104 is initially individualized in accordance with step 708 (step 706), the RFID reader 104 and the personalization system 116 may combine with mutual authentication as described above with respect to FIGS. 6A and 6B. have. After mutual authentication is complete, the personalization system 116 is suitably manufactured or configured for the RFID reader 104 to operate within the system 100. The confirmation may include evaluating the operation of the RFID reader 104 by determining whether the RFID reader will accept a predetermined default setting. That is, the personalization system 116 provides a set of default settings to the RFID reader 104 (step 708) and determines whether the RFID reader 104 will accept these settings (step 712). If the RFID reader 104 does not allow the default setting, the personalization system 116 stops the personalization process (step 714).

If the individualization system 116 determines that the individualization process is not the first individualization process taken by the RFID reader 104 (step 706), then the individualization system 116 and the RFID reader 104 determine the existing RFID reader 104. ) Can be combined into a mutual authentication process using the security key already stored (step 710). If authentication is not successful (step 712), personalization system 116 stops the individualization process (step 714).

If the personalization system 116 and the RFID reader 104 successfully authenticate each other, the personalization system 116 updates the RFID reader 104 security key (step 716). Updating the security key may occur at a time determined by the system 100 manager. The update can occur as part of routine maintenance or to install current security key data. The update can be performed by downloading the firmware to the RFID reader 104 (step 718). If the personalization system 116 determines in step 716 that the RFID reader 104 is initializing, the firmware may be loaded into the RFID reader 104 for the first time. Here, "firware" may include any file that causes the RFID reader 102 to operate under the system 100 guidelines. For example, these guidelines are for the operation of the RFID reader and protocol / sequence controller 314.

The personalization system 116 may determine whether the individualization key (eg, security key, decryption key, RFID identifier) needs to be updated or whether the RFID reader 104 needs to have initial settings of the individualization key ( Step 720). If so, personalization system 116 may download the individualization key as appropriate (step 722).

Personalization system 116 may check RFID reader 104 to determine if fob 102 identifier and corresponding security key has been updated or initially loaded (step 724). If no update is needed, the individualization system 116 may terminate the individualization procedure (step 732). Conversely, if personalization system 116 determines that fob 102 identifier and corresponding key need to be updated or installed, personalization system 116 may download information onto RFID reader 104 (step 726). . The information (eg, fob security key and identifier) may be downloaded in an encrypted format, and the RFID reader 104 may store the information in the RFID reader database 310 as appropriate (step 728). Personalization system 116 may generate or update a status log listing later use and analysis by users of personalization system 116 (step 730). The personalization process may end when updating the status log (step 732).

It should be noted that in some cases it is necessary to re-individify the RFID reader in a manner similar to that described above. In that case, the individualization process described in FIGS. 7A and 7B can be repeated.

8 is an exemplary flow diagram for the operation of system 100A. This operation may be understood with reference to FIG. 1A, which illustrates the components of system 100A that may be used in a typical transaction. This process begins when the customer wants to pay the fob 102 (step 802). Upon application of fob 102, the merchant initiates an RF payment process via RFID reader 104 (step 804). In particular, the RFID reader transmits a call signal to the outside to scan for the presence of the fob 1020 (step 806.) The RF signal may be provided via the RFID reader antenna 106 or optionally the external antenna 108. Customer May provide a payment to fob 102 (step 808), and fob 102 is activated by the provided RF paging signal.

The fob 102 and the RFID reader 104 may combine by mutual authentication (step 810). If mutual authentication is not successful, an error message may be provided to the customer via an RFID selection and / or audible indicator (step 814) and the transaction is aborted (step 816). If mutual authentication succeeds (step 812), the RFID reader 104 provides the customer with an appropriate selection and / or audible message (eg, "transaction processing" or "waiting") (step 818). The fob protocol / sequence controller 208 retrieves the encrypted fob account number from the database 214 and provides the encrypted account number to the RFID reader 104 (step 820).

The RFID reader 104 decrypts the account number and converts it into a magnetic stripe (ISO / IEC 7813) format (step 822) and provides the decrypted account number to the merchant system 130 (step 828). In particular, the account number may be provided to the POS device 110 for transmission to the merchant network 112 for processing. A typical treatment method according to the present invention will be described below with reference to FIGS. 10 to 13. In processing, the POS device 110 may transmit an optional and / or audible transaction status message to the RFID reader 104 for communication with the customer (step 832).

The method for processing a transaction may include one of several formats as required by the fove issuer. For example, one processing method may include processing a transaction under a preloaded fob format. Here, the payment value (eg, monetary value, value of reward points, barter point value, etc.) may be preloaded into preloaded value account or data before allowing the use of the fob. In this way, the user may be allowed to separately set the total amount of payment for transactions for goods or services using the fob. During processing of the transaction, the approval of the transaction includes comparing the transaction amount with the total amount stored (or maintained) in the preloaded value data file. The comparison can be done by a preloaded value processing system. Here, the preloaded value processing system can compare the preloaded value data file with the transaction value to be processed. If the transaction amount exceeds the total amount stored in the preloaded value account, the preloaded value processing system refuses authentication to complete the transaction, requests the user to increase the value in the data file, and all or part of the transaction amount. May request other forms of payment to satisfy the payment and / or any other means for satisfying the associated payment financial institution. If the transaction amount does not exceed the total amount stored in the value of the preloaded value data file, then the preloaded value processing system may provide authentication of the transaction.

A typical preloaded value processing system 1000 is shown in relation to FIG. 10. The preloaded value processing system 1000 may include a fob 102 that includes a transponder 114, which may be a merchant system via an RFID reader 104 or computer interface as described in connection with FIG. 1A. Communicate with 130. The merchant system may communicate with the issuer system 1010, which may be maintained by any entity (eg, non-financial institution, financial institution, American Express, visa, and / or master card, etc.). This allows the probe 102 user to store the total amount of preload values in a preloaded value account (eg, a data file) maintained on an issuer database 1012 of similar configuration, such as database 212. do. The issuer system 1000 may further include one or more process servers to process the fob transaction. As shown, the POS device 110 (included in the merchant system 130) may communicate with an Issuer Account Server (IAS) 1014 for receiving Forbe account information from the POS device 110. . IAS 1014 may communicate with a Preloaded Value Authorization Server (PLAS) 1016 to process a transaction that includes a preloaded value fob. The PLAS 1016 may communicate with an issuer database 101 for retrieving funds from preloaded value data files (not shown) used to satisfy preloaded forbes or merchant transaction requests. In this example, the preloaded value data file may be included in the database 1012 as one or more subfiles, for example.

As used herein, the term “issuer” or “account provider” refers to any entity that facilitates payment of a transaction using a fob, and makes payments using at least one preloaded or unloaded fob. It may include a system that allows. Typical issuers are American Express, MasterCard, Visa and Discover. In the preloaded value processing context, exchange values (eg, money, reward points, barter points, etc.) may be stored in the preloaded value data file for use in completing the required transaction. In one embodiment, the exchange value is not stored in the fob itself. The preloaded value data file can also debit the amount of the transaction, so the preloaded value account can be replenished. As described in more detail below, the preloaded value system platform may be used to complete a "direct link" transaction. In this case, the preloaded value account can function as a place holder and store zero values.

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

In a typical operation, the fob identification information (eg, account number or fob marker) may be provided to the POS device 110 in a manner similar to that described with respect to FIG. 1A. That is, the fob 102 may be provided to the merchant system 130 via the RFID reader 104 or the computer interface 134, which may be in the format of track 1 or track 2 or the POS device 110 and / or issuer system. The fob identification can be provided in any format recognizable by 1001. The POS device 110 included in the merchant system 130 receives the fob 102 identification information and issues the fob identification information with the transaction identification information (for example, total amount, quantity, merchant identification, etc.) for authentication. May be provided to the system 1010. Merchant system 130 may include a merchant system marker or identifier that indicates merchant system identity. Merchant system 130 may combine the fob 102 identification, merchant identification, and / or transaction identification to a merchant transaction request for presentation to issuer system 1010.

IAS 1014 receives the transaction and the fob identification (or merchant transaction request) and may appropriately recognize that the transaction has been requested for a preloaded value account associated with the preloaded fob. That is, the IAS 1014 may recognize that the user provided a preloaded fob for payment. Recognition of the fob 102 as a preloaded fob means that a marker or identifier is included in the fob identification indicating that the fob is associated with a preloaded value data file. Upon recognition of the marker, IAS 1014 may send transaction and fob identification information to PLAS 1016 for processing. The PLAS 1016 compares the transaction amount with the value stored or remaining in the preloaded value to determine whether authentication was allowed or negated. If the transaction amount exceeds the value stored in the preloaded value data file, the PLAS 1016 sends a transaction fraud message to the IAS 1014 for presentation to the merchant system 130, or else the PLAS sends the data to the user. Facilitate a request to increase the value in the file and request other forms of payment and / or other means to satisfy current or future payment related financial institutions to satisfy all or part of the transaction. Alternatively, if the transaction amount is less than or equal to the value stored in the preloaded value data file, the PLAS 1016 may deduct the amount necessary to satisfy the transaction from the preloaded value data file.

As noted above, in one exemplary embodiment of the present invention, the PLAS 1016 may address various financial security reasons, such as when the amount stored in the preloaded value account is less than necessary to satisfy the merchant or forve transaction request. To provide a fraudulent message to IAS. In this example, if the preloaded value falls below a predetermined minimum value (eg, a minimum depletion level), the Forbe user needs to reload the preloaded value data file. . Reloading of preloaded value accounts can occur either mutually (e.g., by a Forbes user's phone or online) or automatically when values stored in a preloaded value data file are exhausted to a predefined level. . If reloading is done automatically, reloading may occur according to rules established by the fove issuer or owner. For example, if the stored value is less than a predetermined amount, it may occur at a preselected time interval until a maximum number of reloads occurs within a predetermined time period or until the maximum reload amount reaches within a predetermined period.

In other typical operations, processing system 1000 may be operated offline. For example, merchant system 130 may be offline to issuer system 1010. That is, the transaction may be approved by the merchant system before the transaction identification information is passed to the issuer system. Instead, merchant system 130 may provide an authorization protocol for use in evaluating merchant transaction requests. For example, the authorization protocol may provide a transaction approval if the transaction is less than a predetermined amount, and may include a specific merchant or product or service, or be requested from a specific location or the like. Once the offline transaction is completed, the merchant can seek the satisfaction of the transaction in a later period by submitting the transaction individually or in batches to the issuer, or under any submission process determined by the merchant.

During offline transactions, the fob 102 may include a counter (not shown) to 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 that point, the fob 102 user is required to perform an online transaction, the counter is reset, and again allows the fob's offline use. As can be appreciated, requiring online use after a predetermined number of offline uses can function as an additional security measure.

11A and 11B illustrate exemplary preloading and reloading processes that may be implemented 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 the funding source 1104. Although these processes have been described using the PLAS 1016, it should be considered that any server configured to set up and manage data files can be used. However, in order to facilitate understanding of the present invention, the preloading and reloading features of the present invention are described with reference to PLAS 1016.

PLAS 1016 may be used to set up value accounts (eg, data files) 1106 preloaded on a server or database (eg, database 1012). Preload Value Accounts may be funded or maintained by a Forbes Issuer / Account Provider, and a Forbes Issuer / Account Provider may be charged or credit cards (e.g. Visa, MasterCard, American Express, Discover, etc.), Debit ( Set credits, charges, debits, reward value accounts, and loyalty accounts for debit or direct debit authorization (DDA) systems.

The preloaded value account may be set to at least one predetermined minimum preload amount or value (eg, minimum preload level) as determined by the account provider and / or the fob user or owner. Here, the predetermined minimum value (eg, preload value) required for setting up the preloaded value account may vary depending on the particular fob user. The preloaded value account can be loaded (eg, preloaded, reloaded) from funds received from one funding source 1104 (American Express, Visa, MasterCard, Discover, Fuel Card, etc.). The preloaded value account can also be loaded with the value received from the loyalty or reward point provider. Loyalty or reward point providers may be referred to herein as funding sources to facilitate understanding of the present invention. Thus, PLAS 1016 may communicate 1108 with funding source 1104 to obtain a fund or value for loading and / or reloading a preloaded value account.

11B illustrates an exemplary reloading process in accordance with the present invention. In operation, a customer may provide a merchant system 130 with a prepaid fob 102 for purchasing a product or service (1110). The preloaded value account is depleted to the value paid to merchant system 130. The process for purchasing a product is repeated until the value stored in the preloaded value account is below a minimum level balance (e.g., depletion level). The minimum depletion level may be predetermined by the fob user or fove issuer and may be allowed to be stored in the preloaded value account until the file is reloaded.

Once the preloaded value data is depleted to reach the minimum depletion level, the PLAS 1016 may trigger an automatic reloading to reload the preloaded value account from the fund retrieved from the funding source 1104 ( 1112). The amount of funds retrieved may be sufficient to load the preloaded value account up to the minimum amount described above or some other predetermined reloading value. In an exemplary embodiment, the PLAS 1016 may trigger automatic reloading when a predetermined minimum depletion level (eg, “minimum level balance”) is reached. That is, the preloaded value account cannot be exhausted to zero value at all when automatic reloading occurs. In this example, PLAS 1016 may charge the funding needed for automatic reloading of funds available at funding source 1104. In another exemplary embodiment, automatic reloading occurs when a transaction exceeds the amount stored or remaining in the preloaded value account. In this way, the value account preloaded can be recovered up to the amount required to complete the transaction. For example, if automatic reloading restores a preloaded value account to a value suitable for transaction completion, the preloaded value account may be automatically reloaded before processing the transaction.

In another exemplary embodiment, automatic reloading may occur based on different user or issuer automatic reloading criteria. Other automatic reloading criteria are reloading until a defined maximum loading amount is reached within a defined time period, reloading at a selected reoccurrence time interval (eg, once a month), or defined within a specific time period. Reloading as permissive until the maximum number of reloads is reached, or reloading until a defined maximum reload amount is reached, but not limited thereto. In some cases, this can be achieved manually, such as when a Forbes user contacts the issuer over the phone or through the user interface to provide specific funding criteria and funding sources for use in reloading preloaded value accounts. Can be.

However, in another exemplary embodiment, the preloaded value transaction processing system may permit the approval of a transaction if the transaction value exceeds the amount of the preloaded value stored in the preloaded value account. That is, the preloaded fob will be used for purchases that exceed the amount of the preloaded value if the fee charged by the merchant is less than or equal to the maximum allowed reloading amount plus the sum total stored on the card when the invoice is submitted. Can be.

In another exemplary embodiment, the preloaded value system may approve a transaction based on a particular merchant's transaction approval protocol. If the issuer reviews and / or approves the merchant's transaction processing method, the system may take this approach in consideration of determining whether to approve the merchant's transaction request. For example, the merchant's transaction processing method may include the merchant submitting a transaction request that exceeds the amount of the preloaded value, but the actual claim may be less than or equal to the amount of the preloaded value. Under this transaction processing method, for example, a merchant, such as a gasoline merchant, can seek approval of the expected amount of gasoline fuel. The merchant as well as the customer may not know the exact final value of the purchase, especially if the customer decides to fill his automatic gas tank or purchases a non-fuel item. Thus, the merchant can submit a transaction request higher than the final amount of the transaction. A merchant may submit a transaction request in real time or later in a similar manner as described above for offline transaction request processing. The value transaction processing system preloaded in on-line or off-line processing may be configured to approve the wish request. The processing system may recognize that the transaction is from a particular merchant and configure a predetermined authorization protocol that correlates with the merchant, since the authorization protocol includes information that the merchant sends a transaction request that exceeds the actual claim. Because.

The transaction processing system may use one of the technologies that can allow the identification of a merchant, such as recognition of a merchant ID, a marker belonging to a transaction, and the like. The processing system may correlate the merchant ID with a merchant protocol requesting transaction authorization greater than the preloaded value (or reloaded value) and approve the merchant request.

Upon receiving a transaction request from the IAS 1014 in accordance with another exemplary embodiment of the preloaded value processing system 1000, the PLAS 1016 is based on several risk criteria established by the issuer for online or offline transactions. Evaluate transaction needs. If all the criteria are successfully met, PLAS 1016 may send the IAS 1014 an authorization of the transaction (eg, “authorized transaction”) to provide to merchant system 130. At the same time or after the transaction authentication is sent to the IAS 1014, the PLAS 1016 may obtain the satisfaction of the transaction from the Forbe value account maintained in the account provider database 1012. The transaction request can be provided to the IAS 1014 for processing. That is, the IAS 1014 may deduct the transaction value from the balance of the amount stored in the preloaded value account.

12 illustrates an exemplary system of another transaction processing system (“direct link” system) 1200 in accordance with the present invention. More specifically, FIG. 12 illustrates a direct link system 1200 that may be used to process a merchant transaction request. Here, the direct link system may use forbes or other available media (credit cards, charge cards, debit cards, etc.) linked directly to an account that stores exchange values (e.g., money, credits or charges or reward points, etc.). May be any system that facilitates the satisfaction of a transaction request. In this example, the preloaded value account cannot be preloaded as described above. The preloaded value account may also be linked to contact financial products such as credits, debits and / or DDA cards that may be provided for payment of goods and services. In this regard, a fob (hereinafter referred to as a "direct link fob") and a card are associated with the same funding source, and the user or trader is satisfied with the transaction from the funding source whether or not the direct link fob or card is used. You can get it. In a typical direct link system 1200, a direct link fob 102 user cannot determine a preloaded value account having a value and the preloaded value account can perceptually store a zero value, or a direct link fob 102 relates to a Forbes trading account that may be used to provide payment to a merchant for goods or services if the Forbes trading account is a credit, debit, loyalty account, or the like.

In accordance with an exemplary embodiment of the present invention, transactions associated with the direct link fob 102 may be processed using the preloaded value transaction processing system described above. As noted, however, in this example the preloaded value account is used as a location holder that stores zero values. The transaction account containing the transaction account value associated with the direct link fob is treated as a funding source to satisfy the direct link transaction. In this example, the transaction may be satisfied according to the Forbe user or a predefined issuer protocol or criteria.

As shown, merchant system 130 may communicate with issuer system 1010 for receiving a merchant transaction request. More specifically, POS device 110 may communicate with an issuer server, such as, for example, an issuer account server (IAS) for receiving merchant and / or transaction identification information. IAS 1014 may also communicate with PLAS 1016 for processing merchant transaction requests. In some cases, the PLAS 1016 may further communicate with the second IAS 1202 even if one or more servers do not require the second IAS 1202 to perform the functions of the second IAS 1202. have. However, IAS 1202 is included herein to simplify understanding of the operation of the exemplary embodiment.

In typical operation of the system 1200, direct link fob identification (eg, a fob identifier or account number) may be provided to the POS device 110 in a manner similar to that described with respect to FIG. 1A. That is, the direct link fob 102 may be provided to the merchant system 130 via the RFID reader 104 or the computer interface 134, which converts the direct link fob 102 identification into the format of track 1 or track 2. Can be provided as The POS device 110 included in the merchant system 130 receives the direct link fob 102 identification information, and converts the direct link fob 102 identification information into transaction identification information (eg, total amount, quantity, merchant identification). Etc.) may be provided to the issuer system 1010 for authentication.

IAS 1014 may receive the transaction and the fob identification and recognize the transaction as required for the direct link fob 102. Recognition of the direct link fob 102 in this example means that the direct link fob 102 identification includes a marker or identifier indicating that the fob is associated with a zero value preloaded value account. Upon recognition of the marker, the IAS 1014 may send the transaction and fob identification information to the 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, the PLAS 1016 may evaluate a transaction request based on several risk criteria established by the issuer. Typical risk criteria may include, but are not limited to, limitations on transaction amounts, specific Forbes user history, fund or reservation restrictions, pre-funded refund rules, user-defined restrictions, or similar valuation criteria for specific time periods. . If all the criteria are successfully met, PLAS 1016 may send the IAS 1014 a certificate of the transaction (eg, “authorized transaction”) to provide to merchant system 130. Transaction authentication may be provided to merchant system 130 based on an assessment of risk criteria but not based on values present in a directlink transaction account or a preloaded value account that stores values for the directlink fob.

After providing transaction authentication to the IAS 1014, the PLAS 1016 is maintained in the issuer database 1012 and funded by a direct link fob account (e.g., a transaction account) funded by the value received from the funding source 1104. Obtain a certificate for the transaction. The authentication request may be provided to the IAS 1202 for approval, and the IAS may retrieve the required value from the direct link fob account. For example, if the direct link fob account is a charge account or a credit account, the PLAS 1016 may request authentication from the first IAS 1202, which IAS 1202 may be assigned to the direct link fob account of the database 1012. Access to the transaction amount. IAS 1202 records the transaction amount in a Forbes user history data file (e.g., a charge account) for payment at the end of the billing cycle, or on a day when the amount is later than the end of the billing cycle. Can be recorded in a Forbes directlink user data file (e.g., a credit account).

In another operation, the PLAS 1016 may access the transaction amount for the direct link Forb account without using the second IAS 1202. It should be understood that the value may not be passed directly to the merchant system from the directlink Forbe account to satisfy the transaction as to whether the transaction is processed using the second IAS 1202. Instead, the directlink fob issuer can guarantee the satisfaction of the merchant transaction, for example by request, until a value is retrieved from the directlink fob account at the end of or after the billing cycle. That is, PLAS 1016 may provide for authentication of the transaction, but may not retrieve the value needed to satisfy the transaction until after the merchant provides the issuer system with a request for resolution.

However, in another exemplary transaction processing system 1300 shown in FIG. 13, the merchant system 130 may provide the process server 1302 with a batch file containing the multi-fob transaction requests to be processed, which multi-fob transactions It may include both a preloaded value and a direct link transaction request. The system 1300 may include a process server 1302 that distinguishes between the preloaded value and the direct link transaction request. In other words, process server 1302 may be used to separate fore trades associated with preloaded values from fore trades that are not associated with preloaded forbe accounts, as described in more detail below. Process server 1302 may communicate with IAS 1014 to resolve a transaction. IAS 1014 may process a transaction request according to the preloaded value trading platform or direct link transaction process described above.

In operation of a typical system 1300, process server 1302 may receive a resolution file and identify the file according to the nature of the transaction request. For example, the process server 1302 places a marker in the received file and creates a subfile of the transaction request for the type of fob used in the transaction (e.g., preloaded fob, and direct link fob associated with the charge or credit). Create Process server 1302 may generate a first fob transaction file for the merchant to pay and the second fob transaction file for the account that may be sent to IAS 1014 for processing. If the subfile contains merchant payments, process server 1302 may provide the fund to the merchant for payment of the transaction. The fund provided may be equal to the transaction minus the discount income. The fund may be retrieved from the funding source to provide to the merchant. Alternatively, process server 1302 may generate a second fob transaction file for a payment account that can be received and send the second fob transaction file to IAS 1014. IAS 1014 may process a transaction request according to the process described in FIGS. 10 and 12. That is, the IAS 1014 may process a transaction by distinguishing a preloaded fob transaction request from that associated with the direct link fob.

Considering the operation of the various transaction processing systems described above, it can be seen that the transaction processing system can be considered when the card associated with the fob is used or the account associated with the preloaded fob is reloaded. In view of that, the present invention can be used to reward points depending on the nature of the use of the fob. This point (e.g., loyalty point) may be stored in a reward account or point maintained in the issuer database (e.g., database 1012). Reward points can later be redeemed from reward accounts that can be exchanged for goods or services when the Forbes user wishes. For more information on loyalty systems and trading systems, see, for example, a US patent entitled "Systems and Methods for Networked Loyalty Programs," filed April 17, 2001 by inventor Voltmer et al. Application 09 / 836,213; US Patent Application No. 10 / 027,984, entitled “Systems and Methods for Networked Loyalty Programs,” filed December 20, 2001 by inventor Ariff et al .; US patent application Ser. No. 10 / 010,947, entitled "Systems and Methods for Networked Loyalty Programs," filed Nov. 6, 2001 by inventor Hines et al .; Shop AMEX ^™ system, published in Sep. 5, 2000, filed 60 / 230,190; MR as Currency ^™ , published 60 / 197,296, filed April 14, 2000, 60 / 200,492, filed April 28, 2000, and 60 / 201,114, filed May 2, 2000; and Loyalty reward system; Stored value cards published in 09 / 241,188 filed February 1, 1999; 09 / 800,461 filed March 7, 2001 and related provisional application 60 / 187,620 filed March 7, 2000, 60 / 200,625 filed April 28, 2000, 60 filed May 22, 2000 Reference is made to a system that facilitates trading using secondary transaction numbers published in US Pat. No. 213,323, all of which are incorporated herein by reference. Other examples of online membership reward systems are those disclosed in US Pat. No. 5,774,870, issued June 30, 1998, and US Pat. No. 6,009,412, issued December 29, 1999, all of which are incorporated by reference. Included herein.

As mentioned, points may be provided, for example, when a fob is used and when a card associated with the fob is used. For example, IAS 1014 may recognize that a fob is used and a reward point (eg, loyalty point) for a reward account has been assigned to a fob user associated with the fob. Loyalty points may be rewarded according to criteria determined by the Forbes issuer. Typical reward criteria include, for example, the frequency of use of the fob, the individual purchases using the fob, the total purchase amount within a given time period, the location of the merchant, the type of merchant, or any point of compensation to encourage the use of the fob. can do.

If the fob is associated with a preloaded value account as described with respect to FIG. 10, points may be rewarded for account reloading. That is, the IAS 1014 may grant reward points to the reward account for the amount of loading or reloading as needed. IAS 1014 may also award reward points to reward accounts for the use of Forbes in certain merchants or certain transactions.

The trading account associated with the fob 102 may include, for example, restrictions on use, such as per-purchase expenditures, daily hours of use, weekly days of use, use of certain merchants, and additional validation when using forbes outside of the limits. Note that it is required. This restriction can be personally assigned by the Forbe user or account provider. For example, in one typical embodiment, an account can only be confirmed if a purchase of $ X or more (ie, spending limit) has been verified by the customer. Such verification may be provided using a suitable Personal Identification Number (PIN), which is when the Forbe 102 is unique to the Forbe owner (eg, customer) and the Corresponding Forbe 102 transaction account number. Or a payment authentication center (not shown). If the required purchase exceeds the consumption limit per purchase, the customer may, for example, be required to provide a PIN, biometric sample and / or similar secondary verification to complete the transaction. That is, for example, the fob 102 may enter a unique PIN on a conventional keypad in the merchant system 130 or the RFID reader 104. The PIN may be provided to the authentication center for comparison with a correlation PIN stored in the issuer system. Alternatively, the PIN can be provided to the fob 102 via the RFID reader 104. The fob 102 can verify the PIN by comparing the PIN with, for example, a correlated PIN stored in the secure memory 212. FIG. have.

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

The verification PIN is a POS device using a conventional merchant (eg, POS) PIN keypad 118 communicating with the POS device 110 shown in FIG. 1, or using an RFID keypad communicating with the RFID reader 104. 110 may be provided. The PIN keypad can communicate with the POS device 110 (or RFID reader 104) using any of the conventional data links described above. Upon receiving the verification PIN, the RFID reader 104 may match the PIN with the verification PIN stored in the RFID reader 104 in the database 310 or 320. Alternatively, a verification PIN may be provided to the payment verification center to determine whether the PIN matches a PIN stored in the payment verification center database associated with the Forbe account. If there is a match, the purchase is no longer restricted and the transaction is allowed and completed.

In another embodiment, the verification above the established spending limit may include a biocircuit included in the fob 102. 9 is a schematic block diagram of a typical fob 102, where the fob 102 includes a biosecurity system 902. The biometric security system 902 can include a biometric sensor 904 for detecting a fingerprint of a fob user. The biosensor 902 may communicate with an interface / driver 906 to receive sensor fingerprints and to activate the operation of the fob 102. The sensor interface 906 in communication with the biometric sensor 904 may be a battery 903 for supplying power needed for operation of the biometric system component.

In a typical embodiment of the fob 102 that includes the biosecurity system 902, the customer initiates a mutual authentication process between the fob 9102 and the RFID reader 104 by placing his finger on the biosensor, or The identity second verification can be provided. The sensor fingerprint can be digitized and compared to the digitized fingerprint stored in a database (eg, security database 212) included in the fob 102. This comparison step can be controlled by protocol / sequence controller 208 and validated by authentication circuit 210. Once this verification is made, mutual authentication between the fob 102 and the RFID reader 104 is initiated and the transaction proceeds accordingly. Alternatively, the comparison may be made with a digitized fingerprint stored on a database maintained by the Forbes 102 trading account provider system (not shown). The digitized fingerprint can be verified in the same manner as described above with respect to the PIN.

In a typical application of the fob 102 that includes the biometric security system 902, the security system 902 can be used to authorize a purchase that exceeds what is set for the spending limit of the purchase. In this case, if the customer's intended purchase exceeds the spending limit, the customer may request that the purchase be authorized. Thus, the customer can provide this verification by placing his finger on the biosensor 904. The biosensor 904 can digitize the fingerprint and provide the digitized fingerprint for verification as described above. Once verified, the fob 102 can provide the RF transponder 202 (or transponder 202) to send a transaction authentication signal to the RFID reader 104. The RFID reader 104 provides a transaction authentication signal to the POS device 110 in a manner similar to that of a conventional PIN drive system and POS device 110, which is usually under the merchant's business as a standard. Process the transaction.

In accordance with another exemplary embodiment of the present invention, a fob user has limited access to a fob user data file and fob user information maintained in an issuer system for managing fob usage. The user can access via telephone, online, or offline. Forbes users change, for example, demographic information (e.g., Forbes user addresses, phone numbers, email addresses, etc.), and funding sources associated with the Forbes (e.g., credit accounts, charge accounts, reward accounts, barter accounts, etc.). To do this, you can access Forbes user data files, view transaction history, and more. Forbes users can also be allowed to load or reload accounts, and can change automatic reloading parameters (eg, amount of reloading, reload duration, etc.). If more than one fob 102 is correlated with a trading account, the user may provide similar access to the data file corresponding to the additional fob.

Referring to FIG. 1A, a fob user can connect the fob 102 to the computer interface 134 via the USB interface 132. A fob user can use the computer interface 134 to access the fob user data file via the network 136. In particular, network 136 may communicate with an issuer system (eg, system 1010 of FIG. 10) and provide limited access to the issuer server (eg, server 1014) for managing the fob. Can be. The issuer server 1014 may communicate with an issuer system database (eg, 1012), which stores information to be managed for the user fob user data file. Changes made to the fob user data file by the fob user are made in real time after a simple delay or after an extended delay. As an example, the changes may be stored in a batch change file in the issuer database for later batch processing. DETAILED DESCRIPTION The foregoing detailed description of exemplary embodiments of the present invention refers to the accompanying drawings that show exemplary exemplary embodiments. These exemplary embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, but other embodiments may be implemented and logical mechanical changes may be made without departing from the spirit and scope of the invention. have. For example, the steps recited in a method or process may be executed in any order and are not limited to the order presented. The present invention can also be implemented using one or more servers as needed. The foregoing detailed description, therefore, is intended to be illustrative rather than restrictive, and the scope of the present invention is defined by the detailed description of the invention and the appended claims.

Claims (47)

In the transponder-reader payment system, a. A transponder system comprising a transponder database storing at least one transponder system identifier, the transponder system responsive to a radio call signal, wherein the identifier of the transponder system is one of a prepaid transponder and a direct link transponder. A transponder system comprising a marker for identifying as; b. A radio frequency identification (RFID) reader communicating with the transponder system wirelessly, supplying the call signal to the transponder system and receiving the transponder system identifier; c. A merchant system associated with a merchant identifier, said RFID reader supplying said transponder system identifier to said interaction apparatus, said interaction apparatus using said merchant identifier and transponder system to a user; A merchant system for associating a transaction request, forming a merchant transaction request, and providing the merchant transaction request to an issuer system server; d. A transponder-reader payment system comprising an issuer system server in communication with the interaction device and an issuer system database including a preloaded value associated with the transponder system identifier. . The method of claim 1, Wherein said predetermined value is preloaded into said preloaded value data file prior to use of said transponder system, said predetermined value being greater than zero. The method of claim 2, The issuer system server identifies the transponder system as a prepaid transponder system. The method of claim 3, wherein And the issuer system server compares the user transaction value with the predetermined value. The method of claim 4, wherein Wherein said user transaction request is less than or equal to said predetermined value. The method of claim 5, wherein And the issuer system provides a transaction approval transfer to the merchant system. The method of claim 6, The issuer system server retrieves at least a portion of the predetermined value from the preloaded value data file, and supplies the retrieved portion of the predetermined value to the merchant system, wherein the preloaded value data is at least the preloaded value data file. And subtracting the portion of the predetermined value from the depletion value of the determined value. The method of claim 7, wherein The depletion value is less than a minimum depletion level, and the issuer server reloads the preloaded value into the predetermined value responsive thereto. The method of claim 8, The issuer system server is in communication with a funding source, the funding source being associated with the transponder system identifier and the preloaded value, the funding source comprising a funding source value. . The method of claim 9, And the issuer server retrieves a portion of the funding source value that is used to reload the preloaded value data file. The method of claim 4, wherein The user transaction request exceeds the predetermined value, and the issuer system server provides a transaction rejection transmission to the merchant system in response to the comparison. The method of claim 2, The interaction device is offline and the interaction device compares the user transaction request with a predetermined authorization protocol that approves or rejects the user transaction request. The method of claim 1, The issuer system server identifies the transponder system as a direct link transponder system. The method of claim 13, And said predetermined value is a value of zero. The method of claim 14, And the issuer system server evaluates the merchant transaction request for approval according to at least one predetermined criterion. The method of claim 15, The issuer system server provides a transaction rejection transmission according to at least one of the predetermined criteria, and the transaction rejection transmission is provided to the merchant system. The method of claim 15, The issuer system server provides a transaction approved transmission in accordance with at least one of the predetermined criteria, wherein the transaction approval transmission is provided to the merchant system. The method of claim 17, And a funding source in communication with the issuer system server, wherein the funding source is associated with the transponder system identifier and the funding source comprises a funding source value. The method of claim 18, The issuer system server credits the funding source in response to the user transaction request, and at least a portion of the user transaction request is added to the funding source value. The method of claim 18, The issuer system server charges the funding source in response to the user transaction request, and the issuer system server receives at least a portion of the funding source value in response and receives a later time than the issuer system server. Wherein said portion of said funding source value provides said transaction approval transfer. The method of claim 13, Further comprising a contact form factor for indicating satisfaction of the merchant transaction request, the contact form element comprising a contact form factor marker, the contact form element The marker of is associated with the transponder system identifier and the preloaded value. The method of claim 21, The element of the contact type is one of a charge card, a credit card, a debit card, a royalty card, and a direct debit authorization card. Transponder-reader payment system. The method of claim 21, A marker of the contact type element is provided to the merchant system, the merchant system associates the marker of the contact type element with a contact user transaction request forming a merchant contact transaction request, and the merchant system identifies the contact transaction request. Transponder-reader payment system, characterized in that provided to the issuer system server. The method of claim 23, And the issuer system server receives the merchant contact transfer request and provides the merchant system with at least one of a second transaction authorization transmission and a second transaction rejection transmission in response thereto. The method of claim 24, The issuer system database further includes a transaction approval data file, wherein the issuer system server generates the approved transaction in response to the transaction approval transmission and the second transaction approval transmission, and the transaction approval data file includes the first transaction data. Transponder-reader payment system, characterized in that the transaction approval transmission is separated from the transaction approval transmission. The method of claim 25, The issuer system database further includes a reward point data file, the reward point data file associated with the transponder system identifier and the marker of the contact type element, wherein the reward point data file includes a loyalty value indication. Transponder-reader payment system, characterized in that. The method of claim 26, The issuer system server increases the royalty value of the loyalty value indication in response to at least one of the transaction approval transmission, the second transaction approval transmission, the merchant identifier, the merchant transaction request, and the merchant contact transaction request. Transponder-reader payment system. The method of claim 26, And the issuer system server increases the loyalty value of the loyalty value indication according to the issuer's predetermined incentive criteria. The method of claim 1, a. In communication with the issuer system server, further comprising a user system remote from the issuer system, b. The transponder system further comprises a USB interface in communication with the user system, c. The issuer system database further includes a user profile data file including at least one of a user population subfile and a transponder system user subfile, wherein the user population subfile and the transponder system use subfile are the issuer system server. Manageable by the user population subfile, wherein the user population subfile stores a plurality of user population identifiers, and wherein the transponder system usage subfile stores at least one restriction placed on transponder system usage. Leader payment system. The method of claim 29, The user system providing at least one of an update demographic identifier and an update restriction on the issuer system server, the update demographic identifier corresponding to at least one of the plurality of user demographic identifiers, The update restriction corresponds to the at least one restriction, and the issuer system server replaces at least one and the at least one restriction of the plurality of user demographic identifiers with the corresponding update demographic identifier and the corresponding update restriction. Transponder-reader payment system, characterized in that. The method of claim 30, Translating at least one of the plurality of user demographic identifiers and the at least one restriction is done in real time. In the radio frequency identification (RFID) transponder-reader payment method, a. Providing the merchant system via a radio signal a transponder system identifier comprising one of a preloaded transponder system marker and a direct link transponder marker; b. Associating the transponder system identifier with a merchant system that forms a merchant transaction request with a user transaction request comprising a transaction value; c. Providing the merchant transaction request to an issuer system server; d. Distinguishing the preloaded transponder system marker and the direct link transponder marker; e. Associating at least one of the preloaded transponder system marker and the direct link transponder marker to a corresponding preloaded value, wherein the preloaded value data file includes the preloaded value. RFID transponder-reader payment method. The method of claim 32, Preloading the preloaded value data file with a preloaded value greater than zero, a. Comparing the user transaction value with the preloaded value; b. Providing a transaction approval transfer to a merchant system wherein the transaction value is less than or equal to the preloaded value; c. Subtracting a transaction value from the preloaded value; d. Providing the transaction value to the merchant system; e. Reloading the preloaded data file when a predetermined minimum depletion level is reached. The method of claim 32, a. Preloading the preloaded value data file with a preloaded value; b. Comparing the user transaction value with the preloaded value; c. If the transaction value is greater than the preloaded value, providing a transaction rejection transmission to a merchant system. The method of claim 33, wherein a. Associating a contact type element identifier with the transponder system identifier; b. Providing the contact type element identifier to a merchant system; c. Associating the element identifier of the contact type with a second user transaction request comprising a second transaction value and forming a second merchant transaction request; d. Providing the second merchant transaction request to an issuer system server; e. And comparing the second user transaction request with the preloaded value. 36. The method of claim 35 wherein And if the second user transaction request is less than or equal to the preloaded value, providing a second transaction approval transmission to the merchant system. 36. The method of claim 35 wherein And if the second user transaction request is greater than the preloaded value, providing a transaction rejection transmission to the merchant system. The method of claim 36, Generating a transponder system usage data file comprising a record of the transaction approval transmission and a second transaction approval transmission, wherein the transaction approval transmission is separate from the second transaction approval transmission Transponder-Reader payment method. The method of claim 38, a. Providing a reward point data file; b. Increasing the compensation value of the reward point data file in response to the transaction approval transmission. The method of claim 38, a. Providing a reward point data file; b. Increasing the compensation value of the reward point data file in response to the second transaction approval transmission. The method of claim 38, Providing a reward point data file; And increasing the reward value of the reward point data file in response to at least one of the transaction approval transmission and the second transaction approval transmission. 42. The method of claim 41 wherein Reloading the preloaded value data file in response to at least one of the transaction approval transmission and the second transaction approval transmission. The method of claim 42, And increasing the reward point data file in response to at least one of the preloaded value data file, a merchant transaction request, a user transaction request, a transponder system identifier, and a merchant system identifier. FONDER-READER PAYMENT. In the radio frequency identification (RFID) transponder system, a. Issuer system is accessible using the transponder system identifier and a transponder system identification using a user interaction device remote from the user system; b. And one of the user population indication and a transponder system usage restriction, wherein the data file associated with the transponder system identifier is updated. The method of claim 44, And the data file is updated in real time. The method of claim 1, And an RFID reader provides the transponder system identifier to the interaction device in a track 1 / track 2 format. The method of claim 32, Providing the transponder system identifier to the merchant system via a wireless signal comprising providing the transponder system identifier in the format of track 1 / track 2;