|Publication number||US20080065553 A1|
|Application number||US 11/764,370|
|Publication date||Mar 13, 2008|
|Filing date||Jun 18, 2007|
|Priority date||Jun 19, 2006|
|Also published as||CA2655015A1, CA2655311A1, CA2655423A1, CA2655465A1, CA2655748A1, CA2656058A1, EP2039038A2, EP2039038A4, EP2039052A2, EP2039052A4, EP2041663A2, EP2041663A4, EP2041714A2, EP2041714A4, EP2047621A2, EP2047621A4, US7810165, US7818264, US7819322, US8135647, US8375441, US8489506, US8494968, US8843417, US8972303, US20070294182, US20080005037, US20080034221, US20080040271, US20080040276, US20080103982, US20090083191, US20090089213, US20090171849, US20110004526, US20110004553, US20110066516, US20120158591, US20130275310, WO2007149762A2, WO2007149762A3, WO2007149775A2, WO2007149775A3, WO2007149785A2, WO2007149785A3, WO2007149787A2, WO2007149787A3, WO2008016752A2, WO2008016752A3, WO2008027642A2, WO2008027642A3|
|Publication number||11764370, 764370, US 2008/0065553 A1, US 2008/065553 A1, US 20080065553 A1, US 20080065553A1, US 2008065553 A1, US 2008065553A1, US-A1-20080065553, US-A1-2008065553, US2008/0065553A1, US2008/065553A1, US20080065553 A1, US20080065553A1, US2008065553 A1, US2008065553A1|
|Inventors||Patrick Faith, Ayman Hammad|
|Original Assignee||Patrick Faith, Ayman Hammad|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (3), Non-Patent Citations (1), Referenced by (17), Classifications (37), Legal Events (1)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application claims the benefit of the filing dates of U.S. Provisional Patent Application No. 60/815,059 filed Jun. 19, 2006, 60/815,430 filed Jun. 20, 2006, and 60/884,089 filed Jan. 9, 2007, which are hereby incorporated by reference, as if set forth in full in this document, 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.
To address the above problems, some have proposed using a dCVV or a dynamic card verification value. The dCVV can be generated using an algorithm which uses at least a counter and input data such as an account number, expiration date, and other information. The counter can increase by one each time a transaction is conducted. The dCVV can be independently generated by either a portable consumer device or POS terminal at the front end of a transaction and can be sent to a back end computer. The counter may be sent from the merchant to the back end computer so that it knows the current counter value associated with the portable consumer device. In other cases, the counter may simply be present at the back end computer. In the latter case, the counter increments every time the back end computer sees a transaction. The back end computer, using a similar algorithm to the one that generated the dCVV at the front end, the counter value, and input data, can independently generate a second dCVV. If the received dCVV and the generated dCVV match, the transaction can be considered authentic. If the dCVVs do not match, this may indicate that the transaction is fraudulent.
Although the above-described dCVV process is useful, there may, however, be a number of instances where the counter value transmitted from a portable consumer device and received at the back end server does not match the corresponding counter value at the back end computer. For example, sometimes, a merchant might not forward transaction data to the issuer in a timely manner. If this occurs, it is possible that future transactions conducted by the consumer could be inadvertently rejected. For instance, if the portable consumer device used by the consumer has a counter in it to count the number of transactions conducted, and if the counter in the back end computer does not keep a corresponding transaction count (e.g., because of the delayed receipt of transaction data from one or more merchants, chargebacks), some of the consumer's transactions may be inadvertently rejected. This is undesirable.
Embodiments of the invention address these and other problems, individually and collectively.
Embodiments of the present invention describes verification error reduction systems and methods for dynamically verifying the authenticity of a payment service deployed on a portable consumer device, such as an integrated circuit credit card, each time the payment service is utilized in a transaction.
One embodiment of the invention is directed to a method comprising: a) receiving a dynamic data element and a first verification value derived from the dynamic data element (e.g., a counter), wherein the first verification value (a dCVV) is generated in response to a transaction conducted using a portable consumer device; b) determining if the dynamic data element is within a predetermined range; c) if the dynamic data element is within the predetermined range, generating a second verification value; d) determining if the second verification value matches the first verification value, or if the second verification value is otherwise acceptable; and e) initiating the approval the transaction if the second verification value matches the first verification value, or if the second verification value is otherwise acceptable.
Another embodiment of the invention is directed to a computer readable medium comprising: code for receiving a dynamic data element and a first verification value derived from the dynamic data element, wherein the first verification value is generated in response to a transaction conducted using a portable consumer device; code for determining if the dynamic data element is within a predetermined range; code for generating a second verification value if the dynamic data element is within the predetermined range; code for determining of the second verification value matches the first verification value, or if the second verification value is otherwise acceptable; and code for initiating the approval of the transaction if the second verification value matches the first verification value, or if the second verification value is otherwise acceptable.
Other embodiments of the invention are directed to server computers and systems.
Before the present methods are described, it is to be understood that this invention is not limited to the particular methodologies, devices or protocols described, as these may vary. It is also to be understood that the terminology used in the description is for the purpose of describing the particular versions or embodiments only, and is not intended to limit the scope of the present invention which may be limited only by the appended claims. In particular, although the present invention is described in conjunction with financial transactions, it may be appreciated that the present invention may find use in any electronic exchange of data.
It is also noted that as used herein and in the appended claims, the singular forms “a”, “an”, and “the” include plural reference unless the context clearly dictates otherwise. Thus, for example, reference to a “key” is a reference to one or more keys and equivalents thereof known to those skilled in the art, and so forth.
Generally, embodiments of the invention provide improved methods and systems for dynamically generating a card verification value for each transaction and for utilizing such value to verify that the payment service is authentic and has not been skimmed. The dynamically generated Card Verification Value (referred to herein as the “dCVV”) is generated on the portable consumer device, embedded into the payment data, and transmitted to a point of sale terminal. In an alternate embodiment, payment data is received from a portable consumer device, a verification value is generated by a point of sale terminal, and the verification value is embedded into the payment data.
In an embodiment, data received by the point of sale terminal is interpreted as simply payment data (e.g. standard magnetic stripe Track 1 and/or Track 2 data without an embedded dCVV) by the point of sale terminal. The point of sale terminal passes on the received data to a payment network which, in turn, passes the data on to the service provider. If the service provider determines the transaction is one for which a dCVV is required, the service provider independently generates a verification value. If the verification value generated by the service provider does not match the dCVV received from the portable consumer device, the transaction is identified as potentially fraudulent and disapproved.
In an alternate embodiment, data is received by the point of sale terminal and is used by the point of sale terminal to generate a verification value. The point of sale terminal passes on the received data to a payment network which, in turn, passes the data on to the service provider. The service provider independently generates a verification value. If the verification value generated by the service provider does not match the dCVV received from the point of sale terminal, the transaction is identified as potentially fraudulent and disapproved.
As explained above, in some instances, a dynamic data element such as a counter (or other type of data element that can change) can be received at a back end computer along with a dCVV generated by a portable consumer device. The back end computer can determine if the counter is within a predetermined range. If it is, then the back end computer can independently generate another dCVV. If the received dCVV and the generated dCVV match, then the transaction can be considered authentic.
The back end computer can comprise a processor, and a computer readable medium comprising code for performing any of the functions described herein. For example, the back end computer may comprise a computer readable medium comprising code for receiving a dynamic data element and a first verification value derived from the dynamic data element, wherein the first verification value is generated in response to a transaction conducted using a portable consumer device, code for determining if the dynamic data element is within a predetermined range, code for generating a second verification value if the dynamic data element is within the predetermined range, code for determining if the second verification value matches the first verification value, and code for initiating the approval of the transaction if the second verification value matches the first verification value.
The range of counter values at the back end computer provides some tolerance, in case the counter at the back end computer does not match the counter that it receives from a POS terminal. In preferred embodiments, the range of counter values is less than about 10, or between about 2 and about 10. If the counter received from the POS terminal and the counter at the back end server are within, for example, 10 or even 5 or less, the transaction may be considered authentic even if the dCVVs do not match.
Advantageously, in embodiments of the invention, fewer transactions will be rejected as being non-authentic due to non-matching counter values. Note that although counter values are described in detail, other types of values and ranges could be used. For example, the dynamic data element could be a time of day and the range could be a range of days.
For purposes of this application, the term “portable consumer device” can include any device comprising a microprocessor which may be used in a transaction or data exchange as described herein. Without limiting the generality of the foregoing, “portable consumer device” can include an integrated circuit card (also commonly known as a smartcard), a memory card, a cellular telephone, a personal digital assistant, a mobile electronic device, or a computer.
For purposes of this application, “contactless” or “wireless” can include any communications method or protocol, including proprietary protocols, in which data are exchanged between two devices without the need for the devices to be physically coupled. Without limiting the generality of the foregoing, “contactless” or “wireless” can include data transmissions by laser, radio frequency, infrared communications, Bluetooth, or wireless local area network.
For purposes of this application, the term “payment service” can include any application deployed on a portable consumer device which causes the exchange of data between the portable consumer device and any other device or location. It should be appreciated that “payment service” is not limited to financial applications.
For purposes of this application, “payment data” can include, with respect to financial applications those data elements used by the payment service to execute a transaction, and with respect to non-financial transactions any necessary data elements exclusive of the present invention. For example, when the payment service is a magnetic stripe credit card transaction, “payment data” would comprise Track 1 and/or Track 2 data, as that is understood by one of ordinary skill in the credit card industry, such as the primary account number, expiration date, service codes, and discretionary data. “Payment data” may also comprise a unique card identification number or a unique identification number for a service provider.
In an embodiment of the invention, the payment data may reside in memory located in the portable consumer device. The portable consumer device may also maintain an application transaction counter (ATC), which may be a value of any suitable length. The ATC may initially be set by the service provider to a predetermined value. Thereafter, the ATC may be incremented with each transaction. Alternately, the ATC may be decremented from its initial predetermined value with each transaction. In addition, the service provider which deployed the payment service may maintain a corresponding ATC accessible to the service provider's computer. As discussed in more detail below, this corresponding ATC is used to identify payment services which may have been skimmed. In an alternate embodiment, a cryptogram, digital signature, or hash value based on transaction data may be used in place of or in conjunction with the ATC.
Each time the payment service is initiated, a dCVV is generated on the portable consumer device for authentication purposes.
It will be apparent to one of ordinary still in the art that the first encryption key 120, the second encryption key 126, the third encryption key 130 and the fourth encryption key 134 may take any preselected value. In an embodiment of the present invention, the first encryption key 120, the second encryption key 126, and the fourth encryption key 134 are equivalent and of a different value from the third encryption key 130. Other permutations of the encryption key values utilized in the methodology of
In one embodiment, the first encryption key 120, the second encryption key 126, the third encryption key 130, and the fourth encryption key 134 take the value of unique keys derived from data existing on the portable consumer device. Upon deployment, each payment service is personalized by the service provider with a master derivation key. The master derived key may be deployed with payment services in batches (i.e. multiple payment services receive the same master derived key) or individually. Each portable consumer device may be personalized with the functionality to derive keys unique to the payment service.
A second evaluation is then performed again beginning with the most significant digit of Block G 136 and examining each sequential nibble. If a nibble contains a hexadecimal value ranging from ten (A) to fifteen (F), inclusive, that value is extracted 310. The extracted value is then decimalized by subtracting the hexadecimal value A from the extracted value resulting in a decimalized value ranging from zero to five 315. This decimalized value is then concatenated on the right to the right most value of the holding string 320.
Once all nibbles in Block G have been twice examined as described, the three most-significant (i.e. left-most) nibbles of the holding string are extracted 325. This 3-digit value is the dCVV for the transaction. Other numbers of bits may be extracted from the twice-examined nibble string to generate the dCVV for a transaction. Furthermore, different nibbles, such as the rightmost nibbles, may be used as the dCVV for a transaction. The three leftmost nibbles, however, represent a preferred embodiment.
Once generated, the dCVV is embedded into the payment data transmitted from the portable consumer device to the point of sale terminal. The data received by the point of sale terminal may appear to the point of sale terminal as standard payment data. In other words, the point of sale terminal may not be able to determine if a dCVV is embedded and where such dCVV may be located. There is no indication to the point of sale terminal that a dCVV is embedded into the data received from the portable consumer device.
An aspect of the present invention is that the system of utilizing the dynamically created CVV allows the service provider to make a determination of the authenticity of the payment service being utilized. This authentication step is not left to merchants, individual point of sale terminals, or other third parties or devices.
As shown in
The methodology of
In an alternate embodiment, the portable consumer device transmits payment data to a point of sale terminal such as a credit card terminal 701. The point of sale terminal receives the data and computes a verification value for the transaction 705. The verification value may be computed in a number of different ways including, without limitation, using a unique transaction number provided by the point of sale terminal, a timestamp, or a transaction amount added to a timestamp. The point of sale terminal may then embed and/or append the verification value and additional data to the payment data 710. The additional data may be required for the service provider computer to verify the transaction. The point of sale terminal then passes the data stream on to the service provider computer 715, likely via a payment network (not shown). The service provider computer receives the payment data with the verification value 720. The service provider computer may optionally compare at least a portion of the additional data embedded or appended by the point of sale terminal to corresponding data stored on the service provider computer to determine if the received data is proper 725, and/or is within a predetermined range. If the received data from the point of sale terminal is improper, the transaction data may potentially have been skimmed 730. If proper data, the service provider computer may independently re-generate the verification value for the given transaction utilizing the same process as used by the point of sale terminal 735. If the service provider generated verification value matches the verification value received from the point of sale terminal 740, of if the generated verification value is otherwise acceptable (e.g., the verification value is generated using dynamic data elements that are within acceptable ranges), the service provider deems the payment application to be authentic 745. The service provider computer may then optionally update the additional data which was previously stored on the service provider computer with the additional data received from the portable consumer device for subsequent authentications 750. If the service provider generated verification value does not match the verification value received from the point of sale terminal, or is otherwise not acceptable, the transaction is potentially fraudulent and is terminated 755.
The foregoing is considered as illustrative only of the principles of the invention. Further, since numerous modifications and changes may readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation shown and described, and accordingly, all suitable modifications and equivalents may be resorted to, falling within the scope of the invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US20070239622 *||Mar 23, 2007||Oct 11, 2007||Larry Routhenstein||Method for generating customer secure card numbers|
|US20070262138 *||Apr 3, 2006||Nov 15, 2007||Jean Somers||Dynamic encryption of payment card numbers in electronic payment transactions|
|US20070276765 *||May 30, 2007||Nov 29, 2007||Hazel Patrick K||Method and system for secured transactions|
|1||*||White, Ron, "How Computers Work", Millennium Ed., Que Corporation, Indianapolis, IN, 1999|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7740168||Jun 18, 2007||Jun 22, 2010||Visa U.S.A. Inc.||Method and system for generating a dynamic verification value|
|US7761374||Aug 18, 2003||Jul 20, 2010||Visa International Service Association||Method and system for generating a dynamic verification value|
|US7818264||Jun 12, 2007||Oct 19, 2010||Visa U.S.A. Inc.||Track data encryption|
|US7819322||Jun 18, 2007||Oct 26, 2010||Visa U.S.A. Inc.||Portable consumer device verification system|
|US8087582||May 10, 2010||Jan 3, 2012||Ayman Hammad||Method and system for generating a dynamic verification value|
|US8387866||Nov 30, 2011||Mar 5, 2013||Visa International Service Association||Method and system for generating a dynamic verification value|
|US8423415||Jun 21, 2010||Apr 16, 2013||Visa International Service Association||Payment service authentication for a transaction using a generated dynamic verification value|
|US8473414 *||Apr 8, 2011||Jun 25, 2013||Visa International Service Association||System and method including chip-based device processing for transaction|
|US8567670||Mar 26, 2010||Oct 29, 2013||Intersections Inc.||Dynamic card verification values and credit transactions|
|US8707319||Jun 26, 2009||Apr 22, 2014||Visa International Service Association||Resource location verification by comparing and updating resource location with a location of a consumer device after a threshold of location mismatches is exceeded|
|US8712889||Jan 6, 2010||Apr 29, 2014||Visa International Service Association||Alterable account number|
|US8812385||Dec 13, 2012||Aug 19, 2014||Visa International Service Association||Alterable account number|
|US8977570 *||May 21, 2013||Mar 10, 2015||Visa International Service Association||System and method including chip-based device processing for transaction|
|US9065643||Jun 25, 2008||Jun 23, 2015||Visa U.S.A. Inc.||System and method for account identifier obfuscation|
|US20100299267 *||May 12, 2010||Nov 25, 2010||Patrick Faith||Device including encrypted data for expiration date and verification value creation|
|US20110276487 *||Nov 10, 2011||Ayman Hammad||System and method including chip-based device processing for transaction|
|US20130254112 *||May 21, 2013||Sep 26, 2013||Ayman Hammad||System and Method Including Chip-Based Device Processing For Transaction|
|International Classification||H04K1/00, G06Q90/00|
|Cooperative Classification||G06Q20/3829, G06Q20/20, G06Q20/401, G06Q20/3674, H04L2209/56, G06Q30/06, G06Q20/085, G06Q2220/00, G06Q20/382, G06Q20/3821, G06Q20/40, G06Q20/385, G06Q40/00, H04L9/3271, G06Q20/204, G06Q20/105, G06Q20/3672, G06Q20/367|
|European Classification||H04L9/32, G06Q30/06, G06Q20/40, G06Q20/20, G06Q20/367, G06Q20/105, G06Q20/385, G06Q20/085, G06Q20/3821, G06Q20/3674, G06Q20/401, G06Q20/382, G06Q40/00, G06Q20/204, G06Q20/3829, G06Q20/3672|
|Dec 4, 2008||AS||Assignment|
Owner name: VISA U.S.A. INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FAITH, PATRICK;HAMMAD, AYMAN;REEL/FRAME:021930/0094;SIGNING DATES FROM 20070828 TO 20070904