US 20100211504A1
`
`(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2010/0211504 A1
`(43) Pub. Date: Aug. 19, 2010
`
`Aabye et a1.
`
`(54) METHOD OF PERFORMING
`TRANSACTIONS WITH CONTACTLESS
`PAYMENT DEVICES USING PRE-TAP AND
`TWO-TAP OPERATIONS
`
`(76)
`
`Inventors:
`
`Christian Aabye, Morgan Hill, CA
`(US); Hao Ngo, San Jose, CA (US);
`David William Wilson, London
`(GB)
`
`Correspondence Address:
`TOWNSEND AND TOWNSEND CREW LLP
`TWO EMBARCADERO CENTER, 8TH FLOOR
`SAN FRANCISCO, CA 94111 (US)
`
`(21)
`
`Appl. No.:
`
`12/563,444
`
`(22)
`
`Filed:
`
`Sep. 21, 2009
`
`Related US. Application Data
`
`(60) Provisional application No. 61/099,060, filed on Sep.
`22, 2008.
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`G06Q 20/00
`H04B 5/00
`
`(2006.01)
`(2006.01)
`
`(52) U.S.Cl. .......................................... 705/44,455/41.1
`
`(57)
`
`ABSTRACT
`
`A system, apparatus, and method for processing payment
`transactions that are conducted using a mobile payment
`device that includes a contactlcss element, such as an inte-
`grated circuit chip. The invention enables one or more of the
`operations of activation of a payment application, transfer of
`transaction data, updating of account records, setting or re—
`setting of a payment application counter or register, or trans-
`fer or processing of a script, command, or instruction, with
`these functions being performed with minimal impact on a
`consumer. This is accomplished by introducing a pre-tap
`and/or two-tap operation prior to, or as part of, the transaction
`flow.
`
`
`Consumer
`
`
`
`Payment Device
`
`20
`
`
`
`Payment Device
`Reader/PCS
`Terminal
`22
`
`,.
`
`/
`
`/
`
`Merchant
`Data.
`Processlng
`System
`
`Acquirer
`30
`
`
`
`
`
`\
`
`\
`
`
`
`Payment
`processing __
`Network
`34
`
`
`
`Issuer
`33
`
`
`
`/ Merchant/
`| Database
`
`28
`\
`
`\
`
`Account
`Database
`36
`
`
`\
`
`1
`
`/ Consumer/
`t DatabaseI
`\
`40
`\
`
`Google LLC v. RFCyber Corp. / Page 1 of 18
`
`6006-1034
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 1 of 18
`
`

`

`Patent Application Publication
`
`Aug. 19, 2010 Sheet 1 0f6
`
`US 2010/0211504 A1
`
`/9V'0939mm
`
`BE3800
`
`533
`
`mm
`
`EmEEQ
`
`9.6309;
`
`{262
`
`«m
`
`Ezooo<K\
`
`3338
`
`
`
`mm
`
`5:391
`
`E2222
`
`LGESMCOO
`
`
`
`magmaEmE>mm
`
`om
`
`9:3on
`
`Ema
`
`
`
`
`
`8300.n_EmEbmm
`
`mOnEmnmom
`
`E2055.
`
`333mm.
`
`mm
`
`V2:9;
`
`E9w>wESEEH
`
`0NNN
`
`.lOC.lebV.CFRv.CLLbg0OG
`
`43maooG
`81fO2egaPla.
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 2 of 18
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`A
`
`010
`
`2
`
`S
`
`99$3x5362we.J533mEmwouEn.
`
`
`
`
`mumtBEW520:39“.EoEwm.$963.80
`
`
`
`
`
` way>o@5600.5S.{95528.260
`
`«3
`
`
`
`
`
`Emuw‘am5250
`
`
`_.mo_>mo9502
`
`
`our5858382522
`
`2:
`
`2v3
`
`mmmg
`
`
`
`tEma2:.G%930mmAmvcozmoiax‘
`
`
`
`
`
`U2:av“.
`
`8300o0RingOm_o:oIQftmnmmm
`
`
`Shaw»...mmEEwmEEOEE\\\£3£8,LWe6629:8.won”.0&2ErboEms.
`N3.Emem.nE.
`2933,02«3
`
`
`
`
`
` 1mmAGh4l0uumm9:_onNuc0rwle1oF«S.w.0.l'lLlllc2F
`
`48310cl4oG3
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 3 of 18
`
`
`
`
`
`

`

`Patent Application Publication
`
`Aug. 19, 2010 Sheet 3 0f 6
`
`US 2010/0211504 A1
`
`Antenna
`
`318
`
`Processor
`304
`
`Display
`306
`
`
`Data Input/Output
`308
`
`Communications
`310
`
`316
`
`Applications/Data Storage/
`Memory
`312
`
`Contactless Element
`
`Interface
`314
`
`Contactless Element
`
`Secure Memory/N FC Data Transfer
`
`302
`
`Figure 3
`
`
`
`
`
`Google LLC v. RFCyber Corp. / Page 4 of 18
`
`GOOG-1034
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 4 of 18
`
`

`

`Patent Application Publication
`
`Aug. 19, 2010 Sheet 4 0f 6
`
`US 2010/0211504 A1
`
`
`
`Present Payment Device to
`Device Reader/PCS
`Terminal
`402
`
`Activate Payment Application
`Resident on Device
`404
`
`lssuer Update (Data.
`Script, etc.) Desired?
`
`412
`
`Yes
`I
`
`Request User to Present
`Payment Device to Device
`Reader/P08 Terminal to
`Receive Update or Prepare
`to Send Update Over—the—Air
`to Payment Device
`414
`
`
`
`
`
`
`
`
`
` Figure 4
`420
`
`
`
`
`
`
`
`No
`
`4:.oo
`
`*4,—
`Device Reader/P08
`Terminal Receives issuer
`Update or Payment Device
`Provided Update Over—the—
`Air (in either case with Issuer
`generated cryptogram if
`desired)
`416
`
`_¢_
`Payment Device Receives
`Update - Update to
`Transaction Data Stored in
`Payment Device and/or
`Function Executed on
`Payment Device
`418
`
`End
`
`Determine if interaction With
`Payment Device or
`Consumer is Required Prior
`to Payment Transaction (see
`Figure 5); If Needed, Perform
`Interaction
`406
`
`
`
`
`
`
`Present Payment Device to
`Reader/P08 Terminal to
`Perform Payment
`Transaction
`408
`
`Process Payment
`Transaction
`41 O
`
`
`
`6006-1034
`Google LLC v. RFCyber Corp. / Page 5 of 18
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 5 of 18
`
`

`

`Patent Application Publication
`
`Aug. 19, 2010 Sheet 5 of 6
`
`US 2010/0211504 A1
`
`//\
`.
`
`,
`
`@entAppliw YES
`Requested Consumer
`
`Action?
`502
`
`Setlndicatorto Show
`
`Consumer Interaction
`
`Required
`503
`
`/
`
`
`
`
`
`1
`
`—>|
`
`| | l | | I |
`
`
`
`\
`Issuer Requested \
`Consumer Action?
`504
`\
`
`Yes
`
`Set Indicator to Show
`
`Consumer Interaction
`Required
`505
`
`
`No
`
`Figure 5
`
`00
`
`’
`
`
`
`_”~" I
`/IceReade~P\
`“8
`32:;"udisssiizfsgi
`Terminal Requested
`_
`
`Consumer~3th Regan?red
`506
`
`
`
` /
`
`'—>|
`
`__
`
`| | | | | | | | | | | I l l 1
`
`
`
` Go To Stage 408 of Figure 4
`509
`
`
`
`
`
`Perform Interaction/Request
`Consumer Action
`<— ______ __i
`
`510
`
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 6 of 18
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 6 of 18
`
`

`

`Patent Application Publication
`
`Aug. 19, 2010 Sheet 6 0f 6
`
`US 2010/0211504 A1
`
`
`
`I/O
`Controller
`660
`
`
`Central
`Processor
`690
`
`Printer
`610
`
`
`
`System
`Bus
`/ 600
`I
`’
`
`
`
`
`Display
`Adaptor
`650
`
`‘
`Serggort
`
`Keyégczfrd
`
`.
`.
`Ext-:13(IJDISK
`
`External
`Interface
`680
`
`Monitor
`640
`
`Figure 6
`
`
`
`
`
`Google LLC v. RFCyber Corp. / Page 7 of 18
`
`GOOG-1034
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 7 of 18
`
`

`

`US 2010/0211504 A1
`
`Aug. 19, 2010
`
`VIETI-IOD OF PERFORMING
`TRANSACTIONS WITH CONTACTLESS
`PAYMENT DEVICES USING PRE-TAP AND
`TWO-TAP OPERATIONS
`
`
`CROSS REFJRENCE IO RELATJD
`APPLICATIONS
`
`
`
`[0001] This application claims priority from US. Provi-
`sional Patent Application No. 61/099,060, enti led “Contact-
`less Phone With Secret Data”, filed Sep. 22, 2008, the con-
`tents of which is hereby incorporated in its entirety by
`reference for all purposes.
`
`BACKGROUND
`
`[0002] Embodiments of the present invention are directed
`to systems, apparatuses and methods for perfomiing payment
`transactions, and more specifically, to a system and associ-
`ated apparatus and method for performing payment transac-
`tions using a payment device that includes a contactless ele-
`ment (such as an integrated circuit chip embedded in a
`wireless mobile device) by interacting with a device reader or
`point of sale terminal using a pre—tap or two—tap process,
`either individually or in combination. Embodiments of the
`invention may be used to conduct payment transactions, per-
`form Issuer updates of data stored in a payment device, or
`enable the configuration of payment device functions or
`operations, among other possible uses.
`[0003] Consumer payment devices are used by millions of
`people worldwide to facilitate various types of commercial
`transactions. In a typical transaction involving the purchase of
`a product or service at a merchant location, the payment
`device is presented at a point of sale tenninal (“POS tenni-
`nal”) located at a merchant’s place of business. The POS
`terminal may be a card reader or similar device that is capable
`of accessing data stored on the payment device, where this
`data may include identification or authentication data, for
`example. Data read from the payment device is provided to
`the merchant’s transaction processing system and then to the
`Acquirer, which is typically a bank or other institution that
`manages the merchant’s account. The data provided to the
`Acquirer may then be provided to a payment processing
`network that is in communication with data processors that
`process the transaction data to determine if the transaction
`should be authorized by the network, and assist in the clear-
`ance and accoruit settlement functions for completed trans-
`actions. The authorization decision and clearance and settle-
`ment portions of
`the
`transaction may also involve
`communication and/or data transfer between the payment
`processing network and the bank or institution that issued the
`payment device to the consumer (known as the Issuer).
`[0004] Although a consumer payment device may be a
`credit card or debit card, it may also take the form ofa “smart”
`card or chip. A smart card is generally defined as a pocket-
`sized card (or other form of portable payment device) that is
`embedded with a microprocessor and one or more memory
`chips, or is embedded with one or more memory chips with
`non-programmable logic. The microprocessor type card typi-
`cally can implement certain data processing functions, such
`as to add, delete, or otherwise manipulate information stored
`in a memory location on the card. In contrast, the memory
`chip type card (for example, a prepaid phone card) can typi-
`cally only act as a file to hold data that is manipulated by a
`card reading device to perform a pre-defined operation, such
`
`as debiting a charge from a pre-established balance stored in
`the memory. Smart cards, unlike magnetic stripe cards (such
`as standard credit cards), can implement a variety offunctions
`and contain a variety of types of information on the card.
`Therefore, in some applications they may not require access
`to a remote database for the purpose of authenticating a con-
`sumer or creating a record at the time ofa transaction. A smart
`chip is a semiconductor device that is capable of performing
`most, if not all, of the functions of a smart card, but may be
`embedded in another device.
`
`Smart cards or chips come in two general varieties;
`[0005]
`the contact type and the contactless type. A contact type smart
`card or chip is one that includes a physical element (e.g., a
`magnetic stripe, contact pad, etc.) that enables access to the
`data and functional capabilities ofthe card, typically via some
`form of terminal or card reader. In contrast, a contactless
`smart card or chip is a device that incorporates a means of
`communicating with a card reader or point of sale terminal
`without the need for direct physical contact. Thus, such
`devices may effectively be “swiped” (i.c., enabled to be read
`by, or otherwise exchange data with another device) by pass-
`ing them close to a card reader or terminal. Contactless cards
`or chips typically connnunicate with a device reader or ter—
`minal using RF (radio—frequency) technology, wherein prox—
`imity to the reader or terminal enables data transfer between
`the card or chip and the reader or terminal. Contactless cards
`have found uses in banking and other applications, where they
`have the advantage of not requiring removal from a user’s
`wallet or pocket in order to participate in a transaction. A
`contactless card or chip may be embedded in, or otherwise
`incorporated into, a mobile device such as a mobile phone or
`personal digital assistant (PDA). Further, because of the
`growing interest in such cards, standards have been devel-
`oped that govern the operation and interfaces for contactless
`smart cards, such as the ISO 14443 standard.
`[0006]
`In a typical payment transaction, data is sent from a
`point of sale terminal to the Issuer to authenticate a consumer
`and obtain authorization for the transaction. As part of the
`authentication or authorization processes, the data may be
`accessed or processed by other elements of the transaction
`processing system (e.g., the merchant’s Acquirer or a pay-
`ment processor that is part of a payment processing network).
`Note that in some cases, authorization for the transaction may
`be obtained without connecting to the Issuer; this may be
`permitted by Issuer configured risk management parameters
`that have been set on the consumer’s payment application or
`payment device. If the proposed transaction is authorized,
`then the consumer may provide other infomiation to the iner-
`chant as part ofcompleting the transaction. The Issuer or data
`processor may also send data back to the consumer. Such data
`may include an update to records ofthe transactions for which
`the payment device has been used, or to a current balance of
`an account associated with the device.
`
`[0007] An Issuer or payment processor may also desire to
`configure (or re—configure) a function, operation, or setting of
`a payment application that is installed on a payment device,
`such as a mobile device that includes a contactless element.
`Such an action may include resetting a counter to enable or
`disable a function, configuring a function or capability of the
`payment application or payment device, or initiating the
`execution ofa script or application that operates on the pay-
`ment application, payment device, or transaction data, for
`example.
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 8 of 18
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 8 of 18
`
`

`

`US 2010/0211504 A1
`
`Aug. 19, 2010
`
`[0008] An issue for any payment transaction system or
`process is case ofuse by a consumer, as this leads to increased
`adoption by the consumer and usage of the system, thereby
`generating more revenue for Merchants and the entities
`involved in authorizing and processing payment transactions.
`A consumer typically desires that a transaction be executed
`with a minimum amount of delay and with minimal burden
`being placed on the consumer. In addition, if required for a
`transaction, a consumer desires to be able to locate and acti-
`vate a payment application on a payment device With rela-
`tively little effort in order to initiate the transaction. The
`concern for minimizing the burden on a consumer is at least
`partly the result of recognizing that a consumer typically does
`not want to be inconvenienced by difficulties in attempting to
`activate a payment application or by having to wait additional
`time While the transaction processing system carries out data
`processing or other ftmctions. Thus, in order to satisfy the
`desires and expectations of consumers, most payment trans-
`action processing systems are designed to require minimal
`interaction on the part of consumers.
`[0009]
`For example, in the ease ofa transaction that uses a
`contactless element, a device reader or point of sale terminal
`is typically expected to be in communication With the con-
`tactless element for only a short period of time; for example,
`enough time for it to be recognized by the reader and to
`provide data needed to initiate or conduct a portion of the
`transaction. However, this means that the consumer payment
`device and device reader or point of sale terminal may not be
`in communication long enough for an Issuer or payment
`processor to process the transaction data and provide the
`processed data to the device reader for transfer to the con-
`sumer device. It may also mean that the payment device and
`device reader or terminal are not in communication When the
`Issuer or payment processor desires to perform an update to
`cause a command or ftmction to be executed on the payment
`device, such as for resetting a counter, configuring a function
`of the payment application or payment device, etc.
`[0010] Another issue for a payment transaction system or
`process in which data or a configuration command or instruc—
`tion is provided by an Issuer or payment processor involves
`ensuring that the received data, command, or instruction is
`from an authorized party. and that the payment device prop-
`erly associates the received information with the transaction
`or application to which the information applies.
`[0011] What is desired is a system, apparatus and method
`for enabling an Is suer or payment processor to provide a
`consumer payment device containing a contactless element
`with transaction data or to initiate an update process, Without
`requiring that a consumer maintain communication between
`the payment device and a device reader or terminal for an
`extended period of time. It is also desired to have a system,
`apparatus and method for enabling the automatic launch of a
`payment application when a payment device is presented to a
`device reader or point of sale terminal, Where this may include
`a determination of whether consumer interaction is required
`
`before a transaction can be completed. Embodiments of the
`invention address these problems and other problems indi-
`vidually and collectively.
`
`
`
`BRIEF SUMMARY
`
`[0012] Embodiments of the present invention are directed
`to a system, apparatus, and method for using a contactless
`element (such as a contactless smart chip) as part of a pay-
`ment transaction. Specifically, embodiments of the present
`
`invention are directed to facilitating the transfer oftransaction
`data or transaction records to a memory that is part of the
`payment device. Embodiments of the present invention may
`also be used to provide a command or instruction (sometimes
`referred to as a “script”) to the device reader for execution by
`the reader, or to the payment device for execution by a pay-
`ment application installed on the device. Such a command or
`instruction may be used to re-set or configure a function ofthe
`payment application or of the payment device. The inventive
`system, apparatus and method may be implemented using a
`contactless smart chip and a Wireless data transfer element
`(e.g., an element having a near field communications (NFC)
`capability or similar short range communications technology,
`etc.) embedded Within a mobile Wireless device. The mobile
`device may be a mobile phone, PDA, MP3 player or the like.
`[0013]
`To ensure that any data, commands, or instructions
`received by the payment device are from an authenticated
`source and that the received information can be associated
`With the proper transaction data stored in the payment device,
`embodiments of the present invention may include use of a
`cryptogram or other form of security control or identification
`data. For example, in order to ensure that data provided during
`an Issuer update process is from an authentic Issuer and that
`the received data is properly associated With the correct trans—
`action, the payment device may generate a cryptogram and
`provide that cryptogram to an Issuer as part of a transaction.
`The Issuer may generate a second cryptogram (either based
`on the initial cryptogram from the payment device, or by an
`independent process) and provide the second cryptogram to
`the payment device as part of any data, command, or instruc-
`tion sent to the payment device as part of an Issuer update
`process. The payment device can then use the cryptogram
`received from the Issuer (along with the initial cryptogram
`sent to the Issuer, if necessary) to confirm the authenticity of
`the Issuer and to properly associate the received data with the
`transaction record to which it applies, Where the record is
`stored in the payment device. The cryptogram(s) may be
`generated by any suitable method and may be stored in a
`memory in the payment device and if desired, erased after
`completion of a transaction.
`[0014] Embodiments of the invention permit an Issuer or
`payment processor to provide transaction data and/or trans-
`action records to a payment device that includes a contactless
`element in a manner that minimizes the impact on a con-
`sumer. This is accomplished by introducing a two-tap opera-
`tion, or a combination of a pre—tap and two—tap operation into
`the transaction process. The pre—tap or two—tap operation may
`include a consumer presenting a payment device to a device
`reader or point of sale terminal one or more times to activate
`a payment application, or to permit the transfer of data or a
`command to the payment device either prior to, during, or
`after a transaction. Some or all of the presentation(s) of the
`payment device that are part of implementing a pre-tap or
`two-tap operation may be in addition to, or include, a presen-
`tation that is typically used to initiate or perform a payment
`transaction (where the presentation may function to transfer
`identification or other authentication data to the device reader
`or terminal).
`[0015]
`In one embodiment, the present invention is directed
`to a method of conducting a payment transaction, Where the
`method includes detecting the presence ofa payment device
`using a near field communications technology of a device
`reader or terminal, receiving data identifying a payment
`account or consumer associated with the payment device,
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 9 of 18
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 9 of 18
`
`

`

`US 2010/0211504 A1
`
`Li.)
`
`Aug. 19, 2010
`
`determining that an interaction with the payment device or a
`consumer is required prior to performance of the payment
`transaction, determining that the interaction has been per—
`formed, detecting the presentment of the payment device
`using the near field communications technology ofthe device
`reader or terminal, and performing the payment transaction.
`[0016]
`In another embodiment,
`the present invention is
`directed to a device reader ofpoint of sale terminal, where the
`device reader or point of sale terminal includes a processor, a
`memory, and a set of instructions stored in the memory, which
`when executed by the processor implement a method to detect
`the presence of a payment device using a near field commu-
`nications technology, receive data identifying a payment
`account or consumer associated with the payment device, in
`response to receiving the data, determine that an interaction
`with the payment device or a consumer is required prior to
`performance of a payment transaction, determine that the
`interaction has been performed, detect the presentment of the
`payment device using the near field communications technol-
`ogy of the device reader or terminal, and perform the payment
`transaction.
`[0017]
`In yet another embodiment, the present invention is
`directed to a method of conducting a payment transaction,
`where the method includes detecting the presence of a pay-
`ment device using a near field communications technology of
`a device reader or terminal, and in response to detecting the
`presence of the payment device, activating a payment appli—
`cation installed on the payment device.
`[0018]
`In yet another embodiment, the present invention is
`directed to a device reader or point of sale terminal. where the
`device reader or point of sale terminal includes a processor, a
`memory, and a set of instructions stored in the memory, which
`when executed by the processor implement a method to detect
`the presence ofa payment device using a near field commu-
`nications technology of a device reader or terminal, and in
`response to detecting the presence of the payment device,
`activate a payment application installed on the payment
`device
`[0019] Other objects and advantages of the present inven—
`tion will be apparent to one of ordinary skill in the art upon
`review ofthe detailed description ofthe present invention and
`the included figures.
`
`
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a block diagram illustrating a transaction
`[0020]
`processing system that may be used with some embodiments
`of the present invention;
`[0021]
`FIG. 2 is a functional block diagram illustrating the
`primary components ofa system for initiating or facilitating a
`payment transaction using a contactless clement contained
`within a mobile device and a pre—tap and’or two—tap opera—
`tion, in accordance with some embodiments of the present
`invention;
`[0022]
`FIG. 3 is a functional block diagram illustrating the
`primary components of a mobile device, such as a mobile
`phone that may be used as part of the inventive system and
`method;
`FIG. 4 is a flow chart illustrating an embodiment of
`[0023]
`the inventive method or process for perfonning a payment
`transaction using a contactless element contained within a
`mobile device by implementing a pre—tap and/or two-tap
`operation;
`[0024]
`FIG. 5 is a flowchart illustrating a process for deter-
`mining whether an interaction with a consumer payment
`
`device is required prior to the device being used to conduct a
`payment transaction, in accordance with some embodiments
`of the present invention; and
`[0025]
`FIG. 6 is a block diagram of an exemplary comput—
`ing apparatus that may be used to implement an embodiment
`of the inventive method or process for performing a payment
`transaction with a contactless payment device using a pre-tap
`and/or two-tap operation.
`
`DETAILED DESCRIPTION
`
`[0026] Embodiments of the present invention are directed
`to a system, apparatus, and method for processing payment
`transactions that are conducted using a mobile payment
`device that includes a contactless element, such as an inte—
`grated circuit chip. Embodiments ofthe invention enable one
`or more of the operations of activation of a payment applica—
`tion, transfer oftransaction data, updating ofaccount records,
`setting or re-setting of a payment application counter or reg-
`ister, or transfer or processing of a script, command. or
`instruction, with these functions being performed with mini-
`mal impact on a consumer. This is accomplished by introduc-
`ing a pre-tap and/or two-tap operation prior to, or as part of,
`the transaction flow. The result is to expedite the payment
`transaction process for a consumer using a contactless pay-
`ment device, while facilitating the ability of an Issuer or
`payment processor to update transaction records or enable,
`disable, or otherwise configure a payment application or the
`consumer device.
`to ensure that any data, commands, or
`[0027]
`Further.
`instructions received by the payment device are from an
`authenticated source and that the received information can be
`associated with the proper transaction data stored in the pay-
`ment device, embodiments of the present invention may
`include use of a cryptogram or other form of security control
`or identification data. For example, the payment device may
`generate a cryptogram and provide that cryptogram to an
`Issuer as part of a transaction. The Issuer may generate a
`second cryptogram (either based on the initial cryptogram
`from the payment device, or by an independent process) and
`provide the second cryptogram to the payment device as part
`of any data, command, or instruction sent to the payment
`device during an Issuer update process. The payment device
`can then use the cryptogram received from the Issuer (along
`with the initial cwptogram sent to the Issuer, if necessary) to
`confinn the authenticity of the Issuer and to properly associ-
`ate the received data with the transaction record to which it
`applies, where that record is stored in the payment device. The
`cryptogram(s) may be generated by any suitable method and
`may be stored in a memory in the payment device and if
`desired, erased after completion of a transaction for which the
`cryptogram was generated.
`[0028] The present invention is typically implemented in
`the context of a payment transaction;
`therefore prior to
`describing one or more embodiments of the invention in
`greater detail, a brief discussion will be presented of the
`entities involved in processing and authorizing a payment
`transaction and their roles in the authorization process.
`[0029]
`FIG. 1 is a block diagram illustrating a transaction
`processing system that may be used with some embodiments
`of the present invention. Typically. an electronic payment
`transaction is authorized if the consumer conducting the
`transaction is properly authenticated (i.e., their identity and
`their valid use of a payment account is verified) and if the
`consumer has sufficient funds or credit to conduct the trans-
`
`
`
`Google LLC v. RFCyber Corp. / Page 10 of 18
`
`GOOG-1034
`
`GOOG-1034
`Google LLC v. RFCyber Corp. / Page 10 of 18
`
`

`

`US 2010/0211504 A1
`
`Aug. 19, 2010
`
`action. Conversely, if there are insufficient funds or credit in
`the consumer’s account, or if the consumer’s payment device
`is on a negative list (e.g., it is indicated as possibly having
`been stolen), then an electronic payment transaction may not
`be authorized. In the following description, an “Acquirer” is
`typically a business entity (e. g., a commercial bank) that has
`a business relationship with a particular merchant. An
`“Issuer” is typically a business entity (e.g., a bank) which
`issues a payment device (such as a credit or debit card) to a
`consumer. Some entities may perform both Issuer and
`Acquirer functions.
`[0030]
`FIG. 1 illustrates the primary functional elements
`that are typically involved in processing a payment transac—
`tion and in the authorization process for such a transaction. As
`shown in FIG. 1, in a typical payment transaction, a consumer
`wishing to purchase a good or service from a merchant uses a
`portable consumer payment device 20 to provide payment
`transaction data that may be used as part of a consumer
`authentication or transaction authorization process. Portable
`constnner payment device 20 may be a debit card, credit card,
`smart card, mobile device containing a contactless chip, or
`other suitable form of device.
`
`[0031] The portable consumer payment device is presented
`to a device reader or point of sale (POS) terminal 22 which is
`able to access data stored on or within the payment device.
`The account data (as well as any required consumer data) is
`communicated to the merchant 24 and ultimately to the mer-
`chant’s transaction/data processing system 26. As part of the
`authentication or authorization process performed by the
`merchant, merchant transaction processing system 26 may
`access merchant database 28, which typically stores data
`regarding the customer/consumer (as the result of a registra-
`tion process with the merchant, for example), the consumer’s
`payment device, and the consumer’s transaction history with
`the merchant. Merchant transaction processing system 26
`typically communicates with Acquirer 30 (which manages
`the merchant’s accounts) as part of the overall authentication
`or authorization process. Merchant transaction processing
`system 26 and/or Acquirer 30 provide data to Payment Pro-
`cessing Network 34, which among other functions, partici-
`pates in the clearance and settlement processes that are part of
`the overall transaction processing. Communication and data
`transfer between Merchant transaction processing system 26
`and Payment Processing Network 34 is typically by means of
`an intermediary, such as Acquirer 30. As part ofthe consumer
`authentication or transaction authorization process, Payment
`Processing Network 34 may access account database 36,
`which typically contains information regarding the consum—
`er’s account payment history, chargeback or transaction dis-
`pute history, credit worthiness, etc. Payment Processing Net-
`work 34 communicates with Issuer 38 as part of the
`authentication or authorization process, where Issuer 38 is the
`entity that issued the payment device to the consumer and
`manages the consumer’s account. Customer or consumer
`account data is typically stored in customer/consumer data-
`base 40 which may be accessed by Issuer 38 as part of the
`authentication, authorization or account management pro—
`cesses. Note that instead of, or in addition to being stored in
`account database 36, consumer account data may be included
`in. or otherwise part of customer/consumer database 40.
`[0032]
`In standard operation, an authorization request ines-
`sage is created during a constuner purchase of a good or
`service at a point of sale (POS) using a portable consumer
`payment device. In some embodiments, the portable con-
`
`sumer payment device may be a wireless phone or personal
`digital assistant that incorporates a contactless card or chip.
`The contactless card or chip may communicate with the point
`of sale terminal using a near field communications (NFC)
`capability. The authorization request message is typically
`sent from the device reader/POS terminal 22 through the
`merchant’s data processing system 26 to the merchant’s
`Acquirer 30, to a payment processing network 34, and then to
`an Issuer 38. An “authorization request message” can include
`a request for authorization to conduct an electronic payment
`transaction and data relevant to determining if the request
`should be granted. For example, it may include one or more of
`an account holder’s payment account number, currency code,
`sale amount, merchant transaction stamp, acceptor city,
`acceptor state/country, etc. An authorization request message
`may be protected using a secure encryption method (e.g.,
`128—bit SSL or equivalent) in order to prevent unauthorized
`access to account or transaction data.
`
`[0033] After the Issuer receives the authorization request
`message, the Issuer determines if the transaction should be
`authorized and sends an authorization response message back
`to the payment processing network to indicate whether or not
`the current transaction is authorized, The payment processing
`system then forwards the authorization response message to
`the Acquirer. Thc Acquirer then sends the response message
`to the Merchant. The Merchant is thus made awa