`US 20090094123A1
`
`(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2009/0094123 A1
`Killian et a1.
`(43) Pub. Date: Apr. 9, 2009
`
`
`(54) PAYMENT SERVICES PROVIDER METHODS
`IN CONNECTION W'ITH PERSONALIZED
`PAYMENTS SYSTEM
`
`(76)
`
`Inventors:
`
`Patrick Killian, Cottlcvillc, MO
`(US); Sandeep Malhotra, Ballwin,
`MO (US); Andrew D. Campbell,
`Ash (GB); Shoon Wong, St.
`Charles, MO OJS); Dana Lorberg,
`St. Louis. MO MS)
`
`Correspondence Address:
`BUCKLEY, MASCHOFF & TALVVALKAR LLC
`50 LOCUST AVENUE
`NEW CANAAN, CT 06840 (US)
`
`(21) App]. No.:
`
`11/964,343
`
`(22)
`
`Filed:
`
`Dec. 26, 2007
`
`Related US. Application Data
`
`(60)
`
`Provisional application No. 60/977,260. filed on Oct.
`3, 2007.
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`(2006.01)
`G06Q 20/00
`(52) US. Cl. .......................................................... 705/16
`(57)
`ABSTRACT
`
`A method includes receiving transaction information from a
`merchant device. The transaction information includes a
`transaction amount and merchant information that identifies a
`merchant that operates the merchant device. The method
`further includes receiving, from a mobile device, a request
`that a ftmds transfer be made from a payment card account
`that belongs to a customer who is operating the mobile device
`to a payment card account that belongs to the merchant. The
`method also includes forwarding the request to a financial
`institution that issued the payment card accotmt that belongs
`to thc customer.
`
`802
`
`
`
`ENTRY OF PURCHASE INFO
`
`804
`
`GENERATE TRANSACTION
`
`DATA
`
`
`
`RECEIVE CUSTOMER
`MOBILE PHONE NO.
`
`|
`
`
`
`DISPLAY/TRANSMIT
`TRANSACTION INFO
`
`
`
`
`COMPLETE TRANSACTION
`
`
`
`CONFIRMATION
`RECEIVED?
`
`812
`
`Google LLC v. RFCyber Corp. / Page 1 of 35
`
`GOOG-1021
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 1 of 35
`
`PGR2022-00003
`Apple EX1021 Page 1
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 1 0f 17
`
`US 2009/0094123 A1
`
`<<(.3
`
`a:
`gh_'Z0:
`:0no10
`
`116
`
`118:
`
`110
`
`108
`
`106
`
`100'\
`
`FI.1
`
`(PRIORART)
`
`102
`
`.
`
`2 E<D
`
`E E>
`
`—(I)
`I—
`
`114
`
`120
`
`
`
`1124b122104
`
`P03
`
`ACQUIRER
`
`
`
`Google LLC v. RFCyber Corp. / Page 2 of 35
`
`GOOG-1021
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 2 of 35
`
`PGR2022-00003
`Apple EX1021 Page 2
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 2 0f 17
`
`US 2009/0094123 A1
`
`SN
`
`08I\\
`
`8“gmNON
`
`
`
`
`
`
`
`55%EMEE
`
`Jl“
`
`mm
`
`2N2N“
`
`cum
`
`AZMEOHWDQmomvH_Muzmm_
`
`H.525”:50:Al55%
`
`55.5%:
`
`NNN
`
`
`
`CNNszooo<
`
`wow
`
`ZMQCOIQE<Q
`
`N_N
`
`Egg;EE5
`
`Hz<Iommz
`
`5:82
`
`NGE
`
`nuG
`2mmGnu
`53fo3e9aPla.roCrebV.CFRv.CLLb9ooG
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 3 of 35
`
`PGR2022-00003
`Apple EX1021 Page 3
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 3 0f 17
`
`US 2009/0094123 A1
`
`308
`
`
`
`CASHDRAWER
`
`304
`
`306
`
`KEYPAD
`
`320
`
`FIG..3
`
`302
`
`PROCESSOR
`
`REID/NFCTERMINAL
`
`
`
`A L
`
`”,>—<_l
`D.
`0—"Q
`
`6
`
`310
`
`312
`
`314
`
`U")2
`:<
`2Z3
`
`OI
`
`PRINTER
`
`.)CONTROLLER
`
`E2OC
`
` GOOG-1021
`
`Google LLC v. RFCyber Corp. / Page 4 of 35
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 4 of 35
`
`PGR2022-00003
`Apple EX1021 Page 4
`
`

`

`Patent Application Publication
`
`mhS9002
`
`m
`
`
`or).mmjoEzoo
`
`AnnyHE‘S;E238”:
`
`SRUv.
`Umf9A0.,m
`><._n_m_o
`
`19mmm2/.nm9OWCWa0b
`
`cLL
`
`15M34.mmu
`
`
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 5 of 35
`
`PGR2022-00003
`Apple EX1021 Page 5
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 5 0f 17
`
`US 2009/0094123 A1
`
`mm“
`
`ma
`
`955%:EE?
`
`55.5%:
`
`238%
`
`EN
`
`Sow.\
`
`55%
`
`
`
`54.10%:New3m65%EEO:
`
`«on
`
`EMEE
`
`mmusfim
`
`Ease”:
`
`Egag
`
`gameE
`
`8m
`
`n.QE
`
`$9225
`
`H2282
`
`2mGooG
`53fo6e9aPla.roCrebV.CFRv.CLLb9ooG
`
`
`
`
`
`
`
`
`
`
`
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 6 of 35
`
`PGR2022-00003
`Apple EX1021 Page 6
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 6 0f 17
`
`US 2009/0094123 A1
`
`8%\
`
`EN
`
`«8
`
`New
`
`EMEE
`
`mmosfim
`
`$95”:
`
`EN
`
`
`
`cz<IommzmOLV
`
`55.5%:
`
`5:83
`
`3m
`
`35%Hzmzél
`
`mGE
`
`
`
`AmmonwzoxoLv
`
`E30155
`
`5382
`
`mm2mgoEE:2
`
`nuG
`2mmGnu
`53fo7e9aPla.roCrebV.CFRv.CLLb9ooG
`
`55%
`
`Eséfi:NewEN8st5502
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 7 of 35
`
`PGR2022-00003
`Apple EX1021 Page 7
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 7 0f 17
`
`US 2009/0094123 A1
`
`705
`
`701
`
`708
`
`//,'502
`
`INPUT
`DENCE
`
`710
`
`7‘2
`
`714
`
`716
`
`718
`
`72o
`
`722
`
`DENCE
`
`COMMUMCAHON
`DEWCE
`
`OUTPUT
`
`700
`
`PROCESSOR
`
`CARDHOLDER
`ENROLNNENT
`
`H ENROLLMENT
`
`TRANSACNON
`HANDUNG
`
`SPENAL SERNCE3——
`CONSUMER
`
`SPENAL SERNCES——
`MERCHANT
`
`SPENAL SERNCES——
`ISSUER
`
`DATABASES
`
`704
`
`
`
`
`
`Google LLC v. RFCyber Corp. / Page 8 of 35
`
`GOOG-1021
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 8 of 35
`
`PGR2022-00003
`Apple EX1021 Page 8
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 8 0f 17
`
`US 2009/0094123 A1
`
`802
`
`ENTRY OF PURCHASE INFO
`
`GENERATE TRANSACTION
`
`DATA
`TRANSACTION INFO
`
`
`I
`
`RECEIVE CUSTOMER
`MOBILE PHONE NO.
`
`I
`
`DISPLAY/TRANSMIT
`
`CONFIRMATION
`RECEIVED?
`
`812
`
`COMPLETE TRANSACTION
`
`FIG. 8
`
`
`
`Google LLC v. RFCyber Corp. / Page 9 of 35
`
`6006-1021
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 9 of 35
`
`PGR2022-00003
`Apple EX1021 Page 9
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 9 0f 17
`
`US 2009/0094123 A1
`
`902
`
`RECEIVE/ENTER
`TRANSACTION INFO
`
`TRANSMIT REQUEST FOR
`PAYMENT TRANSACTTON
`
`GENERATE REQUEST FOR
`PAYMENT TRANSACTTON
`
`RECEIVE CONFIRMATTON
`
`Google LLC v. RFCyber Corp. / Page 10 of 35
`
`GOOG-1021
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 10 of 35
`
`PGR2022-00003
`Apple EX1021 Page 10
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 10 0f 17
`
`US 2009/0094123 A1
`
`1002
`
`{-1014
`
`,1—1016
`
`I
`
`RECEIVE TRANSACTION
`INFORMATION FROM
`MERCHANT DEVICE
`
`TRANSMIT TRANSACTION
`INFORMATION TO
`
`CUSTOMER DEVICE
`
`RECEIVE REQUEST FOR
`PAYMENT TRANSACTION FROM
`CUSTOMER DEVICE
`
`I
`
`'ON BEHALF' SERVICES/
`SPECIAL SERVICES
`
`_|
`
`I
`I_l
`
`I
`RECEIVE AUTHORIZATION
`|
`I
`RESPONSE FROM
`|
`I
`MERCHANT Fl
`|
`I— __________ _.
`
`I— _________ _I' _|
`
`I
`TO ISSUER
`
`SEND CONFIRMATION T0
`|
`MERCHANT DEVICE
`I
`I_ __________ _.
`
`|
`
`I
`SEND CONFIRMATION TO
`|
`CUSTOMER DEVICE
`|_ __________ _l
`
`TRANSLATE CUSTOMER 8c
`MERCHANT ID'S TO PAN'S
`
`FORWARD REQUEST
`
`FIG. 10
`
`
`
`Google LLC v. RFCyber Corp. / Page 11 of 35
`
`6006-1021
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 11 of 35
`
`PGR2022-00003
`Apple EX1021 Page 11
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 11 of 17
`
`US 2009/0094123 A1
`
`E
`
`mg
`
`gm
`
`2%:
`
`305%
`
`Egg
`
`as
`
`
`
`Easel5ng”E
`
`
`
`magma65%
`
`5:82
`
`EN
`
`2GE
`
`@2058E
`
`$32920
`
`5:82
`
`ES2$22
`
`s:\\
`
`ESE
`
`55mm3:8:§sag:8:
`
`.lOC.lebV.CFRv.CLLbg0OG
`
`2mGooG
`53fO21egaPla.
`
`
`
`
`
`
`
`
`
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 12 of 35
`
`PGR2022-00003
`Apple EX1021 Page 12
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 12 0f 17
`
`US 2009/0094123 A1
`
`{—1212
`_________ _L _I
`RECEIVE AUTHORIZATION
`I
`I
`RESPONSES, FROM
`I
`I
`PROVIDERS FI
`|
`I
`'— —————————— _l
`I
`,r—IZI’I
`T— ————————— —" —T
`
`SEND CONFIRMATIONS TO
`I
`SERWCE PROVIDER
`I
`._ __________ _.
`I
`
`I
`
`|
`
`SEND CONFIRMATIONS TO
`CUSTOMER DEVICES
`
`I
`
`|_ __________ _l
`
`RECEIVE BATCH OF BILLING
`INFORMATION FROM
`SERVICE PROVIDER
`
`TRANSMIT BILLING
`INFORMATION TO
`CUSTOMER DEVICES
`
`RECEIVE REQUESTS FOR
`PAYMENT TRANSACTIONS FROM
`CUSTOMER DEVICES
`
`T0 ISSUERS
`
`TRANSLATE CUSTOMER & ,
`SERVICE PROVIDER IDS TO PANS
`
`FORWARD REQUESTS
`
`FIG. 12
`
`
`
`Google LLC v. RFCyber Corp. / Page 13 of 35
`
`6006-1021
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 13 of 35
`
`PGR2022-00003
`Apple EX1021 Page 13
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 13 0f 17
`
`US 2009/0094123 A1
`
`33%EE?
`
`mfiofism
`
`H2382
`
`$2
`
`
`
`NE
`
`mom_.\\
`
`
`
`
`
`8m_
`
`2m_
`
`“90.55AJ|mfiofism
`
`$2
`
`m.“GE
`
`New
`
`EMEE
`
`flosmmm
`
`”magma
`
`:2
`
`990%NE
`
`”90:5
`
`2:82
`
`.lOC.lebV.CFRv.CLLbg0OG
`
`2mGooG
`53fO41egaPla.
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 14 of 35
`
`PGR2022-00003
`Apple EX1021 Page 14
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 14 0f 17
`
`US 2009/0094123 A1
`
`1402
`
`RECEIVE BATCH OF
`
`PAYROLL INFORMARON
`
`|
`
`TRANSLATE EMPLOYEE ID'S
`AND EMPLOYER ID TO PANS
`
`I
`
`TRANSMIT REQUESTS FOR
`PAYMENT TRANSACMONS TO
`
`ISSUER
`
`|
`RECEIVE AUR—IORIZARON
`|
`|
`RESPONSES FROM
`|
`|
`EMPLOYEE FI’S
`l
`|_ __________ _I
`Y
`,—1410
`
`l— _________ _L _|
`
`I
`I
`
`SEND CONFIRMAHONS TO
`EMPLOYEES
`
`I
`I
`
`|_ __________ _l
`
` GOOG-1021
`
`Google LLC v. RFCyber Corp. / Page 15 of 35
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 15 of 35
`
`PGR2022-00003
`Apple EX1021 Page 15
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 15 0f 17
`
`US 2009/0094123 A1
`
`
`
`
`
`
`._<zo_:8<
`
`ozazE
`
`mumzom
`
`\\\\\\\\\\\\\‘Nom
`
`H2m2><m
`
`mmoszmm
`
`ESE
`
`
`
`55.5%:mom*3
`
`85%Bio:
`
`guamm
`
`
`
`Apz<IommzMOLV
`
`
`
`
`
`¢_N:whm»mHzm2><l
`
`25.5%:
`
`H2382
`
`n5GE
`
`”mama
`
`
`
`AEESOPmDQ“OLV
`
`ESGIES
`
`H2884.
`
`.lOC.lebV.CFRv.CLLbg0OG
`
`nuG
`2mmGnu
`53fO61egaPla.
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 16 of 35
`
`PGR2022-00003
`Apple EX1021 Page 16
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 16 0f 17
`
`US 2009/0094123 A1
`
`925%:EE?
`
`55.5%:
`
`2:82
`
`3m
`
`EN
`
`Eagé
`
`:58:
`
`CZEEEUmob
`
`$32an
`
`32E5:
`
`fig“
`
`o3E39
`
`8N
`
`2GE
`
`gamei
`
`$50155
`
`5382
`
`.lOC.lebV.CFRv.CLLbg0OG
`
`2mGooG
`53fO71egaPla.
`
`BED
`
`Elsa:“can:3:
`
`momeow
`
`
`
`
`
`
`
`
`
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 17 of 35
`
`PGR2022-00003
`Apple EX1021 Page 17
`
`

`

`Patent Application Publication
`
`Apr. 9, 2009 Sheet 17 0f 17
`
`US 2009/0094123 A1
`
`1 702
`
`ENTRY OF PURCHASE
`
`INFORMATTON
`
`1704
`
`
`TRANS.
`MODE
`
`SELECTTON?
`
`PURCHASE
`
`
` PAYMENT
`
`TRANS.
`
`1706
`
`
`
`PAYMENT TRANSACTTON
`MODE
`
`PURCHASE TRANSACTION
`MODE
`
`FIG. 17
`
`
`
`Google LLC v. RFCyber Corp. / Page 18 of 35
`
`GOOG-1021
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 18 of 35
`
`PGR2022-00003
`Apple EX1021 Page 18
`
`

`

`US 2009/0094123 A1
`
`Apr. 9, 2009
`
`PAYMENT SERVICES PROVIDER lVIETI-IODS
`IN CONNECTION WITH PERSONALIZED
`PAYMENTS SYSTElVI
`
`
`
`CROSS-R A F 4 RENCE TO RELATED
`
`APPLICATION
`
`
`
`[0001] This application claims the benefit of provisional
`patent application Ser. No. 60/977,260, filed Oct. 3, 2007,
`which application is incorporated herein by reference.
`
`BACKGROUND
`
`[0002] Embodiments disclosed herein relate to payment
`systems. In particular, some embodiments relate to methods,
`apparatus, systems, means and computer program products
`for implementing a payment system on the basis ofa payment
`card system.
`[0003]
`Payment card systems are in widespread use. A
`prominent payment card system is operated by the assignee
`hereof, MasterCard International Incorporated, and by its
`member financial institutions. FIG. 1 schematically illus-
`trates a typical transaction, as carried out in a payment system
`100. To initiate the transaction, a customer (not shown) Visits
`a retail store (not shown) operated by a merchant, selects
`goods (not shown) that he/she wishes to purchase, carries the
`goods to the merchant’s point of sale terminal 104, and pre—
`sents his/her payment card 102 to the point of sale tenninal
`104. The point of sale terminal 104 reads the customer’s
`payment card account number from the payment card 102,
`and then sends an authorization request to an acquirer finan-
`cial institution (Fl) 106 with which the merchant has a rela-
`tionship. The authorization request includes the payment card
`account number and the amount of the transaction, among
`other information. The authorization request is routed via a
`payment card system 108 (which may be, for example, the
`well—known Banknet system operated by the assignee hereof)
`to the issuer financial institution 110 that issued the custom—
`er’s payment card 102. Arrows 112, 114 and 116 trace the
`path of the authorization request from the POS terminal 104
`to the issuer 110.
`[0004] Assuming that all is in order, the issuer F1 110 trans-
`mits a favorable authorization response to the point of sale
`terminal 104 through the payment card system 108 and via the
`acquirer FI 106. (The path ofthe authorization response from
`the issuer FI 110 to the POS terminal 104 is traced by arrows
`118, 120, 122.) The transaction at the point of sale tenninal
`104 is then completed and the customer leaves the store with
`the goods. A subsequent clearing transaction initiated by the
`merchant results in a transfer of the transaction amount from
`the customer’s payment card account 124 to an account that
`belongs to the merchant. The customer’s payment card
`account 124 may be, for example, either a debit card account
`or a credit card account. In the former case, the clearing
`transaction results in the ftmds being debited directly from the
`account 124. In the latter case, the clearing transaction results
`in a charge being posted against the account 124, and the
`charge subsequently appears on the customer’s monthly
`credit card statement.
`
`[0005] The foregoing description of the typical transaction
`may be considered to be somewhat simplified in some
`respects. For example, a so-called merchant processing sys-
`tem (not shown) may be interposed between the POS terminal
`and the acquirer FI. As is familiar to those who are skilled in
`the art, a merchant processing system may be operated by or
`
`on behalfofthe merchant to form part ofthe communications
`path between the acquirer FI and a considerable number of
`POS terminals operated by the merchant. It is also often the
`case that a third party transaction processing service may
`operate to handle payment card transactions on behalf of the
`acquirer and on behalfofa large number ofother like financial
`institutions.
`[0006] The present inventors have now recognized that an
`existing facility of a payment card system, referred to as a
`“payment transaction”, may be utilized to provide more con-
`venient and flexible handling of purchases ofgoods and other
`exchanges of value. Among other advantages, the transac-
`tions described herein may be conducted such that the cus-
`tomer need not disclose hisflier payment card account number
`to the merchant. This may, in at least some circumstances,
`enhance the security ofthe customer’s payment card account
`and lessen the possibilities for misappropriation of the pay—
`ment card account number.
`[0007] The novel use of payment transactions disclosed
`herein may also cause transactions to be conducted in such a
`manner that the customer may be made fully aware of all
`transaction details before the customer initiates the payment
`transaction. This may help to protect the customer from unin-
`tentionally authorizing erroneous or fraudulent payment card
`transactions, and may reduce the number of occasions in
`which transactions need to be reversed.
`[0008]
`From the merchant’s point ofView, transaction tech-
`niques disclosed herein may save the merchant from having
`to enter into a relationship with an acquirer financial institu-
`tion. This may be particularly advantageous for very small
`merchants or for merchants who do not have fixed places of
`business. Moreover, elimination ofthe “acquirer” function, as
`proposed herein, may result in savings in bank fees charged to
`merchants.
`[0009] The present inventors have also recognized that the
`novel transaction techniques proposed herein present oppor—
`tunities for novel value—added services which may be pro—
`vided to customers, merchants and/or financial institutions.
`
`
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`Features and advantages of some embodiments of
`[0010]
`the present invention, and the manner in which the same are
`accomplished, will become more readily apparent upon con-
`sideration of the following detailed description of the inven-
`tion taken in conjtmction with the accompanying drawings,
`which illustrate preferred and exemplary embodiments and
`which are not necessarily drawn to scale, wherein:
`[0011]
`F G. 1 is a block diagram that illustrates a conven-
`tional payment system.
`[0012]
`F G. 2 is a block diagram that illustrates a transac-
`tion-handling system in accordance with aspects of the
`present invention.
`[0013]
`F G. 3 is a block diagram that illustrates a point of
`sale terminal that is shown in FIG. 2.
`
`F G. 4 is a block diagram that illustrates a custom—
`[0014]
`er’s mobile telephone that is shown in FIG. 2.
`[0015]
`F G. 5 is a block diagram that illustrates a transac—
`tion—handling system according to some other embodiments.
`[0016]
`F G. 6 is block diagram that illustrates another
`embodiment of a transaction-handling system.
`[0017]
`F G. 7 is a block diagram representation ofa com-
`puter that provides payment services in the system of FIG. 5
`or 6.
`
`
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 19 of 35
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 19 of 35
`
`PGR2022-00003
`Apple EX1021 Page 19
`
`

`

`US 2009/0094123 A1
`
`Apr. 9, 2009
`
`FIG. 8 is a flow chart that illustrates a process that
`[0018]
`may be performed by a point of sale terminal or other mer-
`chant device in connection with a transaction handled as in
`FIG. 2, FIG. 5 or FIG. 6.
`[0019]
`FIG. 9 is a flow chart that illustrates a process that
`may be performed by a customer’s mobile device in comiec-
`tion with a transaction handled as in FIG. 2. FIG. 5 or FIG. 6.
`[0020]
`FIG. 10 is a flow chart that illustrates a process that
`may be performed by the computer of FIG. 7.
`[0021]
`FIG. 11 is a block diagram that illustrates a bill
`payment system according to some embodiments.
`[0022]
`FIG. 12 is a flow chart that illustrates a process that
`may be performed by a payment services provider computer
`in the system of FIG. 11.
`[0023]
`FIG. 13 is a block diagram that illustrates a payroll
`disbursement system according to some embodiments.
`[0024]
`FIG. 14 is a flow chart that illustrates a process that
`may be performed by a payment services provider computer
`in the system ofFIG. 13.
`[0025]
`FIG. 15 is a block diagram that illustrates still
`another embodiment of a transaction-handling system.
`[0026]
`FIG. 16 is a block diagram that
`illustrates yet
`another embodiment of a transaction-handling system,
`[0027]
`FIG. 17 is a flow chart that illustrates a process that
`may bcperformed in a point ofsalc terminal that may serve as
`the merchant device shown in FIG. 2.
`
`DETAILED DESCRIPTION
`
`In general, and for the purpose of introducing con—
`[0028]
`cepts of embodiments of the present invention, a payment
`card system payment transaction initiated from a customer’s
`device (such as a mobile telephone) is utilized to consummate
`a purchase of goods or services. In some embodiments, the
`transaction information, such as an amount due for the pur-
`chase, and a code that identifies the merchant, may be entered
`into or transmitted to the customer’s device. In the former
`case, the transaction information may be displayed by a mer-
`chant’s device (e.g., a POS terminal) to be read by the cus-
`tomer and manually entered by the customer into the custom-
`er’s device. The customer may operate his/her device to
`initiate a request for a payment transaction via the issuer of
`the customer’s payment card account. The request may direct
`the customer’s issuer to implement a transfer of funds from
`the customer’s payment card account to the merchant’s pay-
`ment card account. The vehicle for the funds transfer may be
`a conventional payment transaction ofthe type now supported
`by at least one payment card system. The issuer of the cus-
`tomer’s payment card account may cause the payment trans-
`action to be routed via the payment card system to the issuer
`of the merchant’s payment card account to be credited to the
`merchant’s payment card account. Upon authorization/
`completion ofthe payment transaction, the merchant’s issuer
`may confirm to the merchant that the funds transfer has
`occurred (or is assured to occur subsequently during conven—
`tional clearing operations), and in response to receiving the
`confirmation. the merchant may transfer ownership of the
`goods to the customer, or may accept the confirmation as
`payment for services rendered or to be rendered to the cus-
`tomer.
`
`In this arrangement, the payment card transaction
`[0029]
`enters the system via a device operated by the customer and is
`initiated for routing from the customer’s issuing financial
`institution, rather than originating from the merchant’s POS
`terminal and the acquiring financial
`institution. Certain
`
`transaction flow
`advantages of the rearranged and novel
`described herein have been alluded to above and will be
`discussed in more detail below. along with other advantages
`and advantageous features.
`[0030]
`In other aspects, a payment services provider corn-
`puter may facilitate and/or relay commtmications between
`the merchant’s device and the customer’s device, and/or
`between the customer’s device and the customer’s issuer,
`and/or between the merchant’s issuer and the merchant. In
`some embodiments, the payment services provider computer
`may be operated by the payment card organization (e.g., the
`assignee hereof) that routes payment transactions from cus—
`tomer issuers to merchant issuers and also routes purchase
`transactions from acquirers to issuers.
`[0031]
`FIG. 2 is a block diagram that illustrates a transac-
`tion process in accordance with aspects of the present inven-
`tion. The various components shown in FIG. 2, and discussed
`below, may be a subset of a larger system, indicated generally
`by reference numeral 200, for facilitating payments to iner—
`chants via credit cards, debit cards and the like. In the
`example embodiment illustrated in FIG. 2, only components
`of system 200 that operate with respect to a single transaction
`are shown.
`
`[0032] The system 200 includes a merchant device 202,
`which may for example be a POS terminal or a suitably
`progrannned mobile telephone or PDA (personal digital
`assistant) with communication capabilities. (The latter two
`possible embodiments of the merchant device may for
`example be particularly appropriate for merchants who oper-
`
`ate without a fixed place ofbusiness. Examples of such mer-
`chants may be flea market sellers, artisans and crafters who
`sell their handiwork at craft fairs, itinerant merchants or iner-
`chants in third world marketplaces. For many merchants in
`the categories described in this parenthetical, it may not be
`practical or economic to enter into a conventional relationship
`with an acquirer FI.) Ifthe merchant device is a POS terminal,
`the latter may operate for the most part in a conventional
`manner or may alternatively have functionality that actively
`contributes to the novel transaction flow illustrated in FIG. 2.
`The POS terminal may be operated in any type of business
`establishment or retail store, including a “mom and pop”
`operation all the way up to a big box store that is part ofamega
`retail chain. In some particularly helpful embodiments, the
`merchant device may be installed in a store such as a small
`antiques or collectibles shop or the like in which the low
`volume of transactions may weigh against the expense and
`paperwork requirements involved in entering into a iner-
`chant—acquirer relationship with an FI.
`[0033] Among other capabilities, and as will be described
`further below, the merchant device 202 may display transac-
`tion information to be read by the customer (not shown) and
`manually inputted by the customer into his/her mobile device
`204. For example, the merchant device may display the total
`amount due for the transaction, and a merchant identification
`number. Alternatively, the merchant ID may be permanently
`displayed on a sticker affixed to the merchant device 202. (In
`some embodiments, the merchant identification number may
`be the account number that identifies the merchant’s payment
`card account to which payment transactions are to be routed.
`In other embodiments the merchant identification number
`may require translation into such an account number, e.g., in
`a manner as described below. If the merchant identification
`number is the merchant’s payment card number, steps may be
`taken to prevent misuse of the account number. For example,
`
`
`
`Google LLC v. RFCyber Corp. / Page 20 of 35
`
`GOOG-1021
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 20 of 35
`
`PGR2022-00003
`Apple EX1021 Page 20
`
`

`

`US 2009/0094123 Al
`
`Li.)
`
`Apr. 9, 2009
`
`the account corresponding to the account number may be
`enabled only to have funds transfers credited thereto, but not
`to receive charges via the payment card system, and with any
`transfers out ofthe account in question going into a compan-
`ion account, with a different number, from which charges
`may be made.) The merchant identification number may in
`some embodiments be the merchant’s mobile telephone num—
`ber or another mobile identifier; this may be particularly
`convenient where the merchant device 202 is a mobile tele-
`phone.
`In other embodiments, the merchant device 202 may
`[0034]
`have capabilities for transmitting the transaction information
`to the customer device 204. The transmitting of the transac-
`tion information from the merchant device 202 to the cus-
`tomer device 204 may be via wireless communication such as
`NFC (near field communication) or alternatively may be via
`a mobile telephone network using text messaging or the like.
`[0035] The customer’s mobile device 204 may for example
`be a mobile telephone with capabilities for initiating payment
`transactions in a payment card system. Operation of a mobile
`telephone to initiate funds transfers via a payment card sys—
`tem is for example described in commonly assigned US.
`patent application Ser. No. 11/836,945, filed Aug. 10, 2007,
`entitled “Payment Card Based Remittance System with Des-
`ignation of Recipient By Mobile Telephone Number”, which
`is incorporated herein by reference. As an alternative, the
`customer’s mobile device 204 may be a PDA with commu-
`nication capabilities. In some embodiments, the customer’s
`mobile device may initiate a payment transaction by interact—
`ing with a website operated by a payment services provider or
`by the issuer of the customer’s payment card account.
`[0036]
`FIG. 2 also shows, as included in the system 200, an
`issuer financial institution 206 which issued the customer’s
`payment card account 208, a payment system 210 (such as the
`Banknet system referred to above) for routing transactions
`from issuer to issuer (and also, e.g., from acquirers to issuers),
`and an issuer financial institution 212 which issued the mer—
`chant’s payment card account 214. Blocks 206 and 212
`should also be understood to represent, respectively, com-
`puter systems operated by or on behalfofthe customer issuer
`F1 and the merchant issuer F1.
`
`[0037] Arrows 216, 218, 220 trace the path ofthe payment
`transaction, requested from the customer’s mobile device
`204, as routed from the customer issuer 206, via the payment
`system 210 to the merchant issuer 212. Arrows 222, 224 and
`226 trace the path of acknowledgement messages from the
`merchant issuer 212 Via the payment system 210 and the
`customer issuer 206 to the customer’s mobile device 204.
`Arrow 228 represents a confirmation message sent from the
`merchant issuer 212 to the merchant device 202 to confirm
`that the payment transaction to pay for the pending sale has or
`will be credited to the merchant account 214. Upon receiving
`the confirmation message 228 the merchant may allow the
`sale or other exchange of value to be completed.
`[0038] Although only two issuing FIs, one mobile device
`and one merchant device are shown in FIG. 2, it should be
`understood that the system 200, in a practical embodiment,
`may include numerous issuing FIs all connected to the pay-
`ment system 210, a large number ofmerchant devices 202 and
`a very large munber of customer mobile devices. Further-
`more, the system 210 preferably also operates in accordance
`with the conventional purchase transaction model illustrated
`
`in FIG. 1, and thus may include a considerable number of
`acquirer FIs as well. Of course, many if not all acquirer FIs
`may also be issuer FIs.
`[0039]
`FIG. 3 is a block diagram of a POS terminal as
`provided in accordance with aspects ofthe invention to serve
`(in some embodiments) as the merchant device 202 shown in
`FIG. 2. In some embodiments, the POS terminal 202 may be
`largely or entirely conventional in its hardware aspects. Nev-
`ertheless, the POS terminal 202 may be programmed in
`accordance with the aspects of the present invention to pro—
`vide functionality as described herein.
`[0040] The POS terminal may include a processing element
`(or elements) such as the processor 302 shown in FIG. 3. The
`processor 302 may for example be a conventional micropro-
`cessor, and may operate to control the overall functioning of
`the POS terminal 202. The POS tcmlinal may also include
`conventional peripheral components, in communication with
`and/or controlled by the processor 302, such as: (a) a keypad
`304 for receiving input from the human operator of the POS
`terminal; (b) a barcode reader 306 for reading product bar-
`codes from products brought to the tenninal for purchase; (c)
`a cash drawer 308 for storing cash received from customers;
`(d) a magnetic stripe reader 310 for reading payment card
`account numbers and related infonnation from magnetic
`stripe payment cards; (e) one or more displays 312 for pro-
`viding output (e.g., identifying products presented for pur-
`chase and their prices, indicating sales tax due, indicating
`transaction subtotals and totals, etc); (1) a printer 314 for
`printing out sales receipts; (g) a wireless communication
`terminal/proximity reader 316 for exchanging wireless short
`range communications/near field communications (NFC)
`with contactless payment cards and/or with mobile telephone
`equipped with contactless payment device capabilities; and
`(h) a communication controller 318 for allowing the proces-
`sor 302, and hence the POS terminal 202 to engage in com-
`munication over data networks with other devices (e.g., a
`merchant processing system (not shown), an acquirer (not
`shown) or its transaction processor (not shown), an issuer 212
`(FIG. 2) of the merchant’s payment card account, etc. (In
`some embodiments, at least one ofthe displays 312 may be a
`touch screen, so as to provide an input function as well as an
`output function.) In some embodiments, the communication
`controller, or another communication device coupled to the
`processor 302, may be provided to allow the POS terminal
`202 to transmit and receive text messages or the like via a
`mobile telephone network (not shown). In addition, the POS
`terminal 202 may include one or more memory and/or data
`storage devices (indicated collectively at 320), which may
`comprise any combination ofone or more of a hard disk drive,
`RAM (random access memory), ROM (read only memory),
`flash memory, etc. The memory/data storage device(s) 320
`may store software and/or firmware that programs the pro-
`cessor 302 and the POS terminal 202 to perform functionality
`as described herein. Further, the POS temlinal may include
`one or more housings (not shown) which contain and/or sup—
`port one or more of the other components shown in FIG. 3.
`[0041] Those who are skilled in the art will recognize that
`components 310, 316 may be integrated in a single unit, and
`may include a display/touch screen to allow for user interac-
`tion.
`
`FIG. 4 is a block diagram of an example mobile
`[0042]
`telephone which may serve as the customer’s mobile device
`204 shown in FIG. 2, The mobile telephone 204 shown in
`FIG. 4 may also (but need not) have capabilities for fimction-
`
`
`
`Google LLC v. RFCyber Corp. / Page 21 of 35
`
`GOOG-1021
`
`GOOG-1021
`Google LLC v. RFCyber Corp. / Page 21 of 35
`
`PGR2022-00003
`Apple EX1021 Page 21
`
`

`

`US 2009/0094123 A1
`
`Apr. 9, 2009
`
`ing as a contactless payment device. In its hardware aspects
`the mobile telephone 204 may be entirely conventional, and
`indeed in its software aspects it also may be conventional, and
`may provide novel functionality as described herein through
`interaction (via a conventional browser) with a web page that
`supports initiation of payment transactions. In other embodi-
`ments, however, novel functionality as described herein may
`result at least partially from software and/or firmware that
`programs the mobile telephone 204.
`[0043] The mobile telephone 204 may include a conven—
`tional housing (indicated by dashed line 402) that contains
`and/or supports the other components ofthe mobile telephone
`204. The mobile telephone 204 further includes conventional
`control circuitry 404, for controlling over-all operation of the
`mobile telephone 402. Preferably the control circuitry 404 is
`suitably programmed to allow the mobile telephone 204 to
`engage in data communications and/or text messaging with
`other devices, and to allow for interaction with web pages
`accessed via browser software, which is not separately
`shown. Other components of the mobile telephone 204,
`which are in communication with and/or controlled by the
`control circuitry 404,
`include:
`(a) one or more memory
`devices 406 (e.g., program and working memory, etc.); (b) a
`conventional SIM (subscriber identification module) card
`408; (c) a conventional keypad 410 (or touch screen) for
`receiving user input; and (d) a conventional display 412 (or,
`again, touch screen) for displaying output information to the
`user.
`
`[0044] The mobile telephone 204 also includes conven—
`tional rece