People use payment accounts to facilitate transactions. For example, in some cases an account owner may insert a payment card (e.g., a credit card or debit card) into an Automated Teller Machine (“ATM”), enter his or her Personal Identification Number (“PIN”), and receive cash that he or she can then use to purchase items or services. In other cases, an account owner may present his or her payment card at a merchant Point Of Sale (“POS”) device (e.g., at a merchant's cash register) to purchase items and/or services.
Note that using a payment card at an ATM or merchant POS device may be inconvenient for an account owner, such as an account owner who does not want to carry a wallet or purse. Moreover, a person other than the account owner may come into possession of the payment card (or even just a credit card number) and attempt to make a transaction using the owner's account (e.g., when the payment card is lost or stolen). Attempting to verify that a person is actually an account holder, can be an expensive, time-consuming, and error prone task for a merchant or online retailer (e.g., who may ask a person to enter a PIN and/or to present additional identification, such as a state issued driver's license). This can be especially true when a substantial number of people (perhaps associated with many different card issuers) attempt a substantial number of transactions in many different locations.
In some cases, a party may attempt to use biometric information to verify a person's identity. For example, a bank or other party involved in payment transaction might maintain a large database containing user fingerprints. A user might scan his or her fingerprint at an ATM or merchant POS device which would in turn transmit an image of the fingerprint to the bank or other party. The image of the fingerprint could then be verified and the transaction authorized. Note, however, that many people will feel uncomfortable having private information, such as fingerprint images, stored by a bank or similar entity. Moreover, if the fingerprint image information was somehow intercepted by an unauthorized party between the ATM or merchant POS device and the bank, the potential for misuse and fraud is substantial.
It would therefore be desirable to provide accurate and efficient systems and methods to identify an account owner when he or she attempts to make a transaction using a payment account.
In some cases an account owner may insert a payment card (e.g., a credit card or debit card) into an ATM, enter his or her PIN, and receive cash that he or she can then use to purchase items or services. In other cases, an account owner may present his or her payment card at a merchant POS device to purchase items or services. Note that using a payment card at a POS device may be inconvenient for some account owners. It would therefore be desirable to provide accurate and efficient systems and methods to identify an account owner when he or she attempts to make a transaction using a payment account.
The authentication platform 150 might be, for example, associated with a Personal Computer (“PC”), laptop computer, an enterprise server, a server farm, and/or a database or similar storage devices. The authentication platform 150 may, according to some embodiments, be associated with a credit card company.
According to some embodiments, an “automated” authentication platform 150 may identify an account owner when he or she attempts to make a transaction using a payment account. For example, the authentication platform 150 may automatically output a payment authorization indication to the POS device or to any other party (e.g., a credit card issuer). As used herein, the term “automated” may refer to, for example, actions that can be performed with little (or no) intervention by a human.
As used herein, devices, including those associated with the authentication platform 150 and any other device described herein, may exchange information via any communication network which may be one or more of a Local Area Network (“LAN”), a Metropolitan Area Network (“MAN”), a Wide Area Network (“WAN”), a proprietary network, a Public Switched Telephone Network (“PSTN”), a Wireless Application Protocol (“WAP”) network, a Bluetooth network, a wireless LAN, and/or an Internet Protocol (“IP”) network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.
The authentication platform 150 may retrieve data from a registered user database 120 and/or a payment account database 130. The payment account database 130 might be associated with, for example, payment accounts, such as credit card or bank accounts. The registered user database 120 and the payment account database 130 may be locally stored or reside remote from the authentication platform 150. As will be described further below, the registered user database 120 and payment account database 130 may be used by the authentication platform 150 to generate a payment authorization message. According to some embodiments, the authentication platform 150 communicates information to an external device, such as by transmitting an electronic file to an email server, a workflow management system, POS device, etc. In other embodiments, the authentication platform 150 might store transaction information in a transaction history database 170. Note that, according to some embodiments, the registered user database 120 does not store any biometric information. Instead, the registered user database 120 may store token key values (created based on biometric information) and/or PIN values. Moreover, it might not be possible to re-create biometric information using the stored token key values.
Although a single authentication platform 150 is shown in
In accordance with some embodiments, the systems and methods described herein provide a framework to identify people who attempt to make ATM and/or merchant POS transactions based on biometric information (that is not stored or transmitted over a network) and information associated with payment accounts. By way of example, and without limiting the generality of the foregoing, a payment card can be a credit card, debit card, charge card, stored-value card, or prepaid card or nearly any other type of financial transaction card. Further, as used herein in, the term “issuer” or “attribute provider” can include, for example, a financial institution (i.e., bank) issuing a card, a merchant issuing a merchant specific card, a stand-in processor configured to act on-behalf of the card-issuer, or any other suitable institution configured to issue a payment card. As used herein, the term “transaction” can be associated with, for example, a merchant, a merchant terminal, an ATM, an online sale, a sale complete via a television, or any other suitable institution or device configured to initiate a financial transaction per the request of the account owner.
The information in the payment account database 130 may be associated with, for example, a “payment card processing system” or “credit card processing networks,” such as the MasterCard® network that allows account owners to use payment cards issued by a variety of issuers to shop at a variety of merchants. With this type of payment card, a card issuer or attribute provider, such as a bank, extends credit to an account owner to purchase products or services. When an account owner makes a purchase from an approved merchant, or withdraws funds via an ATM, the card number and amount of the purchase, along with other relevant information, are transmitted via the processing network to a processing center, which verifies that the card has not been reported lost or stolen and that the card's credit limit has not been exceeded. In some cases, the account owner's signature is also verified, a personal identification number is required or other user authentication mechanisms are imposed. The account owner is required to repay the bank for the purchases or cash withdrawals, generally on a monthly basis.
The payment account database 130 may further store a “business classification,” which is a group of merchants and/or businesses, by the type of goods and/or service the merchant and/or business provides. For example, the group of merchants and/or businesses can include merchants and/or business, which provide similar goods and/or services. In addition, the merchants and/or businesses can be classified based on geographical location, sales, and any other type of classification, which can be used to associate a merchant and/or business with similar goods, services, locations, economic and/or business sector, industry and/or industry group. According to some embodiments, different business classifications may be associated with different biometric standards.
The payment account database 130 may also store a “merchant category code” or “MCC,” which is a four-digit number created by MasterCard® or VISA® and assigned to a business by the acquirer when the business first starts accepting one of these cards as a form of payment. The MCC is used to classify the business by the type of goods or services it provides. For example, in the United States, the merchant category code can be used to determine if a payment needs to be reported to the IRS for tax purposes. In addition, MCCs are used by card issuers to categorize, track or restrict certain types of purchases. According to some embodiments, different MCCs may be associated with different biometric standards.
In accordance with some embodiments, data associated with payment card transactions is stored within the transaction history database 140. The data may include, for example, a listing of sales amount for each payment card transaction including the type of goods and/or services sold, a total number of goods and/or services sold in each transaction, a total sales amount for each transaction (e.g., gross dollar amount), a token keys value received from the account owner, etc. In addition, for each merchant and/or business, the data associated with each transaction may include a point-of-sale or point-of-purchase (e.g., location of each payment card transaction). The point-of-sale or point-of-purchase provides that for merchants and/or businesses having one or more locations, the location of the merchant and/or business, which generated the sale can be identified.
At S210, a POS device may read biometric information of the user. As used herein, the term “POS device” may refer to a merchant POS device, an ATM device, an online transaction (where, for example, a computer mouse may be adapted to read a user's fingerprint, a television transaction (where, for example, a television remote control may be adapted to read a user's fingerprint), etc. Moreover, according to some embodiments, the biometric user data comprises fingerprint information. Note that the ridges of a human finger are detailed, unique, difficult to alter, and durable over the life of an individual—which make them suitable as a long-term marker of human identity. Fingerprint identification, known as dactyloscopy, is the process of comparing two instances of ridge skin patterns to determine whether the impressions came from the same individual. Because no two finger or palm prints are ever exactly alike in every detail, an expert or computer system may use threshold scoring rules to determine whether two ridge patterns are likely to have originated from the same finger. Note, however, that embodiments described herein do not employ dactyloscopy. According to some embodiments, the biometric information comprises a plurality of fingerprints of the user (e.g., all five fingers of the person's left hand).
Note that embodiments may be associated with biometric data other than fingerprints. For example, the biometric user data might be associated with “palm vein biometrics.” Note that the pattern of blood veins in person's palm is unique to every individual (even among identical twins). Moreover, palms have a broad, complicated vascular pattern and thus contain a wealth of differentiating features for personal identification. Furthermore, these patterns will not vary during a person's lifetime. As a result, it is a very secure method of authentication because this blood vein pattern lies under the skin (making it difficult for others to read or copy).
An individual's vein pattern image might be captured by having sensors in a touchscreen radiate the person's hand with near-infrared rays. The reflection method illuminates the palm using an infrared ray and captures the light given off by the region after diffusion through the palm. The deoxidized hemoglobin in the in the vein vessels absorb the infrared ray, thereby reducing the reflection rate and causing the veins to appear as a black pattern. This vein pattern may then be captured. As veins are internal in the body and have a wealth of differentiating features, attempts to forge an identity are extremely difficult, thereby enabling a high level of security. In addition, the sensors of a palm vein device might only recognize the pattern when the deoxidized hemoglobin is actively flowing within the individual's veins. Note that such a sensor is not dangerous; a near infrared is a component of sunlight (there is no more exposure when scanning a hand as compared to walking outside in the sun). Further note that palm veins are inside the hand, and are therefore protected and less susceptible to minor trauma, cuts, etc. (as compared to some fingerprint systems). Also, the sensors may be contactless, hygienic, non-invasive, and highly accurate (e.g., with a false rejection rate of 0.01% and false acceptance rate of 0.00008%).
Other examples of biometric information that might be associated with embodiments described herein include facial information, retina information, DNA information, palm print data, hand geometry information, iris recognition data, and voice data.
At S220, the POS device may execute an encryption algorithm on the biometric information read from the user to create a token key value. The token key value may comprise, for example, a sixteen or twenty digit number that is uniquely generated based on the person's fingerprint (or other biometric data). Note that the encryption algorithm may be executed such that the original biometric information read from the user cannot be determined from the token key value. At S230, the POS device may receive from the user a PIN value. For example, he or she might enter a 4-digit PIN value using a keypad or touch screen at a merchant's POS device. Note that the token key value might comprise an alpha-numeric series associated with a tokenization algorithm (e.g., a series of 16 digits, 20 digits, etc.).
At S240, the POS device may arrange for the token key value and the PIN value to be received at an authentication server. For example, the POS device might transmit the token key value and PIN value to the authentication server without including any biometric information. In this way, people may feel more comfortable using the system and the chance of having private information stolen or otherwise compromised may be reduced.
At S320, the authentication server may determine that the received token key value and the PIN value match a verified token key value and a verified PIN value in a registered user database. For example, according to some embodiments the authentication server is coupled to a registered user database that stores, for each of a plurality of registered users, a verified token key value and an associated verified PIN value. In this case, the authentication server may search the registered user database to determine if it contains the token key value received in a transaction authentication message.
At S330, the authentication server may transmit a signal indicating that the received token key value and the PIN value match the verified token key value and the verified PIN value in the registered user database. That is, the authentication server may approve the transaction when it is determined that the user's token key value and PIN value match what is in the registered user database.
According to some embodiments, prior to using the system a user is registered with the authentication server, including the establishment and storage of the verified token key value and the associated verified PIN value in connection with a payment account. The payment account might be associated with, for example, a credit card account, a debit card account, an electronic wallet (e.g., associated with multiple payment accounts), and/or a pre-paid payment account. According to some embodiments, this establishment may be performed via a smartphone application executing on the user's smartphone. The smartphone application may, for example, generate a token key value in the same way a POS terminal would perform that function. Note that a smartphone is used herein only as an example, and embodiments may be associated with any other device able to capture biometric data.
According to some embodiments, an automated authentication platform 450 may identify an account owner when he or she attempts to make a transaction using a payment account. For example, the authentication platform 450 may automatically output a payment authorization indication to the POS device 410 or to any other party (e.g., a credit card issuer).
As used herein, devices, including those associated with the authentication platform 450 and any other device described herein, may exchange information via any communication network which may be one or more of a LAN, a MAN, a WAN, a proprietary network, a PSTN, a WAP network, a Bluetooth network, a wireless LAN, and/or an IP network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.
A verification engine 452 of the authentication platform 450 may retrieve data from a registered user database 420 and/or a payment account database. The payment account database might be associated with, for example, payment accounts, such as credit card or bank accounts. The registered user database 420 and the payment account database may be locally stored or reside remote from the authentication platform 450. As will be described further below, the registered user database 420 and payment account database may be used by the authentication platform 450 to generate a payment authorization message. Information in the registered user database 420 might, according to some embodiments, be received from a user's smartphone during a registration process. According to some embodiments, the authentication platform 450 might store transaction information in a transaction history database 470. Note that, according to some embodiments, the registered user database 420 does not store any biometric information. Instead, the registered user database 420 may store token key values (created based on biometric information) and/or PIN values. Moreover, it might not be possible to re-create biometric information using the stored token key values.
Although a single authentication platform 450 is shown in
In accordance with some embodiments, the systems and methods described herein provide a framework to identify people who attempt to make ATM and/or merchant POS transactions based on biometric information (that is not stored or transmitted over a network) and information associated with payment accounts. By way of example, and without limiting the generality of the foregoing, a payment card can be a credit card, debit card, charge card, stored-value card, or prepaid card or nearly any other type of financial transaction card. Further, as used herein in, the term “issuer” or “attribute provider” can include, for example, a financial institution (i.e., bank) issuing a card, a merchant issuing a merchant specific card, a stand-in processor configured to act on-behalf of the card-issuer, or any other suitable institution configured to issue a payment card. As used herein, the term “transaction” can be associated with, for example, a merchant, a merchant terminal, an ATM, an online sale, a sale complete via a television, or any other suitable institution or device configured to initiate a financial transaction per the request of the account owner.
In this way, the authentication platform may collect and store information about a substantial number of users with actually collecting biometric information (or even information that could be used to re-create biometric user information). Note that the embodiments described herein may be implemented using any number of different hardware configurations. For example,
The processor 510 also communicates with a storage device 530. The storage device 530 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device 530 stores a program 512 and/or authentication platform logic 514 for controlling the processor 510. The processor 510 performs instructions of the programs 512, 514, and thereby operates in accordance with any of the embodiments described herein. For example, a POS device may read a user's biometric information. The POS device may then execute an encryption algorithm on the biometric information read to create a token key value. The POS device may also receive a personal identification number value from the user and transmit the token key value and the personal identification number value to the processor 510. The processor 510 may determine that the received token key value and the personal identification number value match a verified token key value and a verified personal identification number value in a registered user database. The processor 510 may then transmit a signal to the POS device indicating that the received token key value and the personal identification number value match the verified token key value and the verified personal identification number value in the registered user database.
The programs 512, 514 may be stored in a compressed, uncompiled and/or encrypted format. The programs 512, 514 may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by the processor 510 to interface with peripheral devices.
As used herein, information may be “received” by or “transmitted” to, for example: (i) the authentication platform 500 from another device; or (ii) a software application or module within the authentication platform 500 from another software application, module, or any other source.
In some embodiments (such as shown in
Referring to
The user identifier 602 may be, for example, a unique alphanumeric code identifying an account owner and the user name 604 might comprise his or her legal name. The payment account 606 might comprise a credit card number, such as a Primary Account Number (“PAN”) associated with a that user's payment account (e.g., credit card account, debit card account, etc.). The key token value 608 may comprise, for example, a sixteen or twenty digit number generated by an encryption algorithm using the user's biometric information (e.g., his or her fingerprint). Note that it might not be possible to re-create the user's biometric information from the key token value 608. The PIN value might comprise, for example, a 4-digit number selected by the user or by an authentication platform.
Thus, according to some embodiments, an improved authentication platform might automatically approve transactions even when no payment card is present during an ATM, merchant POS, or other type of transaction. In addition, people may feel more comfortable knowing that their personal biometric information is not being stored or transmitted over a network (where it might be inappropriately accessed by unauthorized parties). Moreover, any embodiments described herein might be implemented for any type of transaction, including online transactions, television transactions (e.g., biometric information might be collected as the user is entering his or her PIN into a remote control unit and then automatically converted to a token key value before being sent to an authentication platform), etc. The present invention has been described in terms of several embodiments solely for the purpose of illustration. Persons skilled in the art will recognize from this description that the invention is not limited to the embodiments described, but may be practiced with modifications and alterations limited only by the spirit and scope of the appended claims.