`
`ELECTRONIC PAYMENT SYSTEM
`.
`.
`.
`Apphcam: safety Pay, Inc-s Mlaml Beam: FL (Us)
`Inventor: Ralf Ohlhauscn, Frankfurt am Main
`(DE)
`
`Assignee: Safety Pay, Inc., Miami Beach, FL (US)
`
`Appl. No.:
`
`14/363,415
`
`54
`
`71
`72
`
`73
`
`21
`
`22
`
`
`
`19 United States
`
`US 20140365371A1
`
`12 Patent Application Publication (10) Pub. No.: US 2014/0365371 A1
`Ohlhausen
`(43) Pub. Date:
`Dec. 11, 2014
`
`(52) U.S. Cl.
`CPC ..................................... G06Q 20/42 (2013.01)
`USPC ............................................................ 705/44
`
`(5 7)
`
`ABSTRACT
`
`A specially configured computer for transferring money to a
`merchant, company, or other individual. The computer may
`comprise a barcode receiver configured to receive a copy of a
`barcode generated by the merchant, a barcode decoder con—
`figured to decode the barcode information with an applica—
`tion, a data input configured to receive customer information
`in an application running on the customer computer, a pay—
`ment interface configured to present an interface for transmit—
`ting a bank payment to the merchant, a transaction informa-
`
`PCT Filed:
`
`DCC- 7a 2012
`
`
`
`86
`
`PC” N05
`§ 371 (0(1))
`(2), (4) Date:
`
`PCT/U512/68539
`
`Jun. 6, 2014
`
`Related US. Application Data
`
`(60)
`
`Provisional application No. 61/568,911, filed on Dec.
`9. 2011.
`i
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`606g 20/42
`
`(2006.01)
`
`tion transfer module configured to send the transaction
`information to a bank system, a bank payment initiator con—
`figured to send an instruction to the bank system to initiate
`payment using the bank system at a first time period; and send
`a confirmation to a payment service provider indicating pay-
`ment was initiated; Wlierein the confirmation is sent Within
`ten minutes of the first time period.
`
`
`
` .3222 oeupmzt M
`
`
`
`
`
`
` ‘,
`am mam
`
`
`/
`{Zirliectoz 2 i (t
`3115
`
`
`
`
`flare,
`e
`
`
`Generator 2 l S
`
`
` ' Infamy/haggard 3311
`é‘aymm; Interim: I
`
` {rank wag“
`
`
`T
`on
`i
`3,)213510172 1451
`a:
`
`
`
`
`
`
`
`Google LLC v. RFCyber Corp. I Page 1 of 17
`
`6006-1008
`
`GOOG-1008
`Google LLC v. RFCyber Corp. / Page 1 of 17
`
`

`

`Patent Application Publication
`
`Dec. 11, 2014 Sheet 1 of5
`
`US 2014/0365371 A1
`
`
`
`233$“£33.
`
`mam
`
`
`
`3%EufimE—mmfiEmEMam
`
`
`
`~mumfluwm.uflafimmflfiQ
`
`m.33%:
`
`
`
`mi:
`
`3.5.3u3i“mafia?
`
`\..4findwuwfiflfiwfi,
`
`a“in.w
`
`mm“Enhgw
`
`G
`
`
`
`av.“Mdxmfimfi
`
`Exam:H
`
`GOOG-1008
`Google LLC v. RFCyber Corp. / Page 2 of 17
`
`
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Dec. 11, 2014 Sheet 2 of5
`
`US 2014/0365371 A1
`
` m...:L;
`
`GOOG-1008
`Google LLC v. RFCyber Corp. / Page 3 of 17
`
`
`

`

`Patent Application Publication
`
`Dec. 11, 2014 Sheet 3 of5
`
`US 2014/0365371 A1
`
`gummng. M
`
`wfimfl
`
`a
`m .
`
`
`
`mm?fififia3
`
`mmgflufifimfi.
`
`1:mm.HMy:
`
`GOOG-1008
`Google LLC v. RFCyber Corp. / Page 4 of 17
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Dec. 11, 2014 Sheet 4 of5
`
`US 2014/0365371 A1
`
`“
`
`.:EEEEEN
`
`hwmwcmfii
`
`m.33$
`
`
`
`“Samaria“Ewan“
`
`3;”“
`
`Emx“
`En
`
`GOOG-1008
`Google LLC v. RFCyber Corp. / Page 5 of 17
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Dec. 11, 2014 Sheet 5 of5
`
`US 2014/0365371 A1
`
`‘\\\x\\\\\\\\\\
`
`m“gm
`
`WR:warm
`E§§§§z§§z§$§m
`
`
`_mamEfiumfiiufi§m§
`»;;mmimm_$§3ufim§$.
`
`W«m§§m
`
`mm.@meM3§E.
`
`
`
`w.93%
`
`sizzm§§s§§i§iii............
`
`mamwmmmwmm..532.
`
`Swag?WWW
`
`uawvgfi3mfimfififi“ENE
`
`
`
`
`
`$52;F.fipsm
`
`fin3%
`
`
`5‘
`
`
`as?“2% ‘3th$$§S§§S$“i...:,JEE“"T1135...9.3%:m8mWawwmgwmmm
`
`
`
`
`
`m3:me
`
`
`
`if“?3"m.§M§S§.mééHS:EMHMHMMHHHMHWMSSA«mm
`
`
`
`
`
`.wfimflmmfiafimQWmsm
`.W:WfimExamx
`
`risirrisiraflRafi
`
`E£33.???“WE.....
`
`MgwaéafiMaggiWfiwfiSE
`
`
`g,mmmfifi:.mmfimgW3&5maufiwfixfimWW3%.a?mH
`
`
`
`
`
`
`
`mmnmhawngmuuwfi
`
`ummam,Maw“Warn
`
`N\m\\xu\
`
`._..wmyHmmman“.
`
`Whamgym“...
`
`.
`
`mfififififi,.-,.._Eu..4
`
`
`MmflwgwfifimwwEm,“~me
`fiéfifi.I.
`
`mmHawnm
`
`\‘“
`
`
`
`m3$§E¢UMuEEmmUW
`
`
`
`EEQEQQumwmmgafi
`
`a“:
`
`Qmam.
`
`firmfimfiw
`
`
`
`If}:El.
`
`I”?
`
`E
`
`US
`
`' Em\\§
`
`
`
`PliEéfaFi.
`
`33mg
`
`a:.3?»
`
`GOOG-1008
`Google LLC v. RFCyber Corp. / Page 6 of 17
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`US 2014/0365371 A1
`
`Dec. 11,2014
`
`ELECTRONIC PAY VI EN'I‘ SYSTEM
`
`CROSS REF iRENC i
`
`
`
`
`[0001] This application claims the benefit of priority to
`US. Provisional Application, 61/568,91 , filed Dec. 9, 2011,
`the contents of which are incorporated by reference in their
`entirety.
`
`BACKGROUND
`
`[0002] This disclosure relates to payment mechanisms for
`delivering payment to a merchant or other legal entity without
`needing to tender a physical credit card, check, or cash during
`the transaction. Rather, a process, computer, and system for
`paying a merchant using a computer such as a smart phone is
`provided.
`
`SUMMARY
`
`[0003] A method of paying a merchant with a customer
`computer is disclosed. The method may comprise generating
`a barcode comprising a set of transaction information includ-
`ing sales and merchant information to be encoded with a
`merchant computer, generating an invoice comprising the
`barcode with the merchant computer, storing a copy of the
`barcode in the customer computer, entering customer infor-
`mation into a payment application running on the customer
`computer, decoding the barcode information with the pay-
`ment application, and presenting an interface with three
`options: a) bank payment; b) credit or debit card payment; or
`c) mobile wallet payment.
`[0004] Choosing choice a) bank payment, may cause the
`payment application rumiing on the customer computer to
`send the transaction information to a payment service pro-
`vider, receive a transaction ID linked with the transaction
`information at the customer computer from the payment ser-
`vice provider, display some transaction information on a dis-
`play ofthe customer computer, and provide an interface with
`options for the bank payment: a) manual login; b) automated
`bank payment; or c) direct debit.
`[0005] Choosing choice a) manual login, may cause the
`application to launch a web browser or a bank application on
`the customer computer to access an online or mobile bank
`system. Using the web browser or bank app the customer can
`log into a bank system account ofthe customer. Through the
`web browser or bank app, the customer can transmit the
`transaction information and/or transaction ID to the bank
`system using the payment app, send the transaction ID to the
`payment service provider using the bank system, send some
`transaction information from the payment service provider to
`the bank system, display information about the transaction on
`the display ofthe customer computer using the bank system,
`verify and/or amend the transaction, and initiate payment
`using the bank system. The bank system may be configured to
`transfer funds from the customer to the merchant or an inter-
`mediary payment service provider using the bank system, and
`send a confirmation notice to the merchant or the intennedi-
`ary payment service provider. The payment service provider
`may send the confirmation notice to the merchant and/or
`customer, and if applicable may transfer funds minus a ser—
`vice fee from the payment service provider to the merchant.
`[0006] Choosing choice b) automated bank payment, may
`cause the payment app to launch a web browser or a bank app
`on the customer computer to access an online or mobile bank
`system associated with the customer, provide the customer
`
`with an interface to initiate payment using the stored and
`gathered customer information and transaction information
`andjor transaction ID, to automatically populate fields and
`transfer funds from a financial account ofthe customer to the
`merchant or an intermediary payment service provider. The
`bank system may be configured to transfer fimds from an
`account of the customer to the merchant or an intermediary
`payment service provider using the bank system, and send a
`confirmation notice to the merchant or intermediary payment
`service provider. The payment service provider may send the
`confirmation notice to the merchant and/or customer, and
`transfer funds from the payment service provider to the iner-
`chant.
`
`[0007] Choosing choice c) direct debit, may cause the pay-
`ment app to launch a web browser or an application on the
`customer computer providing the customer with an interface
`to initiate payment using the stored and gathered customer
`information and transaction infonnation, send a direct debit
`authorization to the merchant or intennediary payment ser-
`vice provider allowing the debit of funds from the customer’ 5
`bank account. The merchant or intermediary payment service
`provider notifies the debit authorization to the customer’s
`financial institution and requests the transfer of the funds to
`the merchant or intermediary payment service provider; and
`if applicable the payment service provider may transfer the
`funds to the merchant.
`
`Ifthe customer selects choice b) credit or debit card,
`[0008]
`the application may launch a website of the merchant allow—
`ing the customer to initiate an online or mobile credit card or
`debit card payment by using the merchant‘s card payment
`service provider. The payment service provider may execute
`the online or mobile credit card or debit card payment, notify
`the merchant that the customer has initiated filnds transfer
`request, and transferring funds from an account of the cus-
`tomer to an account of the merchant and or intermediary
`payment service provider. Once executed, the payment ser-
`vice provider may send the merchant a notice that the funds
`were received, and if applicable may transfer the funds minus
`a service fee to an account controlled by the merchant.
`[0009]
`If the customer selects choice c) mobile wallet pay-
`ment, the application may launch a web browser or mobile
`wallet app 011 the customer computer to access a wallet
`account. The web browser or mobile wallet app may request
`the customer to verify transactions details, and may request
`usemame and pas sword or a pin to authenticate and authorize
`the payment before providing a transfer funds function con-
`figured to transfer funds from a wallet account of the cus-
`tomer to an account of the merchant or an intennediary pay-
`ment service provider.
`[0010]
`In addition to the above processes, a specially con-
`figured computer is set forth herein. The computer may com-
`prise a processor for executing instructions stored on tangible
`computer readable storage media, tangible computer read-
`able storage media for storing processor instructions. The
`instructions may comprise, a barcode receiver configured to
`receive a copy o fa barcode generated by the merchant, a data
`input configured to receive customer information into an
`application running on the customer computer, a barcode
`decoder configured to decode the barcode information with
`the application, a payment interface configured to present an
`interface for transmitting a bank payment to the merchant, a
`transaction information transfer module configured to send
`the transaction information to a payment service provider, a
`transaction ID receiver configured to receive a transaction ID
`
`
`
`GOOG-1008
`Google LLC v. RFCyber Corp. / Page 7 of 17
`
`

`

`US 2014/0365371 A1
`
`Dec. 11,2014
`
`linked with the transaction information at the customer coni—
`puter from the payment service provider, a login interface
`configured to provide an interface for logging into a bank
`system account of the customer, a transaction If) transmitter
`configured to transmit the transaction ID to the bank system
`using the application, and a bank payment initiator configured
`to initiate payment using the bank system.
`[0011]
`In another configuration, a method ofpaying a mer-
`chant with a customer computer is disclosed. The method
`may comprise generating a barcode associated with transac-
`tion information to be encoded with a merchant computer;
`receiving a copy of the barcode at the customer computer;
`executing an application on the customer computer to decode
`the barcode infonnation; presenting an interface for transmit-
`ting a bank payment to the merchant; logging into a bank
`system account of a customer; transmitting all or a part ofthe
`transaction information to the bank system using the cus—
`tomer computer; and initiating payment using the bank sys—
`tem at a first time. Either the bank system to a payment service
`provider may send a confirmation notice of payment to a
`computer ofthe merchant within ten minutes ofthe first time;
`and transfer funds from the payment service provider to a
`financial account of the merchant The computer of the mer—
`chant may be the first computer, or it may be a second coni-
`puter such as a smart phone. The merchant may receive the
`confirmation notice within a few seconds of transmission.
`[0012]
`I11 another configuration, a computer for paying a
`merchant is provided. The computer may comprise a proces-
`sor for executing instructions stored on tangible computer
`readable storage media, and tangible computer readable stor-
`age media for storing processor instructions. The instructions
`may comprise instructions to the processor to generate a
`barcode receiver configured to receive a copy of a barcode
`generated by a computer ofthe merchant; a barcode decoder
`configured to decode the barcode information with the appli—
`cation; a data input configured to receive customer inforrna—
`tion in an application running on the customer computer; a
`payment interface configured to present an interface for trans-
`mitting a bank payment to the merchant; a transaction infor-
`mation transfer module configured to send the transaction
`information to a bank system; and a login interface configured
`to provide an interface for logging into a bank system accotmt
`ofthe customer. The computer readable media may comprise
`instructions for the processor to generate a bank payment
`initiator configured to send an instruction to the bank system
`to initiate payment using the bank system at a first time
`period; and send an instruction to the bank system to send a
`confirmation to a payment service provider indicating pay—
`ment was initiated; wherein the confirmation is sent within
`ten minutes (or in some cases withina few seconds) of the first
`time period. Alternatively, the computer readable media may
`comprise instructions for the processor to generate a bank
`payment initiator configured to send an instruction to the
`bank system to initiate payment using the bank system at a
`first time period; and send an instruction to the bank system to
`send a confirmation to the merchant indicating payment was
`initiated; wherein the confirmation is sent within ten minutes
`(or in some case within a few seconds) ofthe first time period.
`
`BRIEF DESCRIPTION
`
`FIG. 1 is a process flow diagram of the merchant
`[0013]
`computer and the customer computer.
`[0014]
`FIG. 2 is a box diagram of the processes of the
`payment processor.
`
`FIG. 3 is a [low diagram of the payment service
`
`[0015]
`provider.
`FIG. 4 is box diagram of some of the functions and
`[0016]
`modules of the application.
`[0017]
`FIG. 5 is a process flow diagram of the application;
`merchant computer, customer computer. and the payment
`service provider.
`
`
`
`
`D ATAII 4D DESCRIPTION
`
`[0018] The following disclosed system and methods pro-
`vide equipment, software, instructions, and process flows to
`enable a customer to pay a merchant using a customer com-
`puter. In an exemplary point of sale transaction, a customer
`would approach a merchant who would ring up the sale and
`provide a receipt for the purchase. The receipt may be elec-
`tronically displayed, emailed, faxed, printed. etc. The mer-
`chant’s computer may include a barcode of some sort on the
`receipt comprising information about the merchant and the
`transaction. When considering the scope of “customer” and
`“merchant” these tenns should be afforded a meaning
`roughly equivalent to “payor” and “payee” respectively .
`.
`. a
`merchant being a legal entity intending to receive a payment
`for a good or service, release of obligation, satisfaction of
`debt, etc. while a customer is a legal entity intending to pay for
`the same. An exchange between two legal entities such as a
`tenant/landlord, lendeellendor, patient/doctor, passenger/air—
`line, patron/restaurant, restaurant/food service provider, resi—
`dent/IRS, etc, should all be considered a customer/merchant
`pairs.
`FIG. 1 shows a merchant computer 100 comprising
`[0019]
`computer hardware such a processor 101, memory 102, hard
`drive 103 (or tangible computer readable storage media). The
`merchant computer may be a desktop, server, laptop, smart
`phone or other computer device. The merchant may use more
`than one computer, such as a combination of a desktop and a
`smart phone in some configurations. The computer readable
`media (CRM) may comprise specially configured instruc—
`tions (a checkout processor 200) comprising an invoice gen—
`erator 205, merchant data collector 210, a barcode generator
`215, and delivery module 220. The invoice generator 205 may
`request data from the computer as to the products, quantities,
`and price ofproducts to be purchased (e.g. “Sales Information
`250”.) Other examples of Sales Information 250 may include
`a sales identification number; numbers and names of items in
`sale; price per item; currency; sales tax; date and time of sale;
`etc. The merchant may input these products into a datastore
`240 using a scanner 104 or other technology product recog-
`nition technology. The merchant data collector 210 is config-
`ured to store information about the merchant, i.e. the “Mer-
`chant Infonnation 230” in the computer readable storage
`memory. Merchant Information 230 may include name,
`address, email address, web site URLs, bank or otherpayment
`details of the merchant, Payment Service Provider (PSP)
`details, and/or merchant ID. “Transaction Information 255”
`may include both “Merchant Information 230” and “Sales
`lnforination 250" or an identifier associated with the Mer—
`chant Information and the Sales Information The scanner
`104 can place product information into the transaction datas—
`tore 240 which the invoice generator 205 can use to generate
`the sales information 250. Both the Merchant Information
`230 and Sales Information 250 may be encoded by a barcode
`generator 215 into a barcode 125. The barcode generator may
`create barcodes in a number of different recognized barcodes
`formats such as the UPC or Matrix (2D) barcode. The check-
`
`
`
`GOOG-1008
`Google LLC v. RFCyber Corp. / Page 8 of 17
`
`

`

`US 2014/0365371 A1
`
`Dec. 11,2014
`
`LN
`
`out processor 200 can deliver the invoice and barcode to the
`delivery module which will format the invoice and barcode
`into a format suitable for final delivery to the customer com—
`puter. In some cases, the delivery module 220 may comprise
`an email module for delivering the invoice and barcode via
`email, a fax module for delivering the invoice and barcode via
`fax, a display module for displaying the invoice and barcode
`on a screen, and a printer module for formatting and deliver-
`ing the invoice and barcode to a printer.
`[0020] The customer computer 130 may comprise a pro-
`cessor 131, memory 132, and tangible computer readable
`storage media 133. The CRM may comprise a payment appli-
`cation (“the App”) 300 configured to receive the Merchant
`and Sales Information via a barcode receiver or intake module
`305. For example, an email client may receive the email with
`the barcode. and a data processor may determine the Mer-
`chant Information and Sales Information from the barcode.
`Of course, barcodes are often used for scamrers, so in some
`embodiments, the email module may deliver the Merchant
`Information and Sales Infonnation without encoding it into a
`barcode. The email module may employ encryption to pro-
`vide additional security to the transaction. The customer com—
`puter may also comprise an integrated camera or feature a
`connected scanner 134 as shown for reading a barcode dis—
`played on a display 105 on the merchant computer 100 or
`printed on an invoice 125 by the printer 120. The App may
`interface with drivers or other software used to control an
`optic device such as a scanner or camera to capture an image
`ofthe barcode. The invoice intake module 305 may comprise
`a barcode decoder 306 (FIG. 4) configured to decode the sales
`and merchant information from the scanned barcode in order
`to provide the customer computer with the needed informa-
`tion to effect the payment process.
`[0021] The customer computer may be a smart phone, cell
`phone, laptop, tablet, or any mobile or desktop computer.
`Once the customer computer 130 has determined the Mer-
`chant Information and Sales Information vis-a-vis the invoice
`intake module 205, the customer computer can initiate the
`payment process.
`[0022] The App 300 may feature a data input 310 for the
`customer to enter and store (either in the computer readable
`media of the computer 130 or on a networked data store)
`various types of “Customer Information” such as a customer
`ID, name, delivery and billing address, bank details, account
`number, accOLmt access credentials, user name, password,
`pin, other account details, payment preferences, currency
`preferences, credit and/or debit card details, card numbers,
`expiry dates, security codes, other payment details, and infor-
`mation relating to the customer computer 130. The customer
`computer 130 may already comprise stored answers for some
`of these data fields, and the App 300 may communicate with
`the customer computer to automatically populate some of
`these fields by using a data populator 344 (FIG. 4) that can
`draw data from the CRM of the customer computer 130.
`[0023] The App may comprise a payment interface 340 to
`olTer the customer several payment options including a bank
`payment option 341, credit or debit card payment option 342,
`or a mobile wallet payment option 343, Ifthe customer selects
`the bank payment option 341, (which may be stored as a
`default option as part of the Customer Information), the App
`will launch the payment processor 350 offering the customer
`three choices 351-353 to pay through his Bank System;
`manual 10gin 351. automated bank payment 352, direct debit
`353 (these choices are shown in FIG. 2). These choices are
`
`also shown in FIG. 5 as processes 8a, 8b, and 8t" respectively.
`The bank payment option may access a PSP 150 and/or bank
`system 180, the credit/debit card option may access a mer—
`chant website or app 151, and the mobile wallet option may
`access a wallet website or app 152. A wallet account is a
`stored value account provided by a wallet service provider.
`Such accounts may have less features than bank accounts and
`wallet providers are more lightly regulated than banks They
`can be accessed via mobile phones, but often they can also be
`accessed and used by any internet-connected device as well as
`plastic cards, e.g. prepaid cards. In any of the options, the
`customer computer 130 and App may send via a transaction
`information transfer module 353 (FIG. 4) at least some Trans-
`action and/or Customer Information to the merchant or PSP
`either directly, or by storing such information into a file that is
`then shared by uploading the file through a web browser,
`website, or application.
`[0024] As shown in FIG. 3, a Payment Service Provider 150
`or PSP is a third party computer configured to receive Trans—
`action Information 255 either from the merchant or the cus—
`tomer or both, receive Customer Information 330 from the
`customer, generate 405 a transaction ID 410, deliver the trans—
`action ID 410 to the merchant computer 100 and/or customer
`computer 130, store 415 the Transaction Information 255
`together with the associated Transaction ID 410, receive 165
`a confirmation from the customer’s financial institution 160
`that a payment to the merchant’ s financial institution 170 or to
`the PSI” s financial institution 166 has been initiated. The PSP
`150 may deliver 173 a notification to the Merchant Computer
`100 and/or Customer Computer 130 that the payment was
`initiated. While the customer may interact with a website
`hosted by the payment service provider, in some configura-
`tions, the customer will use an application or a web browser to
`login into 181 a bank system 180 of the customer’s financial
`institution 160. The bank system may receive 182 a transac-
`tion ID from the Customer Computer 130 and forward 183
`this transaction 1]) to the PSP 150. The PSP 150 may return
`184 the transaction information associated to the transaction
`ID to the bank system 180.
`[0025] The customer, the PSP and the merchant may have
`an account with a financial institution 160, 166 and 170. The
`financial institutions (160, 166 and 170) can send and receive
`finances through ACH, wire, or other teclmiques. A “Bank
`System 180,” an application or web portal that a customer can
`access to provide information to the customer’s financial
`institution and/or direct a specific payment to the merchant’s
`financial institution 171 or to the PSP’s financial institution
`172, may be provided by the customer’s financial institution
`(or third party hosting site) to send and receive information
`between the customer and the customer’s financial institu-
`tion.
`
`FIG. 4 shows some additional modules/functions of
`[0026]
`the payment application 300. For example,
`the payment
`application may comprise a transaction 1].) receiver 371 con—
`figured to receive a transaction ID linked with the transaction
`information at the merchant computer from the payment ser—
`vice provider. A launcher 372 may launch a web browser or
`bank application on the customer computer. A 10gin interface
`373 may provide the cu stomcr with a screen for entering Bank
`System information. During login, the en stomer may transmit
`the transaction ID to the Bank System using a transaction ID
`transmitter 374. A bank payment initiator 375 may provide
`the customer a button or other interface to send an instruction
`to the bank system to: initiate payment using the bank system
`
`
`
`GOOG-1008
`Google LLC v. RFCyber Corp. / Page 9 of 17
`
`

`

`US 2014/0365371 A1
`
`Dec. 11,2014
`
`at a first time period; and send a confirmation to a payment
`service provider indicating payment was initiated; wherein
`the confirmation is sent within ten minutes of the first time
`period.
`FIG. 5 illustrates a process flow for effecting pay—
`[0027]
`ment to a merchant. The process flow may be implemented or
`executed in various sequences other than the ones provided.
`Although the sequences are proposed as step 1, step 2, etc.,
`some steps may be skipped or repeated, and the arrangement
`of the steps may be changed depending on needs for the
`customer application, payment service provider, etc.
`[0028]
`Step 1 and 1a. In step 1, a merchant computer 100
`may determine transaction information to be added to an
`invoice from the products or services for sale. The merchant
`computer 100 may be configured to determine the contents of
`the transaction information to store into the barcode and
`generate the barcode with the barcode generator. In some
`embodiments (Step 1a), the merchant transfers the transac—
`tion information to a PSP 150, who assigns a transaction ID to
`the transaction information, stores both transaction I] ) and the
`corresponding transaction information in their system and
`returns the transaction ID to the merchant, who may encode it
`in addition or instead of the transaction information into the
`barcode. The barcode may be transferred to the Delivery
`Module 220.
`
`Step 2 and 2a. In step 2. the Delivery Module 220
`[0029]
`may be configured to collect necessary information from the
`merchant computer 100 to display or print the barcode. The
`merchant computer 1 00 may be configured to direct the deliv-
`ery module to create an output having the Transaction Infor-
`mation encoded Within a barcode. The output (including the
`invoice and barcode) may then be sent to a Printer 120 (Step
`2) or a Display 105 (Step 2a).
`[0030]
`Step 3 and 3a. The printer 120 prints an invoice
`comprising thebarcode (Step 3) orthe display 1 05 displays an
`invoice and/or barcode (Step 30).
`[0031]
`Step 4. A customer computer 130 can use the “App”
`300 stored in memory and executed by the processor of the
`customer computer to scan the barcode once the image ofthe
`information is in the memory of the customer computer. The
`computer can then decode barcode and effect payment. If the
`customer computer is a smart phone, the optic device may be
`an integrated camera or a connected external camera. The
`customer computer may be connected to at least one of the
`participating parties in this process via a data network 145.
`The data network 145 may comprise standard fixed or mobile
`networking equipment.
`[0032]
`Step 5. The customer may Lise the data input 310 to
`store various types of Customer Information 33 0 in the Com-
`puter Readable Media 133 of the customer computer.
`[0033]
`Step 6. Using the image captured by the optic device
`135 (or email received by the email client), the customer
`computer 130 decodes the information in the barcode. The
`App 300 may comprise instructions from which the processor
`of the customer computer can decode the barcode. ()nce the
`decoded information is obtained, the App 300 may store the
`Transaction Information into the computer readable media of
`the customer computer 130. The App may offer one or more
`of the payment options to the customer as shown in FIG. 1:
`elements 341 -343. Based on the merchant information, which
`is part of the transaction information, there could be several
`providers for each payment option creating a longer list,
`similar to the checkout page of online merchants.
`
`
`
`Step 70. When selecting the bank payment option,
`[0034]
`the transaction information may be sent to the PSP 150 pro—
`viding this option, who may assign a transaction ID if not
`already part ofthe transaction infomiation and may send the
`transaction ID back to the customer computer 130 and App
`(running on the computer), which may be configured to dis—
`play at least some Transaction Information 505. Depending
`on the stored Customer Information (in Step 5), the App may
`be configured to display the payment interface providing the
`customer with the following options for the bank payment:
`811) manual login, 85) automated bank payment, or 8c) direct
`debit.
`
`Step 7b, bypassing Steps 8-13. may be executed
`[0035]
`when option 719) credit or debit card payment is selected by
`customer through the interface. The customer makes an
`online or mobile credit or debit card payment by using the
`merchant’s website by either providing the card details and
`customer info manually or via the App 300 using stored data
`if available and if necessary providing the rest manually. The
`PSP may request authorization of the payment from the cus-
`tomer’s financial
`institution (Step 7b1). The customer’s
`financial institution may check availability of the requested
`amount on the customer’s account, may reserve the amount
`for a set period and may notify the PSP if it authorizes the
`payment or not (Step 7122). If authorized, the PSP may request
`either right away or at a later stage the customer’s financial
`institution to transfer the authorized amount from the cu stom—
`er’s account to the merchant or the PSP (Step 7173).
`[0036]
`Step 70, bypassing Steps 8—15, may be executed
`when option c) mobile wallet is selected. The customer makes
`a mobile wallet payment by using a web browser or mobile
`wallet app on the customer computer to access his/her mobile
`wallet account by entering his/her access credentials if nec—
`essary, enter any necessary transaction information or verify
`and/or amend the stored Transaction Information that may
`have been passed on by the App; and if necessary authorize
`the payment to the PSP or merchant for example with a PIN,
`before executing it. A mobile wallet payment is confirmed by
`the wallet provider to the PSP or merchant. The PSP may
`notify (step 16) the merchant Whether the payment was suc-
`cessful or not, and ifsuccessful, the funds are transferred from
`the customer’s mobile wallet to the merchant’s financial insti-
`tution (Step 7c1) or to the PSP’s financial institution (Step
`702) through ACH or other electronic transfer mechanism. If
`applicable the PSP may subsequently transfer the payment to
`the merchant (Step 703).
`[0037]
`Step 8a, returning back to the step 7a process (bank
`payment), in step 8a (manual login), the customer computer
`is configured to execute a program (such as a web browser or
`a bank app) for accessing the customer’s Bank System 180
`(such as a bank or financial institution’s online or mobile
`banking platform). In some embodiments, this program will
`be launched automatically by the App 300.
`[0038]
`Step 8b is selected when the customer selects b)
`automated bank payment 352 in the App (bypassing Steps
`9—13). In this process, the App provides the customer with an
`interface to enter his or her Customer Information 330 or to
`verify and/or amend the stored Customer Information and
`then execute the payment using the Customer Bank System.
`The App th