US20130166448A1 - Financial transfers from mobile devices - Google Patents

Financial transfers from mobile devices Download PDF

Info

Publication number
US20130166448A1
US20130166448A1 US13/418,318 US201213418318A US2013166448A1 US 20130166448 A1 US20130166448 A1 US 20130166448A1 US 201213418318 A US201213418318 A US 201213418318A US 2013166448 A1 US2013166448 A1 US 2013166448A1
Authority
US
United States
Prior art keywords
identifier
mobile device
merchant
unique user
account
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/418,318
Inventor
Anoop Narayanan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Infosys Ltd
Original Assignee
Infosys Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to IN4608/CHE/2011 priority Critical
Priority to IN4607/CHE/2011 priority
Priority to IN4608CH2011 priority
Priority to IN4607CH2011 priority
Application filed by Infosys Ltd filed Critical Infosys Ltd
Assigned to Infosys Limited reassignment Infosys Limited ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: NARAYANAN, ANOOP
Publication of US20130166448A1 publication Critical patent/US20130166448A1/en
Application status is Abandoned legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements, e.g. access security or fraud detection; Authentication, e.g. verifying user identity or authorisation; Protecting privacy or anonymity ; Protecting confidentiality; Key management; Integrity; Mobile application security; Using identity modules; Secure pairing of devices; Context aware security; Lawful interception
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements, e.g. access security or fraud detection; Authentication, e.g. verifying user identity or authorisation; Protecting privacy or anonymity ; Protecting confidentiality; Key management; Integrity; Mobile application security; Using identity modules; Secure pairing of devices; Context aware security; Lawful interception
    • H04W12/002Mobile device security; Mobile application security
    • H04W12/0023Protecting application or service provisioning, e.g. securing SIM application provisioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements, e.g. access security or fraud detection; Authentication, e.g. verifying user identity or authorisation; Protecting privacy or anonymity ; Protecting confidentiality; Key management; Integrity; Mobile application security; Using identity modules; Secure pairing of devices; Context aware security; Lawful interception
    • H04W12/04Key management, e.g. by generic bootstrapping architecture [GBA]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W60/00Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/04Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration using triggered events
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/18Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20Transfer of user or subscriber data

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 whether the transaction is authorized based on the mobile device identifier and the unique 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 determined that the transaction is not authorized; and transmitting to a payment 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 transaction is authorized.

Description

    RELATED APPLICATION DATA
  • 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
  • Credit cards allow users to carry less liquid currency. However, despite the security mechanisms implemented in relation to credit card transactions, credit card users continue to place 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 information to make unauthorized transactions without even stealing the physical card. More recently, some cards have incorporated Radio Frequency Identification (“RFID”) and similar short-range wireless communication systems to allow for more convenient “touchless” credit card transactions. However, such wireless credit cards have reduced security even further by allowing for hands-free theft by homemade scanning devices.
  • To both increase security and convenience, many companies have been working to develop mobile device (e.g., mobile phone) based payment systems as substitutes for conventional credit cards. While such payment systems alleviate 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 information. 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 may still enable sophisticated thieves to intercept account information.
  • Still other systems attempt to increase security by 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 authorized. In such a system, the merchant's POS device may submit a request for authorization of a charge, the submission including the user's account information. A back-end payment system may then send a message (e.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 transaction by either providing 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 transmitted between a user and a merchant or between a user's device and a merchant's device.
  • Improved mobile financial transfer systems are desired.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 shows an exemplary architecture for making financial transfers from a mobile device.
  • FIG. 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.
  • FIG. 3 shows an exemplary data flow illustrating that the mobile payment system may be deployed within existing payment gateway architectures without modification.
  • FIG. 4 shows an exemplary architecture for making financial transfers from a mobile device where the mobile device receives data from the point of sale device.
  • FIG. 5 shows an exemplary computing device useful for performing processes disclosed herein.
  • 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 form 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 organizational purposes only and are not meant to limit the scope of the description or the claims. As used herein, the word “may” is used in a permissive sense (i.e., meaning having the potential 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
  • Disclosed embodiments provide systems, computer-implemented methods, and computer-readable media for performing financial transfers with mobile devices, such as smartphones (e.g., phones using the iOS, Android, or BlackBerry 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, embodiments may allow a user to initiate a secure financial transfer using their mobile device without communicating any account information directly to the merchant. Thus, embodiments may transfer absolutely no account information from a mobile device to a POS device that a duplicitous employee could steal.
  • Additionally, the systems disclosed in the background each include their own infrastructure which may be expensive to deploy. For example, modern credit card systems generally require scanning devices associated with POS devices that communicate with a payment gateway or front-end credit card processing system via a network connection 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 new back-end infrastructures. In contrast to these expensive-to-deploy systems, embodiments may utilize existing payment 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 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 or a credit card, embodiments may allow payer 115 to utilize an application 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.
  • 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 (“UI”) of the mobile device. Embodiments may also allow the payer 115 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 devices (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 specific security needs and device capabilities.
  • 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 identifier may identify the exact mobile device making the transmission. Alternatively, the mobile device identifier may be a phone number or identifier assigned to the mobile device by a mobile carrier.
  • While FIG. 1 shows the transmission directly from mobile device 105 to mobile payment system 120, the transmission 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.
  • Once the mobile payment system 120 receives the MIDN, 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, determine whether the transfer is authorized, and, if the transfer is authorized, provide the appropriate information 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 simultaneously. 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.
  • 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 embodiments, 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 corresponds to an authorized account, the system may transmit account information associated with the UUI and MDI, the MIDN, and the transfer amount to a payment gateway associated 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. Alternatively, 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.
  • 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 financial transfer from John Doe's account and at step 230 the system may transmit a request to a payment gateway including 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 existing payment gateways are configured to receive these data, embodiments may be deployed within existing system architectures without requiring any modification to credit card payment gateways or merchant POS devices.
  • After the system transmits the MIDN, account information, 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.
  • 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 conventional systems, such as systems for redeeming accrued bonus points (e.g., airline points on an airline credit card), systems for making PayPal purchases, and the like.
  • 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 authorize the payment. In some embodiments, existing systems, such as Sybase 365 systems, may be utilized as the payment gateway 125.
  • 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 115.
  • As FIGS. 1 and 2 show, embodiments allow for a payer 115 to transfer finances to merchant 130 without disclosing any potentially sensitive information to the merchant. While the payer 115 may provide a general identifier, such as the payer's name, to the merchant so that the payment authorization may be matched to the specific payer 115, embodiments alleviate the need to provide any account related information (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.
  • 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 simply detects the MDI and allows a user to enter their UUI. The mobile payment system securely maintains associations between accounts and one or more corresponding MDI and UUI. Thus, even if the mobile device is lost or stolen, it has no account information that could be extracted to make fraudulent payments.
  • FIG. 3 shows an exemplary data flow 300 illustrating that the mobile payment system may be deployed within existing payment gateway architectures without modification. Additionally, data flow 300 illustrates that the information 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 information 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 internet).
  • Mobile payment system 315 may receive and process the data to determine whether the secure identifier and the device identifier correspond to an authorized account. 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 authorized, 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. Alternatively, if the transaction is not authorized (e.g., the account is overdrawn or has been closed), the payment gateway 320 may transmit a notification of the 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 merchant may give the user the goods or services they are purchasing.
  • As shown in FIG. 3, a user may avail embodiments across the globe and independent of the telecom service provider providing mobile network access. Because embodiments 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 of security at the expense of cross-platform convenience.
  • 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 of sale device. In such an embodiment, 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 communication 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 transmitted 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.
  • While the above embodiments generally describe financial transfers occurring at POS devices, embodiments may be implemented to allow for other secure financial transactions 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 checkout. 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., if the 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 avoid phishing scams by having the payment gateway validate all MIDNs.
  • Embodiments may also be configured to allow a user to transfer money to another user. For example, individual 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 (e.g., the phones may “bump” using NFC). In such embodiments, a payer's phone may transmit no account information to the payee's phone.
  • Embodiments may be configured to accept voice commands for performing all transactions. Such embodiments 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.
  • 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.
  • 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 of service (e.g., the calculator may add 0% for awful service, 5% for poor service, 15% for good service, and 25% for exceptional service).
  • 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 previous purchases or other financial transfers. Thus, embodiments 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 mobile device, for example by selecting a promotion and providing their UUI to authorize the purchase of the promoted goods or services.
  • Embodiments may also provide account management 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 product is defective), view an account balance, and the like. Embodiments may also allow for a bank or financial institution to push information to a user via their mobile device, for example messages about the user's account (e.g., e-statements), notifications of fee changes, promotions, and the like.
  • The embodiments described herein may be implemented 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 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.
  • Other embodiments may utilize web apps (i.e., applications executed through an internet connected browser). Such embodiments may provide a user with convenient access to their account without requiring installation of an application on their mobile device. In such embodiments, 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.
  • In still other embodiments, the application may be made an integral part of the operating system image installed on the mobile device. Such embodiments may provide additional security since the application cannot be easily uninstalled or tampered with.
  • 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 if they 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 security. In such embodiments, an application useful for performing 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.
  • The above embodiments generally describe the MDI being a mobile phone's IMEI. In alternative embodiments, the MDI may be data stored on a Subscriber Identification Module (“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 APPARATUS FOR REGISTERING A COMPUTING DEVICE WITH A SERVICE PROVIDER” invented by Anoop Narayanan having docket number IN-PED-0918, the entire contents of which are incorporated herein by reference. 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 device for reading the soft SIM. The subscriber may register the IMEI number of his or her mobile device with the service provider and the soft SIM, like a plastic SIM card, may have a unique cell number to identify the Global System for Mobile Communications (“GSM”) subscriber. Embodiments using an MDI associated with a SIM card or soft SIM may conveniently allow a user to maintain the same MDI associated with an account after they upgrade their mobile device.
  • Thus, a soft SIM may provide a digital signature to securely and uniquely identify an authorized mobile device and user. A single soft SIM may act as a digital signature for all transactions performed from the device in conjunction with a unique device identifier, such as an IMEI number or other data embedded in read-only memory which uniquely identifies the device. In other words, a device registered with a service provider may act as a digital signature of a person. Financial transactions (e.g., transfers) may be required to be performed from the signature device (i.e., the device having the soft SIM) and may require a dynamically changing authentication (e.g., a PIN or password). A single device may have plural soft SIMs but the same soft SIM may not be used on more than one device.
  • While the above embodiments generally describe financial transfers from a user to another user or to a merchant, embodiments may also be useful for allowing a user to securely withdraw money from an ATM using their mobile device. Such embodiments may add a level of security to conventional ATM withdrawals. In such embodiments, a user may utilize an application on their mobile device and enter a unique identifier for the bank in the MIDN field, the amount of the withdrawal, and their UUI. The application may then give the user a temporary PIN number valid for a specific time interval and for the specific cash amount. The user can then visit the ATM of that respective bank, enter the PIN number, and withdraw the cash within the allowed time limit. In other embodiments, the PIN may be valid for a specific time interval but the cash amount may not be predetermined.
  • These embodiments may be implemented with software, for example modules executed on computing devices such as computing device 510 of FIG. 5. Of course, modules described herein illustrate various functionalities and do not limit the structure of any embodiments. Rather the functionality of various modules may be divided differently and performed by more or fewer modules according to various design considerations.
  • Computing device 510 has one or more processing device 511 designed to process instructions, for example computer-readable instructions (i.e., code) stored on a storage device 513. By processing instructions, processing device 511 may perform the steps and functions disclosed herein. Storage device 513 may be any type of storage device (e.g., an optical storage device, a magnetic storage device, a solid state storage device, etc.), for example a non-transitory storage device. Alternatively, instructions may be stored in one or more remote storage devices, for example storage devices accessed over a network or the internet. Computing device 510 additionally may have memory 512, an input controller 516, and an output controller 515. A bus 514 may operatively couple components of computing device 510, including processor 511, memory 512, storage device 513, input controller 516, output controller 515, and any other devices (e.g., network controllers, sound controllers, etc.). Output controller 515 may be operatively coupled (e.g., via a wired or wireless connection) to a display device 520 (e.g., a monitor, television, mobile device screen, touch-display, etc.) in such a fashion that output controller 515 can transform the display on display device 520 (e.g., in response to modules executed). Input controller 516 may be operatively coupled (e.g., via a wired or wireless connection) to input device 530 (e.g., mouse, keyboard, touch-pad, scroll-ball, touch-display, etc.) in such a fashion that input can be received from a user.
  • Of course, FIG. 5 illustrates computing device 510, display device 520, and input device 530 as separate devices for ease of identification only. Computing device 510, display device 520, and input device 530 may be separate devices (e.g., a personal computer connected by wires to a monitor and mouse), may be integrated in a single device (e.g., a mobile device with a touch-display, such as a smartphone or a tablet), or any combination of devices (e.g., a computing device operatively coupled to a touch-screen display device, a plurality of computing devices attached to a single display device and input device, etc.). Computing device 510 may be one or more servers, for example a farm of networked servers, a clustered server environment, or a cloud network of computing devices.
  • The above embodiments may utilize MIDNs corresponding to the entity receiving the payment initiated from a mobile device. While each MIDN may be associated with a payee, the MIDN may also be transaction specific. For example, if an MIDN is a determined number of digits, a portion of the MIDN may be configured to identify the payee and a portion of the MIDN may be configured to identify the specific transaction. In this fashion, the payee may determine whether the specific transaction is authorized through the mobile financial transfer system.
  • Embodiments have been disclosed herein. However, various modifications can be made without departing from the scope of the embodiments as defined by the appended claims and legal equivalents.

Claims (19)

What is claimed is:
1. A computer-implemented method executed by one or more computing devices for financial transfers from a mobile device, the method comprising:
receiving, by at least one of the one or more computing devices, a mobile device identifier, a unique user identifier, a merchant identifier, and an amount from a mobile device;
determining, by at least one of the one or more computing devices, whether the transaction is authorized based on the mobile device identifier and the unique user identifier;
transmitting, by at least one of the one or more computing devices, 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, by at least one of the one or more computing devices, to a payment 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 transaction is authorized.
2. The method of claim 1, wherein the mobile device identifier is an International Mobile Equipment Identity number;
wherein the unique user identifier is at least one of a Personal Identification Number, a password, and a biometric identifier; and
wherein the determining step determines whether the unique user identifier and the mobile device identifier correspond to an account identifier in an account dataset.
3. The method of claim 1, wherein the step of transmitting to the payment gateway transmits all data in a format accepted by conventional credit card payment gateways.
4. The method of claim 1, wherein the merchant identifier incorporates a merchant account identification and a unique transaction identification.
5. The method of claim 1, wherein the mobile device identifier, unique user identifier, merchant identifier, and amount are received from a mobile device via a wireless data connection.
6. The method of claim 1, wherein the mobile device identifier, unique user identifier, merchant identifier, and amount are received from a mobile device via an encrypted Short Message Service message.
7. The method of claim 1, wherein the mobile device identifier is a soft Subscriber Identification Module.
8. A system for financial transfers from a mobile device comprising:
a memory; and
a processor operatively coupled to the memory, the processor configured to perform the steps of:
receiving a mobile device identifier, a unique user identifier, a merchant identifier, and an amount from a mobile device;
determining whether the transaction is authorized based on the mobile device identifier and the unique 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 determined that the transaction is not authorized; and
transmitting to a payment 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 transaction is authorized.
9. The system of claim 8, wherein the mobile device identifier is an International Mobile Equipment Identity number;
wherein the unique user identifier is at least one of a Personal Identification Number, a password, and a biometric identifier; and
wherein the determining step determines whether the unique user identifier and the mobile device identifier correspond to an account identifier in an account dataset.
10. The system of claim 8, wherein the step of transmitting to the payment gateway transmits all data in a format accepted by conventional credit card payment gateways.
11. The system of claim 8, wherein the merchant identifier incorporates a merchant account identification and a unique transaction identification.
12. The system of claim 8, wherein the mobile device identifier, unique user identifier, merchant identifier, and amount are received from a mobile device via one of a wireless data connection and an encrypted Short Message Service message.
13. The system of claim 8, wherein the mobile device identifier is a soft Subscriber Identification Module.
14. A non-transitory computer-readable medium having computer-readable code stored thereon that, when executed by a computing device, performs a method for financial transfers from a mobile device, the method 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 authorized based on the mobile device identifier and the unique 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 determined that the transaction is not authorized; and
transmitting to a payment 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 transaction is authorized.
15. The medium of claim 14, wherein the mobile device identifier is an International Mobile Equipment Identity number;
wherein the unique user identifier is at least one of a Personal Identification Number, a password, and a biometric identifier; and
wherein the determining step determines whether the unique user identifier and the mobile device identifier correspond to an account identifier in an account dataset.
16. The medium of claim 14, wherein the step of transmitting to the payment gateway transmits all data in a format accepted by conventional credit card payment gateways.
17. The medium of claim 14, wherein the merchant identifier incorporates a merchant account identification and a unique transaction identification.
18. The medium of claim 14, wherein the mobile device identifier, unique user identifier, merchant identifier, and amount are received from a mobile device via one of a wireless data connection and an encrypted Short Message Service message.
19. The medium of claim 14, wherein the mobile device identifier is a soft Subscriber Identification Module.
US13/418,318 2011-12-27 2012-03-12 Financial transfers from mobile devices Abandoned US20130166448A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
IN4608/CHE/2011 2011-12-27
IN4607/CHE/2011 2011-12-27
IN4608CH2011 2011-12-27
IN4607CH2011 2011-12-27

Publications (1)

Publication Number Publication Date
US20130166448A1 true US20130166448A1 (en) 2013-06-27

Family

ID=48655041

Family Applications (2)

Application Number Title Priority Date Filing Date
US13/418,321 Active 2033-11-12 US9210573B2 (en) 2011-12-27 2012-03-12 Method and apparatus for registering a computing device with a service provider
US13/418,318 Abandoned US20130166448A1 (en) 2011-12-27 2012-03-12 Financial transfers from mobile devices

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US13/418,321 Active 2033-11-12 US9210573B2 (en) 2011-12-27 2012-03-12 Method and apparatus for registering a computing device with a service provider

Country Status (1)

Country Link
US (2) US9210573B2 (en)

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140324689A1 (en) * 2013-04-24 2014-10-30 The Roberto Giori Company Ltd. System and method for electronic money withdrawal
US20150170132A1 (en) * 2013-12-18 2015-06-18 PayRange Inc. Method and System for Presenting Representations of Payment Accepting Unit Events
US9134994B2 (en) 2013-12-18 2015-09-15 PayRange Inc. Method and system for updating firmware using a mobile device as a communications bridge
WO2015191589A1 (en) * 2014-06-14 2015-12-17 Mastercard International Incorporated Apparatus, method, and computer program for mobile open payment network
US9256873B2 (en) 2013-12-18 2016-02-09 PayRange Inc. Method and device for retrofitting an offline-payment operated machine to accept electronic payments
US9262771B1 (en) 2015-01-30 2016-02-16 PayRange Inc. Method and system for providing offers for automated retail machines via mobile devices
USD755183S1 (en) 2013-12-18 2016-05-03 Payrange, Inc. In-line dongle
US20160155112A1 (en) * 2012-10-10 2016-06-02 Mastercard International Incorporated Barcode-triggered payment method and system
USD763888S1 (en) 2015-01-30 2016-08-16 PayRange Inc. Display screen or portion thereof with graphical user interface
USD763905S1 (en) 2015-01-30 2016-08-16 PayRange Inc. Display screen or portion thereof with animated graphical user interface
USD764532S1 (en) 2015-01-30 2016-08-23 PayRange Inc. Display screen or portion thereof with animated graphical user interface
USD773508S1 (en) 2015-01-30 2016-12-06 PayRange Inc. Display screen or portion thereof with a graphical user interface
US20170140614A1 (en) * 2014-07-02 2017-05-18 Grg Banking Equipment Co., Ltd. Method and system for handling situation of card detainment in self-service terminal
US9672512B1 (en) * 2014-01-02 2017-06-06 Sprint Communications Company L.P. Processor routing number for mobile communication service provider billing
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
US9875473B2 (en) 2013-12-18 2018-01-23 PayRange Inc. Method and system for retrofitting an offline-payment operated machine to accept electronic payments
US9972005B2 (en) 2013-12-19 2018-05-15 Visa International Service Association Cloud-based transactions methods and systems
USD836118S1 (en) 2015-01-30 2018-12-18 Payrange, Inc. Display screen or portion thereof with an animated graphical user interface
US10187363B2 (en) 2014-12-31 2019-01-22 Visa International Service Association Hybrid integration of software development kit with secure execution environment

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150095453A1 (en) 2013-09-27 2015-04-02 Google Inc. System and method for increased call quality and success rate
US9628359B1 (en) 2013-12-23 2017-04-18 Google Inc. Network selection using current and historical measurements
US9736704B1 (en) 2013-12-23 2017-08-15 Google Inc. Providing an overlay network using multiple underlying networks
US9877188B1 (en) 2014-01-03 2018-01-23 Google Llc Wireless network access credential sharing using a network based credential storage service
US9312902B1 (en) 2014-04-22 2016-04-12 Google Inc. Linking a subscriber identity module to a mobile device
US9565578B2 (en) 2014-06-18 2017-02-07 Google Inc. Method for collecting and aggregating network quality data
US9614915B2 (en) 2014-08-18 2017-04-04 Google Inc. Seamless peer to peer internet connectivity
US9942900B1 (en) 2014-11-24 2018-04-10 Google Llc System and method for improved band-channel scanning and network switching
US9648537B2 (en) 2015-04-17 2017-05-09 Google Inc. Profile switching powered by location
US10021618B2 (en) 2015-04-30 2018-07-10 Google Technology Holdings LLC Apparatus and method for cloud assisted wireless mobility
US10257782B2 (en) 2015-07-30 2019-04-09 Google Llc Power management by powering off unnecessary radios automatically
US10225783B2 (en) 2016-04-01 2019-03-05 Google Llc Method and apparatus for providing peer based network switching

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090094123A1 (en) * 2007-10-03 2009-04-09 Patrick Killian Payment services provider methods in connection with personalized payments system
US20110173060A1 (en) * 2010-01-08 2011-07-14 Gallagher Kevin N Guest Check Presenter Having a Wireless Communication Device
US20110217994A1 (en) * 2010-03-03 2011-09-08 Boku, Inc. Systems and Methods to Automate Transactions via Mobile Devices
US20120136732A1 (en) * 2010-11-29 2012-05-31 Mcmillen Glenn Curtiss Method and system for account management and electronic wallet access on a mobile device
US20120197796A1 (en) * 2011-01-31 2012-08-02 Nathan Dent Cash dispensing at atm

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0116592D0 (en) * 2001-07-06 2001-08-29 Pathfinder Tech Resources Ltd SMS routing
GB2412544B (en) 2004-03-22 2008-12-31 Vodafone Plc Visual verification of the user of a mobile device
US7275685B2 (en) 2004-04-12 2007-10-02 Rearden Capital Corporation Method for electronic payment
KR20040066769A (en) 2004-07-07 2004-07-27 박승현 System For Providing A Service Of Settlement A Mobile Phone Of Credit Card And Its Method
WO2007024150A1 (en) 2005-08-22 2007-03-01 G-Xchange, Inc. A method of cash-less, cardless purchase transaction using mobile phones
US8280354B2 (en) * 2005-10-27 2012-10-02 Research In Motion Limited Method and system for provisioning wireless services
US7657489B2 (en) 2006-01-18 2010-02-02 Mocapay, Inc. Systems and method for secure wireless payment transactions
KR100846161B1 (en) 2006-10-20 2008-07-14 주식회사 더존씨앤티 System and method for disposable mobile credit card service
US20090005016A1 (en) * 2007-06-29 2009-01-01 Betty Eng Apparatus and method to maintain a continuous connection of a cellular device and a sensor network
US7930249B2 (en) 2007-07-11 2011-04-19 Qualcomm Incorporated Mobile wireless financial instrument for automatically selecting a payment instrument
US8301197B2 (en) 2007-11-18 2012-10-30 Qualcomm Incorporated Method and apparatus for synchronizing contacts stored on smart card with contacts stored in an internal memory
US7928965B2 (en) 2007-12-27 2011-04-19 Apple Inc. Touch screen RFID tag reader
US9053474B2 (en) 2008-08-04 2015-06-09 At&T Mobility Ii Llc Systems and methods for handling point-of-sale transactions using a mobile device
US20100078471A1 (en) 2008-09-30 2010-04-01 Apple Inc. System and method for processing peer-to-peer financial transactions
US20100082455A1 (en) 2008-09-30 2010-04-01 Apple Inc. Real-time bargain hunting
US9026462B2 (en) 2008-09-30 2015-05-05 Apple Inc. Portable point of purchase user interfaces
US20100082445A1 (en) 2008-09-30 2010-04-01 Apple Inc. Smart menu options
US20100082485A1 (en) 2008-09-30 2010-04-01 Apple Inc. Portable point of purchase devices and methods
GB2466038A (en) 2008-12-09 2010-06-16 Alexzandre Anthony Capurro Authorisation of cashless payment using SMS
US7913914B2 (en) 2009-04-28 2011-03-29 Sony Ericsson Mobile Communications Ab Connector device
US20100311402A1 (en) 2009-06-08 2010-12-09 Prasanna Srinivasan Method and apparatus for performing soft switch of virtual sim service contracts
KR20110037487A (en) * 2009-10-07 2011-04-13 삼성전자주식회사 Apparatus and method for setting main sim card in dual sim cards terminal
US8543841B2 (en) * 2011-06-30 2013-09-24 Oracle International Corporation Secure hosted execution architecture

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090094123A1 (en) * 2007-10-03 2009-04-09 Patrick Killian Payment services provider methods in connection with personalized payments system
US20110173060A1 (en) * 2010-01-08 2011-07-14 Gallagher Kevin N Guest Check Presenter Having a Wireless Communication Device
US20110217994A1 (en) * 2010-03-03 2011-09-08 Boku, Inc. Systems and Methods to Automate Transactions via Mobile Devices
US20120136732A1 (en) * 2010-11-29 2012-05-31 Mcmillen Glenn Curtiss Method and system for account management and electronic wallet access on a mobile device
US20120197796A1 (en) * 2011-01-31 2012-08-02 Nathan Dent Cash dispensing at atm

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160155112A1 (en) * 2012-10-10 2016-06-02 Mastercard International Incorporated Barcode-triggered payment method and system
US20140324689A1 (en) * 2013-04-24 2014-10-30 The Roberto Giori Company Ltd. System and method for electronic money withdrawal
US9134994B2 (en) 2013-12-18 2015-09-15 PayRange Inc. Method and system for updating firmware using a mobile device as a communications bridge
US9875473B2 (en) 2013-12-18 2018-01-23 PayRange Inc. Method and system for retrofitting an offline-payment operated machine to accept electronic payments
US9256873B2 (en) 2013-12-18 2016-02-09 PayRange Inc. Method and device for retrofitting an offline-payment operated machine to accept electronic payments
US9659296B2 (en) * 2013-12-18 2017-05-23 PayRange Inc. Method and system for presenting representations of payment accepting unit events
USD755183S1 (en) 2013-12-18 2016-05-03 Payrange, Inc. In-line dongle
US20150170132A1 (en) * 2013-12-18 2015-06-18 PayRange Inc. Method and System for Presenting Representations of Payment Accepting Unit Events
USD782482S1 (en) 2013-12-18 2017-03-28 Payrange, Inc. In-line dongle
USD782483S1 (en) 2013-12-18 2017-03-28 Payrange, Inc. In-line dongle
US9547859B2 (en) 2013-12-18 2017-01-17 PayRange Inc. Method and system for performing mobile device-to-machine payments
US9972005B2 (en) 2013-12-19 2018-05-15 Visa International Service Association Cloud-based transactions methods and systems
US9672512B1 (en) * 2014-01-02 2017-06-06 Sprint Communications Company L.P. Processor routing number for mobile communication service provider billing
US10318954B1 (en) 2014-01-02 2019-06-11 Sprint Communications Company L.P. Processor routing number for mobile communication service provider billing
WO2015191589A1 (en) * 2014-06-14 2015-12-17 Mastercard International Incorporated Apparatus, method, and computer program for mobile open payment network
US20170140614A1 (en) * 2014-07-02 2017-05-18 Grg Banking Equipment Co., Ltd. Method and system for handling situation of card detainment in self-service terminal
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
US10187363B2 (en) 2014-12-31 2019-01-22 Visa International Service Association Hybrid integration of software development kit with secure execution environment
USD763888S1 (en) 2015-01-30 2016-08-16 PayRange Inc. Display screen or portion thereof with graphical user interface
USD763905S1 (en) 2015-01-30 2016-08-16 PayRange Inc. Display screen or portion thereof with animated graphical user interface
USD764532S1 (en) 2015-01-30 2016-08-23 PayRange Inc. Display screen or portion thereof with animated graphical user interface
US10019724B2 (en) 2015-01-30 2018-07-10 PayRange Inc. Method and system for providing offers for automated retail machines via mobile devices
USD836118S1 (en) 2015-01-30 2018-12-18 Payrange, Inc. Display screen or portion thereof with an animated graphical user interface
US9262771B1 (en) 2015-01-30 2016-02-16 PayRange Inc. Method and system for providing offers for automated retail machines via mobile devices
USD773508S1 (en) 2015-01-30 2016-12-06 PayRange Inc. Display screen or portion thereof with a graphical user interface

Also Published As

Publication number Publication date
US9210573B2 (en) 2015-12-08
US20130165117A1 (en) 2013-06-27

Similar Documents

Publication Publication Date Title
US8116734B2 (en) Party identification in a wireless network
AU2011237387B2 (en) Mobile phone payment processing methods and systems
US8156543B2 (en) Method and system for authenticating a party to a transaction
US8005426B2 (en) Method and mobile terminal device including smartcard module and near field communications means
CA2920661C (en) Methods and systems for provisioning mobile devices with payment credentials
US10366387B2 (en) Digital wallet system and method
AU2012201745B2 (en) Authentication using application authentication element
US9183549B2 (en) System and method of secure payment transactions
US7774076B2 (en) System and method for validation of transactions
US10043178B2 (en) Secure mobile payment system
US9471921B1 (en) Secure mobile payment authorization
US7014107B2 (en) Wireless payment processing system
US10346838B2 (en) Systems and methods for distributed enhanced payment processing
US20090281904A1 (en) Mobile telephone transaction systems and methods
US10102518B2 (en) Enrollment and registration of a device in a mobile commerce system
AU2007340015B2 (en) Mobile payment system and method using alias
US9292870B2 (en) System and method for point of service payment acceptance via wireless communication
US20110016047A1 (en) Financial transaction system, automated teller machine (atm), and method for operating an atm
AU2009292921B2 (en) Apparatus and method for preventing unauthorized access to payment application installed in contactless payment device
RU2556453C2 (en) System and method for authentication of transactions without car with help of mobile device
US10163100B2 (en) Location based authentication
US20120259782A1 (en) Multiple tokenization for authentication
US10152711B2 (en) Systems and methods for arbitraged enhanced payment processing
US20150088751A1 (en) Transaction verification system based on user location
US9846866B2 (en) Processing of financial transactions using debit networks

Legal Events

Date Code Title Description
AS Assignment

Owner name: INFOSYS LIMITED, INDIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NARAYANAN, ANOOP;REEL/FRAME:028044/0821

Effective date: 20111222

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION