OMAR TACTAAA
`
`US 20050043997A1
`
`as) United States
`a2) Patent Application Publication 0) Pub. No.: US 2005/0043997 Al
`
` Sahota etal. (43) Pub. Date: Feb. 24, 2005
`
`
`(54) METHOD AND SYSTEM FOR GENERATING
`A DYNAMIC VERIFICATION VALUE
`
`(52) US. C0. eee eceecsseseesseessssnsssnceaseesrensesnscnscenseeses 705/16
`
`(76)
`
`Inventors: Jagdeep Singh Sahota, Rodeo, CA
`(US); Christian Aabye, Foster City, CA
`(US)
`
`(57)
`
`ABSTRACT
`
`Correspondence Address:
`Pepper Hamilton LLP
`50th Floor
`One Mellon Center
`500 Grant Street,
`.
`Pittsburgh, PA 15219 (US)
`
`Methods and systems for dynamically generating a verifi-
`cation value for a transaction and for utilizing such value to
`verify the authenticity of the payment service application.
`The dynamically created verification value may be gener-
`ated on a paymentdevice, such as an integratedcircuit credit
`card or smart card, embedded into the payment data, and
`transmitted to a point of sale terminal. Alternatively, pay-
`ment data is sent by a payment device to a point of sale
`(21) Appl. No.: terminal, which generatesaverification value and embedsit10/642,878
`
`
`(22)
`Filed:
`Aug.18, 2003
`into the payment data. The embedded verification value is
`used by a service provider to verify the authenticity of the
`transaction. The methods and systems may be used in a
`contactless (wireless) environment or a non-wireless envi-
`ronment.
`
`Publication Classification
`
`(SL) Ute C0 eee ceeccccsssssssssneescceceennnnseeseeseee GO06F 17/60
`
`102
`1
`
`108
`
`Padding Character
`
`
`
`1
`
`SAMSUNG 1006
`
`of the 16 digi PAN 104
`
`Overlay the ATC on
`
`ATC
`the faft most 4 digits
`
`
`PAN
`
`Expiry Date
`Expiry Date
`
`SVC Code
`SVC Code...
`
`
`= 128 hits
`
`1
`
`SAMSUNG 1006
`
`

`

`Patent Application Publication Feb. 24,2005 Sheet 1 of 7
`
`US 2005/0043997 Al
`
`
`
`g0Lé01
`
`Syd82}=‘|
`
`O1W
`
`apoa3P0DAS|amahie10DSAS
`
`
`978QAdlcx3apuepaueyNvdayegAuidk3
`
`afolyv0!
`
`Ott
`
`vfay
`
`@-polg
`
`S40bo
`
`SLL
`
`vel
`
`Ob
`
`NvWEipopeijo
`
`
`
`
`
`JapessydBulppegolyUOSiay)ABHaAG,
`
`suéippsowyeyour
`
`2
`
`
`
`
`
`

`

`Patent Application Publication Feb. 24,2005 Sheet 2 of 7
`
`US 2005/0043997 Al
`
`201
`
`202
`
`203
`
`204
`
`Account number
`
`Account sequence
`number
`
`
`Inverse of account
`number
`
`Inverse of account
`sequence number
`
`210
`
`Account sequence| Inverse of account|Inverse of account
`Padding
`Account number
`number
`number
`sequence number
`
`
`MasterDerivation
`
`
`
`220
`
`230
`
`
`
`Key (MDK)
`
`
`
`
`
`Data encryption
`
`Unique Derived Key
`(UDK)
`
`240
`
`FIG. 2
`
`3
`
`

`

`Patent Application Publication Feb. 24,2005 Sheet 3 of 7
`
`US 2005/0043997 Al
`
` Extract nibbles
`
`with decimal
`values from 0 to 9
`
` values in holding
`
` 305
`
`string by
`concatenating on
`right of previous
`value
`
` Extract nibbles
`
`with hexadecimal
`
`values from A to F
`
`301
`
`310
`
` Decimalize
`
`
` 315
`
`extracted value by
`subtracting
`
`hexadecimal
`
` values in holding
`string by
`concatenating on
`right of previous
`alue
`
` 320
`
`
` Extract 3 most
`
`
` 325
`
`significant nibbles
`from holding string
`
`to generate dCVV
`
`
`
`
`FIG. 3
`
`4
`
`

`

`Patent Application Publication Feb. 24,2005 Sheet 4 of 7
`
`US 2005/0043997 Al
`
`415
`
`PEPPERELL 3 0
`
` |in|
`.Hg
`=
`
` =|
`PPEEPEET|
`
`
`
`‘|“|EPL|
`
`
`ee
`>|
`
`|is|
`
`ce
`as
`“a
`
`401
`
`5
`
`

`

`Patent Application Publication Feb. 24,2005 Sheet 5 of 7
`
`US 2005/0043997 Al
`
`POS
`
`cOS
`
`6
`
`

`

`Patent Application Publication Feb. 24,2005 Sheet 6 of 7
`
`US 2005/0043997 Al
`
`
`dCVV embedded
`
`
`
`Magnetic stripe
`
`
`Payment device
`into magnetic
`
`data transmit to
`generates dCVV
`
`stripe
`POSterminal
`
`
`
`data format
`
`
`610
`
`620
`
`POSterminal
`
`passes MSdata
` Service provider
`
`
`receives MS data
`on to service
`
`provider
`
`
`
`615
`
`
`s ATC next in
`Possible data
`Standard magnetic
`
`
`Contactless?
`stripe processing
`sequence?
`skimming
`
`
`
`
`
`
`
`
`645
` 660
`
` Generate dCVV
`for the transaction
`
`
`
`Service provider
`
`
`Transaction may
`dCVV = payment
`be approved
`
`device dCVV?
`
`
`
`655
`
`Terminate
`
`
`Store ATC
`
`FIG. 6
`
`7
`
`

`

`Patent Application Publication Feb. 24,2005 Sheet 7 of 7
`
`US 2005/0043997 Al
`
`701
`
`720
`
`Service provider
`receives MS data
`
`POS device
`passes MS data
`on to service
`provider
`
`710
`
`ms
`
`
`
`Magnetic stripe
`data transmit to
`
`POSdevice
`
`
`
`POSdevice
`computes
`verification value
`
`Verification value
`embeddedinto
`magnetic stripe
`data format
`
`
`
`
`
`
`Is additional
`Possible data
`
`
`data next in
`skimmin
`
`9
`sequence?
`
`
`
`Generate
`
`verification value
`735
`for the transaction
`
`
`
`
`
`Service provider
`
`Transaction may
`verification value = POS
`.
`
`
`be approved
`device verification
`Terminate
`
`value?
`
`
`
`Store additional
`
`
`
`data
`
`FIG. 7
`
`748
`
`750
`
`8
`
`

`

`US 2005/0043997 Al
`
`Feb. 24, 2005
`
`METHOD AND SYSTEM FOR GENERATING A
`DYNAMIC VERIFICATION VALUE
`
`BACKGROUND OF THE INVENTION
`
`[0001] As methods and devices for engaging in financial
`transactions have increased and expanded into new hori-
`zons, age old problems such as fraud and counterfeiting
`persist. In fact, as applications and devices are developed
`which make credit or debit based transactions a more
`
`attractive and readily available alternative to cash, fraud and
`counterfeiting activities have seen a proportionate increase.
`
`In order to protect financial institutions, consumers
`[0002]
`and merchants from the fraudulent use of transaction cards,
`the industry has developed and introduced many features
`designed to reduce fraud and counterfeiting such as holo-
`grams, special over-layers, and watermarks. Nonetheless,
`many of these features are proving to be less effective as
`financial transactions are increasingly being conducted in a
`wireless environment. Similarly, as financial instruments are
`increasingly being employed on electronic devices, rather
`than physical plastic cards, the ability to use techniques such
`as a customer signature or hologramsto verify a party to a
`transaction is becomingless available.
`
`[0003] One of the primary sources of fraud which is
`prevalent in the credit card industry is skimming, which
`refers to the electronic copying of the card’s magneticstripe
`data to create counterfeit cards. Early skimming wasdifficult
`to hide and required cumbersome equipment. As credit card
`technology has become more sophisticated, so has the
`technology used by skimmers.
`
`In addition, new forms of skimming have appeared.
`[0004]
`For example, in one instance a small bug was implanted in
`a terminal, and left in place for weeks to collect hundreds of
`card numbers before being removedto harvest the collective
`card data. Also, one of the more insidious forms of skim-
`ming involved line tapping wherein the communication
`lines between the terminal and the credit card issuer is
`tapped and the card data extracted from the communications
`string. One of the most sophisticated examples of line
`tapping involved skimmers renting an office next
`to an
`issuers regional data center and tapping lines going to the
`issuer computers. The tapped lines were redirected through
`a computer on the skimmer’s site. Compounding the prob-
`lem, the skimmers were able to remotely access their com-
`puter thus permitting the skimmersto harvest the credit card
`numbers from a remote location. By some estimates, skim-
`ming costs financial
`institutions hundreds of billions of
`dollars annually. Furthermore, some industry analysts have
`estimated that each skimmed card will engage in at least
`$2,000 in transactions before the fraud is uncovered.
`
`[0005] Skimming is predominantly a phenomenonafflict-
`ing 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 media. In other words, the digital content of the
`magnetic stripe can be perfectly copied, without any differ-
`ence between the copy andthe original. Largely, this feature
`is relied upon in legitimate magnetic stripe transactions as a
`point of sale terminal is simply required to read the data
`present on the magnetic stripe.
`
`[0006] One of the primary means by which skimming can
`be prevented is for the consumer to closely monitor the
`
`whereabouts of their transaction card. This will allow the
`consumer to prevent the card from being swiped through
`inappropriate devices. However, as magnetic stripe contact-
`less cards evolve and bring the promise of quick transactions
`to current payment environments,
`the classic skimming
`problem comesalong with it. In fact, in a wireless environ-
`ment 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 simply, and
`without knowledge of the consumer or merchant, intercept
`the wireless transaction and copy the data being transmitted
`from the card to POS terminal.
`
`[0007] Nonetheless, magnetic stripe data and magnetic
`stripe paymentapplications are increasingly being deployed
`on integrated circuit cards or similar devices which have
`processing capabilities. Accordingly, what is needed is to
`dynamically generate a verification value for each transac-
`tion which can be used to authenticate the transaction. Such
`an approach to authentication of the payment service will
`significantly reduce the opportunity for skimming since the
`verification valueis different for each transaction. Therefore,
`even if the data utilized in a given transaction is skimmed,
`that data will not be useful in conducting further transactions
`since the skimmedverification value is not valid for subse-
`
`quent transactions.
`SUMMARYOF THE INVENTION
`
`invention describes a system and
`[0008] The present
`method for dynamically generating a verification value for
`verifying the authenticity of a payment service deployed on
`a payment device, such as an integrated circuit credit card,
`each time the payment service is utilized in a transaction.
`With each transaction, a verification value is dynamically
`generated on the payment device from data specific to the
`paymentservice. The verification value is embeddedinto the
`payment data which is transmitted from the payment device
`to a point of sale terminal such as a credit card terminal. The
`point of sale terminal transmits the payment data, with the
`embedded verification data, which may be in the form of
`magnetic stripe credit card Track 1 and/or Track 2 data, to
`a payment network which transmits the payment data to a
`service provider computer. The service provider computer
`independently generates a verification value. The transaction
`is disapprovedif the service provider generated verification
`value does not match the payment device generated verifi-
`cation value.
`
`In an alternate embodiment, payment data gener-
`[0009]
`ated with each transaction on the payment device is trans-
`mitted from the payment device on which the payment data
`wasgenerated to a point of sale terminal such as a credit card
`terminal. A verification value may be generated by the point
`of sale terminal using the payment data and information
`contained within the point of sale device. The point of sale
`terminal transmits the payment data, with the verification
`data, which maybein the form of magnetic stripe credit card
`Track 1 and/or Track 2 data, to a payment network which
`transmits the payment data to a service provider computer.
`The service provider computer independently generates a
`verification value. The transaction is disapproved if the
`service provider generated verification value does not match
`the verification value generated on the pointof sale terminal.
`
`9
`
`

`

`US 2005/0043997 Al
`
`Feb. 24, 2005
`
`[0010] The present invention may be used in any transac-
`tion in which magnetic stripe Track 1 and/or Track 2 data
`will be exchanged over any type of interface including
`contact-based interfaces and wireless interfaces.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0011] Aspects, features, benefits and advantages of the
`embodiments of the present invention will be apparent with
`regard to the following description, appended claims and
`accompanying drawings where:
`
`[0012] FIG. 1 depicts the method of creating an encrypted
`data block for use in the present invention.
`
`[0013] FIG. 2 depicts a method for generating unique
`derived keys from data residing on a payment device.
`
`[0014] FIG. 3 depicts a method for extracting portions of
`an encrypted data block for creating a dynamic card verifi-
`cation value according to the present invention.
`
`[0015] FIG. 4 depicts an exemplary record format for use
`in an embodimentof the present invention.
`
`[0016] FIG. 5 depicts an alternative exemplary format for
`use in an embodimentof the present invention.
`
`[0017] FIG. 6 is a flowchart of a preferred method of
`utilizing a dynamically created verification value to authen-
`ticate a transaction.
`
`[0018] FIG. 7 is a flowchart of an alternate method of
`utilizing a dynamically created verification value to authen-
`ticate a transaction.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`[0019] Before the present methodsare 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 will be limited only
`by the appended claims. In particular, although the present
`invention is described in conjunction with financial trans-
`actions, it will be appreciated that the present invention may
`find use in any electronic exchange of data.
`
`It must also be noted that as used herein and in the
`[0020]
`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
`knownto those skilled in the art, and so forth. Unless defined
`otherwise, all technical and scientific terms used herein have
`the same meanings as commonly understood by one of
`ordinary skill in the art. Although any methods similar or
`equivalent to those described herein can be used in the
`practice or testing of embodiments of the present invention,
`the preferred methods are now described. All publications
`mentioned herein are incorporated by reference. Nothing
`herein is to be construed as an admission that the invention
`is not entitled to antedate such disclosure by virtue of prior
`invention.
`
`[0021] Generally, the present invention provides methods
`and systems for dynamically generating a card verification
`
`value for each transaction and for utilizing such value to
`verify that the paymentservice is authentic and has not been
`skimmed. The dynamically generated Card Verification
`Value (referred to herein as the “dCVV”) is generated on the
`payment device, embedded into the payment data, and
`transmitted to a point of sale terminal.
`In an alternate
`embodiment, payment data is received from a payment
`device, a verification value is generated by a pointof sale
`terminal, and the verification value is embedded into the
`paymentdata.
`
`In an embodiment, data received by the point of
`[0022]
`sale terminal is interpreted as simply payment data (e.g.
`standard magnetic stripe Track 1 and/or Track 2 data without
`an embedded dCVV)bythe pointof 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 verifi-
`cation value generated by the service provider does not
`match the dCVV received from the payment device, the
`transaction is identified as potentially fraudulent and disap-
`proved.
`
`In an alternate embodiment, data is received by the
`[0023]
`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.
`
`[0024] For purposesofthis application, the term “payment
`device” shall mean 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, “payment device” shall
`include an integrated
`circuit card (also commonly known as a smartcard), a
`memory card, a cellular telephone, a personal digital assis-
`tant, a mobile electronic device, or a computer.
`
`[0025] For purposes of this application, “contactless” or
`“wireless” shall mean any communications method or pro-
`tocol,
`including proprietary protocols,
`in which data is
`exchanged between two devices without the need for the
`devices to be physically coupled. Without
`limiting the
`generality of the foregoing, “contactless” or “wireless” shall
`include data transmissionsbylaser, radio frequency, infrared
`communications, Bluetooth, or wireless local area network.
`
`[0026] For purposes ofthis application, the term “payment
`service” shall mean any application deployed on a payment
`device which causes the exchange of data between the
`payment device and any other device or location. It should
`be appreciated that “payment service” is not
`limited to
`financial applications.
`
`[0027] For purposes of this application, “payment data”
`shall mean, with respect to financial applications those data
`elements used by the paymentservice to execute a transac-
`tion, and with respect
`to non-financial
`transactions any
`necessary data elements exclusive of the present invention.
`For example, when the paymentservice is a magneticstripe
`
`10
`
`10
`
`

`

`US 2005/0043997 Al
`
`Feb. 24, 2005
`
`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 discre-
`tionary data. “Payment data” may also comprise a unique
`card identification numberor a unique identification number
`for a service provider.
`
`In an embodiment, the payment data will reside on
`[0028]
`memorylocated on the payment device. The payment device
`will also maintain an application transaction counter (ATC).
`The ATC will initially be set by the service provider to a
`predetermined value. Thereafter,
`the ATC will be incre-
`mented with each transaction. Alternately, the ATC may be
`decremented from its initial predetermined value with each
`transaction. The ATC may be a value of any length. In
`addition, the service provider which deployed the payment
`service will maintain a corresponding ATC accessable 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.
`
`[0029] Each time the paymentservice is initiated, a dCVV
`is generated on the payment device for authentication pur-
`poses. 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 num-
`ber for the payment service or PAN 104. This numeric string
`is concatenated on the right with the expiration date for the
`paymentservice and the service code to produce a concat-
`enated 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 a preferred embodiment, this numeric string 112
`is 128-bits in length, although a numericstring 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 payment 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.
`
`It will be apparent to one of ordinary still in the art
`[0030]
`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.
`
`Ina preferred embodiment,the first encryption key
`[0031]
`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 payment
`device. Upon deployment, each paymentservice is person-
`alized 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 payment
`device will be personalized with the functionality to derive
`keys unique to the payment service. FIG. 2 shows the
`methodology for deriving two unique keys which are uti-
`lized in the preferred embodiment. The account number201,
`the account sequence number 202, the inverse of the account
`number 203, and the inverse of the account sequence num-
`ber 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, to create a
`string of a predetermined fixed length.
`In a preferred
`embodiment, the concatenated value 210 may be 128 bits in
`length, although the concatenated value is not limited to
`being this length. 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 241from 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 241are of equal length.
`
`[0032] Returning now to the result of the methodology set
`forth in FIG. 1. 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 exam-
`ining 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 will be that the holding string containsa 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.
`
`[0033] Asecond evaluation is then performed again begin-
`ning 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 valueis
`then decimalized by subtracting the hexadecimal value A
`from the extracted value resulting in a decimalized value
`
`11
`
`11
`
`

`

`US 2005/0043997 Al
`
`Feb. 24, 2005
`
`ranging from zero to five 315. This decimalized valueis then
`concatenated on the right to the right most value of the
`holding string 320.
`
`[0034] 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 dCVVfor the transaction. Other numbers
`of bits may be extracted from the twice-examined nibble
`string to generate the dCVV fora transaction. Furthermore,
`different nibbles, such as the rightmost nibbles, may be used
`as the dCVVfor a transaction. The three leftmost nibbles,
`however, represent a preferred embodiment.
`
`[0035] Once generated, the dCVV is embedded into the
`payment data transmitted from the payment device to the
`point of sale terminal. The data received by the point of sale
`terminal will appear to the point of sale terminal as standard
`paymentdata. In other words, the point of sale terminal will
`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 embeddedinto the data
`received from the paymentdevice.
`
`[0036] FIG. 4 depicts an exemplary record format for
`transmitting payment data, with the dCVV embedded
`therein, from the payment device to the point of sale
`terminal. The record format of FIG.4 is created by concat-
`enating a primary account number 401 for the payment
`service, with an expiration date 402, and a service code 403.
`In a preferred embodiment, the primary account number401
`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 405 that a (CVV has been embedded
`in this record. The value of this indicator is known by the
`service provider which deployed the application on the
`payment 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 remainderof the record may comprise additional
`discretionary data.
`
`[0037] Alternately, FIG. 5 depicts a second exemplary
`format for transmitting payment information with the dCVV
`embedded thereon from the payment device to the point of
`sale terminal. The format in FIG. 5 is created by concat-
`enating 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 a
`preferred embodiment, the primary account number 501 is
`sixteen digits long, the expiration date 502 is four digits
`long, the service code 503is 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 dynami-
`cally created CVV, the ATC and the indicator to be used by
`the service provider to identify that a dynamic CVV has
`been embeddedare stored in sequence. The remainderofthe
`record may comprise additional discretionary data.
`
`the service provider to make a determination of the authen-
`ticity of the payment service being utilized. This authenti-
`cation 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 payment device to
`make a determination of whether the payment application
`has been skimmed. Although shownin the embodimentof a
`contactless environment in FIG.6, the present invention is
`not limited to such an environment and maybe used for any
`transaction where magnetic stripe Track 1 and/or Track 2
`data is exchanged using any method or means for commu-
`nicating such data. As shownin FIG.6, the payment device
`generates the dCVV 601, preferably 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 dCVVis transmitted by data com-
`munication 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 net-
`work (not shown). The service provider computer receives
`620 the payment data with the embedded dCVVandinter-
`rogates the appropriate indicator to determine if the trans-
`action was a contactless transaction or not 625. If the service
`provider computer determinesthat the transaction was not a
`contactless transaction, the transaction is processed in its
`normal manner 630. If the service provider computer deter-
`minesthat the transaction was contactless, the service pro-
`vider computer compares the ATC received from the pay-
`ment device to the corresponding ATC stored on the service
`provider computer to determine if the received ATC is the
`expected next ATC 635. If the ATC received from the
`payment device is not the expected next ATC, the payment
`service deployed on the paymentdevice has potentially been
`skimmed 640. If the expected next ATC is received, the
`service provider computer will independently re-generate
`the dCVV for the given transaction 645 utilizing the same
`process as described above. If the service provider generated
`dCVV matches the dCVV received from the payment device
`650, the service provider deems the payment application to
`be authentic 655. The service provider computer
`then
`replaces the ATC which waspreviously stored on the service
`provider computer with the ATC received from the payment
`device 660 for subsequent authentications. If the service
`provider generated dCVV does not match the dCVV
`received from the paymentdevice, the transaction is poten-
`tially fraudulent and is terminated 665.
`[0039] The methodology of FIG. 6 discussed in conjunc-
`tion 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 applica-
`tion, would configure the application to generate a (CVV 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 beutilized
`with respect to any other transaction criteria including, but
`notlimited to, geographic location, use patterns, or any other
`criteria.
`
`[0038] An important aspect of the present inventionis that
`the system of utilizing the dynamically created CVV allows
`
`In an alternate embodiment, the payment device
`[0040]
`transmits paymentdata to a point of sale terminal such as a
`
`12
`
`12
`
`

`

`US 2005/0043997 Al
`
`Feb. 24, 2005
`
`credit card terminal 701. The point of sale terminal receives
`the data and computesa verification value for the transaction
`705. The verification value may be computed in a numberof
`different ways including, without limitation, using a unique
`transaction numberprovided bythe 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 ve