WO2012099885A1

WO2012099885A1 - Techniques to access a cloud-based wallet using a basic handset

Info

Publication number: WO2012099885A1
Application number: PCT/US2012/021564
Authority: WO
Inventors: Marc E. ELBIRT; Sebastien Taveau; Amol Bhasker Patel
Original assignee: Ebay Inc.
Priority date: 2011-01-18
Filing date: 2012-01-17
Publication date: 2012-07-26

Abstract

A method performed by an e-commerce service provider in communication with a mobile device over a network other than the Internet, the method including providing a user of the mobile device with a plurality of financial transaction options on an interface of the mobile device, receiving input from the user indicating at least one of the options, and completing a financial transaction in accordance with the input from a cloud-based wallet, the cloud-based wallet providing the plurality of financial transactions by offering access to a plurality of payment methods and access to a plurality of counterparties.

Description

TECHNIQUES TO ACCESS A CLOUD-BASED WALLET

USING A BASIC HANDSET

BACKGROUND

Technical Field

The present disclosure generally relates to providing access to a cloud-based wallet and, more particularly, to providing access to the cloud-based wallet using connections other than the Internet.

Related Art

Current wireless phone technology provides for smartphones and feature phones.

Smartphones usually include a large, color display, data connectivity (in addition to voice connectivity), and an advanced processor that is operable to execute applications. Many smartphones provide robust capabilities. For instance, 4G smartphones provide Internet connectivity with relatively fast upload and download speeds and usually offer a wide variety of Internet-connected applications that provide utility and entertainment. Feature phones, by contrast, offer very basic features and are centered on voice connectivity rather than data connectivity. However, some feature phones provide basic Internet connectivity with a primitive browser. Additional data capabilities offered by feature phones may include Short Message Service (SMS) messaging and Unstructured Supplementary Service Data (USSD) messaging.

While smartphones are quite common in the developed world, feature phones tend to predominate in developing economies. Furthermore, some services, mostly in developing economies, have begun to use USSD messaging to provide payment by users of feature phones. In one example, a user of a feature phone "tops up" his or her minutes on the feature phone by providing cash to a vendor at a physical location and then entering data associated with the transaction using a USSD session with a mobile carrier. Thus, USSD can be used in very basic monetary transactions.

PayPal Inc. currently provides methods for online payments and money transfers. In fact, PayPal provides a cloud-based wallet to its users with very robust and sophisticated abilities. The cloud-based wallet allows for electronic transactions using any of a number of payment methods (e.g., credit cards, bank accounts, etc.) to any registered payee or from any registered payer (where payees and payers and referred to collectively herein as

counterparties).

The cloud-based wallet offered by PayPal is accessible by smartphones but has not yet been offered for use in a comprehensive way for feature phones. It would be desirable to provide techniques for feature phone users to access a cloud-based wallet to facilitate transactions with a variety of counterparties using a variety of payment methods.

SUMMARY

One of the broader forms of the present disclosure involves a method performed by an e- commerce service provider in communication with a mobile device over a network other than the Internet, the method including providing a user of the mobile device with a plurality of financial transaction options on an interface of the mobile device, receiving input from the user indicating at least one of the options, and completing a financial transaction in accordance with the input from a cloud-based wallet, the cloud-based wallet providing the plurality of financial transactions by offering access to a plurality of payment methods and access to a plurality of counterparties.

Another one of the broader forms of the present disclosure involves a method performed by a user at a phone that is in communication with an e-commerce service provider over a network other than the Internet, the method including initiating a first financial transaction with the e- commerce service provider, selecting the first financial transaction from a menu of multiple financial transaction options on an interface of the phone, and completing the first financial transaction using a electronic wallet that includes multiple payment methods and access to multiple counterparties.

Yet another one of the broader forms of the present disclosure involves a network computer with at least one computer processor that executes computer-readable code to provide financial transactions, the network computer including a gateway communicating with a plurality of phones of a plurality of users over a network other than the Internet, a

communication interface with an e-commerce service provider hosting an electronic wallet that facilitates the financial transactions with multiple counterparties and with multiple methods of payment; a database containing history data and identity data for the plurality of users and the plurality of phones, and a workflow engine in communication with the gateway, the communication interface, and the database to provide the following functions: providing a first one of the users of a first one of the phones with a plurality of financial transaction options on an interface of the first one of the phones, receiving input from the first one of the users indicating at least one of the options, and completing a first financial transaction in accordance with the input from the first one of the users.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is an illustration of a system overview according to one example embodiment.

Fig. 2 is an illustration of the example MTG of Fig. 1 , in more detail, adapted according to one embodiment.

Figs. 3A and 3B provide an illustration of an example method adapted according to one embodiment.

Figs. 4A and B show exemplary menu screen shots that may be provided on an interface of a phone (e.g., a LCD screen) from a GTM to a user, using USSD, consistent with method of Fig. 3.

Fig. 5 is an illustration of an example method adapted according to one embodiment.

Fig. 6 provides a series of screen shots showing example USSD text indications on a screen of a mobile phone, consistent with the method of Fig. 5.

Fig. 7 is an illustration of an example method adapted according to one embodiment.

Fig. 8 is an illustration of an example method adapted according to one embodiment.

Fig. 9 includes screen shots on the user's mobile device of a USSD session consistent with the method of Fig. 8.

Fig. 10 is a block diagram of an example computer system suitable for implementing various methods and devices described herein, for example, the various action blocks of Figs. 3, 5, 7, and 8.

DETAILED DESCRIPTION

It is to be understood that the following disclosure provides many different embodiments, or examples, for implementing different features of the present disclosure. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. Various features may be arbitrarily drawn in different scales for simplicity and clarity.

Various embodiments provide access to a cloud-based wallet to a user at a basic phone that may have limited or no Internet access. In one non-limiting example, the user interacts with the cloud-based wallet via Unstructured Supplementary Service Data (USSD) messaging. The user may set up an account with the service offering the cloud-based wallet, make payments, receive payments, and edit the user's profile or payment methods without accessing the Internet. In such examples, the e-commerce service provider offering the cloud-based wallet may provide a menu interface on the phone's screen, through with the user may navigate.

Some embodiments include a mobile transaction gateway (MTG) that communicates with a messaging gateway at the mobile carrier. The e-commerce service provider has its own computers that communicate with the MTG, thereby exposing the services of the cloud-based wallet to the MTG. The MTG includes computer-executable code, which when executed by one or more processors at the MTG, manages communications to and from the user's mobile phone. The MTG includes fraud management, certificate lookup, user information database management, and communication with the mobile carrier and e-commerce service provider. Thus, one example includes a MTG that is between the mobile carrier and the e-commerce service provider, where the MTG communicates with the user' s phone (via the mobile carrier) and the e-commerce service provider to manage account set-up and transactions.

It is a feature of various embodiments that the communications with the user occur on a communications channel other than the Internet. As mentioned above, USSD provides one such communications channel; however, the scope of embodiments is not so limited. Other embodiments may use, e.g., SMS messaging, Interactive Voice Response (IVR), a SIM Tool Kit (STK) application, a Java 2 Platform, Micro Edition (J2ME) application, and/or the like.

The user may access the cloud-based wallet to enjoy a comprehensive set of financial transaction options. For instance, the user may access a debit account, a credit account, a bank account, or any other account that is linked with the payment service. The user may also pay, or be paid by, any counterparty linked to the payment service. Thus, in contrast to conventional techniques that provide only payment to specific payees (e.g., payment to a mobile carrier), various embodiments provide payments to and from any arbitrary counterparty using any of a variety of payment methods. Fig. 1 is an illustration of a system overview according to one example embodiment. Fig. 1 shows the relationship between mobile device 130 (e.g., a feature phone), mobile service carrier 110, payment service 140, and MTG 120. Payment service 140 includes an entity that provides a cloud-based wallet. For instance, payment service 140 may be associated with PayPal Inc. or some other e-commerce service provider. Payment service 140 administers the payment methods and money transfers and provides the cloud-based wallet for the user. While not shown in Fig. 1 it is noted that payment service 140 may be accessible in other ways, such as directly via Internet 145 from other users (not shown) by a personal computer or smartphone.

Payment service 140 communicates with MTG 120 using one or more Application

Programming Interfaces (APIs), which expose the underlying cloud-based wallet functionality to the MTG 120. MTG 120 may include one or more computers that manage the mobile session to facilitate one or more financial transactions with a user at mobile device 130. In this example, MTG 120 provides an interface for the user to access payment service 140 using at least one of SMS messaging, USSD messaging, IVR, an STK application, and/or a J2ME application. MTG 120 is described in more detail with respect to Fig. 2.

MTG 120 communicates over Internet 145 with mobile service carrier 110. Although Fig. 1 shows Internet 145 between MTG 120 and mobile service carrier 110, it is noted that any data connection therebetween (with or without Internet 145) may be used in various embodiments. Furthermore, even though Internet 145 is shown in Fig. 1 it is still true that mobile device 130 does not have an Internet connection with payment service 140 because mobile device 130 does not, itself, communicate over Internet 145 and is unaware of the use of the Internet in one of the paths of communication. Thus, the embodiment of Fig. 1 is designed to perform even if the user at mobile device 130 has no Internet access through mobile device 130 (or has Internet access but chooses not to use it).

Mobile services carrier 110 includes computer systems 111-115. Over The Air (OTA) server 111 receives communications from any of computer systems 112-114 and transmits the communications to mobile device 130 over Global System for Mobile Communications (GSM) network 135. Online charging gateway 112 provides communication between MTG 120 and mobile device 130 over IVR or a J2ME application. In a scenario wherein mobile device 130 uses USSD messaging, USSD gateway 113 communicates messages to and from MTG 120. Similarly, if mobile device 130 accesses payment service 140 using an STK application, STK gateway 114 communicates messages to and from MTG 120. In a scenario wherein mobile device 130 accesses payment service 140 using SMS, SMS gateway 115 communicates messages to and from MTG 120.

Thus, whichever communication technique is used between the mobile device 130 and mobile service carrier 110, MTG 120 communicates with an appropriate gateway 112-114 at mobile services carrier 110. As explained with respect to Fig. 2, MTG 120 includes the capability to use each one of the different communication techniques as appropriate.

Moreover, it is noted that the scope of embodiments is not limited to the list of

communication techniques provided above. Rather, any appropriate communication technique now known or later developed may be used with various embodiments.

In an example wherein mobile device 130 communicates using USSD, the user (not shown) at mobile device 130 initiates a transaction by formulating a message to a USSD address associated with payment service 140. The message traverses GSM network 135, OTA server 111, USSD gateway 113 and is received by MTG 120. The USSD session is established, and MTG 120 analyzes the message for an identification of the user. If MTG 120 can verify the user, MTG 120 then follows up with additional messages (as appropriate) and passes information to and from payment service 140 to complete the transaction. In some examples, a given USSD message to the user from MTG 120 appears as a menu, asking the user to select an option by keying in one or more characters and replying to the message. SMS examples may work in a similar way, though SMS examples may be limited to one-hundred forty characters per message, making SMS slightly less convenient for menu-type messages than USSD. An IVR embodiments and embodiments using STK and J2ME applications may also use menu-type configurations, though any organizational arrangement is within the scope of embodiments.

Fig. 2 is an illustration of an example MTG 120 (of Fig. 1) adapted according to one embodiment. MTG 120 includes internal gateways 212-215 to facilitate communication with mobile service carrier gateways 112-115 (Fig. 1). For instance, USSD gateway 213 is programmed to use the appropriate protocols to send and receive messages with USSD gateway 213. The other internal gateways 212, 214, 215 operate similarly.

Workflow engine 223 is the main operational program of MTG 120 and provides many of the operations discussed in the flowcharts of Figs. 3, 5, 7, and 8. In this example, workflow engine 223 includes business logic to implement the variety of use cases discussed with respect to Figs. 3, 5, 7, and 8. Among other things, workflow engine 223 includes logic to create messages to send to the user during a requested transaction, to parse messages from the user, and to communicate with payment service 140 in order to perform the requested actions (e.g., managing/creating a cloud-based wallet, making a payment, etc.).

Database 224 includes user information (e.g., to match a mobile device to one or more user accounts at payment service 140), number history (e.g., information about use history associated with a particular phone number or mobile device), and transaction data (e.g., information about specific past transactions). The workflow engine 223 may consult database 224 during the course of a transaction as appropriate.

Fraud management unit 226 implements fraud detection logic. For instance, for a given USSD session, the following information may be gleaned by fraud management unit 226: country and mobile network of the user, cell identity within the mobile network, a phone identifier (IMEI) that can be mapped to a handset model, and a relation between current SIM and phone and if either of them have a history of having been connected to many devices. Other solutions implementing STK apps, J2ME apps, IVR, or SMS may gather other or different information. Fraud management unit 226 can use such information, along with username, password, and other appropriate information to detect suspicious behavior. If suspicious behavior is detected, MTG 120 may suspend or end the transaction or ask for more information. Workflow engine 223 may consult with fraud management engine 226 before approving any money transfer.

APIs 225 and 228 are the interfaces between MTG 120 and payment service 140. MTG 120 communicates with payment service 140 to complete the requested financial transaction. MTG 120 may include some, but not all, of the logic used to authenticate a requested transaction and to determine whether a requested transaction should go forward— payment service 140 may include the same or similar logic and may be able independently to verify a transaction and/or to determine whether a transaction should go forward.

Furthermore, during a transaction, workflow engine 223 may communicate (via APIs 225 and 228) with payment service 140 identities of payer and payee, amount of transaction, selection of payment method, and other appropriate data.

Smart licentio 227 may consult a certificate repository 230 to identify trusted third parties when commanded to do so by workflow engine 223. O&M 221 is an administration function for MTG 120 and is beyond the scope of the present discussion. Similarly, reporting manager 222 provides reports of activity and is also beyond the scope of this discussion. Figs. 3 A and 3B provide an illustration of an example method 300 adapted according to one embodiment. Method 300 may be performed using SMS, USSD, IVR, an application on the handset, or any other appropriate technique. Figs. 4 A and B show exemplary

communications that may be provided on an interface of a phone (e.g., a LCD screen) from a GTM to a user, using USSD, consistent with method 300. Method 300 is used to sign up a user and establish a cloud-based wallet for the user, where the cloud-based wallet is hosted by an e-commerce service provider. In the example of method 300 the e-commerce service provider is indicated as PayPal, though other e-commerce service providers may be used in various embodiments.

In block 302, the user receives an SMS message about a top-up service offered by the e- commerce service provider. The user them dials a USSD access number provided in the SMS message and hears an introduction from the e-commerce service provider at block 304.

At blocks 306-314, the MTG asks whether the user consents to sharing information with the e-commerce service provider and whether the user agrees to the Terms of Use (TOU) of the service. Only if the user consents and agrees does method 300 progress to block 316. At block 316-324, the MTG asks the user to confirm his or her name and address. If the user cannot confirm name or address, the user is directed to his or her mobile carrier to correct his or her information. Only if the user confirms both name and address does method 300 progress to block 326.

At block 326, the MTG asks the user to enter a date of birth, which is accepted as valid or rejected and re -requested at blocks 328 and 330. At blocks 332-336, the MTG prompts the user, with the aid of a menu, to enter and confirm an email address. Once again, the actions of Fig. 3 A are illustrated in the menus of Figs. 4A and B.

Moving to Fig. 3B, where communication with the user is performed via IVR. Once again, the IVR functionality may be provided by MTG. At blocks 338 and 340, the user receives a call from the e-commerce service provider that provides an introduction and a reminder that the user has consented to the TOU and also recites some account data, such as user name and address.

At block 342, the e-commerce service provider asks the user to enter a credit card number that is to be added to the user's cloud-based wallet as a method of payment. At the blocks collectively labeled 344, the MTG receives and validates the user's credit card information and only proceeds forward upon receiving and entering valid credit card data. At the blocks collectively labeled 346 the user enters and re-enters a Personal Identification Number (PIN) that is used in future transactions to verify the user. After the user has successfully selected a PIN, the e-commerce service provider finishes the call at blocks 348 and 350 and sends an SMS message to the user that has a brief introduction and an instructions for the user to access the cloud-based wallet for future transactions.

Fig. 5 is an illustration of example method 500 adapted according to one embodiment. In method 500, the user tops up his or her minutes by transferring money from the cloud-based wallet to the user's mobile carrier. Method 500 includes actions that are performed by the user, the MTG, and the e-commerce service provider (PayPal in this example). Fig. 6 provides a series of example USSD text indications on a screen of a mobile phone, consistent with the method 500 of Fig. 5. While the method of Fig. 5 and the screen shots of Fig. 6 show USSD as a communication technique, the method of Fig. 5 may be accomplished using any appropriate communication technique.

At block 502, the user wishes to top-up the mobile device and dials a USSD access code associated with the payment service. At block 504, the user is presented with a welcome screen that has a menu of options, and the user enters a number consistent with the menu item for top-up.

At block 506, the user enters a desired top-up option. For instance, the user may enter an amount by which to top-up the phone or may select from a menu of amounts. Either way, the user is asked to confirm the choice at block 508 and, if the user entered an incorrect amount, the user has a chance to enter a correct amount at block 510.

At block 512, the MTG passes the information to the e-commerce service provider, and the e- commerce service provider processes the request. At block 514 the e-commerce service provider notifies the user' s carrier that the top-up was successful and transfers money accordingly. At block 516, the carrier sends the user a confirmation for the top-up with the new balance.

Method 500 illustrated by Figs. 5 and 6 show a top-up operation, wherein a user adds money to his or her mobile phone account. The scope of embodiments is not limited to top-ups, but instead can include any appropriate financial transaction. For instance, the menu shown in the first screen of Fig. 6 includes an option to send a payment to a payee. Thus, menus, such as that shown in Fig. 6, are used to provide the user at the mobile device with multiple financial transaction options. Upon selecting the "send payment" option, the user of the mobile device can transfer money to any registered account using the method 700 of Fig. 7.

Fig. 7 is an illustration of example method 700 adapted according to one embodiment for transferring money. Method 700 includes steps that are performed by a user, an MTG, and a payment service.

At blocks 702 and 704, the user is presented with the menu shown in Fig. 6 and chooses option 2— "send payment." This is similar to the actions shown at blocks 502 and 504 of Fig. 5.

At block 706, the e-commerce service provider asks the user to enter the desired amount of money to transfer. The user enters the amount using, e.g., USSD messaging. However, as explained above, the communication between the user and the MTG may include any appropriate technique.

At block 708, the e-commerce service provider asks the user for an identification of the person to whom the money will be transferred. In some embodiments, such an indication may include an email address or phone number of the payee, though other embodiments may include any appropriate indication. The user enters the identification, and the e-commerce service provider indicates to the user that the user will receive a call to confirm the transfer at block 710.

The first screen of Fig. 6 includes an additional option— "account"— by which the user at the mobile device may manage his or her account. Fig. 8 is an illustration of an example method 800 adapted according to one embodiment, whereby the user adds a method of payment to his or her cloud-based wallet. In some embodiments, the user may add any appropriate number and type of payment methods to the cloud-based wallet including, e.g., credit cards, debit cards, bank accounts, and the like. Fig. 8 illustrates the addition of a credit card, and it is understood that a similar method may be used to add methods of payment other than credit cards. Fig. 9 includes screen shots on the user's mobile device of a USSD session consistent with method 800.

At blocks 802 and 804, the user is presented the menu shown in the first screen shot of Fig. 9, and the user chooses the "account" option. At block 806, the user is presented the account menu, which in this example includes three options— "add card", "reset PIN", and "main menu." Upon selecting the "add card" option, the MTG informs the user that the remainder of the operation will be performed over the telephone (e.g., by IVR) at block 808. The blocks collectively labeled 810 provide a technique for entering as many cards as the user desires. Block 810 are similar to blocks 342 and 344 of Fig. 3B, with the addition of an option to add more than one card.

In the embodiments described above with respect to Figs. 3A-9, the MTG (e.g., MTG 120 of Fig. 1) provides the communication with the user. For instance, in the embodiment of Fig. 8, the MTG may be programmed to use both USSD and IVR to complete the operation shown. Thus, logic in the MTG may be used to facilitate a comprehensive solution for

communicating with users at mobile devices that are not connected to the Internet. Also, while the examples above include the use of USSD and IVR, it is noted that the scope of embodiments includes other forms of communication between the user and the MTG (e.g., STK and J2ME applications, SMS, and the like).

The embodiments described above provide one or more advantages. For instance, a user at a mobile device without the Internet is limited to simple financial transactions in conventional systems (e.g., one method of payment and access to only a single payee). By contrast, the above-described embodiments provide the user with a cloud-based wallet that can offer any number of appropriate payment methods (e.g., cards, bank accounts) for use in transferring money to any registered counterparty. The additional flexibility opens up many possibilities for users (especially in the developing world) who desire easier and more secure forms of payment.

Fig. 10 is a block diagram of an example computer system 100 suitable for implementing various methods and devices described herein, for example, the various action blocks of the methods 300, 500, 700, and 800. In various implementations, a MTG, a mobile carrier gateway, and a computer at the payment service may conform to the general description shown in Fig. 10. Such computers may include a network computing device (e.g., a network server, a computer processor, an electronic communications interface, etc.) capable of communicating with one or more networks. Accordingly, it should be appreciated that each of the devices may be implemented as the computer system 1000 for communication with networks in a manner as follows.

In accordance with various embodiments of the present disclosure, the computer system 1000, such as a network server, includes a bus component 1002 or other communication mechanisms for communicating information, which interconnects subsystems and components, such as processing component 1004 (e.g., processor, micro-controller, digital signal processor (DSP), etc.), system memory component 1006 (e.g., RAM), static storage component 1008 (e.g., ROM), disk drive component 1010 (e.g., magnetic or optical), network interface component 1012 (e.g., modem or Ethernet card), display component 1014 (e.g., cathode ray tube (CRT) or liquid crystal display (LCD)), input component 1016 (e.g., keyboard), cursor control component 1018 (e.g., mouse or trackball), and image capture component 1020 (e.g., analog or digital camera). In one implementation, disk drive component 1010 may comprise an array having one or more disk drive components.

In accordance with embodiments of the present disclosure, computer system 1000 performs specific operations by processor 1004 executing one or more sequences of one or more instructions contained in system memory component 1006. Such instructions may be read into system memory component 1006 from another computer readable medium, such as static storage component 1008 or disk drive component 1010. In other embodiments, hard-wired circuitry may be used in place of (or in combination with) software instructions to implement the present disclosure.

Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processor 1004 for execution. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. In one embodiment, the computer readable medium is non-transitory. In various implementations, non- volatile media includes optical or magnetic disks, such as disk drive component 1010, and volatile media includes dynamic memory, such as system memory component 1006. In one aspect, data and information related to execution instructions may be transmitted to computer system 1000 via a transmission media, such as in the form of acoustic or light waves, including those generated during radio wave and infrared data communications. In various implementations, transmission media may include coaxial cables, copper wire, and fiber optics, including wires that comprise bus 1002.

Some common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, or any other non- transitory medium from which a computer is adapted to read.

In various embodiments of the present disclosure, execution of instruction sequences to practice the present disclosure may be performed by computer system 1000. In various other embodiments of the present disclosure, a plurality of computer systems 1000 coupled by communication link 1030 (e.g., a communications network, such as a LAN, WLAN, PTSN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks) may perform instruction sequences to practice the present disclosure in coordination with one another.

Computer system 1000 may transmit and receive messages, data, information and instructions, including one or more programs (i.e., application code) through communication link 1030 and communication interface 1012. Received program code may be executed by processor 1004 as received and/or stored in disk drive component 1010 or some other non- volatile storage component for execution.

Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also, where applicable, the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components and vice- versa.

Software, in accordance with the present disclosure, such as computer program code and/or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.

It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures, wherein these labeled figures are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same.

The foregoing disclosure is not intended to limit the present disclosure to the precise forms or particular fields of use disclosed. As such, it is contemplated that various alternate embodiments and/or modifications to the present disclosure, whether explicitly described or implied herein, are possible in light of the disclosure. Having thus described embodiments of the present disclosure, persons of ordinary skill in the art will recognize that changes may be made in form and detail without departing from the scope of the present disclosure. Thus, the present disclosure is limited only by the claims.

Claims

WHAT IS CLAIMED IS:

1. A method performed by an e-commerce service provider in communication with a mobile device over a network other than the Internet, the method comprising:

providing a user of the mobile device with a plurality of financial transaction options on an interface of the mobile device;

receiving input from the user indicating at least one of the options; and

completing a financial transaction in accordance with the input from a cloud-based wallet, the cloud-based wallet providing the plurality of financial transactions by offering access to a plurality of payment methods and access to a plurality of counterparties.

2. The method of claim 1 in which providing the user with the plurality of financial transaction options comprises:

communicating with the user according to Unstructured Supplementary Service Data (USSD) protocol.

3. The method of claim 2 in which providing the user with the plurality of financial transaction options comprises:

providing a text-based menu on a screen of the mobile device using USSD.

4. The method of claim 1 in which providing the user with the plurality of financial transaction options comprises communicating with the user according to at least one of the following techniques:

Short Message Service (SMS); and

Interactive Voice Response (IVR).

5. The method of claim 1 in which providing the user with the plurality of financial transaction options comprises:

communicating with an application on the mobile device.

6. The method of claim 1 in which the application comprises at least one of a SIM Tool Kit (STK) application and a Java 2 Platform, Micro Edition (J2ME) application.

7. The method of claim 1 further comprising:

before completing the financial transaction, employing a fraud protection algorithm to discern whether the financial transaction should proceed.

8. The method of claim 7 in which the fraud protection algorithm examines at least one of the following factors in discerning whether the financial transaction is legitimate:

a country and mobile network of the user;

a cell identity of a base station serving the mobile device in the network;

an identifier of the mobile device; and

a relation between the mobile device and a Subscriber Identity Module (SIM) of the mobile device.

9. The method of claim 1 in which the e-commerce service provider communicates with the phone by using an Application Programming Interface (API) to a Mobile Transaction Gateway (MTG), where the mobile transaction gateway communicates with a mobile services provider that provides the network.

10. A method performed by a user at a phone that is in communication with an e- commerce service provider over a network other than the Internet, the method comprising: initiating a first financial transaction with the e-commerce service provider;

selecting the first financial transaction from a menu of multiple financial transaction options on an interface of the phone; and

completing the first financial transaction using a electronic wallet that includes multiple payment methods and access to multiple counterparties.

11. The method of claim 10 further comprising:

adding a payment method to the electronic wallet using the interface of the phone.

12. The method of claim 10 in which the first transaction comprises sending a payment to a counterparty.

13. The method of claim 12 in which the first transaction comprises topping up an account with a mobile carrier of the user.

14. The method of claim 10 in which selecting the first financial transaction comprises sending a message in a USSD session to a mobile transaction gateway in communication with the e-commerce service provider.

15. A network computer with at least one computer processor that executes computer- readable code to provide financial transactions, the network computer comprising:

a gateway communicating with a plurality of phones of a plurality of users over a network other than the Internet;

a communication interface with an e-commerce service provider hosting an electronic wallet that facilitates the financial transactions with multiple counterparties and with multiple methods of payment;

a database containing history data and identity data for the plurality of users and the plurality of phones; and

a workflow engine in communication with the gateway, the communication interface, and the database to provide the following functions:

providing a first one of the users of a first one of the phones with a plurality of financial transaction options on an interface of the first one of the phones;

receiving input from the first one of the users indicating at least one of the options; and

completing a first financial transaction in accordance with the input from the first one of the users.

16. The network computer of claim 15 comprising a Mobile Transaction Gateway (MTG).

17. The network computer of claim 15 in which the workflow engine communicates with the first one of the users according to Unstructured Supplementary Service Data (USSD) protocol.

18. The network computer of claim 15 in which the workflow engine communicates with a first one of the users according to at least one of the following techniques:

Short Message Service (SMS); and

Interactive Voice Response (IVR).

19. The network computer of claim 15 in which the workflow engine communicates with the first one of the users with an application on the mobile device, in which the application comprises at least one of a SIM Tool Kit (STK) application and a Java 2 Platform, Micro Edition (J2ME) application

20. The network computer of claim 15 in which the workflow engine consults the database to determine whether the first financial transaction should proceed.