Signature based negative list for off line payment device validation
AssigneeVisa U.S.A. Inc.
InventorsPhil Dixon, Ayman Hammad, William Alexander Thaw, Christian Aabye
Life of this patent
Estimating the term…
Loading patent…
AssigneeVisa U.S.A. Inc.
InventorsPhil Dixon, Ayman Hammad, William Alexander Thaw, Christian Aabye
Estimating the term…
At each of a plurality of transit readers of a transit system, for each of a plurality of riders, where each rider seeks to conduct an access transaction with the transit system for access into the transit facility by using a payment device issued by an issuer in a payment system, data is read from the payment device. The data includes an encryption code that uniquely corresponds to the payment device and was created by the issuer using one or more encryption keys and a predetermined algorithm. A check will be performed, remotely and/or locally, of one or more lists of other encryption codes to determine if the encryption code is on the list. On the basis of whether the encryption code is on the list, the rider is permitted access to the facility of the transit system. The payment device need not be changed for the rider's fare. Decryption of the encryption code read from the payment device is not required to complete the access transaction.
A method comprising a plurality of steps each being performed by hardware executing software, wherein the steps include:
A method comprising a plurality of steps each being performed by hardware executing software, wherein the steps include:
A method comprising a plurality of steps each being performed by hardware executing software, wherein the steps include:
Dependencies are inferred from the claim text.
Drawings are temporarily unavailable. Open the PDF at USPTO
From the US filing history. Foreign family members aren’t listed.
Transaction verification: involving fraud or risk level assessment in transaction processing
Involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]: involving a payment switch or gateway
Payment architectures, schemes or protocols: payment circuits
Payment architectures: involving remote charge determination or related payment systems
About 10 months of term left · ends 20 Aug 2027 (estimated)
The present invention relates generally to financial transactions, particularly to customers requesting financial transactions with merchants, and more particularly to financial transactions conducted with a financial institution portable payment device issued by a financial institution, such as a credit card that, that may be used both in a retail transaction and in a transit fare transaction.
Portable payment devices can take many forms and are used in a great variety of financial transactions. The portable payment devices can comprise, for example, smart cards, payment tokens, credit cards, debit cards, stored value cards, pre-paid cards contactless cards, cellular telephones, Personal Digital Assistant (PDA) devices, key fobs, or smart cards. The financial transactions can involve, for example, retail purchases, transit fares, access to venue fares, etc. In all such transactions, the portable payment device users (consumers) are concerned with convenience and the merchants with whom they deal are concerned with ease of transacting with their customer-consumers.
Preferably, financial institution portable payment devices issued by a financial institution (FIPPD) are used in an on-line fashion (e.g., a point of service that is connected to a payment processing system during a transaction). The information from the FIPPD may be transmitted on-line to an issuer during a retail payment transaction for purposes of authorizing the use of the FIPPD for that transaction. The issuer may review parameters of the transaction such as transaction amount, credit history, card authenticity, and other factors when determining whether or not to authorize or decline the transaction.
The subject invention will be described in the context of the appended drawing figures, where the same numbers are used throughout the disclosure and figures to reference like components and features:
FIG. 1 is a block level diagram illustrating an exemplary payment processing system;
FIG. 2 is a block level diagram illustrating an exemplary closed transit processing system;
Implementations facilitate the protection of cardholder information used to validate a transaction between a merchant and consumer. The cardholder information is transformed by the merchant through the use of a card signature. The transformed cardholder information can be checked against one or more lists kept remote from both the issuer of the cardholder information and remote from a point of service terminal at which the consumer transacts with the merchant. The cardholder information stored on a payment device and used by the consumer need not be altered during the transaction.
The card signature can be a cryptographic value, such as one that is based on encryption keys and an algorithm that is personalized (stored) on a contactless card by the issuer of the payment card, payment device, etc. The card signature, for instance, can be calculated and validated at the payment device (such as a Point of Sale (POS) terminal, a transit agency fare box, a vending machine, etc.), thus providing a mechanism to detect and prevent the use of counterfeit cards that will not contain the proper cryptographic value. Here, this mechanism prevents the use of counterfeit cards because the card was not created with the proper algorithm or keys. Rather, the card signature value will be based on some set of data, such as a value that is unique to each card and can be calculated based on encryption techniques. The card signature number can be a type of encryptogram based on specific card data, algorithm, and keys. The number (i.e.; the signature) that is used in the negative listing process can be designed such that is would not resemble a payment account number and would not be accepted in any payment environment.
Example off-line environments include transit fare collection, taxi cabs fare payment, vending machines payments, venue access, parking meters or machines, and other applications that may not have connectivity or the necessary time required in order to on-line to the issuer of the payment device offered by the consumer (e.g.; the cardholder) for payment.