Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20080065553 A1
Publication typeApplication
Application numberUS 11/764,370
Publication date13 Mar 2008
Filing date18 Jun 2007
Priority date19 Jun 2006
Also published asCA2655015A1, CA2655311A1, CA2655423A1, CA2655465A1, CA2655465C, 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 number11764370, 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
InventorsPatrick Faith, Ayman Hammad
Original AssigneePatrick Faith, Ayman Hammad
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Verification Error Reduction System
US 20080065553 A1
Abstract
A method is disclosed. The method includes a) 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, 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.
Images(8)
Previous page
Next page
Claims(17)
1. A method comprising:
a) 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;
b) determining if the dynamic data element is within a predetermined range;
c) 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.
2. The method of claim 1 wherein the dynamic data element is a counter value and wherein the predetermined range is a predetermined counter range.
3. The method of claim 2 wherein the predetermined counter range is between 2 and 10.
4. The method of claim 1 wherein the portable consumer device is a card.
5. The method of claim 1 wherein the portable consumer device is a phone.
6. The method of claim 1 a)-d) are performed by a service provider computer.
7. The method of claim 1 wherein initiating the approval includes approving the transaction or sending a message to an issuer who subsequently approves the transaction.
8. The method of claim 1 wherein the transaction is a purchase transaction.
9. The method of claim 1 wherein the predetermined range is less than 5.
10. The method of claim 1 wherein the verification value is 4 digits or less.
11. 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;
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.
12. The computer readable medium of claim 11 wherein the dynamic data element is a counter value and wherein the predetermined range is a predetermined counter range.
13. The computer readable medium of claim 12 wherein the predetermined counter range is between 2 and 10.
14. The computer readable medium of claim 11 wherein the portable consumer device is a card.
15. A computer comprising the computer readable medium of claim 11.
16. The computer of claim 15 wherein the dynamic data element is a counter value.
17. The computer apparatus of claim 15 wherein the predetermined counter range is between 2 and 10.
Description
    CROSS-REFERENCES TO RELATED APPLICATIONS
  • [0001]
    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.
  • BACKGROUND
  • [0002]
    As methods and devices for engaging in financial transactions have increased, old problems such as fraud and counterfeiting persist.
  • [0003]
    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.
  • [0004]
    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.
  • [0005]
    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.
  • [0006]
    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.
  • [0007]
    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.
  • [0008]
    Embodiments of the invention address these and other problems, individually and collectively.
  • BRIEF SUMMARY
  • [0009]
    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.
  • [0010]
    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.
  • [0011]
    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.
  • [0012]
    Other embodiments of the invention are directed to server computers and systems.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0013]
    FIG. 1 depicts a method of creating an encrypted data block for use in an embodiment of the present invention.
  • [0014]
    FIG. 2 depicts a method for generating unique derived keys from data residing on a portable consumer device.
  • [0015]
    FIG. 3 depicts a method for extracting portions of an encrypted data block for creating a dynamic card verification value according to the present invention.
  • [0016]
    FIG. 4 depicts an exemplary record format for use in an embodiment of the present invention.
  • [0017]
    FIG. 5 depicts an alternative exemplary format for use in an embodiment of the present invention.
  • [0018]
    FIG. 6 is a flowchart of a preferred method of utilizing a dynamically created verification value to authenticate a transaction.
  • [0019]
    FIG. 7 is a flowchart of an alternate method of utilizing a dynamically created verification value to authenticate a transaction.
  • DETAILED DESCRIPTION
  • [0020]
    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.
  • [0021]
    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.
  • [0022]
    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.
  • [0023]
    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.
  • [0024]
    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.
  • [0025]
    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.
  • [0026]
    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.
  • [0027]
    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.
  • [0028]
    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.
  • [0029]
    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.
  • [0030]
    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.
  • [0031]
    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.
  • [0032]
    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.
  • [0033]
    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.
  • [0034]
    Each time the payment service is initiated, a dCVV is generated on the portable consumer device for authentication purposes. FIG. 1 depicts the method of generating a dCVV for each transaction according to the present invention. Initially, a numeric string of predetermined length is created. This numeric string is created by overlaying 101 the ATC 102 over the corresponding leftmost digits of the account number for the payment service or PAN 104. This numeric string is concatenated on the right with the expiration date for the payment service and the service code to produce a concatenated value 106. If necessary, padding characters 108 are concatenated 110 on the right of the concatenated value 106 to form a numeric string 112 with a predetermined fixed length. In one embodiment, this numeric string 112 is 128-bits in length, although a numeric string of any length may be used. The padding characters 108 may consist of a stream of 0's, 1's or any other numeric value that is known both to the portable consumer device and the service provider. The numeric string 112 is bisected into two blocks of equal length, Block A 116 and Block B 118. Block A 116 is then encrypted 121 with a first encryption key 120. The result of the encryption step 121 is Block C 122 of length equal to Block A 116. Block C 122 is then exclusively OR'ed (XOR) 123 with Block B 118 resulting in Block D 124. Block D 124 is then encrypted 125 with a second encryption key 126 to produce Block E 128. Block E 128 is then decrypted 129 using a decryption key 130 to produce Block F 132. Block F 132 is then encrypted 133 using a fourth encryption key 134 to produce Block G 136.
  • [0035]
    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 FIG. 1 are within the scope of the present invention.
  • [0036]
    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.
  • [0037]
    FIG. 2 shows the methodology for deriving two unique keys which are utilized in the preferred embodiment. The account number 201, the account sequence number 202, the inverse of the account number 203, and the inverse of the account sequence number 204 are concatenated together to create a concatenated value 210. If necessary, the concatenated value 210 may be padded with zeroes, or some other value 211 and may accommodate additional discretionary data comprising one or more data elements, to create a string of a predetermined fixed length. In one embodiment, the concatenated value 210 may be 128 bits in length, although the concatenated value is not limited to being this length and may accommodate additional discretionary data comprising one or more data elements. The concatenated value 210 is then encrypted 220 using the master derivation key 221 as the encryption key for each encryption stage. The encryption utilized may include any type of encryption methodology. For example, this encryption step may utilize Triple-DES encryption. The value resulting from the encryption step 220 is a unique derived key or UDK 230 for the application identified by the account number. Two additional keys, UDKA 240 and UDKB 241, are derived from the UDK. The derivation of UDKA 240 and UDKB 241 from the UDK 230 may take any form, including assigning the value of the leftmost half of the UDK 230 to UDKA 240, and assigning the value of the rightmost half of the UDK 230 to UDKB 241. Alternatively, the UDKA 240 may be derived by selecting alternating or other predetermined bit sequences from the UDK 230 while the remaining bits are assigned to UDKB 241. Furthermore, there is no requirement that UDKA 240 and UDKB 241 are of equal length.
  • [0038]
    FIG. 3 describes the further processing required to generate the dCVV. Each nibble (4-bit grouping) of the value stored in Block G 136 is subjected to two separate iterative processes to evaluate the value of each nibble. As shown in FIG. 3, beginning with the most significant (i.e. left most) digit of Block G 136 and examining each sequential nibble, if a nibble contains a value ranging from zero to nine, inclusive, that value is extracted 301 and placed in a new numeric string 305, referred to herein as a holding string, by concatenating the extracted value to the right of the previously extracted value, if any. The result may be that the holding string contains a series of values ranging from zero to nine, inclusive, which appear from left to right in the holding string in the same sequence in which they appear in Block G 136.
  • [0039]
    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.
  • [0040]
    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.
  • [0041]
    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.
  • [0042]
    FIG. 4 depicts an exemplary record format for transmitting payment data, with the dCVV embedded therein, from the portable consumer device to the point of sale terminal. The record format of FIG. 4 is created by concatenating a primary account number 401 for the payment service, with an expiration date 402, and a service code 403. In one embodiment, the primary account number 401 is 16 digits long, the expiration date 402 is four digits long, and the service code 403 is three digits long. However, the primary account number 401, the expiration date 402, and the service code 403 are not limited to being these lengths. Next, in a field typically reserved for other uses, a value is placed as an indicator 705 that a dCVV has been embedded in this record. The value of this indicator is known by the service provider which deployed the application on the portable consumer device. Next, the ATC 410 is placed in the field which may typically be reserved for PIN verification data. Finally, the dCVV 415 is concatenated on the right of the record. The remainder of the record may comprise additional discretionary data.
  • [0043]
    Alternately, FIG. 5 depicts a second exemplary format for transmitting payment information with the dCVV embedded thereon from the portable consumer device to the point of sale terminal. The format in FIG. 5 is created by concatenating a primary account number 501 for the payment service, with an expiration date 502, a service code 503, a PVKI 504, and a field for PIN verification data 505. In one embodiment, the primary account number 501 is sixteen digits long, the expiration date 502 is four digits long, the service code 503 is three digits long, the PVKI 504 is one digit long, and the PIN verification data 505 is four digits long. However, the primary account number 501, the expiration date 502, the service code 503, the PVKI 504, and the PIN verification data 505 are not limited to being these lengths. Next, in a single data field 510 each of the dynamically created CVV, the ATC and the indicator to be used by the service provider to identify that a dynamic CVV has been embedded are stored in sequence. The remainder of the record may comprise additional discretionary data.
  • [0044]
    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. FIG. 6 shows how the dCVV is used in a contactless environment to permit the service provider to evaluate the authenticity of the payment application deployed on the portable consumer device to make a determination of whether the payment application has been skimmed. Although shown in the embodiment of a contactless environment in FIG. 6, the present invention is not limited to such an environment and may be used for any transaction where magnetic stripe Track 1 and/or Track 2 data is exchanged using any method or means for communicating such data.
  • [0045]
    As shown in FIG. 6, the portable consumer device generates the dCVV 601, using the methodology described above. The dCVV is embedded into the payment data 605. In this respect, the exemplary record formats shown in FIG. 4 or FIG. 5 may be utilized. The payment data with the embedded dCVV is transmitted by data communication to the point of sale terminal 610. The point of sale terminal recognizes the received data as in the standard format of payment data and passes the data stream on to the service provider computer 615, likely via a payment network (not shown). The service provider computer receives 620 the payment data with the embedded dCVV and interrogates the appropriate indicator to determine if the transaction was a contactless transaction or not 625. If the service provider computer determines that the transaction was not a contactless transaction, the transaction is processed in its normal manner 630. If the service provider computer determines that the transaction was contactless, the service provider computer compares the ATC received from the portable consumer device to the corresponding ATC on the service provider computer to determine if the received ATC is the expected next ATC 635, and/or is within an allowable range. If the ATC received from the portable consumer device is not the expected next ATC or within the allowable range, the payment service deployed on the portable consumer device has potentially been skimmed 640. If the expected next ATC and/or an ATC that is within the allowable range is received, the service provider computer may independently re-generate the dCVV for the given transaction 645 utilizing a similar or analogous process as described above. If the service provider generated dCVV matches the dCVV received from the portable consumer device 650, or if the dCVV is one that can be generated using an ATC within the allowable range, the service provider deems the payment application to be authentic 655. The service provider computer then replaces the ATC which was previously stored on the service provider computer with the generated ATC received from the portable consumer device 660 for subsequent authentications. If the service provider generated dCVV does not match the dCVV, or is not one which is derived from an ATC within the allowable range, the transaction is potentially fraudulent and is terminated 665.
  • [0046]
    The methodology of FIG. 6 discussed in conjunction with contactless transactions, is not limited thereto. For example, the methodology may be utilized with respect to transactions above a certain threshold value. In such an instance, the service provider, upon deploying the application, would configure the application to generate a dCVV for transactions above the threshold. The indicator interrogated in Step 625 would then be set for transactions above the threshold value. Similarly, the methodology may be utilized with respect to any other transaction criteria including, but not limited to, geographic location, use patterns, or any other criteria.
  • [0047]
    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.
  • [0048]
    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.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US4528442 *25 May 19849 Jul 1985Omron Tateisi Electronics, Co.Personal identification system
US5254843 *7 Aug 199119 Oct 1993Hynes John ESecuring magnetically encoded data using timing variations in encoded data
US5311594 *26 Mar 199310 May 1994At&T Bell LaboratoriesFraud protection for card transactions
US5434398 *22 Feb 199418 Jul 1995Haim LabenskiMagnetic smartcard
US5465387 *8 Oct 19937 Nov 1995At&T Corp.Adaptive fraud monitoring and control
US5513250 *13 Oct 199430 Apr 1996Bell Atlantic Network Services, Inc.Telephone based credit card protection
US5625689 *5 Apr 199529 Apr 1997Washington UniversityMethod and apparatus for secure data storage and manipulation using magnetic media
US5627355 *13 Apr 19956 May 1997Rahman; SamTransaction device, equipment and method for protecting account numbers and their associated personal identification numbers
US5708422 *31 May 199513 Jan 1998At&TTransaction authorization and alert system
US5740244 *7 May 199614 Apr 1998Washington UniversityMethod and apparatus for improved fingerprinting and authenticating various magnetic media
US5774525 *14 Aug 199730 Jun 1998International Business Machines CorporationMethod and apparatus utilizing dynamic questioning to provide secure access control
US5818226 *27 Sep 19966 Oct 1998Sony CorporationMagnetic sensor having a coil with varying turns along the length of a bobbin
US5819226 *8 Sep 19926 Oct 1998Hnc Software Inc.Fraud detection using predictive modeling
US5834747 *19 Feb 199710 Nov 1998Pixel InstrumentsUniversal credit card apparatus and method
US5872834 *16 Sep 199616 Feb 1999Dew Engineering And Development LimitedTelephone with biometric sensing device
US5878337 *12 Jun 19972 Mar 1999Joao; Raymond AnthonyTransaction security apparatus and method
US5903830 *12 Jun 199711 May 1999Joao; Raymond AnthonyTransaction security apparatus and method
US5914472 *23 Sep 199722 Jun 1999At&T CorpCredit card spending authorization control system
US5920628 *9 Jan 19976 Jul 1999Washington UniversityMethod and apparatus for fingerprinting and authenticating various magnetic media
US5988497 *30 May 199623 Nov 1999Mci Communications CorporationMethod for authenticating credit transactions to prevent fraudulent charges
US6000832 *24 Sep 199714 Dec 1999Microsoft CorporationElectronic online commerce card with customer generated transaction proxy number for online transactions
US6012144 *1 Oct 19974 Jan 2000Pickett; Thomas E.Transaction security method and apparatus
US6029154 *28 Jul 199722 Feb 2000Internet Commerce Services CorporationMethod and system for detecting fraud in a credit card transaction over the internet
US6157707 *2 Apr 19995 Dec 2000Lucent Technologies Inc.Automated and selective intervention in transaction-based networks
US6219793 *8 Sep 199717 Apr 2001Hush, Inc.Method of using fingerprints to authenticate wireless communications
US6260146 *22 Jun 199810 Jul 2001Semtek Innovative Solutions, Inc.Method and apparatus for securing and authenticating encoded data and documents containing such data
US6308890 *30 Jun 199830 Oct 2001Pixel Instruments, Inc.Universal credit card apparatus and method
US6442532 *17 Aug 199827 Aug 2002Transaction Technology Inc.Wireless transaction and information system
US6529725 *9 Oct 19984 Mar 2003Raymond Anthony JoaoTransaction security apparatus and method
US6612488 *31 Oct 20012 Sep 2003Hitachi, Ltd.Method and system to prevent fraudulent payment in credit/debit card transactions, and terminals therefor
US6636833 *22 Jan 199921 Oct 2003Obis Patents Ltd.Credit card system and method
US6714918 *18 Nov 200230 Mar 2004Access Business Group International LlcSystem and method for detecting fraudulent transactions
US6823721 *11 Dec 200230 Nov 2004Hutchison Hayes, L.P.Method and system for mass flow balance accounting
US6832721 *3 Oct 200121 Dec 2004Nec CorporationAuthentication system using information on position
US6899269 *3 Jun 199931 May 2005Mag-Tek, Inc.Magnetic stripe authentication and verification system
US6913194 *7 Jul 20035 Jul 2005Hitachi, Ltd.Method and system to prevent fraudulent payment in credit/debit card transactions, and terminals therefor
US7003497 *31 Dec 200121 Feb 2006International Business Machines CorporationSystem and method for confirming electronic transactions
US7024396 *10 Dec 20034 Apr 2006Ncr CorporationTransaction system and method of conducting a point-of-sale transaction between a merchant and a consumer using a wireless platform
US7044394 *17 Dec 200316 May 2006Kerry Dennis BrownProgrammable magnetic data storage card
US7051002 *12 Jun 200323 May 2006Cardinalcommerce CorporationUniversal merchant platform for payment authentication
US7096003 *10 Sep 200122 Aug 2006Raymond Anthony JoaoTransaction security apparatus
US7143095 *31 Dec 200228 Nov 2006American Express Travel Related Services Company, Inc.Method and system for implementing and managing an enterprise identity management for distributed security
US20020091562 *1 Jun 200111 Jul 2002Sony Corporation And Sony Electrics Inc.Facilitating offline and online sales
US20020108062 *15 May 20018 Aug 2002Takayuki NakajimaAuthentication system and method
US20020133462 *16 Mar 200119 Sep 2002Koninklijke Philips Electronics N.V.Instant electronic notification of credit card use serves as deterrent
US20020153424 *19 Apr 200124 Oct 2002Chuan LiMethod and apparatus of secure credit card transaction
US20020180584 *19 Dec 20015 Dec 2002Audlem, Ltd.Bio-metric smart card, bio-metric smart card reader, and method of use
US20030028481 *4 Jun 20026 Feb 2003Orbis Patents, Ltd.Credit card system and method
US20030208684 *7 Mar 20016 Nov 2003Camacho Luz MariaMethod and apparatus for reducing on-line fraud using personal digital identification
US20040107170 *29 Jul 20033 Jun 2004Fujitsu LimitedApparatuses for purchasing of goods and services
US20040153417 *3 Feb 20035 Aug 2004Mary EverhartRemotely synchronizing financial authentication
US20040156537 *2 Feb 200412 Aug 2004Chung Kevin Kwong-TaiqGeneration, verification and reproduction of a digitized writing
US20040171406 *28 Feb 20032 Sep 2004Gary PurkTransaction card providing displayed information
US20040185830 *31 Jan 200423 Sep 2004Joao Raymond AnthonyApparatus and method for providing account security
US20050043997 *18 Aug 200324 Feb 2005Sahota Jagdeep SinghMethod and system for generating a dynamic verification value
US20050080730 *27 Sep 200414 Apr 2005First Data CorporationSystem and method for secure account transactions
US20050170814 *28 Mar 20054 Aug 2005Joao Raymond A.Transaction security apparatus and method
US20060059110 *3 Apr 200216 Mar 2006Ajay MadhokSystem and method for detecting card fraud
US20060202025 *11 Mar 200514 Sep 2006Gerry CalabreseMobile phone charge card notification and authorization method
US20060281439 *13 Jun 200514 Dec 2006Benco David SNetwork support for credit card charge notification
US20060282382 *23 May 200614 Dec 2006Cardinalcommerce CorporationUniversal merchant platform for payment authentication
US20070239622 *23 Mar 200711 Oct 2007Larry RouthensteinMethod for generating customer secure card numbers
US20070262138 *3 Apr 200615 Nov 2007Jean SomersDynamic encryption of payment card numbers in electronic payment transactions
US20070276765 *30 May 200729 Nov 2007Hazel Patrick KMethod and system for secured transactions
US20080302876 *29 Oct 200711 Dec 2008Mullen Jeffrey DDynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card
Non-Patent Citations
Reference
1 *White, Ron, "How Computers Work", Millennium Ed., Que Corporation, Indianapolis, IN, 1999
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US774016818 Jun 200722 Jun 2010Visa U.S.A. Inc.Method and system for generating a dynamic verification value
US776137418 Aug 200320 Jul 2010Visa International Service AssociationMethod and system for generating a dynamic verification value
US781826412 Jun 200719 Oct 2010Visa U.S.A. Inc.Track data encryption
US781932218 Jun 200726 Oct 2010Visa U.S.A. Inc.Portable consumer device verification system
US808758210 May 20103 Jan 2012Ayman HammadMethod and system for generating a dynamic verification value
US812194220 Jun 200821 Feb 2012Visa U.S.A. Inc.Systems and methods for secure and transparent cardless transactions
US812195620 Jun 200821 Feb 2012Visa U.S.A. Inc.Cardless challenge systems and methods
US838786630 Nov 20115 Mar 2013Visa International Service AssociationMethod and system for generating a dynamic verification value
US842341521 Jun 201016 Apr 2013Visa International Service AssociationPayment service authentication for a transaction using a generated dynamic verification value
US8473414 *8 Apr 201125 Jun 2013Visa International Service AssociationSystem and method including chip-based device processing for transaction
US848950615 Sep 201016 Jul 2013Visa U.S.A. Inc.Portable consumer device verification system
US85331185 Nov 200910 Sep 2013Visa International Service AssociationOnline challenge-response
US856767026 Mar 201029 Oct 2013Intersections Inc.Dynamic card verification values and credit transactions
US858929120 Jan 201219 Nov 2013Visa U.S.A. Inc.System and method utilizing device information
US860670025 Jan 201210 Dec 2013Visa U.S.A., Inc.Systems and methods for secure and transparent cardless transactions
US86362058 Feb 201328 Jan 2014Visa U.S.A. Inc.Method and system for generating a dynamic verification value
US87066219 Oct 201322 Apr 2014Visa U.S.A., Inc.Secure checkout and challenge systems and methods
US870731926 Jun 200922 Apr 2014Visa International Service AssociationResource location verification by comparing and updating resource location with a location of a consumer device after a threshold of location mismatches is exceeded
US87128896 Jan 201029 Apr 2014Visa International Service AssociationAlterable account number
US87449588 Nov 20133 Jun 2014Visa U. S. A. Inc.Systems and methods for secure and transparent cardless transactions
US876227912 Aug 201324 Jun 2014Visa International Service AssociationOnline challenge-response
US881238513 Dec 201219 Aug 2014Visa International Service AssociationAlterable account number
US88434173 Nov 200823 Sep 2014Visa U.S.A. Inc.Track data encryption
US897230316 Sep 20103 Mar 2015Visa U.S.A. Inc.Track data encryption
US8977570 *21 May 201310 Mar 2015Visa International Service AssociationSystem and method including chip-based device processing for transaction
US906564325 Jun 200823 Jun 2015Visa U.S.A. Inc.System and method for account identifier obfuscation
US972125024 Oct 20081 Aug 2017Visa U.S.A. Inc.Location based authentication
US20080029593 *18 Jun 20077 Feb 2008Ayman HammadMethod and System for Generating a Dynamic Verification Value
US20080040271 *18 Jun 200714 Feb 2008Ayman HammadPortable Consumer Device Verification System
US20080319869 *20 Jun 200825 Dec 2008Mark CarlsonSystems and methods for secure and transparent cardless transactions
US20090083191 *3 Nov 200826 Mar 2009Ayman HammadTrack data encryption
US20090089213 *3 Nov 20082 Apr 2009Ayman HammadTrack data encryption
US20090150295 *9 Dec 200711 Jun 2009Jeffrey Alan HatchValidation service for payment cards with preloaded dynamic card verification values
US20090171849 *3 Nov 20082 Jul 2009Ayman HammadTrack data encryption
US20090327135 *26 Jun 200931 Dec 2009Loc Duc NguyenCredit card paired with location identifiable device for point of service fraud detection
US20090328052 *26 Jun 200931 Dec 2009Loc Duc NguyenResource locator verification method and apparatus
US20100114776 *5 Nov 20096 May 2010Kevin WellerOnline challenge-response
US20100252623 *10 May 20107 Oct 2010Ayman HammadMethod and system for generating a dynamic verification value
US20100258625 *26 Mar 201014 Oct 2010Intersections Inc.Dynamic Card Verification Values and Credit Transactions
US20100262546 *21 Jun 201014 Oct 2010Jagdeep Singh SahotaPayment service authentication for a transaction using a generated dynamic verification value
US20100287085 *6 Jan 201011 Nov 2010Bob JoubertAlterable account number
US20100299267 *12 May 201025 Nov 2010Patrick FaithDevice including encrypted data for expiration date and verification value creation
US20110004526 *15 Sep 20106 Jan 2011Ayman HammadPortable consumer device verification system
US20110004553 *16 Sep 20106 Jan 2011Ayman HammadTrack data encryption
US20110145208 *15 Dec 200916 Jun 2011Microsoft CorporationPolicy driven distributed data resiliency
US20110276487 *8 Apr 201110 Nov 2011Ayman HammadSystem and method including chip-based device processing for transaction
US20130254112 *21 May 201326 Sep 2013Ayman HammadSystem and Method Including Chip-Based Device Processing For Transaction
Classifications
U.S. Classification705/64
International ClassificationH04K1/00, G06Q90/00
Cooperative ClassificationG06Q20/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 ClassificationH04L9/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
Legal Events
DateCodeEventDescription
4 Dec 2008ASAssignment
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