US 20130166448A1
`
`(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2013/0166448 A1
`
` Narayanan (43) Pub. Date: Jun. 27, 2013
`
`
`(54) FINANCIAL TRANSFERS FROM MOBILE
`DEVICES
`
`(52) US. Cl.
`USPC ............................................................ 705/44
`
`(75)
`
`Inventor: Anoop Narayanan, Kottayam (IN)
`
`(73) Assignee:
`
`INFOSYS LIMITED. BANGALORE
`(1N)
`
`57‘
`)
`
`(
`
`ABSTRACT
`
`.
`(21) Appl. NO” 13/418’318
`.
`.
`(22) Ffled'
`(30)
`
`Mar. 12’ 2012
`Foreign Application Priority Data
`
`Dec. 273 201 1
`Dec. 273 2011
`
`(IN)
`(IN)
`
`........................... 4607/CHE/201 1
`........................... 4608/CHE/2011
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`G06Q 20/40
`G06Q 20/32
`
`(2012.01)
`(2012.01)
`
`Computer-implemented systems, methods, and computer-
`readable media for financial transfers from a mobile device,
`comprising: receiving a mobile device identifier, a unique
`user identifier, a merchant identifier, and an amount from a
`mobile device; determining whether the transaction is autho-
`.
`.
`.
`.
`.
`.
`nzed based on the mobile dev1ce Identifier and the umque
`user identifier; transmitting an authorization failure message
`to at least one of the mobile device and a merchant device
`associated with the merchant identifier if it is detemiined that
`the transaction is not authorized; and transmitting to a pay-
`ment gateway an account identifier associated With the unique
`user identifier and mobile device identifier, the merchant
`identifier, and the amount if it is determined that the transac-
`tion is authorized.
`
`1 O
`
`
`
`3
`
`
`
`Mobile
`Device
`
`55,
`
`105
`
`2
`
`r
`
`J
`
`1 1O
`
`{cWfi’
`Point of Sale
`Device
`8
`
`
`Mé’iésheifit
`
`\“
`
`Google LLC v. RFCyber Corp. / Page 1 of 12
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 1 of 12
`
`PGR2022-00003
`Apple EX1013 Page 1
`
`

`

`Patent Application Publication
`
`Jun. 27, 2013 Sheet 1 0f 5
`
`US 2013/0166448 A1
`
`
`
` \\
`
`Mobiie
`Deviae
`
`1 05
`
`Point of Sale
`Device
`
`6
`
`2 /
`
`»
`
`,
`
`,,
`
`\
`
`/
`
`,
`
`/
`
`,
`/
`
`,
`\
`
`,1
`
`1/
`
`,
`z
`
`.,
`
`\
`
`'
`
`\.
`
`‘
`
`,
`,/
`/
`;:,.,,JMerchéfit
`
`\
`
`-
`
`"E
`
`Google LLC v. RFCyber Corp. / Page 2 of 12
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 2 of 12
`
`PGR2022-00003
`Apple EX1013 Page 2
`
`

`

`Patent Application Publication
`
`Jun. 27, 2013 Sheet 2 0f 5
`
`US 2013/0166448 A1
`
`
`205 2
`210
`215
`
`Receive
`
`MEDN
`
`
`
`Receive UUI
`
`and MD!
`
`‘
`
`522:;i
`Amount
`
`.
`
`220
`
`it) an Authorized Account
`
`[Determine Whether UU! and MIDI Correspond
`225 I
`
`..........................................................................................................................................................................................
`
`\ \
`,
`/ fi/
`Authorized? "j:
`1/
`
`
`
`TransmitMlDN, Acceunt, and
`Transmit Authorization Faiiure
`Amountto PaymeniGateway Message
`
`
`
`Receive Confirmeéien or
`
`Transmit Confirmatien or
`
`Demai
`
`Denied to Mobile Devace
`
`Google LLC v. RFCyber Corp. / Page 3 of 12
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 3 of 12
`
`PGR2022-00003
`Apple EX1013 Page 3
`
`

`

`Patent Application Publication
`
`Jun. 27, 2013 Sheet 3 0f 5
`
`US 2013/0166448 A1
`
`305 /
`
`.
`_
`Mobiie Bevsce
`
`3’1 0
`
`315
`
`328
`
`Data required to authorize transfer
`
`in mobéie payment system
`
`V Mobile Carrier System
`
`Data required to authorize transfer
`in mobite payment system
`
`
`
`Bate required to autherize
`transaction in payment gateway
`
`Payment Gateway
`
`Data required to notify merchant
`that transactien is authorized
`
`
`325 ""2
`
`.
`P08 {Bevme
`
`fl
`
`FIG. 3
`
`Google LLC v. RFCyber Corp. / Page 4 of 12
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 4 of 12
`
`PGR2022-00003
`Apple EX1013 Page 4
`
`

`

`Patent Application Publication
`
`Jun. 27, 2013 Sheet 4 0f 5
`
`US 2013/0166448 A1
`
`
`
`
`
`
`
`Point of Sale
`
`Device
`
` "
`
`‘\
`,
`/
`‘ /
`MéEChaB-t
`
`payer
`
`FIG. 4
`
`Google LLC v. RFCyber Corp. / Page 5 of 12
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 5 of 12
`
`PGR2022-00003
`Apple EX1013 Page 5
`
`

`

`Patent Application Publication
`
`Jun. 27, 2013 Sheet 5 0f 5
`
`US 2013/0166448 A1
`
`
`
`FIG. 5
`
`
`
`Google LLC v. RFCyber Corp. / Page 6 of 12
`
`
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 6 of 12
`
`PGR2022-00003
`Apple EX1013 Page 6
`
`

`

`US 2013/0166448 A1
`
`Jun. 27, 2013
`
`FINANCIAL TRANSFERS FROVI MOBILE
`DEVICES
`
`RELATED APPLICATION DATA
`
`[0001] This application claims priority to Indian Patent
`Application No. 4607/CHE/2011, filcc Dec. 27, 2011, and
`Indian Patent Application No. 4608/CHE/201 1, filed Dec. 27,
`2011, both of which are hereby incorporated by reference in
`its entirety.
`
`
`
`BACKGROUND
`
`[0002] Credit cards allow users to carry less liquid cur-
`rency. However, despite the security mechanisms imple-
`mented in relation to credit card transactions, credit card users
`continue to placc themselves at risk. If a credit card is stolen,
`the thief can very quickly charge up to the credit limit before
`the card owner even realizes that the credit card is missing.
`Additionally, because most credit card authorizations only
`require information that is plainly visible on the card (e.g., the
`account number, owner name, expiration date, and Card
`Security Code (“CSC”)), a duplicitous cashier or call center
`worker may copy down the credit card authorization infor-
`mation to make unauthorized transactions without even steal-
`ing the physical card. More recently, some cards have incor-
`porated Radio Frequency Identification (“RFID”) and similar
`short-range wireless communication systems to allow for
`morc convcnicnt “touchlcss” credit card transactions How-
`ever, such wireless credit cards have reduced security even
`further by allowing for hands—free theft by homemade scan—
`ning devices.
`[0003]
`To both increase security and convenience, many
`companies have been working to develop mo bile device (e.g,,
`mobile phone) based payment systems as substitutes for con-
`ventional credit cards. While such payment systcms allcviatc
`some security concerns presented by credit cards, they also
`perpetuate others. For example, mobile device based payment
`systems generally include personal information and account
`information on the device itself, so if a thief steals the device
`they may gain access to the device owner’s account informa-
`tion. Additionally, known mobile device payment systems
`usually include a close-range wireless connection between
`the mobile device and a Point-of-Sale (“POS”) device (eg,
`via Near Field Communication ("NFC”)) for the mobile
`device to transmit payment information. Such transmissions
`may still enable sophisticated thieves to intercept account
`information.
`
`Still other systems attempt to increase security by
`[0004]
`allowing for a user to provide their account information to a
`merchant then requiring independent authorization by the
`user via their mobile device before the payment can be autho-
`rized. In such a system, the merchant’s POS device may
`submit a rcqucst for authorization of a chargc, the submission
`including thc uscr’s account information. A back-cnd pay-
`ment systcm may then scnd a message (c.g., a Short Mcssagc
`Service (“SMS”) message) to the user’s mobile device
`requesting authorization of the charge. The user may then
`authorize the completion of the transaction by either provid-
`ing a code to the merchant (e.g., a code received via an SMS
`message) or may respond to the message and the back-end
`system may transmit authorization to the merchant. However,
`in similar fashion to conventional credit cards and mobile
`device payment systems using NFC,
`these systems still
`require sensitive data relating to a user’s account to be trans-
`
`mitted between a user and a merchant or between a user’s
`dcvicc and a mcrchant’s dcvicc.
`[0005]
`Improved mobile financial
`dcsircd.
`
`transfer systems are
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`
`
`F G. 1 shows an exemplary architecture for making
`[0006]
`financial transfers from a mobile device.
`[0007]
`F G. 2 shows a process flow for a mobile payment
`system to receive a request for a financial transfer from a
`mobile device, determine whether the transfer is authorized,
`and, if the transfer is authorized, provide the appropriate
`information to a payment gateway.
`[0008]
`FIG. 3 shows an exemplary data flow illustrating
`that the mobile payment system may be deployed within
`existing payment gateway architectures without modifica-
`tion.
`FIG. 4 shows an exemplary architecture for making
`[0009]
`financial transfers from a mobile device where the mobile
`device receives data from the point of sale device,
`[0010]
`FIG. 5 shows an exemplary computing device useful
`for performing processes disclosed herein.
`[0011] While systems and methods are described herein by
`way of example and embodiments, those skilled in the art
`recognize that systems and methods for financial transfers
`from mobile devices are not limited to the embodiments or
`drawings described. The drawings and description are not
`intended to be limiting to the particular fonn disclosed.
`Rather, the intention is to cover all modifications, equivalents,
`and alternatives falling within the spirit and scope of the
`appended claims. Any headings used herein are for organiza-
`tional purposcs only and arc not mcant to limit thc scope of
`the description or the claims. As used herein, the word “may”
`is used in a permissive sense (i.e., meaning having the poten—
`tial to) rather than the mandatory sense (i.e., meaning must).
`Similarly, the words “include,” “including,” and “includes”
`mean including, but not limited to.
`
`DETAILED DESCRIPTION
`
`[0012] Disclosed embodiments provide systems, com-
`puter-implemented methods, and computer-readable media
`for performing financial transfers with mobile devices, such
`as smartphones (e.g., phones using the iOS, Android, or
`BlackBeny OS operating systems) and tablets. In contrast to
`the many solutions being developed to allow a person to
`initiate a financial transfer by having their mobile device
`operatively couple with a POS device as described in the
`background, cmbodimcnts may allow a user to initiatc a
`sccurc financial transfcr using thcir mobilc device without
`communicating any account information directly to the iner—
`chant. Thus, embodiments may transfer absolutely no
`account information from a mobile device to a POS device
`that a duplicitous employee could steal.
`[0013] Additionally, thc systcms discloscd in thc back-
`ground each include their own infrastructure which may be
`expensive to deploy. For example, modern credit card sys—
`tems generally require scanning devices associated with POS
`devices that communicate with a payment gateway or front-
`end credit card proces sing system via a network cormection to
`determine Whether a charge is authorized (i.e., whether both
`the account is valid and whether the amount is authorized).
`Currently suggested mobile device payment systems require
`installation of expensive new equipment at POS devices and
`
`Google LLC v. RFCyber Corp. / Page 7 of 12
`
`6006-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 7 of 12
`
`PGR2022-00003
`Apple EX1013 Page 7
`
`

`

`US 2013/0166448 A1
`
`Jun. 27, 2013
`
`new back-end infrastructures. In contrast to these expensive-
`to-deploy systems, embodiments may utilize existing pay-
`ment gateways. Thus, embodiments may be less expensive to
`deploy than current mobile device payment systems because
`they do not require new hardware to be integrated with POS
`devices or new back-end infrastructures.
`
`FIG. 1 shows an exemplary architecture 100 for
`[0014]
`making financial transfers from a mobile device. In a typical
`POS transaction, a payer 115 purchases goods or services
`from a merchant 13 0. Rather than paying with cash or a credit
`card, embodiments may allow payer 115 to utilize an appli-
`cation on their mobile device 105 to pay the merchant. At the
`POS, the merchant 130 may provide the payer with a unique
`Merchant Identification Number (“MIDN”). The MIDN may
`be a unique identifier useful for a payment gateway 125
`(discussed further below) to identify the merchant’s account.
`The merchant 130 may also provide payer 115 with a total
`amount for a purchase of goods or services.
`[0015] Next, payer 115 may enter the MIDN identifying
`who will receive the financial transfer, the amount of the
`financial transfer, and a unique user identifier (“UUI”) into a
`user interface (“III”) ofthe mobile device. Embodiments may
`also allow the payer l 15 to enter additional information, for
`example a memo line may allow the payer 115 to include a
`note relating to the transaction for their own record keeping.
`The UUI may be a Personal Identification Number (“PIN”),
`an alpha—numeric password, or an answer to a payer—specific
`question. In some embodiments, the UUI may be any other
`user input, such as a pattern or drawing traced on a touch-
`screen display. In some embodiments, the UUI may be a
`biometric input (e.g., a voice-recognized word or phrase, a
`detected fingerprint, a detected iris pattern, a detected face,
`etc). Biometric input may be detected via conventional
`mobile device input cevices (e.g., microphones, cameras,
`touch-displays, etc.) or may be input by special purpose
`devices integrated into or coupled to the mobile device (e.g.,
`finger print readers). Embodiments may be configured to
`utilize one or more of these or other UUIs according to spe—
`cific security needs and device capabilities.
`[0016] The mobile device 105 may then transmit the UUI,
`MIDN, and amount, as well as a mobile device identifier
`(“MDI”) to a back—end mobile payment system 120. The MDI
`may be a hardware specific identifier, such as an International
`Mobile Equipment Identity (“IMEI”) number. Such an iden—
`tifier may identify the exact mobile device making the trans-
`mission. Alternatively, the mobile device identifier may be a
`phone number or identifier assigned to the mobile device by a
`mobile carrier.
`
`
`
`[0017] While FIG. 1 shows the transmission directly from
`mobile device 105 to mobile payment system 120, the trans—
`mission may pass through one or more intermediaries. For
`example, the transmission may be via an application or web
`app running on mobile device 105 and the connection may be
`made to a destination Uniform Resource Locator (“URL”),
`Internet Protocol (“IP”) address, or any other address. In such
`embodiments, the mobile device 105 may transmit via a
`mobile carrier’s network (e.g., a 4G network) and the mobile
`carrier may then route the transmission to the mobile payment
`system 120 Via one or more other networks, such as the
`internet.
`
`[0018] Once the mobile payment system 120 receives the
`IVHDN, UUI, MDI, and transfer amount, the mobile payment
`system may perform the process flow shown in FIG. 2. FIG.
`2 shows a process flow 200 for a mobile payment system 120
`
`to receive a request for a financial transfer from a mobile
`device, detemiinc whether the transfer is authorized, and, if
`the transfer is authorized, provide the appropriate infomtation
`to a payment gateway. As shown in process flow 200, at step
`205 the payment system may receive the MIDN, at step 210
`the payment system may receive the UUI and MDI, and at
`step 215 the payment system may receive the transfer amount.
`Steps 205, 210, and 215 may occur in any order or simulta-
`neously. In each of these steps the received information may
`be encrypted, for example using a private key or certificate. If
`the received information is encrypted, the system may also
`decrypt all received information.
`[0019] Next, at step 220 the system may determine whether
`the UUI and MDI correspond to an authorized account. For
`example, a dataset of authorized accounts may store for each
`account one or more UUIs of authorized users and one or
`more MDIs of authorized mobile devices. In such embodi-
`ments, the system may perform a search of all accounts to
`determine whether an authorized account corresponds to both
`the received UUI and the received MDI. At step 225, if it is
`determined that the received identification information cor-
`responds to an authorized account, the system may transmit
`account information associated with the UUI and MIDI, the
`MIDN, and the transfer amount to a payment gateway asso—
`ciated with the authorized account in step 230 (e.g., payment
`gateway 125 shown in FIG. 1). The account information,
`MIDN, and transfer amount may be transferred to a payment
`gateway in a conventional format, for example using the
`format currently utilized for credit cards or debit cards. Alter-
`natively, if it is determined that the request is not valid, an
`authorization failure message may be transmitted back to the
`attempting payer’s device or any other device or system in
`step 235.
`[0020] By way of example, a UUI password “password”
`and an MDI “12345” may be registered with an account
`associated with a credit card having a name “John Doe”, a
`number “1234 5678 9101 1213”, an expiration date “01/13”,
`and a CSC “123”. If in step 210 the system received the UUI
`“password” and an MDI “12345”, at step 220 the system may
`determine that the request is an authorized request for a finan—
`cial transfer from John Doe’s account and at step 230 the
`system may transmit a request to a payment gateway includ—
`ing accotmt information such as John Doe’s name, credit card
`number, credit card expiration date, and CSC as well as the
`transfer amount and the MIDN. Because existing payment
`gateways are configured to receive these data, embodiments
`may be deployed within existing system architectures with-
`out requiring any modification to credit card payment gate-
`ways or merchant POS devices.
`[0021] After the system transmits the MIDN, account infor—
`mation, and transfer amount to a payment gateway in step
`230, the system may optionally be configured to receive a
`confirmation or denial from the payment gateway. The system
`may then be configured to transmit the confirmation or denial
`to the payer’s mobile device in step 245.
`[0022] While the above example references a credit card
`account, embodiments may be configured to work with any
`account architecture. For example, if being utilized within a
`debit card account system. the system may have a Personal
`Identification Number (“PIN”) associated with an account
`and may transmit the PIN to the payment gateway along with
`all other necessary information to make the transfer. Still
`other embodiments may be configured to utilize less conven-
`tional systems, such as systems for redeeming accrued bonus
`
`Google LLC v. RFCyber Corp. / Page 8 of 12
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 8 of 12
`
`PGR2022-00003
`Apple EX1013 Page 8
`
`

`

`US 2013/0166448 A1
`
`Jun. 27, 2013
`
`Li.)
`
`points (e.g., airline points on an airline credit card), systems
`for making PayPal purchases, and the like.
`[0023] Referring again to FIG. 1, if authorized by the
`mobile payment system 120, the transfer request (including
`all necessary account information, the transfer amount, and
`the MIDN) may be transmitted to the payment gateway 125.
`While payment gateway 125 is illustrated as a single entity in
`FIG. 1 and described above in the context of a credit card
`payment processor, the payment gateway may be any system
`that facilitates the transfer of information between the mobile
`payment system 120 and the front-end processor of a credit
`card provider, a bank, or any other institution that can autho-
`rize the payment. In some embodiments, existing systems,
`such as Sybase 365 systems, may be utilized as the payment
`gateway 125.
`[0024]
`If the payment gateway authorizes or receives
`authorization of the payment, the payment gateway may
`transmit the payment authorization to the point of sale device
`110. The MIDN may include sufficient information for the
`payment gateway to contact the POS device (e.g., a URL, IP
`address, phone number, etc). The merchant 130 may then
`observe the confirmed payment and provide the purchased
`goods or services to the payer 1 [5.
`[0025] As FIGS. 1 and 2 show, embodiments allow for a
`payer 115 to transfer finances to merchant 130 without dis-
`closing any potentially sensitive information to the merchant.
`While the payer 1 [5 may provide a general identifier, such as
`the payer’s name, to the merchant so that the payment autho-
`rization may be matched to the specific payer 115, embodi—
`ments alleviate the need to provide any account related infor—
`mation (e.g., account numbers, credit card numbers, PINs,
`etc.) that could be stolen to make fraudulent purchases. This
`provides a benefit over system that utilize NFC or similar
`technologies to pass “secure” data between a mobile device
`and a POS device because even such “secure” data may be
`intercepted and potentially used to provide unauthorized
`access to payer 115’s account,
`[0026] These figures also show that the mobile device does
`not require access to any account information at all. Rather,
`the mobile device only requires an application to be installed
`or run from a web browser. Even this application does not
`need to know any of the payer’s account information; it sim-
`ply detects the MDI and allows a user to enter their U U1. The
`mo bile payment system securely maintains associations
`between accounts and one or more corresponding MD] and
`UUI. Thus, even ifthe mobile device is lost or stolen, it has no
`account information that could be extracted to make fraudu-
`lent payments.
`[0027]
`FIG. 3 shows an exemplary data flow 300 illustrat-
`ing that the mobile payment system may be deployed Within
`existing payment gateway architectures without modifica-
`tion. Additionally, data flow 300 illustrates that the informa-
`tion transmitted from the mobile device may contain no user
`account information. First, mobile device 305 may receive a
`request for a transaction from a user. For example, a user may
`enter a merchant ID, a transaction amount, and a secure
`identifier (e.g., password) into an application’s or web app’s
`UI. Mobile device 305 may then transmit all data required to
`authorize the transfer in mobile payment system 315 across a
`mobile network to a mobile carrier system 310. This infor-
`mation may include both the information input by the user
`and a device identifier. This information does not need to
`include any account information. The mobile carrier system
`310 may then pass the data on without modification to the
`
`mobile payment system 315, for example by routing the data
`from the mobile network to another network (e.g., the inter-
`net).
`[0028] Mobile payment system 315 may receive and pro-
`cess the data to determine whether the secure identifier and
`the device identifier correspond to an authorized accotmt. If
`they correspond to an authorized account, the account may
`include data indicating a payment gateway for the user as well
`as account details for the user. Mobile payment system 315
`may then transmit to the payment gateway 320 all data
`required to authorize the transaction, such as a credit card’s
`user name, number, expiration date, and CSC, an amount of
`the transfer, and an identification of the merchant account to
`receive the transfer. The payment gateway 320 may receive
`the data transmitted from the mobile payment system 315 and
`process it in conventional fashion. If the payment is autho-
`rized, the payment gateway 320 may transmit a notification of
`the authorization and any relevant information (e.g., the
`authorized user, the amount, the date the transaction will
`settle, etc.) to the POS device 325. Altematively, if the trans-
`action is not authorized (e.g., the account is ovcrdrawn or has
`been closed), the payment gateway 320 may transmit a noti—
`fication ofthe denial to the POS device 325. While not shown,
`the payment gateway 320 may also transmit a notification of
`authorization or denial back to the mobile payment system
`315 which may, in turn, ultimately transmit a notification
`back to the mobile device 305. Once the POS device 325
`receives a notification that the payment is authorized, a mer-
`chant may give the user the goods or services they are pur-
`chasing.
`[0029] As shown in FIG. 3, a user may avail embodiments
`across the globe and independent of the telecom service pro-
`vider providing mobile network access. Because embodi-
`ments only require network connectivity (e.g., via wired or
`wireless networks), embodiments may be completely carrier
`independent. Alternatively, some embodiments may require
`all payment requests to be received from a specific mobile
`carrier to provide an additional level ofsecurity at the expense
`of cross-platform convenience.
`[0030] While in the above discussed embodiments a user
`may input all necessary data into their mobile device, in
`alternative embodiments
`some necessary data may be
`received by the mobile device in alternative fashions. FIG. 4
`shows an exemplary architecture 400 for making financial
`transfers from a mobile device where the mobile device
`receives data from the point ofsale device. In such an embodi-
`ment, mobile device 105 may receive at least one of the
`amount of the transaction and the merchant’s identification
`automatically. For example, a camera on a mobile device may
`be utilized optically recognize at least one of the MIDN and
`the amount of the transfer from a barcode, Quick Response
`(“QR”) code, screen readout, and the like. Alternatively, a
`wireless conununication coupling, (e.g., via NFC) may be
`utilized to transmit at least one of the MIDN and the amount
`from the POS device to the mobile device. However, even
`though information relating to the transaction may be trans-
`mitted from the POS device 110 to the mobile device 105, this
`embodiment may still avoid transmitting any account related
`information from the mobile device 105 to the POS device
`110. The remaining architecture 400 may process a financial
`transaction in similar fashion to architecture 100 described in
`reference to FIG. 1 above.
`
`[0031] While the above embodiments generally describe
`financial transfers occurring at POS devices, embodiments
`
`Google LLC v. RFCyber Corp. / Page 9 of 12
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 9 of 12
`
`PGR2022-00003
`Apple EX1013 Page 9
`
`

`

`US 2013/0166448 A1
`
`Jun. 27, 2013
`
`may be implemented to allow for other secure financial trans-
`actions to be initiated from a mobile device. For example,
`embodiments may be utilized for a user to make on—line
`purchases. In such embodiments, an ecommerce website may
`provide and MIDN and total amount of a purchase at check—
`out. The customer (i.e., a user) may then initiate the financial
`transfer on their mobile device by entering in the MIDN, total,
`and their UUI into an appropriate application. Alternatively.
`at least one of the MIDN and total may be automatically
`received by the mobile device from the ecommerce website
`(e. g., ifthe website were accessed via a browser on the mobile
`device). In such on—line purchase embodiments, a user may
`purchase from any ecommerce website without disclosing
`any account information to the website. Such embodiments
`may prevent an ecommerce website worker from stealing
`account information to make fraudulent purchases. Such
`embodiments may also be configured to avoidphishing scams
`by having the payment gateway validate all MIDNs.
`[0032] Embodiments may also be configured to allow a
`user to transfer money to another user. For example, indi—
`vidual users may register accounts with a payment gateway
`and receive a MIDN in similar fashion to how a merchant
`would. The receiving user (i.e., payee) may then tell
`the
`paying user (i.e., payer) their MIDN and the paying user may
`enter the amount, the receiving user’s MIDN, and their UUI
`into an application to initiate the transfer in similar fashion to
`the above description of FIG. 1. In other embodiments, the
`users’ phones may operatively couple to allow the payee’s
`phone to transmit the payee’s MIDN to the payer’s phone
`(c.g., the phones may “bump” using NFC). In such embodi-
`ments, a payer’s phone may transmit no account information
`to the payee’s phone.
`[0033] Embodiments may be configured to accept voice
`commands for performing all transactions. Such embodi-
`ments may be configured to recognize the voice of only a
`specific authorized user. Such embodiments may be useful to
`both biometrically authenticate an authorized user and to
`allow for hands—free use of the mobile device.
`
`[0034] Embodiments may also be configured to store
`receipts or other transaction related data. For example, a
`mobile device may be configured to receive a receipt from a
`POS device, for example over NFC. The mobile device may
`store a local copy of the receipt for later review, may upload
`the receipt to cloud storage, may upload the receipt to the
`mobile payment system (which itself may be in the cloud), or
`may otherwise process the receipts or other transaction data.
`In some embodiments, the mobile device may store received
`receipts locally until the device receives network connectivity
`and then transfer the receipts to cloud storage.
`[0035]
`In addition to allowing the user to pay the amount
`indicated by a merchant, embodiments may allow a user to
`enter a tip amount. For example, embodiments may include a
`tip calculator in an application to allow the user to enter a tip
`by tip amount, by tip percentage, or by quality ofservice (e.g.,
`the calculator may add 0% for awful service, 5% for poor
`service, 15% for good service, and 25% for exceptional ser-
`vice).
`[003 6] Embodiments may also be configured to provide ads
`or promotions to a user interface. For example, embodiments
`may provide a user with directed promotions based on previ-
`ous purchases or other financial transfers. Thus, embodi-
`ments may conveniently help a user to find the best deals
`based on their individual habits. Embodiments may allow the
`user to redeem promotions directly from their mo bile device,
`
`for example by selecting a promotion and providing their III II
`to authorize the purchase of the promoted goods or services.
`[0037] Embodiments may also provide accotmt manage-
`ment tools. For example, embodiments may provide tools to
`allow a user to close an account, view a transaction history,
`cancel a credit card payment (e.g., because a purchased prod-
`uct is defective), View an account balance, and the like.
`
`Embodiments may also allow for a bank or financial institu—
`tion to push information to a user via their mobile device, for
`example messages about the user’s account (e.g., e—state—
`ments), notifications offee changes, promotions, and the like.
`[0038] The embodiments described herein may be imple—
`mented with an application run on a mobile device. The
`application may, for example, be downloaded from a bank’ 5
`website. The downloaded application may be configured to
`know the authorized payment gateway for the account. When
`the application is installed, it may automatically retrieve the
`IMEI and other details of the phone on which it is installed. A
`user may then simply register their UUI with the bank to
`complete initial authorization of the mobile financial transfer
`system.
`[0039] Other embodiments may utilize web apps (i.e.,
`applications
`executed through an internet
`connected
`browser). Such embodiments may provide a user with con-
`venient access to their account without requiring installation
`of an application on their mobile device. In such embodi-
`ments, the user may register their mobile device’s IMEI with
`tlicirbank. Then, when thcweb app is usedto make a financial
`transfer, the user may enter their UUI and he web app may
`
`automatically detect the mobile devices IMEI to authenticate
`the transfer.
`
`In still other embodiments, the application may be
`[0040]
`made an integral part ofthe operating system image installed
`on the mobile device. Such embodiments may provide addi—
`tional security since the application cannot be easily unin—
`stalled or tampered with.
`[0041]
`Further, embodiments may be used in conjunction
`with conventional payments systems. For example, a bank
`may issue a credit card and authorize a mobile financial
`transfer account for the same user. In such embodiments a
`user may chose to use their credit card ifthey do not have their
`phone with them or may use their mobile phone to initiate a
`transaction if they do not have their credit card with them or
`if they wish to perform the transaction with additional secu-
`rity. In such embodiments, an application useful for perform-
`ing the secure mobile financial transaction may also be useful
`for managing transactions made with the credit card. Such
`embodiments may also utilize other known mobile financial
`service systems, such as Google Wallet, on the same mobile
`device.
`[0042] The above embodiments generally describe the
`MDI being a mobile phone’s IMEI. In alternative embodi-
`ments, the MDI may be data stored on a Subscriber Identifi-
`cation Modulc (“SIM”) card provided by a mobile carrier. In
`still other embodiments, the MDI may be provided by a soft
`SIM image, such as the soft SIM image describe in the patent
`application filed concurrently herewith titled “METHOD
`AND APPAR