SYSTEM AND METHOD FOR SECURING A
RECURRENT BILLING TRANSACTION
CROSS-REFERENCE TO RELATED
APPLICATIONS 5
This invention is a continuation in part of, and claims priority to U.S. patent application Ser. No. 10/192,488, entitled "SYSTEM AND METHOD FOR PAYMENT USING RADIO FREQUENCY IDENTIFICATION IN 10 CONTACT AND CONTACTLESS TRANSACTIONS," filed on Jul. 9, 2002 (which itself claims priority to U.S. Provisional Patent Application No. 60/304,216, filed Jul. 10, 2001); to U.S. patent application Ser. No. 10/340,352, entitled "SYSTEM AND METHOD FOR INCENTING 15 PAYMENT USING RADIO FREQUENCY IDENTIFICATION IN CONTACT AND CONTACTLESS TRANSACTIONS," filed Jan. 10, 2003 (which itself claims priority to U.S. Provisional PatentApplicationNo. 60/396,577, filed Jul. 16, 2002); to U.S. patent application Ser. No. 10/708,569, 20 entitled "SYSTEM AND METHOD SECURING SENSITIVE INFORMATION DURING COMPLETION OF A TRANSACTION," filed Mar. 11, 2004; and to U.S. patent application Ser. No. 09/865,878, entitled "RECURRENT BILLING MAINTENANCE SYSTEM," filed May 25,2001, 25 all of which are incorporated herein by reference.
FIELD OF INVENTION
This invention generally relates to securing a transaction 30 involving radio frequency identification (RFID) technology. More particularly, the invention pertains to a system and method for securing the RFID enabled transaction using a proxy code or number, which hides the underlying payment device information from the merchant system.
BACKGROUND OF INVENTION
Like barcode and voice data entry, RFID is a contactless 4Q information acquisition technology. Of late, companies are increasingly embodying RFID data acquisition technology in a fob or tag for use in completing financial transactions. During the transaction completion, information from the RFID fob is ordinarily passed to the POS, which delivers the information to a merchant system.
To complete the transaction, fob identification data is typically passed to a third-party server database. The third-party server references the identification data to a consumer (e.g., user) transaction account (e.g., charge, credit, debit, loyalty, 50 etc). In an exemplary processing method, the third-party server may seek authorization for the transaction by passing the transaction and account data to an authorizing entity, such as for example an "acquirer" and/or account issuer. Once the server receives authorization from the authorizing entity, the 55 authorizing entity sends clearance to the POS device for completion of the transaction.
In addition to sending the information to an issuer system for verification, the merchant system may store the information in a merchant system database for later reference. For 60 example, where the transaction device user is a repeat consumer, the transaction device user may wish to complete the transaction using transaction account information previously submitted to the merchant system. Since the account information is stored on the merchant system, the user need not 65 provide the information to a merchant to complete subsequent transactions. Instead, the user may indicate to the mer
chant to use the transaction account information stored on the merchant system for transaction completion.
In another typical example, the merchant system may store the transaction account information for later reference when the transaction device user establishes a "recurrent billing" account. In this instance, the merchant may periodically charge a user for services rendered and/or goods purchased. The user may authorize the merchant system to seek satisfaction of the bill using the transaction account information. The merchant may thereby send a transaction request regarding the bill to an account provider, and/or a third-party server.
To lessen the financial impact of fraudulent transactions in the RFID environment, fob issuers have focused much effort on securing RFID transactions. Many of the efforts have focused on securing the transaction account and/or related data during transmission from the user to the merchant, and/ or from the merchant to a third-party server and/or account provider system. For example, one conventional method for securing RFID transactions involves requiring the device user to provide a secondary form of identification during transaction completion. The RFID transaction device user may be asked to enter a personal identification number (PIN) into a keypad. The PIN may then be verified against a number associated with the user and/or the RFID transaction device, wherein the associated number is stored in an account issuer database. If the PIN number provided by the device user matches the associated number, then the transaction may be cleared for completion.
One problem with the issuer's efforts in securing RFID transactions is that they typically do not focus on the ways to guard the transaction account information stored on the merchant system from theft. As noted, the merchant may typically store on a merchant database the information received from the transaction device during a transaction. Such information may be sensitive information concerning the fob user or the fob user's account. Should the fob user's sensitive information be retrieved from the merchant system without authorization, the fob user or issuer may be subjected to fraudulent activity. The ability to secure the sensitive information stored on the merchant system is limited by the security measures taken by the merchant in securing its merchant system database. Consequently, the account provider often has little influence over the security of the account information once the information is provided to the merchant system.
As such, a need exists for a method of securing sensitive transaction account information which permits the account provider to have a significant influence on the security of the fob user information stored on a merchant system. A suitable system may secure the sensitive information irrespective of the merchant system.
SUMMARY OF INVENTION
A system and method for securing transactions is described which addresses the problems found in conventional transaction securing methods. The securing method described herein includes providing a proxy code to a merchant system for use as the customer identifier during a transaction instead of the merchant providing sensitive transaction account information. A transaction device in accordance with the invention provides the proxy code and/or proxy number to the merchant system contemporaneously with a transaction request. The merchant system receives the proxy code and correlates the proxy code to a user or transaction in the merchant system. The merchant system stores the proxy code in a merchant database for later reference.
3
In one embodiment, the proxy code does not include any sensitive information about the transaction device user or user transaction account. Instead the merchant system receives a proxy code, which takes the place of the sensitive information ordinarily received during transaction completion. In other 5 words, certain information such as the user's actual account number is never transmitted to the merchant. Thus, the user's account number is not available should the merchant system be compromised.
In accordance with one exemplary embodiment of the 10 invention, a radio frequency identification (RFID) transaction device is used to complete a transaction. The RFID transaction device is interrogated by a RFID reader operable to provide a RF interrogation signal for powering a transponder system. The RFID reader receives the proxy code instead of 15 sensitive transaction device information, and the merchant receives the transaction device proxy code from the RFID transaction device and provides the proxy code to an authorizing agent, such as an acquirer or an account issuer, for verification. For example, the authorizing agent verifies that 20 the proxy code corresponds to a valid transaction account on the account provider system. The authorizing agent uses the proxy code to locate the appropriate verifying (e.g., "validating") information for confirming the transaction account validity. Once the authorizing agent verifies the validity of the 25 transaction account using the proxy code, the authorizing entity (e.g., account issuer or acquirer) provides authorization to the merchant that a transaction may be completed.
In another exemplary embodiment, a non-RFID transaction device is used to complete a transaction. The non-RFID 30 transaction device could be a magnetic stripe card, a computer-based program, and/or the like. The computer-based program could be used, for example, for initiating the recurring payment via the Internet.
In one exemplary embodiment, the RFID reader is addi- 35 tionally validated. In this instance, the RFID reader is provided a RFID reader authentication tag which is used to validate the reader. During transaction completion, the RFID reader receives the RFID transaction device proxy code and the reader provides the transaction device proxy code and the 40 reader authentication tag to an authorizing agent, such as an acquirer. In a similar manner as with the transaction account, the acquirer then validates that the RFID reader is an authorized reader for facilitating a RF transaction with the account issuer. If the RFID reader is validated, the acquirer provides 45 the RFID transaction device identifier to an account provider for RFID device verification. The account issuer then verifies that the RFID transaction device is authorized to complete the requested transaction. Alternatively, the account issuer directly validates the reader. 50
In yet another embodiment of the invention, the proxy code is assigned to a single merchant or multiple merchants. Upon receiving a request from a merchant to establish a recurring account for a consumer, the account issuer provides the merchant with a marked proxy code that is unique to the con- 55 sumer. The marked proxy code includes a marker that is predetermined by the account issuer and which corresponds to one or more merchants. The merchant correlates the marked proxy code to a particular consumer and stores the marked proxy code relative to the consumer in a merchant 60 database. When the merchant submits a transaction request to an account issuer for satisfaction, the account issuer verifies that the transaction is received from an authorized merchant by validating that the marker included in the marked proxy code corresponds with the marked proxy code that the 65 account issuer has assigned to the merchant providing the transaction request.
4
These features and other advantages of the system and method, as well as the structure and operation of various exemplary embodiments of the system and method, are described below.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, wherein like numerals depict like elements, illustrate exemplary embodiments of the present invention.
FIG. 1 illustrates an exemplary RFID transaction system depicting exemplary components for use in a secure RFID transaction completed in accordance with an exemplary embodiment of the present invention; and
FIG. 2 depicts a flowchart of an exemplary method for securing a RFID transaction in accordance with an exemplary embodiment of the present invention; and
FIG. 3 depicts a flowchart of another exemplary method for securing a transaction using a proxy code in accordance with an exemplary embodiment of the present invention.
DETAILED DESCRIPTION
The present invention may be described herein in terms of functional block components, screen shots, optional selections and various processing steps. Such functional blocks may be realized by any number of hardware and/or software components configured to perform the specified functions.
In one exemplary embodiment, the transaction device is correlated with a unique RFID transaction device account number. In accordance with the invention, the account number is not provided to a merchant during transaction completion. Instead, the merchant system is provided a "proxy code" (described below). The transaction device proxy code is stored on a transaction device database located on the transaction device. The transaction device database is configured to store multiple proxy codes issued to the RFID transaction device user by the same or different account providing institutions.
To facilitate understanding, the present invention is described with respect to a charge, debit, credit, or loyalty account. However, it should be noted that the invention is not so limited. Other transaction accounts, which facilitate an exchange of goods or services, are contemplated to be within the scope of the present invention.
Various components are described herein in terms of their "validity." In this context, a "valid" component is one that is partially or fully authorized for use in completing a transaction request in accordance with the present invention. Contrarily, an "invalid" component is one that is not partially or fully authorized for transaction completion.
Although the present invention is described with respect to validating a transaction device or reader communicating in a RF transaction, the invention is not so limited. The present invention is used for any software, device, machine, or article, which provides user-identifying data to a merchant. Thus, the present invention is used in any contact or contactless environment where identifying data is transferred to a merchant.
During a typical RFID transaction, a RFID transaction device user transmits information concerning the user's transaction account to a merchant POS. The information received by the POS includes, for example, the transaction device identifier or account number. The information further includes personal, demographic, biometric or statistical information related to the transaction device user. Upon receiving the information, the merchant POS ordinarily provides the information to a merchant system. The merchant
5
stores the information in a merchant system database for later reference. For example, the merchant system then references the transaction device information in the event that a user wishes to complete a transaction by providing the merchant the same identifying information as the merchant has stored 5 on the merchant system.
In most instances, the transaction device information is stored on the merchant system database for an extended period of time. The extended storage is often performed because the merchant typically wishes to have the informa- 10 tion readily available for later reference (e.g., transaction request maintenance, account or transaction request tracking, or the like). The merchant may also desire to archive the transaction device information for later use in preparing promotional offers or solicitations or materials to be provided to 15 the transaction device user.
One key disadvantage of the conventional transaction processing method described above is that the information stored by the merchant is typically "sensitive information." Sensitive information is that information which the transaction 20 account provider or the transaction device user would want to guard from theft or restrict use. Sensitive information is any information or data. In the wrong hands, the sensitive information is often used to conduct a fraudulent transaction. For example, sensitive information includes the user account 25 number, transaction device identifier, transaction device user personal data and/or the like. The information is used, for example, to complete a transaction by reproducing the sensitive information without authorization. If sensitive information is somehow compromised or stolen, it is easily subjected 30 to fraudulent usage. For example, should an unscrupulous person gain access to the merchant system and steal the transaction device identifier or account number, the person is able to use the stolen information to place fraudulent charges on the associated transaction account. As such, the merchant 35 puts into place special security measures designed to protect the sensitive information from theft. The merchant ordinarily makes decisions related to securing the sensitive information without consulting the account provider. The transaction account provider often relies on the effectiveness of the mer- 40 chant security measures to ensure that the information is not stolen while being stored on the merchant database. If the merchant security methods are ineffective or easily compromised, the sensitive information may be easily stolen.
The present system and method permits the account issuer 45 to control the level of security with which the information stored on the merchant database is protected. As used herein, the term "proxy code" includes any device, hardware, software, code, number, letter, symbol, digital certificate, smart chip, digital signal, analog signal, biometric and/or other 50 identifier/indicia. The proxy code also refers to any information provided to, for example, a merchant system during completion of a transaction request, which partially and/or fully masks the underlying sensitive information from the merchant system. As such, the information provided "masks" 55 the underlying sensitive information related to the transaction account from the merchant system. Particularly, the information provided to the merchant (called "proxy code" herein) does not include sensitive information like, for example, the transaction account number. Consequently, in one embodi- 60 ment, the merchant system is provided limited or no sensitive information since the sensitive information is not included in the proxy code. Moreover, the proxy code may take the form of any conventional transaction account identifier. As such, when the merchant receives the proxy code, the merchant 65 system processes the proxy code under business as usual standards. For example, the proxy code may take the form of
6
any conventional transaction device identifier and/or account number. The merchant system thereby stores the proxy code in the place of the information ordinarily stored under conventional processing methods. Since the proxy code does not include sensitive information, no sensitive information is stolen should the merchant system be compromised. In this way, the account issuer substantially eliminates, minimizes and/or controls the risks associated with the security of the merchant system being compromised (e.g., fraudulent transactions, identity theft, etc.). In alternative embodiments, the system and method also contemplates that certain sensitive information may be provided to the merchant, the merchant system may be partially re-configured to handle special data, and/or any other desired customization may be implemented.
Another advantage of an embodiment of the present invention is that since the proxy code is permanently associated to a transaction account, the proxy code need never be modified in the merchant system. As such, the present invention eliminates or reduces the need to update information on the merchant system every time the related transaction device is lost, stolen, or replaced. More particularly, the replacement device is provided the identical proxy code as was provided to the original transaction device. Consequently, the merchant is provided the identical proxy code in any instance where the user wishes to complete a transaction using the transaction account, which the account provider has permanently associated with the proxy code. When the transaction is sent to the account provider for reconciliation, the account provider determines that the proxy code correlates to the replacement device and not the original transaction device.
For example, the merchant receives the proxy code and stores the proxy code related to a recurrent billing account such as a telephone account. Periodically the merchant may bill a transaction device user in accordance with the telephone services provided. The device user may wish to provide the merchant with transaction device information the merchant may use to satisfy the bill. The user authorizes the merchant to store the device information for repeated use in satisfying the bill. In a conventional recurrent billing environment, the device information is ordinarily updated when the user loses the device or the device information expires. That is, the replacement device often is given device information, which is often different from the information contained on the original transaction device. However, in accordance with the present invention, the merchant need not update transaction device information because the proxy code is permanently associated with the transaction account. In other embodiments, the proxy code may be temporarily or periodically associated with the transaction account.
FIG. 1 illustrates an exemplary RFID transaction system 100 in accordance with the present invention, wherein exemplary components for use in completing a RF transaction are depicted. In general, system 100 includes a RFID transaction device 102 in RF communication with a RFID reader 104 for transmitting data there between. RFID reader 104 is in further communication with a merchant POS device 106 for providing to POS 106 information received from RFID transaction device 102. POS 106 is in further communication with a merchant system 101, which includes a merchant database 103. Merchant system 101 is in communication with an acquirer 110 and/or account issuer 112 via a network 108 for transmitting transaction request data and receiving authorization concerning transaction completion.
Although POS 106 is described herein with respect to a merchant POS device, the invention is not to be so limited. Indeed, a merchant POS device is used herein by way of example, and POS device 106 is any device capable of receiv
|
