as) United States
`a2) Patent Application Publication co) Pub. No.: US 2015/0178724 Al
`
` Ngoet al. (43) Pub. Date: Jun. 25, 2015
`
`
`US 20150178724A1
`
`(54) LIMITED-USE KEYS AND CRYPTOGRAMS
`
`Publication Classification
`
`(71) Applicants:Hao Ngo, San Jose, CA (US); Christian
`Aabye, Foster City, CA (US); John
`Sheets, San Francisco, CA (US); Oleg
`Makhotin, Castro Valley, CA (US)
`
`(72)
`
`Inventors: Hao Ngo, San Jose, CA (US); Christian
`Aabye, Foster City, CA (US); John
`Sheets, San Francisco, CA (US); Oleg
`Makhotin,Castro Valley, CA (US)
`
`(21) Appl. No.: 14/577,678
`4.
`Filed:
`(22)
`Dec. 19, 2014
`+
`as
`Related U.S. Application Data
`(60) Provisional application No. 61/918,643, filed on Dec.
`19, 2013, provisional application No. 61/941,227,
`filed on Feb. 18, 2014, provisional application No.
`61/982,169,filed on Apr. 21, 2014, provisional appli-
`cation No. 61/983,635, filed on Apr. 24, 2014.
`
`100
`
`(51)
`
`Int. Cl.
`G06Q 20/38
`(52) U.S. CL.
`CPC vieccccccccsccccescetesessees G06Q 20/3829 (2013.01)
`
`(2006.01)
`
`ABSTRACT
`
`57
`67)
`Techniques for enhancing the security of a communication
`device when conducting a transaction using the communica-
`tion device may include encrypting account information with
`a first encryption key to generate a second encryption key, and
`encrypting key index information using the second key to
`generate a limited-use key (LUK). The key index information
`may include a key index having information pertaining to
`generation of the LUK. The LUK andthe key index can be
`provided to the communication deviceto facilitate generation
`ofa transaction cryptogram for a transaction conducted using
`the communication device, and the transaction can be autho-
`rized basedon the transaction cryptogram generated from the
`LUK.
`
`Cloud Based
`Payments
`
`Issuer/ Host
`v5.
`=
`
`“
`
`Mobile
`Application
`Platform
`170
`
`Network
`
` Payment Processing
`
`Network
`Portable Communication Device
`194
`
`i App Environment 110
`Mobile App / Wallet
`112
`On-Device Cloud
`Based Transaction
`SW 113
`Acquirer
`
`
`Platform
` Communications
`192
`
`174 fMobileOS1i4
`
`i
`
`Card Emulation APls 116
`
`Device Hardware 104
`Electronic
`} Contactless i
`i
`
`
`Contactless Interface 108 # Acceptance|Cash Register }}¢> i Reader
`
`
`i
`i
`i; Device 164
`i
`
`MerchantPoint of Sale / Access Device 160
`
`1
`
`SAMSUNG 1012
`
`SAMSUNG 1012
`
`1
`
`

`

`Patent Application Publication
`
`Jun. 25,2015 Sheet 1 of 16
`
`US 2015/0178724 Al
`
`100
`
`oe
`Application
`Platform
`170
`
`Cloud Based
`Payments
`Platform
`
`Issuer / Host
`System
`5
`—
`
`
`Mobile
`
`
`194
`
`
`Communications
`Network
`192
`
`Portable Communication Device
`
`PaymentProcessing
`Network
`
`Mobile App / Wallet
`112
`
`On-Device Cloud
`Based Transaction
`
`Acquirer
`174
`
`Contactless Interface 108
`
`}¢+
`i
`
`Contactless
`Reader
`
`i
`
`Acceptance
`Device 164
`
`Electronic
`Cash Register }
`
`2
`
`

`

`Patent Application Publication
`
`Jun. 25, 2015 Sheet 2 of 16
`
`US 2015/0178724 Al
`
`siqowa|qeyod
`
`ONINOISIAONd
`LNAWTIOYNA
`
`
`
`pasegpno|d
`
`sjuawAed
`
`WJOJ1e|d
`
`08z
`
`1SOH/Janss|
`
`LW3a3SAS
`
`aka
`
`
`
`volesiddy*WLWUO?
`
`
`
`WIOPeldaolaaq
`
`0ZzToc
`
`9EZUONEWIYUOD
`
`cOl
`
`972JsanbaySUIUOISIAOId
`
`
`ZZJsanbayUaW||ouuy
`
`7ZZysanbayyuaw|osuy
`
`
`
`8Z7Ze1eqSUIUOISIAOI
`
`
`
`O€Ze1eqSUIUOISIAOId
`
`PETUONEWIIYUOD
`
`CECUONCWIIU0D
`
`3
`
`

`

`Patent Application Publication
`
`Jun. 25,2015 Sheet 3 of 16
`
`US 2015/0178724 Al
`
`Portable
`Comm.
`Devi
`evice
`301
`
`Access
`Device
`360
`
`Integrated Chip Based Transaction
`
`Available Applications Request 302
`(e.g., Select PPSE Command)
`
`Available Applications Response 304
`(e.g., Select PPSE Response)
`
`
`
`Transaction Processing Information 312
`(e.g., GPO Response)
`
`Application Selection 306
`(e.g., Select AID Command)
`
`Terminal Transaction Data Request 308
`(e.g., Select AID Response)
`
`PDOL
`
`Terminal Transaction Data 310
`(e.g., GPO Command)
`
`PDOL (TTQ = chip)
`
`AFL, AIP, Cryptogram, Track 2 (e.g., Token/PAN), etc.
`
`Account Data Request 314
`(e.g., Read Record Command)
`
`AFL
`
`Account Data 316
`(e.g., Read Record Response)
`
`FIG. 3
`
`4
`
`

`

`Patent Application Publication
`
`Jun. 25,2015 Sheet 4 of 16
`
`US 2015/0178724 Al
`
`Access
`Device
`460
`
`Mobile
`Device
`401
`
`Magnetic Stripe Based Transaction
`
`Available Applications Request 402
`(e.g., Select PPSE Command)
`
`Available Applications Response 404
`(e.g., Select PPSE Response)
`
`
`
`Transaction Processing Information 412
`(e.g., GPO Response)
`
`Application Selection 406
`(e.g., Select AID Command)
`
`Terminal Transaction Data Request 408
`(e.g., Select AID Response)
`
`PDOL
`
`Terminal Transaction Data 410
`(e.g., GPO Command)
`
`PDOL (TTQ = mag. stripe)
`
`AFL, AIP
`
`Account Data Request 414
`(e.g., Read Record Command)
`
`Account Data 416
`
`(e.g., Read Record Response)
`
`Track 2 (e.g., Token/PAN, Key Index, Cryptogram)
`
`FIG. 4
`
`5
`
`

`

`Patent Application Publication
`
`Jun. 25,2015 Sheet 5 of 16
`
`US 2015/0178724 Al
`
`Sequence Counter (SC)
`
`'
`
`Transaction Timestamp
`
`Unpredictable Number (UN)
`
`Application Transaction Counter (ATC)
`
`Transaction Type
`
`Transaction Type
`
`Transaction Timestamp
`
`Unpredictable Number (UN)
`
`Application Transaction Counter (ATC)
`
`FIG. 5
`
`Transaction 1
`
`Transaction N
`
`6
`
`

`

`Patent Application Publication
`
`Jun. 25, 2015 Sheet 6 of 16
`
`US 2015/0178724 Al
`
`1SOH/Janss|
`
`WaisdsS
`
`cL9
`
`
`
`NOILVOISTHAALNAWAVd-LSOd
`
`
`
`
`
`pesegpno|D9|IQOW9|GeWod
`
`
`
`
`
`sjuawAeduolenjddy"WwOoD
`
`
`
`
`
`WOLIeIdWJOselda0lAaq
`
`0890L9TO9
`
`
`
`7ZZ9Jsenbay3o7]uonoesued|779Isanbay807uoNoesues]979IsSenbay8o7uolesuel|
`
`
`
`
`
`UO!}eWIOJU|307UO!JDesUeIL
`
`UOIEWJIOJU]307]UOIDesUeL|
`
`UOIEWIOJU|ZO]uolesuedL
`
`cea
`
`0€9
`
`8c9
`
`9“Old
`
`7
`
`
`
`

`

`Patent Application Publication
`
`Jun. 25, 2015 Sheet 7 of 16
`
`US 2015/0178724 Al
`
` L£°Old
`
`
`
`
`
`9Z/UONEDLNONJUaWYsiUa|dayZLJsenbeyJUuawWYsUua|deyZZZJsanbayJUeWYsius|day
`
`
`
`
`
`8Z/JUaWAaspa|moUNYyO€/SuaJawWeJegJUNODDYMANZE/SdayaWesegJUNOIDYMAN
`
`
`
`pesegpno|dS|IQoIe|qeuod
`
`
`sjuawAeduoljeaddy“wwoy
`WJIOJE|WO]dao1Aaq
`08ZOZZTOL
`
`
`
`1SOH/Janss|
`
`Wwayshs
`
`CZL
`
`
`
`
`
`LNAWHSINA1dSYSYSLAAIVeVdLNNODDV
`
`QELUOIJEUIIJUODPELUONeWIYUOD
`
`8
`
`

`

`Patent Application Publication
`
`Jun. 25, 2015 Sheet 8 of 16
`
`US 2015/0178724 Al
`
`008
`
`AZ08
`
`808
`
`vs
`
`508
`
`
`uoljounyuolydAyouy
`
`Nsd||Yax01/NWd“3'9)
`
`
`
`uolyeWJOjU]JUNODDY
`
`
`
`
`
`(NSd|[Ua}OL/NVdpayeau|
`
`cL8
`
`
`uoljounyuolydAusuy
`
`XXXXXXXXIIHHHHAW,“"3"9)
`
`
`
`UOHeWJOJU]XepuyAay|
`
`(XXXXXXXXIDHHHHAY,
`
`8°Ol48¢8
`
`
`
`fF wuewgoidAs9
`
`/(paziejiwiaq)
`
`uolnoesued|
`
`0¢8
`
`uoljesuedL
`
`wesgoidAsp
`
`
`
`228 prmrete,vonfvcs
`EdeSEISuolpunyuoidAuouy
`
`
`
`
`uonounyuoldAyouyaIweuAqg
`8T8fejequonoesuedy
`
`
`
`volunazyewloeq
`
`978
`
`9T8
`
`
`
`uolpesues|paseg
`
`
`
`adiuissyeusey
`
`
`
`uoljaesued)pasegFdiyd
`paesgaqu|
`
`9
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Jun. 25, 2015 Sheet 9 of 16
`
`US 2015/0178724 Al
`
`006
`
`ro
`
`(9)vaa
`
`pe
`
`:puebe7q
`
`Fe
`
`wesGoidA9
`
`6‘Old
`
`
`
`(apowjUaLUaYdi9ap)
`
`iNdNO=O
`
`yooqejeq
`
`vyhay
`
`gfey
`
`YO-eaIsnjoxy
`
`
`
`(apowjUsUUaydious)
`
`
`
`
`
`wuyyioblyuondAiosuyejeq=(8)vad
`
`ynduj=|
`
`
`
`
`
`wuyyoBlyuondAsuyejeq=(p)Wad
`
`10
`
`10
`
`

`

`Patent Application Publication
`
`Jun. 25,2015 Sheet 10 of 16
`
`US 2015/0178724 Al
`
`1000
`
`“a RECEIVE LUK ASSOCIATED WITH ONE OR
`
`MORE LIMITED-USE THRESHOLDS
`
`INITIATE TRANSACTION
`1004
`
`GENERATE TRANSACTION CRYPTOGRAM
`USING LUK
`1006
`
`SEND TRANSACTION CRYPTOGRAM TO
`CONDUCT TRANSACTION
`1008
`
`SET OF ONE OR MORE LIMITED-USE
`THRESHOLDS OF LUK EXCEEDED?
`1010
`
`SEND REPLENISHMENT REQUEST
`FOR NEW LUK
`1012
`
`FIG. 10
`
`11
`
`11
`
`

`

`Patent Application Publication
`
`Jun. 25,2015 Sheet 11 of 16
`
`US 2015/0178724 Al
`
`1100
`
`ENCRYPT ACCOUNT INFORMATION WITH
`A FIRST ENCRYPTION KEY TO GENERATE
`A SECOND ENCRYPTION KEY
`1102
`
`ENCRYPT KEY INDEX INFORMATION USING
`THE SECOND ENCRYPTION KEY TO GENERATE
`A LIMITED USE KEY (LUK)
`1104
`
`GENERATION OF A TRANSACTION CRYPTOGRAM
`
`ASSOCIATE THE LUK WITH A SET OF
`ONE OR MORE LIMITED-USE THRESHOLDS
`1106
`
`PROVIDE THE LUK AND KEY INDEX TO
`A PORTABLE COMMUNICATION DEVICE TO FACILITATE
`
`FIG. 11
`
`12
`
`12
`
`

`

`Patent Application Publication
`
`Jun. 25,2015 Sheet 12 of 16
`
`US 2015/0178724 Al
`
`Portable Communication Device 1201
`
`Memory 1202
`
`i Mobile Application }
`; Account
`Features 1220
`{3
`i? Parameters {
`ii
`Storage
`Enrollment 1232
`
`
`Payment Modes i ii>Mobile_— ii
`
`
`1222 Provisioning 1233|3} if Application }
`Verification
`:
`Lifecycle
`:
`!
`!
`comme
`
`
`Methods 1224||} LManagement 1238|| if 1246
`
`aa
`User Settings
`:
`Management 1236
`Key Index
`1226 Post Payment 1238|i}
`
`peeeeeenneeeeenneneeeeeeeeeeeeeeeeeeenn nn nee eee eee eee eens +.
`{ Cloud-Based Payment Logic 1250
`
`$
`
`Acct Parameters
`Thresholds 1252
`
`Transaction
`Verification Log
`1254
`
`Proximity Payment
`System
`Environment 1256
`
`Contactless
`PaymentLogic
`1258
`
`Contactless Interface 1208
`
`Device Hardware 1204
`
`Processor 1205
`
`User Interface 1206
`
`Display 1207
`
`Communication Subsystem 1209
`
`FIG. 12
`
`13
`
`13
`
`

`

`Patent Application Publication
`
`Jun. 25, 2015 Sheet 13 of 16
`
`US 2015/0178724 Al
`
`WADA
`
`pallian
`
`
`
`de]puovas
`
`
`
`(aze1sJUBIOSUeI)
`
`(a
`
`
`
`yeys}uaiosuel|)
`
`
`
`yndu|WADGD
`
`
`
`
`
`}UaSS|PIWUBpodDJUNODIYV
`
`wWoswl]
`
`Japeaeuodel
`
`
`
`JBPCOdSSOB/JOLYUODECOF}JBAO
`
`
`
`juasJuawAed
`
`
`
`(aesJUaIsSUeI])
`
`pazeluu|
`
`el‘Old
`
`ynoawil,
`
`
`
`punojsyoegAe}0}ApeayquasjuawAed
`
`
`pasinbaujasnaundVINYum
`
`
`ADCS(a}e1sJUalsued|)Joyagesoulpeara’!
`
`14
`
`pa|eysu|
`
`UYDUMSUd2IISYIJIMSUdVdJ9$
`
`
`
`
`‘yNOOWILyUdWNIYsSUl
`
`juawAedsja|asp4es
`
`
`
`
`
`punojgaj0}0}|SungdJawunsuo)eppvyjezsu|
`
`
`
`
`
`
`
`SUIUUNY10NuadoBANIVpepeojumog
`
`
`
`ysei>‘UMopynuSs
`
`‘Qso|D
`
`
`
`
`
`payzejasjuawAedUoU
`
`
`‘s8Ul}jasayI|
`
`SUO!DUNYJYWl422'R0JGOWWANVIAL
`
`
`
`14
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Jun. 25, 2015 Sheet 14 of 16
`
`US 2015/0178724 Al
`
`uado
`
`
`
`
`
`SUIUUNYJONdAILOVpapeojumog
`
`
`
`yses>‘UMOpPINYS
`
`“aso|D
`
`JGOWNO-SAVM1V
`
`ysel>‘UMOpINUsepoul
`
`‘9so|Djenue||NosAemjyv
`
`0}asueyuyspayjasyawnsuo?psc
`
`
`
`
`
`WAG)
`
`paljlian
`
`
`
`yndu|WADdD
`
`
`
`(aye3sJUDIDSUeL|)
`
`ynoaull|JO}adessow
`Japeas$$9]19e]U09&0}JaAO
`
`
`
`jUassjeluapes)JUNODDYJasndy}
`
`quasyuawAeddvuM
`
`WADGDAe|d03Apeay
`
`asinbeadpazyelqiul
`
`15
`
`psljeysu|
`
`
`
`de]puosas
`
`
`
`(aye3sJUDIDSUeL|)
`
`ynoawiyL
`
`euodel
`
`Japeal
`
`
`
`quasjuawAed
`
`
`
`(aye1sJUdISUeL|)
`
`pazijetu
`
`vtOld
`
`
`
`
`
`&ppvjye3Su|
`
`15
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Jun. 25, 2015 Sheet 15 of 16
`
`US 2015/0178724 Al
`
`
`
`SUIUUNYJON
`
`‘aso|D
`
`‘“uMopinus
`
`ysel9
`
`punoisyoeg
`
`
`
`payxdo|UNUaaIIS
`
`‘aso|D
`
`‘“uMopinus
`
`ysel9
`
`uado
`
`HOUaaIIS
`
`WADGD
`
`paijliaa
`
`
`
`indu|WADdD
`
`
`
`(a7e\sJUaIDSUeI])
`
`
`
`de]puosas
`
`
`
`(a7e\sJUaIDSUeI])
`
`inoawi
`
`L
`
`WADG5
`
`posinba
`
`ynNoswL
`
`Japeaseuodel
`
`
`eisu0}ABUEYD=sjpajasJaUINsUO?I|
`Jenuel|A|NosAemv
`Japeas$$3]}9e}]U0De&0}JAAO
`
`juassjeljUapa>yUuNODDYJoaSessoul
`
`
`opolu&ppv
`
`aAIVYpapeojumoq
`
`
`NOILVOISIHSAJDIAAG-NOHLIM4GOWNO-SAVMIV
`juasJUaWAegdVW4M
`
`
`
`Ae|d0}Apeay
`
`pezijeiiu|
`
`16
`
`pues
`
`payyjeysu|
`
`
`
`quasjuawAed
`
`
`
`(aye1sJUdISUe|)
`
`pezijellu|
`
`ST‘Old
`
`16
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Jun. 25, 2015 Sheet 16 of 16
`
`US 2015/0178724 Al
`
`TWNYALXA
`
`SLOT
`
`YALNIdd
`
`JOVINSINISIGdaXldauVvOgAIy1YOdTIdAS
`
`
`
`
`
`cOETFOOT
`809T909T9TST
`
`YOSSjDOU"dAYOINAWYATIOYLNOD
`
`
`WuLNdDWALSASO/I
`
`
`Oc9TccolvI9OL
`
`AW1dSI0
`
`ddldVdVv
`
`clot
`
`17
`
`9T“Old
`
`YOLINOW
`
`OTST
`
`17
`
`
`

`

`US 2015/0178724 Al
`
`Jun. 25, 2015
`
`LIMITED-USE KEYS AND CRYPTOGRAMS
`
`CROSS-REFERENCES TO RELATED
`APPLICATIONS
`
`[0001] This application claims the benefit of priority to
`USS. Provisional Application No. 61/918,643, filed on Dec.
`19, 2013, U.S. Provisional Application No. 61/941,227, filed
`on Feb. 18, 2014, U.S. Provisional Application No. 61/982,
`169,filed on Apr. 21, 2014, and U.S. Provisional Application
`No. 61/983,635, filed on Apr. 24, 2014, which are all herein
`incorporated by reference in their entirety for all purposes.
`
`[0002] This applicationis related to commonly owned U.S.
`Non-Provisional Application (Atty Dkt. No. 79900-923273)
`entitled “Cloud-Based Transactions Methods and Systems,”
`being filed concurrently on Dec. 19, 2014, the contents of
`which is hereby incorporated by reference in its entirety for
`all purposes.
`
`BACKGROUND
`
`[0003] Advancesin the capabilities of portable communi-
`cation devices have allowed portable communication devices
`such as smart phones to be used as payment instruments to
`conduct contactless transactions. For example, a portable
`communication device can be placed in proximity to an
`access device such as a point-of-sale (POS) terminal to trans-
`fer account information from the portable communication
`device to the access device to conducta transaction. To pro-
`vide a secure operating environmentto securely store account
`information on a portable communication device, a secure
`element such as subscriber identity module (SIM)card, spe-
`cialized integrated chip embeddedinto the portable commu-
`nication device, or specialized component provided asafter-
`market solution is used. At the time of a transaction, the
`secure element communicates directly with a contactless
`interface (e.g., a near-field communication (NFC) trans-
`ceiver) of the portable communication device to pass pay-
`ment data to a contactless reader of the access device. A
`secure element is considered secure because account infor-
`
`mationis stored in tamper-resistant hardware, which protects
`the account information from malware or viruses that may
`have infected the operating system or an application running
`on the portable communication device.
`
`[0004] However, a secure elementused in a portable com-
`munication device is typically not under the control of a
`financial institution, but is instead under the control of a
`mobile network operator (MNO). Asa result, an issuer and/or
`payment processor may not have direct access to a secure
`elementto provision it with account credentials and payment
`functionalities. In order to gain access to a secure element, an
`issuer and/or payment processor may haveto establish com-
`mercial agreements and technical connectivity with the party
`controlling the secure element to perform over-the-air (OTA)
`personalization of the secure element. This is both a cumber-
`some and complex process. Furthermore, incorporating a
`secure element adds to the manufacturing cost of the portable
`communication device, and increasesthe costofthe finished
`portable communication device.
`
`[0005] Thus, in some cases, it would be desirable to use a
`portable communication device that does not have a secure
`element to make payments. Or, ifthe portable communication
`device does have a secure element, it may be desirable not to
`
`rely on the use of the secure element. However, because a
`secure element is not used, transaction security will be a
`concern.
`
`[0006] Embodiments ofthe present invention address these
`and other problems individually and collectively. Specifi-
`cally, embodiments of the invention address the problem of
`security concerns with conducting paymenttransactions with
`amobile communication device that does not have or does not
`
`rely on a secure element.
`
`BRIEF SUMMARY
`
`[0007] Embodiments of the present invention provide tech-
`niques for enhancing the security of a communication device
`(e.g., a portable communication device) when conducting a
`transaction using the communication device. The techniques
`described herein can be used with a communication device
`that may or may not have a secure element, because the
`techniques do not require the use of a secure element to
`safeguard account credentials. Embodiments ofthe invention
`instead utilize limited-use account parameters that may have
`a limitedlifespan, and once expired, may no longer be used to
`conduct a transaction until the limited-use account param-
`eters are replenished from the cloud (e.g., a remote com-
`puter). Hence, transactions conducted using the techniques
`described herein maybereferred to as “cloud-basedtransac-
`tions.”
`
`[0008] According to some embodiments, a method for
`enhancing the security of a communication device when con-
`ducting a transaction using the communication device may
`include receiving, from a remote computer, a limited-use key
`(LUK)thatis associated with a set of one or more limited-use
`thresholdsthat limits usage ofthe LUK. The method mayalso
`include generating, by the communication device, a transac-
`tion cryptogram using the LUK,and sending, by the commu-
`nication device to an access device, a token instead ofa real
`account identifier and the transaction cryptogram to conduct
`the transaction. The transaction can be authorized based on at
`
`least whether usage ofthe LUKhasexceededthe set ofone or
`more limited-use thresholds.
`
`[0009] According to some embodiments, a communication
`device may include a processor; and a memory coupledto the
`processor and storing a mobile application that performs
`operations for enhancing security of the communication
`device when conducting transactions using the communica-
`tion device. The operations may include receiving a limited-
`use key (LUK)that is associated with a set of one or more
`limited-use thresholdsthat limits usage of the LUK, generat-
`ing a transaction cryptogram using the LUK,and sending a
`token instead of a real accountidentifier and the transaction
`
`cryptogram to conduct the transaction. The transaction may
`be authorized basedon at least whether usage of the LUK has
`exceededthe set of one or more limited-use thresholds.
`
`[0010] According to some embodiments, a method for
`enhancing the security of a communication device when con-
`ducting a transaction using the communication device may
`include encrypting, by a computer, account information with
`a first encryption key to generate a second encryption key, and
`encrypting key index information using the second key to
`generate a limited-use key (LUK), wherethe key index infor-
`mation includes a key index having information pertaining to
`generation ofthe LUK. The method mayalso include provid-
`ing the LUKandthe key index to the communication device
`to facilitate generation ofa transaction cryptogram for a trans-
`
`18
`
`18
`
`

`

`US 2015/0178724 Al
`
`Jun. 25, 2015
`
`action conducted using the communication device. The trans-
`action can be authorized based on the LUKandthe transac-
`
`tion cryptogram.
`[0011] According to some embodiments, a computer for
`enhancing the security of a communication device when con-
`ducting a transaction using the communication device may
`include a processor, and a memory storing computer readable
`code, which when executes by the processor, causes the com-
`puter to encrypt account information with a first encryption
`key to generate a second encryption key, encrypting key index
`information using the second key to generate a limited-use
`key (LUK), and provide the LUK and the key index to the
`communication device to facilitate generation of a transac-
`tion cryptogram for a transaction conducted using the com-
`munication device. The key index information may include a
`key index having information pertaining to generation of the
`LUK.Thetransaction can be authorized based on the LUK
`and the transaction cryptogram.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG.1 illustrates a block diagram of an example of
`[0012]
`acloud-basedtransaction system, according to some embodi-
`ments.
`
`FIG.2 illustrates a communication flow diagram of
`[0013]
`an example of an enrollment and provisioning process,
`according to some embodiments.
`[0014]
`FIG.3 illustrates a communication flow diagram of
`an example of executing an integrated chip based transaction,
`according to some embodiments.
`[0015]
`FIG.4 illustrates a communication flow diagram of
`an example of executing a magneticstripe basedtransaction,
`according to some embodiments.
`[0016]
`FIG. 5 illustrates an example ofa transaction veri-
`fication log, according to some embodiments.
`[0017]
`FIG. 6 illustrates a communication flow diagram of
`an example of a post-paymentverification process, according
`to some embodiments.
`
`FIG. 7 illustrates a communication flow diagram of
`[0018]
`an example of an account parameters replenishmentprocess,
`according to some embodiments.
`[0019]
`FIG.8 illustrates an example of a process for gen-
`erating a transaction cryptogram, according to some embodi-
`ments.
`
`FIG.9 illustrates an example of an encryption func-
`[0020]
`tion, according to some embodiments.
`[0021]
`FIG. 10 illustrates a flow diagram of an example of
`a method for enhancing the security of a portable communi-
`cation device, according to some embodiments.
`[0022]
`FIG.11 illustrates a flow diagram of an example of
`another method for enhancing the security of a portable com-
`munication device, according to some embodiments.
`[0023]
`FIG. 12 illustrates a block diagram of an example of
`aportable communication device, according to some embodi-
`ments.
`
`FIG. 13 illustrates a state diagram of an example of
`[0024]
`a mobile application in manual mode, according to some
`embodiments.
`
`FIG. 14 illustrates a state diagram of an example of
`[0025]
`a mobile application in always-on mode, according to some
`embodiments.
`
`FIG. 15 illustrates a state diagram of an example of
`[0026]
`a mobile application in always-on modewith on-deviceveri-
`fication, according to some embodiments.
`
`FIG. 16 illustrates a block diagram of an example of
`[0027]
`a computer system, according to some embodiments.
`
`DETAILED DESCRIPTION
`
`[0028] Embodiments of the present invention provide for
`methods, devices, and systems for cloud-based transactions
`that can be performed by a communication devices with or
`without a secure element. The techniques described herein
`can utilize card emulation technology(e.g., Host Card Emu-
`lation (HCE), etc.) to emulate a smartcard on a communica-
`tion device(e.g., a portable communication device) to allow a
`mobile application running on the portable communication
`device to conduct contactless transactions. In the card emu-
`
`lation environment, a mobile application can access the con-
`tactless interface (e.g., a near-field communication (NFC)
`transceiver) of the portable communication device via the
`operating system (OS)ofthe portable communication device
`without involving a secure element. As compared to secure
`element
`implementations,
`the card emulation approach
`reduces the technical and commercial complexities for issu-
`ers and/or payment processors, because issuers and/or pay-
`ment processors can provision account credentials and pay-
`ment functionalities to a mobile application on a portable
`communication device without having to obtain access to a
`secure element through a mobile network operator.
`
`[0029] By removingthe control of payment functionalities
`and accountcredentials from the confines ofa secure element,
`the tamper-resistant hardware based security provided by a
`secure element can no longer be relied on to safeguard
`account information. Without the requirement that a secure
`element be present, account credentials may be stored in a
`memory ofthe portable communication device thatis not part
`of a secure element, such as the general memory ofthe por-
`table communication device. As such, the account credentials
`maybe susceptible to access by malwareorviruses that may
`have infected an application or operating system of the por-
`table communication device.
`
`To enhance the security of a portable communica-
`[0030]
`tion device when conducting transactions withoututilizing a
`secure element, instead of using stagnant account credentials
`stored on a portable communication device which may be
`valid for the lifetime of an account, the cloud-based tech-
`niques described herein provision a portable communication
`device with limited-use account parameters that have a lim-
`ited usage or lifespan. Whenthe limited usageor lifespan of
`the limited-use account parameters is exhausted, the same set
`of limited-use account parameters may no longer be used to
`conductfurther transactions. In order to conductfurther trans-
`actions using the portable communication device, new lim-
`ited-use account parameters are replenished to the portable
`communication device. The limited-use account parameters
`provided to the portable communication device can be
`renewedor replenished from the network(also be referred to
`as the “cloud”) repeatedly during the lifetime of an account.
`By managing the delivery and lifecycle of the limited-use
`account parameters between a set of network based capabili-
`ties and the portable communication device, the compromise
`of mobile application software and/or account credentials
`stored on a portable communication device becomes only a
`limited security risk, because stolen limited-use account
`parameters can at most be used for only a small number of
`transactions or limited monetary amount.
`
`19
`
`19
`
`

`

`US 2015/0178724 Al
`
`Jun. 25, 2015
`
`Prior to discussing the details of some embodiments
`[0031]
`of the present invention, description of some terms may be
`helpful in understanding the various embodiments.
`[0032] A “communication device” may be a device that
`includes one or more electronic components (e.g., an inte-
`grated chip) that can communicate with another device. A
`“portable communication device” be a communication
`device that can be transported and operated by a user. A
`portable communication device may provide remote commu-
`nication capabilities to a network. The portable communica-
`tion device can be configured to transmit and receive data or
`communications to and from other devices. A portable com-
`munication device maybe in the form ofa mobile device such
`as a mobile phone (e.g., smart phone, cellular phone,etc.),
`tablets, portable media player, personal digital assistant
`devices (PDAs), wearable computing device (e.g., watch),
`electronic reader device, etc., or in the form of a card (e.g.,
`smart card) or a fob, etc. Examples of portable communica-
`tion devices may also include portable computing devices
`(e.g., laptops, netbooks, ultrabooks, etc.).
`[0033] A “server computer’ may include a powerful com-
`puter or cluster of computers. For example, the server com-
`puter can be a large mainframe, a minicomputercluster, or a
`group of servers functioning as a unit. In one example, the
`server computer maybe a database server coupled to a Web
`server. The server computer may be coupledto a database and
`mayinclude any hardware, software, other logic, or combi-
`nation ofthe preceding for servicing the requests from one or
`more client computers. The server computer may comprise
`one or more computational apparatuses and may use any of a
`variety of computing structures, arrangements, and compila-
`tions for servicing the requests from one or more client com-
`puters.
`[0034] An “issuer” maytypically refer to a business entity
`(e.g., a bank) that maintains an account for a user that is
`associated with a portable communication device such as an
`account enrolled in a mobile application installed on a por-
`table communication device. An issuer may also issue
`account parameters associated with the account to a portable
`communication device. An issuer may be associated with a
`host system that performs someorall of the functions of the
`issuer on behalfof the issuer.
`
`associated with, a portable communication device. In some
`embodiments, where an access device may comprise a POS
`terminal, any suitable POS terminal may be used and may
`include a reader, a processor, and a computer-readable
`medium. A reader may include any suitable contact or con-
`tactless mode of operation. For example, exemplary card
`readers can include radio frequency (RF) antennas, optical
`scamners, bar code readers, or magneticstripe readersto inter-
`act with a portable communication device.
`[0038] An “authorization request message” may be anelec-
`tronic message that is sent to request authorization for a
`transaction. The authorization request message can be sent to
`a payment processing network and/or an issuer of a payment
`card. An authorization request message according to some
`embodiments may comply with ISO 8583, which is a stan-
`dard for systems that exchange electronic transaction infor-
`mation associated with a payment made by a user using a
`payment device or payment account. The authorization
`request message mayinclude informationthat can be used to
`identify an account. An authorization request message may
`also comprise additional data elements such as one or more of
`a service code, an expiration date, etc. An authorization
`request message may also comprise transaction information,
`such as any information associated with a currenttransaction,
`such as the transaction amount, merchantidentifier, merchant
`location, etc., as well as any other information that may be
`utilized in determining whether to identify and/or authorize a
`transaction. The authorization request message may also
`include other information such as informationthat identifies
`the access device that generated the authorization request
`message, information about the location ofthe access device,
`etc.
`
`[0039] An “authorization response message” may be an
`electronic messagereply to an authorization request message.
`The authorization response message can be generated by an
`issuing financial institution or a paymentprocessing network.
`The authorization response message may include, by way of
`example only, one or moreof the following status indicators:
`Approval—transaction was approved; Decline—transaction
`was not approved; or Call Center—response pending more
`information, merchant must call the toll-free authorization
`phone number. The authorization response message may also
`include an authorization code, which may be a code that a
`credit card issuing bank returns in response to an authoriza-
`tion request message in an electronic message(either directly
`or through the payment processing network) to the merchant
`computerthat indicates approvalof the transaction. The code
`mayserve as proofof authorization. As noted above, in some
`embodiments, a payment processing network may generate
`or forward the authorization response message to the mer-
`chant.
`
`[0035] A “merchant” may typically be an entity that
`engages in transactions and can sell goods or services, or
`provide access to goods or services.
`[0036] An “acquirer” may typically be a business entity
`(e.g., acommercial bank)that has a business relationship with
`a particular merchantor other entity. Someentities can per-
`form both issuer and acquirer functions. Some embodiments
`may encompass such single entity issuer-acquirers.
`[0037] An “access device” may be any suitable device for
`[0040] The term “authentication” and its derivatives may
`communicating with a merchant computer or payment pro-
`refer to a process by which the credential of an endpoint
`cessing network, andfor interacting with a paymentdevice, a
`(including but not limited to applications, people, devices,
`user computer apparatus, and/or a user mobile device. An
`processes, and systems) can be verified to ensure that the
`access device may generally be located in any suitable loca-
`endpoint is who they are declaredto be.
`tion, such as at the location of a merchant. An access device
`[0041] The term “verification” andits derivatives may refer
`may be in any suitable form. Some examples of access
`to a process thatutilizes information to determine whether an
`devices include POS devices, cellular phones, PDAs, per-
`underlying subjectis valid underagiven set of circumstances.
`sonal computers (PCs), tablet PCs, hand-held specialized
`Verification may include any comparison of information to
`readers, set-top boxes, electronic cash registers (ECRs), auto-
`ensure some data or information is correct, valid, accurate,
`matedteller machines (ATMs),virtual cash registers (VCRs),
`legitimate, and/or in good standing.
`kiosks, security systems, access systems, Websites, and the
`like. An access device may use any suitable contact or con-
`[0042] A “token” may include a substitute identifier for
`tactless mode of operation to send or receive data from, or
`some information. For example, a payment
`token may
`
`20
`
`20
`
`

`

`US 2015/0178724 Al
`
`Jun. 25, 2015
`
`underlying information with a valid key, and comparing the
`result to the received cryptogram.
`[0047] A “limited-use threshold” mayrefer to a condition
`that limits the usage of a piece of information. A limited-use
`threshold may be exceeded or exhausted whenthe underlying
`condition is met. For example, a limited-use threshold may
`include a time-to-live that indicates an amount of time for
`
`includean identifier for a payment accountthat is a substitute
`for an accountidentifier, such as a primary account number
`(PAN). For instance, a token may include a series of alpha-
`numeric characters that may be used as a substitute for an
`original accountidentifier. For example, a token “4900 0000
`0000 0001” may be used in place of a PAN “4147 0900 0000
`1234.” In some embodiments, a token may be “format pre-
`serving” and may have a numeric format that conformsto the
`whichapiece of information is valid, and once that amount of
`account identifiers used in existing payment processing net-
`time has elapsed, the limited-use threshold is exceeded or
`works(e.g., ISO 8583 financial transaction message format).
`exhausted, and the piece of information may becomeinvalid
`In some embodiments, a token may be usedin place of a PAN
`and mayno longer be used. As another example, a limited-use
`