US20180315050A1 - Secure communication of payment information to merchants using a verification token - Google Patents
Secure communication of payment information to merchants using a verification token Download PDFInfo
- Publication number
- US20180315050A1 US20180315050A1 US16/028,941 US201816028941A US2018315050A1 US 20180315050 A1 US20180315050 A1 US 20180315050A1 US 201816028941 A US201816028941 A US 201816028941A US 2018315050 A1 US2018315050 A1 US 2018315050A1
- Authority
- US
- United States
- Prior art keywords
- merchant
- identification information
- computer
- token
- validation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/42—User authentication using separate channels for security data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3226—Use of secure elements separate from M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
- G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4018—Transaction verification using the card verification value [CVV] associated with the card
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
- G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
Definitions
- Skimming refers to the electronic copying of a card's magnetic stripe data to create counterfeit cards.
- Skimming is predominantly a phenomenon afflicting magnetic stripe-based transactions. This is because the magnetic stripe, which is placed on the back of a transaction card and stores a variety of data on three separate tracks, is a passive medium. In other words, the digital content of the magnetic stripe can be perfectly copied, without any difference between the copy and the original.
- skimming One of the primary means by which skimming can be prevented is for the consumer to closely monitor the whereabouts of his transaction card. This may allow the consumer to prevent the card from being swiped through inappropriate devices.
- contactless cards evolve, the classic skimming problem comes along with it.
- a potential skimmer need not physically possess the card to be skimmed nor have access to any of the physical equipment (e.g., POS terminal, communication lines, etc.) which is required for skimming in a wire-based environment.
- a skimmer can, without the knowledge of the consumer or merchant, intercept the wireless transaction and copy the data being transmitted from the card to POS terminal. Similar types of interceptions can occur for online purchases.
- a dCVV or a dynamic card verification value can be used.
- various systems and methods for generating dCVV's are discussed in U.S. patent application Ser. No. 10/642,878 entitled “Method and System for Generating a Dynamic Verification Value” filed on Aug. 18, 2003, and in U.S. patent application Ser. No. 11/764,376 entitled “On-Line Payment Transactions” filed on Jan. 29, 2008. Both of these applications are incorporated herein by reference in their entirely for all purposes.
- a dCVV can be more effective for preventing fraud when it is securely received by a consumer.
- securely receiving and using a dCVV cannot overly interfere with a consumer's experience conducting a transaction. A consumer might not use the dCVV or a consumer might conduct fewer transactions if the inconvenience of receiving and using a dCVV is too great.
- Embodiments of the invention are directed to addressing the above problems, and other problems, individually and collectively.
- One embodiment of the invention is directed to a verification token that reads identification information from a portable consumer device and securely provides the identification information to a validation entity.
- the exemplary verification token comprises a peripheral interface adapted to couple to a peripheral interface of a computer, a reader adapted to read identification information from portable consumer devices, a computer-readable medium, a data processor electrically coupled to the token's peripheral interface, reader, and the computer-readable medium, and code embodied on the computer-readable medium that directs the data processor to perform various actions.
- the verification token comprises code that directs the data processor to communicate with a computer by way of the apparatus' peripheral interface and to access to a networking facility of the computer, code embodied on the computer-readable medium that directs the data processor to transmit at least a portion of identification information to the validation entity by way of the networking facility of the computer, the at least a portion of the identification information preferably being transmitted in encrypted form.
- the verification token also receives a uniform resource identifier (URID) to the validation entity from the portable consumer device, as read by the token's reader.
- the uniform resource identifier may comprise a conventional uniform resource locator (URL), an internet-protocol address (IP-address), or any other type of identifier that can identify an entity on a communications network.
- the validation entity receives the identification information from the verification token, and sends the identification information to a merchant.
- the validation entity may validate the identification information before sending the identification information to the merchant.
- the validation entity may be associated with, operated by, and/or owned by the merchant.
- the portable consumer device may be associated with the merchant, co-branded by the merchant and an issuing bank, and/or provided by the merchant.
- the merchant may correlate the identification information it receives from the validation entity with an online transaction being conducted at the merchant's website, and may use the identification information to process the online transaction.
- a portion of the account number of the portable consumer device is associated with a particular merchant, such as in the case of a co-branded credit card (e.g., co-branded between the merchant and an issuing bank).
- the validation entity can determine the merchant identity by comparing a selected portion of each account number it receives against a list numbers of known co-branded cards, and send the identification information to the merchant determined by the comparison action.
- the validation entity may validate the identification information before sending the identification information to the merchant, or it may leave that action to the merchant's website to perform.
- the verification token comprises a uniform resource identifier (URID) to the validation entity, or receives such a URID from the portable consumer device.
- the verification token further comprises code that directs the data processor to obtain an merchant identifier that identifiers a merchant, and sends the merchant identifier to the validation entity along with the at least a portion of the identification information read from the portable consumer device.
- the validation entity uses the merchant identifier to send the received identification information read from the portable consumer device to the merchant.
- the validation entity may validate the received identification information before sending it to the merchant.
- the validation entity may be associated with, operated by, and/or owned by a payment processing network, an issuing bank, or a third party.
- the merchant identification information may comprise a uniform resource identifier (URID) to the merchant.
- Another embodiment of the invention is directed to a method comprising: establishing a communication link between a verification token and a computer, the establishing a communication link between a verification token and a computer, the computer having a networking facility, an Internet browser, and a display having a merchant web page of a merchant displayed thereon by the Internet browser; reading identification information from a portable consumer device into the verification token; transmitting, using the networking facility of the computer, at least a portion of the read identification information from the verification token to an entity that can provide at least a portion of the read identification information to the merchant.
- Another embodiment of the invention is directed to a method comprising: coupling a verification token to a first computer using a peripheral interface of the first computer, the first computer having a networking facility and a display, the verification token comprising a peripheral interface adapted to couple to the peripheral interface of the first computer, a reader adapted to read identification information from portable consumer devices, a computer-readable medium, and a data processor, the verification token being configured to read identification information of a portable consumer device using the reader and to send at least a portion of the read identification information to a validation entity using the networking facility of the first computer; displaying a merchant web page on the first computer's display, the merchant web page being provided by a second computer; and presenting a portable consumer device to the reader of the verification token to send identification information contained in the portable consumer device to the merchant via the validation entity, wherein the validation entity is different from the first and second computers.
- Another embodiment of the invention is directed to a computer program product embodied on a tangible computer-readable medium that can be used by a validation entity.
- the exemplary computer program product comprises: code embodied on the computer-readable medium that directs a data processor to communicate with a verification token over a communications network with a computer disposed between the verification token and the communications network, the verification token being coupled to the computer by way of a peripheral interface of the computer and configured to access a networking facility of the computer, the verification token being configured to read a portable consumer device for identification information, and to cause at least a portion of the identification information to be sent to the data processor using the networking facility of the computer; code embodied on the computer-readable medium that directs a data processor to receive identification information sent by the verification token; and code embodied on the computer-readable medium that directs a data processor to send data representative of at least a portion of the received identification information to a merchant computer.
- Another embodiment of the invention is directed to a computer program product embodied on a tangible computer-readable medium that can be used by a validation entity.
- the exemplary computer program product comprises: code embodied on the computer-readable medium that directs a data processor to receive identification information of a portable consumer device read and sent by a verification token over a communications network with a computer disposed between the verification token and the communications network, the verification token being coupled to the computer by way of a peripheral interface of the computer and configured to access a networking facility of the computer; code that directs a data processor to apply at least one validation test on a piece of information sent by the verification token, the validation test producing a result of pass or fall; and code that directs a data processor to send, if the result of the at least one validation test is pass, data representative of at least a portion of the received identification information to a merchant computer.
- Another embodiment of the invention is directed to a method that can be used by a validation entity.
- the exemplary method comprises: receiving, at a server, identification information of a portable consumer device read and sent by a verification token over a communications network with a computer disposed between the verification token and the communications network, the verification token being coupled to the computer by way of a peripheral interface of the computer and configured to access a networking facility of the computer; selecting a merchant to send at least a portion of the received identification information to; and sending, from the server, data representative of at least a portion of the received identification information to a computer of the selected merchant.
- Another embodiment of the invention is directed to a computer program product embodied on a tangible computer-readable medium that can be used by a merchant computer system.
- the exemplary computer program product comprises: code embodied on the computer-readable medium that directs a data processor to present a website portal providing various web pages that enable a plurality of users to select at least one product or service for purchase, the code directing the data processor to create an active purchase session for each user that is actively pursuing a purchase; code embodied on the computer-readable medium that directs a data processor to receive messages from one or more validation entities, each validation message including data representative of at least a portion of the identification information of a portable consumer device; and code embodied on the computer-readable medium that directs a data processor to correlate the data received in a message from a validation entity to an active purchase session.
- the exemplary system comprises a first component that communicates with a verification token over a communications network with a computer disposed between the verification token and the communications network, the verification token being coupled to the computer by way of a peripheral interface of the computer and configured to access a networking facility of the computer, the verification token being configured to read a portable consumer device for identification information, and to cause at least a portion of the identification information to be sent in encrypted form to the first component using the networking facility of the computer, the first component receives encrypted identification information sent by the verification token and decrypts the encrypted identification information.
- the system further comprises a second component that processes purchases from consumers over a communications network, and that receives data representative of decrypted identification information from the first component; the second component correlating the data received from the first component with a purchase that is it processing.
- Another embodiment of the invention is directed to a method that can be used by a merchant computer system.
- the exemplary method comprises: presenting, from a server, a website portal providing various web pages that enable a plurality of users to select at least one product or service for purchase, the code directing the data processor to create an active purchase session for each user that is actively pursuing a purchase; receiving messages from one or more validation entities, each validation message including data representative of at least a portion of the identification information of a portable consumer device; and correlating the data received in a message from a validation entity to an active purchase session.
- the communications between the computer and the validation entity may be facilitated by, and/or conveyed through, a gateway (e.g., a proxy server, server entity, etc.) that is disposed between the computer and the validation entity.
- the gateway may act as an intermediary between a plurality of verification tokens and their associated computers on the one side, and a plurality of validation entities on the other side.
- the gateway may receive one or more initial communications from a verification token (via a computer in communication with the token), and may determine from information in the one or more initial communications an appropriate one of the validation entities to use to fulfill the token's request.
- each verification token may be configured to operate with portable consumer devices issued by many different issuing banks or other such entities, and one or more of the validation entities may be configured to process requests from portable consumer devices issued by respective issuing banks or other such entities.
- the gateway may determine an appropriate one of validation entities to use based upon the identification information that the token read from a portable consumer device and sent to the gateway in an initial communication. In one implementation, the gateway redirects the token to the determined appropriate validation entity, with further communications occurring directly between the verification token and the appropriate validation entity. In another implementation, the communications between the verification token and the appropriate validation entity may be conveyed through the gateway (after the gateway has initially determined the identity of the appropriate validation entity based upon one or more initial communications with the token).
- This latter implementation may comprise relatively simple passing through of communications between the token and the appropriate validation entity with minimal processing by the gateway, or may comprise having the gateway virtually present itself as the appropriate validation entity to the verification token.
- Such virtual presentation may involve the gateway decrypting each message from the verification token, communicating with the appropriate validation entity to formulate a response to the token's message, and encrypting and sending a response message to the verification token.
- the gateway may also conduct one or more validation tests on behalf of the appropriate validation entity, particularly those related to validating the verification token. In this case, the gateway does not need to send to the appropriate validation entity those communications it receives from the token that pertain to validation tests that the gateway is handling.
- the gateway may be associated with, or operated by, a payment processing network.
- FIG. 1 illustrates some exemplary embodiments of the invention.
- FIG. 2 illustrates an exemplary method embodiment that can be used by a verification token.
- FIG. 3 illustrates an exemplary method embodiment that can be used by a user of a verification token.
- FIG. 4 illustrates an exemplary method embodiment that can be used by a validation entity.
- FIG. 5 illustrates an exemplary implementation of a computer-readable memory that can be used by a verification token.
- FIG. 6 illustrates an verification token and computer using USB connectors in the peripheral interfaces.
- FIG. 7 illustrates an exemplary identification information that can be send by a verification token and used by a validation entity.
- FIG. 8 illustrates an exemplary merchant computer.
- FIG. 9 illustrates additional exemplary embodiments of the invention.
- Embodiments disclosed herein pertain to the secure communication of identification information (e.g., payment information) of portable consumer devices to merchants.
- a portable consumer device comprises a device that holds identification information pertaining to an account held by a user with another entity, which is typically an entity that holds, extends, or credits items of value to the user (e.g., monetary funds, credits, debts, etc.).
- Portable consumer devices encompass credit cards, charge cards, debit cards, bank cards, prepaid cards, and other cards that identify an account held by a user with another entity.
- the cards are capable of existing in both passive forms (e.g., card with a magnetic stripe) and active forms (e.g., integrated circuit cards or smartcards), and further encompass portable electronic devices that, in whole or in part, function as such cards.
- Such portable electronic devices can include memory cards, account tokens, fobs, stickers, cellular telephones (including near-field communications phone), keychain devices (such as the SpeedpassTM commercially available from Exxon-Mobil Corp.), personal digital assistants, transponders, smart media, pagers, and other mobile electronic devices.
- memory cards account tokens, fobs, stickers, cellular telephones (including near-field communications phone), keychain devices (such as the SpeedpassTM commercially available from Exxon-Mobil Corp.), personal digital assistants, transponders, smart media, pagers, and other mobile electronic devices.
- the identification information held by (e.g., embodied on) a consumer portable device comprises at least an account number, and preferably at least one of the following: a digital fingerprint of a magnetic stripe of the portable consumer device, or a variable datum that varies each time the portable consumer device is read for its identification information, as illustrated in FIG. 7 .
- the magnetic stripe carries at least the account number of the device.
- the account number identifies the consumer account within at least one payment processing network, and may comprise a primary account number (PAN); it may also comprise alphanumeric characters.
- PAN primary account number
- the digital fingerprint of the magnetic stripe is representative of the distribution of magnetic particles that form the magnetic stripe, and is generated by a specialized card reader that samples the distribution of magnetic particles when the card is swiped.
- variable datum may comprise number characters, alphanumeric characters, or a cryptogram (e.g., cryptograph 17 ).
- the values of the variable datum vary in a way that is known to both the portable consumer device and an authorization entity, the latter of which may be an issuing bank or a payment processing network.
- the variable datum encompasses the dynamic CVV (“dCVV”) and CVC3 card verification values generated by smartcards (both the contact and contactless forms), as well as cryptograms generated by many smartcards (e.g., cryptogram 17 ).
- the datum values may be pre-stored in a computer-readable medium of the device and In a computer-readable medium of the authorization entity, or may be generated by each of the device and the entity as needed (e.g., “generated on the fly”) using a confidential algorithm known to the device and the entity or by a known algorithm that uses confidential keys or confidential information.
- the variable datum may comprise, or may be accompanied by, a counter value that indicates the number of times the portable consumer device has generated the variable datum; the counter value may assist the authorization entity in retrieving the variable datum from the entity's computer-readable medium, or in generating the variable datum from the algorithm.
- a counter value is not necessary, and the authorization entity may deduce the number of times the device has generated the variable datum from the history of authorization requests made for the device, or an algorithm that does not require a counter may be used.
- the identification information may further comprise the name of the account holder (e.g., the user), the expiration date of the card, service codes, and discretionary data.
- the identification information may include the conventional “payment data” stored on the tracks of the magnetic stripe of a conventional credit card (e.g., Track 1, Track 2, and/or Track 3).
- the identification information of a portable consumer device is read by a reader, which is an electrical component that can read the identification information from a portable consumer device and provide the identification information to another electrical component.
- a reader may comprise one or more of the following: a magnetic stripe reader (which may include fingerprint sampling circuitry), a card contact reader, and a contactless reader, the latter of which is commonly known as an RFID reader (RFID being an acronym for radio-frequency identification).
- RFID reader RFID being an acronym for radio-frequency identification
- a reader for reading fingerprints of magnetic stripes may include a security module that comprises a proprietary algorithm that generates a digital fingerprint from the sampled fingerprint data and that encrypts the digital fingerprint with a nonce word using an encryption key. Readers are predominantly found at point-of-sales locations of merchants.
- a typical credit card transaction flow using a portable consumer device at a point-of-sales location is described next.
- the user's portable consumer device is provided to the user by or on behalf of an issuing bank.
- the issuing bank extends credit to the user, represents the user in credit card transactions, and pays merchants for the purchases made by the user.
- a user presents his or her portable consumer device to a merchant at a point-of-sales location to pay for an item or service.
- the merchant uses a reader to read the user's portable consumer device, and sends the identification information read from the device along with merchant's information and the transaction amount to an acquiring bank.
- the merchant may also read the portable consumer device for the printed card verification value (e.g., the CVV value printed on the backs of many credit cards), and may send this along as part of the transaction information sent to the acquiring bank.
- the acquiring bank represents, and vouches for, the merchant in credit card transactions.
- the acquiring bank forwards the transaction information to a payment processing network, such as VisaNetTM, for authorization.
- a payment processing network generally encompasses a collection of one or more data processing server computers, subsystems, networks, and operations used to support and deliver one or more of the following: authorization services, exception file services, and clearing and settlement services.
- Payment processing networks encompass bank processing networks, credit-card payment processing network, etc.
- An exemplary payment processing network may include VisaNetTM.
- Exemplary payment processing networks are able to process one or more of the following: credit-card transactions, debit-card transactions, and other types of commercial transactions.
- a payment processing network may use any suitable wired or wireless network, including the Internet, to communicate with acquiring banks and is
- the payment processing network Prior to the occurrence of a credit-card transaction, the payment processing network has established a protocol with each issuing bank on how the bank's transactions are to be authorized. In some cases, such as when the transaction amount is below a threshold value, the payment processing network will authorize the transaction based on information that it has about the user's account without consulting the issuing bank, and will accept the liability if the transaction turns out to be fraudulent. In other cases, such as when the transaction amount is above a threshold value, the payment processing network will forward the transaction information on to the issuing bank for verification and authorization. As part of the authorization process, the payment network or the issuing bank may verify the digital fingerprint or the varying datum provided by the portable consumer device.
- the digital fingerprint is stored at the issuing bank, and may be securely provided to the payment processing network by the issuing bank for storage and subsequent use.
- the algorithm for generating the varying datum is stored at the issuing bank, and may be securely provided to the payment processing network for storage and subsequent use.
- the payment network or the issuing bank may verify the printed card verification value (e.g., CVV), which is stored at the issuing bank, and may be securely provided by the issuing bank to the payment processing network for storage and subsequent use.
- CVV printed card verification value
- the degree to which the payment processing network is involved in the verification of the consumer portable device and the authorization of the transaction is typically configured according to the wishes of the issuing bank.
- the payment processing network sends an authorization indication to the acquiring bank, which sends the authorization indication on to the merchant.
- the payment processing network sends an authorization indication to the acquiring bank, which sends the authorization indication on to the merchant.
- merchants are not allowed to store digital fingerprints, variable datum, and printed card verification values (CVVs) for more than 24 hours.
- the user When a user wishes to make an online purchase with a merchant over the Internet, the user types in the credit card account number, cardholder name, expiration date, and the printed card verification value into respective fields on the merchant's checkout page.
- the card's magnetic fingerprint or the card's variable datum is not used in the transaction, and they are not available to the payment processing network or the issuing bank to aid in verifying that the card was actually present during the transaction. Accordingly, there is a greater risk of fraud with such online purchases. For example, a store clerk can copy down the account information and printed verification value during a transaction at a point-of-sales location, and can later use the copied information to make an online purchase.
- a hacker can install spyware on the user's computer to intercept the account information and printed verification value, and use it to make fraudulent purchases at other online merchants.
- Other avenues of potential fraud exist.
- Embodiments of the invention are directed to mitigating these types of fraudulent activity.
- FIG. 1 illustrates some exemplary embodiments of the invention In the context of an online purchase. A general overview description of the embodiments and components shown in the figure will be given, followed by more detailed descriptions. Shown in the figure are icons for a user 1 , the user's portable consumer device 5 , the user's communication device 7 (such as a cell phone), the user's computer 10 , the merchant's website 20 , and a first communications network 31 that enables the user's computer and the merchant's website to communicate with one another.
- the user's portable consumer device 5 such as a cell phone
- the user's communication device 7 such as a cell phone
- the first communications network 31 may include the Internet, a telecommunications network (e.g., a wireless network, cell phone network, a telephone network, a cable network, or any combination thereof), a wide area network (WAN), a local area network (LAN), a home router or gateway coupled to one of the above networks, or any combination of the above. Also shown in FIG. 1 is an acquiring bank 50 for the merchant, an issuing bank 60 for the portable consumer device 5 , a payment processing network 70 , and a second communications network 32 that enables the payment processing network 70 to communicate with each of the banks 50 and 60 .
- a telecommunications network e.g., a wireless network, cell phone network, a telephone network, a cable network, or any combination thereof
- WAN wide area network
- LAN local area network
- FIG. 1 Also shown in FIG. 1 is an acquiring bank 50 for the merchant, an issuing bank 60 for the portable consumer device 5 , a payment processing network 70 , and a second communications network 32 that enables the payment
- the second communications network 32 may comprise the Internet (and therefore may overlap and share facilities with the first communications network 31 ), or may comprise one or more private networks, or combination of one or more private networks with the Internet.
- a private network may comprise a telecommunications network, a wide area network (WAN), a local area network (LAN), or any combination thereof.
- the first and second communications networks 31 and 32 may be the same (such as a network using the Internet as the backbone).
- a communications network generally comprises a network of one or more communications links and two or more nodes that pass messages from one part of the network to another part. Each node comprises one or more pieces of electrical machinery, and each link may comprise one or more of the following: optical fibers, optical links, radio links, electrical wires. The components described so far are, for the most part, conventional and arranged in a conventional manner.
- FIG. 1 illustrates a verification token 40 according to one embodiment of the invention, and a validation entity 80 according to another embodiment of the invention. These components, and the interactions between them and between other components shown in FIG. 1 are novel, and do not form part of the prior art.
- Verification token 40 has a reader 44 to read portable consumer device 5 , and a peripheral interface 46 adapted to couple to a peripheral interface 16 of computer 10 .
- Reader 46 may comprise one or more of the following: a magnetic stripe reader (which may include fingerprint sampling circuitry and security module), a card contact reader, and a contactless reader, the latter of which is commonly known as an RFID reader.
- Verification token 40 is configured to communicate to validation entity 80 by way of a networking facility 14 of computer 10 .
- merchant website 20 e.g., merchant computer
- the user may bring up the merchant's checkout page to provide the user's payment information and commit to the purchase.
- user 1 presents his or her portable consumer device 5 to a card reader 44 of verification token 40 to provide the device's identification information (an example of which is illustrate in FIG. 7 ).
- the verification token 40 reads the identification information from the user's portable consumer device 5 , and sends at least a portion of the identification information in a secure manner (e.g., in an encrypted form) to validation entity 80 .
- Validation entity 80 preferably validates the identification information and/or validates the verification token 40 to ensure that the portable consumer device 5 was actually presented to verification token 40 , and securely forwards the identification information on to a transaction processing entity, such as a computer of merchant's website 20 , to be used in a purchase transaction if the identification information and/or token is validated.
- Validation entity 80 preferably applies one or more validation tests to verification token 40 and/or the identification information to obtain a level of confidence that the portable consumer device 5 was actually presented to verification token 40 to request the dCVV2 value.
- Validation entity 80 may have a stored record of the digital fingerprint of portable consumer device 5 or the algorithm for generating the variable datum of device 5 , and can validate the received identification information by comparing the fingerprint or variable datum provided in the received information with that read or recreated from its stored record for device 5 . In addition to this, or in place of this, validation entity 80 can validate the authenticity of verification token 40 , and trust the information sent by verification token 40 until a fraudulent attempt or incident occurs. When the one or more validation tests are passed, and preferably with no tests being failed, validation entity 80 forwards the identification information on to a transaction processing entity, such as a merchant's website 20 (also called merchant computer 20 , and merchant computer system 20 ).
- a transaction processing entity such as a merchant's website 20 (also called merchant computer 20 , and merchant computer system 20 ).
- validation entity 80 and merchant website 20 are part of a merchant system for a merchant that offers a co-branded credit card (e.g., co-branded portable consumer devices 5 ). This possibility is illustrated by the dashed line that connects validation entity 80 with merchant website 20 .
- the merchant system may be owned and operated by the merchant, or owned by another party and operated on behalf of the merchant.
- entity 80 may determine the identity of the merchant from some of the digits of the account number provided in the identification information, where such digits are assigned to a merchant of a cobranded credit card.
- validation entity 80 receives information that identifies a merchant (the “merchant identification information” or “merchant identifier”) from verification token 40 along with the identification information for device 5 , and, if valid, securely forwards data representative of the identification information for device 5 on to the merchant identified by the merchant identification information.
- the merchants may be screened and verified by validation entity 80 beforehand, and secure communication channels between entity 80 and the verified merchants may be established beforehand.
- the data representative of the identification information sent to the merchant by entity 80 may comprise a portion or all of the received and verified identification information, or may comprise a substitute account number that the merchant is to use in place of the PAN, or a payment-processing transaction number, or a combination of the above (e.g., card holder name, substitute account number, and payment-processing transaction number).
- user 1 does not need to input payment information into the merchant's checkout page.
- the data may be entered on the checkout page by merchant website 20 and displayed to the user on user interface 13 , with the account number and CVV value for device 5 being partially and/or fully masked with non-related characters, such as asterisks (e.g., “***”).
- user 1 may commit to the purchase transaction and complete the transaction by clicking on a “Submit” button or “Continue” button of the checkout page.
- Validation entity 80 may also provide the user's shipping and/or billing address (“address information”) to the merchant so that the user need not fill this information into the merchant's checkout page.
- Validation entity 80 may obtain the address information from verification token 40 , from the issuing bank 60 for device 5 , or from an account that user has set up with validation entity 80 (described below in greater detail).
- Merchant website 20 may use a number of techniques to correlate the data representative of the validated identification information that it receives from validation entity 80 with the active purchasing sessions that it is processing. First, if validation entity 80 and merchant website 20 are part of a merchant system, merchant website 20 may have previously established a secure (e.g., password protected) merchant account for user 1 , where the user has registered the account information for his or her portable consumer device 5 . In this case, merchant website 20 may compare the incoming validated identification information from validation entity 80 with the account information of the active purchasing sessions that it is handling to find a match.
- a secure e.g., password protected
- the merchant website 20 may have asked user 1 to provide a portion of the identification information of device 5 on its checkout page, such as the last four or five digits of the account number and account holder's last name. Merchant website 20 can compare this partial amount of information against the incoming identification information from validation entity 80 to make the correlations.
- merchant website 20 sends the data representative of the identification information, the purchase information, and the merchant information to acquiring bank 50 , which in turn sends the data and information to payment processing network 70 for authorization.
- This is known as an authorization request
- the data and information that merchant website 20 sends is known as the transaction information (e.g., the collection of the data representative of the identification information, the purchase information, and the merchant information).
- the data representative of the validated identification information sent to merchant website 20 by validation entity 80 may include an CVC3 value or dCVV value, as described above.
- Merchant website 20 may include this value with the transaction information sent to network 70 , and/or may include a printed CVV value with the transaction information, the printed CVV value being read from device 5 and entered on the merchant's checkout page by user 1 or token 40 .
- Payment processing network 70 and issuing bank 60 can then perform the actions that they normally perform to authorize the transaction, such as checking whether the merchant 20 is in good standing, and checking the account limit of user 1 to ensure that there are sufficient funds to cover the purchase price of the transaction, and checking the CVC3, dVCC, or CVV values.
- merchant 20 may provide an indication that the identification information was read by a verification token 40 and validated by validation entity 80 , which gives payment processing network 70 and issuing bank 60 an extra degree of assurance that the user's portable consumer device 5 was present during the transaction.
- validation entity 80 may convey an indication to payment processing network 70 that it validated device 5 's identification information for a transaction on merchant website 20 .
- the communication of the data representative of the identification information from verification token 40 to merchant 20 by way of validation entity 80 can be done in encrypted channels that are secure against a “man in the middle” attack that a fraudster may try on the user's computer 10 .
- the fraudster installs a “Trojan horse” program on the user's computer 10 that logs the user's key strokes one the computer's keyboard and sends them to the fraudster's computer
- the identification information e.g., credit card account number and card holder name
- the Trojan horse program cannot be obtained by the Trojan horse program since the information is not typed into the merchant's web page by the user, but is instead securely sent to merchant 20 by validation entity 80 .
- the identification information read from portable consumer device 5 may include a cryptogram (e.g., cryptogram 17 ) generated by the device as the variable datum.
- card reader 44 provides the user's device 5 with “dummy” transaction information that is known to both token 40 and validation entity 80 .
- the dummy transaction information may include a static transaction amount and a static merchant name, depending upon the type of cryptogram to be generated.
- the dummy transaction information may be different for each token 40 .
- the user's device 5 uses the transaction information to generate the cryptogram.
- the user's device typically has a counter value, often called the Application Transaction Counter (ATC), which is included in the cryptogram computation, and which is incremented with each transaction.
- ATC Application Transaction Counter
- token 40 may display a pop-up window on the user's computer 10 that requests the entry of a PIN by the user, and token 40 may provide the pin to the user's device 5 along with the request for the cryptogram.
- validation entity 80 may obtain a dynamic device verification value for the portable consumer device 5 as part of validating the device's identification information.
- this device verification value is referred to as a “dCVV2” value, so as to distinguish it from the following: (1) the “CVC3” or “dCVV” values generated by smartcards (described above), (2) the printed CVV values found on the backs of credit cards, and (3) the CVV field found on the merchant's checkout page.
- the dCVV2 value comprises a variable datum (e.g., a multi-digit number), and can be used to complete the purchase transaction.
- Validation entity 80 may obtain the dCVV2 value by generating it from pre-stored data, or by receiving it from payment processing network 70 or issuing bank 60 in response to a request for it. If it did not receive the dCCV2 value from processing network 70 , validation entity 80 provides the dCVV2 value to payment processing network 70 , along with the identification information of device 5 so that network 70 can correlate the dCVV2 value to the user's account. Validation entity 80 also provides the dCVV2 value to one or both of merchant 20 and verification token 20 .
- token 40 may fill in the CVV field found on the merchant's checkout page with the provided dCVV2 value, or may display the provided dCVV2 value to user 1 so that the user can fill in the CVV field with the dCVV2 value. If the dCVV2 value is provided to merchant 20 , merchant 20 may fill in the CVV field on the merchant's own checkout page with the provided dCVV2 value, or may check it against the value entered on its checkout page by user 1 or token 40 to gain further assurance for itself that device 5 was present during the transaction. In either case, the dCVV2 value reaches both the merchant 20 and payment processing network 70 .
- merchant 20 sends the dCVV2 value along with the user's payment information (e.g., the data representative of identification information of device 5 ), merchant information, and transaction information to network 70 (via its acquiring bank) as part of its authorization request for the transaction.
- the user's payment information e.g., the data representative of identification information of device 5
- merchant information e.g., the data representative of identification information of device 5
- transaction information e.g., the data representative of identification information of device 5
- network 70 via its acquiring bank
- payment processing network 70 can compare incoming authorization requests from merchants (such as forwarded by acquiring banks) against the information it receives from validation entity 80 (such as by looking at account numbers), and can match (e.g., correlate) incoming authorization requests with validation information and dCVV2 values previously sent to it by validation entity 80 . If a match between the dCVV2 value provided in an authorization request and the dCVV2 value previously provided by entity 80 is found, then payment processing network 70 has a very high degree of assurance that consumer portable device 5 was present and in the possession of user 1 at the time the purchase transaction was made. This provides a greater degree of assurance in comparison to the reliance on CCV values printed on the backs of credit cards.
- Payment processing network 70 and issuing bank 60 can then undertake the other actions that they perform to authorize the transaction, such as those described above. In these implementations where dCVV2 values are used, payment processing network 70 does not need to validate the digital fingerprint and/or the variable datum of the portable consumer device 5 , if those actions have been done by validation entity 80 . (Payment processing network 70 may, however, perform those validate actions for merchant point-of-sales transactions.)
- the identification information that token 40 collects and provides to validation entity 80 may include a device identifier alone with the account number. This device identifier uniquely identifies one of the devices allocated under the account number. Provision entity 80 may further use the device identifier to obtain different dCVV2 values for the different devices allocated under the account number.
- a first validation test that validation entity 80 may apply pertains to verifying that verification token 40 is authentic.
- verification token 40 may send its serial number to validation entity 80 , along with a message encrypted by an encryption key, with the message and encryption key being known to token 40 and entity 80 (but not the general public), and with the encryption key further being uniquely assigned to the token's serial number (uniquely assigned to the token).
- Validation entity 80 has a database of serial numbers and corresponding uniquely assigned encryption keys, and can validate that verification token 40 has sent the correct message for the serial number. Validation of the correct message serves to authenticate verification token 40 .
- validation entity 80 may record the serial number of the failed token 40 and the source IP address from which the failed token 40 made the request in a database (such as a database 86 described below).
- a second validation test that validation entity 80 may apply pertains to verifying that verification token 40 has not been involved in fraudulent transactions.
- validation entity 80 may also have a database that tracks the serial numbers of verification tokens that have been used In fraudulent activities, and may check the serial number of verification token 40 against this database.
- the second validation test may further comprise checking the token serial number and/or the IP address from which an incoming dCVV2 request was originated (the source IP address of the message) against the previously-described database that stores token serial numbers and IP addresses associated with requests that have failed the first validation test.
- the second validation test may be deemed to have been failed. Checking the token serial numbers and/or the IP addresses in this way prevents replay attacks by fraudsters. It may be appreciated that the database of serial numbers of tokens that failed the first validation test may be combined with the database of serial numbers of tokens involved in fraudulent activities. This combined database, as well as the two other databases, may be generically termed as a database of serial numbers of suspicious tokens. Additional validation tests are described below in greater detail.
- FIG. 1 Embodiments and components shown in FIG. 1 are now described in greater detail.
- the user's computer 10 may comprise a desktop computer, a laptop computer, or any portable electronic device that has a networking facility and a peripheral interface for communicating with one or more peripheral devices.
- Computer 10 has one or more processors 11 , a tangible computer-readable medium 12 coupled to processor(s) 11 that stores instruction codes (software) that direct processor(s) 11 and that stores data used by processor(s) 11 , and a user interface 13 coupled to processor(s) 11 .
- Networking facility 14 and peripheral interface 16 which were previously described above, are also coupled to processor(s) 11 , with networking facility 14 also being coupled to first communications network 31 .
- User interface 13 comprises one or more video output devices (e.g., displays, screens) and one or more input devices (e.g., keyboard, mouse, trackball, etc.) for user 1 to receive information from computer 10 and to provide input to computer 10 .
- Computer-readable medium 12 may comprise a combination of semiconductor memory and non-volatile storage, such as one or more disk drives and/or non-volatile memory.
- Computer-readable medium 12 stores an operating system for computer 10 , which enables processes and applications to, be run by processor(s) 11 .
- the operating system provides services to these processes and applications, and enables these processes and applications to access components of user interface 13 , portions of computer-readable medium 12 , networking facility 14 , peripheral interface 16 , and other components of computer 10 .
- the operating system may be complex and full featured, such as found on desk-top computers, or simplified, such as found on cell phones, PDAs, and many other types of portable electronic devices.
- Networking facility 14 of computer 10 may comprise software and hardware that enable a process running on computer 10 to communicate with a communications network, such as network 31 , to send and receive messages, data, and the like to one or more entities coupled to the communications network.
- the hardware of facility 14 may comprise dedicated hardware separate from processor(s) 11 , or the shared use of processor(s) 11 , or a combination thereof.
- the software of facility 14 may comprise firmware, software stored in computer-readable medium 12 or another computer-readable medium, portions of the operating system, or a combination of any of the preceding items.
- Networking facility 14 is preferably a non-exclusive resource, allowing access to the communications network by other processes and applications being run by computer 10 .
- Peripheral interface 16 of computer 10 comprises a wired or wireless connection that enables a peripheral device (separate from computer 10 ) to communicate with the computer.
- Conventional wired connections include universal serial bus (USB) connectors (“USB ports”), serial ports, parallel ports, and PCMCIA ports.
- Conventional wireless connections include infra-red (IR) base stations and BluetoothTM base stations that are built into computer 10 or that are coupled to a peripheral interface of computer 10 .
- IR infra-red
- verification token 40 further comprises a processor 41 , a tangible computer-readable medium 42 coupled to processor 41 holding data and codes that direct the operation of processor 41 , a security module 43 coupled to processor 41 and adapted to securely store one or more encryption keys and to encrypt and decrypt data for token 40 , a reader 44 coupled to processor 41 and adapted to read portable consumer devices 5 , and a peripheral interface 46 coupled to processor 41 and adapted to communicate to computer 10 by way of peripheral interface 16 .
- Processor 41 may comprise a conventional microprocessor
- computer-readable medium 42 may comprise a combination of semiconductor memory and non-volatile storage, such non-volatile memory.
- security module 43 may comprise encryption and decryption circuitry (which may include one or more processors), and may comprise one or more encryption keys stored in a secured memory. Security module 43 may also include firewall security circuitry that protects verification token 40 from attacks from hackers conducted through peripheral interface 16 .
- Reader 44 may comprise a convention reader, as described above.
- Peripheral interface 46 may comprise a wired or wireless connection adapted to communicate with peripheral interface 16 of computer 10 .
- verification token 40 may be detachably coupled to computer 10 at peripheral interface 16 , such as at a USB port connector.
- FIG. 6 illustrates an exemplary verification token 40 - 1 with a USB port connector (male type) as part of its peripheral interface 46 - 1 . Also illustrate in FIG.
- Token 40 may further include a visual indicator, such as a light-emitting diode (LED), that it lights when it is ready to read a user's device 5 , and may further include an audible indicator, such as a piezoelectric buzzer, that sounds when token 40 is finished with reading a user's device 5 .
- the visual and audible indicators may be operated by the circuitry of reader 44 . In other implementations, one or more of these indicators may be operated by processor 41 through I/O commands.
- verification token 40 further comprises various codes embodied on computer-readable medium 42 that direct data processor 41 to perform respective actions (e.g., processor codes shown in FIG. 5 ).
- a first code directs data processor 41 to communicate with computer 10 by way of peripheral interface 46 so as to gain access networking facility 14 of computer 10 .
- the first code may comprise code that directs data processor 41 to send a device driver to computer 10 and an instruction to install the device driver in the computer's operating system, wherein the device driver is a collection of instructions to be run by computer 10 that enables computer 10 to recognize the verification token and communicate with the verification token 40 , and enables the token's data processor 41 to make function calls to various application program interfaces (API's) of the computer's operating system, such as those related to networking and accessing networking facility 14 .
- API's application program interfaces
- So called “self-installing” drivers are known to the art, and can be used here. They comprise one or more function calls to an application programming interface (API) of the computer's operating system, such as the device manager's API.
- API application programming interface
- the first code may be configured to work with a selected operating system, such as Windows or Symbian OS, or may be configured to work with several operating systems. In the latter case, the first code may include several device drivers for the various operating systems, and instructions that query computer 10 for its operating system type and select (and install) the driver most appropriate for the computer's operating system.
- the device drivers may be stored in a section of computer-readable medium 42 , as illustrated in the example of FIG. 5 .
- the first code may further include, as an option, instructions that direct processor 41 to generate an I/O signal that causes the above-described visual indicator to be lit in response to processor 41 gaining access to networking facility 14 of computer 10 .
- a second code of verification token 40 directs data processor 41 to receive identification information read from portable consumer device 5 by the reader 44 .
- the second code may include code that directs the data processor 41 to receive a universal resource identifier (URID) of a validation entity 80 , as read from portable consumer device 5 by the reader 44 .
- the second code may comprise instructions that direct processor 41 to contact reader 44 at periodic intervals through an I/O command to determine if the reader has any data for the processor, and to read the data when data is indicated as being present.
- the second code may further direct processor 41 to contact reader 44 through an I/O command to clear the data after processor 41 has read it, or reader 44 may be configured to clear the data after it has sensed that processor 41 has read it, or after a period of time greater than the periodic contact interval used by processor 41 .
- reader 44 may be configured to generate an interrupt signal to processor 41 when data is present, and the second code may include instructions that direct processor 41 to respond to the interrupt signal by reading the data from reader 44 and clearing the interrupt.
- the second code may further include, as an option, instructions that direct processor 41 to generate an I/O signal that causes the above-described audible indicator to sound in response to processor 41 receiving data from reader 44 .
- the above instructions may include conventional I/O instructions that direct the communications with reader 44 and the indicators.
- a uniform resource identifier may comprise a uniform resource locator (URL), an Internet-protocol address (IP-address), or any other type of identifier that can identify an entity on a communications network.
- verification token 40 may store a URID to a default validation entity 80 .
- some verification tokens 40 may be co-branded with respective issuing banks and/or co-branded merchants, and only work for portable consumer devices that are co-branded with the same issuing banks/merchants, and each issuing bank/merchant may have its own validation entity 80 with its own URID.
- these verification tokens 40 may store the URIDs to their respective co-branded validation entities 80 .
- some verification tokens 40 may be associated with respective payment processing networks 70 , and each such network may have its own validation entity 80 .
- these verification tokens 40 may store the URIDs to their respective associated validation entities 80 .
- the second code of verification token 40 may be further configured to direct data processor 41 to only use a default URID stored by token 40 , or to use a default URID if consumer portable device 5 does not provide token 40 with a URID to entity 80 .
- verification token 40 may include code that directs processor 41 to select one of a number of URIDs stored in token 40 based on a bank number provided in the identification information or embedded in the account number.
- the above further direction and codes may be implemented with conventional I/O instructions, memory access instructions, and CPU logical and control instructions.
- One or more URIDs to validation entities may be stored in computer-readable memory 42 , as illustrated in the example shown in FIG. 5 .
- a third code of verification token 40 directs data processor 41 to establish communications with validation entity 80 using networking facility 14 of computer 10 .
- the operating system of computer 10 comprises one or more software modules and application programs, generically called “network services modules” herein, that can access networking facility 14 and set up communications sessions to entities on communications network 31 .
- network services modules include Microsoft's Windows Communications Foundation (e.g., .NET 3.0, .NET 4.0, etc.), Apple's CFNetwork Framework, the networking section of the Unix and Linux operating system kernels, the OS Services Layer and the Base Services Layer of the Symbian operating system, internet browsers, and the like.
- Each of these network services modules is non-exclusive (e.g., capable of serving more than one processor and more than one process/application) and provides an application programming interface (API) to a collection of functions that a processor can access using respective function calls.
- API application programming interface
- a collection of function calls can be readily constructed for a processor to execute that enables the processor to establish a communications channel with an entity on a communications network coupled to networking facility 14 , and to exchange messages and data with the entity.
- the third code of verification token 40 comprises such a collection of function calls to the API of a network services module of computer 10 , including one or more function calls that provide the universal resource identifier (URID) for validation entity 80 and an instruction to establish a session with the validation entity.
- UID universal resource identifier
- the session may be a secure socket layer (or secure transport layer) session (e.g., SSL session) with mutual authentication.
- the third code of verification token 40 may include directing data processor 41 to provide, or to cause to be provided, a network address for the token to the computer's network services module and to validation entity 80 .
- the network address may be static or dynamic, the latter of which may be obtained through API function calls to the computer's network services module.
- the network address may an IP address.
- token 40 may further comprise API function calls to the computer's operating system to initiate an instance of the browser and provide it with access to the browser instance.
- the third code may direct the data processor 41 to establish communications with validation entity 80 well before user 1 presents consumer portable device 5 to reader 44 , and before processor 41 reads device data from reader 44 .
- Verification token 40 and validation entity 80 may keep the communications session active until device 5 is presented to reader 44 , and between times that device 5 is presented to reader 44 , by intermittently exchanging “heartbeat” messages. For example, verification token 40 may periodically, aperiodically, or randomly send messages to validation entity 80 confirming its presence in the session, and validation entity 80 may send a reply message confirming its presence in the session.
- the third code may be executed in response to data being received by processor 41 from reader 44 , or may be executed prior to receiving data from reader 44 .
- the third code may include, as an option, instructions that direct processor 41 to send an I/O command to reader 44 to enable its reading capability after processor 41 has established communications with validation entity 80 .
- a fourth code of verification token 40 directs the data processor 41 to transmit at least a portion of identification information to validation entity 80 by way of networking facility 14 of computer 10 , wherein the identification information is preferably transmitted in encrypted form.
- the fourth code may direct data processor 41 to pass the identification information to the computer's network services module using appropriate function calls to the API for the network services module, and the identification information may be transmitted in the SSL session, where the transmitted and received data are encrypted by a session key.
- the fourth code may further comprise code that directs processor 41 to encrypt the identification information with the help of security module 43 using an encryption key stored in token 40 before providing it to networking facility 14 .
- These instructions may include conventional I/O instructions that direct the communications with security module 43 to pass the identification information to module 43 and to receive back the encrypted information. An encryption key for this may be stored in computer-readable medium 42 or in security module 43 .
- a fifth code for some implementations of verification token 40 directs data processor 41 to obtain merchant identification information that identifies the merchant of merchant website 20 , and the previously-described fourth code may further include code that directs the data processor 41 to transmit the merchant identification information to validation entity 80 by way of the networking facility 14 of computer 10 .
- the fifth code may further include code that directs data processor 41 to display a dialog box to user 1 on computer 10 that prompts the user to enter a merchant name or identifier into a dialog box, where the merchant identifier may be displayed on the merchant's checkout page.
- the code may comprise function calls to the graphical user interface of the operating system of computer 10 to open, read, and then close a dialog box on user interface 13 .
- This code may also comprise code that directs processor 41 to execute function calls to the computer's internet browser to query the browser for the URL (or URID) or network address (e.g., IP address) of the entity that provided the content of its active browser session (which presumed to be the merchant's checkout page), and instructions that direct processor 41 to extract the merchant's name or identifier from the obtained URL or URID.
- the fifth code may include code that directs processor 41 to execute function calls to the computer's internet browser to query a special field on its active browser session (which is the merchant's checkout page), where the special field has been pre-arranged by the merchant to contain the merchant's identifier and is known to token 40 for this purpose.
- the fifth code may further include code that directs processor 41 to collect a merchant transaction identifier along with the merchant identifier, either by asking the user to enter this transaction identifier into the above-described dialog box, or by obtaining it from another special field on the merchant's checkout page, which has been pre-arranged by the merchant to contain this transaction identifier.
- the above-described codes can be readily augmented to implement this collection of the transaction identifier.
- the merchant transaction identifier which may comprise a number, can be provided to entity 80 by token 40 , along with the identification information of device 5 and the merchant identifier.
- Entity 80 may then include this transaction identifier with the other information it sends to merchant 20 so that merchant 20 can match the information from entity 80 to the transaction that it is conducting with user 1 at its website, with the correlation being done on the basis of matching the received transaction identifier to the transaction identifier that has been assigned by the merchant to the transaction that the merchant is conducting with user 1 .
- the previously-described fourth code may further include code that directs the data processor 41 to transmit the merchant transaction identifier to validation entity 80 by way of the networking facility 14 of computer 10 .
- the above-described transaction identifier may comprise the network address (e.g., IP address) of the user's computer 10 .
- Validation entity 80 may obtain the network address of computer 10 from the token 40 (which in turn obtains it from the active browser session), or may obtain the network address from the source IP address of the network packets it receives from computer 10 /token 40 .
- Verification token 40 may be configured to work with a selected validation entity 80 as a default if it does not read a URID of a validation entity 80 from portable consumer device 5 . If a URID of a validation entity 80 from portable consumer device 5 is read, then the default is overridden. This configuration enables verification token 40 to be used for other purposes, such as described in co-pending U.S. patent application Ser. No. 12/780,657, entitled “Verification of Portable Consumer Devices,” filed May 14, 2010. Also, verification token 40 may be cobranded to a specific merchant and may have the URID of the cobranded validation entity 80 stored in its memory. In this case, the above fifth code and the corresponding collection of merchant identifier is not needed.
- verification token 40 may contain the URID of validation entity 80 , which handles validation requests for several different co-branded portable consumer devices 5 .
- each of these co-branded devices 5 may hold a URID to a co-branding merchant.
- the merchant URID is read by verification token 40 , such as directed by the above-described second code, and provided to validation entity 80 as the merchant identifier along with the device's identification information, as directed by the above-described four code.
- Validation entity 80 can then send the validated identification information to the merchant URID.
- the above codes of verification token 40 can be readily implemented by one of ordinary skill in the art without undue experimentation.
- the use of function calls to various application programming interfaces (APIs) of the operating system of computer 10 its support modules, facilities, and its applications is well known to the software art, and one of ordinary skill in the art will be able to construct instructions and API function calls to implement the above-described codes and tasks in view of this disclosure without undue experimentation.
- APIs application programming interfaces
- FIG. 2 illustrates an exemplary embodiment 140 of a method that can be used by verification token 40 .
- Exemplary method 140 comprises a plurality of actions 141 - 146 .
- Action 141 comprises establishing a communications link between the verification token and the computer, with the computer having a networking facility, as described above.
- Action 142 comprises establishing a communications session between the verification token and a validation entity using the computer's networking facility and a network services module therefor.
- Action 143 comprises reading identification information from a portable consumer device 5 into the verification token using a reader, such as reader 44 .
- action 143 may precede either or both of actions 141 and 142 .
- Action 144 is optional and comprises obtaining a merchant identifier and/or merchant transaction identifier related to the transaction, either from the user directly or from a webpage on the user's computer, as described above.
- Action 144 comprises transmitting the read identification information, and optionally the obtained merchant identifier and transaction identifier, from the verification token to the validation entity through the communications session, the identification information and identifiers preferably being transmitted to the validation entity in encrypted forms.
- Action 144 may comprise directing the communications session to encrypt the identification information and identifiers, and/or encrypting the identification information and identifiers using an encryption key stored in the token. A triple DES based algorithm may be used for both encryptions.
- Action 146 is optional and occurs after transmitting the identification information.
- Action 146 comprises receiving, at the verification token, a device verification value from the validation entity by way of the communications session.
- FIG. 3 illustrates an exemplary embodiment 150 of a method for a user to use verification token 40 and the like.
- Exemplary method 150 comprises a plurality of actions 151 - 154 .
- Action 151 comprises coupling a verification token, such as token 40 , to a computer, such as computer 10 , using a peripheral interface of the computer.
- Action 152 comprises displaying a merchant web page on the computer's display using an Internet browser, the merchant web page preferably being a checkout page for a transaction between the user and the merchant.
- Action 153 comprises presenting a portable consumer device 5 to the reader of the verification token to send identification information contained in device 5 to a merchant via validation entity 80 .
- action 153 may comprise swiping the magnetic stripe through a magnetic stripe reader of the verification token. If device 5 comprises a wireless communications interface, action 153 may comprise waving device 5 near the reader of verification token.
- Action 154 comprises optionally receiving a device verification value from validation entity 80 and optionally providing the value to the merchant via the merchant's checkout page. Action on 154 also comprises confirming the transaction (such as by clicking the “Submit” button or “Continue” button on the merchant's checkout page, or equivalent button).
- the method may include further optional actions by the user, such as providing a merchant identifier, transaction identifier, and/or password by way of one or more dialog boxes, as described above and below in greater detail.
- validation entity 80 may use a first validation test to validate verification token 40 .
- verification token 40 may send its serial number to validation entity 80 , along with a message encrypted by an encryption key, with the message and encryption key being known to token 40 and entity 80 (but not the general public), and with the encryption key further being uniquely assigned to the token's serial number.
- Validation entity 80 has a database of serial numbers and the corresponding uniquely-assigned encryption keys (or stored algorithms for generating said keys), and can validate that verification token 40 has sent the correct message for the serial number.
- verification token 40 may comprise a serial number and unique encryption key embodied in a computer-readable medium, the unique encryption key being unique to verification token 40 (see FIG.
- Serial Number and “Datum for Encrypted message” code that directs data processor 41 to send the serial number and a message encrypted by the unique encryption key to validation entity 80 .
- the message may be pre-stored on the computer-readable medium (e.g., stored in “Datum for Encrypted message” in FIG. 5 ), or derivable from information known to both verification token 40 and validation entity 80 , such as a message derived from an algorithm applied to the current date, serial number of token 40 , and/or session key of the communications session between token 40 and entity 80 . In this manner, the message sent by token 40 to validation entity 80 is verifiable by validation entity 80 using information stored at the validation entity.
- the computer-readable medium for the above tasks may be located in computer-readable medium 42 and/or security module 43 .
- the above codes may include I/O instructions to security module 43 , and function calls to the API of the computer's network services module.
- verification token 40 may send, from time to time, one or more pieces of machine-unique information of computer 10 to validation entity 80 , which may check this information against a database of computer information associated with known fraudsters.
- machine-unique information may include the serial numbers of processors, disk drives, and operating systems of computer 10 .
- Verification token 40 may comprise code that directs data processor 41 to obtain one or more pieces of machine-unique information from computer 10 , and to send the machine-specific information to validation entity 80 .
- This code may include function calls to the API of the computer's operating system to obtain the information, and function calls to the API of the computer's network services module to send the information to validation entity 80 .
- verification token 40 may be configured to prompt user 1 for a password to activate one or more features of token 40 .
- the password may be stored on a computer-readable medium located in security module 43 or in computer-readable medium 42 (see FIG. 5 for an exemplary implementation of the latter).
- the password may be provided to user 1 on a piece of paper by the provider or seller of token 40 .
- Token 40 may be sent to user 1 through the mail by or on behalf of an issuing bank, or may be purchased by user 1 in a store. Token 40 may be configured to require that the password be entered each time the user wishes to present a consumer portable device 5 , and/or each time token 40 is coupled to a computer 10 .
- verification token 40 may further comprise code embodied on computer-readable medium 42 that directs data processor 41 to prompt the user to enter a password on a keyboard of computer 10 in response to token 40 being initially coupled to computer 10 and/or in response to device 5 being presented to token 40 , to read a password entered by the user, and to compare the entered password against a stored password embodied on the computer-readable medium.
- This code may comprise API function calls to the graphical user interface of the operating system of computer 10 to open a display box on user interface 13 to request and receive a password from user 1 , I/O instructions, memory access instructions, and CPU logical and control instructions.
- Verification token 40 may further comprise one or more of the following:
- validation token 40 may further comprise code embodied on computer-readable medium 42 that directs data processor 41 to establish a user name for the token by presenting user 1 with a dialog box to receive input designating a username, and by storing the username in computer-readable medium 42 (example shown In FIG. 5 ).
- the above codes for processing the password may be further augmented to include requesting a username for the token and comparing the received username with the stored username for a match, and including a match as a condition that must be met in each of the four above codes that initiate or allow various actions to be done.
- These codes may be done with I/O instructions, memory access instructions, and CPU logical and control instructions.
- validation token 40 may further comprise code embodied on computer-readable medium 42 that directs data processor 41 to establish one or more shipping addresses and/or billing addresses in the token that token 40 can provide to validation entity 80 along with the identification information and merchant information that it sends to entity 80 .
- Each shipping address and/or billing address may be associated with a portable consumer device.
- the code may direct processor 41 to present a series of dialog boxes to the user by way of the computer's user interface 13 to receive the address information and the account number (or last four digits thereof) of the portable consumer device 5 that is to be associated to the address information, and to store the address information in a computer-readable medium, such as medium 42 (as illustrated by the example shown in FIG. 5 ).
- Token 40 may further comprise code embodied on computer-readable medium 42 that directs data processor 41 to access the address information in response to a request being sent to validation entity 80 (the address information may be selected among many stored addresses based on the account number sent in the request), and to include the address information in the other information that token 40 sends to entity 80 in the request.
- the code may direct data processor 41 to encrypt the address information with an encryption key stored in token 40 .
- the code may be configured to direct processor 41 to only send the address information when the locations for the information on the merchant checkout page are blank, thereby allowing the user to override any address information that may be stored in token 40 .
- the code may direct data processor 41 to fill the address information into appropriate locations of a merchant checkout page, such as when a dCVV2 value is received back from validation entity 80 .
- the code may be configured to direct processor 41 to only fill in the address information when the locations for the information on the merchant checkout page are blank.
- the filling code may be further configured to direct data processor 41 to use shipping and/or billing information stored on portable consumer device 5 when shipping and/or billing information is not store in token 40 for the account number of device 5 , and further if the locations for the shipping information on the merchant checkout page are blank.
- the filling code may include code that directs data processor 41 to locate a browser session on the computer that has a form fields for address information and/or a device verification value, and to fill the address fields with the selected address information.
- This can include function calls to the API of the Internet browser to search the active web page or all open web pages for an input field marked as name, address, city, postal code, country, and CVV, and to input the datum of the selected address information into the appropriate fields.
- the above codes may be implemented with API function calls, I/O instructions, memory access instructions, and CPU logical and control instructions.
- token 40 may send the identification information pertaining to portable consumer device 5 to computer 10 in a number of forms, including: (1) unaltered form (“clear form”), (2) encrypted form, (3) hashed formed (e.g., encoded), (4) signed form, (5) or any combination of these forms. These forms may be generated by portable consumer device 5 , verification token 40 , computer 10 , or any combination thereof.
- verification token 40 and validation entity 80 may perform a mutual authentication process before verification token 40 sends the identification information.
- Token 40 may also send the merchant and/or transaction information in any of the above forms as well.
- the above codes of token 40 and the identification information read from device 5 by token 40 may be stored independently of computer 10 and may be secure from programs (including spyware and other malicious programs) running on computer 10 .
- the identification information is put in secure form (e.g., encrypted, hashed, signed, or combination thereof) by verification token 40 before the information is provided to computer 10 . Accordingly, securing the information is not dependent upon the security of computer 10 .
- Symmetric or asymmetric keys may be used for encryption and signing.
- the keys for a verification token 40 may be unique with respect to other verification tokens (that is, the keys for a token may be unique to that token).
- Keys for a token may be based upon a uniquely assigned serial number for the verification token, which the token can communicate to validation entity 80 in an initial communication. Both the verification token and the validation entity may have a shared secret on how to derive a key from the token's serial number, such as by manipulating and/or replacing selected digits of the serial number. A number of keys may be derived from the unique serial number using respective shared secrets. Thus, the challenge and response messages used in a mutual authentication process between a verification token and a validation entity may be signed using respective keys derived from the serial number of the verification token.
- verification token 40 may be configured to work with selected consumer payment devices 5 , such as those issued by a selected bank, or configured to work with a selected merchant website 20 .
- Verification token 40 may further comprise codes that directs processor 41 to send heartbeat messages to validation entity 80 , to send a unique identifier of the token to entity 80 , and to obtain one or more unique identifiers of computer 10 from computer 10 and to send these unique identifiers to entity 80 .
- Validation entity 80 comprises a system having one or more servers coupled to a communications network that can receive a request from a verification token 40 to process (e.g., to validate) the identification information that the token has read from a portable consumer device 5 , and to forward data representative of at least a portion of the identification information to the appropriate merchant website 20 if the identification information passes one or more validation tests. If the validation tests are passed, validation entity 80 may also, as an option, provide a device verification value (dCVV2) to token 40 and the payment processing network 70 .
- dCVV2 device verification value
- the server comprises one or more processors 81 electrically coupled to each of a tangible computer-readable medium 82 , a user interface 83 , one or more databases 86 , and a networking facility 84 , the latter of which is coupled to first and second communications networks 31 and 32 .
- User interface 83 comprises one or more video output devices (e.g., displays, screens) and one or more input devices (e.g., keyboard, mouse, trackball, etc.), which enable an administrator of entity 80 to receive information from the server and to provide input to the server.
- Computer-readable medium 82 may comprise a combination of semiconductor memory and non-volatile storage, such as one or more disk drives and/or non-volatile memory.
- Computer-readable medium 82 stores an operating system for the server, which enables processes and applications to be run by processor(s) 81 , and enables codes for directing the operation of processor(s) 81 to be run.
- the operating system provides services to these processes and applications, and enables these processes and applications to access components of user interface 83 , portions of computer-readable medium 82 , networking facility 84 , and other components of entity 80 .
- the operating system may be full featured.
- the operating system provides one or more I/O communications modules that enable processor(s) 81 to communicate with user interface 83 and databases 86 .
- Each I/O communications module has an application programming interface (API) with a collection of functions that a processor 81 can call in order to access the components.
- API application programming interface
- the operating system of entity 80 also comprises one or more network services modules that can access networking facility 84 and set up communications sessions to entities on communications networks 31 and 32 , and with SMS relay server 35 .
- network services modules include Microsoft's Windows Communications Foundation (e.g., .NET 3.0, .NET 4.0, etc.), Apple's CFNetwork Framework, the networking section of the Unix and Linux operating system kernels, and the OS Services Layer and the Base Services Layer of the Symbian operating system, and the like.
- Each of these network services modules can be non-exclusive (e.g., capable of serving more than one processor and more than one process/application) and each provides an application programming interface (API), which has a collection of functions that a processor 81 can call in order to manage communications with another entity.
- API application programming interface
- API facility 84 a collection of API function calls can be readily constructed for a processor to execute that enables the processor to establish a communications channel with an entity on a communications network coupled to networking facility 84 , and to exchange messages and data with the entity.
- the above operating system, modules, and APIs all include instructions that direct the operation of processor(s) 81 .
- One or more databases 86 may be configured as database servers, which processor(s) 81 can access via networking facility 84 over a private communications network 87 , which is illustrated by the dashed line in FIG. 1 .
- Validation entity 80 conventionally has a clock 88 for tracking time and dates for various applications.
- Clock 88 may be a simple counter of seconds, or fractions thereof, that can be read by processor 81 by an I/O operation, or may comprise a more complex arrangement of hardware or firmware that can provide the various components of the current date and time (year, month, day, hour, minute, and second) in various registers that can be read by processor 81 through the execution of one or more I/O operations.
- Validation entity 80 can process identification information transmitted from a plurality of different verification tokens 40 (e.g., millions of tokens), and can process any number of transmissions by a particular token 40 .
- the issuing bank for the device may provide validation entity 80 with the digital magnetic fingerprint of the device, and/or the algorithm that the device uses to generate the device's variable datum (e.g., CVC3, dCVV, cryptogram).
- validation entity 80 When validation entity 80 receives identification information from a verification token 40 for a specific portable consumer device 5 , it can access its record of the digital magnetic fingerprint and/or datum/cryptogram algorithm for the specific device, and compares the received fingerprint and/or variable datum (e.g., CVC3, dCVV, cryptogram) against its record of the fingerprint and/or variable datum (the record of the variable datum being computed according to algorithm in the entity's records).
- fingerprint and/or variable datum e.g., CVC3, dCVV, cryptogram
- validation entity 80 can validate the identification information and forward data representative of at least a portion of it to the appropriate merchant, as determined by one or more of the following: (1) on an a priori basis in the case of a co-branded card, (2) by examining a portion of the account number against a listing of co-branded cards, (3) by receiving an indication from the token of the intended merchant.
- the data representative of at least a portion of the identification information sent to the merchant by entity 80 may comprise a portion or all of the received and verified identification information, or may comprise a substitute account number that the merchant is to use in place of the PAN, or a payment-processing transaction number, or a combination of the above (e.g., card holder name, substitute account number, and payment-processing transaction number).
- Entity 80 may obtain the substitute account number and/or payment-processing transaction number from payment processing network 70 , and entity 80 may provide network 70 with some or all of the identification information that corresponds to the substitute account number and/or payment-processing transaction number.
- network 70 will be able to correlate the incoming transaction having the substitute account number and/or payment-processing transaction number with the user's account specified by the identification information received by entity 80 .
- entity 80 can generate one or both of the substitute account number and/or payment-processing transaction number, and send it/them to payment processing network 70 along with the identification information.
- the transaction number may comprise alphanumeric characters, and may be sent by merchant 20 to acquiring bank 50 , and then to network 70 , in a discretionary data field present in current credit-card processing flows.
- Validation entity 80 comprises a plurality of codes embodied on computer-readable medium 82 for directing processor(s) 81 to conduct various actions.
- Validation entity 80 may comprise a first code that directs data processor 81 to communicate with a plurality of verification tokens 40 over communications network 31 , with a computer disposed between each verification token and the communications network.
- the first code can include code for establishing a communication session with each token, which may include establishing a secure socket layer (SSL) session with mutual authentication and encryption based on a triple DES algorithm, and instructions for sending and receiving messages to verification token 40 through the communications session.
- the first code may also include instructions to send “heartbeat” messages to the verification token and to receive heartbeat messages from the token to keep the session alive between times that identification information is not being sent.
- SSL secure socket layer
- the first code may also include instructions that direct data processor(s) 81 to receive and verify an encrypted serial number or other identification uniquely assigned to the verification token (not to the device 5 ) in order to validate the authenticity of the token.
- the first code may also include instructions that direct data processor(s) 81 to compare the token's serial number or other unique identification against a first list of tokens known to have been used to conduct fraudulent activities. If found on the first list, the first code can direct processor(s) 81 (and hence validation entity 80 ) to decline processing of any identification information sent by token 40 , and refuse to forward identification information from the token to merchant websites 20 .
- the first code may also include instructions that direct data processor(s) 81 to send a message to a verification token 40 to request that the token send to entity 80 a unique datum of information about computer 10 , such as the serial number of processor or disk drive of computer 10 .
- Entity 80 may further comprise code that directs the processor to compile a second list of serial numbers of computers 10 known to be used to conduct fraudulent activities, and the first code may further comprise instructions that direct processor 81 to compare the information it receives about the computer that each verification token communicates through against this second list. If a token 40 is found to be using a computer that is on the second list, the first code may direct processor 81 to add the serial number of the token to the first list.
- Validation entity 80 can then decline processing of any identification information sent by a token 40 that provides computer information found on the second list, and can refuse to forward identification information from the token to merchant websites 20 . These actions may be effected by code that directs processor 81 to take the actions.
- a second code directs data processor 81 to receive identification information sent by the verification token in the communication session established by the first code. If the identification information is encrypted with an encryption key that has been assigned beforehand to the token (i.e., an encryption key that is different from a session key of an SSL session), the second code may further direct data processor 81 to decrypt the identification information.
- the identification information may be encrypted by a session key of an SSL session or by an encryption key stored in verification token 40 and known to validation entity 80 , or may be doubly encrypted by both keys.
- validation entity 80 By validating token 40 against the above first and second lists (i.e., by verifying that token 40 has not thus far been involved in fraudulent activities), validation entity 80 has some degree of confidence that the identification information sent by token 40 is valid, and can, in some implementations, forward the identification information to the appropriate merchant website.
- validation entity 80 may further comprise a third code that directs data processor 81 to compare a digital fingerprint received in the identification information, if present, with the stored copy of the digital fingerprint that entity 80 has for the account number provided with the identification information. If the digital fingerprints match to an acceptable degree, validation entity 80 can validate the identification information and forward it to the appropriate merchant website.
- the third code may include instructions that direct data processor 81 to compare the variable datum received in the identification information, if present, with a copy of the variable datum for the account number provided with the variable datum in the received identification information.
- Processor 81 may generate the copy of the variable datum from an algorithm stored at entity 80 , or from a list of values for the variable datum stored at entity 80 . If the received variable datum and entity 80 's copy of the variable datum match, then validation entity 80 can validate the identification information and forward it to the appropriate merchant website.
- the above validation tests and further exemplary codes for implementing the validation tests are described in a section below in greater detail.
- Validation entity 80 further comprises a fourth code that directs data processor 81 to forward (e.g., send) data representative of at least a portion of the received identification information to the appropriate merchant in response to validation entity 80 validating the token and/or identification information in any of the ways described above.
- validation entity 80 is associated with a selected merchant, and validation entity 80 may send the data to the website 20 of that selected merchant.
- the fourth code may comprise instructions that direct data processor 81 to send the data to a website of the selected merchant.
- validation entity 80 may process a number of portable consumer devices 5 that are co-branded by a number of merchants and associated issuing banks, where the co-branded devices associated with each co-branded merchant have account numbers that incorporate a common sub-number (e.g., co-branded bank number).
- the fourth code may comprise instructions that direct data processor 81 to identify the common sub-number in the account number provided in each received and validated identification information, to compare the identified common sub-number against a list of sub-numbers of the co-branded devices to find a match to a merchant in order to select a merchant to send the information to, and to send the data representative of at least a portion of the identification information to a website of the selected merchant.
- validation entity 80 may receive an indication of the merchant along with the received identification information, and the fourth code may include instructions that direct data processor(s) 81 to select a merchant based on the merchant identification information and to send the data representative of at least a portion of the validated identification information to a website of the selected merchant.
- the merchant indication may be a URID or network address (e.g., IP address) to a website of the selected merchant.
- Entity 80 may have a database 86 that associates such websites with merchant identification.
- the code may direct data processor(s) 81 to also send the last name or full name of the holder of portable consumer device 5 so that merchant 20 can correlate the validated identification information to an open purchase session on its website.
- the code may also direct data processor(s) 81 to also send any transaction identifier that it receives from token 40 .
- the code may also direct data processor(s) 81 to obtain the network address of computer 10 from the source IP address field of the network packets sent from computer 10 , and to send this network address as the transaction identifier to merchant 20 .
- the fourth code further comprises instructions that direct data processor(s) 81 to obtain one or both of these numbers, either by generating them or requesting them from payment processing network 70 .
- the fourth code further directs data processor(s) 81 to send at least a portion of the received identification information to payment processing network 70 so that network 70 can correlate the received identification information with these numbers when they are received in a transaction from an acquiring bank 50 .
- Validation entity 80 may be configured to implement two or more of the above general sets of implementations. For example, validation entity 80 may have code that directs data processor(s) 81 to examine communications from each token 40 for an indication of a merchant. If a merchant indication is provided, then this code of validation entity 80 may direct data processor(s) 81 to send the validated identification information to the identified merchant (third set of implementations). If a merchant indication is not provided, then this code of validation entity 80 may direct data processor(s) 81 to examine the account number for a sub-number that is on a list of common sub-numbers of the co-branded devices to find a match to a merchant, and if found, to forward the validated identification information to the matched merchant (second set of implementations). If this code of validation entity 80 does not find a matching sub-number, it may then direct data processor(s) 81 to forward the validated identification information to a selected merchant.
- Validation entity 80 may send to merchant computer 20 all of the information that website 20 needs to complete the transaction, such as shipping address, card expiration date, card holder name, etc. All of this information may be conveyed to validation entity 80 by consumer portable device 5 through token 40 , or validation entity 80 may have all the information securely stored at its location in one of its databases 86 , or validation entity 80 may obtain the information from an issuing bank 60 or payment processing network 70 . When verification token is co-branded with a specific merchant, validation entity 80 can also obtain the serial number of token 40 and provide it to merchant computer 20 , and merchant computer 20 can use the received token serial number to correlate the other information received from validation entity 80 to the active purchase session of the user, as described below in greater detail. Entity 80 may comprises additional codes that direct its processor(s) 81 to perform these actions.
- validation entity 80 may be further configured to generate or otherwise obtain a dCVV2 value for the identification information that it has validated, and to send the dCVV2 value and identification information to both the merchant and payment processing network 70 .
- validation entity 80 may comprise code that directs processor 81 to generate the dCVV2 value or obtain a dCVV2 value for the issuing bank 60 and to send it to both the merchant website 20 and the payment processing network 70 , along with the validated identification information. Instead of sending the dCVV2 value to the merchant 20 , or in place thereof, validation entity 80 may send the dCVV2 value to token 40 , where token 40 or user 1 may enter the dCVV2 value into the CVV field of the merchant's checkout page.
- both merchant 20 and token 40 receive the dCVV2 value from validation entity 80 , then merchant 20 can use the dCVV2 value it receives from user 1 and token 40 (via entry onto the merchant' check out page) to verify that it has properly correlated the identification information received from entity 80 with the user's purchase session.
- Exemplary codes for processing the dCCV2 value by entity 80 are described section below in greater detail.
- Verification entity 80 may further comprise code that directs processor 81 to send an alert text message to the communication device 7 of user 1 or send an alert e-mail message to an e-mail account of user 1 when one or more of the following events occurs: (1) when verification token 40 initiates communications with entity 80 , (2) when verification token 40 reads a portable consumer device 5 of user 1 , (3) when verification entity 80 receives identification information from a portable consumer device 5 or a verification token 40 associated with user 1 , (4) when verification entity 80 validates said identification information, (5) when verification entity 80 sends validated identification information to a merchant (and optional sends a dCVV2 value to other entities), and (6) when verification entity 80 denies a request to send identification information to a merchant.
- the alerts sent by entity 80 may include information related to the events that triggered the alerts, such as a portion of account number involved and the merchant name.
- the alert text messages may be sent from networking facility 84 to an SMS relay server 35 that is coupled to one of communications networks 31 and 32 , along with the phone number or network address of the user's communication device 7 .
- the SMS relay server has an interface to one or more mobile communication networks, and can relay the text message to the phone number or network address provided by processor 81 .
- Validation entity 80 may comprise the relay server.
- Email alerts may be sent directly to the user's e-mail account from networking facility 84 .
- networking facility 84 may comprise a conventional mail agent, which is well known to the art.
- Validation entity 80 may comprise a website accessible to the user 1 that enables the user: (1) to create a password-protected management account associated with the serial number of the token, the latter of which may be provided on a slip of paper originally sent with the token; (2) to associate an e-mail address to be used for one or more of the above-described alerts; (3) to associate a mobile number and/or URID (e.g., network address) of the user's communications device 5 to be used for one or more of the above-described alerts; and (4) to select one or more of the above-described alert conditions
- the website may also enable the user to provide and associate the account numbers for one or more of the user's devices 5 with the password-protected account, and may further enable the user to associate the e-mails and mobile numbers for the alerts to particular devices 5 according to their account numbers.
- the website may also enable the user to associate a shipping address and/or billing address to one or more specific device account numbers, which validation entity 80 may provide to merchant 20 along with the identification information with each request for sending such information is made by token 40 for such a specified device account number. This association may include an option that the user can select for a specified device account that directs entity 80 to obtain the address information from the issuing bank 60 for the specified device account.
- the website may also enable the user to associate a shipping address and/or billing address to the token itself, which validation entity 80 may provide to merchant 20 for each request to send identification information to a merchant in which a shipping address and/or billing address has not been associated to the device account number or contained in the request from token 40 .
- One of databases 86 may be assigned to hold the above-described password-protected accounts of the users.
- code in entity 80 can direct processor(s) 81 to query this database 86 to find the user's password-protected account (e.g., identify the user from the token's serial number and/or the account number sent in the identification information), to determine what text message alerts and emails are to be generated and sent based on the parameters stored in the password-protected account, to identify the mobile phone number or universal resource identifier (e.g., network address) of the personal communication device to which to sent the messages, and/or to identify the email address to which to send the messages, and to send the determined messages to the identified destinations.
- the user's password-protected account e.g., identify the user from the token's serial number and/or the account number sent in the identification information
- the mobile phone number or universal resource identifier e.g., network address
- Entity 80 can also have code that directs data processor(s) 81 to determine from the account record if any shipping address information or billing address information is to be sent with the communication to the merchant 20 by looking up the settings that the user may have provided for the device account number indicated in the request message, and to send the address information to merchant 20 according to the found settings.
- the above codes and actions can be implemented with HTML page codes, XML page codes, and the like (e.g., web pages), conventional I/O instructions, memory access instructions, database API function calls, CPU arithmetic instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation.
- FIG. 4 illustrates an exemplary embodiment 180 of a method that can be used by validation entity 80 .
- Exemplary method 180 comprises a plurality of actions 181 - 186 .
- Action 181 comprises establishing a communication link between validation entity 80 and a verification token 40 using a networking facility of validation entity 80 .
- Action 182 comprises receiving encrypted identification information pertaining to device 5 and/or token information (e.g., serial number and encrypted message) sent by verification token 40 .
- Action 183 comprises decrypting the encrypted information (e.g., encrypted identification information and/or encrypted message from the token).
- Action 184 comprises applying at least one validation test to the decrypted information.
- Action 185 comprises transmitting, if a selected number of validation tests are passed, data representative of at least a portion of the identification information to a merchant, as described above.
- Action 185 may also, as an option, send a device verification value (dCVV2 value) to verification token 40 and/or merchant 20 , and to payment processing network 70 .
- Action 186 comprises identifying the user (e.g., the user's account) from the identification information, and sending text and/or email alerts to the user as specified in the user's password-protected account.
- a first validation test that validation entity 80 may apply pertains to verifying that verification token 40 is authentic.
- verification token 40 may send its serial number to validation entity 80 , along with a test message encrypted by an encryption key, with the test message and encryption key (or corresponding decryption key) being known to token 40 and entity 80 (but not the general public), and with the encryption key further being uniquely assigned to the token's serial number.
- Validation entity 80 may access a database of token serial numbers and corresponding uniquely-assigned encryption keys (or corresponding decryption keys) in one of databases 86 , and may determine whether verification token 40 has sent a correct test message for the serial number that the token provided.
- the test message may be fixed or variable; in the latter case it may be generated based on information known to both token 40 and entity 80 .
- the test message may be encrypted and decrypted by a triple DES algorithm, which can be implemented by a number of well known sets of computer instructions using a single symmetric encryption key.
- the test message may also be encrypted by a first key of an asymmetric encryption key set at the verification token 40 and decrypted by the second key (the decryption key) of the asymmetric encryption key set at validation entity 80 , which can be implemented by a number of well known sets of computer instructions.
- entity 80 can decrypt the test message using the key that it has, and can compare the decrypted test message to a set of acceptable messages for a match. Entity 80 may also validate the encrypted test message in the reverse way by encrypting the set of acceptable messages and comparing the encrypted test message sent by token 40 to its set of encrypted acceptable messages. If the sent test message is correct, the first validation test can be deemed to have been passed, otherwise the first validation test is deems to have failed.
- validation entity 80 may comprise code embodied on computer-readable medium 82 that directs data processor 81 to receive one or more messages from verification token 40 via networking facility 84 that has the token's serial number and encrypted test message, code that directs data processor 81 to obtain from one of databases 86 a key that has been assigned to the received serial number of the token and one or more acceptable messages that can be accepted as the correct test message, and code that directs the data processor to validate the encrypted test message from the token using the encrypted test message, the obtained key, and the obtained one or more acceptable messages.
- the latter validation code may comprise code that directs data processor 81 to decrypt the encrypted test message using the obtained key, and code that directs data processor 81 to compare the decrypted test message to the one or more acceptable messages to determine if the first validation test has been passed (in the case of a match between the decrypted test message and an acceptable message), or has been failed (in the case of no such match).
- the above validation code may comprise code that directs data processor 81 to encrypt the obtained acceptable messages with the encryption key for token 40 (as found in the database according to the token's serial number), to compare the encrypted test message from token 40 to the one or more encrypted acceptable messages to determine if the first validation test has been passed (in the case of a match between the encrypted test message and an encrypted acceptable message), or has been failed (in the case of no such match).
- An acceptable message may be obtained by accessing it directly from one of databases 86 , or by generating it from information stored in one or more of databases 86 .
- validation entity 80 may record the serial number of the failed token 40 and the source IP address from which the failed token 40 made the request in one of databases 86 .
- validation entity 80 may further comprise code that directs data processor 81 to obtain the source IP address from the request message and to store the source IP address and the token's serial number as one record or two separate records in one of databases 86 , which may be called the failed validation database 86 . This information may be accessed as port of the second validation test described below.
- the above codes can be implemented with conventional I/O instructions, API function calls to databases, memory access instructions, CPU arithmetic and logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation.
- validation entity 80 may have a database in databases 86 that tracks the serial numbers of verification tokens that have been used in fraudulent activities (e.g., suspicious tokens), and validation entity 80 may check the serial number of verification token 40 against this database. If a check of this database indicates that verification token 40 has not been involved in fraudulent activity or is not otherwise suspicious, the second validation test can be deemed to have been passed. To assist in tracking fraudulent activity back to a verification token, validation entity 80 may send the serial number of token 40 along with the dCVV2 value and account number that it sends to payment processing network 70 .
- validation entity 80 may comprise code embodied on computer-readable medium 82 that directs data processor 81 to receive a message from verification token 40 via networking facility 84 that has the token's serial number, code that directs data processor 81 to have the received serial number compared with serial numbers stored in a database of databases 86 that stores serial numbers of suspicious tokens used in fraudulent transactions to determine if the second validation test has been passed (no fraudulent activity), or has been failed (fraudulent activity).
- This code may further include instructions that direct processor 81 to obtain the source IP address of the message from token 40 , and to compare the source IP address and the serial number of token 40 to IP addresses and serial numbers in the failed validation database 86 for a match. If a match is found, the second validation test may be deemed to have been failed. Checking the token serial numbers and IP addresses in this way prevents retry attacks by fraudsters.
- the above codes can be implemented with conventional I/O instructions, API function calls to databases, memory access instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation.
- validation entity 80 may send a message to verification token 40 requesting that token 40 send it one or more pieces of computer-specific information about computer 10 , such as the serial numbers of one or more of the following: the computer's processor, one or more of the computer's disk drives, the computer's operating system.
- Validation entity 80 may receive this information and check it against a database storing computer-specific information of suspicious computers known to have been involved in fraudulent activity. If a check of this database indicates that the computer 10 used by verification token 40 has not been involved in fraudulent activity, the third validation test can be deemed to have been passed.
- validation entity 80 may send the serial number of token 40 and the computer-specific information along with the dCVV2 value and account number that it sends to payment processing network 70 . If network 70 later finds out that the transaction processed with the account number provided by token 40 was fraudulent, it can send a message to that effect to validation entity 80 , and entity 80 may then enter the serial number of the token into the database of suspicious tokens used in fraudulent activities, and the computer-specific information into the database of suspicious computers known to have been involved in fraudulent activity.
- validation entity 80 may comprise code embodied on computer-readable medium 82 that directs data processor 81 to send a message to verification token 40 requesting computer-specific information (if verification token 40 has not sent such information beforehand without prompting), code that directs data processor 81 to receive one or more data messages from verification token 40 via networking facility 84 that have the token's serial number and the computer-specific information, and code that directs data processor 81 to have the received computer-specific information compared with computer-specific information stored in a database (of databases 86 ) that stores computer-specific information of suspicious computers used in fraudulent transactions to determine if the third validation test has been passed (no fraudulent activity), or has been failed (fraudulent activity).
- the above codes can be implemented with conventional I/O instructions, API function calls to databases, memory access instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation.
- validation entity 80 may compare a digital fingerprint received in the identification information, if present, with the stored copy of the valid digital fingerprint that entity 80 has for the account number specified by the identification information. If the digital fingerprints match to an acceptable degree (e.g., the degree of similarity, or correlation, of the two fingerprints being above a selected level of similarity), validation entity 80 can deem the fourth validation test as being passed.
- the degree of similarity between the two fingerprints may be assessed by applying a correlation function to the two fingerprints. Such correlation functions are well known to the art.
- the issuing bank for the device may provide validation entity 80 with the valid digital magnetic fingerprint of the device, which entity 80 may store in one of databases 86 .
- validation entity 80 When validation entity 80 receives identification information from a verification token 40 for a specific portable consumer device 5 , it accesses databases 86 for its record of the valid digital fingerprint, and compares the received fingerprint against the valid digital fingerprint to assess a degree of similarity, and to determine if the fourth validation test has been passed (e.g., the degree of similarity between the two fingerprints is above a selected level), or has been failed (e.g., the degree of similarity between the two fingerprints is below the selected level).
- the fourth validation test has been passed (e.g., the degree of similarity between the two fingerprints is above a selected level), or has been failed (e.g., the degree of similarity between the two fingerprints is below the selected level).
- validation entity 80 may comprise code embodied on computer-readable medium 82 that directs data processor 81 to obtain the stored valid digital fingerprint for the account from one of databases 86 , and code that directs data processor 81 to compare the received digital fingerprint and the stored valid digital fingerprint for similarity to determine if the forth test is passed (sufficient similarity) or failed (not sufficient similarity).
- the latter code may comprise code that directs data processor 81 to generating a value representative of the similarity between the two fingerprints by applying one or more correlation functions to the fingerprints, and comparing the value against a selected level.
- correlation functions also known as probabilistic models, are known to the credit card art.
- the above codes can be implemented with conventional I/O instructions, API function calls to databases, memory access instructions, CPU arithmetic instructions, CPU logic instructions, and CPU control instructions.
- the codes may be implemented by one of ordinary skill in the art without undue experimentation.
- validation entity 80 may perform a fifth validation test that compares a variable datum (e.g., CVC3, dCVV, cryptogram) received as part of the identification information, if present, with a set of one or more acceptable values for the variable datum that validation entity 80 has for the account number provided as part of the identification information. If the values match, validation entity 80 can deem the fifth validation test as being passed.
- a variable datum e.g., CVC3, dCVV, cryptogram
- the variable datum can be configured to vary with time.
- the variable datum can be configured to have its value vary with each use of portable consumer device 5 , and device 5 can provide a counter value in the datum or along with the datum.
- Validation entity 80 or a payment processing network can use the counter value to determine what value the variable datum should have for the given counter value. This determination may be done based on an algorithm that is a function of the counter value (and/or other possible variables), or a look-up table whose entries are correlated to the counter value (the table may be cyclically repeated).
- the algorithm may comprise one or more random number generators, each of which accepts a starting “seed” value, whose value can be selected to customize the algorithm to a particular portable consumer device 5 .
- the values of the look-up table may be based on the output of the algorithm.
- the variable datum may also be based on time, date, or other information known to both verification token 40 and entity 80 , which may or may not use a counter value.
- entity 80 may generate a set of acceptable datum values based on possible slight differences in the starting information, and may compare the datum value received from device 5 with each member of the set to determine if a match exists.
- a cryptogram which typically has more characters than a CVC3 value or a dCVV value, may be generated by an algorithm in a similar way as described above, except that a piece of transaction information is usually included as an input to the algorithm.
- token 40 seeks a cryptogram from a cryptogram-enabled device 5 , it provides device 5 with dummy transaction information which is known to both token 40 and validation entity 80 , but not known to the general public.
- the variable datum received by entity 80 from token 40 comprises a cryptogram (which may be deduced from the character length of the variable datum or the account number of the device 5 )
- validation 80 may look up the dummy transaction information in one of its databases 86 based upon the serial number of token 40 .
- Validation entity 80 may determine the identity of the issuing bank 60 for the device 5 based on the device's account number, and may request the current value of the card's Application Transaction Counter (ATC) from the issuing bank 60 . Entity 80 may then generate the cryptogram based on the dummy transaction information, the ATC, and other information used in the algorithm, and compare the generated cryptogram with the cryptogram received from token 40 . If the cryptograms match, validation entity 80 can deem the fifth validation test as being passed.
- ATC Application Transaction Counter
- entity 80 may generate a set of acceptable cryptograms based on small incremental differences in the ATC value, and may compare the cryptogram received from device 5 with each member of the set to determine if a match exists. If a match cannot be found, the fifth validation test is deemed to have been failed. As another approach, validation entity 80 may forward a request for the cryptogram's value to the issuing bank 60 along with a copy of the dummy transaction information. Validation entity 80 may then compare the cryptogram received back from the issuing back to that received from token 40 to determine whether there is a match.
- validation entity 80 may forward the dummy transaction information and the cryptogram received from token 40 to the issuing bank 60 with a request that the bank determine whether the cryptogram is valid or not, and to send its determination to validation entity 80 . Validation entity 80 may then determine that the fifth validation test is passed if the bank sends an indication that the cryptogram received from token 40 is valid, and failed otherwise.
- the issuing bank for the device may provide validation entity 80 with the look-up table, algorithm (including any seed values), or other data elements that the device uses to generate the device's variable datum (e.g., CVC3, dCVV, or cryptogram), which entity 80 may store in one of its databases 86 .
- algorithm including any seed values
- other data elements e.g., CVC3, dCVV, or cryptogram
- validation entity 80 When validation entity 80 receives identification information from a verification token 40 for a specific portable consumer device 5 , it accesses its record of the look-up table, algorithm, or other data elements for the specific device 5 to determine its value or set of values for the device's variable datum, and compares the received value for a variable datum (e.g., CVC3, dCVV, or cryptogram) against its value or set of acceptable values for the variable datum to determine if the fifth validation test has been passed (e.g., a match in values is found), or has been failed (e.g., a match has not been found).
- a variable datum e.g., CVC3, dCVV, or cryptogram
- validation entity 80 may comprise code embodied on computer-readable medium 82 that directs data processor 81 to access the one or more stored data elements used to obtain the variable datum for the account from one of databases 86 , code that directs data processor 81 to obtain one or more acceptable values for the variable datum from the one or more stored data elements, and code that directs data processor 81 to compare the received variable datum and the one or more acceptable values for a match to determine if the fifth test is passed (a match is found) or failed (a match is not found).
- the code that directs data processor 81 to obtain one or more acceptable values may be based upon the look-up table method described above, or any of the algorithm based methods described above.
- the codes may include instructions that direct data processor 81 to determine if a received variable datum comprises a cryptogram, and if so, to obtain the dummy transaction information from a database 86 based upon the serial number of the token.
- the code may further include instructions that direct data processor 81 to determine the identity of the issuing bank and to obtain an ATC value for the device 5 from the bank, and to generate one or more acceptable values of the cryptogram using the dummy transaction information, the ATC value, and other inputs used in the algorithm.
- the code may further include instructions that direct data processor 81 to send the account information and the dummy transaction information to the identified issuing bank with a request for one or more acceptable cryptogram values.
- the code may include instructions that direct data processor 81 to obtain the dummy transaction information as described above, to identify the issuing bank as described above, to send the account information, dummy transaction information, and the cryptogram received from token 40 to the identified bank with a request that the bank send back an indication of whether or not the cryptogram is valid, and to pass or fail the fifth validation test based on the indication sent back by the issuing bank.
- the above codes can be implemented with conventional I/O instructions, API function calls to databases, memory access instructions, CPU arithmetic instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation.
- Validation entity 80 may be configured to perform one or more of the above validation tests, and may be configured to send the validated identification information to merchant 20 (as described above), and to optionally send a dCCV2 value to verification token 40 and/or merchant 20 , and to payment processing network 70 , if one or more of the tests are passes.
- Validation entity 80 may comprise code embodied on computer-readable medium 82 that directs data processor 81 to execute a selected one or more of the validation tests and track the pass/fail results, and code that directs data processor 81 to take the above actions if a selected number of tests have been passed.
- validation entity 80 may use any method to generate the dCCV2 value, and need not use the method used by portable consumer device 5 to generate the variable datum (e.g., the CVC3 or dCVV).
- Validation entity 80 may generate the dCVV2 values using a pseudo-random number generator or a look-up table, or a sequential counter (such as when: distributing the values from that counter over different accounts).
- the dCVV2 generation process can be done on a per transaction basis (fully dynamic), or for a group of transactions (semi-dynamic), the latter being for a particular device 5 or a group of devices 5 .
- the identification information sent by token 40 may comprises a device identifier as well as an account number
- validation entity 80 may use the device identifier to distinguish between the devices and to generate different dCVV2 values for the devices that are under a common account number.
- Validation entity 80 may use a particular dCVV2 value for a particular device 5 over a selected time period (such as three days), and then select another dCVV2 value for the particular device for the next selected time period, and so on.
- validation entity 80 may receive the dCVV2 values to use during the selected time periods from the issuing bank of the device 5 in advance of the selected time periods, and store them for later use, as determined by entity 80 's clock. This permits validation entity 80 to omit the action of sending the dCVV2 values to payment processing network 70 .
- the device verification value provided by validation entity 80 may have the same format as the CVC3s and dynamic CVVs (“dCVVs”) output by existing smartcard credit cards (e.g., a string of 3 or 4 numbers).
- dCVVs dynamic CVVs
- validation entity 80 may send a message to the issuing bank 60 for portable consumer device 5 to request a value to provide as the dCVV2 value; this request may include the account number and any device identifier.
- the above codes and actions can be implemented with conventional I/O instructions, memory access instructions, CPU arithmetic instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art
- Exemplary Merchant Computer 20 may comprise a system having one or more servers coupled to a communications networks 31 and 32 that can interact with the user through computer 10 to arrange a purchase transaction and receive identification information and other information regarding the transaction from validation entity 80 to process (e.g., to correlate with open transactions and to complete correlated open transactions).
- One of the servers of merchant 20 is shown in FIG. 8 ; the server comprises one or more processors 21 electrically coupled to each of a tangible computer-readable medium 22 , a operator interface 33 , one or more databases 26 , and a networking facility 24 , the latter of which is coupled to first and second communications networks 31 and 32 .
- User interface 23 comprises one or more video output devices (e.g., displays, screens) and one or more input devices (e.g., keyboard, mouse, trackball, etc.), which enable an administrator of Merchant 20 to receive information from the server and to provide input to the server.
- Computer-readable medium 22 may comprise a combination of semiconductor memory and non-volatile storage, such as one or more disk drives and/or non-volatile memory.
- Computer-readable medium 22 stores an operating system for the server, which enables processes and applications to be run by processor(s) 21 , and enables codes for directing the operation of processor(s) 21 to be run.
- the operating system provides services to these processes and applications, and enables these processes and applications to access components of user interface 23 , portions of computer-readable medium 22 , networking facility 24 , and other components of merchant 20 .
- the operating system may be full featured.
- the operating system provides one or more I/O communications modules that enable processor(s) 21 to communicate with user interface 23 and databases 26 .
- Each I/O communications module has an application programming interface (API) with a collection of functions that a processor 21 can call in order to access the components.
- API application programming interface
- the operating system of Merchant computer 20 also comprises one or more network services modules that can access networking facility 24 and set up communications sessions to entities on communications networks 31 and 32 .
- network services modules include Microsoft's Windows Communications Foundation (e.g., .NET 3.0, .NET 4.0, etc.), Apple's CFNetwork Framework, the networking section of the Unix and Linux operating system kernels, and the OS Services Layer and the Base Services Layer of the Symbian operating system, and the like.
- Each of these network services modules can be non-exclusive (e.g., capable of serving more than one processor and more than one process/application) and each provides an application programming interface (API), which has a collection of functions that a processor 21 can call in order to manage communications with another entity.
- API application programming interface
- API facility 24 a collection of API function calls can be readily constructed for a processor to execute that enables the processor to establish a communications channel with an entity on a communications network coupled to networking facility 24 , and to exchange messages and data with the entity.
- the above operating system, modules, and APIs all include instructions that direct the operation of processor(s) 21 .
- One or more databases 26 may be configured as database servers, which processor(s) 21 can access via networking facility 24 over a private communications network 27 , which is illustrated by the dashed line in FIG. 8 .
- Merchant computer 20 conventionally has a clock 28 for tracking time and dates for various applications.
- Clock 28 may be a simple counter of seconds, or fractions thereof, that can be read by processor 21 by an I/O operation, or may comprise a more complex arrangement of hardware or firmware that can provide the various components of the current date and time (year, month, day, hour, minute, and second) in various registers that can be read by processor 21 through the execution of one or more I/O operations.
- Merchant computer 20 comprises a plurality of codes embodied on computer-readable medium 22 for directing data processor(s) 21 to conduct various actions.
- Merchant computer 20 may comprise a first code that directs data processor(s) 21 to present a website portal to computers 10 that provides various web pages that enable users 1 to select products and/or services for purchase, and that provides each such user with a checkout web page where the user's payment information can be entered.
- the first code may direct data processor(s) 21 to require the user to login into the user's previously-created merchant-side account before reaching the checkout web page. In this manner, merchant computer 20 will know the user's name, which will enable it to correlate validated identification information from validation entity 80 to the active purchase session.
- the user merchant-side account may also store the account numbers of one or more portable consumer devices 5 , or the last four digits thereof, that user has registered for use at the merchant site.
- the above aspects of the first code may be implemented by generating and outputting various HTML and XML pages to the user's computer 10 , and other codes known to the art for implementing online merchant websites. This aspect of the first code is known to the art and can be implemented by one of ordinary skill in the art without undue experimentation.
- the first code may further direct data processor(s) 21 to provide a transaction identifier within the URID of the checkout web page or within the contents of the checkout web page, such as in an HTML or XML field, or the like, where the field may be visible or hidden.
- This transaction identifier can be read by verification token 40 , as described above, and feedback to merchant computer 20 via validation entity 80 along with the identification information of a portable consumer device 5 , and can thus further help merchant computer 20 correlate information from validation entity 80 to one of the active purchase sessions being handled by processor(s) 21 under the direction of the first code.
- the first code may further direct data processor(s) 21 to provide a merchant identifier within the URID of the checkout web page or within the contents of the checkout web page, such as in an HTML or XML field, or the like, where the field may be visible or hidden.
- the merchant identifier will enable validation entity to determine the identity of the merchant and the communication channel (e.g., URID) to use to relay information to the merchant.
- the above novel aspects can be implemented with HTML, XML code, or the like, without undue experimentation by one of ordinary skill in the art in view of this disclosure.
- the first code may direct data processor(s) 21 to create a data structure stored in tangible computer readable memory that lists each active purchase session and the user's name, the identity of the user's merchant-side account, and/or transaction identifier for each active purchase session.
- the data structure also preferably lists the corresponding process identification number for the purchase session.
- the first code will direct the data processor(s) 21 to create a respective process thread for each active purchase session, where each process thread will execute a section of the first code for the active purchase session.
- the first code may direct data processor(s) 21 to create a data structure stored in tangible computer readable memory that lists each active purchase session, the network address of the corresponding user computer for that active purchase session, and corresponding process identification number for the purchase session.
- This data structure may optionally include the user names and identities of their merchant-side accounts.
- Merchant computer 20 may further comprise a second code that directs data processor(s) 21 to receive messages from validation entity 80 , and to correlate the data in each received message to one of the active purchase sessions.
- a secure communication channel may be established between merchant computer 20 and validation entity 80 , and the second code may direct data processor(s) 21 to handle the session encryption keys and mutual authentication with validation entity 80 , which may include decrypting the data sent in the messages form entity 80 .
- the second code may direct data processor(s) 21 to identify the user's merchant-side account based upon the account number received in the information sent by validation entity 80 , and to thereafter identify the active purchase session based upon the identity of the merchant-side account.
- identification information of device 5 contains the identity (e.g., account number) of the user's merchant-side account.
- validation entity 80 may send the serial number of token 40 to merchant computer 20 , and the second code can direct data processor(s) 21 to identify the user's merchant-side account based upon the serial number of the token (the serial number being uniquely assigned among the tokens), and to thereafter identify the active purchase session based upon the identity of the merchant-side account.
- the second code can direct data processor(s) 21 to identify the user's merchant-side account based upon the user name provided in the data sent by entity 80 .
- the second code may direct processor(s) 21 to select the merchant-side account that is active, and/or the merchant-side account that has the same address information or network address of computer 10 as present in the data sent by entity 80 , and/or the merchant-side account that has a previously-registered bank account number (PAN), or portion thereof, that is the same that as provided in the message from entity 80 . Also, if a transaction identifier is present within the message sent by entity 80 , the second code may direct data processors(s) 21 to identify the active purchase session based upon the transaction identifier received from entity 80 .
- PAN bank account number
- this transaction identifier may comprise the network address (e.g., IP address) of the user's computer 10 .
- the second code may direct data processors(s) 21 to access one of the above-described data structures of active purchase sessions created under the direction of the first code.
- the second code can be readily implemented by one of ordinary skill in the art without undue experimentation using computer control and memory access instructions, function calls to network services, operating system calls, database function calls, etc.
- the second code may direct data processor(s) 21 to send the data provided in the message from entity 80 to the identified (e.g., correlated) active purchase session.
- This can be done by a inter-process communication of data from the process thread that is executing the second code to the process thread that is executing a section of the first code for the active purchase session.
- the inter-process communication may be accomplished by appropriate function calls to the operating system, which are known to the art.
- the process thread for the active purchase session accepts the provided data and updates its data structure with the received payment information present in the data.
- This action may be directed by a section of the first code that is being executed by the process thread for the active purchase session.
- This part of the first code may comprises a third code that directs data processor(s) 21 to resend the merchant checkout page to the user's computer 10 with an indication that the payment information has been received. This indication may take the form of providing a merchant checkout page with asterisk characters filling in the fields for the payment information.
- the process thread under the direction of the first code, is now ready to receive the user's final approval and commitment to the purchase, such as by waiting for and receiving the user's submission of the checkout page, such as by the user's clicking on the “Submit” button or “Continue” button on the checkout page.
- the first code directs data processor(s) 21 to submit the standard transaction approval request, which is sent to payment processing network 70 , which is typically sent by way of acquiring bank 50 .
- the second code can be readily implemented by one of ordinary skill in the art without undue experimentation using computer control and memory access instructions, function calls to network services, operating system calls, database function calls, etc
- validation entity 80 and merchant computer 20 may be two components owned and operated by a merchant.
- a method that can be conducted by a merchant may comprise: presenting, from a server, a website portal providing various web pages that enable a plurality of users to select at least one product or service for purchase, the code directing the data processor to create an active purchase session for each user that is actively pursuing a purchase; receiving messages from one or more validation entities, each validation messaging including data representative of at least a portion of the identification information of a portable consumer device; and correlating the information received in a message from a validation entity to an active purchase session.
- the merchant website 20 provides a transaction identifier on its merchant checkout page, and verification token 40 obtains the transaction identifier and sends it to validation entity 80 .
- entity 80 can send the transaction identifier to merchant 20 with the other information it normally sends so that merchant 20 can correlate the information received from entity 80 to an active purchase session.
- validation entity 80 can generate this transaction identifier and send it to both verification token 40 and merchant 20 to assist in the correlation process at the merchant computer.
- the transaction identifier may take the form of a “dummy” personal account number (PAN) generated by entity 80 , and which token 40 enters into the PAN field of the merchant checkout page.
- PAN personal account number
- the dummy PAN may start with a sequence of numbers that the merchant recognizes as a dummy PAN (e.g., a dummy bank code), and may be unique over a certain time duration, such as a week (e.g., enough time to complete and process the transactions.
- User 1 submits the merchant checkout page, and the merchant computer system 20 scans the PAN and recognizes it as a dummy PAN, and then examines a queue of messages from entity 80 for a matching message having the same dummy PAN as the transaction identifier. When found, merchant computer system 20 uses the payment information contained in the matching message.
- the merchant may provide a separate field in the checkout page to enter it, and a separate button for the user to click to submit the transaction number to the merchant.
- Merchant 20 can then response by resending an updated checkout page that acknowledges receipt of the payment information, and the user can commit to the purchase by clicking the “Submit” button or “Continue” button.
- Merchant computer system 20 may further comprise codes that direct processor(s) 21 to perform the above actions.
- Validation entity 80 may further comprise codes that direct its processor(s) 81 to generate a transaction identifier and to send the transaction identifier to both verification token 40 and merchant computer system 20 .
- Verification token 40 may further comprises codes that direct its processor 41 to receive the transaction identifier and to enter it on a designated field of the merchant checkout page, such as the PAN field or another field provided by the merchant.
- the code is similar in construction to the code that directs processor 41 to enter the dCVV2 value into the CVV field of the merchant checkout page.
- the communications between computer 10 and validation entity 80 may be facilitated by, and/or conveyed through, a gateway (e.g., a proxy server, server entity, etc.) that is disposed between computer 10 and validation entity 80 .
- a gateway e.g., a proxy server, server entity, etc.
- Gateway 90 may act as an intermediary between a plurality of verification tokens 40 -A, 40 -B, . . . and their associated computers 10 -A, 10 -B, . . . on the one side, and a plurality of validation entities 80 -A, 80 -B, . . . on the other side.
- Computers 10 -A, 10 B, . . . may be the same as computer 10 shown in FIG. 1 , and may be coupled to the first communications networks 31 , as described above.
- First communications network 31 , second communications network 32 , merchant websites 20 , acquiring banks 50 , issuing banks 60 , and payment processing network 70 are coupled to one another as described above.
- First and second communications networks 31 , 32 are also coupled to a plurality of validation entities 80 -A, 80 -B, 80 -C, . . . , each of which may be constructed and configured the same as validation entity 80 shown in FIG. 1 .
- a reference number without a suffix -A, -B, or -C generically refers to each of the suffixed items (e.g., entity 80 refers to each of 80 -A, 80 -B, 80 -C).
- Gateway 90 may receive one or more initial communications from one of verification tokens 40 -A, 40 -B, . . . (via one of computer 10 -A, 10 B, . . . in communication with the token), and may determine from information in the initial communication(s) an appropriate one of a plurality of validation entities 80 -A, 80 -B, 80 -C, . . . to use to fulfill the token's request.
- each verification token 40 -A, 40 -B, . . . may be configured to operate with portable consumer devices 5 issued by many different issuing banks 60 or other such entities, and one or more of the validation entities 80 may be configured to process requests from portable consumer devices 5 issued by respective issuing banks 60 or other such entities.
- Gateway 90 may determine an appropriate one of validation entities 80 -A, 80 -B, 80 -C, . . . based upon the identification information that the token read from a portable consumer device and sent to the gateway in an initial communication. For example, a portion of the account number in the identification information may comprises an unique identifier assigned to the bank 60 that issued the portable consumer devices 5 from which the identification information was read.
- gateway 90 may redirect the token to conduct further communications with the determined appropriate validation entity, or may direct the determined validation entity to contact the token to conduct further communications.
- all communications between the verification token and the determined appropriate validation entity may be conveyed through gateway 90 (after the gateway has initially determined the identity of the appropriate validation entity based upon one or more initial communications with the token). This latter implementation may comprise relatively simple passing through of communications between the token and the appropriate validation entity with minimal processing by gateway 90 , or may comprise having the gateway virtually presenting itself as the appropriate validation entity to the verification token.
- gateway 90 decrypting each message from the verification token, communicating with the appropriate validation entity to formulate a response to the token's message, and encrypting and sending a response message to the verification token.
- gateway 90 may also conduct one or more validation tests on behalf of the appropriate validation entity, particularly those related to validating the verification token. In this case, the gateway does not need to send to the determined appropriate validation entity those communications it receives from the token that pertain to validation tests that the gateway is handling.
- Gateway 90 may be associated with, or operated by, payment processing network 70 or the owner thereof.
- Gateway 90 acts as an entity that can provide a device verification value (dCVV2 value) to token 40 , just as in the case that validation entity 80 can provide a device verification value to token 40 when entity 80 is directly contacted by token 40 .
- dCVV2 value device verification value
- gateway 90 comprises a system having one or more servers coupled to a communications network that can receive a request from a verification token 40 to process, as described above.
- the server comprises one or more processors 91 electrically coupled to each of a tangible computer-readable medium 92 , a user interface 93 , one or more databases 96 , and a networking facility 94 , the latter of which is coupled to first and second communications networks 31 and 32 .
- User interface 93 comprises one or more video output devices (e.g., displays, screens) and one or more input devices (e.g., keyboard, mouse, trackball, etc.), which enable an administrator of gateway 90 to receive information from the server and to provide input to the server.
- Computer-readable medium 92 may comprise a combination of semiconductor memory and non-volatile storage, such as one or more disk drives and/or non-volatile memory.
- Computer-readable medium 92 stores an operating system for the server, which enables processes and applications to be run by processor(s) 91 , and enables codes for directing the operation of processor(s) 91 to be run.
- the operating system provides services to these processes and applications, and enables these processes and applications to access components of user interface 93 , portions of computer-readable medium 92 , networking facility 94 , and other components of entity 90 .
- the operating system may be full featured.
- the operating system provides one or more I/O communications modules that enable processor(s) 91 to communicate with user interface 93 and databases 96 .
- Each I/O communications module has an application programming interface (API) with a collection of functions that a processor 91 can call in order to access the components.
- API application programming interface
- the operating system of entity 90 also comprises one or more network services modules that can access networking facility 94 and set up communications sessions to entities on communications networks 31 and 32 , and with SMS relay server 35 .
- network services modules include Microsoft's Windows Communications Foundation (e.g., .NET 3.0, .NET 4.0, etc.), Apple's CFNetwork Framework, the networking section of the Unix and Linux operating system kernels, and the OS Services Layer and the Base Services Layer of the Symbian operating system, and the like.
- Each of these network services modules can be non-exclusive (e.g., capable of serving more than one processor and more than one process/application) and each provides an application programming interface (API), which has a collection of functions that a processor 91 can call in order to manage communications with another entity.
- API application programming interface
- API facility 94 a collection of API function calls can be readily constructed for a processor to execute that enables the processor to establish a communications channel with an entity on a communications network coupled to networking facility 94 , and to exchange messages and data with the entity.
- the above operating system, modules, and APIs all include instructions that direct the operation of processor(s) 91 .
- One or more databases 96 may be configured as database servers, which processor(s) 91 can access via networking facility 94 over a private communications network 97 , which is illustrated by the dashed line in FIG. 9 .
- Gateway 90 conventionally has a clock 98 for tracking time and dates for various applications.
- Clock 98 may be a simple counter of seconds, or fractions thereof, that can be read by processor 91 by an I/O operation, or may comprise a more complex arrangement of hardware or firmware that can provide the various components of the current date and time (year, month, day, hour, minute, and second) in various registers that can be read by processor 91 through the execution of one or more I/O operations.
- Gateway 90 may comprise code embodied on computer-readable medium 92 that directs data processor 91 to communicate with a computer 10 and an associated verification token 40 using networking facility 94 over communications network 31 .
- This code may include instructions that establish a communications session with computer 10 , including the option of establishing an SSL session with mutual authentication and encryption based on a triple DES algorithm, and instructions for sending and receiving messages to verification token 40 through the communications session.
- Gateway 90 may further comprise code embodied on computer-readable medium 92 that directs data processor 91 to receive encrypted identification information sent by verification token 40 , and code that directs data processor 91 to decrypt the encrypted identification information.
- the identification information may be encrypted by a session key of an SSL session or by an encryption key stored in verification token 40 and known to gateway 90 , or may be doubly encrypted by both keys. The latter key may be uniquely assigned to the token, as described above.
- Gateway 90 may further comprise code embodied on computer-readable medium 92 that directs data processor 91 to determine, from the received identification information and/or the token's identity (e.g., the token's serial number), the appropriate one of the validation entities 80 -A, 80 -B, 80 -C, . . . to be used for further processing of the request from verification token 40 .
- data processor 91 may access one of databases 96 for a correlation list that relates identification information (or portions thereof) to validation entities 80 , and/or for a correlation list that relates token identifiers to validation entities 80 , and may then compare the information received from the token 40 with the correlation list(s) to determine the appropriate one of the validation entities 80 .
- Gateway 90 may further comprise code embodied on computer-readable medium 92 that directs data processor 91 to apply one or more validation tests as previously described above, and to continue processing the request from token 40 if a selected number of validation tests are passed.
- the above codes for gateway 90 , and codes for gateway 90 described below may be implemented in any number of programming languages. Furthermore, one of ordinary skill in the art will be readily able to construct instructions to implement these codes in view of this disclosure without undue experimentation.
- gateway 90 may further comprise code embodied on computer-readable medium 92 that directs data processor 91 to send a communication to token 40 (by way of its associated computer 10 ) informing the token to contact the determined appropriate validation entity 80 to process its request.
- This communication may include a URID for the determined appropriate validation entity.
- Token 40 may then communicate with the determined appropriate entity 80 as described above, and no changes to entity 80 are needed.
- the code may further direct data processor 91 to send a communication to the determined appropriate validation entity 80 that informs the entity of the request from the token 40 (along with an indication of the identification information sent by token 40 ), and informs the entity that the token 40 will be contacting it for a dCVV2 value for the identification information (as sent to gateway 90 by the token 40 ).
- This communication by gateway 90 can serve as an additional security measure that assures the appropriate validation entity 80 that the subsequent contact by token 40 is legitimate.
- gateway 90 may further comprise code embodied on computer-readable medium 92 that directs data processor 91 to send a communication to the determined appropriate validation entity 80 with the identification information and other information received from the verification token 40 , and with a request for the validation entity to process the request and to send the dCVV2 value or other information as outlined above to the verification token 40 (by way of its associated computer 10 ).
- This communication to the determined appropriate validation entity 80 may include a URID for the verification token 40 .
- the codes of the validation entity 80 previously described above may be augmented to direct the entity's processor 81 to receive above-described communication from gateway 90 , and to initiate communications with the requesting token 40 .
- the codes of validation entity 80 need not need to direct the entity's processor 81 to receive the identification information from the requesting token (as that may have been provided to the entity by gateway 90 ); however, as an added security measure, the requesting token 40 may provide the identification information to entity 80 , and the entity may include the code to receive the identification information and other information from the token.
- the code for gateway 90 may further direct data processor 91 to send a communication to the verification token 40 (via the associate computer 10 ) informing the token that the determined appropriate validation entity 80 will be communication with it to potentially send a dCVV2 value.
- Gateway 90 Other exemplary embodiments for Gateway 90 are possible, and are described in co-pending patent application Ser. No. 12/780,657, entitled “Verification of Portable Consumer Devices,” filed May 14, 2010, the contents which is incorporated in their entirety by reference for all purposes.
- validation entities 80 and gateway 90 are separate entities from computers 10 , and are separate entities from verification tokens 40 . It may also be appreciated that in several embodiments and implementations thereof that computers 10 , validation entities 80 , and gateway 90 are addressed as separate network nodes on communications network 31 (e.g., have different network addresses in the communication packets), and that tokens 40 communicate through the network nodes of computers 10 to entities 80 and/or gateway 90 (e.g., computers 10 construct and decode network communication packets for tokens 40 ).
- token 40 may unconditionally send the read identification information to validation entity 80 and/or gateway 90 without requiring a validation between the token and the user, such as may be provided by the entry of a PIN or the provision of a biometric sample (e.g., fingerprint); and that token 40 may send the read identification information in a relatively short amount of time (such as within one minute of being read, and typically within ten seconds).
- a biometric sample e.g., fingerprint
- Embodiments of the invention are not limited to the above-described embodiments.
- functional blocks are shown for an issuer, payment processing system, and acquirer, some entities perform all of these functions and may be included in embodiments of invention.
- any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, C, C++, C#, Java, C++ or Perl using, for example, conventional or object-oriented techniques.
- the software code may be stored as a series of instructions, or commands on a computer-readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM.
- RAM random access memory
- ROM read only memory
- magnetic medium such as a hard-drive or a floppy disk
- optical medium such as a CD-ROM.
- Any such computer-readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Disclosed are apparatuses, systems, and methods pertaining to the secure communication of payment information from portable consumer devices, such as credit cards, to online merchants using verification tokens.
Description
- This application claims priority to U.S. Provisional Patent Application No. 61/241,367, entitled “Secure Communication of Payment Information to Merchants Using a Verification Token,” filed Sep. 10, 2009, the contents of which are hereby incorporated in their entirety by reference for all purposes.
- Also, this application is a continuation-in-part of prior application Ser. No. 12/780,657, entitled “Verification of Portable Consumer Devices,” filed May 14, 2010, and a continuation-in-part of prior application Ser. No. 12/712,148, entitled “Verification of Portable Consumer Devices,” filed Feb. 24, 2010, the contents of both applications being hereby incorporated in their entirety by reference for all purposes. Both of said prior application Ser. Nos. 12/780,657 and 12/712,148 claim priority to U.S. Provisional Patent Application No. 61/178,636, entitled “Dynamic Data Authentication,” filed May 15, 2009, the contents of which are hereby incorporated in their entirety by reference for all purposes.
- As methods and devices for engaging in financial transactions have increased, old problems such as fraud and counterfeiting persist.
- One of the primary sources of fraud, which is prevalent in the credit card industry, is skimming. Skimming refers to the electronic copying of a card's magnetic stripe data to create counterfeit cards.
- Skimming is predominantly a phenomenon afflicting magnetic stripe-based transactions. This is because the magnetic stripe, which is placed on the back of a transaction card and stores a variety of data on three separate tracks, is a passive medium. In other words, the digital content of the magnetic stripe can be perfectly copied, without any difference between the copy and the original.
- One of the primary means by which skimming can be prevented is for the consumer to closely monitor the whereabouts of his transaction card. This may allow the consumer to prevent the card from being swiped through inappropriate devices. However, as contactless cards evolve, the classic skimming problem comes along with it. In fact, in a wireless environment the opportunity to skim magnetic stripe data is more prevalent. In a wireless environment, a potential skimmer need not physically possess the card to be skimmed nor have access to any of the physical equipment (e.g., POS terminal, communication lines, etc.) which is required for skimming in a wire-based environment. A skimmer can, without the knowledge of the consumer or merchant, intercept the wireless transaction and copy the data being transmitted from the card to POS terminal. Similar types of interceptions can occur for online purchases.
- To address the above problems, a dCVV or a dynamic card verification value can be used. For example, various systems and methods for generating dCVV's are discussed in U.S. patent application Ser. No. 10/642,878 entitled “Method and System for Generating a Dynamic Verification Value” filed on Aug. 18, 2003, and in U.S. patent application Ser. No. 11/764,376 entitled “On-Line Payment Transactions” filed on Jan. 29, 2008. Both of these applications are incorporated herein by reference in their entirely for all purposes.
- In addition to generating a dCVV, a dCVV can be more effective for preventing fraud when it is securely received by a consumer. However, securely receiving and using a dCVV cannot overly interfere with a consumer's experience conducting a transaction. A consumer might not use the dCVV or a consumer might conduct fewer transactions if the inconvenience of receiving and using a dCVV is too great.
- Embodiments of the invention are directed to addressing the above problems, and other problems, individually and collectively.
- Disclosed are apparatuses, methods, and systems pertaining to the communication of payment information to online merchants and/or payment processing networks using verification tokens that read identification information from portable consumer devices.
- One embodiment of the invention is directed to a verification token that reads identification information from a portable consumer device and securely provides the identification information to a validation entity. The exemplary verification token comprises a peripheral interface adapted to couple to a peripheral interface of a computer, a reader adapted to read identification information from portable consumer devices, a computer-readable medium, a data processor electrically coupled to the token's peripheral interface, reader, and the computer-readable medium, and code embodied on the computer-readable medium that directs the data processor to perform various actions. In an exemplary implementation, the verification token comprises code that directs the data processor to communicate with a computer by way of the apparatus' peripheral interface and to access to a networking facility of the computer, code embodied on the computer-readable medium that directs the data processor to transmit at least a portion of identification information to the validation entity by way of the networking facility of the computer, the at least a portion of the identification information preferably being transmitted in encrypted form.
- In some implementations of the above embodiment, the verification token also receives a uniform resource identifier (URID) to the validation entity from the portable consumer device, as read by the token's reader. The uniform resource identifier (URID) may comprise a conventional uniform resource locator (URL), an internet-protocol address (IP-address), or any other type of identifier that can identify an entity on a communications network. The validation entity receives the identification information from the verification token, and sends the identification information to a merchant. The validation entity may validate the identification information before sending the identification information to the merchant. The validation entity may be associated with, operated by, and/or owned by the merchant. Also in this implementation, the portable consumer device may be associated with the merchant, co-branded by the merchant and an issuing bank, and/or provided by the merchant. The merchant may correlate the identification information it receives from the validation entity with an online transaction being conducted at the merchant's website, and may use the identification information to process the online transaction.
- In other implementations of the above embodiment, a portion of the account number of the portable consumer device is associated with a particular merchant, such as in the case of a co-branded credit card (e.g., co-branded between the merchant and an issuing bank). In these implementations, the validation entity can determine the merchant identity by comparing a selected portion of each account number it receives against a list numbers of known co-branded cards, and send the identification information to the merchant determined by the comparison action. The validation entity may validate the identification information before sending the identification information to the merchant, or it may leave that action to the merchant's website to perform.
- In an implementation of a further embodiment to the above-described embodiment, the verification token comprises a uniform resource identifier (URID) to the validation entity, or receives such a URID from the portable consumer device. The verification token further comprises code that directs the data processor to obtain an merchant identifier that identifiers a merchant, and sends the merchant identifier to the validation entity along with the at least a portion of the identification information read from the portable consumer device. The validation entity uses the merchant identifier to send the received identification information read from the portable consumer device to the merchant. The validation entity may validate the received identification information before sending it to the merchant. The validation entity may be associated with, operated by, and/or owned by a payment processing network, an issuing bank, or a third party. The merchant identification information may comprise a uniform resource identifier (URID) to the merchant.
- Another embodiment of the invention is directed to a method comprising: establishing a communication link between a verification token and a computer, the establishing a communication link between a verification token and a computer, the computer having a networking facility, an Internet browser, and a display having a merchant web page of a merchant displayed thereon by the Internet browser; reading identification information from a portable consumer device into the verification token; transmitting, using the networking facility of the computer, at least a portion of the read identification information from the verification token to an entity that can provide at least a portion of the read identification information to the merchant.
- Another embodiment of the invention is directed to a method comprising: coupling a verification token to a first computer using a peripheral interface of the first computer, the first computer having a networking facility and a display, the verification token comprising a peripheral interface adapted to couple to the peripheral interface of the first computer, a reader adapted to read identification information from portable consumer devices, a computer-readable medium, and a data processor, the verification token being configured to read identification information of a portable consumer device using the reader and to send at least a portion of the read identification information to a validation entity using the networking facility of the first computer; displaying a merchant web page on the first computer's display, the merchant web page being provided by a second computer; and presenting a portable consumer device to the reader of the verification token to send identification information contained in the portable consumer device to the merchant via the validation entity, wherein the validation entity is different from the first and second computers.
- Another embodiment of the invention is directed to a computer program product embodied on a tangible computer-readable medium that can be used by a validation entity. The exemplary computer program product comprises: code embodied on the computer-readable medium that directs a data processor to communicate with a verification token over a communications network with a computer disposed between the verification token and the communications network, the verification token being coupled to the computer by way of a peripheral interface of the computer and configured to access a networking facility of the computer, the verification token being configured to read a portable consumer device for identification information, and to cause at least a portion of the identification information to be sent to the data processor using the networking facility of the computer; code embodied on the computer-readable medium that directs a data processor to receive identification information sent by the verification token; and code embodied on the computer-readable medium that directs a data processor to send data representative of at least a portion of the received identification information to a merchant computer.
- Another embodiment of the invention is directed to a computer program product embodied on a tangible computer-readable medium that can be used by a validation entity. The exemplary computer program product comprises: code embodied on the computer-readable medium that directs a data processor to receive identification information of a portable consumer device read and sent by a verification token over a communications network with a computer disposed between the verification token and the communications network, the verification token being coupled to the computer by way of a peripheral interface of the computer and configured to access a networking facility of the computer; code that directs a data processor to apply at least one validation test on a piece of information sent by the verification token, the validation test producing a result of pass or fall; and code that directs a data processor to send, if the result of the at least one validation test is pass, data representative of at least a portion of the received identification information to a merchant computer.
- Another embodiment of the invention is directed to a method that can be used by a validation entity. The exemplary method comprises: receiving, at a server, identification information of a portable consumer device read and sent by a verification token over a communications network with a computer disposed between the verification token and the communications network, the verification token being coupled to the computer by way of a peripheral interface of the computer and configured to access a networking facility of the computer; selecting a merchant to send at least a portion of the received identification information to; and sending, from the server, data representative of at least a portion of the received identification information to a computer of the selected merchant.
- Another embodiment of the invention is directed to a computer program product embodied on a tangible computer-readable medium that can be used by a merchant computer system. The exemplary computer program product comprises: code embodied on the computer-readable medium that directs a data processor to present a website portal providing various web pages that enable a plurality of users to select at least one product or service for purchase, the code directing the data processor to create an active purchase session for each user that is actively pursuing a purchase; code embodied on the computer-readable medium that directs a data processor to receive messages from one or more validation entities, each validation message including data representative of at least a portion of the identification information of a portable consumer device; and code embodied on the computer-readable medium that directs a data processor to correlate the data received in a message from a validation entity to an active purchase session.
- Another embodiment of the invention is directed to a merchant processing system. The exemplary system comprises a first component that communicates with a verification token over a communications network with a computer disposed between the verification token and the communications network, the verification token being coupled to the computer by way of a peripheral interface of the computer and configured to access a networking facility of the computer, the verification token being configured to read a portable consumer device for identification information, and to cause at least a portion of the identification information to be sent in encrypted form to the first component using the networking facility of the computer, the first component receives encrypted identification information sent by the verification token and decrypts the encrypted identification information. The system further comprises a second component that processes purchases from consumers over a communications network, and that receives data representative of decrypted identification information from the first component; the second component correlating the data received from the first component with a purchase that is it processing.
- Another embodiment of the invention is directed to a method that can be used by a merchant computer system. The exemplary method comprises: presenting, from a server, a website portal providing various web pages that enable a plurality of users to select at least one product or service for purchase, the code directing the data processor to create an active purchase session for each user that is actively pursuing a purchase; receiving messages from one or more validation entities, each validation message including data representative of at least a portion of the identification information of a portable consumer device; and correlating the data received in a message from a validation entity to an active purchase session.
- In each of the embodiments described above, and in each of the embodiments described below, the communications between the computer and the validation entity may be facilitated by, and/or conveyed through, a gateway (e.g., a proxy server, server entity, etc.) that is disposed between the computer and the validation entity. The gateway may act as an intermediary between a plurality of verification tokens and their associated computers on the one side, and a plurality of validation entities on the other side. The gateway may receive one or more initial communications from a verification token (via a computer in communication with the token), and may determine from information in the one or more initial communications an appropriate one of the validation entities to use to fulfill the token's request. For example, each verification token may be configured to operate with portable consumer devices issued by many different issuing banks or other such entities, and one or more of the validation entities may be configured to process requests from portable consumer devices issued by respective issuing banks or other such entities. The gateway may determine an appropriate one of validation entities to use based upon the identification information that the token read from a portable consumer device and sent to the gateway in an initial communication. In one implementation, the gateway redirects the token to the determined appropriate validation entity, with further communications occurring directly between the verification token and the appropriate validation entity. In another implementation, the communications between the verification token and the appropriate validation entity may be conveyed through the gateway (after the gateway has initially determined the identity of the appropriate validation entity based upon one or more initial communications with the token). This latter implementation may comprise relatively simple passing through of communications between the token and the appropriate validation entity with minimal processing by the gateway, or may comprise having the gateway virtually present itself as the appropriate validation entity to the verification token. Such virtual presentation may involve the gateway decrypting each message from the verification token, communicating with the appropriate validation entity to formulate a response to the token's message, and encrypting and sending a response message to the verification token. The gateway may also conduct one or more validation tests on behalf of the appropriate validation entity, particularly those related to validating the verification token. In this case, the gateway does not need to send to the appropriate validation entity those communications it receives from the token that pertain to validation tests that the gateway is handling. The gateway may be associated with, or operated by, a payment processing network.
- Further details regarding embodiments of the invention are provided below in the Detailed Description with reference to the Figures. Further embodiments are also disclosed therein.
-
FIG. 1 illustrates some exemplary embodiments of the invention. -
FIG. 2 illustrates an exemplary method embodiment that can be used by a verification token. -
FIG. 3 illustrates an exemplary method embodiment that can be used by a user of a verification token. -
FIG. 4 illustrates an exemplary method embodiment that can be used by a validation entity. -
FIG. 5 illustrates an exemplary implementation of a computer-readable memory that can be used by a verification token. -
FIG. 6 illustrates an verification token and computer using USB connectors in the peripheral interfaces. -
FIG. 7 illustrates an exemplary identification information that can be send by a verification token and used by a validation entity. -
FIG. 8 illustrates an exemplary merchant computer. -
FIG. 9 illustrates additional exemplary embodiments of the invention. - Embodiments disclosed herein pertain to the secure communication of identification information (e.g., payment information) of portable consumer devices to merchants. A portable consumer device comprises a device that holds identification information pertaining to an account held by a user with another entity, which is typically an entity that holds, extends, or credits items of value to the user (e.g., monetary funds, credits, debts, etc.). Portable consumer devices encompass credit cards, charge cards, debit cards, bank cards, prepaid cards, and other cards that identify an account held by a user with another entity. The cards are capable of existing in both passive forms (e.g., card with a magnetic stripe) and active forms (e.g., integrated circuit cards or smartcards), and further encompass portable electronic devices that, in whole or in part, function as such cards. Such portable electronic devices can include memory cards, account tokens, fobs, stickers, cellular telephones (including near-field communications phone), keychain devices (such as the Speedpass™ commercially available from Exxon-Mobil Corp.), personal digital assistants, transponders, smart media, pagers, and other mobile electronic devices.
- The identification information held by (e.g., embodied on) a consumer portable device comprises at least an account number, and preferably at least one of the following: a digital fingerprint of a magnetic stripe of the portable consumer device, or a variable datum that varies each time the portable consumer device is read for its identification information, as illustrated in
FIG. 7 . The magnetic stripe carries at least the account number of the device. The account number identifies the consumer account within at least one payment processing network, and may comprise a primary account number (PAN); it may also comprise alphanumeric characters. The digital fingerprint of the magnetic stripe is representative of the distribution of magnetic particles that form the magnetic stripe, and is generated by a specialized card reader that samples the distribution of magnetic particles when the card is swiped. The variable datum may comprise number characters, alphanumeric characters, or a cryptogram (e.g., cryptograph 17). The values of the variable datum vary in a way that is known to both the portable consumer device and an authorization entity, the latter of which may be an issuing bank or a payment processing network. The variable datum encompasses the dynamic CVV (“dCVV”) and CVC3 card verification values generated by smartcards (both the contact and contactless forms), as well as cryptograms generated by many smartcards (e.g., cryptogram 17). The datum values may be pre-stored in a computer-readable medium of the device and In a computer-readable medium of the authorization entity, or may be generated by each of the device and the entity as needed (e.g., “generated on the fly”) using a confidential algorithm known to the device and the entity or by a known algorithm that uses confidential keys or confidential information. The variable datum may comprise, or may be accompanied by, a counter value that indicates the number of times the portable consumer device has generated the variable datum; the counter value may assist the authorization entity in retrieving the variable datum from the entity's computer-readable medium, or in generating the variable datum from the algorithm. However, a counter value is not necessary, and the authorization entity may deduce the number of times the device has generated the variable datum from the history of authorization requests made for the device, or an algorithm that does not require a counter may be used. - The identification information may further comprise the name of the account holder (e.g., the user), the expiration date of the card, service codes, and discretionary data. As an example, the identification information may include the conventional “payment data” stored on the tracks of the magnetic stripe of a conventional credit card (e.g.,
Track 1,Track 2, and/or Track 3). - The identification information of a portable consumer device is read by a reader, which is an electrical component that can read the identification information from a portable consumer device and provide the identification information to another electrical component. A reader may comprise one or more of the following: a magnetic stripe reader (which may include fingerprint sampling circuitry), a card contact reader, and a contactless reader, the latter of which is commonly known as an RFID reader (RFID being an acronym for radio-frequency identification). A reader for reading fingerprints of magnetic stripes may include a security module that comprises a proprietary algorithm that generates a digital fingerprint from the sampled fingerprint data and that encrypts the digital fingerprint with a nonce word using an encryption key. Readers are predominantly found at point-of-sales locations of merchants.
- A typical credit card transaction flow using a portable consumer device at a point-of-sales location is described next. The user's portable consumer device is provided to the user by or on behalf of an issuing bank. The issuing bank extends credit to the user, represents the user in credit card transactions, and pays merchants for the purchases made by the user. A user presents his or her portable consumer device to a merchant at a point-of-sales location to pay for an item or service. The merchant uses a reader to read the user's portable consumer device, and sends the identification information read from the device along with merchant's information and the transaction amount to an acquiring bank. The merchant may also read the portable consumer device for the printed card verification value (e.g., the CVV value printed on the backs of many credit cards), and may send this along as part of the transaction information sent to the acquiring bank. The acquiring bank represents, and vouches for, the merchant in credit card transactions. The acquiring bank forwards the transaction information to a payment processing network, such as VisaNet™, for authorization. A payment processing network generally encompasses a collection of one or more data processing server computers, subsystems, networks, and operations used to support and deliver one or more of the following: authorization services, exception file services, and clearing and settlement services. Payment processing networks encompass bank processing networks, credit-card payment processing network, etc. An exemplary payment processing network may include VisaNet™. Exemplary payment processing networks are able to process one or more of the following: credit-card transactions, debit-card transactions, and other types of commercial transactions. A payment processing network may use any suitable wired or wireless network, including the Internet, to communicate with acquiring banks and issuing banks.
- Prior to the occurrence of a credit-card transaction, the payment processing network has established a protocol with each issuing bank on how the bank's transactions are to be authorized. In some cases, such as when the transaction amount is below a threshold value, the payment processing network will authorize the transaction based on information that it has about the user's account without consulting the issuing bank, and will accept the liability if the transaction turns out to be fraudulent. In other cases, such as when the transaction amount is above a threshold value, the payment processing network will forward the transaction information on to the issuing bank for verification and authorization. As part of the authorization process, the payment network or the issuing bank may verify the digital fingerprint or the varying datum provided by the portable consumer device. The digital fingerprint is stored at the issuing bank, and may be securely provided to the payment processing network by the issuing bank for storage and subsequent use. The algorithm for generating the varying datum is stored at the issuing bank, and may be securely provided to the payment processing network for storage and subsequent use. As also part of the authorization process, the payment network or the issuing bank may verify the printed card verification value (e.g., CVV), which is stored at the issuing bank, and may be securely provided by the issuing bank to the payment processing network for storage and subsequent use. The degree to which the payment processing network is involved in the verification of the consumer portable device and the authorization of the transaction is typically configured according to the wishes of the issuing bank. Once the transaction is authorized, the payment processing network sends an authorization indication to the acquiring bank, which sends the authorization indication on to the merchant. In order to reduce fraud, merchants are not allowed to store digital fingerprints, variable datum, and printed card verification values (CVVs) for more than 24 hours.
- When a user wishes to make an online purchase with a merchant over the Internet, the user types in the credit card account number, cardholder name, expiration date, and the printed card verification value into respective fields on the merchant's checkout page. In this case, the card's magnetic fingerprint or the card's variable datum is not used in the transaction, and they are not available to the payment processing network or the issuing bank to aid in verifying that the card was actually present during the transaction. Accordingly, there is a greater risk of fraud with such online purchases. For example, a store clerk can copy down the account information and printed verification value during a transaction at a point-of-sales location, and can later use the copied information to make an online purchase. As another example, a hacker can install spyware on the user's computer to intercept the account information and printed verification value, and use it to make fraudulent purchases at other online merchants. Other avenues of potential fraud exist. Embodiments of the invention are directed to mitigating these types of fraudulent activity.
-
FIG. 1 illustrates some exemplary embodiments of the invention In the context of an online purchase. A general overview description of the embodiments and components shown in the figure will be given, followed by more detailed descriptions. Shown in the figure are icons for auser 1, the user'sportable consumer device 5, the user's communication device 7 (such as a cell phone), the user'scomputer 10, the merchant'swebsite 20, and afirst communications network 31 that enables the user's computer and the merchant's website to communicate with one another. Thefirst communications network 31 may include the Internet, a telecommunications network (e.g., a wireless network, cell phone network, a telephone network, a cable network, or any combination thereof), a wide area network (WAN), a local area network (LAN), a home router or gateway coupled to one of the above networks, or any combination of the above. Also shown inFIG. 1 is an acquiringbank 50 for the merchant, an issuingbank 60 for theportable consumer device 5, apayment processing network 70, and asecond communications network 32 that enables thepayment processing network 70 to communicate with each of thebanks second communications network 32 may comprise the Internet (and therefore may overlap and share facilities with the first communications network 31), or may comprise one or more private networks, or combination of one or more private networks with the Internet. A private network may comprise a telecommunications network, a wide area network (WAN), a local area network (LAN), or any combination thereof. In some instances, the first andsecond communications networks -
FIG. 1 illustrates averification token 40 according to one embodiment of the invention, and avalidation entity 80 according to another embodiment of the invention. These components, and the interactions between them and between other components shown inFIG. 1 are novel, and do not form part of the prior art.Verification token 40 has areader 44 to readportable consumer device 5, and aperipheral interface 46 adapted to couple to aperipheral interface 16 ofcomputer 10.Reader 46 may comprise one or more of the following: a magnetic stripe reader (which may include fingerprint sampling circuitry and security module), a card contact reader, and a contactless reader, the latter of which is commonly known as an RFID reader.Verification token 40 is configured to communicate tovalidation entity 80 by way of anetworking facility 14 ofcomputer 10. Afteruser 1 fills a purchase cart on merchant website 20 (e.g., merchant computer), the user may bring up the merchant's checkout page to provide the user's payment information and commit to the purchase. At this point,user 1 presents his or herportable consumer device 5 to acard reader 44 ofverification token 40 to provide the device's identification information (an example of which is illustrate inFIG. 7 ). Theverification token 40 reads the identification information from the user'sportable consumer device 5, and sends at least a portion of the identification information in a secure manner (e.g., in an encrypted form) tovalidation entity 80.Validation entity 80 preferably validates the identification information and/or validates theverification token 40 to ensure that theportable consumer device 5 was actually presented toverification token 40, and securely forwards the identification information on to a transaction processing entity, such as a computer of merchant'swebsite 20, to be used in a purchase transaction if the identification information and/or token is validated.Validation entity 80 preferably applies one or more validation tests toverification token 40 and/or the identification information to obtain a level of confidence that theportable consumer device 5 was actually presented toverification token 40 to request the dCVV2 value.Validation entity 80 may have a stored record of the digital fingerprint ofportable consumer device 5 or the algorithm for generating the variable datum ofdevice 5, and can validate the received identification information by comparing the fingerprint or variable datum provided in the received information with that read or recreated from its stored record fordevice 5. In addition to this, or in place of this,validation entity 80 can validate the authenticity ofverification token 40, and trust the information sent byverification token 40 until a fraudulent attempt or incident occurs. When the one or more validation tests are passed, and preferably with no tests being failed,validation entity 80 forwards the identification information on to a transaction processing entity, such as a merchant's website 20 (also calledmerchant computer 20, and merchant computer system 20). - In some implementations,
validation entity 80 andmerchant website 20 are part of a merchant system for a merchant that offers a co-branded credit card (e.g., co-branded portable consumer devices 5). This possibility is illustrated by the dashed line that connectsvalidation entity 80 withmerchant website 20. The merchant system may be owned and operated by the merchant, or owned by another party and operated on behalf of the merchant. In other implementations,entity 80 may determine the identity of the merchant from some of the digits of the account number provided in the identification information, where such digits are assigned to a merchant of a cobranded credit card. In yet other implementations,validation entity 80 receives information that identifies a merchant (the “merchant identification information” or “merchant identifier”) fromverification token 40 along with the identification information fordevice 5, and, if valid, securely forwards data representative of the identification information fordevice 5 on to the merchant identified by the merchant identification information. For this, the merchants may be screened and verified byvalidation entity 80 beforehand, and secure communication channels betweenentity 80 and the verified merchants may be established beforehand. Depending upon implementations, the data representative of the identification information sent to the merchant byentity 80 may comprise a portion or all of the received and verified identification information, or may comprise a substitute account number that the merchant is to use in place of the PAN, or a payment-processing transaction number, or a combination of the above (e.g., card holder name, substitute account number, and payment-processing transaction number). In each of the above implementations,user 1 does not need to input payment information into the merchant's checkout page. Instead, oncemerchant website 20 receives the data representative of the validated identification information fromentity 80, the data may be entered on the checkout page bymerchant website 20 and displayed to the user onuser interface 13, with the account number and CVV value fordevice 5 being partially and/or fully masked with non-related characters, such as asterisks (e.g., “***”). Once the data is filled in,user 1 may commit to the purchase transaction and complete the transaction by clicking on a “Submit” button or “Continue” button of the checkout page.Validation entity 80 may also provide the user's shipping and/or billing address (“address information”) to the merchant so that the user need not fill this information into the merchant's checkout page.Validation entity 80 may obtain the address information fromverification token 40, from the issuingbank 60 fordevice 5, or from an account that user has set up with validation entity 80 (described below in greater detail). -
Merchant website 20 may use a number of techniques to correlate the data representative of the validated identification information that it receives fromvalidation entity 80 with the active purchasing sessions that it is processing. First, ifvalidation entity 80 andmerchant website 20 are part of a merchant system,merchant website 20 may have previously established a secure (e.g., password protected) merchant account foruser 1, where the user has registered the account information for his or herportable consumer device 5. In this case,merchant website 20 may compare the incoming validated identification information fromvalidation entity 80 with the account information of the active purchasing sessions that it is handling to find a match. In another case, themerchant website 20 may have askeduser 1 to provide a portion of the identification information ofdevice 5 on its checkout page, such as the last four or five digits of the account number and account holder's last name.Merchant website 20 can compare this partial amount of information against the incoming identification information fromvalidation entity 80 to make the correlations. - After
user 1 commits to the purchase transaction,merchant website 20 sends the data representative of the identification information, the purchase information, and the merchant information to acquiringbank 50, which in turn sends the data and information topayment processing network 70 for authorization. This is known as an authorization request, and the data and information thatmerchant website 20 sends is known as the transaction information (e.g., the collection of the data representative of the identification information, the purchase information, and the merchant information). The data representative of the validated identification information sent tomerchant website 20 byvalidation entity 80 may include an CVC3 value or dCVV value, as described above.Merchant website 20 may include this value with the transaction information sent to network 70, and/or may include a printed CVV value with the transaction information, the printed CVV value being read fromdevice 5 and entered on the merchant's checkout page byuser 1 ortoken 40.Payment processing network 70 and issuingbank 60 can then perform the actions that they normally perform to authorize the transaction, such as checking whether themerchant 20 is in good standing, and checking the account limit ofuser 1 to ensure that there are sufficient funds to cover the purchase price of the transaction, and checking the CVC3, dVCC, or CVV values. In the transaction request that it sends,merchant 20 may provide an indication that the identification information was read by averification token 40 and validated byvalidation entity 80, which givespayment processing network 70 and issuingbank 60 an extra degree of assurance that the user'sportable consumer device 5 was present during the transaction. Instead, or in addition thereto,validation entity 80 may convey an indication topayment processing network 70 that it validateddevice 5's identification information for a transaction onmerchant website 20. - In addition to helping ensure that
portable consumer device 5 was actually present during the transaction betweenuser 1 andmerchant 20, the communication of the data representative of the identification information fromverification token 40 tomerchant 20 by way ofvalidation entity 80 can be done in encrypted channels that are secure against a “man in the middle” attack that a fraudster may try on the user'scomputer 10. That is, even if the fraudster installs a “Trojan horse” program on the user'scomputer 10 that logs the user's key strokes one the computer's keyboard and sends them to the fraudster's computer, the identification information (e.g., credit card account number and card holder name) cannot be obtained by the Trojan horse program since the information is not typed into the merchant's web page by the user, but is instead securely sent tomerchant 20 byvalidation entity 80. - As indicated above, the identification information read from
portable consumer device 5 may include a cryptogram (e.g., cryptogram 17) generated by the device as the variable datum. In such cases wheredevice 5 is adapted to generate and provide such a cryptogram,card reader 44 provides the user'sdevice 5 with “dummy” transaction information that is known to both token 40 andvalidation entity 80. The dummy transaction information may include a static transaction amount and a static merchant name, depending upon the type of cryptogram to be generated. The dummy transaction information may be different for each token 40. The user'sdevice 5 uses the transaction information to generate the cryptogram. The user's device typically has a counter value, often called the Application Transaction Counter (ATC), which is included in the cryptogram computation, and which is incremented with each transaction. The counter reduces the chances of a fraudster guessing the cryptogram value. In some cases, user'sdevice 5 may need a PIN to activate the computation of the cryptogram. For this, token 40 may display a pop-up window on the user'scomputer 10 that requests the entry of a PIN by the user, and token 40 may provide the pin to the user'sdevice 5 along with the request for the cryptogram. - In further implementations,
validation entity 80 may obtain a dynamic device verification value for theportable consumer device 5 as part of validating the device's identification information. For the sake of clarity, and without loss of generality, this device verification value is referred to as a “dCVV2” value, so as to distinguish it from the following: (1) the “CVC3” or “dCVV” values generated by smartcards (described above), (2) the printed CVV values found on the backs of credit cards, and (3) the CVV field found on the merchant's checkout page. The dCVV2 value comprises a variable datum (e.g., a multi-digit number), and can be used to complete the purchase transaction.Validation entity 80 may obtain the dCVV2 value by generating it from pre-stored data, or by receiving it frompayment processing network 70 or issuingbank 60 in response to a request for it. If it did not receive the dCCV2 value from processingnetwork 70,validation entity 80 provides the dCVV2 value topayment processing network 70, along with the identification information ofdevice 5 so thatnetwork 70 can correlate the dCVV2 value to the user's account.Validation entity 80 also provides the dCVV2 value to one or both ofmerchant 20 andverification token 20. If the dCVV2 value is provided toverification token 40, token 40 may fill in the CVV field found on the merchant's checkout page with the provided dCVV2 value, or may display the provided dCVV2 value touser 1 so that the user can fill in the CVV field with the dCVV2 value. If the dCVV2 value is provided tomerchant 20,merchant 20 may fill in the CVV field on the merchant's own checkout page with the provided dCVV2 value, or may check it against the value entered on its checkout page byuser 1 or token 40 to gain further assurance for itself thatdevice 5 was present during the transaction. In either case, the dCVV2 value reaches both themerchant 20 andpayment processing network 70. Whenuser 1 authorization the transaction (such as by clicking the “Submit” button or “Continue” button on the merchant's checkout page),merchant 20 sends the dCVV2 value along with the user's payment information (e.g., the data representative of identification information of device 5), merchant information, and transaction information to network 70 (via its acquiring bank) as part of its authorization request for the transaction. - Next,
payment processing network 70 can compare incoming authorization requests from merchants (such as forwarded by acquiring banks) against the information it receives from validation entity 80 (such as by looking at account numbers), and can match (e.g., correlate) incoming authorization requests with validation information and dCVV2 values previously sent to it byvalidation entity 80. If a match between the dCVV2 value provided in an authorization request and the dCVV2 value previously provided byentity 80 is found, thenpayment processing network 70 has a very high degree of assurance that consumerportable device 5 was present and in the possession ofuser 1 at the time the purchase transaction was made. This provides a greater degree of assurance in comparison to the reliance on CCV values printed on the backs of credit cards.Payment processing network 70 and issuingbank 60 can then undertake the other actions that they perform to authorize the transaction, such as those described above. In these implementations where dCVV2 values are used,payment processing network 70 does not need to validate the digital fingerprint and/or the variable datum of theportable consumer device 5, if those actions have been done byvalidation entity 80. (Payment processing network 70 may, however, perform those validate actions for merchant point-of-sales transactions.) - As a further feature, which is useful when
multiple devices 5 have been allocated under one account number (e.g., multiple cards under one PAN for a household), the identification information that token 40 collects and provides tovalidation entity 80 may include a device identifier alone with the account number. This device identifier uniquely identifies one of the devices allocated under the account number.Provision entity 80 may further use the device identifier to obtain different dCVV2 values for the different devices allocated under the account number. - A first validation test that
validation entity 80 may apply pertains to verifying thatverification token 40 is authentic. For this,verification token 40 may send its serial number tovalidation entity 80, along with a message encrypted by an encryption key, with the message and encryption key being known to token 40 and entity 80 (but not the general public), and with the encryption key further being uniquely assigned to the token's serial number (uniquely assigned to the token).Validation entity 80 has a database of serial numbers and corresponding uniquely assigned encryption keys, and can validate thatverification token 40 has sent the correct message for the serial number. Validation of the correct message serves to authenticateverification token 40. If the first validation test is failed,validation entity 80 may record the serial number of the failedtoken 40 and the source IP address from which the failed token 40 made the request in a database (such as adatabase 86 described below). A second validation test thatvalidation entity 80 may apply pertains to verifying thatverification token 40 has not been involved in fraudulent transactions. For this,validation entity 80 may also have a database that tracks the serial numbers of verification tokens that have been used In fraudulent activities, and may check the serial number ofverification token 40 against this database. The second validation test may further comprise checking the token serial number and/or the IP address from which an incoming dCVV2 request was originated (the source IP address of the message) against the previously-described database that stores token serial numbers and IP addresses associated with requests that have failed the first validation test. If a token serial number or IP address is found in this database, the second validation test may be deemed to have been failed. Checking the token serial numbers and/or the IP addresses in this way prevents replay attacks by fraudsters. It may be appreciated that the database of serial numbers of tokens that failed the first validation test may be combined with the database of serial numbers of tokens involved in fraudulent activities. This combined database, as well as the two other databases, may be generically termed as a database of serial numbers of suspicious tokens. Additional validation tests are described below in greater detail. - Embodiments and components shown in
FIG. 1 are now described in greater detail. -
Computer 10. - The user's
computer 10 may comprise a desktop computer, a laptop computer, or any portable electronic device that has a networking facility and a peripheral interface for communicating with one or more peripheral devices.Computer 10 has one ormore processors 11, a tangible computer-readable medium 12 coupled to processor(s) 11 that stores instruction codes (software) that direct processor(s) 11 and that stores data used by processor(s) 11, and auser interface 13 coupled to processor(s) 11.Networking facility 14 andperipheral interface 16, which were previously described above, are also coupled to processor(s) 11, withnetworking facility 14 also being coupled tofirst communications network 31.User interface 13 comprises one or more video output devices (e.g., displays, screens) and one or more input devices (e.g., keyboard, mouse, trackball, etc.) foruser 1 to receive information fromcomputer 10 and to provide input tocomputer 10. Computer-readable medium 12 may comprise a combination of semiconductor memory and non-volatile storage, such as one or more disk drives and/or non-volatile memory. Computer-readable medium 12 stores an operating system forcomputer 10, which enables processes and applications to, be run by processor(s) 11. The operating system provides services to these processes and applications, and enables these processes and applications to access components ofuser interface 13, portions of computer-readable medium 12,networking facility 14,peripheral interface 16, and other components ofcomputer 10. The operating system may be complex and full featured, such as found on desk-top computers, or simplified, such as found on cell phones, PDAs, and many other types of portable electronic devices. -
Networking facility 14 ofcomputer 10 may comprise software and hardware that enable a process running oncomputer 10 to communicate with a communications network, such asnetwork 31, to send and receive messages, data, and the like to one or more entities coupled to the communications network. The hardware offacility 14 may comprise dedicated hardware separate from processor(s) 11, or the shared use of processor(s) 11, or a combination thereof. The software offacility 14 may comprise firmware, software stored in computer-readable medium 12 or another computer-readable medium, portions of the operating system, or a combination of any of the preceding items.Networking facility 14 is preferably a non-exclusive resource, allowing access to the communications network by other processes and applications being run bycomputer 10.Peripheral interface 16 ofcomputer 10 comprises a wired or wireless connection that enables a peripheral device (separate from computer 10) to communicate with the computer. Conventional wired connections include universal serial bus (USB) connectors (“USB ports”), serial ports, parallel ports, and PCMCIA ports. Conventional wireless connections include infra-red (IR) base stations and Bluetooth™ base stations that are built intocomputer 10 or that are coupled to a peripheral interface ofcomputer 10. -
Verification Token 40. - In addition to
reader 44 and peripheral interface 46 (described above),verification token 40 further comprises aprocessor 41, a tangible computer-readable medium 42 coupled toprocessor 41 holding data and codes that direct the operation ofprocessor 41, asecurity module 43 coupled toprocessor 41 and adapted to securely store one or more encryption keys and to encrypt and decrypt data fortoken 40, areader 44 coupled toprocessor 41 and adapted to readportable consumer devices 5, and aperipheral interface 46 coupled toprocessor 41 and adapted to communicate tocomputer 10 by way ofperipheral interface 16.Processor 41 may comprise a conventional microprocessor, and computer-readable medium 42 may comprise a combination of semiconductor memory and non-volatile storage, such non-volatile memory.FIG. 5 illustrates an exemplary implementation of computer-readable medium 42, which include the storage of several datum elements (described in greater detail below), processor codes that direct the operation ofprocessor 41, and processor memory whichprocessor 41 may use in carrying out its tasks. Referring back toFIG. 1 ,security module 43 may comprise encryption and decryption circuitry (which may include one or more processors), and may comprise one or more encryption keys stored in a secured memory.Security module 43 may also include firewall security circuitry that protectsverification token 40 from attacks from hackers conducted throughperipheral interface 16.Reader 44 may comprise a convention reader, as described above.Peripheral interface 46 may comprise a wired or wireless connection adapted to communicate withperipheral interface 16 ofcomputer 10. As indicated above, conventional wired connections include universal serial bus connectors (“USB ports”), serial ports, parallel ports, and PCMCIA ports. Conventional wireless connections may include infrared and Bluetooth™ remote stations. When using a conventional wired connection withperipheral interface 46,verification token 40 may be detachably coupled tocomputer 10 atperipheral interface 16, such as at a USB port connector.FIG. 6 illustrates an exemplary verification token 40-1 with a USB port connector (male type) as part of its peripheral interface 46-1. Also illustrate inFIG. 6 iscomputer 10, its peripheral interface 16-1 having a USB port connector (female type) to which USB connector 46-1 is plugged into, theuser interface 13 of computer (e.g., screen and keyboard), the user's portable consumer device 5 (RFID-type card),user 1, and the presentation of a dCVV2 value onuser interface 13.Token 40 may further include a visual indicator, such as a light-emitting diode (LED), that it lights when it is ready to read a user'sdevice 5, and may further include an audible indicator, such as a piezoelectric buzzer, that sounds when token 40 is finished with reading a user'sdevice 5. The visual and audible indicators may be operated by the circuitry ofreader 44. In other implementations, one or more of these indicators may be operated byprocessor 41 through I/O commands. - Referring back to
FIG. 1 ,verification token 40 further comprises various codes embodied on computer-readable medium 42 thatdirect data processor 41 to perform respective actions (e.g., processor codes shown inFIG. 5 ). A first code directsdata processor 41 to communicate withcomputer 10 by way ofperipheral interface 46 so as to gainaccess networking facility 14 ofcomputer 10. The first code may comprise code that directsdata processor 41 to send a device driver tocomputer 10 and an instruction to install the device driver in the computer's operating system, wherein the device driver is a collection of instructions to be run bycomputer 10 that enablescomputer 10 to recognize the verification token and communicate with theverification token 40, and enables the token'sdata processor 41 to make function calls to various application program interfaces (API's) of the computer's operating system, such as those related to networking and accessingnetworking facility 14. So called “self-installing” drivers are known to the art, and can be used here. They comprise one or more function calls to an application programming interface (API) of the computer's operating system, such as the device manager's API. The first code may be configured to work with a selected operating system, such as Windows or Symbian OS, or may be configured to work with several operating systems. In the latter case, the first code may include several device drivers for the various operating systems, and instructions that querycomputer 10 for its operating system type and select (and install) the driver most appropriate for the computer's operating system. The device drivers may be stored in a section of computer-readable medium 42, as illustrated in the example ofFIG. 5 . The first code may further include, as an option, instructions thatdirect processor 41 to generate an I/O signal that causes the above-described visual indicator to be lit in response toprocessor 41 gaining access tonetworking facility 14 ofcomputer 10. - Referring back to
FIG. 1 , a second code ofverification token 40 directsdata processor 41 to receive identification information read fromportable consumer device 5 by thereader 44. The second code may include code that directs thedata processor 41 to receive a universal resource identifier (URID) of avalidation entity 80, as read fromportable consumer device 5 by thereader 44. The second code may comprise instructions thatdirect processor 41 to contactreader 44 at periodic intervals through an I/O command to determine if the reader has any data for the processor, and to read the data when data is indicated as being present. The second code may further directprocessor 41 to contactreader 44 through an I/O command to clear the data afterprocessor 41 has read it, orreader 44 may be configured to clear the data after it has sensed thatprocessor 41 has read it, or after a period of time greater than the periodic contact interval used byprocessor 41. In another implementation,reader 44 may be configured to generate an interrupt signal toprocessor 41 when data is present, and the second code may include instructions thatdirect processor 41 to respond to the interrupt signal by reading the data fromreader 44 and clearing the interrupt. The second code may further include, as an option, instructions thatdirect processor 41 to generate an I/O signal that causes the above-described audible indicator to sound in response toprocessor 41 receiving data fromreader 44. The above instructions may include conventional I/O instructions that direct the communications withreader 44 and the indicators. Differentportable consumer device 5 may store and provide different URIDs todifferent validation entities 80. A uniform resource identifier (URID) may comprise a uniform resource locator (URL), an Internet-protocol address (IP-address), or any other type of identifier that can identify an entity on a communications network. If aportable consumer device 5 does not provide a URID tovalidation entity 80,verification token 40 may store a URID to adefault validation entity 80. In some configurations, someverification tokens 40 may be co-branded with respective issuing banks and/or co-branded merchants, and only work for portable consumer devices that are co-branded with the same issuing banks/merchants, and each issuing bank/merchant may have itsown validation entity 80 with its own URID. In such a configuration, theseverification tokens 40 may store the URIDs to their respectiveco-branded validation entities 80. Instead of, or in addition to, this configuration, someverification tokens 40 may be associated with respectivepayment processing networks 70, and each such network may have itsown validation entity 80. In such a configuration, theseverification tokens 40 may store the URIDs to their respective associatedvalidation entities 80. Accordingly, the second code ofverification token 40 may be further configured to directdata processor 41 to only use a default URID stored bytoken 40, or to use a default URID if consumerportable device 5 does not provide token 40 with a URID toentity 80. As yet another implementation,verification token 40 may include code that directsprocessor 41 to select one of a number of URIDs stored intoken 40 based on a bank number provided in the identification information or embedded in the account number. The above further direction and codes may be implemented with conventional I/O instructions, memory access instructions, and CPU logical and control instructions. One or more URIDs to validation entities may be stored in computer-readable memory 42, as illustrated in the example shown inFIG. 5 . - Referring back to
FIG. 1 , A third code ofverification token 40 directsdata processor 41 to establish communications withvalidation entity 80 usingnetworking facility 14 ofcomputer 10. The operating system ofcomputer 10 comprises one or more software modules and application programs, generically called “network services modules” herein, that can accessnetworking facility 14 and set up communications sessions to entities oncommunications network 31. Such network services modules include Microsoft's Windows Communications Foundation (e.g., .NET 3.0, .NET 4.0, etc.), Apple's CFNetwork Framework, the networking section of the Unix and Linux operating system kernels, the OS Services Layer and the Base Services Layer of the Symbian operating system, internet browsers, and the like. Each of these network services modules is non-exclusive (e.g., capable of serving more than one processor and more than one process/application) and provides an application programming interface (API) to a collection of functions that a processor can access using respective function calls. With these API facilities, a collection of function calls can be readily constructed for a processor to execute that enables the processor to establish a communications channel with an entity on a communications network coupled tonetworking facility 14, and to exchange messages and data with the entity. The third code ofverification token 40 comprises such a collection of function calls to the API of a network services module ofcomputer 10, including one or more function calls that provide the universal resource identifier (URID) forvalidation entity 80 and an instruction to establish a session with the validation entity. The session may be a secure socket layer (or secure transport layer) session (e.g., SSL session) with mutual authentication. As part of establishing the session in some implementations, the third code ofverification token 40 may include directingdata processor 41 to provide, or to cause to be provided, a network address for the token to the computer's network services module and tovalidation entity 80. The network address may be static or dynamic, the latter of which may be obtained through API function calls to the computer's network services module. The network address may an IP address. - If token 40 wishes to use an Internet browser for a network services module, it may further comprise API function calls to the computer's operating system to initiate an instance of the browser and provide it with access to the browser instance. In some implementations, such as when
verification entity 40 stores the URID ofvalidation entity 80, the third code may direct thedata processor 41 to establish communications withvalidation entity 80 well beforeuser 1 presents consumerportable device 5 toreader 44, and beforeprocessor 41 reads device data fromreader 44.Verification token 40 andvalidation entity 80 may keep the communications session active untildevice 5 is presented toreader 44, and between times thatdevice 5 is presented toreader 44, by intermittently exchanging “heartbeat” messages. For example,verification token 40 may periodically, aperiodically, or randomly send messages tovalidation entity 80 confirming its presence in the session, andvalidation entity 80 may send a reply message confirming its presence in the session. - The third code may be executed in response to data being received by
processor 41 fromreader 44, or may be executed prior to receiving data fromreader 44. In the latter case, the third code may include, as an option, instructions thatdirect processor 41 to send an I/O command toreader 44 to enable its reading capability afterprocessor 41 has established communications withvalidation entity 80. - A fourth code of
verification token 40 directs thedata processor 41 to transmit at least a portion of identification information tovalidation entity 80 by way ofnetworking facility 14 ofcomputer 10, wherein the identification information is preferably transmitted in encrypted form. If an SSL session has been established, the fourth code may directdata processor 41 to pass the identification information to the computer's network services module using appropriate function calls to the API for the network services module, and the identification information may be transmitted in the SSL session, where the transmitted and received data are encrypted by a session key. For an additional layer of security, the fourth code may further comprise code that directsprocessor 41 to encrypt the identification information with the help ofsecurity module 43 using an encryption key stored intoken 40 before providing it tonetworking facility 14. These instructions may include conventional I/O instructions that direct the communications withsecurity module 43 to pass the identification information tomodule 43 and to receive back the encrypted information. An encryption key for this may be stored in computer-readable medium 42 or insecurity module 43. - A fifth code for some implementations of
verification token 40 directsdata processor 41 to obtain merchant identification information that identifies the merchant ofmerchant website 20, and the previously-described fourth code may further include code that directs thedata processor 41 to transmit the merchant identification information tovalidation entity 80 by way of thenetworking facility 14 ofcomputer 10. The fifth code may further include code that directsdata processor 41 to display a dialog box touser 1 oncomputer 10 that prompts the user to enter a merchant name or identifier into a dialog box, where the merchant identifier may be displayed on the merchant's checkout page. The code may comprise function calls to the graphical user interface of the operating system ofcomputer 10 to open, read, and then close a dialog box onuser interface 13. This code may also comprise code that directsprocessor 41 to execute function calls to the computer's internet browser to query the browser for the URL (or URID) or network address (e.g., IP address) of the entity that provided the content of its active browser session (which presumed to be the merchant's checkout page), and instructions thatdirect processor 41 to extract the merchant's name or identifier from the obtained URL or URID. Instead of extracting the merchant name or identifier from the obtained URL or URID, the fifth code may include code that directsprocessor 41 to execute function calls to the computer's internet browser to query a special field on its active browser session (which is the merchant's checkout page), where the special field has been pre-arranged by the merchant to contain the merchant's identifier and is known to token 40 for this purpose. The fifth code may further include code that directsprocessor 41 to collect a merchant transaction identifier along with the merchant identifier, either by asking the user to enter this transaction identifier into the above-described dialog box, or by obtaining it from another special field on the merchant's checkout page, which has been pre-arranged by the merchant to contain this transaction identifier. The above-described codes can be readily augmented to implement this collection of the transaction identifier. The merchant transaction identifier, which may comprise a number, can be provided toentity 80 bytoken 40, along with the identification information ofdevice 5 and the merchant identifier.Entity 80 may then include this transaction identifier with the other information it sends tomerchant 20 so thatmerchant 20 can match the information fromentity 80 to the transaction that it is conducting withuser 1 at its website, with the correlation being done on the basis of matching the received transaction identifier to the transaction identifier that has been assigned by the merchant to the transaction that the merchant is conducting withuser 1. The previously-described fourth code may further include code that directs thedata processor 41 to transmit the merchant transaction identifier tovalidation entity 80 by way of thenetworking facility 14 ofcomputer 10. Alternatively, or in addition, the above-described transaction identifier may comprise the network address (e.g., IP address) of the user'scomputer 10. Bothvalidation entity 80 andmerchant 20 will see the same network address for the user'scomputer 10 within any given time period for conducting a transaction, andmerchant 20 can use the computer's network address to correlate the data received fromvalidation entity 80 to the active purchase session.Validation entity 80 may obtain the network address ofcomputer 10 from the token 40 (which in turn obtains it from the active browser session), or may obtain the network address from the source IP address of the network packets it receives fromcomputer 10/token 40. -
Verification token 40 may be configured to work with a selectedvalidation entity 80 as a default if it does not read a URID of avalidation entity 80 fromportable consumer device 5. If a URID of avalidation entity 80 fromportable consumer device 5 is read, then the default is overridden. This configuration enablesverification token 40 to be used for other purposes, such as described in co-pending U.S. patent application Ser. No. 12/780,657, entitled “Verification of Portable Consumer Devices,” filed May 14, 2010. Also,verification token 40 may be cobranded to a specific merchant and may have the URID of thecobranded validation entity 80 stored in its memory. In this case, the above fifth code and the corresponding collection of merchant identifier is not needed. - In yet further implementations,
verification token 40 may contain the URID ofvalidation entity 80, which handles validation requests for several different co-brandedportable consumer devices 5. In addition, each of theseco-branded devices 5 may hold a URID to a co-branding merchant. The merchant URID is read byverification token 40, such as directed by the above-described second code, and provided tovalidation entity 80 as the merchant identifier along with the device's identification information, as directed by the above-described four code.Validation entity 80 can then send the validated identification information to the merchant URID. - In view of the above disclosure, the above codes of
verification token 40 can be readily implemented by one of ordinary skill in the art without undue experimentation. The use of function calls to various application programming interfaces (APIs) of the operating system ofcomputer 10 its support modules, facilities, and its applications is well known to the software art, and one of ordinary skill in the art will be able to construct instructions and API function calls to implement the above-described codes and tasks in view of this disclosure without undue experimentation. -
FIG. 2 illustrates anexemplary embodiment 140 of a method that can be used byverification token 40.Exemplary method 140 comprises a plurality of actions 141-146.Action 141 comprises establishing a communications link between the verification token and the computer, with the computer having a networking facility, as described above.Action 142 comprises establishing a communications session between the verification token and a validation entity using the computer's networking facility and a network services module therefor.Action 143 comprises reading identification information from aportable consumer device 5 into the verification token using a reader, such asreader 44. In some implementations,action 143 may precede either or both ofactions Action 144 is optional and comprises obtaining a merchant identifier and/or merchant transaction identifier related to the transaction, either from the user directly or from a webpage on the user's computer, as described above.Action 144 comprises transmitting the read identification information, and optionally the obtained merchant identifier and transaction identifier, from the verification token to the validation entity through the communications session, the identification information and identifiers preferably being transmitted to the validation entity in encrypted forms.Action 144 may comprise directing the communications session to encrypt the identification information and identifiers, and/or encrypting the identification information and identifiers using an encryption key stored in the token. A triple DES based algorithm may be used for both encryptions.Action 146 is optional and occurs after transmitting the identification information.Action 146 comprises receiving, at the verification token, a device verification value from the validation entity by way of the communications session. -
FIG. 3 illustrates anexemplary embodiment 150 of a method for a user to useverification token 40 and the like.Exemplary method 150 comprises a plurality of actions 151-154.Action 151 comprises coupling a verification token, such astoken 40, to a computer, such ascomputer 10, using a peripheral interface of the computer.Action 152 comprises displaying a merchant web page on the computer's display using an Internet browser, the merchant web page preferably being a checkout page for a transaction between the user and the merchant.Action 153 comprises presenting aportable consumer device 5 to the reader of the verification token to send identification information contained indevice 5 to a merchant viavalidation entity 80. Ifdevice 5 has a magnetic stripe,action 153 may comprise swiping the magnetic stripe through a magnetic stripe reader of the verification token. Ifdevice 5 comprises a wireless communications interface,action 153 may comprise wavingdevice 5 near the reader of verification token.Action 154 comprises optionally receiving a device verification value fromvalidation entity 80 and optionally providing the value to the merchant via the merchant's checkout page. Action on 154 also comprises confirming the transaction (such as by clicking the “Submit” button or “Continue” button on the merchant's checkout page, or equivalent button). The method may include further optional actions by the user, such as providing a merchant identifier, transaction identifier, and/or password by way of one or more dialog boxes, as described above and below in greater detail. - As indicated above,
validation entity 80 may use a first validation test to validateverification token 40. For this,verification token 40 may send its serial number tovalidation entity 80, along with a message encrypted by an encryption key, with the message and encryption key being known to token 40 and entity 80 (but not the general public), and with the encryption key further being uniquely assigned to the token's serial number.Validation entity 80 has a database of serial numbers and the corresponding uniquely-assigned encryption keys (or stored algorithms for generating said keys), and can validate thatverification token 40 has sent the correct message for the serial number. For this,verification token 40 may comprise a serial number and unique encryption key embodied in a computer-readable medium, the unique encryption key being unique to verification token 40 (seeFIG. 5 for an exemplary implementation, “Serial Number” and “Datum for Encrypted message”), and code that directsdata processor 41 to send the serial number and a message encrypted by the unique encryption key tovalidation entity 80. The message may be pre-stored on the computer-readable medium (e.g., stored in “Datum for Encrypted message” inFIG. 5 ), or derivable from information known to bothverification token 40 andvalidation entity 80, such as a message derived from an algorithm applied to the current date, serial number oftoken 40, and/or session key of the communications session betweentoken 40 andentity 80. In this manner, the message sent by token 40 tovalidation entity 80 is verifiable byvalidation entity 80 using information stored at the validation entity. The computer-readable medium for the above tasks may be located in computer-readable medium 42 and/orsecurity module 43. The above codes may include I/O instructions tosecurity module 43, and function calls to the API of the computer's network services module. - As an option,
verification token 40 may send, from time to time, one or more pieces of machine-unique information ofcomputer 10 tovalidation entity 80, which may check this information against a database of computer information associated with known fraudsters. Such machine-unique information may include the serial numbers of processors, disk drives, and operating systems ofcomputer 10.Verification token 40 may comprise code that directsdata processor 41 to obtain one or more pieces of machine-unique information fromcomputer 10, and to send the machine-specific information tovalidation entity 80. This code may include function calls to the API of the computer's operating system to obtain the information, and function calls to the API of the computer's network services module to send the information tovalidation entity 80. - As another option,
verification token 40 may be configured to promptuser 1 for a password to activate one or more features oftoken 40. The password may be stored on a computer-readable medium located insecurity module 43 or in computer-readable medium 42 (seeFIG. 5 for an exemplary implementation of the latter). The password may be provided touser 1 on a piece of paper by the provider or seller oftoken 40.Token 40 may be sent touser 1 through the mail by or on behalf of an issuing bank, or may be purchased byuser 1 in a store.Token 40 may be configured to require that the password be entered each time the user wishes to present a consumerportable device 5, and/or eachtime token 40 is coupled to acomputer 10. For this,verification token 40 may further comprise code embodied on computer-readable medium 42 that directsdata processor 41 to prompt the user to enter a password on a keyboard ofcomputer 10 in response to token 40 being initially coupled tocomputer 10 and/or in response todevice 5 being presented to token 40, to read a password entered by the user, and to compare the entered password against a stored password embodied on the computer-readable medium. This code may comprise API function calls to the graphical user interface of the operating system ofcomputer 10 to open a display box onuser interface 13 to request and receive a password fromuser 1, I/O instructions, memory access instructions, and CPU logical and control instructions.Verification token 40 may further comprise one or more of the following: -
- (1) code embodied on computer-
readable medium 42 that directsdata processor 41 to initiate and/or allow the above-described communications withcomputer 10 in response to an entered password matching the stored password; - (2) code embodied on computer-
readable medium 42 that directsdata processor 41 to initiate and/or allow the above-described communications withvalidation entity 80 in response to an entered password matching the stored password; - (3) code embodied on computer-
readable medium 42 that directsdata processor 41 to activatereader 44 and/or to accept identification information fromreader 44 in response to an entered password matching the stored password; and - (4) code embodied on computer-
readable medium 42 that directsdata processor 41 to initiate and/or allow the above-described transmission of identification information (and optionally merchant or transaction information) tovalidation entity 80 in response to entered password matching the stored password.
- (1) code embodied on computer-
- These codes may be done with I/O instructions, memory access instructions, and CPU logical and control instructions. They, alone or in combination, prevent the transmission of identification information to
entity 80 when the entered password is not the same as the stored password, and thereby comprise code embodied on the computer-readable medium that directs the data processor for doing so. One of ordinary skill in the art will be able to construct the instructions and API function calls to implement the above-described codes in view of this disclosure without undue experimentation. As further protection,validation token 40 may further comprise code embodied on computer-readable medium 42 that directsdata processor 41 to establish a user name for the token by presentinguser 1 with a dialog box to receive input designating a username, and by storing the username in computer-readable medium 42 (example shown InFIG. 5 ). The above codes for processing the password may be further augmented to include requesting a username for the token and comparing the received username with the stored username for a match, and including a match as a condition that must be met in each of the four above codes that initiate or allow various actions to be done. These codes may be done with I/O instructions, memory access instructions, and CPU logical and control instructions. - In further implementations,
validation token 40 may further comprise code embodied on computer-readable medium 42 that directsdata processor 41 to establish one or more shipping addresses and/or billing addresses in the token that token 40 can provide tovalidation entity 80 along with the identification information and merchant information that it sends toentity 80. Each shipping address and/or billing address may be associated with a portable consumer device. The code may directprocessor 41 to present a series of dialog boxes to the user by way of the computer'suser interface 13 to receive the address information and the account number (or last four digits thereof) of theportable consumer device 5 that is to be associated to the address information, and to store the address information in a computer-readable medium, such as medium 42 (as illustrated by the example shown inFIG. 5 ).Token 40 may further comprise code embodied on computer-readable medium 42 that directsdata processor 41 to access the address information in response to a request being sent to validation entity 80 (the address information may be selected among many stored addresses based on the account number sent in the request), and to include the address information in the other information thattoken 40 sends toentity 80 in the request. The code may directdata processor 41 to encrypt the address information with an encryption key stored intoken 40. The code may be configured to directprocessor 41 to only send the address information when the locations for the information on the merchant checkout page are blank, thereby allowing the user to override any address information that may be stored intoken 40. As another approach, the code may directdata processor 41 to fill the address information into appropriate locations of a merchant checkout page, such as when a dCVV2 value is received back fromvalidation entity 80. The code may be configured to directprocessor 41 to only fill in the address information when the locations for the information on the merchant checkout page are blank. The filling code may be further configured to directdata processor 41 to use shipping and/or billing information stored onportable consumer device 5 when shipping and/or billing information is not store intoken 40 for the account number ofdevice 5, and further if the locations for the shipping information on the merchant checkout page are blank. The filling code may include code that directsdata processor 41 to locate a browser session on the computer that has a form fields for address information and/or a device verification value, and to fill the address fields with the selected address information. This can include function calls to the API of the Internet browser to search the active web page or all open web pages for an input field marked as name, address, city, postal code, country, and CVV, and to input the datum of the selected address information into the appropriate fields. The above codes may be implemented with API function calls, I/O instructions, memory access instructions, and CPU logical and control instructions. - In each of the embodiments described herein pertaining to
verification token 40, token 40 may send the identification information pertaining toportable consumer device 5 tocomputer 10 in a number of forms, including: (1) unaltered form (“clear form”), (2) encrypted form, (3) hashed formed (e.g., encoded), (4) signed form, (5) or any combination of these forms. These forms may be generated byportable consumer device 5,verification token 40,computer 10, or any combination thereof. In addition,verification token 40 andvalidation entity 80 may perform a mutual authentication process beforeverification token 40 sends the identification information.Token 40 may also send the merchant and/or transaction information in any of the above forms as well. - In each of the embodiments described herein pertaining to
verification token 40, the above codes oftoken 40 and the identification information read fromdevice 5 bytoken 40 may be stored independently ofcomputer 10 and may be secure from programs (including spyware and other malicious programs) running oncomputer 10. In such implementations, the identification information is put in secure form (e.g., encrypted, hashed, signed, or combination thereof) byverification token 40 before the information is provided tocomputer 10. Accordingly, securing the information is not dependent upon the security ofcomputer 10. Symmetric or asymmetric keys may be used for encryption and signing. The keys for averification token 40 may be unique with respect to other verification tokens (that is, the keys for a token may be unique to that token). Keys for a token, and particularly symmetric keys, may be based upon a uniquely assigned serial number for the verification token, which the token can communicate tovalidation entity 80 in an initial communication. Both the verification token and the validation entity may have a shared secret on how to derive a key from the token's serial number, such as by manipulating and/or replacing selected digits of the serial number. A number of keys may be derived from the unique serial number using respective shared secrets. Thus, the challenge and response messages used in a mutual authentication process between a verification token and a validation entity may be signed using respective keys derived from the serial number of the verification token. - It may be appreciated that in some implementations of
verification token 40 may be configured to work with selectedconsumer payment devices 5, such as those issued by a selected bank, or configured to work with a selectedmerchant website 20. -
Verification token 40 may further comprise codes that directsprocessor 41 to send heartbeat messages tovalidation entity 80, to send a unique identifier of the token toentity 80, and to obtain one or more unique identifiers ofcomputer 10 fromcomputer 10 and to send these unique identifiers toentity 80. -
Validation Entity 80. - Having described various embodiments and implementations of
verification token 40, various embodiments and implementations ofvalidation entity 80 are now described.Validation entity 80 comprises a system having one or more servers coupled to a communications network that can receive a request from averification token 40 to process (e.g., to validate) the identification information that the token has read from aportable consumer device 5, and to forward data representative of at least a portion of the identification information to theappropriate merchant website 20 if the identification information passes one or more validation tests. If the validation tests are passed,validation entity 80 may also, as an option, provide a device verification value (dCVV2) totoken 40 and thepayment processing network 70. One of the servers ofentity 80 is shown inFIG. 1 ; the server comprises one ormore processors 81 electrically coupled to each of a tangible computer-readable medium 82, auser interface 83, one ormore databases 86, and anetworking facility 84, the latter of which is coupled to first andsecond communications networks User interface 83 comprises one or more video output devices (e.g., displays, screens) and one or more input devices (e.g., keyboard, mouse, trackball, etc.), which enable an administrator ofentity 80 to receive information from the server and to provide input to the server. Computer-readable medium 82 may comprise a combination of semiconductor memory and non-volatile storage, such as one or more disk drives and/or non-volatile memory. - Computer-
readable medium 82 stores an operating system for the server, which enables processes and applications to be run by processor(s) 81, and enables codes for directing the operation of processor(s) 81 to be run. The operating system provides services to these processes and applications, and enables these processes and applications to access components ofuser interface 83, portions of computer-readable medium 82,networking facility 84, and other components ofentity 80. The operating system may be full featured. Specifically, the operating system provides one or more I/O communications modules that enable processor(s) 81 to communicate withuser interface 83 anddatabases 86. Each I/O communications module has an application programming interface (API) with a collection of functions that aprocessor 81 can call in order to access the components. The operating system ofentity 80 also comprises one or more network services modules that can accessnetworking facility 84 and set up communications sessions to entities oncommunications networks SMS relay server 35. Such network services modules include Microsoft's Windows Communications Foundation (e.g., .NET 3.0, .NET 4.0, etc.), Apple's CFNetwork Framework, the networking section of the Unix and Linux operating system kernels, and the OS Services Layer and the Base Services Layer of the Symbian operating system, and the like. Each of these network services modules can be non-exclusive (e.g., capable of serving more than one processor and more than one process/application) and each provides an application programming interface (API), which has a collection of functions that aprocessor 81 can call in order to manage communications with another entity. With these API facilities, a collection of API function calls can be readily constructed for a processor to execute that enables the processor to establish a communications channel with an entity on a communications network coupled tonetworking facility 84, and to exchange messages and data with the entity. The above operating system, modules, and APIs all include instructions that direct the operation of processor(s) 81. - One or
more databases 86 may be configured as database servers, which processor(s) 81 can access vianetworking facility 84 over aprivate communications network 87, which is illustrated by the dashed line inFIG. 1 .Validation entity 80 conventionally has aclock 88 for tracking time and dates for various applications.Clock 88 may be a simple counter of seconds, or fractions thereof, that can be read byprocessor 81 by an I/O operation, or may comprise a more complex arrangement of hardware or firmware that can provide the various components of the current date and time (year, month, day, hour, minute, and second) in various registers that can be read byprocessor 81 through the execution of one or more I/O operations. -
Validation entity 80 can process identification information transmitted from a plurality of different verification tokens 40 (e.g., millions of tokens), and can process any number of transmissions by aparticular token 40. Before receiving identification information for aportable consumer device 5 from a token, the issuing bank for the device may providevalidation entity 80 with the digital magnetic fingerprint of the device, and/or the algorithm that the device uses to generate the device's variable datum (e.g., CVC3, dCVV, cryptogram). Whenvalidation entity 80 receives identification information from averification token 40 for a specificportable consumer device 5, it can access its record of the digital magnetic fingerprint and/or datum/cryptogram algorithm for the specific device, and compares the received fingerprint and/or variable datum (e.g., CVC3, dCVV, cryptogram) against its record of the fingerprint and/or variable datum (the record of the variable datum being computed according to algorithm in the entity's records). If the received fingerprint and/or variable datum match(es) the recorded fingerprint and/or variable datum,validation entity 80 can validate the identification information and forward data representative of at least a portion of it to the appropriate merchant, as determined by one or more of the following: (1) on an a priori basis in the case of a co-branded card, (2) by examining a portion of the account number against a listing of co-branded cards, (3) by receiving an indication from the token of the intended merchant. Depending upon implementations, the data representative of at least a portion of the identification information sent to the merchant byentity 80 may comprise a portion or all of the received and verified identification information, or may comprise a substitute account number that the merchant is to use in place of the PAN, or a payment-processing transaction number, or a combination of the above (e.g., card holder name, substitute account number, and payment-processing transaction number).Entity 80 may obtain the substitute account number and/or payment-processing transaction number frompayment processing network 70, andentity 80 may providenetwork 70 with some or all of the identification information that corresponds to the substitute account number and/or payment-processing transaction number. In this way,network 70 will be able to correlate the incoming transaction having the substitute account number and/or payment-processing transaction number with the user's account specified by the identification information received byentity 80. Alternatively,entity 80 can generate one or both of the substitute account number and/or payment-processing transaction number, and send it/them topayment processing network 70 along with the identification information. The transaction number may comprise alphanumeric characters, and may be sent bymerchant 20 to acquiringbank 50, and then to network 70, in a discretionary data field present in current credit-card processing flows. -
Validation entity 80 comprises a plurality of codes embodied on computer-readable medium 82 for directing processor(s) 81 to conduct various actions.Validation entity 80 may comprise a first code that directsdata processor 81 to communicate with a plurality ofverification tokens 40 overcommunications network 31, with a computer disposed between each verification token and the communications network. The first code can include code for establishing a communication session with each token, which may include establishing a secure socket layer (SSL) session with mutual authentication and encryption based on a triple DES algorithm, and instructions for sending and receiving messages toverification token 40 through the communications session. The first code may also include instructions to send “heartbeat” messages to the verification token and to receive heartbeat messages from the token to keep the session alive between times that identification information is not being sent. The first code may also include instructions that direct data processor(s) 81 to receive and verify an encrypted serial number or other identification uniquely assigned to the verification token (not to the device 5) in order to validate the authenticity of the token. The first code may also include instructions that direct data processor(s) 81 to compare the token's serial number or other unique identification against a first list of tokens known to have been used to conduct fraudulent activities. If found on the first list, the first code can direct processor(s) 81 (and hence validation entity 80) to decline processing of any identification information sent bytoken 40, and refuse to forward identification information from the token tomerchant websites 20. The first code may also include instructions that direct data processor(s) 81 to send a message to averification token 40 to request that the token send to entity 80 a unique datum of information aboutcomputer 10, such as the serial number of processor or disk drive ofcomputer 10.Entity 80 may further comprise code that directs the processor to compile a second list of serial numbers ofcomputers 10 known to be used to conduct fraudulent activities, and the first code may further comprise instructions thatdirect processor 81 to compare the information it receives about the computer that each verification token communicates through against this second list. If a token 40 is found to be using a computer that is on the second list, the first code may directprocessor 81 to add the serial number of the token to the first list.Validation entity 80 can then decline processing of any identification information sent by a token 40 that provides computer information found on the second list, and can refuse to forward identification information from the token tomerchant websites 20. These actions may be effected by code that directsprocessor 81 to take the actions. - A second code directs
data processor 81 to receive identification information sent by the verification token in the communication session established by the first code. If the identification information is encrypted with an encryption key that has been assigned beforehand to the token (i.e., an encryption key that is different from a session key of an SSL session), the second code may further directdata processor 81 to decrypt the identification information. The identification information may be encrypted by a session key of an SSL session or by an encryption key stored inverification token 40 and known tovalidation entity 80, or may be doubly encrypted by both keys. - By validating
token 40 against the above first and second lists (i.e., by verifying that token 40 has not thus far been involved in fraudulent activities),validation entity 80 has some degree of confidence that the identification information sent bytoken 40 is valid, and can, in some implementations, forward the identification information to the appropriate merchant website. To increase the degree of confidence,validation entity 80 may further comprise a third code that directsdata processor 81 to compare a digital fingerprint received in the identification information, if present, with the stored copy of the digital fingerprint thatentity 80 has for the account number provided with the identification information. If the digital fingerprints match to an acceptable degree,validation entity 80 can validate the identification information and forward it to the appropriate merchant website. If there is no digital fingerprint in the received identification information, the third code may include instructions thatdirect data processor 81 to compare the variable datum received in the identification information, if present, with a copy of the variable datum for the account number provided with the variable datum in the received identification information.Processor 81 may generate the copy of the variable datum from an algorithm stored atentity 80, or from a list of values for the variable datum stored atentity 80. If the received variable datum andentity 80's copy of the variable datum match, thenvalidation entity 80 can validate the identification information and forward it to the appropriate merchant website. The above validation tests and further exemplary codes for implementing the validation tests are described in a section below in greater detail. -
Validation entity 80 further comprises a fourth code that directsdata processor 81 to forward (e.g., send) data representative of at least a portion of the received identification information to the appropriate merchant in response tovalidation entity 80 validating the token and/or identification information in any of the ways described above. In a first set of implementations,validation entity 80 is associated with a selected merchant, andvalidation entity 80 may send the data to thewebsite 20 of that selected merchant. In these implementations, the fourth code may comprise instructions thatdirect data processor 81 to send the data to a website of the selected merchant. In a second set of implementations,validation entity 80 may process a number ofportable consumer devices 5 that are co-branded by a number of merchants and associated issuing banks, where the co-branded devices associated with each co-branded merchant have account numbers that incorporate a common sub-number (e.g., co-branded bank number). In these implementations, the fourth code may comprise instructions thatdirect data processor 81 to identify the common sub-number in the account number provided in each received and validated identification information, to compare the identified common sub-number against a list of sub-numbers of the co-branded devices to find a match to a merchant in order to select a merchant to send the information to, and to send the data representative of at least a portion of the identification information to a website of the selected merchant. In a third set of implementations,validation entity 80 may receive an indication of the merchant along with the received identification information, and the fourth code may include instructions that direct data processor(s) 81 to select a merchant based on the merchant identification information and to send the data representative of at least a portion of the validated identification information to a website of the selected merchant. As indicated above, the merchant indication may be a URID or network address (e.g., IP address) to a website of the selected merchant.Entity 80 may have adatabase 86 that associates such websites with merchant identification. In any of the above implementations, an particularly in the latter implementation, the code may direct data processor(s) 81 to also send the last name or full name of the holder ofportable consumer device 5 so thatmerchant 20 can correlate the validated identification information to an open purchase session on its website. The code may also direct data processor(s) 81 to also send any transaction identifier that it receives fromtoken 40. The code may also direct data processor(s) 81 to obtain the network address ofcomputer 10 from the source IP address field of the network packets sent fromcomputer 10, and to send this network address as the transaction identifier tomerchant 20. - If the above-described data representative of at least a portion of the received identification information comprises a substitute account number and/or a payment-processing transaction number, then the fourth code further comprises instructions that direct data processor(s) 81 to obtain one or both of these numbers, either by generating them or requesting them from
payment processing network 70. In this case, the fourth code further directs data processor(s) 81 to send at least a portion of the received identification information topayment processing network 70 so thatnetwork 70 can correlate the received identification information with these numbers when they are received in a transaction from an acquiringbank 50. -
Validation entity 80 may be configured to implement two or more of the above general sets of implementations. For example,validation entity 80 may have code that directs data processor(s) 81 to examine communications from each token 40 for an indication of a merchant. If a merchant indication is provided, then this code ofvalidation entity 80 may direct data processor(s) 81 to send the validated identification information to the identified merchant (third set of implementations). If a merchant indication is not provided, then this code ofvalidation entity 80 may direct data processor(s) 81 to examine the account number for a sub-number that is on a list of common sub-numbers of the co-branded devices to find a match to a merchant, and if found, to forward the validated identification information to the matched merchant (second set of implementations). If this code ofvalidation entity 80 does not find a matching sub-number, it may then direct data processor(s) 81 to forward the validated identification information to a selected merchant. -
Validation entity 80 may send tomerchant computer 20 all of the information thatwebsite 20 needs to complete the transaction, such as shipping address, card expiration date, card holder name, etc. All of this information may be conveyed tovalidation entity 80 by consumerportable device 5 throughtoken 40, orvalidation entity 80 may have all the information securely stored at its location in one of itsdatabases 86, orvalidation entity 80 may obtain the information from an issuingbank 60 orpayment processing network 70. When verification token is co-branded with a specific merchant,validation entity 80 can also obtain the serial number oftoken 40 and provide it tomerchant computer 20, andmerchant computer 20 can use the received token serial number to correlate the other information received fromvalidation entity 80 to the active purchase session of the user, as described below in greater detail.Entity 80 may comprises additional codes that direct its processor(s) 81 to perform these actions. - As indicated above,
validation entity 80 may be further configured to generate or otherwise obtain a dCVV2 value for the identification information that it has validated, and to send the dCVV2 value and identification information to both the merchant andpayment processing network 70. For this,validation entity 80 may comprise code that directsprocessor 81 to generate the dCVV2 value or obtain a dCVV2 value for the issuingbank 60 and to send it to both themerchant website 20 and thepayment processing network 70, along with the validated identification information. Instead of sending the dCVV2 value to themerchant 20, or in place thereof,validation entity 80 may send the dCVV2 value totoken 40, where token 40 oruser 1 may enter the dCVV2 value into the CVV field of the merchant's checkout page. If bothmerchant 20 and token 40 receive the dCVV2 value fromvalidation entity 80, thenmerchant 20 can use the dCVV2 value it receives fromuser 1 and token 40 (via entry onto the merchant' check out page) to verify that it has properly correlated the identification information received fromentity 80 with the user's purchase session. Exemplary codes for processing the dCCV2 value byentity 80 are described section below in greater detail. -
Verification entity 80 may further comprise code that directsprocessor 81 to send an alert text message to thecommunication device 7 ofuser 1 or send an alert e-mail message to an e-mail account ofuser 1 when one or more of the following events occurs: (1) whenverification token 40 initiates communications withentity 80, (2) whenverification token 40 reads aportable consumer device 5 ofuser 1, (3) whenverification entity 80 receives identification information from aportable consumer device 5 or averification token 40 associated withuser 1, (4) whenverification entity 80 validates said identification information, (5) whenverification entity 80 sends validated identification information to a merchant (and optional sends a dCVV2 value to other entities), and (6) whenverification entity 80 denies a request to send identification information to a merchant. The alerts sent byentity 80 may include information related to the events that triggered the alerts, such as a portion of account number involved and the merchant name. The alert text messages may be sent fromnetworking facility 84 to anSMS relay server 35 that is coupled to one ofcommunications networks communication device 7. The SMS relay server has an interface to one or more mobile communication networks, and can relay the text message to the phone number or network address provided byprocessor 81.Validation entity 80 may comprise the relay server. Email alerts may be sent directly to the user's e-mail account from networkingfacility 84. For this, networkingfacility 84 may comprise a conventional mail agent, which is well known to the art. - In view of this disclosure, one of ordinary skill in the art will be readily able to construct the code and instructions to implement the above-described codes without undue experimentation.
-
Validation entity 80 may comprise a website accessible to theuser 1 that enables the user: (1) to create a password-protected management account associated with the serial number of the token, the latter of which may be provided on a slip of paper originally sent with the token; (2) to associate an e-mail address to be used for one or more of the above-described alerts; (3) to associate a mobile number and/or URID (e.g., network address) of the user'scommunications device 5 to be used for one or more of the above-described alerts; and (4) to select one or more of the above-described alert conditions The website may also enable the user to provide and associate the account numbers for one or more of the user'sdevices 5 with the password-protected account, and may further enable the user to associate the e-mails and mobile numbers for the alerts toparticular devices 5 according to their account numbers. The website may also enable the user to associate a shipping address and/or billing address to one or more specific device account numbers, whichvalidation entity 80 may provide tomerchant 20 along with the identification information with each request for sending such information is made bytoken 40 for such a specified device account number. This association may include an option that the user can select for a specified device account that directsentity 80 to obtain the address information from the issuingbank 60 for the specified device account. The website may also enable the user to associate a shipping address and/or billing address to the token itself, whichvalidation entity 80 may provide tomerchant 20 for each request to send identification information to a merchant in which a shipping address and/or billing address has not been associated to the device account number or contained in the request fromtoken 40. - One of
databases 86 may be assigned to hold the above-described password-protected accounts of the users. Whenvalidation entity 80 receives a request fromverification token 40 to send identification information to a merchant, code inentity 80 can direct processor(s) 81 to query thisdatabase 86 to find the user's password-protected account (e.g., identify the user from the token's serial number and/or the account number sent in the identification information), to determine what text message alerts and emails are to be generated and sent based on the parameters stored in the password-protected account, to identify the mobile phone number or universal resource identifier (e.g., network address) of the personal communication device to which to sent the messages, and/or to identify the email address to which to send the messages, and to send the determined messages to the identified destinations. One or more alerts pertaining to a particular request may be combined together into a single text message or email to the user.Entity 80 can also have code that directs data processor(s) 81 to determine from the account record if any shipping address information or billing address information is to be sent with the communication to themerchant 20 by looking up the settings that the user may have provided for the device account number indicated in the request message, and to send the address information tomerchant 20 according to the found settings. The above codes and actions can be implemented with HTML page codes, XML page codes, and the like (e.g., web pages), conventional I/O instructions, memory access instructions, database API function calls, CPU arithmetic instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation. -
FIG. 4 illustrates anexemplary embodiment 180 of a method that can be used byvalidation entity 80.Exemplary method 180 comprises a plurality of actions 181-186.Action 181 comprises establishing a communication link betweenvalidation entity 80 and averification token 40 using a networking facility ofvalidation entity 80.Action 182 comprises receiving encrypted identification information pertaining todevice 5 and/or token information (e.g., serial number and encrypted message) sent byverification token 40.Action 183 comprises decrypting the encrypted information (e.g., encrypted identification information and/or encrypted message from the token).Action 184 comprises applying at least one validation test to the decrypted information.Action 185 comprises transmitting, if a selected number of validation tests are passed, data representative of at least a portion of the identification information to a merchant, as described above.Action 185 may also, as an option, send a device verification value (dCVV2 value) toverification token 40 and/ormerchant 20, and topayment processing network 70.Action 186 comprises identifying the user (e.g., the user's account) from the identification information, and sending text and/or email alerts to the user as specified in the user's password-protected account. - Exemplary Validation Tests and Code Therefor.
- As described above, a first validation test that
validation entity 80 may apply pertains to verifying thatverification token 40 is authentic. For this,verification token 40 may send its serial number tovalidation entity 80, along with a test message encrypted by an encryption key, with the test message and encryption key (or corresponding decryption key) being known to token 40 and entity 80 (but not the general public), and with the encryption key further being uniquely assigned to the token's serial number.Validation entity 80 may access a database of token serial numbers and corresponding uniquely-assigned encryption keys (or corresponding decryption keys) in one ofdatabases 86, and may determine whetherverification token 40 has sent a correct test message for the serial number that the token provided. The test message may be fixed or variable; in the latter case it may be generated based on information known to both token 40 andentity 80. The test message may be encrypted and decrypted by a triple DES algorithm, which can be implemented by a number of well known sets of computer instructions using a single symmetric encryption key. The test message may also be encrypted by a first key of an asymmetric encryption key set at theverification token 40 and decrypted by the second key (the decryption key) of the asymmetric encryption key set atvalidation entity 80, which can be implemented by a number of well known sets of computer instructions. To validate the encrypted test message sent bytoken 40,entity 80 can decrypt the test message using the key that it has, and can compare the decrypted test message to a set of acceptable messages for a match.Entity 80 may also validate the encrypted test message in the reverse way by encrypting the set of acceptable messages and comparing the encrypted test message sent by token 40 to its set of encrypted acceptable messages. If the sent test message is correct, the first validation test can be deemed to have been passed, otherwise the first validation test is deems to have failed. - To implement the above validation test,
validation entity 80 may comprise code embodied on computer-readable medium 82 that directsdata processor 81 to receive one or more messages fromverification token 40 vianetworking facility 84 that has the token's serial number and encrypted test message, code that directsdata processor 81 to obtain from one of databases 86 a key that has been assigned to the received serial number of the token and one or more acceptable messages that can be accepted as the correct test message, and code that directs the data processor to validate the encrypted test message from the token using the encrypted test message, the obtained key, and the obtained one or more acceptable messages. The latter validation code may comprise code that directsdata processor 81 to decrypt the encrypted test message using the obtained key, and code that directsdata processor 81 to compare the decrypted test message to the one or more acceptable messages to determine if the first validation test has been passed (in the case of a match between the decrypted test message and an acceptable message), or has been failed (in the case of no such match). In addition, or as another approach, the above validation code may comprise code that directsdata processor 81 to encrypt the obtained acceptable messages with the encryption key for token 40 (as found in the database according to the token's serial number), to compare the encrypted test message from token 40 to the one or more encrypted acceptable messages to determine if the first validation test has been passed (in the case of a match between the encrypted test message and an encrypted acceptable message), or has been failed (in the case of no such match). An acceptable message may be obtained by accessing it directly from one ofdatabases 86, or by generating it from information stored in one or more ofdatabases 86. As an option, if the first validation test is failed,validation entity 80 may record the serial number of the failedtoken 40 and the source IP address from which the failed token 40 made the request in one ofdatabases 86. For this,validation entity 80 may further comprise code that directsdata processor 81 to obtain the source IP address from the request message and to store the source IP address and the token's serial number as one record or two separate records in one ofdatabases 86, which may be called the failedvalidation database 86. This information may be accessed as port of the second validation test described below. The above codes can be implemented with conventional I/O instructions, API function calls to databases, memory access instructions, CPU arithmetic and logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation. - As a second validation test,
validation entity 80 may have a database indatabases 86 that tracks the serial numbers of verification tokens that have been used in fraudulent activities (e.g., suspicious tokens), andvalidation entity 80 may check the serial number ofverification token 40 against this database. If a check of this database indicates thatverification token 40 has not been involved in fraudulent activity or is not otherwise suspicious, the second validation test can be deemed to have been passed. To assist in tracking fraudulent activity back to a verification token,validation entity 80 may send the serial number oftoken 40 along with the dCVV2 value and account number that it sends topayment processing network 70. Ifnetwork 70 later finds out that the transaction processed with the account number provided bytoken 40 was fraudulent, it can send a message to that effect tovalidation entity 80, andentity 80 may then enter the serial number of the token into the database of tokens used in fraudulent activities. To implement the second validation test,validation entity 80 may comprise code embodied on computer-readable medium 82 that directsdata processor 81 to receive a message fromverification token 40 vianetworking facility 84 that has the token's serial number, code that directsdata processor 81 to have the received serial number compared with serial numbers stored in a database ofdatabases 86 that stores serial numbers of suspicious tokens used in fraudulent transactions to determine if the second validation test has been passed (no fraudulent activity), or has been failed (fraudulent activity). This code may further include instructions thatdirect processor 81 to obtain the source IP address of the message fromtoken 40, and to compare the source IP address and the serial number oftoken 40 to IP addresses and serial numbers in the failedvalidation database 86 for a match. If a match is found, the second validation test may be deemed to have been failed. Checking the token serial numbers and IP addresses in this way prevents retry attacks by fraudsters. The above codes can be implemented with conventional I/O instructions, API function calls to databases, memory access instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation. - As a third validation test,
validation entity 80 may send a message toverification token 40 requesting that token 40 send it one or more pieces of computer-specific information aboutcomputer 10, such as the serial numbers of one or more of the following: the computer's processor, one or more of the computer's disk drives, the computer's operating system.Validation entity 80 may receive this information and check it against a database storing computer-specific information of suspicious computers known to have been involved in fraudulent activity. If a check of this database indicates that thecomputer 10 used byverification token 40 has not been involved in fraudulent activity, the third validation test can be deemed to have been passed. To assist in tracking fraudulent activity back tocomputer 10,validation entity 80 may send the serial number oftoken 40 and the computer-specific information along with the dCVV2 value and account number that it sends topayment processing network 70. Ifnetwork 70 later finds out that the transaction processed with the account number provided bytoken 40 was fraudulent, it can send a message to that effect tovalidation entity 80, andentity 80 may then enter the serial number of the token into the database of suspicious tokens used in fraudulent activities, and the computer-specific information into the database of suspicious computers known to have been involved in fraudulent activity. To implement the third validation test,validation entity 80 may comprise code embodied on computer-readable medium 82 that directsdata processor 81 to send a message toverification token 40 requesting computer-specific information (ifverification token 40 has not sent such information beforehand without prompting), code that directsdata processor 81 to receive one or more data messages fromverification token 40 vianetworking facility 84 that have the token's serial number and the computer-specific information, and code that directsdata processor 81 to have the received computer-specific information compared with computer-specific information stored in a database (of databases 86) that stores computer-specific information of suspicious computers used in fraudulent transactions to determine if the third validation test has been passed (no fraudulent activity), or has been failed (fraudulent activity). The above codes can be implemented with conventional I/O instructions, API function calls to databases, memory access instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation. - As a fourth validation test,
validation entity 80 may compare a digital fingerprint received in the identification information, if present, with the stored copy of the valid digital fingerprint thatentity 80 has for the account number specified by the identification information. If the digital fingerprints match to an acceptable degree (e.g., the degree of similarity, or correlation, of the two fingerprints being above a selected level of similarity),validation entity 80 can deem the fourth validation test as being passed. The degree of similarity between the two fingerprints may be assessed by applying a correlation function to the two fingerprints. Such correlation functions are well known to the art. Before receiving identification information for aportable consumer device 5 from a token, the issuing bank for the device may providevalidation entity 80 with the valid digital magnetic fingerprint of the device, whichentity 80 may store in one ofdatabases 86. Whenvalidation entity 80 receives identification information from averification token 40 for a specificportable consumer device 5, it accessesdatabases 86 for its record of the valid digital fingerprint, and compares the received fingerprint against the valid digital fingerprint to assess a degree of similarity, and to determine if the fourth validation test has been passed (e.g., the degree of similarity between the two fingerprints is above a selected level), or has been failed (e.g., the degree of similarity between the two fingerprints is below the selected level). To implement the fourth validation test,validation entity 80 may comprise code embodied on computer-readable medium 82 that directsdata processor 81 to obtain the stored valid digital fingerprint for the account from one ofdatabases 86, and code that directsdata processor 81 to compare the received digital fingerprint and the stored valid digital fingerprint for similarity to determine if the forth test is passed (sufficient similarity) or failed (not sufficient similarity). The latter code may comprise code that directsdata processor 81 to generating a value representative of the similarity between the two fingerprints by applying one or more correlation functions to the fingerprints, and comparing the value against a selected level. Such correlation functions, also known as probabilistic models, are known to the credit card art. The above codes can be implemented with conventional I/O instructions, API function calls to databases, memory access instructions, CPU arithmetic instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation. - As a fifth validation test,
validation entity 80 may perform a fifth validation test that compares a variable datum (e.g., CVC3, dCVV, cryptogram) received as part of the identification information, if present, with a set of one or more acceptable values for the variable datum thatvalidation entity 80 has for the account number provided as part of the identification information. If the values match,validation entity 80 can deem the fifth validation test as being passed. There are number of ways that the variable datum can be configured to vary with time. As some examples, the variable datum can be configured to have its value vary with each use ofportable consumer device 5, anddevice 5 can provide a counter value in the datum or along with the datum.Validation entity 80 or a payment processing network can use the counter value to determine what value the variable datum should have for the given counter value. This determination may be done based on an algorithm that is a function of the counter value (and/or other possible variables), or a look-up table whose entries are correlated to the counter value (the table may be cyclically repeated). The algorithm may comprise one or more random number generators, each of which accepts a starting “seed” value, whose value can be selected to customize the algorithm to a particularportable consumer device 5. The values of the look-up table may be based on the output of the algorithm. The variable datum may also be based on time, date, or other information known to bothverification token 40 andentity 80, which may or may not use a counter value. Additional ways of generating the values of a variable datum are discussed in U.S. patent application Ser. No. 10/642,878 entitled “Method and System for Generating a Dynamic Verification Value” filed on Aug. 18, 2003, now issued as U.S. Pat. No. 7,761,374, and in U.S. patent application Ser. No. 11/764,376 entitled “On-Line Payment Transactions” filed on Jan. 29, 2008, now issued as U.S. Pat. No. 7,740,168. Both of these applications are incorporated herein by reference in their entirely for all purposes. In some implementations, there may be slight differences in the starting information thatdevice 5 andentity 80 use in generating their respective datum values, such as differences in the times of their clocks, andentity 80 may generate a set of acceptable datum values based on possible slight differences in the starting information, and may compare the datum value received fromdevice 5 with each member of the set to determine if a match exists. - A cryptogram, which typically has more characters than a CVC3 value or a dCVV value, may be generated by an algorithm in a similar way as described above, except that a piece of transaction information is usually included as an input to the algorithm. As previously described below, if
token 40 seeks a cryptogram from a cryptogram-enableddevice 5, it providesdevice 5 with dummy transaction information which is known to both token 40 andvalidation entity 80, but not known to the general public. When the variable datum received byentity 80 fromtoken 40 comprises a cryptogram (which may be deduced from the character length of the variable datum or the account number of the device 5),validation 80 may look up the dummy transaction information in one of itsdatabases 86 based upon the serial number oftoken 40.Validation entity 80 may determine the identity of the issuingbank 60 for thedevice 5 based on the device's account number, and may request the current value of the card's Application Transaction Counter (ATC) from the issuingbank 60.Entity 80 may then generate the cryptogram based on the dummy transaction information, the ATC, and other information used in the algorithm, and compare the generated cryptogram with the cryptogram received fromtoken 40. If the cryptograms match,validation entity 80 can deem the fifth validation test as being passed. In some implementations, there may be slight differences in the ATC values thatdevice 5 andentity 80 use in generating their respective cryptograms, andentity 80 may generate a set of acceptable cryptograms based on small incremental differences in the ATC value, and may compare the cryptogram received fromdevice 5 with each member of the set to determine if a match exists. If a match cannot be found, the fifth validation test is deemed to have been failed. As another approach,validation entity 80 may forward a request for the cryptogram's value to the issuingbank 60 along with a copy of the dummy transaction information.Validation entity 80 may then compare the cryptogram received back from the issuing back to that received from token 40 to determine whether there is a match. As yet another approach,validation entity 80 may forward the dummy transaction information and the cryptogram received from token 40 to the issuingbank 60 with a request that the bank determine whether the cryptogram is valid or not, and to send its determination tovalidation entity 80.Validation entity 80 may then determine that the fifth validation test is passed if the bank sends an indication that the cryptogram received fromtoken 40 is valid, and failed otherwise. - Before receiving identification information for a
portable consumer device 5 from a token, the issuing bank for the device may providevalidation entity 80 with the look-up table, algorithm (including any seed values), or other data elements that the device uses to generate the device's variable datum (e.g., CVC3, dCVV, or cryptogram), whichentity 80 may store in one of itsdatabases 86. Whenvalidation entity 80 receives identification information from averification token 40 for a specificportable consumer device 5, it accesses its record of the look-up table, algorithm, or other data elements for thespecific device 5 to determine its value or set of values for the device's variable datum, and compares the received value for a variable datum (e.g., CVC3, dCVV, or cryptogram) against its value or set of acceptable values for the variable datum to determine if the fifth validation test has been passed (e.g., a match in values is found), or has been failed (e.g., a match has not been found). To implement the fifth validation test,validation entity 80 may comprise code embodied on computer-readable medium 82 that directsdata processor 81 to access the one or more stored data elements used to obtain the variable datum for the account from one ofdatabases 86, code that directsdata processor 81 to obtain one or more acceptable values for the variable datum from the one or more stored data elements, and code that directsdata processor 81 to compare the received variable datum and the one or more acceptable values for a match to determine if the fifth test is passed (a match is found) or failed (a match is not found). The code that directsdata processor 81 to obtain one or more acceptable values may be based upon the look-up table method described above, or any of the algorithm based methods described above. The codes may include instructions thatdirect data processor 81 to determine if a received variable datum comprises a cryptogram, and if so, to obtain the dummy transaction information from adatabase 86 based upon the serial number of the token. Depending upon the implementation for processing cryptograms, the code may further include instructions thatdirect data processor 81 to determine the identity of the issuing bank and to obtain an ATC value for thedevice 5 from the bank, and to generate one or more acceptable values of the cryptogram using the dummy transaction information, the ATC value, and other inputs used in the algorithm. Also, the code may further include instructions thatdirect data processor 81 to send the account information and the dummy transaction information to the identified issuing bank with a request for one or more acceptable cryptogram values. Also, instead of directingprocessor 81 to obtain one or more acceptable cryptogram values and to compare the cryptogram received from token 40 to the acceptable cryptogram values, the code may include instructions thatdirect data processor 81 to obtain the dummy transaction information as described above, to identify the issuing bank as described above, to send the account information, dummy transaction information, and the cryptogram received from token 40 to the identified bank with a request that the bank send back an indication of whether or not the cryptogram is valid, and to pass or fail the fifth validation test based on the indication sent back by the issuing bank. The above codes can be implemented with conventional I/O instructions, API function calls to databases, memory access instructions, CPU arithmetic instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation. -
Validation entity 80 may be configured to perform one or more of the above validation tests, and may be configured to send the validated identification information to merchant 20 (as described above), and to optionally send a dCCV2 value toverification token 40 and/ormerchant 20, and topayment processing network 70, if one or more of the tests are passes.Validation entity 80 may comprise code embodied on computer-readable medium 82 that directsdata processor 81 to execute a selected one or more of the validation tests and track the pass/fail results, and code that directsdata processor 81 to take the above actions if a selected number of tests have been passed. - dCVV2 Provisioning by
Entity 80. - Since the dCVV2 value is being sent to both the merchant (directly or relayed through verification token 40) and the payment processing network 70 (which may forward it to the issuing bank),
validation entity 80 may use any method to generate the dCCV2 value, and need not use the method used byportable consumer device 5 to generate the variable datum (e.g., the CVC3 or dCVV).Validation entity 80 may generate the dCVV2 values using a pseudo-random number generator or a look-up table, or a sequential counter (such as when: distributing the values from that counter over different accounts). The dCVV2 generation process can be done on a per transaction basis (fully dynamic), or for a group of transactions (semi-dynamic), the latter being for aparticular device 5 or a group ofdevices 5. If two ormore devices 5 are assigned under a common account number, the identification information sent bytoken 40 may comprises a device identifier as well as an account number, andvalidation entity 80 may use the device identifier to distinguish between the devices and to generate different dCVV2 values for the devices that are under a common account number.Validation entity 80 may use a particular dCVV2 value for aparticular device 5 over a selected time period (such as three days), and then select another dCVV2 value for the particular device for the next selected time period, and so on. Moreover,validation entity 80 may receive the dCVV2 values to use during the selected time periods from the issuing bank of thedevice 5 in advance of the selected time periods, and store them for later use, as determined byentity 80's clock. This permitsvalidation entity 80 to omit the action of sending the dCVV2 values topayment processing network 70. The device verification value provided byvalidation entity 80 may have the same format as the CVC3s and dynamic CVVs (“dCVVs”) output by existing smartcard credit cards (e.g., a string of 3 or 4 numbers). As another approach,validation entity 80 may send a message to the issuingbank 60 forportable consumer device 5 to request a value to provide as the dCVV2 value; this request may include the account number and any device identifier. The above codes and actions can be implemented with conventional I/O instructions, memory access instructions, CPU arithmetic instructions, CPU logic instructions, and CPU control instructions. In view of this disclosure, the codes may be implemented by one of ordinary skill in the art without undue experimentation. -
Exemplary Merchant Computer 20 may comprise a system having one or more servers coupled to a communications networks 31 and 32 that can interact with the user throughcomputer 10 to arrange a purchase transaction and receive identification information and other information regarding the transaction fromvalidation entity 80 to process (e.g., to correlate with open transactions and to complete correlated open transactions). One of the servers ofmerchant 20 is shown inFIG. 8 ; the server comprises one ormore processors 21 electrically coupled to each of a tangible computer-readable medium 22, a operator interface 33, one ormore databases 26, and anetworking facility 24, the latter of which is coupled to first andsecond communications networks User interface 23 comprises one or more video output devices (e.g., displays, screens) and one or more input devices (e.g., keyboard, mouse, trackball, etc.), which enable an administrator ofMerchant 20 to receive information from the server and to provide input to the server. Computer-readable medium 22 may comprise a combination of semiconductor memory and non-volatile storage, such as one or more disk drives and/or non-volatile memory. - Computer-
readable medium 22 stores an operating system for the server, which enables processes and applications to be run by processor(s) 21, and enables codes for directing the operation of processor(s) 21 to be run. The operating system provides services to these processes and applications, and enables these processes and applications to access components ofuser interface 23, portions of computer-readable medium 22,networking facility 24, and other components ofmerchant 20. The operating system may be full featured. Specifically, the operating system provides one or more I/O communications modules that enable processor(s) 21 to communicate withuser interface 23 anddatabases 26. Each I/O communications module has an application programming interface (API) with a collection of functions that aprocessor 21 can call in order to access the components. The operating system ofMerchant computer 20 also comprises one or more network services modules that can accessnetworking facility 24 and set up communications sessions to entities oncommunications networks processor 21 can call in order to manage communications with another entity. With these API facilities, a collection of API function calls can be readily constructed for a processor to execute that enables the processor to establish a communications channel with an entity on a communications network coupled tonetworking facility 24, and to exchange messages and data with the entity. The above operating system, modules, and APIs all include instructions that direct the operation of processor(s) 21. - One or
more databases 26 may be configured as database servers, which processor(s) 21 can access vianetworking facility 24 over aprivate communications network 27, which is illustrated by the dashed line inFIG. 8 .Merchant computer 20 conventionally has aclock 28 for tracking time and dates for various applications.Clock 28 may be a simple counter of seconds, or fractions thereof, that can be read byprocessor 21 by an I/O operation, or may comprise a more complex arrangement of hardware or firmware that can provide the various components of the current date and time (year, month, day, hour, minute, and second) in various registers that can be read byprocessor 21 through the execution of one or more I/O operations. -
Merchant computer 20 comprises a plurality of codes embodied on computer-readable medium 22 for directing data processor(s) 21 to conduct various actions.Merchant computer 20 may comprise a first code that directs data processor(s) 21 to present a website portal tocomputers 10 that provides various web pages that enableusers 1 to select products and/or services for purchase, and that provides each such user with a checkout web page where the user's payment information can be entered. The first code may direct data processor(s) 21 to require the user to login into the user's previously-created merchant-side account before reaching the checkout web page. In this manner,merchant computer 20 will know the user's name, which will enable it to correlate validated identification information fromvalidation entity 80 to the active purchase session. The user merchant-side account may also store the account numbers of one or moreportable consumer devices 5, or the last four digits thereof, that user has registered for use at the merchant site. The above aspects of the first code may be implemented by generating and outputting various HTML and XML pages to the user'scomputer 10, and other codes known to the art for implementing online merchant websites. This aspect of the first code is known to the art and can be implemented by one of ordinary skill in the art without undue experimentation. - As a novel aspect compared to the prior art, the first code may further direct data processor(s) 21 to provide a transaction identifier within the URID of the checkout web page or within the contents of the checkout web page, such as in an HTML or XML field, or the like, where the field may be visible or hidden. This transaction identifier can be read by
verification token 40, as described above, and feedback tomerchant computer 20 viavalidation entity 80 along with the identification information of aportable consumer device 5, and can thus further helpmerchant computer 20 correlate information fromvalidation entity 80 to one of the active purchase sessions being handled by processor(s) 21 under the direction of the first code. An another novel aspect, the first code may further direct data processor(s) 21 to provide a merchant identifier within the URID of the checkout web page or within the contents of the checkout web page, such as in an HTML or XML field, or the like, where the field may be visible or hidden. In those cases wheredevice 5, token 40, and/orvalidation entity 80 are not co-branded with the merchant, the merchant identifier will enable validation entity to determine the identity of the merchant and the communication channel (e.g., URID) to use to relay information to the merchant. The above novel aspects can be implemented with HTML, XML code, or the like, without undue experimentation by one of ordinary skill in the art in view of this disclosure. As a further novel aspect, the first code may direct data processor(s) 21 to create a data structure stored in tangible computer readable memory that lists each active purchase session and the user's name, the identity of the user's merchant-side account, and/or transaction identifier for each active purchase session. In order to facilitate the ability to send inter-process communications, the data structure also preferably lists the corresponding process identification number for the purchase session. Typically, the first code will direct the data processor(s) 21 to create a respective process thread for each active purchase session, where each process thread will execute a section of the first code for the active purchase session. As another approach where the network address (e.g., IP address of the user'scomputer 10 is used for the transaction identifier), the first code may direct data processor(s) 21 to create a data structure stored in tangible computer readable memory that lists each active purchase session, the network address of the corresponding user computer for that active purchase session, and corresponding process identification number for the purchase session. (This data structure may optionally include the user names and identities of their merchant-side accounts. In view of this disclosure, this aspect of the first code can be readily implemented using conventional computer control and memory access instructions by one of ordinary skill in the art without undue experimentation. -
Merchant computer 20 may further comprise a second code that directs data processor(s) 21 to receive messages fromvalidation entity 80, and to correlate the data in each received message to one of the active purchase sessions. A secure communication channel may be established betweenmerchant computer 20 andvalidation entity 80, and the second code may direct data processor(s) 21 to handle the session encryption keys and mutual authentication withvalidation entity 80, which may include decrypting the data sent in the messages formentity 80. In the case wheredevice 5 is cobranded with the merchant, the second code may direct data processor(s) 21 to identify the user's merchant-side account based upon the account number received in the information sent byvalidation entity 80, and to thereafter identify the active purchase session based upon the identity of the merchant-side account. In some cases, this can be simplified when the identification information ofdevice 5 contains the identity (e.g., account number) of the user's merchant-side account. In cases where token 40 is cobranded with the merchant,validation entity 80 may send the serial number oftoken 40 tomerchant computer 20, and the second code can direct data processor(s) 21 to identify the user's merchant-side account based upon the serial number of the token (the serial number being uniquely assigned among the tokens), and to thereafter identify the active purchase session based upon the identity of the merchant-side account. In cases withdevice 5 and token 40 are not cobranded withmerchant 20, and the second code can direct data processor(s) 21 to identify the user's merchant-side account based upon the user name provided in the data sent byentity 80. In cases where there are several user merchant-side accounts with the same user name, the second code may direct processor(s) 21 to select the merchant-side account that is active, and/or the merchant-side account that has the same address information or network address ofcomputer 10 as present in the data sent byentity 80, and/or the merchant-side account that has a previously-registered bank account number (PAN), or portion thereof, that is the same that as provided in the message fromentity 80. Also, if a transaction identifier is present within the message sent byentity 80, the second code may direct data processors(s) 21 to identify the active purchase session based upon the transaction identifier received fromentity 80. As indicated above, this transaction identifier may comprise the network address (e.g., IP address) of the user'scomputer 10. For these various correlation approaches, the second code may direct data processors(s) 21 to access one of the above-described data structures of active purchase sessions created under the direction of the first code. In view of this disclosure, the second code can be readily implemented by one of ordinary skill in the art without undue experimentation using computer control and memory access instructions, function calls to network services, operating system calls, database function calls, etc. - Once the active purchase session is identified by data processors(s) 21, the second code may direct data processor(s) 21 to send the data provided in the message from
entity 80 to the identified (e.g., correlated) active purchase session. This can be done by a inter-process communication of data from the process thread that is executing the second code to the process thread that is executing a section of the first code for the active purchase session. The inter-process communication may be accomplished by appropriate function calls to the operating system, which are known to the art. In response to receiving the inter-process communication, the process thread for the active purchase session accepts the provided data and updates its data structure with the received payment information present in the data. This can include placing the substitute account number as the PAN for the transaction, and placing the payment processing number in an appropriate discretionary field that is pre-agreed upon withpayment processing network 70. This action may be directed by a section of the first code that is being executed by the process thread for the active purchase session. This part of the first code may comprises a third code that directs data processor(s) 21 to resend the merchant checkout page to the user'scomputer 10 with an indication that the payment information has been received. This indication may take the form of providing a merchant checkout page with asterisk characters filling in the fields for the payment information. The process thread, under the direction of the first code, is now ready to receive the user's final approval and commitment to the purchase, such as by waiting for and receiving the user's submission of the checkout page, such as by the user's clicking on the “Submit” button or “Continue” button on the checkout page. Once the user's submission is received, the first code directs data processor(s) 21 to submit the standard transaction approval request, which is sent topayment processing network 70, which is typically sent by way of acquiringbank 50. In view of this disclosure, the second code can be readily implemented by one of ordinary skill in the art without undue experimentation using computer control and memory access instructions, function calls to network services, operating system calls, database function calls, etc - It may be appreciated that in some co-branded embodiments,
validation entity 80 andmerchant computer 20 may be two components owned and operated by a merchant. - In view of the above discussion, it may be appreciated that a method that can be conducted by a merchant may comprise: presenting, from a server, a website portal providing various web pages that enable a plurality of users to select at least one product or service for purchase, the code directing the data processor to create an active purchase session for each user that is actively pursuing a purchase; receiving messages from one or more validation entities, each validation messaging including data representative of at least a portion of the identification information of a portable consumer device; and correlating the information received in a message from a validation entity to an active purchase session.
- In some of the above exemplary embodiments, the
merchant website 20 provides a transaction identifier on its merchant checkout page, andverification token 40 obtains the transaction identifier and sends it tovalidation entity 80. In turn,entity 80 can send the transaction identifier tomerchant 20 with the other information it normally sends so thatmerchant 20 can correlate the information received fromentity 80 to an active purchase session. It is also possible thatvalidation entity 80 can generate this transaction identifier and send it to bothverification token 40 andmerchant 20 to assist in the correlation process at the merchant computer. The transaction identifier may take the form of a “dummy” personal account number (PAN) generated byentity 80, and whichtoken 40 enters into the PAN field of the merchant checkout page. The dummy PAN may start with a sequence of numbers that the merchant recognizes as a dummy PAN (e.g., a dummy bank code), and may be unique over a certain time duration, such as a week (e.g., enough time to complete and process the transactions.User 1 submits the merchant checkout page, and themerchant computer system 20 scans the PAN and recognizes it as a dummy PAN, and then examines a queue of messages fromentity 80 for a matching message having the same dummy PAN as the transaction identifier. When found,merchant computer system 20 uses the payment information contained in the matching message. Instead of providing the transaction identifier as a dummy PAN to be placed in the PAN field of the checkout page, the merchant may provide a separate field in the checkout page to enter it, and a separate button for the user to click to submit the transaction number to the merchant.Merchant 20 can then response by resending an updated checkout page that acknowledges receipt of the payment information, and the user can commit to the purchase by clicking the “Submit” button or “Continue” button.Merchant computer system 20 may further comprise codes that direct processor(s) 21 to perform the above actions.Validation entity 80 may further comprise codes that direct its processor(s) 81 to generate a transaction identifier and to send the transaction identifier to bothverification token 40 andmerchant computer system 20.Verification token 40 may further comprises codes that direct itsprocessor 41 to receive the transaction identifier and to enter it on a designated field of the merchant checkout page, such as the PAN field or another field provided by the merchant. The code is similar in construction to the code that directsprocessor 41 to enter the dCVV2 value into the CVV field of the merchant checkout page. - In each of the embodiments described herein, the communications between
computer 10 andvalidation entity 80 may be facilitated by, and/or conveyed through, a gateway (e.g., a proxy server, server entity, etc.) that is disposed betweencomputer 10 andvalidation entity 80. Such a gateway is shown at 90 inFIG. 9 .Gateway 90 may act as an intermediary between a plurality of verification tokens 40-A, 40-B, . . . and their associated computers 10-A, 10-B, . . . on the one side, and a plurality of validation entities 80-A, 80-B, . . . on the other side. Tokens 40-A, 40-B, . . . may be constructed and configured the same as token 40 shown inFIG. 1 , and may interact with respective computers 10-A, 10B, . . . , respective users 1-A, 1-B, . . . , and respective portable consumer devices 5-A, 5-B, . . . . Computers 10-A, 10B, . . . may be the same ascomputer 10 shown inFIG. 1 , and may be coupled to thefirst communications networks 31, as described above.First communications network 31,second communications network 32,merchant websites 20, acquiringbanks 50, issuingbanks 60, andpayment processing network 70 are coupled to one another as described above. First andsecond communications networks validation entity 80 shown inFIG. 1 . - In the below discussion of the embodiments and implementations shown in
FIG. 9 , a reference number without a suffix -A, -B, or -C generically refers to each of the suffixed items (e.g.,entity 80 refers to each of 80-A, 80-B, 80-C). -
Gateway 90 may receive one or more initial communications from one of verification tokens 40-A, 40-B, . . . (via one of computer 10-A, 10B, . . . in communication with the token), and may determine from information in the initial communication(s) an appropriate one of a plurality of validation entities 80-A, 80-B, 80-C, . . . to use to fulfill the token's request. For example, each verification token 40-A, 40-B, . . . may be configured to operate withportable consumer devices 5 issued by manydifferent issuing banks 60 or other such entities, and one or more of thevalidation entities 80 may be configured to process requests fromportable consumer devices 5 issued by respective issuingbanks 60 or other such entities.Gateway 90 may determine an appropriate one of validation entities 80-A, 80-B, 80-C, . . . based upon the identification information that the token read from a portable consumer device and sent to the gateway in an initial communication. For example, a portion of the account number in the identification information may comprises an unique identifier assigned to thebank 60 that issued theportable consumer devices 5 from which the identification information was read. - In one implementation, after
gateway 90 has determined an appropriate validation entity for the token's request, the gateway may redirect the token to conduct further communications with the determined appropriate validation entity, or may direct the determined validation entity to contact the token to conduct further communications. In another implementation, all communications between the verification token and the determined appropriate validation entity may be conveyed through gateway 90 (after the gateway has initially determined the identity of the appropriate validation entity based upon one or more initial communications with the token). This latter implementation may comprise relatively simple passing through of communications between the token and the appropriate validation entity with minimal processing bygateway 90, or may comprise having the gateway virtually presenting itself as the appropriate validation entity to the verification token. Such virtual presentation may involvegateway 90 decrypting each message from the verification token, communicating with the appropriate validation entity to formulate a response to the token's message, and encrypting and sending a response message to the verification token. In each of the above implementations, and in other implementations,gateway 90 may also conduct one or more validation tests on behalf of the appropriate validation entity, particularly those related to validating the verification token. In this case, the gateway does not need to send to the determined appropriate validation entity those communications it receives from the token that pertain to validation tests that the gateway is handling.Gateway 90 may be associated with, or operated by,payment processing network 70 or the owner thereof. It may be appreciated that, in each of these implementations,Gateway 90 acts as an entity that can provide a device verification value (dCVV2 value) totoken 40, just as in the case thatvalidation entity 80 can provide a device verification value to token 40 whenentity 80 is directly contacted bytoken 40. - Referring to
FIG. 9 ,gateway 90 comprises a system having one or more servers coupled to a communications network that can receive a request from averification token 40 to process, as described above. One of the servers ofgateway 90 is shown inFIG. 9 ; the server comprises one ormore processors 91 electrically coupled to each of a tangible computer-readable medium 92, auser interface 93, one ormore databases 96, and a networking facility 94, the latter of which is coupled to first andsecond communications networks User interface 93 comprises one or more video output devices (e.g., displays, screens) and one or more input devices (e.g., keyboard, mouse, trackball, etc.), which enable an administrator ofgateway 90 to receive information from the server and to provide input to the server. Computer-readable medium 92 may comprise a combination of semiconductor memory and non-volatile storage, such as one or more disk drives and/or non-volatile memory. - Computer-
readable medium 92 stores an operating system for the server, which enables processes and applications to be run by processor(s) 91, and enables codes for directing the operation of processor(s) 91 to be run. The operating system provides services to these processes and applications, and enables these processes and applications to access components ofuser interface 93, portions of computer-readable medium 92, networking facility 94, and other components ofentity 90. The operating system may be full featured. Specifically, the operating system provides one or more I/O communications modules that enable processor(s) 91 to communicate withuser interface 93 anddatabases 96. Each I/O communications module has an application programming interface (API) with a collection of functions that aprocessor 91 can call in order to access the components. The operating system ofentity 90 also comprises one or more network services modules that can access networking facility 94 and set up communications sessions to entities oncommunications networks SMS relay server 35. Such network services modules include Microsoft's Windows Communications Foundation (e.g., .NET 3.0, .NET 4.0, etc.), Apple's CFNetwork Framework, the networking section of the Unix and Linux operating system kernels, and the OS Services Layer and the Base Services Layer of the Symbian operating system, and the like. Each of these network services modules can be non-exclusive (e.g., capable of serving more than one processor and more than one process/application) and each provides an application programming interface (API), which has a collection of functions that aprocessor 91 can call in order to manage communications with another entity. With these API facilities, a collection of API function calls can be readily constructed for a processor to execute that enables the processor to establish a communications channel with an entity on a communications network coupled to networking facility 94, and to exchange messages and data with the entity. The above operating system, modules, and APIs all include instructions that direct the operation of processor(s) 91. - One or
more databases 96 may be configured as database servers, which processor(s) 91 can access via networking facility 94 over aprivate communications network 97, which is illustrated by the dashed line inFIG. 9 .Gateway 90 conventionally has aclock 98 for tracking time and dates for various applications.Clock 98 may be a simple counter of seconds, or fractions thereof, that can be read byprocessor 91 by an I/O operation, or may comprise a more complex arrangement of hardware or firmware that can provide the various components of the current date and time (year, month, day, hour, minute, and second) in various registers that can be read byprocessor 91 through the execution of one or more I/O operations. -
Gateway 90 may comprise code embodied on computer-readable medium 92 that directsdata processor 91 to communicate with acomputer 10 and an associatedverification token 40 using networking facility 94 overcommunications network 31. This code may include instructions that establish a communications session withcomputer 10, including the option of establishing an SSL session with mutual authentication and encryption based on a triple DES algorithm, and instructions for sending and receiving messages toverification token 40 through the communications session.Gateway 90 may further comprise code embodied on computer-readable medium 92 that directsdata processor 91 to receive encrypted identification information sent byverification token 40, and code that directsdata processor 91 to decrypt the encrypted identification information. The identification information may be encrypted by a session key of an SSL session or by an encryption key stored inverification token 40 and known togateway 90, or may be doubly encrypted by both keys. The latter key may be uniquely assigned to the token, as described above.Gateway 90 may further comprise code embodied on computer-readable medium 92 that directsdata processor 91 to determine, from the received identification information and/or the token's identity (e.g., the token's serial number), the appropriate one of the validation entities 80-A, 80-B, 80-C, . . . to be used for further processing of the request fromverification token 40. For this,data processor 91 may access one ofdatabases 96 for a correlation list that relates identification information (or portions thereof) tovalidation entities 80, and/or for a correlation list that relates token identifiers tovalidation entities 80, and may then compare the information received from the token 40 with the correlation list(s) to determine the appropriate one of thevalidation entities 80.Gateway 90 may further comprise code embodied on computer-readable medium 92 that directsdata processor 91 to apply one or more validation tests as previously described above, and to continue processing the request from token 40 if a selected number of validation tests are passed. Various ways of continuing the processing are described below in various possible implementations ofgateway 90. The above codes forgateway 90, and codes forgateway 90 described below, may be implemented in any number of programming languages. Furthermore, one of ordinary skill in the art will be readily able to construct instructions to implement these codes in view of this disclosure without undue experimentation. - In one implementation,
gateway 90 may further comprise code embodied on computer-readable medium 92 that directsdata processor 91 to send a communication to token 40 (by way of its associated computer 10) informing the token to contact the determinedappropriate validation entity 80 to process its request. This communication may include a URID for the determined appropriate validation entity.Token 40 may then communicate with the determinedappropriate entity 80 as described above, and no changes toentity 80 are needed. In this implementation ofgateway 90, the code may further directdata processor 91 to send a communication to the determinedappropriate validation entity 80 that informs the entity of the request from the token 40 (along with an indication of the identification information sent by token 40), and informs the entity that the token 40 will be contacting it for a dCVV2 value for the identification information (as sent togateway 90 by the token 40). This communication bygateway 90 can serve as an additional security measure that assures theappropriate validation entity 80 that the subsequent contact bytoken 40 is legitimate. - In another implementation,
gateway 90 may further comprise code embodied on computer-readable medium 92 that directsdata processor 91 to send a communication to the determinedappropriate validation entity 80 with the identification information and other information received from theverification token 40, and with a request for the validation entity to process the request and to send the dCVV2 value or other information as outlined above to the verification token 40 (by way of its associated computer 10). This communication to the determinedappropriate validation entity 80 may include a URID for theverification token 40. The codes of thevalidation entity 80 previously described above may be augmented to direct the entity'sprocessor 81 to receive above-described communication fromgateway 90, and to initiate communications with the requestingtoken 40. The codes ofvalidation entity 80 need not need to direct the entity'sprocessor 81 to receive the identification information from the requesting token (as that may have been provided to the entity by gateway 90); however, as an added security measure, the requestingtoken 40 may provide the identification information toentity 80, and the entity may include the code to receive the identification information and other information from the token. In this implementation ofgateway 90, the code forgateway 90 may further directdata processor 91 to send a communication to the verification token 40 (via the associate computer 10) informing the token that the determinedappropriate validation entity 80 will be communication with it to potentially send a dCVV2 value. - Other exemplary embodiments for
Gateway 90 are possible, and are described in co-pending patent application Ser. No. 12/780,657, entitled “Verification of Portable Consumer Devices,” filed May 14, 2010, the contents which is incorporated in their entirety by reference for all purposes. - From the above description, it may be appreciated that
validation entities 80 andgateway 90 are separate entities fromcomputers 10, and are separate entities fromverification tokens 40. It may also be appreciated that in several embodiments and implementations thereof thatcomputers 10,validation entities 80, andgateway 90 are addressed as separate network nodes on communications network 31 (e.g., have different network addresses in the communication packets), and thattokens 40 communicate through the network nodes ofcomputers 10 toentities 80 and/or gateway 90 (e.g.,computers 10 construct and decode network communication packets for tokens 40). it may be also appreciated that, in several embodiments and implementations oftoken 40, token 40 may unconditionally send the read identification information tovalidation entity 80 and/orgateway 90 without requiring a validation between the token and the user, such as may be provided by the entry of a PIN or the provision of a biometric sample (e.g., fingerprint); and that token 40 may send the read identification information in a relatively short amount of time (such as within one minute of being read, and typically within ten seconds). - Embodiments of the invention are not limited to the above-described embodiments. For example, although separate functional blocks are shown for an issuer, payment processing system, and acquirer, some entities perform all of these functions and may be included in embodiments of invention.
- It should be understood that various embodiments of the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement embodiments of the present invention using hardware and a combination of hardware and software.
- Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, C, C++, C#, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer-readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
- The above description is illustrative and is not restrictive. Many variations of the invention and embodiments thereof will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
- One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.
- A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.
- All patents, patent applications, publications, and descriptions mentioned above are herein incorporated by reference in their entirety for all purposes. None is admitted to be prior art.
Claims (23)
1.-50. (canceled)
51. A method of communicating payment information to a merchant, the method comprising:
receiving, at a server, identification information of a portable consumer device read and sent by a verification token over a communications network, the verification token being coupled to a computer by way of a peripheral interface of the computer and configured to access a networking facility of the computer;
selecting a merchant to send data representative of at least a portion of the received identification information to; and
sending, from the server, data representative of at least a portion of the received identification information to a computer of the selected merchant.
52. The method of claim 51 , wherein the identification information has an account number associated with a user, wherein selecting the merchant comprises identifying the selected merchant from a portion of the account number.
53. The method of claim 51 , wherein the identification information has a personal account number that comprises a bank number and a user number, wherein selecting the merchant comprises extracting the bank number in the personal account number of the identification information and identifying the selected merchant from the extracted bank number.
54. The method of claim 51 , wherein the identification information is received by the server in the form of a request that includes a merchant identifier, and wherein selecting the merchant comprises identifying the selected merchant from the received merchant identifier.
55. The method of claim 51 , wherein the identification information is received by the server in the form of a request that includes a merchant identifier, and wherein selecting the merchant comprises selecting a single merchant for processing the request before the request is received.
56. The method of claim 51 , further comprising:
applying at least one validation test pertaining to the identification information received by the server before sending the data representative of at least a portion of the received identification information to the computer of the selected merchant.
57. The method of claim 56 , wherein applying at least one validation comprises:
receiving a serial number of the verification token and a test message encrypted by the verification token by an encryption key;
obtaining a key and one or more acceptable messages; and
validating the encrypted test message using the encrypted test message, the obtained key, and the obtained one or more acceptable messages.
58. The method of claim 56 , wherein applying at least one validation comprises:
receiving a serial number of the verification token; and
comparing the received serial number with serial numbers of suspicious tokens.
59. The method of claim 56 , wherein applying at least one validation comprises:
receiving one or more data messages having information specific to the computer, the information being obtained by the token; and
comparing the received information with computer-specific information of suspicious computers for a match.
60. The method of claim 56 wherein the identification information is conveyed by way of a network packet on a communications network, and wherein applying at least one validation comprises:
obtaining a source IP address from the network packet; and
comparing the obtained source IP address with suspect IP addresses for a match.
61. The method of claim 56 , wherein the received identification information includes an account number of a portable consumer device and a digital fingerprint of a magnetic stripe of the portable consumer device, and wherein applying at least one validation comprises:
obtaining a valid digital fingerprint for the portable consumer device having the account number in the received identification information; and
comparing the digital fingerprint in the received identification information to the valid digital fingerprint.
62. The method of claim 56 , wherein the received identification information includes an account number of a portable consumer device and a variable datum that varies each time the portable consumer device is read for its identification information, and wherein applying at least one validation comprises:
obtaining one or more acceptable datum values for the portable consumer device having the account number in the received identification information; and
comparing the variable datum in the received identification information to obtain one or more acceptable datum values for a match.
63. The method of claim 56 , wherein the received identification information includes an account number of a portable consumer device and a variable datum that varies each time the portable consumer device is read for its identification information, and wherein applying at least one validation comprises:
sending the account number and the variable datum to an issuing bank with a request for the bank to determine if the variable datum is valid; and
receiving the issuing bank's determination.
64. The method of claim 51 , further comprising:
sending address information to the computer of the selected merchant.
65. The method of claim 51 , further comprising:
sending a device verification value to the computer of the selected merchant along with the data representative of at least a portion of the identification information.
66. The method of claim 65 , further comprising:
sending the device verification value and data representative of at least a portion of the identification information to a payment processing network.
67. The method of claim 65 , further comprising:
sending the device verification value to the verification token.
68. The method of claim 51 , further comprising:
identifying a mobile phone number or universal resource identifier of a communications device associated with the portable consumer device indicated in the received identification information; and
sending a message to the portable communications device indicating that an action has been taken with respect to the user's portable consumer device.
69. The method of claim 68 , wherein the message comprises a text message sent to a cell phone.
70. The method of claim 51 , further comprising:
identifying an email address associated with the portable consumer device indicated in the received identification information; and
sending a message to the identified email address indicating that an action has been taken with respect to the user's portable consumer device.
71.-81. (canceled)
82. A server comprising:
a processor; and
a computer readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor for implementing a method comprising:
receiving, at the server, identification information of a portable consumer device read and sent by a verification token over a communications network, the verification token being coupled to a computer by way of a peripheral interface of the computer and configured to access a networking facility of the computer;
selecting a merchant to send data representative of at least a portion of the received identification information to; and
sending, from the server, data representative of at least a portion of the received identification information to a computer of the selected merchant.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/028,941 US20180315050A1 (en) | 2009-05-15 | 2018-07-06 | Secure communication of payment information to merchants using a verification token |
Applications Claiming Priority (8)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17863609P | 2009-05-15 | 2009-05-15 | |
US24136709P | 2009-09-10 | 2009-09-10 | |
US12/712,148 US7891560B2 (en) | 2009-05-15 | 2010-02-24 | Verification of portable consumer devices |
US12/780,657 US9038886B2 (en) | 2009-05-15 | 2010-05-14 | Verification of portable consumer devices |
US12/878,947 US8893967B2 (en) | 2009-05-15 | 2010-09-09 | Secure Communication of payment information to merchants using a verification token |
US14/511,034 US9582801B2 (en) | 2009-05-15 | 2014-10-09 | Secure communication of payment information to merchants using a verification token |
US15/258,258 US10049360B2 (en) | 2009-05-15 | 2016-09-07 | Secure communication of payment information to merchants using a verification token |
US16/028,941 US20180315050A1 (en) | 2009-05-15 | 2018-07-06 | Secure communication of payment information to merchants using a verification token |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/258,258 Continuation US10049360B2 (en) | 2009-05-15 | 2016-09-07 | Secure communication of payment information to merchants using a verification token |
Publications (1)
Publication Number | Publication Date |
---|---|
US20180315050A1 true US20180315050A1 (en) | 2018-11-01 |
Family
ID=43379618
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/878,947 Active US8893967B2 (en) | 2009-05-15 | 2010-09-09 | Secure Communication of payment information to merchants using a verification token |
US14/511,034 Active 2030-06-10 US9582801B2 (en) | 2009-05-15 | 2014-10-09 | Secure communication of payment information to merchants using a verification token |
US15/258,258 Active US10049360B2 (en) | 2009-05-15 | 2016-09-07 | Secure communication of payment information to merchants using a verification token |
US16/028,941 Abandoned US20180315050A1 (en) | 2009-05-15 | 2018-07-06 | Secure communication of payment information to merchants using a verification token |
Family Applications Before (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/878,947 Active US8893967B2 (en) | 2009-05-15 | 2010-09-09 | Secure Communication of payment information to merchants using a verification token |
US14/511,034 Active 2030-06-10 US9582801B2 (en) | 2009-05-15 | 2014-10-09 | Secure communication of payment information to merchants using a verification token |
US15/258,258 Active US10049360B2 (en) | 2009-05-15 | 2016-09-07 | Secure communication of payment information to merchants using a verification token |
Country Status (1)
Country | Link |
---|---|
US (4) | US8893967B2 (en) |
Cited By (106)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10425129B1 (en) | 2019-02-27 | 2019-09-24 | Capital One Services, Llc | Techniques to reduce power consumption in near field communication systems |
US10438437B1 (en) | 2019-03-20 | 2019-10-08 | Capital One Services, Llc | Tap to copy data to clipboard via NFC |
US10467445B1 (en) | 2019-03-28 | 2019-11-05 | Capital One Services, Llc | Devices and methods for contactless card alignment with a foldable mobile device |
US10467622B1 (en) | 2019-02-01 | 2019-11-05 | Capital One Services, Llc | Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms |
US10489781B1 (en) | 2018-10-02 | 2019-11-26 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10498401B1 (en) | 2019-07-15 | 2019-12-03 | Capital One Services, Llc | System and method for guiding card positioning using phone sensors |
US10506426B1 (en) | 2019-07-19 | 2019-12-10 | Capital One Services, Llc | Techniques for call authentication |
US10505738B1 (en) | 2018-10-02 | 2019-12-10 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10510074B1 (en) | 2019-02-01 | 2019-12-17 | Capital One Services, Llc | One-tap payment using a contactless card |
US10511443B1 (en) | 2018-10-02 | 2019-12-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10516447B1 (en) | 2019-06-17 | 2019-12-24 | Capital One Services, Llc | Dynamic power levels in NFC card communications |
US10523708B1 (en) | 2019-03-18 | 2019-12-31 | Capital One Services, Llc | System and method for second factor authentication of customer support calls |
US10535062B1 (en) | 2019-03-20 | 2020-01-14 | Capital One Services, Llc | Using a contactless card to securely share personal data stored in a blockchain |
US10542036B1 (en) | 2018-10-02 | 2020-01-21 | Capital One Services, Llc | Systems and methods for signaling an attack on contactless cards |
US10541995B1 (en) | 2019-07-23 | 2020-01-21 | Capital One Services, Llc | First factor contactless card authentication system and method |
US10546444B2 (en) | 2018-06-21 | 2020-01-28 | Capital One Services, Llc | Systems and methods for secure read-only authentication |
US10554411B1 (en) | 2018-10-02 | 2020-02-04 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10565587B1 (en) | 2018-10-02 | 2020-02-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10579998B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10582386B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10581611B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10592710B1 (en) | 2018-10-02 | 2020-03-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10607216B1 (en) | 2018-10-02 | 2020-03-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10607214B1 (en) | 2018-10-02 | 2020-03-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10615981B1 (en) | 2018-10-02 | 2020-04-07 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10623393B1 (en) | 2018-10-02 | 2020-04-14 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10630653B1 (en) | 2018-10-02 | 2020-04-21 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10643420B1 (en) | 2019-03-20 | 2020-05-05 | Capital One Services, Llc | Contextual tapping engine |
US10657754B1 (en) | 2019-12-23 | 2020-05-19 | Capital One Services, Llc | Contactless card and personal identification system |
US10664941B1 (en) | 2019-12-24 | 2020-05-26 | Capital One Services, Llc | Steganographic image encoding of biometric template information on a card |
US10680824B2 (en) | 2018-10-02 | 2020-06-09 | Capital One Services, Llc | Systems and methods for inventory management using cryptographic authentication of contactless cards |
US10685350B2 (en) | 2018-10-02 | 2020-06-16 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10686603B2 (en) | 2018-10-02 | 2020-06-16 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
WO2020122898A1 (en) * | 2018-12-12 | 2020-06-18 | Visa International Service Association | Provisioning initiated from a contactless device |
US10701560B1 (en) | 2019-10-02 | 2020-06-30 | Capital One Services, Llc | Client device authentication using contactless legacy magnetic stripe data |
US10713649B1 (en) | 2019-07-09 | 2020-07-14 | Capital One Services, Llc | System and method enabling mobile near-field communication to update display on a payment card |
US10733601B1 (en) | 2019-07-17 | 2020-08-04 | Capital One Services, Llc | Body area network facilitated authentication or payment authorization |
US10733283B1 (en) | 2019-12-23 | 2020-08-04 | Capital One Services, Llc | Secure password generation and management using NFC and contactless smart cards |
US10733645B2 (en) | 2018-10-02 | 2020-08-04 | Capital One Services, Llc | Systems and methods for establishing identity for order pick up |
US10748138B2 (en) | 2018-10-02 | 2020-08-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10757574B1 (en) | 2019-12-26 | 2020-08-25 | Capital One Services, Llc | Multi-factor authentication providing a credential via a contactless card for secure messaging |
US10771253B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10771254B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for email-based card activation |
US10783519B2 (en) | 2018-10-02 | 2020-09-22 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10797882B2 (en) | 2018-10-02 | 2020-10-06 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10832271B1 (en) | 2019-07-17 | 2020-11-10 | Capital One Services, Llc | Verified reviews using a contactless card |
US10841091B2 (en) | 2018-10-02 | 2020-11-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10846683B2 (en) | 2009-05-15 | 2020-11-24 | Visa International Service Association | Integration of verification tokens with mobile communication devices |
US10853795B1 (en) | 2019-12-24 | 2020-12-01 | Capital One Services, Llc | Secure authentication based on identity data stored in a contactless card |
US10860914B1 (en) | 2019-12-31 | 2020-12-08 | Capital One Services, Llc | Contactless card and method of assembly |
US10862540B1 (en) | 2019-12-23 | 2020-12-08 | Capital One Services, Llc | Method for mapping NFC field strength and location on mobile devices |
US10860814B2 (en) | 2018-10-02 | 2020-12-08 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10861006B1 (en) | 2020-04-30 | 2020-12-08 | Capital One Services, Llc | Systems and methods for data access control using a short-range transceiver |
US10871958B1 (en) | 2019-07-03 | 2020-12-22 | Capital One Services, Llc | Techniques to perform applet programming |
US10885410B1 (en) | 2019-12-23 | 2021-01-05 | Capital One Services, Llc | Generating barcodes utilizing cryptographic techniques |
US10885514B1 (en) | 2019-07-15 | 2021-01-05 | Capital One Services, Llc | System and method for using image data to trigger contactless card transactions |
US10909527B2 (en) | 2018-10-02 | 2021-02-02 | Capital One Services, Llc | Systems and methods for performing a reissue of a contactless card |
US10909544B1 (en) | 2019-12-26 | 2021-02-02 | Capital One Services, Llc | Accessing and utilizing multiple loyalty point accounts |
US10915888B1 (en) | 2020-04-30 | 2021-02-09 | Capital One Services, Llc | Contactless card with multiple rotating security keys |
US10949520B2 (en) | 2018-10-02 | 2021-03-16 | Capital One Services, Llc | Systems and methods for cross coupling risk analytics and one-time-passcodes |
US10963865B1 (en) | 2020-05-12 | 2021-03-30 | Capital One Services, Llc | Augmented reality card activation experience |
US10970712B2 (en) | 2019-03-21 | 2021-04-06 | Capital One Services, Llc | Delegated administration of permissions using a contactless card |
US10984416B2 (en) | 2019-03-20 | 2021-04-20 | Capital One Services, Llc | NFC mobile currency transfer |
US10992477B2 (en) | 2018-10-02 | 2021-04-27 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10997573B2 (en) | 2009-04-28 | 2021-05-04 | Visa International Service Association | Verification of portable consumer devices |
US11030339B1 (en) | 2020-04-30 | 2021-06-08 | Capital One Services, Llc | Systems and methods for data access control of personal user data using a short-range transceiver |
US11038688B1 (en) | 2019-12-30 | 2021-06-15 | Capital One Services, Llc | Techniques to control applets for contactless cards |
US11037136B2 (en) | 2019-01-24 | 2021-06-15 | Capital One Services, Llc | Tap to autofill card data |
US11063979B1 (en) | 2020-05-18 | 2021-07-13 | Capital One Services, Llc | Enabling communications between applications in a mobile operating system |
US11062098B1 (en) | 2020-08-11 | 2021-07-13 | Capital One Services, Llc | Augmented reality information display and interaction via NFC based authentication |
US11100511B1 (en) | 2020-05-18 | 2021-08-24 | Capital One Services, Llc | Application-based point of sale system in mobile operating systems |
US11113685B2 (en) | 2019-12-23 | 2021-09-07 | Capital One Services, Llc | Card issuing with restricted virtual numbers |
US11120453B2 (en) | 2019-02-01 | 2021-09-14 | Capital One Services, Llc | Tap card to securely generate card data to copy to clipboard |
US11165586B1 (en) | 2020-10-30 | 2021-11-02 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
US11182771B2 (en) * | 2019-07-17 | 2021-11-23 | Capital One Services, Llc | System for value loading onto in-vehicle device |
US11200563B2 (en) | 2019-12-24 | 2021-12-14 | Capital One Services, Llc | Account registration using a contactless card |
US11210664B2 (en) | 2018-10-02 | 2021-12-28 | Capital One Services, Llc | Systems and methods for amplifying the strength of cryptographic algorithms |
US11210656B2 (en) | 2020-04-13 | 2021-12-28 | Capital One Services, Llc | Determining specific terms for contactless card activation |
US11216799B1 (en) | 2021-01-04 | 2022-01-04 | Capital One Services, Llc | Secure generation of one-time passcodes using a contactless card |
US11222342B2 (en) | 2020-04-30 | 2022-01-11 | Capital One Services, Llc | Accurate images in graphical user interfaces to enable data transfer |
US11245438B1 (en) | 2021-03-26 | 2022-02-08 | Capital One Services, Llc | Network-enabled smart apparatus and systems and methods for activating and provisioning same |
US11282066B1 (en) * | 2019-01-18 | 2022-03-22 | Worldpay, Llc | Systems and methods to provide user verification in a shared user environment via a device-specific display |
US11354555B1 (en) | 2021-05-04 | 2022-06-07 | Capital One Services, Llc | Methods, mediums, and systems for applying a display to a transaction card |
US11361302B2 (en) | 2019-01-11 | 2022-06-14 | Capital One Services, Llc | Systems and methods for touch screen interface interaction using a card overlay |
US11373169B2 (en) | 2020-11-03 | 2022-06-28 | Capital One Services, Llc | Web-based activation of contactless cards |
US11392933B2 (en) | 2019-07-03 | 2022-07-19 | Capital One Services, Llc | Systems and methods for providing online and hybridcard interactions |
US11438329B2 (en) | 2021-01-29 | 2022-09-06 | Capital One Services, Llc | Systems and methods for authenticated peer-to-peer data transfer using resource locators |
US11455620B2 (en) | 2019-12-31 | 2022-09-27 | Capital One Services, Llc | Tapping a contactless card to a computing device to provision a virtual number |
US11482312B2 (en) | 2020-10-30 | 2022-10-25 | Capital One Services, Llc | Secure verification of medical status using a contactless card |
US11521213B2 (en) | 2019-07-18 | 2022-12-06 | Capital One Services, Llc | Continuous authentication for digital services based on contactless card positioning |
US11521262B2 (en) | 2019-05-28 | 2022-12-06 | Capital One Services, Llc | NFC enhanced augmented reality information overlays |
US11562358B2 (en) | 2021-01-28 | 2023-01-24 | Capital One Services, Llc | Systems and methods for near field contactless card communication and cryptographic authentication |
US11574312B2 (en) | 2009-05-15 | 2023-02-07 | Visa International Service Association | Secure authentication system and method |
US11615395B2 (en) | 2019-12-23 | 2023-03-28 | Capital One Services, Llc | Authentication for third party digital wallet provisioning |
US11637826B2 (en) | 2021-02-24 | 2023-04-25 | Capital One Services, Llc | Establishing authentication persistence |
US11651361B2 (en) | 2019-12-23 | 2023-05-16 | Capital One Services, Llc | Secure authentication based on passport data stored in a contactless card |
US11682012B2 (en) | 2021-01-27 | 2023-06-20 | Capital One Services, Llc | Contactless delivery systems and methods |
US11687930B2 (en) | 2021-01-28 | 2023-06-27 | Capital One Services, Llc | Systems and methods for authentication of access tokens |
US11694187B2 (en) | 2019-07-03 | 2023-07-04 | Capital One Services, Llc | Constraining transactional capabilities for contactless cards |
US11777933B2 (en) | 2021-02-03 | 2023-10-03 | Capital One Services, Llc | URL-based authentication for payment cards |
US11792001B2 (en) | 2021-01-28 | 2023-10-17 | Capital One Services, Llc | Systems and methods for secure reprovisioning |
US11823175B2 (en) | 2020-04-30 | 2023-11-21 | Capital One Services, Llc | Intelligent card unlock |
US11902442B2 (en) | 2021-04-22 | 2024-02-13 | Capital One Services, Llc | Secure management of accounts on display devices using a contactless card |
US11935035B2 (en) | 2021-04-20 | 2024-03-19 | Capital One Services, Llc | Techniques to utilize resource locators by a contactless card to perform a sequence of operations |
US11961089B2 (en) | 2021-04-20 | 2024-04-16 | Capital One Services, Llc | On-demand applications to extend web services |
US11995633B2 (en) | 2012-03-06 | 2024-05-28 | Visa International Service Association | Security system incorporating mobile device |
Families Citing this family (96)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11475436B2 (en) * | 2010-01-08 | 2022-10-18 | Blackhawk Network, Inc. | System and method for providing a security code |
US8842834B2 (en) * | 2007-03-19 | 2014-09-23 | Harris Corporation | Robust delivery of packet based secure voice |
US10332171B1 (en) * | 2007-05-24 | 2019-06-25 | Google Llc | Offline to online sales conversion |
US8924308B1 (en) | 2007-07-18 | 2014-12-30 | Playspan, Inc. | Apparatus and method for secure fulfillment of transactions involving virtual items |
US8893967B2 (en) * | 2009-05-15 | 2014-11-25 | Visa International Service Association | Secure Communication of payment information to merchants using a verification token |
US9038886B2 (en) | 2009-05-15 | 2015-05-26 | Visa International Service Association | Verification of portable consumer devices |
US8602293B2 (en) | 2009-05-15 | 2013-12-10 | Visa International Service Association | Integration of verification tokens with portable computing devices |
US8534564B2 (en) | 2009-05-15 | 2013-09-17 | Ayman Hammad | Integration of verification tokens with mobile communication devices |
US20110147451A1 (en) * | 2009-12-23 | 2011-06-23 | Sanjay Bakshi | Near field communication secure transactions |
US9342832B2 (en) | 2010-08-12 | 2016-05-17 | Visa International Service Association | Securing external systems with account token substitution |
US20120116957A1 (en) * | 2010-11-04 | 2012-05-10 | Bank Of America Corporation | System and method for populating a list of transaction participants |
USD774529S1 (en) | 2010-11-04 | 2016-12-20 | Bank Of America Corporation | Display screen with graphical user interface for funds transfer |
US20160277412A1 (en) * | 2010-11-17 | 2016-09-22 | Invysta Technology Group | Methodology for identifying local/mobile client computing devices using a network based database containing records of hashed distinctive hardware, software, and user provided biometric makers for authorization of electronic transactions and right of entry to secure locations |
USD774527S1 (en) | 2011-02-21 | 2016-12-20 | Bank Of America Corporation | Display screen with graphical user interface for funds transfer |
USD774528S1 (en) | 2011-02-21 | 2016-12-20 | Bank Of America Corporation | Display screen with graphical user interface for funds transfer |
USD774526S1 (en) | 2011-02-21 | 2016-12-20 | Bank Of America Corporation | Display screen with graphical user interface for funds transfer |
AU2012225684B2 (en) | 2011-03-04 | 2016-11-10 | Visa International Service Association | Integration of payment capability into secure elements of computers |
GB201105765D0 (en) | 2011-04-05 | 2011-05-18 | Visa Europe Ltd | Payment system |
US10019704B2 (en) * | 2011-09-26 | 2018-07-10 | Cubic Corporation | Personal point of sale |
US9473295B2 (en) | 2011-09-26 | 2016-10-18 | Cubic Corporation | Virtual transportation point of sale |
CA2848418C (en) * | 2011-09-26 | 2019-08-13 | Cubic Corporation | Personal point of sale |
GB2495704B (en) | 2011-10-12 | 2014-03-26 | Technology Business Man Ltd | ID Authentication |
US9830596B2 (en) * | 2011-11-01 | 2017-11-28 | Stripe, Inc. | Method for conducting a transaction between a merchant site and a customer's electronic device without exposing payment information to a server-side application of the merchant site |
DE112012004804T5 (en) * | 2011-11-19 | 2014-07-31 | International Business Machines Corporation | storage unit |
US9171304B2 (en) * | 2011-11-22 | 2015-10-27 | Aurus Inc. | Systems and methods for removing point of sale processing from PCI scope |
CN103177388B (en) * | 2011-12-22 | 2016-12-07 | ***股份有限公司 | For authoring system and for authorization method |
US8935802B1 (en) | 2012-01-31 | 2015-01-13 | Protegrity Corporation | Verifiable tokenization |
US8825798B1 (en) | 2012-02-02 | 2014-09-02 | Wells Fargo Bank N.A. | Business event tracking system |
WO2013122912A1 (en) | 2012-02-15 | 2013-08-22 | Cardinalcommerce Corporation | Authentication platform for pin debit issuers |
US9659105B2 (en) * | 2012-03-15 | 2017-05-23 | The Nielsen Company (Us), Llc | Methods and apparatus to track web browsing sessions |
US9032217B1 (en) * | 2012-03-28 | 2015-05-12 | Amazon Technologies, Inc. | Device-specific tokens for authentication |
US20130282588A1 (en) * | 2012-04-22 | 2013-10-24 | John Hruska | Consumer, Merchant and Mobile Device Specific, Real-Time Dynamic Tokenization Activation within a Secure Mobile-Wallet Financial Transaction System |
WO2014012037A1 (en) * | 2012-07-13 | 2014-01-16 | Cubic Corporation | Virtual transportation point of sale |
US8973119B2 (en) * | 2012-08-17 | 2015-03-03 | Scannx, Inc. | Secure method to exchange digital content between a scanning appliance and SMS-enabled device |
GB2513494B (en) * | 2012-08-23 | 2015-07-29 | Vzinternet Ltd | Data verification |
CN110889659A (en) * | 2012-09-03 | 2020-03-17 | 手持产品公司 | Method for authenticating parcel recipient by using mark decoding device and decoding device |
USD770478S1 (en) | 2012-09-07 | 2016-11-01 | Bank Of America Corporation | Communication device with graphical user interface |
CN103259711B (en) * | 2012-11-07 | 2016-05-11 | 鹤山世达光电科技有限公司 | communication information transmission method and system |
GB201304764D0 (en) * | 2013-03-15 | 2013-05-01 | Mastercard International Inc | Method and apparatus for payment transactions |
US10108995B2 (en) * | 2013-05-07 | 2018-10-23 | Excalibur Ip, Llc | Online and offline collaboration associated with shopping and purchasing |
WO2015027404A1 (en) * | 2013-08-28 | 2015-03-05 | 华为技术有限公司 | Data transmission processing method and apparatus |
US9922322B2 (en) | 2013-12-19 | 2018-03-20 | Visa International Service Association | Cloud-based transactions with magnetic secure transmission |
SG11201604906QA (en) | 2013-12-19 | 2016-07-28 | Visa Int Service Ass | Cloud-based transactions methods and systems |
US20150371234A1 (en) * | 2014-02-21 | 2015-12-24 | Looppay, Inc. | Methods, devices, and systems for secure provisioning, transmission, and authentication of payment data |
US9721248B2 (en) * | 2014-03-04 | 2017-08-01 | Bank Of America Corporation | ATM token cash withdrawal |
KR102151579B1 (en) * | 2014-04-14 | 2020-09-03 | 마스터카드 인터내셔날, 인코포레이티드 | Method and system for generating an advanced storage key in a mobile device without secure elements |
CN106465112A (en) | 2014-05-21 | 2017-02-22 | 维萨国际服务协会 | Offline authentication |
US9775029B2 (en) | 2014-08-22 | 2017-09-26 | Visa International Service Association | Embedding cloud-based functionalities in a communication device |
US9646307B2 (en) | 2014-09-23 | 2017-05-09 | Sony Corporation | Receiving fingerprints through touch screen of CE device |
US9367845B2 (en) | 2014-09-23 | 2016-06-14 | Sony Corporation | Messaging customer mobile device when electronic bank card used |
US9355424B2 (en) | 2014-09-23 | 2016-05-31 | Sony Corporation | Analyzing hack attempts of E-cards |
US9953323B2 (en) * | 2014-09-23 | 2018-04-24 | Sony Corporation | Limiting e-card transactions based on lack of proximity to associated CE device |
US9317847B2 (en) | 2014-09-23 | 2016-04-19 | Sony Corporation | E-card transaction authorization based on geographic location |
US9558488B2 (en) | 2014-09-23 | 2017-01-31 | Sony Corporation | Customer's CE device interrogating customer's e-card for transaction information |
US9378502B2 (en) | 2014-09-23 | 2016-06-28 | Sony Corporation | Using biometrics to recover password in customer mobile device |
US10262316B2 (en) * | 2014-09-23 | 2019-04-16 | Sony Corporation | Automatic notification of transaction by bank card to customer device |
DE102014219297A1 (en) * | 2014-09-24 | 2016-03-24 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Authentication Stick |
US20160092867A1 (en) * | 2014-09-29 | 2016-03-31 | The Toronto-Dominion Bank | Systems and methods for administering mobile applications using pre-loaded tokens |
WO2016089993A1 (en) * | 2014-12-03 | 2016-06-09 | D Alisa Albert | Proprietary token-based universal payment processing system |
US11049090B2 (en) * | 2015-03-11 | 2021-06-29 | Paypal, Inc. | NFC application registry for enhanced mobile transactions and payments |
US10163083B2 (en) | 2015-04-13 | 2018-12-25 | Bank Of America Corporation | Account activity management system |
WO2017010793A1 (en) | 2015-07-14 | 2017-01-19 | Samsung Electronics Co., Ltd. | Electronic device and payment method using the same |
EP3118789A1 (en) * | 2015-07-14 | 2017-01-18 | Samsung Electronics Co., Ltd. | Payment system, electronic device and payment method thereof |
KR102470570B1 (en) | 2015-07-14 | 2022-11-24 | 삼성전자주식회사 | Payment system, electronic device and payment method thereof |
CN106529952B (en) * | 2015-09-09 | 2021-09-17 | 腾讯科技(深圳)有限公司 | Verification implementation method and system in data transfer |
US11429971B1 (en) * | 2016-06-03 | 2022-08-30 | Jpmorgan Chase Bank, N.A. | Systems, methods, and devices for integrating a first party service into a second party computer application |
GB2551543A (en) * | 2016-06-21 | 2017-12-27 | Eckoh Uk Ltd | Methods of authenticating a user for data exchange |
WO2018004600A1 (en) | 2016-06-30 | 2018-01-04 | Sophos Limited | Proactive network security using a health heartbeat |
BR112018076196A2 (en) | 2016-07-11 | 2019-03-26 | Visa International Service Association | method, and portable communication and access devices. |
US11132682B1 (en) | 2016-07-22 | 2021-09-28 | Wells Fargo Bank, N.A. | Piezoelectric biometric card security |
US11023880B2 (en) * | 2016-07-23 | 2021-06-01 | Vray Inc. | Online mobile payment system and method using authentication codes |
KR20190039173A (en) * | 2016-08-05 | 2019-04-10 | 센소리안트, 인코포레이티드 | SYSTEM AND METHOD FOR MAINTAINING USER PRIVACY IN AN APPLICATION PROVIDING PRODUCTS AND / OR SERVICES |
US10860735B2 (en) | 2016-08-05 | 2020-12-08 | Sensoriant, Inc. | Database system for protecting and securing stored data using a privacy switch |
US10380359B2 (en) | 2016-08-05 | 2019-08-13 | Sensoriant, Inc. | Software-based switch for providing products and/or services to users without compromising their privacy |
US10389733B2 (en) * | 2016-09-06 | 2019-08-20 | Apple Inc. | Data verification via independent processors of a device |
CN112184192A (en) | 2016-12-12 | 2021-01-05 | 创新先进技术有限公司 | Resource allocation method and device and electronic payment method |
CN107395561A (en) * | 2017-06-08 | 2017-11-24 | 上海斐讯数据通信技术有限公司 | WIFI sharing methods, control device, router and system based on cloud account |
US11687929B2 (en) * | 2018-03-23 | 2023-06-27 | American Express Travel Related Services Co., Inc. | Authenticated secure online and offline transactions |
US11144921B2 (en) | 2018-04-05 | 2021-10-12 | The Toronto-Dominion Bank | Generation and provisioning of digital tokens based on dynamically obtained contextual data |
US11785013B2 (en) * | 2018-05-18 | 2023-10-10 | Telefonaktiebolaget Lm Ericsson (Publ) | Application program access control |
US11361284B1 (en) | 2018-05-31 | 2022-06-14 | Stripe, Inc. | Payment processing method and apparatus using an intermediary platform |
US11227252B1 (en) * | 2018-09-28 | 2022-01-18 | The Descartes Systems Group Inc. | Token-based transport rules |
WO2020101654A1 (en) * | 2018-11-13 | 2020-05-22 | Visa International Service Association | System, method, and computer program product for conducting secure online payment transactions |
EP3660766A1 (en) * | 2018-11-28 | 2020-06-03 | Mastercard International Incorporated | Improvements relating to security and authentication of interaction data |
JP2022511964A (en) * | 2018-12-11 | 2022-02-01 | セーセーエス 12 | Devices and methods for securing security data for bank payment cards |
US11275820B2 (en) * | 2019-03-08 | 2022-03-15 | Master Lock Company Llc | Locking device biometric access |
US20200372496A1 (en) * | 2019-05-23 | 2020-11-26 | Clear Labs Israel Ltd. | System and method for validation of business transactions |
TWI726383B (en) * | 2019-08-15 | 2021-05-01 | 互動資通股份有限公司 | Method of identity identification for initiating wepage by messaging service |
US11721336B1 (en) * | 2019-11-22 | 2023-08-08 | Messageloud Inc. | Messaging system for a virtual assistant |
US11374917B2 (en) | 2020-01-24 | 2022-06-28 | Visa International Service Association | Prevention of token authentication replay attacks system and method |
EP3889863A1 (en) | 2020-03-30 | 2021-10-06 | Mastercard International Incorporated | Merchant identification and secure data transfer |
US11316843B1 (en) * | 2020-03-31 | 2022-04-26 | Amazon Technologies, Inc. | Systems for authenticating users from a separate user interface |
US11467848B2 (en) * | 2020-05-07 | 2022-10-11 | Capital One Services, Llc | Portable operating system and portable user data |
US11669834B2 (en) * | 2021-03-02 | 2023-06-06 | Mastercard International Incorporated | Contactless payment technology with payment card network to open banking network conversion |
US11790120B2 (en) | 2021-03-26 | 2023-10-17 | Bank Of America Corporation | System and method for encrypting storage mediums with an encryption chip |
US11886417B2 (en) * | 2021-11-04 | 2024-01-30 | Capital One Services, Llc | Systems and methods for enhancing transaction data |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5477040A (en) * | 1994-05-23 | 1995-12-19 | Lalonde; Michael G. | Structure for a method of facilitating charge transactions |
US7757953B2 (en) * | 2006-01-13 | 2010-07-20 | Magtek, Inc. | Secure magnetic stripe reader |
Family Cites Families (634)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH03180968A (en) | 1989-12-08 | 1991-08-06 | Hitachi Ltd | Data base retrieving method and formated document outputting method using the retrieving method |
US5625669A (en) | 1991-09-27 | 1997-04-29 | Telemac Cellular Corporation | Mobile phone with internal call accounting controls |
US5640577A (en) | 1991-12-30 | 1997-06-17 | Davox Corporation | Data processing system with automated at least partial forms completion |
US5336870A (en) | 1992-05-26 | 1994-08-09 | Hughes Thomas S | System for remote purchase payment transactions and remote bill payments |
US20020044689A1 (en) | 1992-10-02 | 2002-04-18 | Alex Roustaei | Apparatus and method for global and local feature extraction from digital images |
US5365586A (en) | 1993-04-09 | 1994-11-15 | Washington University | Method and apparatus for fingerprinting magnetic media |
EP0776584A4 (en) | 1994-08-15 | 2000-05-24 | Ken Bailey | Cellular telephone credit card billing system |
US5613012A (en) | 1994-11-28 | 1997-03-18 | Smarttouch, Llc. | Tokenless identification system for authorization of electronic transactions and electronic transmissions |
US5550561A (en) | 1995-01-11 | 1996-08-27 | Ziarno; Witold A. | Display cursor controlling device for reading card information from an information bearing credit or debit card |
US5696824A (en) | 1995-06-07 | 1997-12-09 | E-Comm Incorporated | System for detecting unauthorized account access |
US5742845A (en) | 1995-06-22 | 1998-04-21 | Datascape, Inc. | System for extending present open network communication protocols to communicate with non-standard I/O devices directly coupled to an open network |
US5781438A (en) | 1995-12-19 | 1998-07-14 | Pitney Bowes Inc. | Token generation process in an open metering system |
US6044360A (en) | 1996-04-16 | 2000-03-28 | Picciallo; Michael J. | Third party credit card |
US5794259A (en) | 1996-07-25 | 1998-08-11 | Lextron Systems, Inc | Apparatus and methods to enhance web browsing on the internet |
US6032859A (en) | 1996-09-18 | 2000-03-07 | New View Technologies, Inc. | Method for processing debit purchase transactions using a counter-top terminal system |
US5913203A (en) | 1996-10-03 | 1999-06-15 | Jaesent Inc. | System and method for pseudo cash transactions |
KR100213188B1 (en) | 1996-10-05 | 1999-08-02 | 윤종용 | Apparatus and method for user authentication |
US5953710A (en) | 1996-10-09 | 1999-09-14 | Fleming; Stephen S. | Children's credit or debit card system |
GB9624127D0 (en) | 1996-11-20 | 1997-01-08 | British Telecomm | Transaction system |
US5949044A (en) | 1997-06-13 | 1999-09-07 | Walker Asset Management Limited Partnership | Method and apparatus for funds and credit line transfers |
US6163771A (en) | 1997-08-28 | 2000-12-19 | Walker Digital, Llc | Method and device for generating a single-use financial account number |
US7177835B1 (en) | 1997-08-28 | 2007-02-13 | Walker Digital, Llc | Method and device for generating a single-use financial account number |
US6000832A (en) | 1997-09-24 | 1999-12-14 | Microsoft Corporation | Electronic online commerce card with customer generated transaction proxy number for online transactions |
US5883810A (en) | 1997-09-24 | 1999-03-16 | Microsoft Corporation | Electronic online commerce card with transactionproxy number for online transactions |
US5974430A (en) | 1997-09-30 | 1999-10-26 | Unisys Corp. | Method for dynamically embedding objects stored in a web server within HTML for display by a web browser |
US6014635A (en) | 1997-12-08 | 2000-01-11 | Shc Direct, Inc. | System and method for providing a discount credit transaction network |
US6385596B1 (en) | 1998-02-06 | 2002-05-07 | Liquid Audio, Inc. | Secure online music distribution system |
US6055592A (en) | 1998-02-09 | 2000-04-25 | Motorola, Inc. | Smart card authentication system comprising means for converting user identification and digital signature to pointing device position data and vice versa using lut |
US6980670B1 (en) | 1998-02-09 | 2005-12-27 | Indivos Corporation | Biometric tokenless electronic rewards system and method |
US6253328B1 (en) | 1998-02-12 | 2001-06-26 | A. James Smith, Jr. | Method and apparatus for securing passwords and personal identification numbers |
US6636833B1 (en) | 1998-03-25 | 2003-10-21 | Obis Patents Ltd. | Credit card system and method |
US6422462B1 (en) | 1998-03-30 | 2002-07-23 | Morris E. Cohen | Apparatus and methods for improved credit cards and credit card transactions |
US6421729B1 (en) | 1998-04-14 | 2002-07-16 | Citicorp Development Center, Inc. | System and method for controlling transmission of stored information to internet websites |
US6234389B1 (en) | 1998-04-29 | 2001-05-22 | @Pos.Com, Inc. | PCMCIA-based point of sale transaction system |
US6685095B2 (en) | 1998-05-05 | 2004-02-03 | Symagery Microsystems, Inc. | Apparatus and method for decoding damaged optical codes |
US6044349A (en) | 1998-06-19 | 2000-03-28 | Intel Corporation | Secure and convenient information storage and retrieval method and apparatus |
IL125826A (en) | 1998-08-17 | 2001-05-20 | Ur Jonathan Shem | Method for preventing unauthorized use of credit cards in remote payments and an optional supplemental-code card for use therein |
KR100358426B1 (en) | 1998-08-18 | 2003-01-29 | 한국전자통신연구원 | Electronic Cash Transaction Method |
US6947908B1 (en) | 1998-08-27 | 2005-09-20 | Citibank, N.A. | System and use for correspondent banking |
US8799153B2 (en) | 1998-08-31 | 2014-08-05 | Mastercard International Incorporated | Systems and methods for appending supplemental payment data to a transaction message |
US6738749B1 (en) | 1998-09-09 | 2004-05-18 | Ncr Corporation | Methods and apparatus for creating and storing secure customer receipts on smart cards |
US7650419B2 (en) | 1998-09-17 | 2010-01-19 | Axxs Technologies Corporation | Multi-media remote data access terminals and system |
US6499042B1 (en) | 1998-10-07 | 2002-12-24 | Infospace, Inc. | Selective proxy approach to filling-in forms embedded in distributed electronic documents |
US7937325B2 (en) | 1998-12-08 | 2011-05-03 | Yodlee.Com, Inc. | Interactive bill payment center |
US6496808B1 (en) | 1998-12-22 | 2002-12-17 | At&T Corp. | Using smartcards to enable probabilistic transaction on an untrusted device |
US6327578B1 (en) | 1998-12-29 | 2001-12-04 | International Business Machines Corporation | Four-party credit/debit payment protocol |
US6571339B1 (en) | 1998-12-30 | 2003-05-27 | Intel Corporation | Use of a processor identification for authentication |
US6490601B1 (en) | 1999-01-15 | 2002-12-03 | Infospace, Inc. | Server for enabling the automatic insertion of data into electronic forms on a user computer |
US7111324B2 (en) | 1999-01-15 | 2006-09-19 | Safenet, Inc. | USB hub keypad |
US7334184B1 (en) | 1999-03-10 | 2008-02-19 | American Express Travel Related Services Company, Inc. | Method for online information sharing for completing electronic forms |
US7571139B1 (en) | 1999-02-19 | 2009-08-04 | Giordano Joseph A | System and method for processing financial transactions |
US6354496B1 (en) | 1999-04-23 | 2002-03-12 | Symbol Technologies, Inc. | Method for self service checkout |
US6560709B1 (en) | 1999-04-30 | 2003-05-06 | 3Com Corporation | Method and apparatus for the transfer of sensitive card data over an unsecure computer network |
US6227447B1 (en) | 1999-05-10 | 2001-05-08 | First Usa Bank, Na | Cardless payment system |
US7194437B1 (en) | 1999-05-14 | 2007-03-20 | Amazon.Com, Inc. | Computer-based funds transfer system |
US7350139B1 (en) | 2000-06-16 | 2008-03-25 | American Express Travel Related Services Company, Inc. | System and method for utilizing a drag and drop technique to complete electronic forms |
FR2796238B1 (en) | 1999-07-06 | 2001-10-12 | France Telecom | PUBLIC TERMINAL FOR ACCESS TO A COMPUTER NETWORK |
US7908216B1 (en) | 1999-07-22 | 2011-03-15 | Visa International Service Association | Internet payment, authentication and loading system using virtual smart card |
WO2001008066A1 (en) | 1999-07-26 | 2001-02-01 | Iprivacy Llc | Electronic purchase of goods over a communication network including physical delivery while securing private and personal information |
FR2797070B1 (en) | 1999-07-30 | 2001-09-28 | St Microelectronics Sa | CHIP CARD READING INCLUDING AN ENERGY SAVING SYSTEM |
US6873974B1 (en) | 1999-08-17 | 2005-03-29 | Citibank, N.A. | System and method for use of distributed electronic wallets |
SE515327C2 (en) | 1999-08-27 | 2001-07-16 | Ericsson Telefon Ab L M | Device for carrying out secure transactions in a communication device |
US7231045B1 (en) | 1999-08-30 | 2007-06-12 | Intel Corporation | Secure transaction modem storing unique indicia |
PT1212732E (en) | 1999-08-31 | 2004-06-30 | American Express Travel Relate | METHOD AND APPARATUS FOR CONDUCTING ELECTRONIC TRANSACTIONS |
RU2252451C2 (en) | 1999-08-31 | 2005-05-20 | Американ Экспресс Тревл Рилейтед Сервисиз Компани, Инк. | Method for performing transactions, computerized method for network server protection, transaction system, electronic wallet server, computerized online shopping method (variants) and computerized access control method |
US7343351B1 (en) | 1999-08-31 | 2008-03-11 | American Express Travel Related Services Company, Inc. | Methods and apparatus for conducting electronic transactions |
US7216292B1 (en) | 1999-09-01 | 2007-05-08 | Microsoft Corporation | System and method for populating forms with previously used data values |
US7249093B1 (en) | 1999-09-07 | 2007-07-24 | Rysix Holdings, Llc | Method of and system for making purchases over a computer network |
US6748367B1 (en) | 1999-09-24 | 2004-06-08 | Joonho John Lee | Method and system for effecting financial transactions over a public network without submission of sensitive information |
US6589290B1 (en) | 1999-10-29 | 2003-07-08 | America Online, Inc. | Method and apparatus for populating a form with data |
AU1598101A (en) | 1999-11-10 | 2001-06-06 | Serge M. Krasnyansky | On-line payment system |
AU2086301A (en) | 1999-12-10 | 2001-06-18 | Auripay, Inc. | Method and apparatus for improved financial instrument processing |
US6980970B2 (en) | 1999-12-16 | 2005-12-27 | Debit.Net, Inc. | Secure networked transaction system |
AU2202001A (en) | 1999-12-17 | 2001-06-25 | Chantilley Corporation Limited | Secure transaction systems |
US7366703B2 (en) | 2000-01-05 | 2008-04-29 | American Express Travel Related Services Company, Inc. | Smartcard internet authorization system |
AUPQ564400A0 (en) | 2000-02-16 | 2000-03-09 | Ong, Yong Kin (Michael) | Electronic credit card-ecc |
CN1152350C (en) | 2000-02-18 | 2004-06-02 | 西帕克公司 | Method and device for identification and authentication |
AU2001238519A1 (en) | 2000-02-18 | 2001-08-27 | Vasco Data Security, Inc. | Field programmable smart card terminal and token device |
US7426750B2 (en) | 2000-02-18 | 2008-09-16 | Verimatrix, Inc. | Network-based content distribution system |
US20010029485A1 (en) | 2000-02-29 | 2001-10-11 | E-Scoring, Inc. | Systems and methods enabling anonymous credit transactions |
TW550477B (en) | 2000-03-01 | 2003-09-01 | Passgate Corp | Method, system and computer readable medium for Web site account and e-commerce management from a central location |
US7865414B2 (en) | 2000-03-01 | 2011-01-04 | Passgate Corporation | Method, system and computer readable medium for web site account and e-commerce management from a central location |
US6993658B1 (en) | 2000-03-06 | 2006-01-31 | April System Design Ab | Use of personal communication devices for user authentication |
US8121941B2 (en) | 2000-03-07 | 2012-02-21 | American Express Travel Related Services Company, Inc. | System and method for automatic reconciliation of transaction account spend |
AU2001243473A1 (en) | 2000-03-07 | 2001-09-17 | American Express Travel Related Services Company, Inc. | System for facilitating a transaction |
US7430540B1 (en) | 2000-03-13 | 2008-09-30 | Karim Asani | System and method for safe financial transactions in E.Commerce |
AU4365801A (en) | 2000-03-15 | 2001-09-24 | Mastercard International Inc | Method and system for secure payments over a computer network |
US7412422B2 (en) | 2000-03-23 | 2008-08-12 | Dekel Shiloh | Method and system for securing user identities and creating virtual users to enhance privacy on a communication network |
US7379919B2 (en) | 2000-04-11 | 2008-05-27 | Mastercard International Incorporated | Method and system for conducting secure payments over a computer network |
US7177848B2 (en) | 2000-04-11 | 2007-02-13 | Mastercard International Incorporated | Method and system for conducting secure payments over a computer network without a pseudo or proxy account number |
US20050127164A1 (en) | 2002-03-19 | 2005-06-16 | John Wankmueller | Method and system for conducting a transaction using a proximity device and an identifier |
US20100223186A1 (en) | 2000-04-11 | 2010-09-02 | Hogan Edward J | Method and System for Conducting Secure Payments |
US6990470B2 (en) | 2000-04-11 | 2006-01-24 | Mastercard International Incorporated | Method and system for conducting secure payments over a computer network |
US20100228668A1 (en) | 2000-04-11 | 2010-09-09 | Hogan Edward J | Method and System for Conducting a Transaction Using a Proximity Device and an Identifier |
US20020023054A1 (en) | 2000-04-13 | 2002-02-21 | Gillespie Kenneth E. | Method and system for protecting credit card transactions |
CA2305249A1 (en) | 2000-04-14 | 2001-10-14 | Branko Sarcanin | Virtual safe |
CA2406001A1 (en) | 2000-04-14 | 2001-10-25 | American Express Travel Related Services Company, Inc. | A system and method for using loyalty points |
US20070129955A1 (en) | 2000-04-14 | 2007-06-07 | American Express Travel Related Services Company, Inc. | System and method for issuing and using a loyalty point advance |
JP5025875B2 (en) | 2000-04-24 | 2012-09-12 | ビザ・インターナショナル・サービス・アソシエーション | Online Payer Authentication Service Method |
US20010047335A1 (en) | 2000-04-28 | 2001-11-29 | Martin Arndt | Secure payment method and apparatus |
US20010051924A1 (en) | 2000-05-09 | 2001-12-13 | James Uberti | On-line based financial services method and system utilizing biometrically secured transactions for issuing credit |
US6592044B1 (en) | 2000-05-15 | 2003-07-15 | Jacob Y. Wong | Anonymous electronic card for generating personal coupons useful in commercial and security transactions |
WO2001088782A1 (en) | 2000-05-19 | 2001-11-22 | E-Mark Systems Inc. | Electronic settlement system, settlement device and terminal |
AU2001265107A1 (en) | 2000-05-26 | 2001-12-11 | Interchecks, Llc | Methods and systems for network based electronic purchasing system |
KR20000054496A (en) | 2000-06-08 | 2000-09-05 | 김휘주 | Phone, PC System Protection and Authentication by Multifunctional Mouse |
EP1168265A1 (en) | 2000-06-26 | 2002-01-02 | Covadis SA | Device for carrying out secure transactions in a communications network |
AU2001256591A1 (en) | 2000-06-26 | 2002-01-08 | Covadis Sa | Computer keyboard unit for carrying out secure transactions in a communications network |
US6891953B1 (en) | 2000-06-27 | 2005-05-10 | Microsoft Corporation | Method and system for binding enhanced software features to a persona |
WO2002007110A2 (en) | 2000-07-17 | 2002-01-24 | Connell Richard O | System and methods of validating an authorized user of a payment card and authorization of a payment card transaction |
US7082533B2 (en) | 2000-08-04 | 2006-07-25 | First Data Corporation | Gauging risk in electronic communications regarding accounts in ABDS system |
US7257581B1 (en) | 2000-08-04 | 2007-08-14 | Guardian Networks, Llc | Storage, management and distribution of consumer information |
US6938019B1 (en) | 2000-08-29 | 2005-08-30 | Uzo Chijioke Chukwuemeka | Method and apparatus for making secure electronic payments |
WO2002019225A1 (en) | 2000-09-01 | 2002-03-07 | Infospace, Inc. | Method and system for facilitating the transfer of funds utilizing a telephonic identifier |
IL138273A0 (en) | 2000-09-05 | 2001-10-31 | Koren Lea | System and method for secure e-commerce |
US7392388B2 (en) | 2000-09-07 | 2008-06-24 | Swivel Secure Limited | Systems and methods for identity verification for secure transactions |
AU2001292725A1 (en) | 2000-09-12 | 2002-03-26 | American Express Travel Related Services Company, Inc. | Microchip-enabled online transaction system |
DE10045924A1 (en) | 2000-09-14 | 2002-04-04 | Giesecke & Devrient Gmbh | Process for securing a transaction on a computer network |
US7006986B1 (en) | 2000-09-25 | 2006-02-28 | Ecardless Bancorp, Ltd. | Order file processes for purchasing on the internet using verified order information |
US7080048B1 (en) | 2000-09-25 | 2006-07-18 | Ecardless Bancorp, Ltd. | Purchasing on the internet using verified order information and bank payment assurance |
US7292996B2 (en) | 2000-10-06 | 2007-11-06 | Openwave Systems Inc. | Method and apparatus for performing a credit based transaction between a user of a wireless communications device and a provider of a product or service |
US20020073045A1 (en) | 2000-10-23 | 2002-06-13 | Rubin Aviel D. | Off-line generation of limited-use credit card numbers |
US7996288B1 (en) | 2000-11-15 | 2011-08-09 | Iprivacy, Llc | Method and system for processing recurrent consumer transactions |
WO2002046881A2 (en) | 2000-12-09 | 2002-06-13 | Singhal Tara Chand | Method and apparatus for an integrated identity security and payment system |
US20020091877A1 (en) | 2001-01-08 | 2002-07-11 | International Business Machines Corporation | Wide screen notebook input/output device interface |
US6931382B2 (en) | 2001-01-24 | 2005-08-16 | Cdck Corporation | Payment instrument authorization technique |
GB2371665A (en) | 2001-01-25 | 2002-07-31 | Lets Guard It Europ Ab | Call-back function provides a user with an authorisation code for accessing a service |
GB2372616A (en) | 2001-02-23 | 2002-08-28 | Hewlett Packard Co | Transaction method and apparatus using two part tokens |
US7292999B2 (en) | 2001-03-15 | 2007-11-06 | American Express Travel Related Services Company, Inc. | Online card present transaction |
US7237117B2 (en) | 2001-03-16 | 2007-06-26 | Kenneth P. Weiss | Universal secure registry |
EP1381987A4 (en) | 2001-03-26 | 2010-09-22 | 3M Future Ltd | Transaction authorisation system |
US20020147913A1 (en) | 2001-04-09 | 2002-10-10 | Lun Yip William Wai | Tamper-proof mobile commerce system |
US7650314B1 (en) | 2001-05-25 | 2010-01-19 | American Express Travel Related Services Company, Inc. | System and method for securing a recurrent billing transaction |
US8060448B2 (en) | 2001-05-30 | 2011-11-15 | Jones Thomas C | Late binding tokens |
JP4363800B2 (en) | 2001-06-11 | 2009-11-11 | ソニー株式会社 | Electronic commerce support apparatus, electronic commerce support method, and computer program |
US7533063B2 (en) | 2001-06-14 | 2009-05-12 | Silicon Storage Technology, Inc. | Smart memory card wallet |
US7805378B2 (en) | 2001-07-10 | 2010-09-28 | American Express Travel Related Servicex Company, Inc. | System and method for encoding information in magnetic stripe format for use in radio frequency identification transactions |
US20060237528A1 (en) | 2001-07-10 | 2006-10-26 | Fred Bishop | Systems and methods for non-traditional payment |
US7543738B1 (en) | 2001-07-10 | 2009-06-09 | American Express Travel Related Services Company, Inc. | System and method for secure transactions manageable by a transaction account provider |
US7225156B2 (en) | 2001-07-11 | 2007-05-29 | Fisher Douglas C | Persistent dynamic payment service |
US8737954B2 (en) | 2001-08-21 | 2014-05-27 | Bookit Oy Ajanvarauspalvelu | Managing recurring payments from mobile terminals |
US20030038835A1 (en) | 2001-08-24 | 2003-02-27 | Defelice William D. | Digital camera/e-mail kiosk |
US7444676B1 (en) | 2001-08-29 | 2008-10-28 | Nader Asghari-Kamrani | Direct authentication and authorization system and method for trusted network of financial institutions |
KR20030020189A (en) | 2001-09-03 | 2003-03-08 | 윤학범 | Integrated electronic money system |
US6830160B2 (en) | 2001-09-12 | 2004-12-14 | Joseph Robert Risolia | Multi-media vending machine with digital docking station |
FR2829892A1 (en) | 2001-09-14 | 2003-03-21 | St Microelectronics Sa | Secure distribution system for music or documents includes provision of identifiable smart card to each recipient, and decryption key available to recognized smart cards |
US7195154B2 (en) | 2001-09-21 | 2007-03-27 | Privasys, Inc. | Method for generating customer secure card numbers |
US7103576B2 (en) | 2001-09-21 | 2006-09-05 | First Usa Bank, Na | System for providing cardless payment |
BR0213306A (en) | 2001-10-15 | 2006-02-21 | Chequepoint Franchise Corp | computerized money transfer system and process |
WO2003047208A1 (en) | 2001-11-29 | 2003-06-05 | Mobile Commerce Limited | Credit card payment by mobile phone |
US6901387B2 (en) | 2001-12-07 | 2005-05-31 | General Electric Capital Financial | Electronic purchasing method and apparatus for performing the same |
US7805376B2 (en) | 2002-06-14 | 2010-09-28 | American Express Travel Related Services Company, Inc. | Methods and apparatus for facilitating a transaction |
US20030115142A1 (en) | 2001-12-12 | 2003-06-19 | Intel Corporation | Identity authentication portfolio system |
US7159180B2 (en) | 2001-12-14 | 2007-01-02 | America Online, Inc. | Proxy platform integration system |
US20040058705A1 (en) | 2001-12-21 | 2004-03-25 | Russell Morgan | Secure point-of-sale cellular telephone docking module system |
US20030135470A1 (en) | 2002-01-16 | 2003-07-17 | Beard Robert E. | Method and system for credit card purchases |
US6873715B2 (en) | 2002-01-31 | 2005-03-29 | You-Ti Kuo | System of central signature verifications and electronic receipt transmissions |
US7904360B2 (en) | 2002-02-04 | 2011-03-08 | Alexander William EVANS | System and method for verification, authentication, and notification of a transaction |
US7890393B2 (en) | 2002-02-07 | 2011-02-15 | Ebay, Inc. | Method and system for completing a transaction between a customer and a merchant |
AU2003211085B2 (en) | 2002-02-15 | 2008-06-12 | Coinstar Asset Holdings, Llc | Methods and systems for exchanging and/or transferring various forms of value |
US7865432B2 (en) | 2002-02-15 | 2011-01-04 | Coinstar, Inc. | Methods and systems for exchanging and/or transferring various forms of value |
US7003316B1 (en) | 2002-02-22 | 2006-02-21 | Virtual Fonlink, Inc. | System and method for wireless transactions |
GB0204620D0 (en) | 2002-02-28 | 2002-04-10 | Europay Internat N V | Chip authentication programme |
AUPS087602A0 (en) | 2002-03-04 | 2002-03-28 | Ong, Yong Kin (Michael) | Electronic fund transfer system |
US20040210498A1 (en) | 2002-03-29 | 2004-10-21 | Bank One, National Association | Method and system for performing purchase and other transactions using tokens with multiple chips |
AU2003230751A1 (en) | 2002-03-29 | 2003-10-13 | Bank One, Delaware, N.A. | System and process for performing purchase transaction using tokens |
US20030191709A1 (en) | 2002-04-03 | 2003-10-09 | Stephen Elston | Distributed payment and loyalty processing for retail and vending |
GB2387253B (en) | 2002-04-03 | 2004-02-18 | Swivel Technologies Ltd | System and method for secure credit and debit card transactions |
US7707120B2 (en) | 2002-04-17 | 2010-04-27 | Visa International Service Association | Mobile account authentication service |
WO2003091849A2 (en) | 2002-04-23 | 2003-11-06 | The Clearing House Service Company L.L.C. | Payment identification code system |
US20040254890A1 (en) | 2002-05-24 | 2004-12-16 | Sancho Enrique David | System method and apparatus for preventing fraudulent transactions |
US8412623B2 (en) | 2002-07-15 | 2013-04-02 | Citicorp Credit Services, Inc. | Method and system for a multi-purpose transactional platform |
US7209561B1 (en) | 2002-07-19 | 2007-04-24 | Cybersource Corporation | System and method for generating encryption seed values |
US20040127256A1 (en) | 2002-07-30 | 2004-07-01 | Scott Goldthwaite | Mobile device equipped with a contactless smart card reader/writer |
US20040104268A1 (en) | 2002-07-30 | 2004-06-03 | Bailey Kenneth Stephen | Plug in credit card reader module for wireless cellular phone verifications |
US7353382B2 (en) | 2002-08-08 | 2008-04-01 | Fujitsu Limited | Security framework and protocol for universal pervasive transactions |
US7801826B2 (en) | 2002-08-08 | 2010-09-21 | Fujitsu Limited | Framework and system for purchasing of goods and services |
US7784684B2 (en) | 2002-08-08 | 2010-08-31 | Fujitsu Limited | Wireless computer wallet for physical point of sale (POS) transactions |
US7606560B2 (en) | 2002-08-08 | 2009-10-20 | Fujitsu Limited | Authentication services using mobile device |
US7822688B2 (en) | 2002-08-08 | 2010-10-26 | Fujitsu Limited | Wireless wallet |
US7512975B2 (en) | 2002-08-16 | 2009-03-31 | Intel Corporation | Hardware-assisted credential validation |
US7210169B2 (en) | 2002-08-20 | 2007-04-24 | Intel Corporation | Originator authentication using platform attestation |
US20050044385A1 (en) | 2002-09-09 | 2005-02-24 | John Holdsworth | Systems and methods for secure authentication of electronic transactions |
US6805287B2 (en) | 2002-09-12 | 2004-10-19 | American Express Travel Related Services Company, Inc. | System and method for converting a stored value card to a credit card |
US20070005685A1 (en) | 2002-09-16 | 2007-01-04 | Wunchun Chau | Browser-based payment system |
US7356706B2 (en) | 2002-09-30 | 2008-04-08 | Intel Corporation | Personal authentication method and apparatus sensing user vicinity |
WO2004042536A2 (en) | 2002-11-05 | 2004-05-21 | Requent | Remote purchasing system and method |
US7346587B2 (en) | 2002-12-06 | 2008-03-18 | Aol Llc | Intelligent method of order completion in an e-commerce environment based on availability of stored billing information |
GB2396472A (en) | 2002-12-18 | 2004-06-23 | Ncr Int Inc | System for cash withdrawal |
US7827101B2 (en) | 2003-01-10 | 2010-11-02 | First Data Corporation | Payment system clearing for transactions |
TW200412524A (en) | 2003-01-15 | 2004-07-16 | Lee Fung Chi | A small amount paying/receiving system |
US6983882B2 (en) * | 2003-03-31 | 2006-01-10 | Kepler, Ltd. | Personal biometric authentication and authorization device |
US7702916B2 (en) | 2003-03-31 | 2010-04-20 | Visa U.S.A. Inc. | Method and system for secure authentication |
US8082210B2 (en) | 2003-04-29 | 2011-12-20 | The Western Union Company | Authentication for online money transfers |
US7437575B2 (en) | 2003-05-29 | 2008-10-14 | Dell Products L.P. | Low power mode for device power management |
JP2006527430A (en) | 2003-06-04 | 2006-11-30 | マスターカード インターナショナル インコーポレーテッド | Customer authentication system and method in commercial transactions |
US20040248554A1 (en) | 2003-06-09 | 2004-12-09 | Khan Mohammad Ather | Method of paying from an account by a customer having a mobile user terminal, and a customer authenticating network |
BRPI0411286B1 (en) | 2003-06-10 | 2016-12-20 | Mastercard International Inc | system for authenticating a cardholder business transaction with a merchant on an electronic network; data structure to carry information and method for business transaction authentication |
US7483845B2 (en) | 2003-06-24 | 2009-01-27 | Nokia Corporation | Methods, system, and computer readable medium for user data entry, at a terminal, for communication to a remote destination |
US20040267672A1 (en) | 2003-06-26 | 2004-12-30 | Gray William J. | System and method for conducting secure electronic transactions |
WO2005003924A2 (en) | 2003-07-02 | 2005-01-13 | Visa International Service Association | Managing activation of cardholders in a secure authentication program |
GB0318000D0 (en) | 2003-07-31 | 2003-09-03 | Ncr Int Inc | Mobile applications |
US7275263B2 (en) | 2003-08-11 | 2007-09-25 | Intel Corporation | Method and system and authenticating a user of a computer system that has a trusted platform module (TPM) |
US7761374B2 (en) | 2003-08-18 | 2010-07-20 | Visa International Service Association | Method and system for generating a dynamic verification value |
KR20050019674A (en) | 2003-08-20 | 2005-03-03 | 엘지전자 주식회사 | Payment method for mobile credit card using mobile communication device |
US7273168B2 (en) | 2003-10-10 | 2007-09-25 | Xilidev, Inc. | Point-of-sale billing via hand-held devices |
US20050199709A1 (en) | 2003-10-10 | 2005-09-15 | James Linlor | Secure money transfer between hand-held devices |
US7567936B1 (en) | 2003-10-14 | 2009-07-28 | Paradox Technical Solutions Llc | Method and apparatus for handling pseudo identities |
US20050080730A1 (en) | 2003-10-14 | 2005-04-14 | First Data Corporation | System and method for secure account transactions |
US20050108178A1 (en) | 2003-11-17 | 2005-05-19 | Richard York | Order risk determination |
US7313691B2 (en) | 2003-11-18 | 2007-12-25 | International Business Machines Corporation | Internet site authentication service |
US7543739B2 (en) | 2003-12-17 | 2009-06-09 | Qsecure, Inc. | Automated payment card fraud detection and location |
FR2865302B1 (en) | 2004-01-15 | 2006-04-14 | Inst Nat Rech Inf Automat | TRANSACTIONAL DEVICE WITH ANTICIPATED PRETREATMENT. |
EP1708473B1 (en) | 2004-01-20 | 2015-05-13 | Kamfu Wong | A-computer accounting system with a lock using in a bank and the corresponding method used for secure payment by phone |
US7600692B2 (en) | 2004-02-26 | 2009-10-13 | William Call | Systems and methods for managing and using prepaid purchasing accounts |
US7580898B2 (en) | 2004-03-15 | 2009-08-25 | Qsecure, Inc. | Financial transactions with dynamic personal account numbers |
US7584153B2 (en) | 2004-03-15 | 2009-09-01 | Qsecure, Inc. | Financial transactions with dynamic card verification values |
US7431202B1 (en) | 2004-03-17 | 2008-10-07 | Clifford Anthony Meador | System and method to monitor credit card transactions |
US7574600B2 (en) | 2004-03-24 | 2009-08-11 | Intel Corporation | System and method for combining user and platform authentication in negotiated channel security protocols |
GB0407369D0 (en) | 2004-03-31 | 2004-05-05 | British Telecomm | Trust tokens |
US20140019352A1 (en) | 2011-02-22 | 2014-01-16 | Visa International Service Association | Multi-purpose virtual card transaction apparatuses, methods and systems |
US7275685B2 (en) | 2004-04-12 | 2007-10-02 | Rearden Capital Corporation | Method for electronic payment |
US20050250538A1 (en) | 2004-05-07 | 2005-11-10 | July Systems, Inc. | Method and system for making card-based payments using mobile devices |
WO2005109360A1 (en) | 2004-05-10 | 2005-11-17 | Hani Girgis | Secure pin entry using personal computer |
US7660779B2 (en) | 2004-05-12 | 2010-02-09 | Microsoft Corporation | Intelligent autofill |
US20050269402A1 (en) | 2004-06-03 | 2005-12-08 | Tyfone, Inc. | System and method for securing financial transactions |
US20050269401A1 (en) | 2004-06-03 | 2005-12-08 | Tyfone, Inc. | System and method for securing financial transactions |
US7293117B2 (en) | 2004-06-10 | 2007-11-06 | Microsoft Corporation | Self-installing peripheral device with memory wherein in response to user request for additional storage peripheral device being configured to remove installation software stored on memory |
US8001047B2 (en) | 2004-06-18 | 2011-08-16 | Paradox Technical Solutions Llc | Method and apparatus for effecting payment |
US8412837B1 (en) | 2004-07-08 | 2013-04-02 | James A. Roskind | Data privacy |
US7273179B2 (en) | 2004-07-09 | 2007-09-25 | Datalogic Scanning, Inc. | Portable data reading device with integrated web server for configuration and data extraction |
US7264154B2 (en) | 2004-07-12 | 2007-09-04 | Harris David N | System and method for securing a credit account |
US20060016879A1 (en) | 2004-07-26 | 2006-01-26 | First Data Corporation | Presentation instrument security arrangement and methods |
US7287692B1 (en) | 2004-07-28 | 2007-10-30 | Cisco Technology, Inc. | System and method for securing transactions in a contact center environment |
WO2006023839A2 (en) | 2004-08-18 | 2006-03-02 | Mastercard International Incorporated | Method and system for authorizing a transaction using a dynamic authorization code |
JP4477968B2 (en) | 2004-08-30 | 2010-06-09 | Hoya株式会社 | Digital camera |
GB0420409D0 (en) | 2004-09-14 | 2004-10-20 | Waterleaf Ltd | Online commercial transaction system and method of operation thereof |
US7051929B2 (en) | 2004-10-18 | 2006-05-30 | Gongling Li | Secure credit card having daily changed security number |
US20090132413A1 (en) | 2004-11-15 | 2009-05-21 | Runtime Ab | Apparatus and method for secure credit card processing infrastructure |
US7748636B2 (en) | 2004-11-16 | 2010-07-06 | Dpd Patent Trust Ltd. | Portable identity card reader system for physical and logical access |
US20060131390A1 (en) | 2004-12-16 | 2006-06-22 | Kim Mike I | Method and system for providing transaction notification and mobile reply authorization |
US7548889B2 (en) | 2005-01-24 | 2009-06-16 | Microsoft Corporation | Payment information security for multi-merchant purchasing environment for downloadable products |
US20060168653A1 (en) | 2005-01-27 | 2006-07-27 | Contrera Suzanne H | Personal network security token |
ITMI20050178A1 (en) | 2005-02-09 | 2006-08-10 | Fabio Giovanni Attilio Corioni | ELECTRONIC SYSTEM AND METHOD TO RECHARGE CREDIT CARDS |
US8820637B1 (en) | 2005-02-26 | 2014-09-02 | James A. Roskind | Time-varying security code for enabling authorizations and other uses of financial accounts |
KR20060096821A (en) | 2005-03-04 | 2006-09-13 | 주식회사 비즈모델라인 | System and method for processing payment and recording medium |
US7357310B2 (en) | 2005-03-11 | 2008-04-15 | Gerry Calabrese | Mobile phone charge card notification and authorization method |
JP2008541206A (en) | 2005-04-19 | 2008-11-20 | マイクロソフト コーポレーション | Network commerce |
US20060235795A1 (en) | 2005-04-19 | 2006-10-19 | Microsoft Corporation | Secure network commercial transactions |
US7849020B2 (en) | 2005-04-19 | 2010-12-07 | Microsoft Corporation | Method and apparatus for network transactions |
KR20060111200A (en) | 2005-04-22 | 2006-10-26 | 주식회사 케이티프리텔 | Payment method and system with virtual account by using mobile phone number |
US7533047B2 (en) | 2005-05-03 | 2009-05-12 | International Business Machines Corporation | Method and system for securing card payment transactions using a mobile communication device |
US20080035738A1 (en) | 2005-05-09 | 2008-02-14 | Mullen Jeffrey D | Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card |
US7793851B2 (en) | 2005-05-09 | 2010-09-14 | Dynamics Inc. | Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card |
US20060294095A1 (en) | 2005-06-09 | 2006-12-28 | Mantas, Inc. | Runtime thresholds for behavior detection |
WO2006135779A2 (en) | 2005-06-10 | 2006-12-21 | American Express Travel Related Services Company, Inc. | System and method for mass transit merchant payment |
US7347361B2 (en) | 2005-06-13 | 2008-03-25 | Robert Lovett | System, method and program product for account transaction validation |
US20060294023A1 (en) | 2005-06-25 | 2006-12-28 | Lu Hongqian K | System and method for secure online transactions using portable secure network devices |
US8762263B2 (en) | 2005-09-06 | 2014-06-24 | Visa U.S.A. Inc. | System and method for secured account numbers in proximity devices |
US8352376B2 (en) | 2005-10-11 | 2013-01-08 | Amazon Technologies, Inc. | System and method for authorization of transactions |
US8205791B2 (en) | 2005-10-11 | 2012-06-26 | National Payment Card Association | Payment system and methods |
US7853995B2 (en) | 2005-11-18 | 2010-12-14 | Microsoft Corporation | Short-lived certificate authority service |
US7568631B2 (en) | 2005-11-21 | 2009-08-04 | Sony Corporation | System, apparatus and method for obtaining one-time credit card numbers using a smart card |
US20070136193A1 (en) | 2005-12-13 | 2007-06-14 | Bellsouth Intellectual Property Corporation | Methods, transactional cards, and systems using account identifers customized by the account holder |
US7664699B1 (en) | 2005-12-21 | 2010-02-16 | Symantec Corporation | Automatic generation of temporary credit card information |
US8275312B2 (en) | 2005-12-31 | 2012-09-25 | Blaze Mobile, Inc. | Induction triggered transactions using an external NFC device |
US8352323B2 (en) | 2007-11-30 | 2013-01-08 | Blaze Mobile, Inc. | Conducting an online payment transaction using an NFC enabled mobile communication device |
US20070170247A1 (en) | 2006-01-20 | 2007-07-26 | Maury Samuel Friedman | Payment card authentication system and method |
WO2007085090A1 (en) | 2006-01-30 | 2007-08-02 | Cpni Inc. | A system and method for authorizing a funds transfer or payment using a phone number |
US8934865B2 (en) * | 2006-02-02 | 2015-01-13 | Alcatel Lucent | Authentication and verification services for third party vendors using mobile devices |
US20070185820A1 (en) | 2006-02-08 | 2007-08-09 | Talker Albert I | Multi-account security verification system with a virtual account and linked multiple real accounts |
EP1987463A1 (en) | 2006-02-21 | 2008-11-05 | WEISS, Kenneth P. | Method and apparatus for secure access payment and identification |
US8234220B2 (en) | 2007-02-21 | 2012-07-31 | Weiss Kenneth P | Universal secure registry |
KR100792147B1 (en) | 2006-02-22 | 2008-01-04 | 사단법인 금융결제원 | Interactive Financial settlement service method using mobile phone number or virtual number |
MX2008011021A (en) | 2006-03-02 | 2008-09-10 | Visa Int Service Ass | Method and system for performing two factor authentication in mail order and telephone order transactions. |
JP4693171B2 (en) | 2006-03-17 | 2011-06-01 | 株式会社日立ソリューションズ | Authentication system |
US8225385B2 (en) | 2006-03-23 | 2012-07-17 | Microsoft Corporation | Multiple security token transactions |
US7331518B2 (en) | 2006-04-04 | 2008-02-19 | Factortrust, Inc. | Transaction processing systems and methods |
US7818264B2 (en) | 2006-06-19 | 2010-10-19 | Visa U.S.A. Inc. | Track data encryption |
US9065643B2 (en) | 2006-04-05 | 2015-06-23 | Visa U.S.A. Inc. | System and method for account identifier obfuscation |
KR100773293B1 (en) | 2006-04-05 | 2007-11-05 | 삼성전자주식회사 | Multi-functional dongle for portable terminal |
US20070245414A1 (en) | 2006-04-14 | 2007-10-18 | Microsoft Corporation | Proxy Authentication and Indirect Certificate Chaining |
WO2007148234A2 (en) | 2006-04-26 | 2007-12-27 | Yosef Shaked | System and method for authenticating a customer's identity and completing a secure credit card transaction without the use of a credit card number |
US20070272743A1 (en) | 2006-05-22 | 2007-11-29 | American Express Travel Related Services Company, Inc. | Kiosk and Method for Vending Stored Value Cards |
US9195985B2 (en) | 2006-06-08 | 2015-11-24 | Iii Holdings 1, Llc | Method, system, and computer program product for customer-level data verification |
US20070291995A1 (en) | 2006-06-09 | 2007-12-20 | Rivera Paul G | System, Method, and Apparatus for Preventing Identity Fraud Associated With Payment and Identity Cards |
US8077012B2 (en) | 2006-06-16 | 2011-12-13 | Intelleflex Corporation | RFID device with first clock for data acquisition and/or calibration of second clock |
CN101485128B (en) | 2006-06-19 | 2016-08-03 | 维萨美国股份有限公司 | Portable consumer device verification system |
US20080015988A1 (en) | 2006-06-28 | 2008-01-17 | Gary Brown | Proxy card authorization system |
CA2662033C (en) | 2006-08-01 | 2016-05-03 | Qpay Holdings Limited | Transaction authorisation system & method |
US20080040278A1 (en) | 2006-08-11 | 2008-02-14 | Dewitt Timothy R | Image recognition authentication and advertising system |
US10019708B2 (en) | 2006-08-25 | 2018-07-10 | Amazon Technologies, Inc. | Utilizing phrase tokens in transactions |
US7469151B2 (en) | 2006-09-01 | 2008-12-23 | Vivotech, Inc. | Methods, systems and computer program products for over the air (OTA) provisioning of soft cards on devices with wireless communications capabilities |
US20080071681A1 (en) | 2006-09-15 | 2008-03-20 | Khalid Atm Shafiqul | Dynamic Credit and Check Card |
KR20080026802A (en) | 2006-09-21 | 2008-03-26 | 엘지전자 주식회사 | A keyboard, computer body including reader of a credit card, computer system using the same and approving method of the credit card |
US8346639B2 (en) | 2007-02-28 | 2013-01-01 | Visa U.S.A. Inc. | Authentication of a data card using a transit verification value |
US20080228646A1 (en) | 2006-10-04 | 2008-09-18 | Myers James R | Method and system for managing a non-changing payment card account number |
US10068220B2 (en) | 2006-10-11 | 2018-09-04 | Visa International Service Association | Systems and methods for brokered authentication express seller links |
US20100223184A1 (en) | 2006-10-11 | 2010-09-02 | Visa International Service Association | Sponsored Accounts For Computer-Implemented Payment System |
US20080103984A1 (en) | 2006-10-30 | 2008-05-01 | Mobilekash, Inc. | System, Method, and Computer-Readable Medium for Mobile Payment Authentication and Authorization |
US7716596B2 (en) | 2006-11-08 | 2010-05-11 | International Business Machines Corporation | Dynamic input field protection |
US9251637B2 (en) | 2006-11-15 | 2016-02-02 | Bank Of America Corporation | Method and apparatus for using at least a portion of a one-time password as a dynamic card verification value |
US10346837B2 (en) | 2006-11-16 | 2019-07-09 | Visa U.S.A. Inc. | Adaptive authentication options |
DE112007002744T5 (en) | 2006-11-16 | 2009-10-08 | Net1 Ueps Technologies, Inc. | Secured financial transactions |
KR100899477B1 (en) | 2006-12-05 | 2009-05-27 | 백승한 | Authentication system and method for approval |
US7848980B2 (en) | 2006-12-26 | 2010-12-07 | Visa U.S.A. Inc. | Mobile payment system and method using alias |
CN101211436B (en) | 2006-12-29 | 2012-03-21 | 盛大计算机(上海)有限公司 | Electronic commerce safe trading platform and its method |
US20080162312A1 (en) | 2006-12-29 | 2008-07-03 | Motorola, Inc. | Method and system for monitoring secure applet events during contactless rfid/nfc communication |
US20090006262A1 (en) | 2006-12-30 | 2009-01-01 | Brown Kerry D | Financial transaction payment processor |
US20080177796A1 (en) | 2007-01-19 | 2008-07-24 | Eldering Charles A | Method of Distributing Contact Information to Merchant Websites |
JP2008210370A (en) | 2007-02-02 | 2008-09-11 | Dainippon Printing Co Ltd | Sim holder |
US8793184B2 (en) | 2007-02-12 | 2014-07-29 | Visa U.S.A. Inc. | Mobile payment services |
US7841539B2 (en) | 2007-02-15 | 2010-11-30 | Alfred Hewton | Smart card with random temporary account number generation |
US20080201264A1 (en) | 2007-02-17 | 2008-08-21 | Brown Kerry D | Payment card financial transaction authenticator |
US7742995B2 (en) | 2007-03-23 | 2010-06-22 | Mastercard International, Inc. | Pre-authenticated identification token |
US20080243702A1 (en) | 2007-03-30 | 2008-10-02 | Ricoh Company, Ltd. | Tokens Usable in Value-Based Transactions |
US7896238B2 (en) | 2007-04-03 | 2011-03-01 | Intellectual Ventures Holding 32 Llc | Secured transaction using color coded account identifiers |
US7938318B2 (en) | 2007-04-03 | 2011-05-10 | Intellectual Ventures Holding 32 Llc | System and method for controlling secured transaction using directionally coded account identifiers |
US8156543B2 (en) | 2007-04-17 | 2012-04-10 | Visa U.S.A. | Method and system for authenticating a party to a transaction |
US8109436B1 (en) | 2007-04-26 | 2012-02-07 | United Services Automobile Association (Usaa) | Secure card |
US7784685B1 (en) | 2007-04-26 | 2010-08-31 | United Services Automobile Association (Usaa) | Secure card |
US7959076B1 (en) | 2007-04-26 | 2011-06-14 | United Services Automobile Association (Usaa) | Secure card |
TW200845690A (en) | 2007-05-14 | 2008-11-16 | David Chiu | Business protection system in internet |
US7770789B2 (en) | 2007-05-17 | 2010-08-10 | Shift4 Corporation | Secure payment card transactions |
US7841523B2 (en) | 2007-05-17 | 2010-11-30 | Shift4 Corporation | Secure payment card transactions |
US7891563B2 (en) | 2007-05-17 | 2011-02-22 | Shift4 Corporation | Secure payment card transactions |
WO2008144555A1 (en) | 2007-05-17 | 2008-11-27 | Shift4 Corporation | Secure payment card transactions |
US7904389B2 (en) * | 2007-05-30 | 2011-03-08 | Visa U.S.A. Inc. | Real time account update |
US20080306876A1 (en) | 2007-06-05 | 2008-12-11 | Horvath Kris M | Verifying dynamic transaction security code in payment card system |
US7971261B2 (en) | 2007-06-12 | 2011-06-28 | Microsoft Corporation | Domain management for digital media |
US8121942B2 (en) | 2007-06-25 | 2012-02-21 | Visa U.S.A. Inc. | Systems and methods for secure and transparent cardless transactions |
US7739169B2 (en) | 2007-06-25 | 2010-06-15 | Visa U.S.A. Inc. | Restricting access to compromised account information |
US20090006646A1 (en) | 2007-06-26 | 2009-01-01 | Data Frenzy, Llc | System and Method of Auto Populating Forms on Websites With Data From Central Database |
JP2009015548A (en) | 2007-07-04 | 2009-01-22 | Omron Corp | Drive assisting device and method, and program |
US8326758B2 (en) | 2007-08-06 | 2012-12-04 | Enpulz, L.L.C. | Proxy card representing many monetary sources from a plurality of vendors |
DE102007037715A1 (en) | 2007-08-09 | 2009-02-19 | Kobil Systems Gmbh | Installation-free chip card reader for secure online banking |
CN101110113A (en) | 2007-08-10 | 2008-01-23 | 魏恺言 | Multi-use safety device for computing electronic payment code and its generating method |
US8494959B2 (en) | 2007-08-17 | 2013-07-23 | Emc Corporation | Payment card with dynamic account number |
WO2009025605A2 (en) | 2007-08-19 | 2009-02-26 | Yubico Ab | Device and method for generating dynamic credit card data |
US7849014B2 (en) | 2007-08-29 | 2010-12-07 | American Express Travel Related Services Company, Inc. | System and method for facilitating a financial transaction with a dynamically generated identifier |
US9070129B2 (en) | 2007-09-04 | 2015-06-30 | Visa U.S.A. Inc. | Method and system for securing data fields |
US9747598B2 (en) | 2007-10-02 | 2017-08-29 | Iii Holdings 1, Llc | Dynamic security code push |
US8565723B2 (en) | 2007-10-17 | 2013-10-22 | First Data Corporation | Onetime passwords for mobile wallets |
US8095113B2 (en) | 2007-10-17 | 2012-01-10 | First Data Corporation | Onetime passwords for smart chip cards |
US20090106160A1 (en) | 2007-10-19 | 2009-04-23 | First Data Corporation | Authorizations for mobile contactless payment transactions |
US20090106138A1 (en) | 2007-10-22 | 2009-04-23 | Smith Steven E | Transaction authentication over independent network |
CA2703628C (en) | 2007-10-24 | 2016-09-13 | Securekey Technologies Inc. | Method and system for effecting secure communication over a network |
CN101425894B (en) | 2007-10-30 | 2012-03-21 | 阿里巴巴集团控股有限公司 | Service implementing system and method |
KR20090044619A (en) | 2007-11-01 | 2009-05-07 | 신성균 | Card data interface apparatus with a smart-card reader |
US8249985B2 (en) | 2007-11-29 | 2012-08-21 | Bank Of America Corporation | Sub-account mechanism |
US20090157555A1 (en) | 2007-12-12 | 2009-06-18 | American Express Travel Related Services Company, | Bill payment system and method |
US8117129B2 (en) | 2007-12-21 | 2012-02-14 | American Express Travel Related Services Company, Inc. | Systems, methods and computer program products for performing mass transit merchant transactions |
US9684861B2 (en) | 2007-12-24 | 2017-06-20 | Dynamics Inc. | Payment cards and devices with displays, chips, RFIDs, magnetic emulators, magnetic decoders, and other components |
KR20080039330A (en) | 2007-12-27 | 2008-05-07 | 탁승호 | Display and control device for contact and contactless smart card terminal and circuit of the device |
US8224702B2 (en) | 2007-12-28 | 2012-07-17 | Ebay, Inc. | Systems and methods for facilitating financial transactions over a network |
EP2245583A1 (en) | 2008-01-04 | 2010-11-03 | M2 International Ltd. | Dynamic card verification value |
FR2926938B1 (en) | 2008-01-28 | 2010-03-19 | Paycool Dev | METHOD OF AUTHENTICATING AND SIGNING A USER TO AN APPLICATION SERVICE USING A MOBILE PHONE AS A SECOND FACTOR IN COMPLEMENT AND INDEPENDENTLY OF A FIRST FACTOR |
EP2098985A3 (en) | 2008-03-03 | 2012-11-07 | Broadcom Corporation | Secure financial reader architecture |
US8255971B1 (en) | 2008-03-03 | 2012-08-28 | Jpmorgan Chase Bank, N.A. | Authentication system and method |
US8578176B2 (en) | 2008-03-26 | 2013-11-05 | Protegrity Corporation | Method and apparatus for tokenization of sensitive sets of characters |
US8234697B2 (en) | 2008-03-31 | 2012-07-31 | Intel Corporation | Method, apparatus, and system for sending credentials securely |
US20090248583A1 (en) | 2008-03-31 | 2009-10-01 | Jasmeet Chhabra | Device, system, and method for secure online transactions |
US8195588B2 (en) | 2008-04-03 | 2012-06-05 | At&T Intellectual Property I, L.P. | System and method for training a critical e-mail classifier using a plurality of base classifiers and N-grams |
GB2459097B (en) | 2008-04-08 | 2012-03-28 | Advanced Risc Mach Ltd | A method and apparatus for processing and displaying secure and non-secure data |
ES2350775B1 (en) | 2008-04-14 | 2011-10-10 | Avenida Diagonal 477, S.L | AUTHORIZATION PROCEDURE FOR A TRANSACTION BETWEEN A COMPUTER AND A REMOTE SERVER AND COMMUNICATION SYSTEM, WITH IMPROVED SECURITY. |
US9390406B2 (en) | 2008-04-22 | 2016-07-12 | Visa U.S.A. Inc. | Prepaid chip card exception processing |
US20090327131A1 (en) | 2008-04-29 | 2009-12-31 | American Express Travel Related Services Company, Inc. | Dynamic account authentication using a mobile device |
US20090276347A1 (en) | 2008-05-01 | 2009-11-05 | Kargman James B | Method and apparatus for use of a temporary financial transaction number or code |
GB2459850A (en) | 2008-05-07 | 2009-11-11 | Keith Hall | Using a mobile phone for fraud prevention in credit card transactions |
US9715709B2 (en) | 2008-05-09 | 2017-07-25 | Visa International Services Association | Communication device including multi-part alias identifier |
CN101582121A (en) | 2008-05-14 | 2009-11-18 | 北京中食新华科技有限公司 | Logistic information management system using RFID labels |
US20090289110A1 (en) | 2008-05-22 | 2009-11-26 | Paul Regen | Wireless Biometric Computer Mouse with Integrated Credit Card Reader |
US8651374B2 (en) | 2008-06-02 | 2014-02-18 | Sears Brands, L.L.C. | System and method for payment card industry enterprise account number elimination |
US8250207B2 (en) | 2009-01-28 | 2012-08-21 | Headwater Partners I, Llc | Network based ambient services |
US20090307140A1 (en) | 2008-06-06 | 2009-12-10 | Upendra Mardikar | Mobile device over-the-air (ota) registration and point-of-sale (pos) payment |
WO2010005681A1 (en) | 2008-06-16 | 2010-01-14 | Visa U.S.A. Inc. | System and method for authorizing financial transactions with online merchants |
US8898089B2 (en) | 2008-06-24 | 2014-11-25 | Visa U.S.A. Inc. | Dynamic verification value system and method |
US9269010B2 (en) | 2008-07-14 | 2016-02-23 | Jumio Inc. | Mobile phone payment system using integrated camera credit card reader |
US8090650B2 (en) | 2008-07-24 | 2012-01-03 | At&T Intellectual Property I, L.P. | Secure payment service and system for interactive voice response (IVR) systems |
US8219489B2 (en) | 2008-07-29 | 2012-07-10 | Visa U.S.A. Inc. | Transaction processing using a global unique identifier |
US9053474B2 (en) | 2008-08-04 | 2015-06-09 | At&T Mobility Ii Llc | Systems and methods for handling point-of-sale transactions using a mobile device |
US8281991B2 (en) | 2008-08-07 | 2012-10-09 | Visa U.S.A. Inc. | Transaction secured in an untrusted environment |
WO2010022129A1 (en) | 2008-08-20 | 2010-02-25 | Xcard Holdings Llc | Secure smart card system |
US8403211B2 (en) | 2008-09-04 | 2013-03-26 | Metabank | System, program product and methods for retail activation and reload associated with partial authorization transactions |
US7694130B1 (en) | 2008-09-12 | 2010-04-06 | Michael Anthony Martinez | System and method to authenticate a user utilizing a time-varying auxiliary code |
US8965811B2 (en) | 2008-10-04 | 2015-02-24 | Mastercard International Incorporated | Methods and systems for using physical payment cards in secure E-commerce transactions |
US20100094755A1 (en) | 2008-10-09 | 2010-04-15 | Nelnet Business Solutions, Inc. | Providing payment data tokens for online transactions utilizing hosted inline frames |
US20100174556A1 (en) | 2008-10-21 | 2010-07-08 | Mastercard International Incorporated | Method and apparatus for facilitating provider payment |
US20100106644A1 (en) | 2008-10-23 | 2010-04-29 | Diversinet Corp. | System and Method for Authorizing Transactions Via Mobile Devices |
BRPI0921124A2 (en) | 2008-11-06 | 2016-09-13 | Visa Int Service Ass | system for authenticating a consumer, computer implemented method, computer readable medium, and server computer. |
US8126449B2 (en) | 2008-11-13 | 2012-02-28 | American Express Travel Related Services Company, Inc. | Servicing attributes on a mobile device |
US20100125516A1 (en) | 2008-11-14 | 2010-05-20 | Wankmueller John R | Methods and systems for secure mobile device initiated payments |
US20100133335A1 (en) | 2008-11-28 | 2010-06-03 | Hazem Abdel Maguid | System and method for mobile payment |
US8196813B2 (en) | 2008-12-03 | 2012-06-12 | Ebay Inc. | System and method to allow access to a value holding account |
US8838503B2 (en) | 2008-12-08 | 2014-09-16 | Ebay Inc. | Unified identity verification |
US9536238B2 (en) | 2008-12-31 | 2017-01-03 | Peter Garrett | Hand-held electronics device for aggregation of and management of personal electronic data |
US8060449B1 (en) | 2009-01-05 | 2011-11-15 | Sprint Communications Company L.P. | Partially delegated over-the-air provisioning of a secure element |
US10037524B2 (en) | 2009-01-22 | 2018-07-31 | First Data Corporation | Dynamic primary account number (PAN) and unique key per card |
US10354321B2 (en) | 2009-01-22 | 2019-07-16 | First Data Corporation | Processing transactions with an extended application ID and dynamic cryptograms |
US8606638B2 (en) | 2009-03-02 | 2013-12-10 | First Data Corporation | Systems, methods and apparatus for facilitating transactions using a mobile device |
US20100235284A1 (en) | 2009-03-13 | 2010-09-16 | Gidah, Inc. | Method and systems for generating and using tokens in a transaction handling system |
US8595098B2 (en) | 2009-03-18 | 2013-11-26 | Network Merchants, Inc. | Transmission of sensitive customer information during electronic-based transactions |
US8567670B2 (en) | 2009-03-27 | 2013-10-29 | Intersections Inc. | Dynamic card verification values and credit transactions |
KR20100110642A (en) | 2009-04-03 | 2010-10-13 | 유비벨록스(주) | Hardware security module |
US8584251B2 (en) | 2009-04-07 | 2013-11-12 | Princeton Payment Solutions | Token-based payment processing system |
US8763142B2 (en) | 2009-04-07 | 2014-06-24 | Princeton Payment Solutions | Tokenized payment processing schemes |
US20100258620A1 (en) | 2009-04-10 | 2010-10-14 | Denise Torreyson | Methods and systems for linking multiple accounts |
US9572025B2 (en) | 2009-04-16 | 2017-02-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, server, computer program and computer program product for communicating with secure element |
US8326759B2 (en) | 2009-04-28 | 2012-12-04 | Visa International Service Association | Verification of portable consumer devices |
US9715681B2 (en) | 2009-04-28 | 2017-07-25 | Visa International Service Association | Verification of portable consumer devices |
WO2010126509A2 (en) | 2009-04-30 | 2010-11-04 | Donald Michael Cardina | Systems and methods for randomized mobile payment |
US8725122B2 (en) | 2009-05-13 | 2014-05-13 | First Data Corporation | Systems and methods for providing trusted service management services |
US20110119155A1 (en) | 2009-05-15 | 2011-05-19 | Ayman Hammad | Verification of portable consumer devices for 3-d secure services |
US8602293B2 (en) | 2009-05-15 | 2013-12-10 | Visa International Service Association | Integration of verification tokens with portable computing devices |
US9038886B2 (en) | 2009-05-15 | 2015-05-26 | Visa International Service Association | Verification of portable consumer devices |
US9105027B2 (en) | 2009-05-15 | 2015-08-11 | Visa International Service Association | Verification of portable consumer device for secure services |
US8893967B2 (en) | 2009-05-15 | 2014-11-25 | Visa International Service Association | Secure Communication of payment information to merchants using a verification token |
US8534564B2 (en) | 2009-05-15 | 2013-09-17 | Ayman Hammad | Integration of verification tokens with mobile communication devices |
US7891560B2 (en) | 2009-05-15 | 2011-02-22 | Visa International Service Assocation | Verification of portable consumer devices |
US10140598B2 (en) | 2009-05-20 | 2018-11-27 | Visa International Service Association | Device including encrypted data for expiration date and verification value creation |
US20100306076A1 (en) | 2009-05-29 | 2010-12-02 | Ebay Inc. | Trusted Integrity Manager (TIM) |
TWI402775B (en) | 2009-07-16 | 2013-07-21 | Mxtran Inc | Financial transaction system, automated teller machine (atm), and method for operating an atm |
CA2770893A1 (en) | 2009-08-10 | 2011-02-17 | Visa International Service Association | Systems and methods for enrolling users in a payment service |
US20110047076A1 (en) | 2009-08-24 | 2011-02-24 | Mark Carlson | Alias reputation interaction system |
CA2773543A1 (en) | 2009-09-10 | 2011-03-17 | Visa International Service Association | Secure communication of payment information to merchants using a verification token |
US20110083018A1 (en) | 2009-10-06 | 2011-04-07 | Validity Sensors, Inc. | Secure User Authentication |
US8447699B2 (en) | 2009-10-13 | 2013-05-21 | Qualcomm Incorporated | Global secure service provider directory |
WO2011047038A2 (en) | 2009-10-13 | 2011-04-21 | Square, Inc. | Systems and methods for card present transaction without sharing card information |
BR112012008846A2 (en) | 2009-10-16 | 2019-09-24 | Visa Int Service Ass | induction fraud method and system |
US20110238579A1 (en) | 2009-10-23 | 2011-09-29 | Apriva, Llc | System and device for facilitating a secure transaction with a validated token |
US20110246317A1 (en) | 2009-10-23 | 2011-10-06 | Apriva, Llc | System and device for facilitating a transaction through use of a proxy account code |
US8296568B2 (en) | 2009-10-27 | 2012-10-23 | Google Inc. | Systems and methods for authenticating an electronic transaction |
US8739262B2 (en) | 2009-12-18 | 2014-05-27 | Sabre Glbl Inc. | Tokenized data security |
US10255591B2 (en) | 2009-12-18 | 2019-04-09 | Visa International Service Association | Payment channel returning limited use proxy dynamic value |
US9324066B2 (en) | 2009-12-21 | 2016-04-26 | Verizon Patent And Licensing Inc. | Method and system for providing virtual credit card services |
US8788429B2 (en) | 2009-12-30 | 2014-07-22 | First Data Corporation | Secure transaction management |
US8346666B2 (en) | 2010-01-19 | 2013-01-01 | Visa Intellectual Service Association | Token based transaction authentication |
RU2698767C2 (en) | 2010-01-19 | 2019-08-29 | Виза Интернэшнл Сервис Ассосиэйшн | Remote variable authentication processing |
US8615468B2 (en) | 2010-01-27 | 2013-12-24 | Ca, Inc. | System and method for generating a dynamic card value |
US9501773B2 (en) | 2010-02-02 | 2016-11-22 | Xia Dai | Secured transaction system |
US10255601B2 (en) | 2010-02-25 | 2019-04-09 | Visa International Service Association | Multifactor authentication using a directory server |
US8510816B2 (en) | 2010-02-25 | 2013-08-13 | Secureauth Corporation | Security device provisioning |
US8458487B1 (en) | 2010-03-03 | 2013-06-04 | Liaison Technologies, Inc. | System and methods for format preserving tokenization of sensitive information |
US9245267B2 (en) | 2010-03-03 | 2016-01-26 | Visa International Service Association | Portable account number for consumer payment account |
EP2545508A4 (en) | 2010-03-07 | 2014-01-29 | Gilbarco Inc | Fuel dispenser payment system and method |
US8887308B2 (en) | 2010-03-21 | 2014-11-11 | William Grecia | Digital cloud access (PDMAS part III) |
US8533860B1 (en) | 2010-03-21 | 2013-09-10 | William Grecia | Personalized digital media access system—PDMAS part II |
US8402555B2 (en) | 2010-03-21 | 2013-03-19 | William Grecia | Personalized digital media access system (PDMAS) |
US20110238573A1 (en) | 2010-03-25 | 2011-09-29 | Computer Associates Think, Inc. | Cardless atm transaction method and system |
US9298964B2 (en) | 2010-03-31 | 2016-03-29 | Hand Held Products, Inc. | Imaging terminal, imaging sensor to determine document orientation based on bar code orientation and methods for operating the same |
US8380177B2 (en) | 2010-04-09 | 2013-02-19 | Paydiant, Inc. | Mobile phone payment processing methods and systems |
US8336088B2 (en) | 2010-04-19 | 2012-12-18 | Visa International Service Association | Alias management and value transfer claim processing |
US20110276418A1 (en) | 2010-05-07 | 2011-11-10 | S1 Corporation | Apparatus, System and Method For Purchaser to Business Payments |
CN102939613A (en) | 2010-06-04 | 2013-02-20 | 维萨国际服务协会 | Payment tokenization apparatuses, methods and systems |
US8590779B2 (en) | 2010-06-29 | 2013-11-26 | Visa International Service Association | Value token conversion |
US8442914B2 (en) | 2010-07-06 | 2013-05-14 | Mastercard International Incorporated | Virtual wallet account with automatic-loading |
US8571939B2 (en) | 2010-07-07 | 2013-10-29 | Toshiba Global Commerce Solutions Holdings Corporation | Two phase payment link and authorization for mobile devices |
US8453226B2 (en) | 2010-07-16 | 2013-05-28 | Visa International Service Association | Token validation for advanced authorization |
US8635157B2 (en) | 2010-07-19 | 2014-01-21 | Payme, Inc. | Mobile system and method for payments and non-financial transactions |
US20120028609A1 (en) | 2010-07-27 | 2012-02-02 | John Hruska | Secure financial transaction system using a registered mobile device |
US9342832B2 (en) | 2010-08-12 | 2016-05-17 | Visa International Service Association | Securing external systems with account token substitution |
CN101938520B (en) | 2010-09-07 | 2015-01-28 | 中兴通讯股份有限公司 | Mobile terminal signature-based remote payment system and method |
US20120066078A1 (en) | 2010-09-10 | 2012-03-15 | Bank Of America Corporation | Overage service using overage passcode |
US8898086B2 (en) | 2010-09-27 | 2014-11-25 | Fidelity National Information Services | Systems and methods for transmitting financial account information |
US20120095852A1 (en) | 2010-10-15 | 2012-04-19 | John Bauer | Method and system for electronic wallet access |
US9558481B2 (en) | 2010-09-28 | 2017-01-31 | Barclays Bank Plc | Secure account provisioning |
US20120095865A1 (en) | 2010-10-15 | 2012-04-19 | Ezpayy, Inc. | System And Method For Mobile Electronic Purchasing |
US10176477B2 (en) | 2010-11-16 | 2019-01-08 | Mastercard International Incorporated | Methods and systems for universal payment account translation |
US8577336B2 (en) | 2010-11-18 | 2013-11-05 | Mobilesphere Holdings LLC | System and method for transaction authentication using a mobile communication device |
WO2012073014A1 (en) | 2010-11-29 | 2012-06-07 | Mobay Technologies Limited | A system for verifying electronic transactions |
US9141945B2 (en) | 2010-12-02 | 2015-09-22 | Appmobi Iplc, Inc. | Secure distributed single action payment system |
US8762284B2 (en) | 2010-12-16 | 2014-06-24 | Democracyontheweb, Llc | Systems and methods for facilitating secure transactions |
US8807440B1 (en) | 2010-12-17 | 2014-08-19 | Google Inc. | Routing secure element payment requests to an alternate application |
EP2656281A4 (en) | 2010-12-20 | 2015-01-14 | Antonio Claudiu Eram | System and method for mobile payments enablement and order fulfillment |
US20120173431A1 (en) | 2010-12-30 | 2012-07-05 | First Data Corporation | Systems and methods for using a token as a payment in a transaction |
US20120185386A1 (en) | 2011-01-18 | 2012-07-19 | Bank Of America | Authentication tool |
WO2012098555A1 (en) | 2011-01-20 | 2012-07-26 | Google Inc. | Direct carrier billing |
US8725644B2 (en) | 2011-01-28 | 2014-05-13 | The Active Network, Inc. | Secure online transaction processing |
US20120203666A1 (en) | 2011-02-09 | 2012-08-09 | Tycoon Unlimited, Inc. | Contactless wireless transaction processing system |
US20120203664A1 (en) | 2011-02-09 | 2012-08-09 | Tycoon Unlimited, Inc. | Contactless wireless transaction processing system |
WO2012116221A1 (en) | 2011-02-23 | 2012-08-30 | Mastercard International, Inc. | Demand deposit account payment system |
WO2012118870A1 (en) | 2011-02-28 | 2012-09-07 | Visa International Service Association | Secure anonymous transaction apparatuses, methods and systems |
AU2012225684B2 (en) | 2011-03-04 | 2016-11-10 | Visa International Service Association | Integration of payment capability into secure elements of computers |
US20120231844A1 (en) | 2011-03-11 | 2012-09-13 | Apriva, Llc | System and device for facilitating a transaction by consolidating sim, personal token, and associated applications for electronic wallet transactions |
US20120233004A1 (en) | 2011-03-11 | 2012-09-13 | James Bercaw | System for mobile electronic commerce |
US20120246071A1 (en) | 2011-03-21 | 2012-09-27 | Nikhil Jain | System and method for presentment of nonconfidential transaction token identifier |
AU2012201745B2 (en) | 2011-03-24 | 2014-11-13 | Visa International Service Association | Authentication using application authentication element |
US9280765B2 (en) | 2011-04-11 | 2016-03-08 | Visa International Service Association | Multiple tokenization for authentication |
EP2697756A4 (en) | 2011-04-15 | 2014-09-10 | Shift4 Corp | Method and system for enabling merchants to share tokens |
US8688589B2 (en) | 2011-04-15 | 2014-04-01 | Shift4 Corporation | Method and system for utilizing authorization factor pools |
US9818111B2 (en) | 2011-04-15 | 2017-11-14 | Shift4 Corporation | Merchant-based token sharing |
US9256874B2 (en) | 2011-04-15 | 2016-02-09 | Shift4 Corporation | Method and system for enabling merchants to share tokens |
US20120271770A1 (en) | 2011-04-20 | 2012-10-25 | Visa International Service Association | Managing electronic tokens in a transaction processing system |
US20130110658A1 (en) | 2011-05-05 | 2013-05-02 | Transaction Network Services, Inc. | Systems and methods for enabling mobile payments |
US20130204793A1 (en) | 2011-05-17 | 2013-08-08 | Kevin S. Kerridge | Smart communication device secured electronic payment system |
US20120303310A1 (en) | 2011-05-26 | 2012-11-29 | First Data Corporation | Systems and Methods for Providing Test Keys to Mobile Devices |
US8943574B2 (en) | 2011-05-27 | 2015-01-27 | Vantiv, Llc | Tokenizing sensitive data |
US10395256B2 (en) | 2011-06-02 | 2019-08-27 | Visa International Service Association | Reputation management in a transaction processing system |
US8538845B2 (en) | 2011-06-03 | 2013-09-17 | Mozido, Llc | Monetary transaction system |
EP2715633A4 (en) | 2011-06-03 | 2014-12-17 | Visa Int Service Ass | Virtual wallet card selection apparatuses, methods and systems |
US10318932B2 (en) | 2011-06-07 | 2019-06-11 | Entit Software Llc | Payment card processing system with structure preserving encryption |
RU2602394C2 (en) | 2011-06-07 | 2016-11-20 | Виза Интернешнл Сервис Ассосиэйшн | Payment privacy tokenisation apparatus, methods and systems |
WO2012167941A1 (en) | 2011-06-09 | 2012-12-13 | Gemalto Sa | Method to validate a transaction between a user and a service provider |
US9355393B2 (en) | 2011-08-18 | 2016-05-31 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US9639828B2 (en) | 2011-07-15 | 2017-05-02 | Visa International Service Association | Method and system for hosted order page/silent order post plus fraud detection |
WO2013019567A2 (en) | 2011-07-29 | 2013-02-07 | Visa International Service Association | Passing payment tokens through an hop/sop |
US20130054412A1 (en) | 2011-08-22 | 2013-02-28 | American Express Travel Related Services Company, Inc. | Methods and systems for contactless payments for online ecommerce checkout |
US20130226799A1 (en) | 2011-08-23 | 2013-08-29 | Thanigaivel Ashwin Raj | Authentication process for value transfer machine |
AP2014007523A0 (en) | 2011-08-23 | 2014-03-31 | Visa Int Service Ass | Mobile funding method and system |
CN110111087B (en) | 2011-08-30 | 2024-01-02 | 欧威环公司 | System and method for authorizing transactions utilizing unpredictable passwords |
US20130339253A1 (en) | 2011-08-31 | 2013-12-19 | Dan Moshe Sincai | Mobile Device Based Financial Transaction System |
US8171525B1 (en) | 2011-09-15 | 2012-05-01 | Google Inc. | Enabling users to select between secure service providers using a central trusted service manager |
US8838982B2 (en) | 2011-09-21 | 2014-09-16 | Visa International Service Association | Systems and methods to secure user identification |
US8453223B2 (en) | 2011-09-23 | 2013-05-28 | Jerome Svigals | Method, device and system for secure transactions |
CN103890793A (en) | 2011-10-01 | 2014-06-25 | 英特尔公司 | Cloud based credit card emulation |
IN2014KN00998A (en) | 2011-10-12 | 2015-09-04 | C Sam Inc | |
US9229964B2 (en) | 2011-10-27 | 2016-01-05 | Visa International Business Machines Corporation | Database cloning and migration for quality assurance |
US9830596B2 (en) | 2011-11-01 | 2017-11-28 | Stripe, Inc. | Method for conducting a transaction between a merchant site and a customer's electronic device without exposing payment information to a server-side application of the merchant site |
KR101903061B1 (en) | 2011-11-01 | 2018-10-01 | 구글 엘엘씨 | Systems, methods, and computer program products for interfacing multiple service provider trusted service managers and secure elements |
US20160140566A1 (en) | 2011-11-13 | 2016-05-19 | Google Inc. | Secure transmission of payment credentials |
US20130124364A1 (en) | 2011-11-13 | 2013-05-16 | Millind Mittal | System and method of electronic payment using payee provided transaction identification codes |
WO2013086048A1 (en) | 2011-12-05 | 2013-06-13 | Visa International Service Association | Dynamic network analytic system |
US8656180B2 (en) | 2011-12-06 | 2014-02-18 | Wwpass Corporation | Token activation |
US8555079B2 (en) | 2011-12-06 | 2013-10-08 | Wwpass Corporation | Token management |
US8972719B2 (en) | 2011-12-06 | 2015-03-03 | Wwpass Corporation | Passcode restoration |
US20130159178A1 (en) | 2011-12-14 | 2013-06-20 | Firethorn Mobile, Inc. | System and Method For Loading A Virtual Token Managed By A Mobile Wallet System |
US20130159184A1 (en) | 2011-12-15 | 2013-06-20 | Visa International Service Association | System and method of using load network to associate product or service with a consumer token |
US20140040139A1 (en) | 2011-12-19 | 2014-02-06 | Sequent Software, Inc. | System and method for dynamic temporary payment authorization in a portable communication device |
EP2795549A4 (en) | 2011-12-21 | 2015-09-23 | Mastercard International Inc | Methods and systems for providing a payment account with adaptive interchange |
US9077769B2 (en) | 2011-12-29 | 2015-07-07 | Blackberry Limited | Communications system providing enhanced trusted service manager (TSM) verification features and related methods |
US20130254117A1 (en) | 2011-12-30 | 2013-09-26 | Clay W. von Mueller | Secured transaction system and method |
US8566168B1 (en) | 2012-01-05 | 2013-10-22 | Sprint Communications Company L.P. | Electronic payment using a proxy account number stored in a secure element |
SG11201403861XA (en) | 2012-01-05 | 2014-08-28 | Visa Int Service Ass | Data protection with translation |
US9830595B2 (en) | 2012-01-26 | 2017-11-28 | Visa International Service Association | System and method of providing tokenization as a service |
US10643191B2 (en) | 2012-01-27 | 2020-05-05 | Visa International Service Association | Mobile services remote deposit capture |
US8595850B2 (en) | 2012-01-30 | 2013-11-26 | Voltage Security, Inc. | System for protecting sensitive data with distributed tokenization |
EP2624190A1 (en) | 2012-02-03 | 2013-08-07 | Pieter Dubois | Authentication of payment transactions using an alias |
US9218624B2 (en) | 2012-02-03 | 2015-12-22 | Paypal, Inc. | Adding card to mobile/cloud wallet using NFC |
US20130212024A1 (en) | 2012-02-10 | 2013-08-15 | Protegrity Corporation | Tokenization in distributed payment environments |
US20130212017A1 (en) | 2012-02-14 | 2013-08-15 | N.B. Development Services Inc. | Transaction system and method of conducting a transaction |
US20130226813A1 (en) | 2012-02-23 | 2013-08-29 | Robert Matthew Voltz | Cyberspace Identification Trust Authority (CITA) System and Method |
US10282724B2 (en) | 2012-03-06 | 2019-05-07 | Visa International Service Association | Security system incorporating mobile device |
WO2013138528A1 (en) | 2012-03-14 | 2013-09-19 | Visa International Service Association | Point-of-transaction account feature redirection apparatuses, methods and systems |
US9105021B2 (en) | 2012-03-15 | 2015-08-11 | Ebay, Inc. | Systems, methods, and computer program products for using proxy accounts |
US9092776B2 (en) | 2012-03-15 | 2015-07-28 | Qualcomm Incorporated | System and method for managing payment in transactions with a PCD |
US20130246259A1 (en) | 2012-03-15 | 2013-09-19 | Firethorn Mobile, Inc. | System and method for managing payment in transactions with a pcd |
US20130246267A1 (en) | 2012-03-15 | 2013-09-19 | Ebay Inc. | Systems, Methods, and Computer Program Products for Using Proxy Accounts |
US20130254102A1 (en) | 2012-03-20 | 2013-09-26 | First Data Corporation | Systems and Methods for Distributing Tokenization and De-Tokenization Services |
US9818098B2 (en) | 2012-03-20 | 2017-11-14 | First Data Corporation | Systems and methods for facilitating payments via a peer-to-peer protocol |
US20130254028A1 (en) | 2012-03-22 | 2013-09-26 | Corbuss Kurumsal Telekom Hizmetleri A.S. | System and method for conducting mobile commerce |
US20130262315A1 (en) | 2012-03-30 | 2013-10-03 | John Hruska | System for Secure Purchases Made by Scanning Barcode Using a Registered Mobile Phone Application Linked to a Consumer-Merchant Closed Loop Financial Proxy Account System |
US10515359B2 (en) | 2012-04-02 | 2019-12-24 | Mastercard International Incorporated | Systems and methods for processing mobile payments by provisioning credentials to mobile devices without secure elements |
US20130262302A1 (en) | 2012-04-02 | 2013-10-03 | Jvl Ventures, Llc | Systems, methods, and computer program products for provisioning payment accounts into mobile wallets and managing events |
PL2836971T3 (en) | 2012-04-13 | 2018-05-30 | Mastercard International Inc | Systems, methods, and computer readable media for conducting a transaction using cloud based credentials |
KR101671457B1 (en) | 2012-04-18 | 2016-11-01 | 구글 인코포레이티드 | Processing payment transactions without a secure element |
US20130282588A1 (en) | 2012-04-22 | 2013-10-24 | John Hruska | Consumer, Merchant and Mobile Device Specific, Real-Time Dynamic Tokenization Activation within a Secure Mobile-Wallet Financial Transaction System |
US10275764B2 (en) | 2012-05-04 | 2019-04-30 | Mastercard International Incorporated | Transaction data tokenization |
US20130297501A1 (en) | 2012-05-04 | 2013-11-07 | Justin Monk | System and method for local data conversion |
US9521548B2 (en) | 2012-05-21 | 2016-12-13 | Nexiden, Inc. | Secure registration of a mobile device for use with a session |
US20130311382A1 (en) | 2012-05-21 | 2013-11-21 | Klaus S. Fosmark | Obtaining information for a payment transaction |
WO2013179271A2 (en) | 2012-06-01 | 2013-12-05 | Mani Venkatachalam Sthanu Subra | Method and system for human assisted secure payment by phone to an insecure third-party service provider |
US9524501B2 (en) | 2012-06-06 | 2016-12-20 | Visa International Service Association | Method and system for correlating diverse transaction data |
US20140007213A1 (en) | 2012-06-29 | 2014-01-02 | Wepay, Inc. | Systems and methods for push notification based application authentication and authorization |
US9059972B2 (en) | 2012-07-03 | 2015-06-16 | International Business Machines Corporation | Issuing, presenting and challenging mobile device identification documents |
US9547769B2 (en) | 2012-07-03 | 2017-01-17 | Visa International Service Association | Data protection hub |
US9043609B2 (en) | 2012-07-19 | 2015-05-26 | Bank Of America Corporation | Implementing security measures for authorized tokens used in mobile transactions |
US20140025585A1 (en) | 2012-07-19 | 2014-01-23 | Bank Of America Corporation | Distributing authorized tokens to conduct mobile transactions |
US20140025581A1 (en) | 2012-07-19 | 2014-01-23 | Bank Of America Corporation | Mobile transactions using authorized tokens |
US9846861B2 (en) | 2012-07-25 | 2017-12-19 | Visa International Service Association | Upstream and downstream data conversion |
US9256871B2 (en) | 2012-07-26 | 2016-02-09 | Visa U.S.A. Inc. | Configurable payment tokens |
US10339524B2 (en) | 2012-07-31 | 2019-07-02 | Worldpay, Llc | Systems and methods for multi-merchant tokenization |
US10346838B2 (en) | 2012-07-31 | 2019-07-09 | Worldpay, Llc | Systems and methods for distributed enhanced payment processing |
US10152711B2 (en) | 2012-07-31 | 2018-12-11 | Worldpay, Llc | Systems and methods for arbitraged enhanced payment processing |
WO2014022778A1 (en) | 2012-08-03 | 2014-02-06 | Vasco Data Security, Inc. | User-convenient authentication method and apparatus using a mobile authentication application |
US9665722B2 (en) | 2012-08-10 | 2017-05-30 | Visa International Service Association | Privacy firewall |
US20140052620A1 (en) | 2012-08-17 | 2014-02-20 | Google Inc. | Wireless reader and payment transaction terminal functionality within a portable device |
US20140068706A1 (en) | 2012-08-28 | 2014-03-06 | Selim Aissi | Protecting Assets on a Device |
US10192216B2 (en) | 2012-09-11 | 2019-01-29 | Visa International Service Association | Cloud-based virtual wallet NFC apparatuses, methods and systems |
US9390412B2 (en) | 2012-10-16 | 2016-07-12 | Visa International Service Association | Dynamic point of sale system integrated with reader device |
US10176478B2 (en) | 2012-10-23 | 2019-01-08 | Visa International Service Association | Transaction initiation determination system utilizing transaction data elements |
US9911118B2 (en) | 2012-11-21 | 2018-03-06 | Visa International Service Association | Device pairing via trusted intermediary |
US20140164243A1 (en) | 2012-12-07 | 2014-06-12 | Christian Aabye | Dynamic Account Identifier With Return Real Account Identifier |
US9741051B2 (en) | 2013-01-02 | 2017-08-22 | Visa International Service Association | Tokenization and third-party interaction |
US9249241B2 (en) | 2013-03-27 | 2016-02-02 | Ut-Battelle, Llc | Surface-functionalized mesoporous carbon materials |
US20140310183A1 (en) | 2013-04-15 | 2014-10-16 | Lance Weber | Embedded acceptance system |
US20140331265A1 (en) | 2013-05-01 | 2014-11-06 | Microsoft Corporation | Integrated interactive television entertainment system |
US20140330722A1 (en) | 2013-05-02 | 2014-11-06 | Prasanna Laxminarayanan | System and method for using an account sequence identifier |
US11055710B2 (en) | 2013-05-02 | 2021-07-06 | Visa International Service Association | Systems and methods for verifying and processing transactions using virtual currency |
US9760886B2 (en) | 2013-05-10 | 2017-09-12 | Visa International Service Association | Device provisioning using partial personalization scripts |
CN105359179B (en) | 2013-05-15 | 2019-12-10 | 维萨国际服务协会 | Mobile tokenization hub |
US10878422B2 (en) | 2013-06-17 | 2020-12-29 | Visa International Service Association | System and method using merchant token |
AU2014290143C1 (en) | 2013-07-15 | 2019-01-03 | Visa International Service Association | Secure remote payment transaction processing |
SG10201800629WA (en) | 2013-07-24 | 2018-02-27 | Visa Int Service Ass | Systems and methods for communicating risk using token assurance data |
US10496986B2 (en) | 2013-08-08 | 2019-12-03 | Visa International Service Association | Multi-network tokenization processing |
CA2920661C (en) | 2013-08-08 | 2019-05-21 | Visa International Service Association | Methods and systems for provisioning mobile devices with payment credentials |
KR102552606B1 (en) | 2013-08-15 | 2023-07-06 | 비자 인터네셔널 서비스 어소시에이션 | Secure remote payment transaction processing using a secure element |
CN115358746A (en) | 2013-09-20 | 2022-11-18 | 维萨国际服务协会 | Secure remote payment transaction processing including consumer authentication |
US9978094B2 (en) | 2013-10-11 | 2018-05-22 | Visa International Service Association | Tokenization revocation list |
EP3937108A1 (en) | 2013-10-11 | 2022-01-12 | Visa International Service Association | Network token system |
US10515358B2 (en) | 2013-10-18 | 2019-12-24 | Visa International Service Association | Contextual transaction token methods and systems |
US10489779B2 (en) | 2013-10-21 | 2019-11-26 | Visa International Service Association | Multi-network token bin routing with defined verification parameters |
US10366387B2 (en) | 2013-10-29 | 2019-07-30 | Visa International Service Association | Digital wallet system and method |
US20150127529A1 (en) | 2013-11-05 | 2015-05-07 | Oleg Makhotin | Methods and systems for mobile payment application selection and management using an application linker |
US20150142673A1 (en) | 2013-11-18 | 2015-05-21 | Mark Nelsen | Methods and systems for token request management |
US9516487B2 (en) | 2013-11-19 | 2016-12-06 | Visa International Service Association | Automated account provisioning |
US20150161597A1 (en) | 2013-12-09 | 2015-06-11 | Kaushik Subramanian | Transactions using temporary credential data |
US9922322B2 (en) | 2013-12-19 | 2018-03-20 | Visa International Service Association | Cloud-based transactions with magnetic secure transmission |
SG11201604906QA (en) | 2013-12-19 | 2016-07-28 | Visa Int Service Ass | Cloud-based transactions methods and systems |
US10445718B2 (en) | 2013-12-27 | 2019-10-15 | Visa International Service Association | Processing a transaction using multiple application identifiers |
US10108409B2 (en) | 2014-01-03 | 2018-10-23 | Visa International Service Association | Systems and methods for updatable applets |
US10433128B2 (en) | 2014-01-07 | 2019-10-01 | Visa International Service Association | Methods and systems for provisioning multiple devices |
US20150199679A1 (en) | 2014-01-13 | 2015-07-16 | Karthikeyan Palanisamy | Multiple token provisioning |
US9846878B2 (en) | 2014-01-14 | 2017-12-19 | Visa International Service Association | Payment account identifier system |
BR112016017947A2 (en) | 2014-02-04 | 2017-08-08 | Visa Int Service Ass | METHOD IMPLEMENTED BY COMPUTER, ACCESS DEVICE, AND SYSTEM |
AU2015231418A1 (en) | 2014-03-18 | 2016-09-29 | Visa International Service Association | Systems and methods for locally derived tokens |
US9942043B2 (en) | 2014-04-23 | 2018-04-10 | Visa International Service Association | Token security on a communication device |
US9848052B2 (en) | 2014-05-05 | 2017-12-19 | Visa International Service Association | System and method for token domain control |
US10592899B2 (en) | 2014-05-13 | 2020-03-17 | Visa International Service Association | Master applet for secure remote payment processing |
US11023890B2 (en) | 2014-06-05 | 2021-06-01 | Visa International Service Association | Identification and verification for provisioning mobile application |
US9780953B2 (en) | 2014-07-23 | 2017-10-03 | Visa International Service Association | Systems and methods for secure detokenization |
US9779345B2 (en) | 2014-08-11 | 2017-10-03 | Visa International Service Association | Mobile device with scannable image including dynamic data |
RU2710897C2 (en) | 2014-08-29 | 2020-01-14 | Виза Интернэшнл Сервис Ассосиэйшн | Methods for safe generation of cryptograms |
CA2960319A1 (en) | 2014-09-26 | 2016-03-31 | Visa International Service Association | Remote server encrypted data provisioning system and methods |
US11257074B2 (en) | 2014-09-29 | 2022-02-22 | Visa International Service Association | Transaction risk based token |
EP3204851B1 (en) | 2014-10-10 | 2020-07-22 | Visa International Service Association | Methods and systems for partial personalization during mobile application update |
US10015147B2 (en) | 2014-10-22 | 2018-07-03 | Visa International Service Association | Token enrollment system and method |
US10325261B2 (en) | 2014-11-25 | 2019-06-18 | Visa International Service Association | Systems communications with non-sensitive identifiers |
CN113537988B (en) | 2014-11-26 | 2024-05-28 | 维萨国际服务协会 | Method and apparatus for tokenizing requests via an access device |
RU2707939C2 (en) | 2014-12-12 | 2019-12-02 | Виза Интернэшнл Сервис Ассосиэйшн | Support platform for inter-machine devices |
US10257185B2 (en) | 2014-12-12 | 2019-04-09 | Visa International Service Association | Automated access data provisioning |
US10096009B2 (en) | 2015-01-20 | 2018-10-09 | Visa International Service Association | Secure payment processing using authorization request |
CN107210914B (en) | 2015-01-27 | 2020-11-03 | 维萨国际服务协会 | Method for secure credential provisioning |
US11250391B2 (en) | 2015-01-30 | 2022-02-15 | Visa International Service Association | Token check offline |
US10977657B2 (en) | 2015-02-09 | 2021-04-13 | Visa International Service Association | Token processing utilizing multiple authorizations |
CN107209891A (en) | 2015-02-13 | 2017-09-26 | 维萨国际服务协会 | The equity forwarding of digital request is authorized |
-
2010
- 2010-09-09 US US12/878,947 patent/US8893967B2/en active Active
-
2014
- 2014-10-09 US US14/511,034 patent/US9582801B2/en active Active
-
2016
- 2016-09-07 US US15/258,258 patent/US10049360B2/en active Active
-
2018
- 2018-07-06 US US16/028,941 patent/US20180315050A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5477040A (en) * | 1994-05-23 | 1995-12-19 | Lalonde; Michael G. | Structure for a method of facilitating charge transactions |
US7757953B2 (en) * | 2006-01-13 | 2010-07-20 | Magtek, Inc. | Secure magnetic stripe reader |
Cited By (162)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10997573B2 (en) | 2009-04-28 | 2021-05-04 | Visa International Service Association | Verification of portable consumer devices |
US11574312B2 (en) | 2009-05-15 | 2023-02-07 | Visa International Service Association | Secure authentication system and method |
US10846683B2 (en) | 2009-05-15 | 2020-11-24 | Visa International Service Association | Integration of verification tokens with mobile communication devices |
US11995633B2 (en) | 2012-03-06 | 2024-05-28 | Visa International Service Association | Security system incorporating mobile device |
US10546444B2 (en) | 2018-06-21 | 2020-01-28 | Capital One Services, Llc | Systems and methods for secure read-only authentication |
US10878651B2 (en) | 2018-06-21 | 2020-12-29 | Capital One Services, Llc | Systems and methods for secure read-only authentication |
US11144915B2 (en) | 2018-10-02 | 2021-10-12 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards using risk factors |
US11728994B2 (en) | 2018-10-02 | 2023-08-15 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11182785B2 (en) | 2018-10-02 | 2021-11-23 | Capital One Services, Llc | Systems and methods for authorization and access to services using contactless cards |
US10511443B1 (en) | 2018-10-02 | 2019-12-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US12008558B2 (en) | 2018-10-02 | 2024-06-11 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US12010238B2 (en) | 2018-10-02 | 2024-06-11 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US12003490B2 (en) | 2018-10-02 | 2024-06-04 | Capital One Services, Llc | Systems and methods for card information management |
US10542036B1 (en) | 2018-10-02 | 2020-01-21 | Capital One Services, Llc | Systems and methods for signaling an attack on contactless cards |
US11997208B2 (en) | 2018-10-02 | 2024-05-28 | Capital One Services, Llc | Systems and methods for inventory management using cryptographic authentication of contactless cards |
US11989724B2 (en) | 2018-10-02 | 2024-05-21 | Capital One Services Llc | Systems and methods for cryptographic authentication of contactless cards using risk factors |
US10554411B1 (en) | 2018-10-02 | 2020-02-04 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10565587B1 (en) | 2018-10-02 | 2020-02-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10579998B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10582386B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10581611B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10592710B1 (en) | 2018-10-02 | 2020-03-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10607216B1 (en) | 2018-10-02 | 2020-03-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10607214B1 (en) | 2018-10-02 | 2020-03-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10615981B1 (en) | 2018-10-02 | 2020-04-07 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10623393B1 (en) | 2018-10-02 | 2020-04-14 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10630653B1 (en) | 2018-10-02 | 2020-04-21 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11974127B2 (en) | 2018-10-02 | 2024-04-30 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11924188B2 (en) | 2018-10-02 | 2024-03-05 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11843698B2 (en) | 2018-10-02 | 2023-12-12 | Capital One Services, Llc | Systems and methods of key selection for cryptographic authentication of contactless cards |
US10680824B2 (en) | 2018-10-02 | 2020-06-09 | Capital One Services, Llc | Systems and methods for inventory management using cryptographic authentication of contactless cards |
US10685350B2 (en) | 2018-10-02 | 2020-06-16 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10686603B2 (en) | 2018-10-02 | 2020-06-16 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11210664B2 (en) | 2018-10-02 | 2021-12-28 | Capital One Services, Llc | Systems and methods for amplifying the strength of cryptographic algorithms |
US11843700B2 (en) | 2018-10-02 | 2023-12-12 | Capital One Services, Llc | Systems and methods for email-based card activation |
US11804964B2 (en) | 2018-10-02 | 2023-10-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11790187B2 (en) | 2018-10-02 | 2023-10-17 | Capital One Services, Llc | Systems and methods for data transmission using contactless cards |
US11784820B2 (en) | 2018-10-02 | 2023-10-10 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10733645B2 (en) | 2018-10-02 | 2020-08-04 | Capital One Services, Llc | Systems and methods for establishing identity for order pick up |
US10748138B2 (en) | 2018-10-02 | 2020-08-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11770254B2 (en) | 2018-10-02 | 2023-09-26 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10771253B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10771254B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for email-based card activation |
US10778437B2 (en) | 2018-10-02 | 2020-09-15 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11182784B2 (en) | 2018-10-02 | 2021-11-23 | Capital One Services, Llc | Systems and methods for performing transactions with contactless cards |
US11195174B2 (en) | 2018-10-02 | 2021-12-07 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10797882B2 (en) | 2018-10-02 | 2020-10-06 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10505738B1 (en) | 2018-10-02 | 2019-12-10 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10841091B2 (en) | 2018-10-02 | 2020-11-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11699047B2 (en) | 2018-10-02 | 2023-07-11 | Capital One Services, Llc | Systems and methods for contactless card applet communication |
US11658997B2 (en) | 2018-10-02 | 2023-05-23 | Capital One Services, Llc | Systems and methods for signaling an attack on contactless cards |
US11610195B2 (en) | 2018-10-02 | 2023-03-21 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11563583B2 (en) | 2018-10-02 | 2023-01-24 | Capital One Services, Llc | Systems and methods for content management using contactless cards |
US10860814B2 (en) | 2018-10-02 | 2020-12-08 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11544707B2 (en) | 2018-10-02 | 2023-01-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11502844B2 (en) | 2018-10-02 | 2022-11-15 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10880327B2 (en) | 2018-10-02 | 2020-12-29 | Capital One Services, Llc | Systems and methods for signaling an attack on contactless cards |
US10489781B1 (en) | 2018-10-02 | 2019-11-26 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11469898B2 (en) | 2018-10-02 | 2022-10-11 | Capital One Services, Llc | Systems and methods for message presentation using contactless cards |
US10887106B2 (en) | 2018-10-02 | 2021-01-05 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11456873B2 (en) | 2018-10-02 | 2022-09-27 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10909527B2 (en) | 2018-10-02 | 2021-02-02 | Capital One Services, Llc | Systems and methods for performing a reissue of a contactless card |
US11444775B2 (en) | 2018-10-02 | 2022-09-13 | Capital One Services, Llc | Systems and methods for content management using contactless cards |
US11438311B2 (en) | 2018-10-02 | 2022-09-06 | Capital One Services, Llc | Systems and methods for card information management |
US10949520B2 (en) | 2018-10-02 | 2021-03-16 | Capital One Services, Llc | Systems and methods for cross coupling risk analytics and one-time-passcodes |
US11438164B2 (en) | 2018-10-02 | 2022-09-06 | Capital One Services, Llc | Systems and methods for email-based card activation |
US10965465B2 (en) | 2018-10-02 | 2021-03-30 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11423452B2 (en) | 2018-10-02 | 2022-08-23 | Capital One Services, Llc | Systems and methods for establishing identity for order pick up |
US10783519B2 (en) | 2018-10-02 | 2020-09-22 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10992477B2 (en) | 2018-10-02 | 2021-04-27 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11349667B2 (en) | 2018-10-02 | 2022-05-31 | Capital One Services, Llc | Systems and methods for inventory management using cryptographic authentication of contactless cards |
US11341480B2 (en) | 2018-10-02 | 2022-05-24 | Capital One Services, Llc | Systems and methods for phone-based card activation |
US11336454B2 (en) | 2018-10-02 | 2022-05-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11233645B2 (en) | 2018-10-02 | 2022-01-25 | Capital One Services, Llc | Systems and methods of key selection for cryptographic authentication of contactless cards |
US11321546B2 (en) | 2018-10-02 | 2022-05-03 | Capital One Services, Llc | Systems and methods data transmission using contactless cards |
US11232272B2 (en) | 2018-10-02 | 2022-01-25 | Capital One Services, Llc | Systems and methods for contactless card applet communication |
US11301848B2 (en) | 2018-10-02 | 2022-04-12 | Capital One Services, Llc | Systems and methods for secure transaction approval |
US11102007B2 (en) | 2018-10-02 | 2021-08-24 | Capital One Services, Llc | Contactless card emulation system and method |
US11297046B2 (en) | 2018-10-02 | 2022-04-05 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11129019B2 (en) | 2018-10-02 | 2021-09-21 | Capital One Services, Llc | Systems and methods for performing transactions with contactless cards |
WO2020122898A1 (en) * | 2018-12-12 | 2020-06-18 | Visa International Service Association | Provisioning initiated from a contactless device |
US11361302B2 (en) | 2019-01-11 | 2022-06-14 | Capital One Services, Llc | Systems and methods for touch screen interface interaction using a card overlay |
US11282066B1 (en) * | 2019-01-18 | 2022-03-22 | Worldpay, Llc | Systems and methods to provide user verification in a shared user environment via a device-specific display |
US20220129882A1 (en) * | 2019-01-18 | 2022-04-28 | Worldpay, Llc | Systems and methods to provide user verification in a shared user environment via a device-specific display |
US11699144B2 (en) * | 2019-01-18 | 2023-07-11 | Worldpay, Llc | Systems and methods to provide user verification in a shared user environment via a device-specific display |
US11037136B2 (en) | 2019-01-24 | 2021-06-15 | Capital One Services, Llc | Tap to autofill card data |
US10510074B1 (en) | 2019-02-01 | 2019-12-17 | Capital One Services, Llc | One-tap payment using a contactless card |
US10467622B1 (en) | 2019-02-01 | 2019-11-05 | Capital One Services, Llc | Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms |
US11120453B2 (en) | 2019-02-01 | 2021-09-14 | Capital One Services, Llc | Tap card to securely generate card data to copy to clipboard |
US10425129B1 (en) | 2019-02-27 | 2019-09-24 | Capital One Services, Llc | Techniques to reduce power consumption in near field communication systems |
US10523708B1 (en) | 2019-03-18 | 2019-12-31 | Capital One Services, Llc | System and method for second factor authentication of customer support calls |
US10438437B1 (en) | 2019-03-20 | 2019-10-08 | Capital One Services, Llc | Tap to copy data to clipboard via NFC |
US10984416B2 (en) | 2019-03-20 | 2021-04-20 | Capital One Services, Llc | NFC mobile currency transfer |
US10535062B1 (en) | 2019-03-20 | 2020-01-14 | Capital One Services, Llc | Using a contactless card to securely share personal data stored in a blockchain |
US10783736B1 (en) | 2019-03-20 | 2020-09-22 | Capital One Services, Llc | Tap to copy data to clipboard via NFC |
US10643420B1 (en) | 2019-03-20 | 2020-05-05 | Capital One Services, Llc | Contextual tapping engine |
US10970712B2 (en) | 2019-03-21 | 2021-04-06 | Capital One Services, Llc | Delegated administration of permissions using a contactless card |
US10467445B1 (en) | 2019-03-28 | 2019-11-05 | Capital One Services, Llc | Devices and methods for contactless card alignment with a foldable mobile device |
US11521262B2 (en) | 2019-05-28 | 2022-12-06 | Capital One Services, Llc | NFC enhanced augmented reality information overlays |
US10516447B1 (en) | 2019-06-17 | 2019-12-24 | Capital One Services, Llc | Dynamic power levels in NFC card communications |
US11694187B2 (en) | 2019-07-03 | 2023-07-04 | Capital One Services, Llc | Constraining transactional capabilities for contactless cards |
US10871958B1 (en) | 2019-07-03 | 2020-12-22 | Capital One Services, Llc | Techniques to perform applet programming |
US11392933B2 (en) | 2019-07-03 | 2022-07-19 | Capital One Services, Llc | Systems and methods for providing online and hybridcard interactions |
US10713649B1 (en) | 2019-07-09 | 2020-07-14 | Capital One Services, Llc | System and method enabling mobile near-field communication to update display on a payment card |
US10498401B1 (en) | 2019-07-15 | 2019-12-03 | Capital One Services, Llc | System and method for guiding card positioning using phone sensors |
US10885514B1 (en) | 2019-07-15 | 2021-01-05 | Capital One Services, Llc | System and method for using image data to trigger contactless card transactions |
US20220101306A1 (en) * | 2019-07-17 | 2022-03-31 | Capital One Services, Llc | System for value loading onto in-vehicle device |
US10733601B1 (en) | 2019-07-17 | 2020-08-04 | Capital One Services, Llc | Body area network facilitated authentication or payment authorization |
US10832271B1 (en) | 2019-07-17 | 2020-11-10 | Capital One Services, Llc | Verified reviews using a contactless card |
US11182771B2 (en) * | 2019-07-17 | 2021-11-23 | Capital One Services, Llc | System for value loading onto in-vehicle device |
US11521213B2 (en) | 2019-07-18 | 2022-12-06 | Capital One Services, Llc | Continuous authentication for digital services based on contactless card positioning |
US10506426B1 (en) | 2019-07-19 | 2019-12-10 | Capital One Services, Llc | Techniques for call authentication |
US10541995B1 (en) | 2019-07-23 | 2020-01-21 | Capital One Services, Llc | First factor contactless card authentication system and method |
US11638148B2 (en) | 2019-10-02 | 2023-04-25 | Capital One Services, Llc | Client device authentication using contactless legacy magnetic stripe data |
US10701560B1 (en) | 2019-10-02 | 2020-06-30 | Capital One Services, Llc | Client device authentication using contactless legacy magnetic stripe data |
US11113685B2 (en) | 2019-12-23 | 2021-09-07 | Capital One Services, Llc | Card issuing with restricted virtual numbers |
US10657754B1 (en) | 2019-12-23 | 2020-05-19 | Capital One Services, Llc | Contactless card and personal identification system |
US10885410B1 (en) | 2019-12-23 | 2021-01-05 | Capital One Services, Llc | Generating barcodes utilizing cryptographic techniques |
US10733283B1 (en) | 2019-12-23 | 2020-08-04 | Capital One Services, Llc | Secure password generation and management using NFC and contactless smart cards |
US11651361B2 (en) | 2019-12-23 | 2023-05-16 | Capital One Services, Llc | Secure authentication based on passport data stored in a contactless card |
US11615395B2 (en) | 2019-12-23 | 2023-03-28 | Capital One Services, Llc | Authentication for third party digital wallet provisioning |
US10862540B1 (en) | 2019-12-23 | 2020-12-08 | Capital One Services, Llc | Method for mapping NFC field strength and location on mobile devices |
US10853795B1 (en) | 2019-12-24 | 2020-12-01 | Capital One Services, Llc | Secure authentication based on identity data stored in a contactless card |
US10664941B1 (en) | 2019-12-24 | 2020-05-26 | Capital One Services, Llc | Steganographic image encoding of biometric template information on a card |
US11200563B2 (en) | 2019-12-24 | 2021-12-14 | Capital One Services, Llc | Account registration using a contactless card |
US10909544B1 (en) | 2019-12-26 | 2021-02-02 | Capital One Services, Llc | Accessing and utilizing multiple loyalty point accounts |
US10757574B1 (en) | 2019-12-26 | 2020-08-25 | Capital One Services, Llc | Multi-factor authentication providing a credential via a contactless card for secure messaging |
US11038688B1 (en) | 2019-12-30 | 2021-06-15 | Capital One Services, Llc | Techniques to control applets for contactless cards |
US10860914B1 (en) | 2019-12-31 | 2020-12-08 | Capital One Services, Llc | Contactless card and method of assembly |
US11455620B2 (en) | 2019-12-31 | 2022-09-27 | Capital One Services, Llc | Tapping a contactless card to a computing device to provision a virtual number |
US11210656B2 (en) | 2020-04-13 | 2021-12-28 | Capital One Services, Llc | Determining specific terms for contactless card activation |
US10861006B1 (en) | 2020-04-30 | 2020-12-08 | Capital One Services, Llc | Systems and methods for data access control using a short-range transceiver |
US11222342B2 (en) | 2020-04-30 | 2022-01-11 | Capital One Services, Llc | Accurate images in graphical user interfaces to enable data transfer |
US11270291B2 (en) | 2020-04-30 | 2022-03-08 | Capital One Services, Llc | Systems and methods for data access control using a short-range transceiver |
US11562346B2 (en) | 2020-04-30 | 2023-01-24 | Capital One Services, Llc | Contactless card with multiple rotating security keys |
US10915888B1 (en) | 2020-04-30 | 2021-02-09 | Capital One Services, Llc | Contactless card with multiple rotating security keys |
US11030339B1 (en) | 2020-04-30 | 2021-06-08 | Capital One Services, Llc | Systems and methods for data access control of personal user data using a short-range transceiver |
US11823175B2 (en) | 2020-04-30 | 2023-11-21 | Capital One Services, Llc | Intelligent card unlock |
US10963865B1 (en) | 2020-05-12 | 2021-03-30 | Capital One Services, Llc | Augmented reality card activation experience |
US11100511B1 (en) | 2020-05-18 | 2021-08-24 | Capital One Services, Llc | Application-based point of sale system in mobile operating systems |
US11063979B1 (en) | 2020-05-18 | 2021-07-13 | Capital One Services, Llc | Enabling communications between applications in a mobile operating system |
US11062098B1 (en) | 2020-08-11 | 2021-07-13 | Capital One Services, Llc | Augmented reality information display and interaction via NFC based authentication |
US11482312B2 (en) | 2020-10-30 | 2022-10-25 | Capital One Services, Llc | Secure verification of medical status using a contactless card |
US11165586B1 (en) | 2020-10-30 | 2021-11-02 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
US11373169B2 (en) | 2020-11-03 | 2022-06-28 | Capital One Services, Llc | Web-based activation of contactless cards |
US11216799B1 (en) | 2021-01-04 | 2022-01-04 | Capital One Services, Llc | Secure generation of one-time passcodes using a contactless card |
US11682012B2 (en) | 2021-01-27 | 2023-06-20 | Capital One Services, Llc | Contactless delivery systems and methods |
US11562358B2 (en) | 2021-01-28 | 2023-01-24 | Capital One Services, Llc | Systems and methods for near field contactless card communication and cryptographic authentication |
US11687930B2 (en) | 2021-01-28 | 2023-06-27 | Capital One Services, Llc | Systems and methods for authentication of access tokens |
US11792001B2 (en) | 2021-01-28 | 2023-10-17 | Capital One Services, Llc | Systems and methods for secure reprovisioning |
US11922417B2 (en) | 2021-01-28 | 2024-03-05 | Capital One Services, Llc | Systems and methods for near field contactless card communication and cryptographic authentication |
US11438329B2 (en) | 2021-01-29 | 2022-09-06 | Capital One Services, Llc | Systems and methods for authenticated peer-to-peer data transfer using resource locators |
US11777933B2 (en) | 2021-02-03 | 2023-10-03 | Capital One Services, Llc | URL-based authentication for payment cards |
US11637826B2 (en) | 2021-02-24 | 2023-04-25 | Capital One Services, Llc | Establishing authentication persistence |
US11245438B1 (en) | 2021-03-26 | 2022-02-08 | Capital One Services, Llc | Network-enabled smart apparatus and systems and methods for activating and provisioning same |
US11848724B2 (en) | 2021-03-26 | 2023-12-19 | Capital One Services, Llc | Network-enabled smart apparatus and systems and methods for activating and provisioning same |
US20220311475A1 (en) | 2021-03-26 | 2022-09-29 | Capital One Services, Llc | Network-enabled smart apparatus and systems and methods for activating and provisioning same |
US11990955B2 (en) | 2021-03-26 | 2024-05-21 | Capital One Services, Llc | Network-enabled smart apparatus and systems and methods for activating and provisioning same |
US11961089B2 (en) | 2021-04-20 | 2024-04-16 | Capital One Services, Llc | On-demand applications to extend web services |
US11935035B2 (en) | 2021-04-20 | 2024-03-19 | Capital One Services, Llc | Techniques to utilize resource locators by a contactless card to perform a sequence of operations |
US11902442B2 (en) | 2021-04-22 | 2024-02-13 | Capital One Services, Llc | Secure management of accounts on display devices using a contactless card |
US11354555B1 (en) | 2021-05-04 | 2022-06-07 | Capital One Services, Llc | Methods, mediums, and systems for applying a display to a transaction card |
Also Published As
Publication number | Publication date |
---|---|
US8893967B2 (en) | 2014-11-25 |
US9582801B2 (en) | 2017-02-28 |
US20100327054A1 (en) | 2010-12-30 |
US20160379217A1 (en) | 2016-12-29 |
US10049360B2 (en) | 2018-08-14 |
US20150134537A1 (en) | 2015-05-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10049360B2 (en) | Secure communication of payment information to merchants using a verification token | |
US11574312B2 (en) | Secure authentication system and method | |
US9904919B2 (en) | Verification of portable consumer devices | |
EP2430602B1 (en) | Verification of portable consumer devices | |
US9372971B2 (en) | Integration of verification tokens with portable computing devices | |
AU2010292125B2 (en) | Secure communication of payment information to merchants using a verification token | |
AU2016203876B2 (en) | Verification of portable consumer devices | |
AU2014201222A1 (en) | Verification of portable consumer devices |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |