(19) United States
`a2) Patent Application Publication co) Pub. No.: US 2013/0166448 Al
`
` Narayanan (43) Pub. Date: Jun. 27, 2013
`
`
`US 20130166448A1
`
`(54) FINANCIAL TRANSFERS FROMMOBILE
`DEVICES
`
`(52) U.S.Cl.
`USPC.
`ccecssssssssssseceessssssssssssesnssssteanssseeeees 705/44
`
`(75)
`
`Inventor: Anoop Narayanan. Kottayam (IN)
`
`(73) Assignee:
`
`INFOSYS LIMITED. BANGALORE
`(IN)
`
`(21) Appl. No.: 13/418,318
`
`(22)
`
`Filed:
`
`Mar. 12, 2012
`
`(30)
`
`Foreign Application Priority Data
`
`Dec. 27, 2011
`Dec. 27, 2011
`
`IN) wae cee 4607/CHE/2011
`CIN) wae 4608/CHE/2011
`Publication Classification
`
`(51)
`
`Int. Cl
`G06Q 20/40
`G06Q 20/32
`
`(2012.01)
`(2012.01)
`
`(57)
`
`ABSTRACT
`
`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 whetherthe transactionis autho-
`rized based on the mobile device identifier and the unique
`useridentifier; 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 determined that
`the transaction is not authorized; and transmitting to a pay-
`ment gatewayan accountidentifier associated with the unique
`user identifier and mobile device identifier, the merchant
`identifier, and the amountifit is determined that the transac-
`tion is authorized.
`
`10
`
`
`
`
`
`Mobile 2.
`Device
`
`105
`
`3
`
`110 ~
`
`SOP
`
`Point of Sale
`Device
`
`
`
`
`
`V3
`Merchant
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 1 of 12
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 1 of 12
`
`

`

`Patent Application Publication
`
`Jun. 27,2013 Sheet 1 of 5
`
`US 2013/0166448 Al
`
`10
`
`
`
`
`
`105
`
`Point of Sale
`Device
`
`6
`
` ms,
`Mobile 2.
`Device
`
`2
`
`
`
`4
`
`VY
`f_f
`Merchant
`
`Yf
`
`\ \
`
`Google LLC v. RFCyber Corp. / Page 2 of 12
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 2 of 12
`
`

`

`Patent Application Publication
`
`Jun. 27,2013 Sheet 2 of 5
`
`US 2013/0166448 Al
`
`205 ~
`
`210
`
`215
`
`
`
`
`Receive
`
`MIDN
`
`| Receive UUl
`|
`|
`
`sand MDI
`
`|
`
`reoee
`Amount
`
`220~“/PasninWhether UU! and MDI Correspond
`
`to an Authorized Account
`
`Transmit Authorization Failure
`Transmit MIDN, Account, and |
`
` _ Amount to Payment Gateway Message
`
`oeVo, i
`Receive Confirmation or
`Transmit Confirmation or
`Denial
`|
`Denial to Mobile Device
`
`240 ~ {
`00
`
`FIG. 2
`
`245°
`
`Google LLC v. RFCyber Corp. / Page 3 of 12
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 3 of 12
`
`

`

`Patent Application Publication
`
`Jun. 27, 2013 Sheet 3 of 5
`
`US 2013/0166448 Al
`
`305 ~
`
`Mobile Device
`
`Data required to authorize transfer
`in mobile payment system
`
`;
`310 >
`“| Mobile Carrier System
`
`
`
`Data required to authorize transfer
`in mobile payment system
`
`315 >
`
`Data required to authorize
`transaction in payment gateway
`
`320 >
`“Payment Gateway
`
`Data required to nolify merchant
`that transaction is authorized
`
`
`325 ~
`os
`
`POS Device
`
`300
`
`FIG. 3
`
`Google LLC v. RFCyber Corp. / Page 4 of 12
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 4 of 12
`
`

`

`Patent Application Publication
`
`Jun. 27,2013 Sheet 4 of 5
`
`US 2013/0166448 Al
`
`Point of Sale
`
`
`Device
`
` of
`
`{
`
`SON
`/
`
`Payer
`
`Merchant
`
`FIG. 4
`
`Google LLC v. RFCyber Corp. / Page 5 of 12
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 5 of 12
`
`

`

`Patent Application Publication
`
`Jun. 27,2013 Sheet 5 of 5
`
`US 2013/0166448 Al
`
`
`
`FIG. 5
`
`
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 6 of 12
`
`
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 6 of 12
`
`

`

`US 2013/0166448 Al
`
`Jun, 27, 2013
`
`FINANCTATLTRANSFERS FROM MOBILE
`DEVICES
`
`RELATED APPLICATION DATA
`
`
`
`[0001] This application claims priority to Indian Patent
`Application No. 4607/CHE/2011, filed Dec. 27, 2011, and
`Indian Patent Application No. 4608/CHE/2011, 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. [lowever, despite the security mechanisms imple-
`mentedin relation to credit card transactions, credit card users
`continue to place themselvesat risk. If a credit cardis 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 informationthat 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 downthe 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
`more convenient “touchless” 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 mobile device (e.¢.,
`mobile phone) based payment systemsas substitutes for con-
`ventional credit cards. While such payment systemsalleviate
`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 deviceitself, so ifa thief steals the device
`they maygain accessto 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 (e-.g.,
`via Near Field Communication (‘NFC”)) for the mobile
`device to transmit payment information. Such transmissions
`maystill 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
`uservia their mobile device before the payment can be autho-
`rized. In such a system, the merchant’s POS device may
`submit a requestfor authorization of a charge, the submission
`including the user’s account information. A back-end pay-
`ment system may then send a message(c.g., a Short Message
`Service (“SMS”) message) to the user’s mobile device
`requesting authorization of the charge. The user may then
`authorize the completion of the transactionbyeither 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
`device and a merchant’s devicc.
`[0005]
`Improved mobile financial
`desired.
`
`transfer systems are
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 shows an exemplaryarchitecture for making
`[0006]
`financial transfers from a mobile device.
`[0007]
`FIG. 2 showsa process flowfor a mobile payment
`system to receive a request for a financial transfer from a
`mobile device, delermine 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 exemplaryarchitecture 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 methodsare described herein by
`way of example and embodiments, those skilled in the art
`recognize thal 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 form disclosed.
`Rather, the intentionis to cover all modifications, equivalents,
`and alternatives falling within the spirit and scope of the
`appendedclaims. Any headings used herein are for organiza-
`tional purposes only and are not meantto limit the scope of
`the description orthe claims. As used herein, the word “may”
`is used in a permissive sense(i.e., meaning having the poten-
`3 kes
`tial to) rather than the mandatorysense(1.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 10S, Android, or
`BlackBerry OSoperating 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, embodiments may allow a user to initiate a
`secure financial transfer using their mobile device without
`communicating any account information directly to the mer-
`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, the systems disclosed in the back-
`ground each include their own infrastructure which maybe
`expensive to deploy. For example, modern credit card sys-
`tems generally require scanning devices associated with POS
`devices that communicate with a payment galewayor front-
`end credit card processing systemvia a network connectionto
`determine whether a charge is authorized (i.e., whether both
`the account is valid and whether the amountis 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
`
`GOOG-1013
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 7 of 12
`
`

`

`US 2013/0166448 Al
`
`Jun, 27, 2013
`
`newback-endinfrastructures. In contrast to these expensive-
`to-deploy systems, embodiments may utilize cxisting pay-
`ment gateways. Thus, embodiments maybe less expensive to
`deploythan current mobile device payment systems because
`they do not require new hardwareto 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 130. Rather than paying with cash ora credit
`card, embodiments may allowpayer 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”). ‘lhe MIDN may
`be a unique identifier useful for a payment gateway 125
`(discussed further below) to identify the merchant’s account.
`The merchant 130 mayalso provide payer 115 with a total
`amountfor a purchase of goodsorservices.
`[0015] Next, payer 115 may enter the MIDN identifying
`who will receive the financial transfer, the amount of the
`financialtransfer, and a unique useridentifier (“UUT’) into a
`userinterface (“UT”) ofthe mobile device. Embodiments may
`also allow the payer 115 to enter additional information, for
`example a memo line mayallow the payer 115 to include a
`note relating to the transaction for their own record keeping.
`The UUI maybe a Personal Identification Number (“PIN”),
`an alpha-numeric password, or an answerto a payer-specific
`question. In some embodiments, the UUI maybe any other
`user input, such as a pattern or drawing, traced on a touch-
`screen display. In some embodiments, the UUI maybe 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 devices (e.g., microphones, cameras,
`touch-displays, ctc.) 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 ofthese 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 aback-end mobile payment system 120. The MDI
`may bea hardware specific identifier, such as an International
`Mobile Equipment Identity (“IMEI”) number. Such an iden-
`lifier may identify the exact mobile device making the trans-
`mission. Alternatively, the mobile device identifier may be a
`phone numberoridentifier assigned to the mobile device by a
`mobile carrier.
`
`
`
`[0017] While FIG. 1 showsthe transmissiondirectly from
`mobile device 105 to mobile payment system 120, the trans-
`mission may pass through one or more intermediaries. For
`example, the transmission maybe 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 maythen 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
`MIDN, UUI, MDI, and transfer amount, the mobile payment
`system mayperformthe process flow shownin FIG. 2. FIG.
`2 showsa process flow 200 for a mobile payment system 120
`
`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. As shownin process flow 200, at step
`205 the payment system mayreceive the MIDN,at step 210
`the payment system may receive the UUI and MDI, and at
`step 215 the payment system mayreceive the transfer amount.
`Steps 205, 210, and 215 mayoccur in any order or simulta-
`neously. In each ofthese steps the received information may
`be encrypted, for example using a private key or certificate. [f
`the received. information is encrypted, the system may also
`decryptall 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 UUlIs of authorized users and one or
`more MDIs of authorized mobile devices. In such embodi-
`ments, the system may performa search ofall accounts to
`determine whether an authorized account corresponds to both
`the received UUTand the received MDI. At step 225, if it is
`determined that the received identification information cor-
`responds to an authorized account, the system maytransmit
`account information associated with the UUI and MDI, the
`MIDN,andthe transfer amount to a payment gateway asso-
`ciated with the authorized account in step 230 (e.g., payment
`galeway 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 maybe transmitted back to the
`attempting payer’s device or any other device or system in
`step 235.
`[0020] Bywayof example, a UUI password “password”
`and an MDI “12345” maybe 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”. Ifin step 210 the system received the UUI
`“password”and an MDI “12345”, at step 220 the system may
`determinethat the request is an authorized requestfor 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 account 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 exisling 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] Afterthe system transmits the MIDN,account infor-
`mation, and transfer amount to a payment gateway in step
`230, the system mayoptionally be configured to receive a
`confirmationor denial from the payment gateway. The system
`maythen 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 gatewayalong 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
`
`

`

`US 2013/0166448 Al
`
`Jun, 27, 2013
`
`Go
`
`mobile payment system 315, for example by routing the data
`points (e.g., airline points on an airline credit card), systems
`from the mobile network to another network (c.g., the inter-
`for making PayPal purchases, and thelike.
`net).
`[0023] Referring again to FIG. 1, if authorized by the
`mobile payment system 120, the transfer request (including
`[0028] Mobile payment system 315 may receive and pro-
`cess the data to determine whether the secure identifier and
`all necessary account information, the transfer amount, and
`the device identifier correspond to an authorized account. If
`the MIDN) maybe transmitted to the payment gateway 125.
`While payment gateway125is illustrated as a single entity in
`they correspond to an authorized. account, the account may
`FIG. 1 and described above in the context of a credit card
`include dataindicating a payment gatewayfor the user as well
`paymentprocessor, the payment gateway may be any system
`as account details for the user. Mobile payment system 315
`that facilitates the transfer of information between the mobile
`maythen transmit to the payment gateway 320 all data
`payment system 120 and the front-end processorof a credit
`required to authorize the transaction, such as a credit card’s
`card provider, a bank, or any otherinstitution that can autho-
`user name, number, expiration date, and CSC, an amount of
`the transfer, and an identification of the merchant account to
`rize the payment. In some embodiments, existing systems,
`such as Sybase 365 systems, may be utilized as the payment
`receive the transfer. The payment gateway 320 may receive
`gateway125.
`the data transmitted from the mobile payment system 315 and
`process it in conventional fashion. If the payment is autho-
`[0024]
`If the payment gateway authorizes or receives
`rized, the payment gateway 320 maytransmit a notification of
`authorization of the payment, the payment pateway may
`the authorization and anyrelevant information (e.g., the
`transmit the payment authorizationto the point ofsale device
`authorized user, the amount, the date the transaction will
`110. ‘the MIDN may include sufficient information for the
`settle, etc.) to the POS device 325. Alternatively, if the trans-
`payment gatewayto contact the POS device (e.g., a URL, 1P
`action is not authorized (c.g., the account is overdrawnor has
`address, phone number, etc.). The merchant 130 may then
`beenclosed), the payment gateway 320 maytransmit a noti-
`observe the confirmed payment and provide the purchased
`fication ofthe denial to the POS device 325. While not shown,
`goodsor services to the payer 115.
`the payment gateway 320 mayalso transmita notification of
`[0025] As FIGS. 1 and 2 show, embodiments allowfor a
`authorization or denial back to the mobile payment system
`payer 115 to transfer finances to merchant 130 without dis-
`315 which may, in turn, ultimately transmit a notification
`closing any potentially sensitive information to the merchant.
`back to the mobile device 305. Once the POS device 325
`While the payer 115 mayprovide a general identifier, such as
`receives a notification that the paymentis authorized, a mer-
`the payer’s name,to the merchantso that the payment autho-
`chant may give the user the goods or services they are pur-
`rization may be matchedto the specific payer 115, embodi-
`chasing.
`mentsalleviate the need to provide any accountrelated infor-
`[0029] As shown in FIG.3, a user may avail embodiments
`mation (e.g., account numbers, credit card numbers, PINs,
`across the globe and independentofthe telecom service pro-
`etc.) that could be stolen to make fraudulent purchases. This
`vider providing mobile network access. Because embodi-
`provides a benefil over system that utilize NFC or similar
`ments only require network connectivity (e.g., via wired or
`technologies to pass “secure” data between a mobile device
`wireless networks), embodiments may be completely carrier
`and a POS device because even such “secure” data may be
`independent. Alternatively, some embodiments may require
`intercepted and potentially used to provide unauthorized
`access to payer 115’s account.
`all payment requests to be received from a specific mobile
`carrier to provide an additional level ofsecurity at the expense
`[0026] These figures also show that the mobile device does
`of cross-platform convenience.
`not require access to any account informationat all. Rather,
`[0030] While in the above discussed embodiments a user
`the mobile device only requires an applicationto be installed
`mayinput all necessary data into their mobile device, in
`or run from a web browser. Even this application does not
`alternative embodiments
`some necessary data may be
`need to knowanyofthe payer’s account information; it sim-
`received by the mobile device in alternative fashions. FIG. 4
`ply detects the MD] and allowsa userto enter their UUI. The
`shows an exemplary architecture 400 for making financial
`mobile payment system securely maintains associations
`transfers from a mobile device where the mobile device
`between accounts and one or more corresponding MDI and
`UUT. Thus, even ifthe mobile deviceis lost or stolen, it has no
`receivesdata from the point of sale device. In such an embodi-
`account information that could be extracted to make fraudu-
`ment, mobile device 105 mayreccive at least one of the
`amountof the transaction and the merchant’s identification
`lent payments.
`automatically. For example, acamera on a mobile device may
`[0027]
`FIG. 3 shows an exemplarydata flow 300 illustrat-
`be utilized optically recognize at least one of the MIDN and
`ing that the mobile payment system maybe deployed within
`the amount ofthe transfer from a barcode, Quick Response
`existing payment gateway architectures without modifica-
`(“QR”) code, screen readout, and the like. Alternatively, a
`tion. Additionally, data flow 300 illustrates that the informa-
`wireless communication coupling (e.g., via NFC) may be
`tion transmitted from the mobile device may contain no user
`utilized to transmit at least one ofthe MIDN and the amount
`account information. First, mobile device 305 may receive a
`from the POS device to the mobile device. However, even
`request for a transaction from a user. For example, a user may
`though informationrelating to the transaction maybetrans-
`enter a merchant ID, a transaction amount, and a secure
`mitted from the POS device 110 to the mobile device 105, this
`identifier (e.g., password) into an application’s or web app’s
`embodiment maystill avoid transmitting any accountrelated
`UI. Mobile device 305 may thentransmitall data required to
`information from the mobile device 105 to the POS device
`authorize thetransfer in mobile payment system 315 across a
`110. The remaining architecture 400 may processafinancial
`mobile network to a mobile carrier system 310. This infor-
`transaction in similar fashion to architecture 100 described in
`mation may include both the information input by the user
`reference to FIG, 1 above.
`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
`
`[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
`
`

`

`US 2013/0166448 Al
`
`Jun, 27, 2013
`
`may be implementedto allow for other secure financialtrans-
`actions to be initiated from a mobile device. For cxample,
`embodiments maybe utilized for a user to make on-line
`purchases. In such embodiments, an ecommerce website may
`provide and MIDNandtotal amount of a purchase at check-
`oul. The customer(1.¢., a user) may then initiate the financial
`transfer on their mobile device byentering 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 mayalso be configured to avoid phishing scams
`byhaving the payment gatewayvalidate 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 (.e., payee) may then tell
`the
`payinguser(i.e., payer) their MIDN andthe paying user may
`enter the amount, the receiving user’s MIDN,and their UUI
`into an applicationto initiate the transfer in similar fashion to
`the above description of FIG. 1. In other embodiments, the
`users’ phones mayoperatively couple to allow the payee’s
`phone to transmit the payee’s MIDNto the payer’s phone
`(c.g., the phones may “bump” using NFC). In such embodi-
`ments, a payer’s phone maytransmit no account information
`to the payee’s phone.
`[0033] Lmbodiments may be configured to accept voice
`commands for performing all transactions. Such embodi-
`ments maybe configured to recognize the voice of only a
`specific authorized user. Such embodiments maybe useful to
`both biometrically authenticate an authorized user and to
`allowfor 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 maybe configured to receive a receipt from a
`POSdevice, for example over NFC. The mobile device may
`store a local copy ofthe receipt for later review, may upload
`the receipt to cloud storage, may upload the receipt to the
`mobile paymentsystem (whichitself maybein 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 applicationto allowthe user to enter a tip
`bytip amount, bytip 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).
`[0036] Embodiments may also be configured to provide ads
`or promotionsto a user interface. For example, embodiments
`may providea user with directed promotions based onprevi-
`ous purchases or other financial transfers. Thus, embodi-
`ments may conveniently help a user to find the best deals
`based ontheir individual habits. Embodiments may allow the
`user to redeem promotions directly from their mobile device,
`
`forexample by selecting a promotion and providing their UUT
`to authorize the purchase of the promoted goodsorservices.
`[0037] Embodiments may also provide account manage-
`menttools. for example, embodiments may providetools to
`allow a user to close an account, viewa 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 orfinancial 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, andthelike.
`[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’s
`website. The downloaded application may be configured to
`know the authorized payment gatewayfor the account. When
`the applicationis installed, it may automatically retrieve the
`IMEIand otherdetails ofthe phone on whichit is installed. A
`user may then simply register their UUJ with the bank to
`complete initial authorization ofthe mobile financial transfer
`system.
`[0039] Other embodiments may utilize web apps (ie.,
`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
`their bank. Then, when the web app is used to make a financial
`transfer, the user may enter their UUI and the web app may
`
`automatically detect the mobile devices IMEI to authenticate
`the transfer.
`
`Instill other embodiments, the application may be
`[0040]
`made anintegral 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 maybe used in conjunction
`with conventional payments systems. For cxample, a bank
`mayissue a credit card and authorize a mobile financial
`transfer account for the same user. In such embodiments a
`user may choseto usetheir credit card ifthey do not have their
`phonewith themor may use their mobile phoneto 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 financialtransaction mayalso be useful
`for managing transactions made with the credit card. Such
`embodiments mayalso utilize other known mobile financial
`service systems, such as Google Wallet, on the same mobile
`device.
`[0042] The above embodiments generally describe the
`MDIbeing a mobile phone’s IMEI. In alternative embodi-
`ments, the MDI maybe data stored on a Subscriber Identifi-
`cation Module (“SIM”) card provided by a mobilecarrier. In
`still other embodiments, the MD] maybeprovided bya soft
`SIM image, such as the soft SIM imagedescribein the patent
`application filed concurrently herewith titled “METHOD
`AND APPARATUSFOR REGISTERING A COMPUTING
`
`
`DEVICE WITH A SERVICE PROVIDER”invented by
`Anoop Narayanan having docket number IN-PED-0918, the
`entire contents ofwhichare incorporated herein byreference.
`The SIM image may be a read-only, encrypted copy of a
`physical SIM card. Such embodiments may incorporate an
`application or operating system level driver in the mobile
`
`
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 10 of 12
`
`GOOG-1013
`Google LLC v. RFCyber Corp. / Page 10 of 12
`
`

`

`US 2013/0166448 Al
`
`Jun, 27, 2013
`
`device for reading the soft SIM. The subscriber mayregister
`the IMEI numberofhis or her mobile device with the service
`providerandthe soft SIM,like a plastic SIM card, may have
`aunique cell numberto identify the Global System for Mobile
`Communications (“GSM”) subscriber. Embodiments using
`an MDI associated with a SIM card or soft SIM may conve-
`nientlyallow a user to maintain the same MD]associate