Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20090281904 A1
Publication typeApplication
Application numberUS 12/412,235
Publication dateNov 12, 2009
Filing dateMar 26, 2009
Priority dateApr 2, 2008
Also published asCA2719944A1, CA2719945A1, CA2720126A1, CN101990676A, CN101990770A, CN101990772A, EP2266087A2, EP2266087A4, EP2266332A1, EP2266332A4, EP2266335A1, EP2266335A4, US8301500, US20090254440, US20090254479, WO2009146106A1, WO2009146110A1, WO2009146111A2, WO2009146111A3
Publication number12412235, 412235, US 2009/0281904 A1, US 2009/281904 A1, US 20090281904 A1, US 20090281904A1, US 2009281904 A1, US 2009281904A1, US-A1-20090281904, US-A1-2009281904, US2009/0281904A1, US2009/281904A1, US20090281904 A1, US20090281904A1, US2009281904 A1, US2009281904A1
InventorsDennis J. Pharris
Original AssigneePharris Dennis J
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Mobile telephone transaction systems and methods
US 20090281904 A1
Abstract
Techniques are disclosed for a mobile telephone, in conjunction with a payment transaction server, to be used directly as a payment device for a variety of financial transactions. Further, the transaction systems and methods for mobile telephone devices described herein allow a mobile telephone to participate in payment transactions in a manner that helps prevent identify theft and without relying on transferring amounts to/from one stored value account to another.
Images(11)
Previous page
Next page
Claims(24)
1. A computer-implemented method for using a mobile telephone as a payment device, comprising:
receiving, by a payment application executing the mobile telephone, a request to engage in a payment transaction using the mobile telephone as the payment device;
prompting a user of the mobile telephone to specify a payment source for the payment transaction;
transmitting the request to initiate the payment transaction and the specified payment source to a transaction server;
receiving a payment code from the transaction server; and
displaying, on a display screen of the mobile telephone, a representation of the payment code, wherein the representation of the payment code is presented to a point-of-sale system of a merchant participating in the payment transaction, wherein the point-of-sale system is configured to transmit an indication of the payment code and a transaction amount to the transaction server, and wherein the transaction server is configured to perform the payment transaction using the specified payment source for the payment amount.
2. The computer-implemented method of claim 1, further comprising, prior to receiving the request to initiate the payment transaction using the mobile telephone as the payment device, establishing a bank account for the mobile telephone, wherein the bank account is tied to both an individual user of the mobile telephone and a telephone number of the mobile telephone.
3. The computer-implemented method of claim 2, wherein the payment source is the bank account established for the mobile telephone.
4. The computer-implemented method of claim 3, wherein the transaction server is further configured to:
upon determining sufficient funds are available in the bank account established for the mobile telephone to cover the transaction amount:
transfer funds from the bank account established for the mobile telephone to an account associated with the merchant, and
transmit, to both the mobile telephone and the point of sale system, a confirmation that the payment transaction was completed successfully.
5. The computer-implemented method of claim 1, wherein the representation of the payment code displayed on the display screen of the mobile telephone comprises a machine readable barcode scanned by the point-of-sale system at the merchant.
6. The computer-implemented method of claim 1, wherein the representation of the payment code displayed on the display screen of the mobile telephone comprises an alphanumeric string keyed into the point-of-sale system at the merchant.
7. The computer-implemented method of claim 1, wherein the payment source comprises ghosted account stored on the mobile telephone, wherein the ghosted account data identifies a payment account for processing the payment transaction without revealing an account number associated with the payment account.
8. The computer-implemented method of claim 7, wherein the transaction server is further configured to:
identify the payment account associated with the ghosted account data received from the payment application on the mobile phone;
initiate a charge to the identified payment account for the transaction amount; and
upon determining that the charge to the payment account has been approved, transmit, to both the mobile telephone and the point of sale system, a confirmation that the payment transaction was completed successfully.
9. A computer-readable storage medium containing a program, which, when executed on a processor performs an operation for using a mobile telephone as a payment device, the operation comprising:
receiving, by a payment application executing the mobile telephone, a request to engage in a payment transaction using the mobile telephone as the payment device;
prompting a user of the mobile telephone to specify a payment source for the payment transaction;
transmitting the request to initiate the payment transaction and the specified payment source to a transaction server;
receiving a payment code from the transaction server; and
displaying, on a display screen of the mobile telephone, a representation of the payment code, wherein the representation of the payment code is presented to a point-of-sale system of a merchant participating in the payment transaction, wherein the point-of-sale system is configured to transmit an indication of the payment code and a transaction amount to the transaction server, and wherein the transaction server is configured to perform the payment transaction using the specified payment source for the payment amount.
10. The computer-readable storage medium of claim 9, wherein the operation further comprises, prior to receiving the request to initiate the payment transaction using the mobile telephone as the payment device, establishing a bank account for the mobile telephone, wherein the bank account is tied to both an individual user of the mobile telephone and a telephone number of the mobile telephone.
11. The computer-readable storage medium of claim 10, wherein the payment source is the bank account established for the mobile telephone.
12. The computer-readable storage medium of claim 11, wherein the transaction server is further configured to:
upon determining sufficient funds are available in the bank account established for the mobile telephone to cover the transaction amount:
transfer funds from the bank account established for the mobile telephone to an account associated with the merchant, and
transmit, to both the mobile telephone and the point of sale system, a confirmation that the payment transaction was completed successfully.
13. The computer-readable storage medium of claim 9, wherein the representation of the payment code displayed on the display screen of the mobile telephone comprises a machine readable barcode scanned by the point-of-sale system at 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 telephone comprises an alphanumeric string keyed into the point-of-sale system at the merchant.
15. The computer-readable storage medium of claim 9, wherein the payment source comprises ghosted account stored on the mobile telephone, wherein the ghosted account data identifies a payment account for processing the payment transaction without revealing an account number associated with the payment account.
16. The computer-readable storage medium of claim 15, wherein the transaction server is further configured to:
identify the payment account associated with the ghosted account data received from the payment application on the mobile phone;
initiate a charge to the identified payment account for the transaction amount; and
upon determining that the charge to the payment account has been approved, transmit, to both the mobile telephone and the point of sale system, a confirmation that the payment transaction was completed successfully.
17. A mobile telephone device, comprising:
a processor; and
a memory containing a payment application, which when executed by the processor performs an operation for using the mobile telephone as a payment device, the operation comprising:
receiving a request to initiate a payment transaction using the mobile telephone as the payment device;
prompting a user of the mobile telephone to specify a payment source for the payment transaction;
transmitting the request to initiate the payment transaction and the specified payment source to a transaction server;
receiving a payment code from the transaction server; and
displaying, on a display screen of the mobile telephone, a representation of the payment code, wherein the representation of the payment code is presented to a point-of-sale system of a merchant participating in the payment transaction, wherein the point-of-sale system is configured to transmit an indication of the payment code and a transaction amount to the transaction server, and wherein the transaction server is configured to perform the payment transaction using the specified payment source for the payment amount.
18. The mobile telephone device of claim 17, wherein the operation further comprises, prior to receiving the request to initiate the payment transaction using the mobile telephone as the payment device, establishing a bank account for the mobile telephone, wherein the bank account is tied to both an individual user of the mobile telephone and a telephone number of the mobile telephone.
19. The mobile telephone device of claim 18, wherein the payment source is the bank account established for the mobile telephone.
20. The mobile telephone device of claim 19, wherein the transaction server is further configured to:
upon determining sufficient funds are available in the bank account established for the mobile telephone to cover the transaction amount:
transfer funds from the bank account established for the mobile telephone to an account associated with the merchant, and
transmit, to both the mobile telephone and the point of sale system, a confirmation that the payment transaction was completed successfully.
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 point-of-sale system at 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 an alphanumeric string keyed into the point-of-sale system at the merchant.
23. The mobile telephone device of claim 17, wherein the payment source comprises ghosted account stored on the mobile telephone, wherein the ghosted account data identifies a payment account for processing the payment transaction without revealing an account number associated with the payment account.
24. The mobile telephone device of claim 23, wherein the transaction server is further configured to:
identify the payment account associated with the ghosted account data received from the payment application on the mobile phone;
initiate a charge to the identified payment account for the transaction amount; and
upon determining that the charge to the payment account has been approved, transmit, to both the mobile telephone and the point of sale system, a confirmation that the payment transaction was completed successfully.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims benefit of U.S. Provisional Patent Application Ser. No. 61/041,723, filed Apr. 2, 2008. This application also claims benefit of U.S. Provisional Patent Application Ser. No. 61/127,314, filed on May 12, 2008. Both provisional applications are incorporated by reference herein in their entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the invention generally provide transaction systems and methods for mobile telephone devices. More specifically, embodiments of the invention allow a mobile telephone, in conjunction with a payment transaction server, to be directly used as a payment device for a variety of financial transactions.

2. Description of the Related Art

As is well known, individuals may establish an account with a bank and write checks drawn on their account to pay for goods and/or services. Similarly, credit and debit cards have replaced the use of cash (and checks) in a large percentage of commercial transactions. However, fraud, theft, and other misuse of checks and credit/debit accounts is a serious problem, costing both banks and consumers substantial sums of money. For example, identity theft has become a significant source of fraud, resulting in financial losses to both banks and individuals. Identify theft generally refers to the co-option of another person's personal information (e.g., name, social security number, bank or credit card account numbers, etc.) without that person's knowledge coupled with the fraudulent use of such information. For the individual involved, the effects of identity theft may reverberate well past an initial theft of information—costing time and resources for the affected individual to address. For the bank, identity theft typically results in unrecoverable losses. Thus, both banks and individuals have a strong incentive to keep account data secure. At the same time, the convenience and near-universal acceptance of credit/debit cards for payment transactions has resulted in extremely widespread adoption of these payment systems both in the United States and around the world.

Another well known payment technique allows individuals to transfer funds from one person to another (or to/from a business) using stored value accounts. For example, gift certificates or gift cards may be purchased and used to store a fixed value amount until used. Other stored value accounts allow individuals to transfer funds from one source (e.g., a charge to a credit card or an ACH debit to a bank account) to another—effectively creating a stored value account for the recipient. The recipient in turn, transfers amounts from the stored value account to an actual account—from which the funds are made available. However, stored value accounts provide consumers with little protection against fraud, theft, or other misuse. Few merchants, e.g., will replace a lost gift card and few mechanisms are used to deter the use of a stolen (or simply found) gift card. Further, stored value accounts may limit the use of funds transferred to the stored value account, e.g., a gift-card is typically good for a single (or limited number) of locations. Further still, stored value accounts are frequently operated in a manner to avoid banking regulation, and thus often operate in a largely unregulated (and uninsured) manner.

At the other end of the spectrum, a sizeable number of individuals do not even have a bank account, and thus, cannot participate in a variety of transactions, e.g., on-line purchases, credit/debit card transactions, etc. As of February 2009, for example, an estimated 28 million people in the United States do not have a bank account—often because of mistrust, cultural, or language barriers. Outside of the United States, the percentage of the “unbanked” is even higher in many countries.

At the same time, mobile telephone devices have become highly sophisticated. In addition to conventional telephone functionality, current mobile telephones provide a handheld computing platform capable of executing a variety of software applications as well as connecting to a data network. Mobile telephones frequently include a web-browser application which allows users to access web sites—some developed specifically for such devices. For example, many banks have developed customized web-sites allowing their customers to access data related to their account directly on a mobile phone. Such websites typically allow users to view balances, transfer funds between their accounts, schedule on-line payments, etc. Similarly, users can make purchases from online merchants by providing credit card information while browsing a website using a browser running on a mobile phone device. While having access to this information from a mobile phone is useful, it essentially provides the same functionality as on-line banking and e-commerce services accessed from a desktop computer. That is, while some users can access banking information and e-commerce websites from their mobile telephone, the mobile telephone device does not, in fact, participate in a payment transaction.

Some approaches have been tried to allow a mobile telephone device to participate in payment transactions directly. For example, radio frequency ID (RFID) tags have been used to allow a mobile phone to be waived in front of a reader and have amounts deducted from a stored value account associated with the telephone or have amounts charged to a credit card account associated with the mobile telephone. However, such approaches turn the phone itself into a target for potential identity theft, fraud or other misuse, as identifying information and account numbers are stored on the mobile phone and subject to misuse when a mobile telephone is lost or stolen. Thus, current approaches for allowing a mobile phone to participate in payment transactions systems have not experienced widespread adoption—despite the overwhelmingly worldwide adoption of mobile phones generally.

SUMMARY OF THE INVENTION

One embodiment of the invention provides a computer implemented method for using a mobile telephone as a payment device. The method may generally include receiving a request to engage in a payment transaction using the mobile telephone as the payment device, prompting a user of the mobile telephone to specify a payment source for the payment transaction, and transmitting the request to initiate the payment transaction and the specified payment source to a transaction server. The method may further include receiving a payment code from the transaction server and displaying, on a display screen of the mobile telephone, a representation of the payment code. The representation of the payment code is presented to a point-of-sale system of a merchant participating in the payment transaction. The point-of-sale system may generally be configured to transmit an indication of the payment code and a transaction amount to the transaction server. Further, the transaction server itself may be configured to perform the payment transaction using the specified payment source for the payment amount.

Another embodiment of the invention includes a computer-readable storage medium containing a program, which, when executed on a processor performs an operation for using a mobile telephone as a payment device. The operation may generally include receiving a request to initiate a payment transaction using the mobile telephone as the payment device, prompting a user of the mobile telephone to specify a payment source for the payment transaction, and transmitting the request to initiate the payment transaction and the specified payment source to a transaction server. The operation may further include receiving a payment code from the transaction server and displaying, on a display screen of the mobile telephone, a representation of the payment code. The representation of the payment code is presented to a point-of-sale system of a merchant participating in the payment transaction. The point-of-sale system may generally be configured to transmit an indication of the payment code and a transaction amount to the transaction server. Further, the transaction server itself may be configured to perform the payment transaction using the specified payment source for the payment amount.

Still another embodiment includes a mobile telephone device having a processor and a memory containing a payment application, which when executed by the processor performs an operation for using the mobile telephone as a payment device. The operation may generally include receiving a request to initiate a payment transaction using the mobile telephone as the payment device, prompting a user of the mobile telephone to specify a payment source for the payment transaction, and transmitting the request to initiate the payment transaction and the specified payment source to a transaction server. The operation may further include receiving a payment code from the transaction server and displaying, on a display screen of the mobile telephone, a representation of the payment code. The representation of the payment code is presented to a point-of-sale system of a merchant participating in the payment transaction. The point-of-sale system may generally be configured to transmit an indication of the payment code and a transaction amount to the transaction server. Further, the transaction server itself may be configured to perform the payment transaction using the specified payment source for the payment amount.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above recited features, advantages and objects 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 of this invention 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 illustrating a mobile telephone transaction system, according to one embodiment of the invention.

FIG. 2 is a block diagram further illustrating a transaction server configured to allow a mobile telephone to participate in a payment transaction, according to one embodiment of the invention.

FIG. 3 is a block diagram further illustrating components of a mobile telephone configured to engage in payment transactions, according to one embodiment of the invention.

FIG. 4 is a flow diagram illustrating a method for enrolling a mobile telephone in a mobile telephone transaction system, according to one embodiment of the invention.

FIG. 5 is a flow diagram illustrating a method for a funds transfer between two enrolled mobile phones, according to one embodiment of the invention.

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

FIG. 7 is a flow diagram illustrating a method for a funds transfer between an enrolled mobile phone and a third-party bank or individual, according to one embodiment of the invention.

FIGS. 8A-8F are examples of graphical user interfaces displays on a mobile telephone device configured to participate in payment transactions, according to one embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments of the invention generally provide transaction systems and methods for mobile telephone devices. For example, embodiments of the invention allow a mobile telephone, in conjunction with a payment transaction server, to be used directly as a payment device for a variety of financial transactions. Further, the transaction systems and methods for mobile telephone devices described herein allow a mobile telephone to participate in payment transactions in a manner that both prevents identify theft and does not rely on transferring amounts to/from one stored value account to another.

In one embodiment, an individual enrolls their mobile telephone in the payment transaction system by providing a cell phone number, along with information as needed to identify that individual and to comply with “know-your-customer” laws, or other regulations. In a particular embodiment, the enrollment process may be kiosk-driven, where the user interacts with a kiosk to provide information regarding their cell phone (e.g., a cell phone number) and identifying information (e.g., a drivers' license, passport, or other government issued identification number). The kiosk itself may include a computer system connected over a computer network to the payment transaction server.

The transaction server may vet the enrollment information provided by the user as needed to ensure (i) that the individual is, in fact, who they represent themselves to be and (ii) that a service provider for the mobile phone being enrolled has an account for the phone that is associated with the individual.

Once the information is vetted by the payment transaction server, a bank account may be opened for the user. In one embodiment, the entity operating the transaction server may itself be a bank. In such a case, the account may be opened for the enrolling individual at that bank. Alternatively, the entity providing the payment transaction server may have a bank affiliate. In such a case, the transaction server may provide the appropriate information to a computer system operated by the affiliate bank to establish an account for the individual and mobile telephone being enrolled. In any event, the user may receive interest on amounts deposited in the bank account, and the account generally function as a typical insured, regulated account (e.g., in the United States, bank accounts are insured for amounts up to $250,000 by the Federal Deposit Insurance Corporation (FDIC)). However, the account is tied directly to the mobile telephone being enrolled in the payment transaction system. That is the mobile telephone becomes a gateway for moving funds into or out of the various bank accounts associated with the mobile telephone and its authorized account holder.

Further, in one embodiment, the customer may be a bank with a merchant account and a designated mobile telephone number. In such a case, the bank may designate subaccounts for other customers using embodiments of the invention to make payments or transfers to a bank related transaction.

Additionally as part of the enrollment process, the user may provide any number of credit/debit card accounts, store-specific credit card accounts, and other bank accounts to associate with the mobile telephone device and the payment transaction system. Once provided, such account numbers are stored securely by the payment transaction server, and not on the user's mobile phone. Instead, the accounts are “ghosted,” on the mobile telephone. That is, each account enrolled with the payment transaction system is represented on the mobile telephone and the transaction server using an alias or “ghosted” name. For example, software running on the mobile telephone may retrieve the last four digits of each account number from the transaction server as part of the enrollment process. Once retrieved, the user may provide a preferred “ghosted” name for each account (or simply stick with the default). Thereafter, when the user wishes to initiate a payment transaction, the user may select one of the accounts to use as the actual source of funds, e.g., a credit/debit card account. Of course, if funds are available in the account specifically tied to the mobile phone, that account may be used to complete a payment transaction as well. By abstracting the user's actual payment account data (e.g., credit/debit card numbers, other bank account numbers, etc.) using the ghosting process, embodiments of the invention greatly reduce the potential for identify theft for users of the mobile phone transaction system described herein.

In one embodiment, the enrolling user may download (or otherwise have) software installed on their mobile telephone. As described in greater detail herein, the software may be used to access the accounts tied to the mobile telephone, e.g., to view balances in that account, to transfer funds, or to allow the mobile telephone to engage in a payment transaction directly. For example, the software on the mobile telephone may be used to transfer funds to another mobile telephone enrolled in the payment transaction system. In such a case, the sender may designate one of the multiple bank accounts from which the transfer should be drawn (or designate the account established for the mobile phone during the enrollment process), and in response funds are moved from the account designated by the sender to another mobile telephone user and deposited to one an account of the recipient. To access such funds, the receiving user may interact with the software running on their mobile telephone to move the funds from the account associated with the mobile phone to another (e.g., to another bank account) or to authorize an ATM (or bank teller) to convert the funds to actual currency.

As another example, the software may be used to generate barcodes, pay codes, or other visual or textual data used by a merchant to complete in a payment transaction. For example, the individual may interact with their mobile phone to initiate a payment transaction and to select a source of funds for the transaction (e.g., the user may select a ghosted credit card account or one of the various accounts tied directly to the mobile phone). In response, the software may generate a barcode used to uniquely identify that transaction. The merchant than uses a device to read the barcode and recover the information identifying the transaction. A computer system at the merchant then contacts the payment transaction server with the barcode and a payment amount. If an external account was selected as the source of payment (e.g., a credit card), then the transaction server attempts to charge the selected account. If the charge is approved, funds are transferred to the merchant's account and a message indicating such is provided to the merchant. If the account tied to the mobile telephone is selected, then, provided funds are available in that designated account, the transaction is approved and a message indicating such is provided to the merchant.

Similarly, a pay code may be generated to complete an on-line purchase. A pay code may provide an alpha-numeric text string entered in place of an actual account number when engaging in payment transaction with an online merchant. The on-line merchant processes the pay code in a manner similar to that described above for a merchant to process a bar code.

In a particular embodiment, the barcode (or pay code) may be valid for a limited period of time—and good for only a single transaction between a specified merchant and the user of the mobile telephone device. Further, to initiate a transaction at all, the user of the mobile phone may be required to enter a pin number or password before the software will generate a requested barcode. Thus, the payment transaction system provides two-factor security—“something you know” (i.e., the pin/password) and “something you have” (i.e., the mobile telephone). Further, because the barcode encodes the identification associated with the ghosted account and transaction identifier, the actual account numbers associated with the transaction are not at risk of being comprised.

In the following, reference is made to embodiments of the invention. However, it should be understood that the invention is not limited to specific described embodiments. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the invention. Furthermore, in various embodiments the invention provides numerous advantages over the prior art. However, although embodiments of the invention may achieve advantages over other possible solutions and/or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the invention. Thus, the following aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).

One embodiment of the invention is implemented as a program product for use with a computer system. The program(s) of the program product defines functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive) on which information is permanently stored; (ii) writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive) on which alterable information is stored. 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 through which information is conveyed to a computer, such as through a computer or telephone network, including wireless communications networks. The latter embodiment specifically includes transmitting information to/from the Internet and 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 communications media may be referred to herein as computer-readable media.

In general, the routines executed to implement the 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 reside locally to the program or are found 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 any particular program nomenclature that follows is used merely for convenience, and thus the invention should not be limited to use solely in any specific application identified and/or implied by such nomenclature.

FIG. 1 is a block diagram illustrating a mobile telephone transaction system 100, according to one embodiment of the invention. As shown, the system 100 includes a mobile phone 105, a client computer system 110, a transaction server 120, an affiliate bank 130, a participating merchant 140, or participating financial institution (i.e., a depository bank), and an enrollment kiosk 150—each configured to communicate over a network 160. As described above, the transaction server 120 allows the mobile telephone 105 to be used directly as a payment device for a variety of financial transactions. For example, the mobile phone may be used as a payment device with the merchant 140.

Prior to being used as a payment device, however, the mobile phone 105 is enrolled in the payment system 100 as a participating device. For example, an individual may interact with enrollment kiosk 150 to enroll their mobile phone in the payment system 100. Illustratively, the enrollment kiosk 150 includes a display 152, a scanner 154, and a camera 156. The display 152 provides an output screen presenting an enrolling user with the current status of the enrollment process. Display 152 may be an interactive, touch sensitive display and the enrollment kiosk 156 may include a keyboard or other input/output devices, allowing the enrolling user to supply the appropriate information to enroll their mobile phone 104 in the payment system 100. Scanner 154 may allow the user to scan both identification cards (e.g., a driver's license) as well as scan credit/debit cards to associate with the mobile telephone 105 as a ghosted account. Camera 156 may be used to capture an image of the individual enrolling a given mobile phone 105 in the payment system 100.

In one embodiment, the transaction server 120 facilitates the process of enrolling the mobile phone 105 as well as manages transactions initiated using the mobile phone 105 as a payment device. As shown, the transaction server 120 provides a computing system which includes a CPU 121, storage 122 and memory 120. CPU 164 is included to be representative of a single CPU, multiple CPUs, a single CPU having multiple processing cores, and the like. Storage 122 stores application programs and data for use by the transaction server 120. Examples of storage 122 include one or more hard-disk drives, flash memory devices, optical media and the like. The transaction server 120 may be connected to the network 160 (e.g., a local area network, which itself may be connected to other networks such as the internet).

Memory 125 can be one or a combination of memory devices, including random access memory, nonvolatile or backup memory (e.g., programmable or flash memories, read-only memories, etc.). Additionally, the transaction server 120 may include input/output devices such as a mouse, keyboard and monitor, as well as a network interface used to connect to network 160. Illustratively, the memory 120 includes a web server 125 and an application server 127. As is known, web server 125 may receive to requests for access to electronic resources residing on the transaction server 120 (e.g., HTML documents, network information, as well as receive requests passed to application server 127). However, one of ordinary skill in the art will recognize that the web server process 125 is merely illustrative and embodiments of the invention may be adapted to support both known and unknown protocols.

Additionally, as described in greater detail below, application server 127 may be configured to process requests related to enrolling mobile phone 105 in the payment transaction system 100 as well as requests to use an enrolled mobile phone as a payment device in a variety of payment transactions. Generally, in response to a given request, the application server 127 generates a response transmitted to (and rendered for display on) the mobile telephone 106. For example, the application server 127 may generate the appropriate WAP markup document, and pass it to the web server 125. In turn, the web-server 125 transmits the WAP markup document to the mobile telephone 105 (e.g., over a cellular network 107).

As part of the enrollment process, once a user supplies their mobile telephone number and identification information, the enrollment kiosk 156 may communicate this information to the transaction server 120 over network 160. In response, the transaction server 120 validates the information and verifies that the mobile phone number is, in fact, associated with the individual enrolling that phone in the payment system 100. For example, the enrollment kiosk 150 may communicate with the transaction server 120 to verify that the International Mobile Equipment Identity (IMEI) number associated with the mobile phone being enrolled is associated with the telephone number provided by the individual. The transaction server 120 may also verify the named individual being enrolled has an account for that mobile telephone with a service provider—and that the name on the mobile telephone account matches the name in the identification (e.g., a scanned drivers license or passport) provided by the enrolling individual.

Provided the data supplied by the enrolling user is successfully validated, the transaction server 120 may communicate with an affiliate bank, e.g., over a secure data link 135. The secure data link 135 may provide a dedicated, secure communications channel for the entity providing the payment transaction service to communicate with the affiliate bank 130. In response, the affiliate bank 130 establishes a bank account tied directly to the mobile phone 105. For example, the account number for the bank account may be a combination of the user's mobile phone number and a 10 digit bank account number assigned by the affiliate bank as follows:

(XXX-XXX-XXXX-XXXXXXXXXX)

{mobile phone number}+{Account Number}

Once established, the user may interact with the mobile phone 105 to transfer money to the account with the affiliate bank—as well as use the mobile phone 105 directly to initiate payment transactions with merchants 140 using either funds from the account or using one of the ghosted accounts. In other words, by binding the user's mobile telephone number to the bank account opened during the enrollment process, the mobile phone 150 itself may be used in a variety of payment transactions directly.

For example, a software application installed on the mobile phone 105 may generate a barcode (or pay code) presented to the merchant 140 as payment for goods/services. Thus, as shown, merchant 140 includes a barcode scanner 142 used to read a barcode displayed on mobile phone 105. Alternatively, a pay code (e.g., an alpha-numeric text string) may be keyed into point-of-sale (POS) system 144 by a clerk at merchant 140. In any case, the payment information presented on the mobile phone 105 is captured by the barcode scanner 142 (or POS system 144) and transmitted in a message to the transaction server 120, along with a payment amount, to authorize a given transaction. Merchant account data 124 stored on transaction server 120 may include data related to participating merchants (e.g., merchant 140).

Illustratively, the affiliate bank 130 is shown to include a bank server 131 and a customer account database 132. Customer account database 132 generally includes customer account information, e.g., account numbers and account balances. As stated, the accounts may be tied directly to a given mobile phone 105, e.g., the phone number of an enrolled mobile phone may be incorporated into the bank account number. The bank server 131 may provide a computing system (e.g., a CPU, processor, and a memory) with application software configured to receive messages from the transaction server 120. For example, the bank server 131 may process messages to create a new account for a mobile telephone 105; messages to obtain a current balance of the account for an enrolled mobile phone 105; messages that the phone has initiated a payment transaction; messages to transfer funds from one participating mobile phone to another; messages to transfer funds to a merchant, messages to transfer funds to the account etc.

In one embodiment, as part of the enrollment process, the user may provide any number of credit/debit card accounts, store-specific credit card accounts, and other bank accounts using the scanner 154 (or may manually key in the account numbers and account types) at enrollment kiosk 150. Each such account is subsequently presented on the mobile telephone 105 as a ghosted account. Importantly, the actual account numbers are stored securely on the transaction server 120 and not on the mobile telephone 105 (shown in FIG. 1 as ghosted account data 123 in storage 122).

FIG. 1 also shows a client computer system 110 including a CPU 102, storage 104 and a memory 106. As shown, the memory 105 includes a web-browser 108. In one embodiment, the user of an enrolled mobile phone 105 may obtain information about their account using the web browser 108. For example, a user may request to see the current balance in the account tied to their mobile phone, review transactions performed with their mobile phone as a payment device, including transactions funded using ghosted accounts, and the like. Further, a user may define a user-profile specifying rules for moving funds into (or out of) the account associated with their mobile phone. For example, a user may desire to always have a minimum amount of funds in their account, or may limit the amount of funds to store in their mobile-phone account to a specified maximum.

FIG. 2 is a block diagram further illustrating a transaction server 120 configured to allow a mobile telephone to participate in a payment transaction, according to one embodiment of the invention. As noted above, the transaction server 120 may be a computer system configured with an application server 127 configured to manage the use of mobile phones as payment devices in the mobile telephone transaction system 100. As shown, an HTTP/HTTPS server may be used to broker communications between the application server 127 and the mobile phone 105, web-browser 108, and merchant 140. As show, the application server 127 includes a plurality of components, each providing a software module configured to facilitate the use of mobile phone 105 in payment transactions. Of course, one of ordinary skill in the art will recognize that the components 205-240 are shown as individual components to facilitate a description of the invention and that a variety of different software architectures may be used to implement the functionality of the components 205-240.

Illustratively, the application server includes a payment services component 205, a merchant services component 210, an identity services component 215, an instant check component 220, an affiliate bank communications component 225, a paycode/barcode management component 230, an auditing component 235, and an enrollment registration component 240. The payment services component 205 may be configured to manage transactions to transfer funds from one enrolled mobile phone to another. That is, from a bank account tied to a first mobile phone 105 to a bank account tied to another mobile phone 205. Some of the functions performed by the payment services component are described in greater detail below in conjunction with a description of FIG. 5.

The a merchant services component 210 may be configured to manage transactions between an enrolled mobile phone and a merchant. That is, the merchant services component 210 manages transactions where an enrolled mobile phone is used directly as a payment device at a participating merchant, e.g., using a barcode or a pay code. Data related to a particular participating merchant may be stored as merchant account data in database 245. Some of the functions performed by the merchant services component 210 are described in greater detail below in conjunction with a description of FIG. 6.

The identity services component 215 may be used to store the identification information used to enroll a given user in the mobile telephone transaction system 100. For example, the identification number of a driver's license or passport as well as biometric data such as a camera or fingerprint scan obtained during the enrollment process at an enrollment kiosk. Further, the identify service component 215 may store passwords (or hashes of same), pin numbers, encryption keys, or other information used to authenticate a given transaction requested initiated by an enrolled mobile phone.

The instant check component 220 may be configured to manage transactions between an enrolled mobile phone and a non-enrolled mobile phone or third party bank. For example, in one embodiment, when a user attempts to send funds to a mobile phone not enrolled in the mobile telephone transaction system 100, the instant check component 220 may send a message to the non-enrolled mobile phone (e.g., using an SMS message) requesting that the recipient enroll their phone in the payment transaction system 100 in order to receive funds transferred from the enrolled mobile phone. Alternatively, the recipient may supply address information for a paper check to be mailed. Similarly, instant check component 220 may be configured to transfer funds from the account tied to a particular mobile phone at the affiliate bank to an account at a third party bank (e.g., using an ACH debit). The receiving bank may deposit the funds in an account held by the recipient at the third party bank. Some of the functions performed by the instant check component 220 are described in greater detail below in conjunction with a description of FIG. 7.

The affiliate bank component 225 may provide a software component be configured to communicate with the affiliate bank. That is, as payment requests are received from an enrolled mobile phone (for transfer to another mobile phone or to a merchant), the affiliate bank component 225 verifies the requested funds are available in the account associated with the sending mobile phone, as well as initiate transfers from that account to others. Thus, the affiliate bank 225 may provide services to other components (e.g., the payment services component 205, merchant services component 210, and instant check component 220).

The pay code management component 230 may be configured to generate unique information used in a given transaction initiated by an enrolled mobile phone. For example, the pay code management component 230 may generate a barcode assigned to a given transaction and send this information (in an encrypted message) to a requesting mobile phone. The merchant then scans the barcode and communicates with the merchant services component 210 to compete a requested payment transaction. Once received, the merchant services component 210 may communicate with the pay code management component 230 to identify the transaction (and ultimately, the account at the particular bank or ghosted account) being used to fund a transaction. Thus, the pay code management component 230 may provide services to other components of the application server 127.

The auditing component 235 may be configured to create and manage a log of both the actions of the other components of the application server 127, as well as record a log of each transaction initiated, completed, or interrupted by an enrolled mobile phone or participating merchant. The log may be stored in database 245.

The enrollment registration component 240 may provide a software component configured to manage the process of enrolling a given mobile phone in the mobile telephone transaction system 100. Thus, the enrollment registration component 240 may communicate with an enrollment kiosk to receive and validate enrollment data and interact with the affiliate bank component 225 to create a bank account to bind to a given mobile phone being enrolled. For example, as described above, the affiliate bank may establish a bank account for the mobile phone being enrolled and use the actual phone number of that mobile phone as part of the account number with the affiliate bank. Additionally, the enrollment registration component 240 may receive account numbers for credit/debit card accounts and store this information as part of ghosted account data 123 in database 245. Some of the functions performed by the enrollment registration component 240 are described in greater detail below in conjunction with a description of FIG. 4.

FIG. 3 is a block diagram further illustrating components of a mobile phone 105 configured to engage in payment transactions, according to one embodiment of the invention. As shown, the mobile telephone 105 includes a display screen 305, a keypad 310, a CPU 315, a transceiver 320, and a memory 325. The display screen 305 generally provide a graphical display device such as an color LCD screen. The display screen 305 may provide a touch sensitive interface used to present a virtual keyboard. Alternatively, (or additionally) the mobile phone 105 may include a keypad 310 including a number pad with a buttons for 0-9 or a full QWERTY keyboard. CPU 315 provides a processor used to execute a mobile phone payment application 330, as well as perform other tasks on mobile phone 105 (namely, sending and receiving text messages and running other application programs stored in the memory 325. Transceiver 320 provides a radio communication device allowing the mobile phone to send and receive voice and data transmissions over a cellular communication network (e.g., a CDMA or GSM network). Note, in one embodiment, in addition to the cellular communication network, mobile phone 105 may include a transceiver used to communicate over a wireless data communication network (e.g., an 802.11 network). Of course, embodiments of the invention may be adapted for use with these currently used voice and data communications protocols as well as other protocols subsequently developed.

Illustratively, the memory 325 on the mobile phone may include a mobile phone payment application 330, a barcode generator 335 and ghosted account data 340. In one embodiment, mobile phone payment application 330 may be used to initiate a payment transaction using the mobile phone as the payment device. Once initiated, the mobile phone payment application 330 may communicate with the transaction server 127 to request a payment code (e.g., a barcode and/or a pay code). In response, the transaction server 127 may then generate a barcode unique to a given transaction and transmit it to the mobile phone 105. The mobile phone payment application 330 receives data from the transaction server 127 and supplies it to the barcode generator 335.

In one embodiment, the barcode generator 335 may generate a display from the data received from the transaction server and display it on display screen 305. For example, the transaction server 127 may generate an encoding of a 2-D barcode, encrypt it, and transmit it to the application 330 on the mobile phone 105. In turn, the barcode generator 335 may decrypt the message from the transaction server 127, recover the encoded data, and generate a scannable display of the 2D barcode (e.g., a JPG image).

Ghosted account data 340 stores the ghosted names of payment accounts (e.g., credit/debit cards, etc.) available to use in a given payment transaction. As noted above, the ghosted names are not the actual account numbers (e.g., an actual credit card number) and nor are the actual account numbers recoverable from the ghosted names. Instead, each ghosted name provides an alias for an actual account, where the actual account numbers remain securely stored on the transaction server 127.

FIG. 4 is a flow diagram illustrating a method 400 for enrolling a mobile telephone in a mobile telephone transaction system, according to one embodiment of the invention. As shown, the method 400 begins at step 405 where an enrolling user supplies a mobile phone number to enroll in the mobile telephone transaction system 100. Additionally, the enrolling user may supply identification data (e.g., a driver's license number or passport number). For example, as described above, an enrolling user may interact with a kiosk to enter their name and phone number and to scan their driver's license. Alternatively, a user may interact with a web browser to provide the same information or with a clerk at a merchant participating in the enrollment process.

Once supplied the enrollment data is transmitted to the transaction server 127. Once received, at step 410, the transaction server 127 may be configured to verify information supplied by the enrolling user. For example, the transaction server 127 may communicate with third-party identification services. Similarly, the enrolling user may indicate a service provider from which they receive mobile phone services. The transaction server 127 may communicate with the service provider to verify that the phone being enrolled is associated with the phone number supplied by the enrolling user—as well as verify that the enrolling user has an account for that phone with the service provider. At step 415, the transaction communicates with the affiliate bank to establish an account to bind to the mobile telephone being enrolled. At step 420, the enrolling user may supply additional account data (e.g., credit/debit card numbers). As noted above, this information may be stored securely on the transaction server, and ghosted names may be transmitted to the mobile phone once the enrollment process is complete.

At step 425, the enrolling user installs a mobile phone payment application on their mobile phone. (e.g., the mobile phone application 330 of FIG. 3). Additionally, in one embodiment, the user may supply a pin, password, or generate encryption keys used to authorize a given payment transaction using the mobile phone as a payment device. Once installed, at step 430, the payment software may retrieve a list of ghosted accounts supplied during the enrollment process. For example, in one embodiment, the payment application installed on the mobile phone may retrieve the last four digits associated with each ghosted account. At step 435, the user may select to replace the default ghosted alias with another ghosted name.

FIG. 5 is a flow diagram illustrating a method 500 for transferring funds between two enrolled mobile phones, according to one embodiment of the invention. Some aspects of the method 500 are described relative to the exemplary mobile phone interface screens shown in FIGS. 8A-8E.

As shown, the method 500 begins at step 505 where a user interacts with the mobile phone payment application installed on their mobile phone. For example, FIG. 8A illustrates an example graphical user interface display shown on an enrolled mobile phone. In this particular example, mobile phone 800 includes a touch sensitive display screen 805 showing a plurality of application icons, including icon 810. In this particular example, user clicks on the icon 810 to launch the payment application. Illustratively, mobile phone 800 includes navigation controls 815, including a track-ball used to move a display cursor in display area 805 to select and execute the payment application associated with icon 810. Of course, one of skill in the art will recognize that mobile phone devices may be configured using a variety of interface controls (e.g., buttons, touch-screens, etc.), which may be used to select and execute the payment application. Note, in one embodiment, a user may also have to supply a pin number or password to launch the payment application—or to invoke different payment transaction functions supported by the payment application.

An example of clicking on icon 810 is shown in FIG. 8B. Once launched, the display 805 shows a list 820 of options for initiating different payment transactions using mobile phone 800, as well as options for reviewing past transactions. Further, a current cash balance 812 of the account associated with the mobile phone 800 is also displayed on mobile phone 800 (i.e., the cash balance of the account with the affiliate bank). Referring again to method 500, at step 510, the first mobile phone prompts for a recipient phone number and payment amount. For example, one of the items in the list 820 is to “send cash (payment).” An example of the result of selecting this option is shown in FIG. 8C, where the user is prompted to select an existing payee (using a button 825) or a new payee (using a button 830). And an example of the result of selecting the “existing payee” button 825 is shown in FIG. 8D. Illustratively, the mobile phone display 805 now shows a list 835 of accounts. Each account in the list 835 includes a payee name and the mobile phone number associated with that possible recipient. Once the user selects one of the available payees, the phone may prompt the user to enter an amount to transfer to the selected recipient.

Referring again to the method 500, once the user supplies a payee and a payment amount, at step 515, the first mobile phone sends this information to the transaction server. At step 520, the transaction server contacts the affiliate bank to confirm that funds are available in the account associated with the first mobile phone. If not, the transaction server sends a message back to the first mobile phone, and the transaction is cancelled. Provided such funds are available, at step 525, the transaction server may send a prompt to the recipient mobile phone to confirm the payment account.

At step 530, the user of the recipient mobile phone may confirm the payment transaction using their mobile phone. At step 535, if the user of the recipient mobile phone declines to receive a transfer of funds from the first mobile phone, then the transaction server notifies the first mobile phone that the transaction was declined. Typically, however, it is expected that the recipient will approve the transfer of funds to their mobile phone. In such a case, at step 540, the transaction server contacts the affiliate bank, which transfers funds from the account associated with the first mobile phone to the account associated with the recipient mobile phone. At step 545, the transaction server notifies the first mobile phone that the transaction has been completed. The current cash balance 812 shown in display 805 of FIG. 8B may be reduced on the sending mobile phone and increased by a corresponding amount on the recipient mobile phone. Thus, the phone-to-phone transaction performed by method 500 operates to transfer funds from both accounts virtually instantaneously, and the amounts shown in the current cash balance 812 on each mobile phone reflect a true balance of the funds available in each account.

Note, in this example, the user of the first mobile phone selected a recipient with a mobile phone that has already been enrolled in the mobile telephone transaction system 100. Alternatively, the user may select the “new payee” button 830 shown in FIG. 8D. In such a case, the user may be prompted to enter the mobile phone number for another enrolled mobile phone. However, if the user enters a mobile phone number for a phone that has not been enrolled in the mobile telephone transaction system 100, then the transaction server may transmit a message requesting that the user of that phone enroll in the system 100, along with instructions for doing so.

FIG. 6 is a flow diagram illustrating a method 600 for a mobile phone to participate directly in a payment transaction 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. For example, the list 820 of display 805 in FIG. 8B includes a choice to “make a purchase” button 814.

At step 610, the mobile phone prompts the user to select a payment source to fund the purchase transaction with the merchant. In one embodiment, the user may select the account tied to the mobile phone that was established during the enrollment process or the user may select a ghosted account. For example, FIG. 8E shows an example of the result of selecting the “make a purchase” button 814 shown in FIG. 8B. As shown in FIG. 8E, the mobile phone display 805 presents a list 840 of ghosted accounts. Each entry in the list shows an alias name of the ghosted account enrolled for that phone in the mobile telephone transaction system 100. Illustratively, the ghosted names in FIG. 8 include entries for a “personal Visa® card” a “business AMEX®” card, and a “business checking” account. Importantly, as noted above, while the ghosted name of “business AMEX®” likely refers to an American Express® charge card, the actual account number for this card is not stored on the mobile phone 800.

At step 615, once the user selects a funding source for a purchase transaction, the selected source is transmitted to the transaction server. In response, the transaction server may generate a payment code and assign the code to a pending transaction for the requesting mobile phone. The payment code uniquely identifies the mobile phone participating in the transaction as well as the particular transaction. Once generated, the payment code may be stored in a list of pending transactions. Further the payment code may be transmitted to the mobile phone in an encrypted message. As noted above, in a particular embodiment, the payment code generated by the transaction server may be valid for a limited period of time and/or good for use only by a merchant identified in the request for the payment code.

At step 620, the mobile phone receives the message from the transaction server, decrypts it, and presents a payment code on the display screen. In one embodiment, the payment code may be an alphanumeric text string keyed into a point of sale system at the merchant. Alternatively, for an on-line merchant, the user of the mobile phone may enter the payment code in a text box in a e-commerce website of a participating online merchant. In another embodiment, the payment code may be a 2D barcode generated from the payment code and displayed on the mobile phone. In such a case, the user may present their mobile phone to the merchant to be scanned. For example, FIG. 8E.

For example, FIG. 8F shows a payment code being displayed in the display 805 of mobile phone 800. Illustratively, the display area 805 shows payment code data 845 indicating how long remains before the payment code expires. Additionally, display 805 shows both an alphanumeric pay code 850 and a 2D barcode 855—each of which provide a representation of the payment code generated by the transaction server.

Referring again to the method 600, at step 625, the merchant scans the 2D bar code 855 (or enters the alphanumeric pay code 850) to recover the payment code associated with the transaction initiated by the mobile phone. The merchant's point-of-sale (POS) system then sends a request to authorize the transaction initiated by the mobile phone user (and represented by the scanned barcode) for a specified amount. At step 630, the transaction server validates the request. For example, the transaction server may match the payment code received from the merchant with the list of payment codes generated for pending transactions. Once identified, the transaction server processes the transaction using the ghosted account specified by the user. For example, assume the user selected the ghosted account with the name “business AMEX®” as shown in FIG. 8E, and assume that this ghosted account does refer to an American Express charge account. In such a case, the transaction server retrieves the actual account number corresponding to the “business AMEX®” ghosted account and attempts to charge the amount specified by the merchant to that account. In such a case, the transaction server may have a merchant charge account with a credit card processing vendor.

Alternatively, the user may have selected to fund the transaction using the account established for the mobile phone during the enrollment process. In such a case, the transaction server communicates with the affiliate bank to verify that funds are available in the requested purchase amount, and if so, transfers funds from the mobile phone account to an associated with the merchant.

Referring again to the method 600, at step 640, if funds are not available in the mobile phone account (or if transaction is declined for the ghosted account, e.g., the American Express charge card is declined), then at step 645 a message is sent to the merchant and the mobile phone that the transaction was declined. Otherwise, at step 650, if the transaction is completed successfully, a message confirming transfer of funds or providing the appropriate authorization code from processing a ghosted account is sent to the merchant. Additionally, a message confirming the successful transaction may be sent to the mobile phone as well.

FIG. 7 is a flow diagram illustrating a method 700 for performing a funds transfer between an enrolled mobile phone and a third-party bank or individual, according to one embodiment of the invention. As shown, the method 700 begins at step 705 where a user initiates a payment to a third party bank or to a non-participating individual (i.e., an individual who has not enrolled a mobile phone in the mobile telephone transaction system 100). At step 710, the mobile phone prompts the user to provide a recipient name and payment amount. For example, to transfer funds to an individual, the user may specify a name, address, and payment amount. To transfer funds to a third-party bank, the user may specify a bank routing number and an account number. The payment application on the mobile phone then sends this information to the transaction server.

At step 715, the transaction server verifies that funds are available in the account established for the mobile phone during the enrollment process. Provided funds are available, if payment is requested to be made to a third-party bank, then at step 720, the transaction server sends a message to the affiliate bank to transfer the requested amount from the affiliate bank to the specified account at the third party bank. Once completed, the transaction server sends a confirmation message to the mobile phone that the transaction was completed.

At step 725, if the payment is requested to be made to a third party, then the transaction server sends a message requesting the affiliate bank generate a paper check made out in the requested amount naming the requested individual as payee. Once completed, the transaction server sends a confirmation message to the mobile phone that the transaction was completed.

Advantageously, as described herein, embodiments of the invention allow a mobile telephone, in conjunction with a payment transaction server, to be used directly as a payment device for a variety of financial transactions. Further, the transaction systems and methods for mobile telephone devices described herein allow a mobile telephone to participate in payment transactions in a manner that both prevent identify theft and does not rely on transferring amounts to/from 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 basic scope thereof, and the scope thereof is determined by the claims that follow.

Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5991749 *Sep 9, 1997Nov 23, 1999Morrill, Jr.; Paul H.Wireless telephony for collecting tolls, conducting financial transactions, and authorizing other activities
US7423535 *Aug 5, 2005Sep 9, 2008Avante International Technology, Inc.Object monitoring, locating, and tracking method employing RFID devices
US7657489 *Jan 18, 2007Feb 2, 2010Mocapay, Inc.Systems and method for secure wireless payment transactions
US7865414 *Feb 26, 2004Jan 4, 2011Passgate CorporationMethod, system and computer readable medium for web site account and e-commerce management from a central location
US8073774 *Jun 6, 2006Dec 6, 2011Sms.Ac, Inc.Billing system and method for micro-transactions
US8073783 *Aug 22, 2007Dec 6, 2011Felsted Patrick RPerforming a business transaction without disclosing sensitive identity information to a relying party
US20020042776 *Sep 19, 2001Apr 11, 2002Woo Kevin K.M.System and method for unifying electronic payment mechanisms
US20020065774 *Nov 30, 2000May 30, 2002Alan YoungSystem and method for performing an electronic transaction using a transaction proxy with an electronic wallet
US20020161708 *Jan 31, 2002Oct 31, 2002Gero OfferMethod and apparatus for performing a cashless payment transaction
US20030101137 *Nov 27, 2001May 29, 2003Pitney Bowes IncorporatedMethod and system for authorizing use of a transaction card
US20030195842 *Apr 15, 2003Oct 16, 2003Kenneth ReeceMethod and device for making secure transactions
US20040030645 *Apr 12, 2002Feb 12, 2004Stephen MonaghanMethod and system for performing a transaction utilising a thin payment network (mvent)
US20050222961 *Sep 14, 2004Oct 6, 2005Philippe StaibSystem and method of facilitating contactless payment transactions across different payment systems using a common mobile device acting as a stored value device
US20060200427 *Aug 1, 2005Sep 7, 2006Morrison Robert ASystems and methods for securing transactions with biometric information
US20060206709 *Mar 24, 2006Sep 14, 2006Fujitsu LimitedAuthentication services using mobile device
US20060235796 *Apr 18, 2006Oct 19, 2006Microsoft CorporationAuthentication for a commercial transaction using a mobile module
US20060265243 *May 15, 2006Nov 23, 2006Jeffrey RachoSystem and method for establishing or verifying a person's identity using SMS and MMS over a wireless communications network
US20060278698 *Jul 11, 2006Dec 14, 2006Robert LovettSystem, method and program product for account transaction validation
US20070022058 *Jul 18, 2006Jan 25, 2007Fujitsu LimitedWireless computer wallet for physical point of sale (POS) transactions
US20070125838 *Mar 15, 2006Jun 7, 2007Law Eric C WElectronic wallet management
US20070125840 *Jul 5, 2006Jun 7, 2007Boncle, Inc.Extended electronic wallet management
US20070175978 *Jan 18, 2007Aug 2, 2007H2West CorporationSystems and method for secure wireless payment transactions
US20070260558 *Apr 16, 2007Nov 8, 2007Look Thomas FMethods and systems for secure transactions with electronic devices
US20080011825 *Jul 12, 2006Jan 17, 2008Giordano Claeton JTransactions using handheld electronic devices based on unobtrusive provisioning of the devices
US20080017704 *Feb 7, 2007Jan 24, 2008First Data CorporationContactless Electronic Wallet Payment Device
US20080040285 *Feb 16, 2007Feb 14, 2008John WankmuellerMethod And System For Authorizing A Transaction Using A Dynamic Authorization Code
US20080048022 *Aug 23, 2006Feb 28, 2008Mci Financial Management Corp.Virtual wallet
US20080208743 *Jul 30, 2007Aug 28, 2008First Data CorporationTransfer of value between mobile devices in a mobile commerce system
US20080208744 *Jul 30, 2007Aug 28, 2008First Data CorporationMobile commerce systems and methods
US20080208762 *Jul 30, 2007Aug 28, 2008First Data CorporationPayments using a mobile commerce device
US20080210751 *Mar 21, 2006Sep 4, 2008Young-Su KimSystem And Method For Transferring Money Based On Approval Of Transfer Request Transmitted From Receiver To Sender
US20080229410 *Aug 22, 2007Sep 18, 2008Novell, Inc.Performing a business transaction without disclosing sensitive identity information to a relying party
US20080249928 *Aug 10, 2007Oct 9, 2008Hill Dennis JPayment card based remittance system with designation of recipient by mobile telephone number
US20080255947 *Apr 9, 2008Oct 16, 2008First Data CorporationMobile commerce infrastructure systems and methods
US20080275779 *Feb 7, 2008Nov 6, 2008Dhamodharan LakshminarayananMobile payment services
US20090037285 *Jul 30, 2007Feb 5, 2009Murphy Timothy MMethod and system for dynamic funding
US20090063312 *Aug 27, 2008Mar 5, 2009Hurst Douglas JMethod and System for Processing Secure Wireless Payment Transactions and for Providing a Virtual Terminal for Merchant Processing of Such Transactions
US20090138366 *Jan 27, 2009May 28, 2009Yt Acquisition CorporationMethod and system for providing biometric authentication at a point-of-sale via a moble device
US20090144161 *Nov 30, 2007Jun 4, 2009Mobile Candy Dish, Inc.Method and system for conducting an online payment transaction using a mobile communication device
US20090171845 *Oct 24, 2008Jul 2, 2009Jonathan Robert PowellMethods and systems for cardholder initiated transactions
US20090182634 *Jan 12, 2009Jul 16, 2009Park David SImage-Based Payment Medium
US20090200371 *Feb 4, 2009Aug 13, 2009First Data CorporationOnetime passwords for smart chip cards
US20090248537 *Dec 1, 2006Oct 1, 2009Shahriar SarkeshikCommercial transaction facilitation system
US20090266884 *Jul 10, 2009Oct 29, 2009Patrick KillianDual use payment device
US20100057619 *Apr 6, 2009Mar 4, 2010Visa International Service AssociationAccount authentication service with chip card
US20100063895 *Nov 12, 2009Mar 11, 2010Visa International Service AssociationMobile account authentication service
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7962411 *Sep 30, 2008Jun 14, 2011United Services Automobile Association (Usaa)Atomic deposit transaction
US7970677 *Oct 24, 2008Jun 28, 2011United Services Automobile Association (Usaa)Systems and methods for financial deposits by electronic message
US8090616 *Feb 3, 2009Jan 3, 2012Proctor Jr James ArthurVisual identification information used as confirmation in a wireless communication
US8301500Mar 26, 2009Oct 30, 2012Global 1 EnterprisesGhosting payment account data in a mobile telephone payment transaction system
US8385913Feb 3, 2009Feb 26, 2013Proxicom Wireless, LlcUsing a first wireless link to exchange identification information used to communicate over a second wireless link
US8401539 *Jan 31, 2012Mar 19, 2013American Express Travel Related Services Company, Inc.Servicing attributes on a mobile device
US8490865 *May 11, 2012Jul 23, 2013National Payment Card AssociationPayment system and methods
US8500013 *Aug 19, 2011Aug 6, 2013General Electric CompanySystems and methods for accessing charging capabilities of electric vehicle charging stations
US8503993 *Jun 2, 2010Aug 6, 2013Alibaba Group Holding LimitedMethod and system for payment through mobile devices
US8571939 *Jul 7, 2010Oct 29, 2013Toshiba Global Commerce Solutions Holdings CorporationTwo phase payment link and authorization for mobile devices
US8738450 *Jan 28, 2010May 27, 2014Bank Of America CorporationAudible transaction process and system
US8744914 *Jan 28, 2010Jun 3, 2014Bank Of America CorporationMobile device consumer interface process and system
US8774781 *Nov 1, 2012Jul 8, 2014First Data CorporationMobile payment and identity verification system
US20090298427 *May 29, 2009Dec 3, 2009Total System Services, Inc.System And Method For Processing Transactions Without Providing Account Information To A Payee
US20100161433 *Dec 19, 2008Jun 24, 2010Spencer WhiteSystems and Methods for Handling Point-of-Sale Transactions Using a Mobile Device
US20100257067 *Sep 22, 2009Oct 7, 2010Tai Man ChanRemote web service appliance for point of sale actions
US20100311397 *Jun 2, 2010Dec 9, 2010Alibaba Group Holding LimitedMethod and system for payment through mobile devices
US20100312703 *Jun 1, 2010Dec 9, 2010Ashish KulpatiSystem and method for providing authentication for card not present transactions using mobile device
US20110071924 *Sep 18, 2009Mar 24, 2011Pitney Bowes Inc.System and method for processing consumer transactions using a central server and a mobile processor
US20110125610 *Nov 18, 2010May 26, 2011Boku, Inc.Systems and Methods to Automate the Initiation of Transactions via Mobile Devices
US20110178884 *Jan 5, 2011Jul 21, 2011Mordechai TeicherTrusted stored-value payment system that includes untrusted merchant terminals
US20110184819 *Jan 28, 2010Jul 28, 2011Bank Of America CorporationAudible transaction process and system
US20110184820 *Jan 28, 2010Jul 28, 2011Bank Of America CorporationMobile device consumer interface process and system
US20110219427 *Feb 28, 2011Sep 8, 2011RSSBus, Inc.Smart Device User Authentication
US20110225057 *Mar 11, 2011Sep 15, 2011Wal-Mart Stores, Inc.System and method for transaction payments using a mobile device
US20110231270 *Jan 13, 2011Sep 22, 2011Verifone, Inc.Payment systems and methodologies
US20120011009 *Jul 7, 2010Jan 12, 2012International Business Machines CorporationTwo phase payment link and authorization for mobile devices
US20120129514 *Jan 31, 2012May 24, 2012American Express Travel Related Services Company, Inc.Servicing attributes on a mobile device
US20120185398 *Sep 10, 2010Jul 19, 2012Meir WeisMobile payment system with two-point authentication
US20120203697 *Feb 10, 2011Aug 9, 2012American Express Travel Related Services Company, Inc.Systems and methods for facilitating secure transactions
US20120278232 *May 11, 2012Nov 1, 2012Randazza Joseph RPayment system and methods
US20120293304 *May 18, 2012Nov 22, 2012Steve SmithIdentification authentication in a communications network
US20120295580 *Jun 1, 2011Nov 22, 2012Boku, Inc.Systems and Methods to Detect Fraudulent Payment Requests
US20130043306 *Aug 19, 2011Feb 21, 2013General Electric CompanySystems and Methods for Accessing Charging Capabilities of Electric Vehicle Charging Stations
US20130060693 *Sep 6, 2011Mar 7, 2013Rawllin International Inc.Unified charging system
US20130339229 *Jun 25, 2013Dec 19, 2013Alibaba Group Holding LtdMethod and system for payment through mobile devices
US20140089186 *Sep 25, 2012Mar 27, 2014Intuit Inc.Mobile payment service for small financial institutions
DE102012005693A1 *Mar 20, 2012Sep 26, 2013Giesecke & Devrient GmbhMethod for performing cash transaction between point-of-sale (POS) terminal and mobile terminal, used in store, involves detecting and processing transaction code to perform transaction by POS terminal
EP2641219A2Nov 18, 2011Sep 25, 2013Mastercard International IncorporatedFinancial card method, device and system utilizing bar codes to identify transaction details
WO2011112158A1Jul 16, 2010Sep 15, 2011Margento R&D D.O.O.Wireless mobile transaction system and the procedure for carrying out transactions with a mobile phone
WO2011112990A1 *Mar 11, 2011Sep 15, 2011Wal-Mart Stores, Inc.System and method for transaction payments using a mobile device
WO2012068480A2 *Nov 18, 2011May 24, 2012Garry LyonsFinancial card method, device and system utilizing bar codes to identify transaction details
WO2012082899A1 *Dec 14, 2011Jun 21, 2012Global 1 Enterprises Inc.Atm/kiosk cash acceptance
WO2013158503A1 *Apr 12, 2013Oct 24, 2013Ebay Inc.Electronic payments using visual code
WO2014051586A1 *Sep 27, 2012Apr 3, 2014Intuit Inc.Mobile payment service for small financial institutions
Classifications
U.S. Classification705/17, 455/566, 235/375, 455/414.1, 705/21
International ClassificationG06Q40/00, G06F17/00, G06Q20/00, H04W4/24
Cooperative ClassificationH04L67/34, G06Q20/202, G06Q20/3227, G06Q20/322, G06Q20/204, G06Q20/385, G06Q20/108, G06Q20/3274, G06Q20/223, G06Q20/12, G06Q20/40, G06Q20/102, H04L63/126, G06Q20/32, H04L63/08, G06Q20/425, G06Q20/105
European ClassificationG06Q20/12, G06Q20/32, G06Q20/202, G06Q20/322, G06Q20/3227, G06Q20/102, G06Q20/425, G06Q20/3274, G06Q20/105, G06Q20/108, G06Q20/40, H04L63/08, H04L63/12B, G06Q20/385, G06Q20/223, G06Q20/204
Legal Events
DateCodeEventDescription
Oct 4, 2012ASAssignment
Effective date: 20121004
Owner name: FISH & RICHARDSON P.C., MINNESOTA
Free format text: LIEN;ASSIGNOR:GLOBAL 1 ENTERPRISES, INC.;REEL/FRAME:029078/0366
Sep 19, 2010ASAssignment
Owner name: GLOBAL 1 ENTERPRISES, INC., TEXAS
Effective date: 20100919
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PHARRIS, JENNIFER;REEL/FRAME:025009/0939
Mar 26, 2009ASAssignment
Owner name: GLOBAL 1 ENTERPRISES, INC., TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PHARRIS, DENNIS J.;REEL/FRAME:022458/0031
Effective date: 20090324