HK1152405A - Mobile telephone transaction systems and methods - Google Patents

Description

Mobile telephone transaction system and method

Technical Field

In general, embodiments of the invention provide transaction systems and methods for mobile phone devices. In particular, embodiments of the present invention allow a mobile phone to be used directly as a payment device for various financial transactions in cooperation with a payment transaction server.

Background

As is well known, individuals may establish bank accounts and sign up on the accounts to purchase goods and/or services. Similarly, credit and debit cards have replaced cash (and checks) in most merchandise transactions. However, fraud, theft and other misuse of checks and credit/debit card accounts is a serious problem, wasting a lot of money for banks and customers. For example, identity theft becomes an important source of fraud, resulting in financial losses for banks and individuals. Generally, identity theft refers to sharing personal information (e.g., name, social security number, bank or credit card account number, etc.) of another person without the person's knowledge that the information is being used for fraud. For the involved individuals, the influence of identity theft can be traced back to the theft of the original information, and the affected individuals need to spend time and resources for resolution. For banks, identity theft often results in irretrievable losses. Thus, there is a strong desire from both banks and individuals to secure account data. At the same time, the convenience and general acceptance of credit/debit cards in payment transactions has led to the widespread adoption of such payment systems in the united states and throughout the world.

Another known payment technique allows an individual to transfer funds from one individual (or company) to another individual (or company) using a stored value account. For example, gift certificates or cards may be purchased, which may store a fixed amount of money before use. Other stored value accounts allow an individual to transfer funds from one source to another (e.g., credit card recharge or ACH debit card transfer to a bank account), which effectively sets up a stored value account for the recipient. The recipient then transfers the funds from the stored-value account to the physical account so that the funds are available for use. However, stored value accounts provide little protection to customers against fraud, theft, or other misuse. For example, only a few merchants will return lost gift cards, and only a few institutions will not allow the use of stolen (or just picked) gift cards. Also, the stored value account may have limited use in transferring funds to the stored value account, e.g., gift cards are typically only valid at one (or a limited number) of locations. Also, stored value accounts typically operate in a manner that avoids bank oversight, and thus stored value accounts are often operated in a very non-canonical (and unsecure) manner.

On the other hand, a significant number of individuals do not even have bank accounts and therefore cannot participate in various transactions, such as online purchases, credit/debit card transactions, and the like. For example, by 2 months 2009, it is estimated that two thousand eight million people in the united states do not have bank accounts-usually because of distrust, cultural or language barriers. Outside the united states, the proportion of "no bank account" is even higher in many countries.

Meanwhile, mobile phone devices have become very sophisticated. In addition to existing telephony functions, present mobile telephony devices also provide a handheld computing platform capable of executing various software applications and capable of connecting to a data network. Mobile telephone devices typically include a web browser application that enables a user to access websites-some developed specifically for such devices. For example, many banks have developed customized web sites that allow their customers to directly access data related to a user's account on a mobile phone. Such websites typically allow users to view balances, transfer money between user accounts, process online payments, and the like.

Similarly, a user may conduct a transaction with an online merchant by providing credit card information while browsing the website using a browser on a mobile phone device. Although this information is available from mobile phones, it provides essentially the same functionality as banking and e-commerce servers over desktop computer access networks. That is, while some users may obtain banking information and access e-commerce websites through their mobile phones, the mobile phones are not actually involved in the payment transaction.

Some schemes have been attempted to allow the mobile telephone device to directly participate in payment services. For example, Radio Frequency Identification (RFID) tags have been used to allow a mobile phone to be swung in front of a reader and to deduct funds from a stored value account associated with the phone or to charge a credit card account associated with the mobile phone with funds. However, these methods make the phone itself a target for potential identity theft, fraud or other misuse because the identity information and account number are stored on the mobile phone and these information can be misused when the mobile phone is lost or stolen. Thus, while mobile phones are widely used throughout the world, the current manner in which mobile phones are allowed to participate in payment transaction systems is not widely adopted.

Disclosure of Invention

One embodiment of the present invention provides a computer-implemented method for using a mobile phone as a payment device. Generally, the method includes receiving, by a mobile phone running a payment application, a request to participate in a payment transaction using the mobile phone as the payment device; prompting a user of the mobile phone to specify a payment source for the payment service; and sending the request for initiating the payment service and the designated payment source to a transaction server. The method may further include receiving a payment code from the transaction server; and displaying a representation of the payment code on a display screen of the mobile phone. Wherein the representation of the payment code is presented to an electronic transaction system of a merchant participating in the payment transaction. The electronic transaction system sends the payment code and an indication of a transaction amount to the transaction server. And, the transaction server performs the payment transaction in the transaction amount using the designated payment source.

Another embodiment of the invention includes a computer readable storage medium containing a program that, when executed on a processor, performs an operation for using a mobile phone as a payment device. The operations generally include receiving, by a mobile phone running a payment application, a request to participate in a payment transaction using the mobile phone as the payment device; prompting a user of the mobile phone to specify a payment source for the payment service; and sending the request for initiating the payment service and the designated payment source to a transaction server. The method may further include receiving a payment code from the transaction server; and displaying a representation of the payment code on a display screen of the mobile phone. Wherein the representation of the payment code is presented to an electronic transaction system of a merchant participating in the payment transaction. The electronic transaction system sends the payment code and an indication of a transaction amount to the transaction server. And, the transaction server performs the payment transaction in the transaction amount using the designated payment source.

Yet another embodiment of the present invention includes a mobile telephone apparatus comprising a processor and a memory device, the memory device comprising a payment application that, when run on the processor, performs an operation that uses the mobile telephone as a payment device. The operations generally include receiving, by a mobile phone running a payment application, a request to participate in a payment transaction using the mobile phone as the payment device; prompting a user of the mobile phone to specify a payment source for the payment service; and sending the request for initiating the payment service and the designated payment source to a transaction server. The method may further include receiving a payment code from the transaction server; and displaying a representation of the payment code on a display screen of the mobile phone. Wherein the representation of the payment code is presented to an electronic transaction system of a merchant participating in the payment transaction. The electronic transaction system sends the payment code and an indication of a transaction amount to the transaction server. And, the transaction server performs the payment transaction in the transaction amount using the designated payment source.

Drawings

So that the manner in which the above recited features and advantages of the present invention are attained and can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to the embodiments thereof which are illustrated in the appended drawings.

It is to be noted, however, that the appended drawings illustrate only typical embodiments and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.

FIG. 1 is a block diagram of a mobile telephone transaction system according to one embodiment of the present invention;

FIG. 2 is a block diagram further illustrating a transaction server that allows a mobile phone to participate in a payment service according to one embodiment of the present invention;

FIG. 3 is a block diagram further illustrating components of a mobile phone participating in a payment service in accordance with one embodiment of the present invention;

FIG. 4 is a flow diagram illustrating a method of registering a mobile phone with a mobile phone transaction system according to one embodiment of the invention;

FIG. 5 is a flow diagram illustrating a method for transferring money between two registered mobile phones, according to one embodiment of the present invention;

FIG. 6 is a flow diagram illustrating a method for a mobile phone to directly participate in a payment service according to one embodiment of the present invention;

FIG. 7 is a flow diagram illustrating a method for transferring money between a registered mobile phone and a third party bank or person, according to one embodiment of the invention;

figures 8A-8F are diagrams illustrating examples of user interfaces displayed on a mobile telephone device engaged in a payment service according to one embodiment of the present invention.

Detailed Description

In general, embodiments of the invention provide transaction systems and methods for mobile phone devices. For example, embodiments of the present invention allow a mobile phone to be used directly as a payment device for various financial transactions in conjunction with a payment transaction server. Moreover, the transaction systems and methods for mobile phone devices described herein allow the mobile phone to participate in payment transactions and both prevent identity theft and do not rely on transfers from one stored value account to another.

In one embodiment, an individual registers their mobile phone into a payment transaction system by providing a phone number, identifying the individual's information, and following a "know customer risk" rule or other rule. In one embodiment, the registration process may be a kiosk-driven (kiosk-driver) in which the user interacts with the kiosk to provide information about the user's mobile phone (e.g., mobile phone number) and identity information (e.g., driver's license, passport, or other government issued identification number). The kiosk itself may include a computer system that is connected to the payment transaction server over a computer network.

The transaction server may verify the registration information provided by the user as needed to ensure that: (1) the individual is indeed the person himself; and (2) the service provider with which the mobile phone is registered has an account with the phone associated with the individual.

Once the identity information is verified by the payment transaction server, a bank account is opened for the user. In one embodiment, the institution operating the transaction server may be a bank. In this case, an account may be opened at the bank for the registered person. Alternatively, the institution providing the payment transaction server may have a bank affinity. In this way, the payment transaction server may provide appropriate information to the computer system operated by the branch to open an account for the individual and the registered mobile phone. Regardless, the user may receive interest in the funds stored on the bank account, and the account is typically an insured, managed account (e.g., in the U.S., Federal Deposit Insurance Company (FDIC) may provide up to $ 250,000 insurance for an account). However, the account is directly bound to the mobile phone registered in the payment transaction system. That is, the mobile phone becomes a gateway for transferring funds in and out of different accounts associated with the mobile phone and its authorized account holder.

Also, in one embodiment, the customer may be a bank having a merchant account and a designated mobile phone number. In this case, the bank may use embodiments of the present invention to assign sub-accounts (subaccounts) to other customers to pay for or transfer bank related transactions.

Additionally, as part of the registration process, the user may provide any number of credit/debit card accounts, store-specific credit card accounts, and other bank accounts associated with the mobile phone device and the payment transaction system. These account numbers are securely stored by the payment transaction server as long as the above accounts are provided and are not stored on the mobile phone. Instead, these accounts are "virtualized" (ghosted) on the mobile phone. That is, each account registered to the payment transaction system is presented on the mobile phone and transaction server using a pseudonym or "virtual" name. For example, as part of the registration process, software running on the mobile phone may obtain the last four digits of each account number from the transaction server. The user may provide a preferred "virtual" name for each account (or simply keep a default) as long as the last four digits are obtained. Thus, when a user wishes to initiate a payment transaction, the user may select an account from among the accounts to be used as the actual source of funds, for example, a credit/debit card account. Of course, if funds are available in an account specifically bound to the mobile phone, the account may also be used to complete the payment transaction. By using a virtual process (g hosting process) to extract the user's actual payment account data (e.g., credit/debit card numbers, other account numbers, etc.), embodiments of the present invention significantly reduce the chance that the user's identity is compromised in the mobile phone transaction system described herein.

In one embodiment, a registered user may download (or otherwise have) software installed on their mobile phone. As described in detail herein, the software may be used to access an account bound to the mobile phone, such as to view account balances, transfer money, or allow the mobile phone to participate directly in payment transactions. For example, software on a mobile phone may be used to transfer funds to another mobile phone registered in the payment transaction system. In this way, the sender may designate one of a plurality of accounts for which payment is to be made (or designate an account set up for the mobile phone during registration), and corresponding funds are transferred from the account designated by the sender to another mobile phone user and stored in an account of the recipient. To use the funds, the receiving user may interact with software running on their mobile phone to transfer the funds from an account associated with the mobile phone to another account (e.g., another bank account), or to authorize an ATM (or bank teller) to convert the funds into cash.

As another example, the software may generate a barcode, payment code, or other visual or textual data for use by the merchant to complete the payment transaction. For example, an individual may interact with their mobile phone to initiate a payment transaction and select a funding source for the transaction (e.g., the user may select a virtual credit card account or select an account from a plurality of accounts bound directly to the mobile phone). In response, the software may generate a barcode to uniquely identify the transaction. The merchant then uses the device to read the bar code and recover the information identifying the transaction. The merchant's computer system then communicates with the payment transaction server using the bar code and the payment code. If an external account (e.g., credit card) is selected for use as the payment source, the transaction server attempts to recharge the selected account. If the recharge is accepted, funds are transferred to the merchant's account and the merchant is provided with information indicating that funds have been transferred to the merchant account. If an account bound to the mobile phone is selected and funds are available in the designated account, the transaction is accepted and a message is provided to the merchant that the transaction was accepted.

Similarly, a payment code may be generated to complete the online transaction. The payment code may provide an entered alphanumeric string for use in place of the real account number when conducting a payment transaction with an online merchant. The online merchant processes the payment code in a similar manner as the merchant processes the bar code described above.

In particular embodiments, the barcode (or payment code) may be valid for a limited period of time — and only for a single transaction between a particular merchant and the user of the mobile phone device. Also, to fully initiate a transaction, the user of the mobile phone may be required to enter a personal identification number (pin code) or password before the software generates the required bar code. Thus, the payment transaction system provides two-factor protection- "something you know" (i.e., personal identification number/password) and "something you have" (i.e., mobile phone). Moreover, because the barcode encodes the identification associated with the virtual account and the transaction identifier, there is no risk that the actual account associated with the transaction is involved.

Embodiments of the present invention will be described below. It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. Rather, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the invention. Moreover, the present invention provides, in various embodiments, numerous advantages over the prior art. However, although the invention has advantages that may be realized over other possible solutions and/or over the prior art, whether or not a particular advantage is obtained by a given implementation is not limiting of the invention. Thus, the following schemes, features, embodiments and advantages are merely exemplary and should not be considered elements of or limitations on the claims except where explicitly defined in the claims. Likewise, "invention" should not be considered a concept of any inventive subject matter disclosed herein, and should not be considered an element of or a limitation of the claims unless expressly defined in such claims.

One embodiment of the invention is a program product for execution by a computer system. The programs in the program product define the functions of the embodiments (including the methods described herein) and can be stored in a variety of computer-readable storage media. Exemplary computer readable storage media include, but are not limited to: (1) read-only storage media that permanently store information (e.g., read-only storage media in a computer such as a CD-ROM disk readable only by a CD-ROM drive); (2) writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive) store alterable information. Such computer-readable storage media, when carrying computer-readable instructions that direct the functions of the present invention, are embodiments of the present invention. Other media include communications media which can convey information to a computer, such as through a computer network or telephone network, including wireless communications networks. Such implementations include, among other things, communicating information to and from the internet or other networks. Such communications media, when carrying computer-readable instructions that direct the functions of the present invention, are embodiments of the present invention. Broadly, computer-readable storage media and communication media may be referred to as computer-readable media of the present application.

In general, the programs executed to implement embodiments of the invention may be part of an operating system or a specific application, component, program, module, object, or sequence of instructions. The computer program of the present invention typically is comprised of a multitude of instructions that will be translated by the native computer into a machine-readable format and hence executable instructions. Also, programs are comprised of variables and data structures that either are stored locally to the program or are stored in memory or on storage devices. In addition, various programs described hereinafter may be identified based upon the application for which they are implemented in a specific embodiment of the invention. However, it should be appreciated that the following programs are named for convenience, and thus, the present invention is not limited to use solely in the specific applications identified and/or indicated by these designations.

FIG. 1 is a block diagram illustrating a mobile telephone transaction system 100 according to one embodiment of the present invention. As shown, system 100 includes a mobile telephone 105, a client computer system 110, a transaction server 120, a branch bank 130, a participating merchant 140 or participating financial institution (i.e., a bank that receives deposits), and a registration kiosk 150, each of which communicates over a network 160. As described above, the transaction server 120 allows the mobile phone 105 to be directly used as a payment device for various financial transactions. For example, a mobile phone may be used as a payment device for transactions with merchant 140.

However, before being used as a payment device, the mobile phone 105 is registered as a participating device in the payment system 100. For example, an individual may interact with the registration kiosk 150 to register their mobile phone into the payment system 100. Illustratively, the registration kiosk 150 includes a display 152, a scanner 154, and a camera 156. The display 152 provides an output screen for displaying the user being registered and the current status of the registration process. The display 152 may be an interactive, touch-sensitive display, and the registration kiosk 156 may include a keyboard or other input/output device that allows the registering user to provide appropriate information to register their mobile phone 104 with the payment system 100. The scanner 154 may allow a user to scan an identification card (e.g., a driver's license) and to scan a credit/debit card associated with the mobile phone 105 as a virtual account. Camera 156 may be used to capture images of individuals who register their mobile phone 105 with payment system 100.

In one embodiment, transaction server 120 facilitates the process of registering mobile phone 105 and managing transactions initiated using mobile phone 105 as a payment device. As shown, the transaction Server 120 provides a computer system that includes a CPU 121, a memory 122, and a memory 120. The included CPU 164 may represent a single CPU, multiple CPUs, a single CPU having multiple processing cores, and the like. The memory 122 stores applications and data used by the transaction server 120. Examples of memory 122 include one or more hard disk drives, flash memory devices, optical media, and the like. The transaction server 120 may be connected to a network 160 (e.g., a local area network, which may be connected to other networks, such as the internet).

The memory 125 may be a memory device or a combination of memory devices including random access memory, non-volatile memory, or backup memory (e.g., programmable or flash memory, read only memory, etc.). In addition, the transaction server 120 may include input/output devices such as a mouse, keyboard, and display, as well as a network interface for connecting to the network 160. Illustratively, the memory 120 includes a web server 125 and an application server 127. As is known, the web server 125 may receive requests for access to electronic resources (e.g., HTML documents, web information) stored on the transaction server 120, and may also receive requests for transmission to the application server 127. However, those skilled in the art will appreciate that web server 125 is merely exemplary and that embodiments of the present invention may be adapted to support known and unknown protocols.

Further, as described in detail below, the application server 127 may process requests related to the mobile phone 105 registered in the payment transaction system 100, and may also request the registered mobile phone to be used as a payment device in various payment services. In general, in response to a given request, application server 127 generates a response that is sent to mobile telephone 106 (and displayed on mobile telephone 106). For example, application server 127 may generate an appropriate WAP markup document and send the WAP markup document to web server 125. The web server 125 then sends the WAP markup document to the mobile telephone 105 (e.g., via the mobile telephone network 107).

As part of the registration process, once the user provides the mobile phone number and identity information, the registration kiosk 156 may send the information to the transaction server 120 over the network 160. In response, the transaction server 120 verifies the information and confirms that the mobile phone number is indeed associated with the person who registered the phone in the payment system 100. For example, the registration kiosk 150 may communicate with the transaction server 120 to verify that the international mobile equipment identification code (IMEI) associated with the registered mobile phone is associated with the phone provided by the individual. The transaction server 120 may also verify that the registered individual has accounts for the mobile phone and the service provider and that the name on the mobile phone account matches the name in the identity information (e.g., scanned driver's license or passport) provided by the individual being registered.

If the data provided by the registering user is successfully verified, the transaction server 120 may communicate with the branch via, for example, a secure data link 135. The secure data link 135 may provide a dedicated secure communication channel for the institution providing payment transaction services to communicate with the branch bank 130. In response, branch bank 130 sets up a bank account that is directly bound to mobile phone 105. For example, the account number of the bank account may be a combination of the user's mobile phone number and the 10-digit bank account number assigned by the branch, such as:

(XXX-XXX-XXXX-XXXXXXXXXX)

{ mobile phone number } + { account number }

Once the bank account is established, the user may interact with the mobile phone 105 to transfer money to the branch's account — the mobile phone 105 may also be used to initiate payment transactions directly with the merchant 140 by using funds from one of the account or the virtual account. In other words, the mobile phone 150 itself can be directly used for various payment services by binding the user's mobile phone number with the opened bank account during the registration process.

For example, a software program installed on mobile phone 105 may generate a barcode (payment code) that is provided to the merchant for use in paying for goods/services. Thus, as shown, merchant 140 includes a bar code scanner 142 for reading a bar code displayed on mobile phone 105. Alternatively, a clerk at merchant 140 can enter a payment code (e.g., an alpha-numeric string) into electronic Payment (POS) system 114. In any case, the barcode scanner 142 (or POS system 144) obtains payment information displayed on the mobile phone 105, which is then sent in a message to the transaction server 120 along with the payment account to authorize the specified transaction. The merchant account data 124 stored on the transaction server 120 may include data related to participating merchants (e.g., merchant 140).

Illustratively, the illustrated branch bank 130 includes a bank server 131 and a customer account database 132. The customer account database 132 typically includes customer account information, such as account numbers and account balances. As described above, an account may be bound directly to a given mobile phone 105, for example, a bank account number may include the phone number of a registered mobile phone. The bank server 131 may provide a computing system (e.g., CPU, processor, and memory) with application software that receives messages from the transaction server 120. For example, bank server 131 may process a message to generate a new account for mobile phone 105, a message to obtain a balance of funds for registered mobile phone 105, a message that a payment transaction has been initiated by the phone, a message to transfer funds from one particular mobile phone to another mobile phone, a message to transfer funds to a merchant, a message to transfer funds to the account, and so on.

In one embodiment, as part of the registration process, the user may provide any number of credit/debit card accounts, stored value card accounts, and other bank accounts using the scanner 154 (or manually entering account numbers and account types) at the registration kiosk 150. Each account is then displayed as a virtual account on mobile phone 105. Importantly, the actual account number is securely stored on the transaction server 120, and not on the mobile phone 105 (fig. 1 shows the virtual account data in memory 122).

FIG. 1 also shows client computer system 110, including CPU 102, storage 104, and memory 106. As shown, memory 105 includes a web browser 108. In one embodiment, a user who is registered with the mobile telephone 10 may use the web browser 108 to obtain information relating to his account. For example, a user may request to view a balance of funds in an account bound to their mobile phone, view transactions performed by their mobile phone as a payment device, including transactions performed using a virtual account, and so forth. Furthermore, the user may define specific rules for the user side to transfer funds to (or from) the account associated with their mobile phone. For example, a user may wish to always have a minimum amount in their account, or may limit the maximum amount stored in their mobile phone account.

Fig. 2 is a block diagram illustrating a transaction server 120 that allows a mobile phone to participate in a payment service according to one embodiment of the present invention. As described above, the transaction server 120 may be a computer system having the application server 127, the application server 127 managing a mobile phone as a payment means in the mobile phone transaction system 100. As shown, the HTTP/HTTPs server may implement communications between application server 127 and mobile phone 105, web browser 108, and merchant 140 as a dispatcher (brooker). As shown, application server 127 includes a plurality of components, each providing a software module that facilitates use of mobile phone 105 in payment transactions. Of course, those skilled in the art will appreciate that the illustration of the components 205-240 as separate components is for ease of describing the present invention and that a variety of different software architectures may be used to implement the functionality of the components 205-240.

Illustratively, the application servers include a payment services component 205, a merchant services component 210, an identity services component 215, an instant detection component 220, a branch communication component 225, a payment code/barcode management component 230, an auditing component 235, and a registration component 240. The payment service component 205 may manage transactions that transfer funds from one registered mobile phone to another. That is, funds are transferred from a bank account bound with the first mobile phone 105 to a bank account bound with the further mobile phone 205. Part of the functions performed by the payment service component will be described in detail below with reference to fig. 5.

Merchant services component 210 may manage transactions between registered mobile phones and merchants. That is, merchant services component 210 manages transactions for which registered mobile phones are used directly as payment devices (e.g., using bar codes or payment codes) at participating merchants. Data relating to a particular participating merchant may be stored in database 245 as merchant account data. Some of the functions performed by the merchant services component will be described in detail below with reference to FIG. 6.

The identity service component 215 may be used to store personal information for registering a specified user in the mobile phone transaction system 100. Such as the identification number of a driver's license or passport, and biometric data obtained during the registration process at the registration kiosk, such as by a camera or fingerprint scan. Moreover, the identity service component 215 may store a password (or a hash thereof), a personal identification number, an encryption key, or other information for verifying a specified transaction initiated by a registered mobile phone.

The instant detection component 220 can manage transactions between registered mobile phones and unregistered mobile phones or third party banks. For example, in one embodiment, when a user attempts to transfer funds to a mobile phone that is not registered with the telephone transaction system 100, the instant detection component 220 may send a message (e.g., using an SMS message) to the unregistered mobile phone requesting that the recipient register their phone with the payment transaction system 100 to receive funds transferred from the registered mobile phone. Alternatively, the recipient may provide address information for mailing the check. Similarly, the instant detection component 220 can transfer funds from an account bound with a particular mobile phone at a branch to an account of a third party bank (e.g., debited using ACH). The receiving bank may deposit the funds into an account held by the recipient at a third party bank. Some of the functions of the instant detection component 220 will be described in detail below with reference to fig. 7.

The branch component 225 may provide a software component that communicates with the branch. That is, upon receipt of a payment request from a registered mobile phone (request transfer to another mobile phone or merchant), the branch component 225 verifies that the requested funds are available in the account associated with the sender mobile phone and initiates transfer from the account to the other account. Accordingly, the distributor 225 may provide services to other components (e.g., the payment services component 205, the merchant services component 210, and the instant detection component 220).

The payment code management component 230 may generate unique information for use in a specified transaction initiated by a registered mobile phone. For example, the payment code management component 230 generates a bar code assigned to the specified transaction and sends this information (in an encrypted message) to the requesting mobile phone. The merchant then scans the barcode and communicates with the merchant services component 210 to complete the requested payment transaction. After receiving the above information, merchant services component 210 may communicate with payment code management component 230 to identify the transaction (and ultimately identify the account or virtual account of a particular bank) to fund the transaction. Accordingly, the payment code management component 230 may provide services to other components of the application server 127.

Audit component 235 can generate and manage a log of the actions of other components of application server 127, and can also record a log of each transaction initiated, completed or interrupted by registered mobile phones or participating merchants. The log may be stored in a database 245.

Registration component 240 may provide a software component that manages the process of registering a given mobile phone in mobile phone transaction system 100. Thus, registration component 240 can communicate with the registration kiosk to receive and verify registration data and interact with branch component 225 to create a bank account to bind the bank account with a designated mobile phone. For example, as described above, the branch may set up a bank account for the mobile phone being registered and use the actual phone number of the mobile phone as part of the branch account number. Additionally, registration component 240 can receive the account number of the credit/debit card account and store this information in database 245 as part of virtual account data 123. Some functions of registration component 240 will be described in detail below with reference to fig. 4.

Fig. 3 is a block diagram illustrating components of mobile phone 105 participating in a payment service according to one embodiment of the present invention. As shown, mobile phone 105 includes display 305, keypad 310, CPU 315, transceiver 320, and memory 325. Typically, the display screen 305 provides a graphical display device, such as a color liquid crystal screen. The display screen 305 may provide a touch sensitive interface for displaying a virtual keyboard. Alternatively (or additionally), mobile phone 105 may include keypad 310, keypad 310 including numeric keys with 0-9 buttons or a standard english typing keypad. CPU 315 provides a processor for executing mobile phone payment application 330 and also for performing other tasks on the mobile phone (i.e., sending and receiving text messages and running other applications stored in memory 325). The transceiver 320 provides a radio frequency communication device that allows the mobile telephone to transceive voice or data transmissions over a cellular communication network, such as a CDMA or GSM network. Note that in one embodiment, mobile telephone 105 may include a transceiver for a wireless data communication network (e.g., an 802.11 network) in addition to a cellular communication network. Of course, embodiments of the present invention are applicable to currently used voice and data communication protocols, as well as other protocols that will be developed later.

Illustratively, the memory 325 on the mobile phone may include a mobile phone payment application 330, a barcode generator 335, and virtual account data 340. In one embodiment, mobile phone payment application 330 may initiate a payment transaction using the mobile phone as a payment device. After initiating the payment transaction, mobile phone payment application 330 may communicate with transaction server 127 to request a payment code (e.g., a barcode and/or a payment code). In response, transaction server 127 may then generate a unique barcode specifying the transaction and send the barcode to mobile phone 105. Mobile phone payment application 330 receives data from transaction server 127 and provides the data to barcode generator 335.

In one embodiment, barcode generator 335 may generate a display from the data received from the transaction server and display it on display screen 305. For example, transaction server 127 may generate an encoded 2D barcode and encrypt it before transmitting it to application 330 on mobile phone 105. The barcode generator 335 then decodes the message from the transaction server 127, recovers the encoded data and generates a scannable display (e.g., a JPG image) of the 2D barcode.

Virtual account data 340 stores virtual names suitable for specifying payment accounts (e.g., credit/debit cards, etc.) in a payment transaction. As described above, the virtual name is not an actual account number (e.g., an actual credit card number), and the actual account number cannot be recovered from the virtual name. Instead, each virtual name provides a code number for the real account, which is securely stored on the transaction server 127.

Fig. 4 is a flow chart illustrating a method 400 of registering a mobile phone in a mobile phone transaction system according to one embodiment of the present invention. As shown, the method 400 begins at step 405, where a registered user provides a mobile phone number to register with the mobile phone transaction system 100 at step 405. Additionally, the registered user may also provide identification data (e.g., a driver's license number or passport number). For example, as described above, a registered user may interact with the kiosk to enter their name and phone number and scan the user's credentials. Alternatively, the user may interact with a web browser or with a clerk of the merchant who participates in the registration process to provide this information.

Once the registration data is provided, the data is transmitted to the transaction server 127. Upon receiving the registration data, the transaction server 127 may verify the information provided by the registered user in step 410. For example, the transaction server 127 may communicate with a third party identity service. Similarly, a registered user may specify the service provider that he or she receives the services provided by the mobile phone. The transaction server 127 may communicate with the service provider to verify that the registered phone is associated with the phone number provided by the registered user and also that the registered user has an account for the phone at the service provider. At step 415, the transaction server communicates with the branch to set up an account, binding the account with the registered mobile phone. At step 420, the registered user may provide additional account data (e.g., credit/debit card number). As described above, this information may be securely stored on the transaction server and the virtual name may be sent to the mobile phone once the registration procedure is completed.

At step 425, the registered user installs a mobile phone payment application (e.g., mobile phone application 330 shown in fig. 3) on the mobile phone. Additionally, in one embodiment, the user may provide a personal identification number, password, or generate an encoded key to authorize a specified payment transaction with the mobile phone as the payment device. After the payment application is installed, the payment software may obtain a list of virtual accounts provided during the registration process in step 430. For example, in one embodiment, a payment application installed on a mobile phone may obtain the last four digits of each virtual account. In step 435, the user may choose to replace the default virtual code number with another virtual name.

Fig. 5 is a flow diagram illustrating a method 500 of transferring money between two registered mobile phones, according to one embodiment of the invention. Some aspects of method 500 are described with reference to exemplary mobile phone screens shown in fig. 8A-8E.

As shown, the method 500 begins at step 505, where the user interacts with a mobile phone payment application installed on the user's mobile phone at step 505. For example, FIG. 8A shows a graphical user interface display displayed on a registered mobile phone. In this particular example, mobile phone 800 includes a touch sensitive display 805, touch sensitive display 805 showing a plurality of application icons including icon 810. In this particular example, the user clicks on icon 810 to launch the payment application. Illustratively, mobile phone 800 includes a navigation control 815, navigation control 815 including a trackball for moving a display cursor in a display area to select and execute a payment application associated with icon 810. Of course, those skilled in the art will appreciate that the mobile telephone device may employ various interface controls (e.g., buttons, touch screens, etc.) that may be used to select and execute the payment application. It should be noted that in one embodiment, the user may also provide a personal identification number or password to initiate the payment application, or to invoke different payment transaction functions supported by the payment application.

Fig. 8B shows an example of clicking on the icon 810. After launching the payment application, the display 805 shows a list 820 including options to initiate different payment transactions with the mobile phone 800 and to view past transactions in the list 820. Also displayed on the mobile phone 800 is the cash balance 812 of the account associated with the mobile phone 800 (i.e., the cash balance of the branch account). Referring again to method 500, in step 510, the first mobile phone prompts for the recipient phone number and payment amount. For example, one option in the list 820 is "send cash (pay)". Fig. 8C shows an exemplary result of selecting this option, where the user is prompted to select either an existing payee (using button 825) or a new payee (using button 830). FIG. 8D shows an exemplary result of selecting the "existing payee" button 825. Exemplarily, the mobile phone 805 now shows an account list 835. Each account in the list 835 includes a payee name and a mobile phone number associated with the potential recipient. After the user selects a valid payee, the phone may prompt the user to enter an amount to be transferred to the selected recipient.

Referring again to method 500, after the user provides the payee and payment amount, the first mobile phone sends the information to the transaction server in step 515. In step 520, the transaction server contacts the branch to confirm the funds available in the account associated with the first mobile phone in the amount described above. If there is no funds available for the amount, the transaction server returns a message to the first mobile phone and the transaction is cancelled. If the funds are available as described above, the transaction server may then send a prompt to the recipient mobile phone to confirm the amount in step 525.

In step 530, the user of the recipient mobile phone may confirm the payment transaction using the mobile phone. In step 535, the transaction server notifies the first mobile phone that the transaction was cancelled if the user of the recipient mobile phone declines to receive the transfer from the first mobile phone. However, the recipient will typically agree to transfer funds to their mobile phone. In such a case, in step 540, the transaction server contacts a branch, which then transfers funds from the account associated with the first mobile phone to the account associated with the recipient mobile phone. In step 545, the transaction server notifies the first mobile phone that the transaction has been completed. The cash balance 812 shown in display 805 of fig. 8B on the sending mobile phone decreases while the cash balance displayed on the corresponding receiving mobile phone increases. Thus, the phone-to-phone transaction performed by method 500 effectively transfers funds quickly, and the cash balance displayed on each mobile phone reflects the true balance of the funds available in each account.

Note that in this example, the mobile phone of the recipient selected by the user of the first mobile phone is already registered in the mobile phone transaction system 100. Alternatively, the user may select the "new payee" button 830 shown in FIG. 8D. In this case, the user may be prompted to enter the mobile telephone number of another registered mobile telephone. However, if the mobile phone number entered by the user is not registered in the mobile phone transaction system 100, the transaction server may send a message requesting that the user of the phone be registered in the system 100 and send an instruction to register.

Fig. 6 is a flow diagram of a method 600 for a mobile phone to participate directly in a payment service with a merchant, according to one embodiment of the invention. As shown, the method 600 begins at step 605, where a user initiates a payment transaction with a participating merchant using their mobile phone as a payment device at step 605. For example, list 820 in display 805 in FIG. 8B includes an option for "make purchase" button 814.

In step 610, the mobile phone prompts the user to select a payment source to pay for a transaction with the merchant. In one embodiment, the user may select an account to be bound to the mobile phone that is set up during the registration process, or the user may select a virtual account. For example, FIG. 8E shows an exemplary result of selecting the "make purchase" button 814 shown in FIG. 8B. As shown in fig. 8E, the mobile phone 805 displays a list 840 of virtual accounts. Each entry in the list shows the code number of the virtual account registered for the phone in the mobile phone system 100. Illustratively, the virtual name of FIG. 8 includes a name for "personal VisaCard, commercial AMEXThe code of the "card and" commercial checking account ". Importantly, as noted above, despite the "commercial AMEX"this virtual name is likely to relate to American ExpressA credit card, but the actual account number of the card is not stored on the mobile phone 800.

After the user selects the funding source for the purchase transaction, the selected funding source is then sent to the transaction server at step 615. In response, the transaction server may generate a payment code and assign the payment code to the pending transaction requested by the requesting mobile phone. The payment code uniquely identifies the mobile phone participating in the transaction and the particular transaction. After the payment code is generated, the payment code may be stored in a list of pending transactions. But also the payment code can be sent to the mobile phone in the form of an encrypted message. As described above, in particular embodiments, the payment code generated by the transaction server may be valid for a limited period of time and/or used only by the merchant specified in the request for the payment code.

In step 620, the mobile phone receives the message from the transaction server, encrypts the message, and presents the payment code on the display screen. In one embodiment, the payment code may be an alphanumeric string entered at the point of sale in the merchant's sales system. Alternatively, for an online merchant, the user of the mobile phone may enter a payment code in a text box of an e-commerce website participating in the online merchant. In another embodiment, the payment code may be a 2D code generated from the payment code and displayed on the mobile phone. In this case, the user may present their mobile phone to the merchant for scanning. Such as fig. 8E.

For example, fig. 8F shows the payment code displayed in the display 805 of the mobile phone 800. Illustratively, the display area 805 shows the payment code data 845, the payment code data 845 indicating the remaining valid time of the payment code. Optionally, the display 805 shows an alphabetic payment code 850 and a 2D barcode 855 — each of which represents a payment code generated by the transaction server.

Referring again to method 600, in step 625, the merchant scans the 2D barcode 855 (or enters the alphanumeric payment code 850) to recover a transaction associated with the mobile phone originationThe payment code of (1). The merchant's electronic Payment (POS) system then sends a request to authorize a transaction of a specific amount initiated by the mobile phone user (and represented by the scanned bar code). In step 630, the transaction server acknowledges the request. For example, the transaction server may match a payment code from the merchant with a list of payment codes generated for the pending transaction. After identifying the payment code, the transaction server then processes the transaction using the virtual account specified by the user. For example, assume that the user selects the name "Business AMEX" as shown in FIG. 8E"and assuming that the virtual account does refer to American ExpressA credit card. In this case, the transaction Server obtains and "Business AMEXThe virtual account corresponds to the actual account number, and the amount specified by the merchant is added to the account in an attempt. In this case, the transaction server may allow the merchant to recharge the account with a credit card processing vending machine.

Alternatively, the user may choose to pay for the transaction using an account set up for the mobile phone during the registration process. In this case, the transaction server communicates with the branch to confirm that funds are available in the account requesting the purchase, and if so, transfers funds from the mobile phone account to the associated merchant.

Referring again to method 600, in step 640, if there are no funds available in the mobile phone account (or if the transaction of the virtual account is cancelled, for example, if American expressThe credit card is cancelled), then in step 645 a message is sent to the merchant and the mobile phone that the transaction was cancelled. Otherwise, atIn step 650, if the transaction is successfully completed, a message confirming the funds transfer or a message providing the appropriate authorization code to process the virtual account is sent to the merchant. Optionally, a message of a successful transaction may also be sent to the mobile phone.

Fig. 7 illustrates a flow diagram of a method 700 of transferring money between a registered mobile phone and a third party bank or person, according to one embodiment of the invention. As shown, method 700 begins at step 705, where a user initiates a payment to a third party or non-participating individual (i.e., an individual not registered with a mobile phone in mobile phone transaction system 100) in step 705. In step 710, the mobile phone prompts the user for a payee name and payment account. For example, to transfer funds to an individual, a user may specify a name, address, and payment account. To transfer funds to a third party bank, the user may specify a bank routing number (bank routing number) and an account number. The payment application on the mobile phone then sends this information to the transaction server.

In step 715, the transaction server confirms that funds are available in the account set up for the mobile phone during the registration process. If there are funds available and payment to the third party bank is requested, the transaction server sends a message to the branch to transfer the requested funds from the branch to the designated account of the third party bank in step 720. After the transaction is completed, the transaction server sends a confirmation message of the completion of the transaction to the mobile phone.

In step 725, if payment is requested to the third party, the transaction server sends a message requesting that the branch generate a check on which the requested amount is written and which indicates the requested individual as a payee. After the transaction is completed, the transaction server sends a confirmation message to the mobile phone confirming the completion of the transaction.

Advantageously, as described herein, embodiments of the present invention allow a mobile phone connected to a payment transaction server to be directly used as a payment device in various financial transactions. Furthermore, the transaction system and method for a mobile phone described herein enables the mobile phone to participate in payment transactions, both to prevent identity theft and to not rely on the transfer of money between one stored value account to another.

While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the scope thereof, and the scope thereof is determined by the claims that follow.

Claims (24)

1. A computer-implemented method for using a mobile phone as a payment device, comprising:

receiving, by a mobile phone running a payment application, a request to participate in a payment transaction using the mobile phone as the payment device;

prompting a user of the mobile phone to specify a payment source for the payment service;

sending the request for initiating the payment service and the appointed payment source to a transaction server;

receiving a payment code from the transaction server; and

displaying a representation of the payment code on a display screen of the mobile phone, wherein the representation of the payment code is presented to an electronic transaction system of a merchant participating in the payment transaction, wherein the electronic transaction system sends the payment code and an indication of a transaction amount to the transaction server, and the transaction server performs the payment transaction at the transaction amount using a specified payment source.

2. The method of claim 1, further comprising:

establishing a bank account for the mobile phone prior to receiving a request to initiate the payment transaction using the mobile phone as the payment device, wherein the bank account is bound to an individual user of the mobile phone and a phone number of the mobile phone.

3. The method of claim 2, wherein the payment source is the bank account established for the mobile phone.

4. The method of claim 2, wherein the transaction server is further configured to:

after determining that there are sufficient funds available in the bank account established for the mobile phone to cover the transaction amount, transferring funds from the bank account established for the mobile phone to an account associated with the merchant, and sending confirmation to the mobile phone and the electronic payment system that the payment transaction was successfully completed.

5. The method of claim 1, wherein the representation of the payment code displayed on the display screen of the mobile phone comprises: a machine readable barcode scanned by the electronic transaction system of the merchant.

6. The method of claim 1, wherein the representation of the payment code displayed on the display screen of the mobile phone comprises: inputting an alphanumeric string of the electronic transaction system of the merchant.

7. The method of claim 1, wherein the payment source comprises a virtual account name stored on the mobile phone, wherein the virtual account data identifies a payment account for processing the payment transaction without revealing an account number of the payment account.

8. The method of claim 7, wherein the transaction server is further configured to:

identifying a payment account associated with virtual account data received from the payment application on the mobile phone;

initiating a recharge of the transaction amount to the identified payment account; and

after determining that recharging of the payment account is permitted, sending a confirmation of successful completion of the payment service to the mobile phone and the electronic transaction system.

9. A computer-readable storage medium containing a program which, when executed on a processor, performs operations for using a mobile phone as a payment device, the operations comprising:

receiving, by a mobile phone running a payment application, a request to participate in a payment transaction using the mobile phone as the payment device;

prompting a user of the mobile phone to specify a payment source for the payment service;

sending the request for initiating the payment service and the appointed payment source to a transaction server;

receiving a payment code from the transaction server; and

displaying a representation of the payment code on a display screen of the mobile phone, wherein the representation of the payment code is presented to an electronic transaction system of a merchant participating in the payment transaction, wherein the electronic transaction system sends the payment code and an indication of a transaction amount to the transaction server, and the transaction server performs the payment transaction at the transaction amount using a specified payment source.

10. The computer-readable storage medium of claim 9, wherein the operations further comprise:

establishing a bank account for the mobile phone prior to receiving a request to initiate the payment transaction using the mobile phone as the payment device, wherein the bank account is bound to an individual user of the mobile phone and a phone number of the mobile phone.

11. The computer-readable storage medium of claim 10, wherein the payment source is the bank account established for the mobile phone.

12. The computer-readable storage medium of claim 11, wherein the transaction server is further configured to:

after determining that there are sufficient funds available in the bank account established for the mobile phone to cover the transaction amount, transferring funds from the bank account established for the mobile phone to an account associated with the merchant, and sending confirmation to the mobile phone and the electronic payment system that the payment transaction was successfully completed.

13. The computer-readable storage medium of claim 9, wherein the representation of the payment code displayed on the display screen of the mobile phone comprises: a machine readable barcode scanned by the electronic transaction system of the merchant.

14. The computer-readable storage medium of claim 9, wherein the representation of the payment code displayed on the display screen of the mobile phone comprises: inputting an alphanumeric string of the electronic transaction system of the merchant.

15. The computer-readable storage medium of claim 9, wherein the payment source comprises a virtual account name stored on the mobile phone, wherein the virtual account data identifies a payment account for processing the payment transaction without revealing an account number of the payment account.

16. The computer-readable storage medium of claim 9, wherein the transaction server is further configured to:

identifying a payment account associated with virtual account data received from the payment application on the mobile phone;

initiating a recharge of the transaction amount to the identified payment account; and

after determining that recharging of the payment account is permitted, sending a confirmation of successful completion of the payment service to the mobile phone and the electronic transaction system.

17. A mobile telephone apparatus comprising:

a processor; and

a memory device including a payment application that, when executed on the processor, performs operations for using a mobile phone as a payment device, the operations comprising:

receiving, by a mobile phone running a payment application, a request to participate in a payment transaction using the mobile phone as the payment device;

prompting a user of the mobile phone to specify a payment source for the payment service;

sending the request for initiating the payment service and the appointed payment source to a transaction server;

receiving a payment code from the transaction server; and

displaying a representation of the payment code on a display screen of the mobile phone, wherein the representation of the payment code is presented to an electronic transaction system of a merchant participating in the payment transaction, wherein the electronic transaction system sends the payment code and an indication of a transaction amount to the transaction server, and the transaction server performs the payment transaction at the transaction amount using a specified payment source.

18. The mobile telephony device of claim 17, wherein the operations further comprise:

establishing a bank account for the mobile phone prior to receiving a request to initiate the payment transaction using the mobile phone as the payment device, wherein the bank account is bound to an individual user of the mobile phone and a phone number of the mobile phone.

19. The mobile phone device of claim 17, wherein the payment source is the bank account established for the mobile phone.

20. The mobile telephony device of claim 19, wherein the transaction server is further configured to:

after determining that there are sufficient funds available in the bank account established for the mobile phone to cover the transaction amount, transferring funds from the bank account established for the mobile phone to an account associated with the merchant, and sending confirmation to the mobile phone and the electronic payment system that the payment transaction was successfully completed.

21. The mobile telephone device of claim 17, wherein the representation of the payment code displayed on the display screen of the mobile telephone comprises: a machine readable barcode scanned by the electronic transaction system of the merchant.

22. The mobile telephone device of claim 17, wherein the representation of the payment code displayed on the display screen of the mobile telephone comprises: inputting an alphanumeric string of the electronic transaction system of the merchant.

23. The mobile phone device of claim 17, wherein the payment source comprises a virtual account name stored on the mobile phone, wherein the virtual account data identifies a payment account for processing the payment transaction without revealing an account number of the payment account.

24. The mobile telephony device of claim 23, wherein the transaction server is further configured to:

identifying a payment account associated with virtual account data received from the payment application on the mobile phone;

initiating a recharge of the transaction amount to the identified payment account; and

after determining that recharging of the payment account is permitted, sending a confirmation of successful completion of the payment service to the mobile phone and the electronic transaction system.