Mobile payment system and method using alias

This patent application is a non-provisional application of U.S. Patent Provisional Application No. 60 / 871,898 filed on December 26, 2006, claiming the priority of the patent provisional application and hereby by reference in its entirety. Invite.

The use of mobile phones for conducting financial transactions is becoming widespread. Various means of using mobile phones to conduct financial transactions have been tried. The most common include those that use the recipient's mobile phone number as an identifier to send money to the recipient. However, this approach poses some problems. First, the recipient must have a mobile phone that can receive the payment. Second, the payer must know the recipient's phone number. Since mobile phone numbers tend to change frequently, payers must ensure that the phone number used is currently valid. Otherwise, the payer runs the risk of sending the intended recipient's old phone number to an unintended third party assigned. Furthermore, in some cases, the recipient and payer may not want to reveal personal information such as mobile phone numbers to each other. Therefore, there is a need for new ways to conduct financial transactions over the telephone.

The embodiments of the present invention address these and other issues.

<p num="0004"> Examples of the present invention relate to methods and systems for enabling payments using mobile phones.</p><p num="0005"> One embodiment of the present invention is directed to a method. The method involves receiving a payment request message from a mobile phone operated by the payer, which includes a request to pay the payee a given amount and is uniquely associated with the payee. Includes personal aliases and transaction amounts. The payment request message is analyzed to determine if the payer is allowed to pay the recipient. A payment notification message is sent to the payee to indicate that the payer has paid to the payee.</p><p num="0006"> Another embodiment of the present invention is directed to a method. The method involves receiving a payment request message from the payer, which includes the amount to be paid to the payee and the alias associated with the payee, and the mobile phone operated by the payer. Sent by the payer via. In response to the payment request message, an authentication request message is sent to the mobile phone. An authentication token is received from the payer in response to sending the authentication request message. The authentication token is sent by the payer using a mobile phone and the authentication token associated with the payer is verified. If the authentication token is verified to be associated with the payer, the alias is used to initiate payment of that amount to the payee.</p><p num="0007"> Another embodiment of the present invention is directed to a method. The method involves receiving a registration request from the recipient specifying the requested alias in order to create an alias that is uniquely associated with the recipient. The recipient can operate the mobile phone and receive or make payments using the alias and the mobile phone. The alias is compared to the other previously registered aliases associated with the other recipient. If the requested alias is not yet associated with another recipient, the alias associated with that recipient is created.</p><p num="0008"> Other embodiments of the invention relate to systems, computer-readable media and devices adapted to carry out the methods described above.</p><p num="0009"> These and other examples of the present invention will be described in detail below.</p>

<figref num="1">It is a block diagram of the system by one Example of this invention.</figref><figref num="2">It is a block diagram of a component in a computer.</figref><figref num="3">It is a block diagram of a component in a mobile phone.</figref><figref num="4">It is a flowchart explaining the process of registration of an alias.</figref><figref num="5">It is a figure which shows the information which can provide when registering an alias.</figref><figref num="6">It is a flowchart explaining the payment method by an Example of this invention.</figref>

The embodiments of the present invention are intended for making individual-to-individual (P2P) and / or individual-to-business (P2B) payments using mobile phones. In an embodiment of the invention, the payer can send a payment request message to the payment processing network. The payment request message uses an alias uniquely associated with the recipient to identify the desired recipient. The payment processing network can then determine who is the recipient using the registration and alias database and forward the payment request message to the paying institution. The paying institution may be a paying bank and the payer may have a payer account associated with that paying institution. The paying institution then analyzes the payment request message and may or may not allow the transaction, depending on whether the payer has sufficient deposits and / or funds in the payer's account. If the paying institution approves the payment request, the paying institution can subsequently transfer funds from the paying institution's payer's account to the receiving institution's payee's account.

The payment request message can be sent from the payer's mobile phone in any suitable form. In one embodiment, the payer can send a payment request message to the payment processing network via a web page accessed by telephone. In another embodiment, the payer can use an SMS message (ie, a text message) to send a payment request message to the payment processing network. In yet another embodiment, the payer can use a software application on the phone to send a payment request message to the payment processing network.

The payment transaction according to the embodiment of the present invention can be carried out in any appropriate relationship. For example, a suitable payment transaction may include the purchase of goods and services from a merchant or individual in an individual-to-business or individual-to-individual relationship. On the other hand, in certain embodiments of the present invention, the payer may make a payment without any compensation in return (eg, the goods or services purchased). For example, a payment may be a gift to a payee or a repayment of a debt to the payee who does not immediately receive compensation for the payment.

I. System

FIG. 1 shows a system that can be used in the embodiments of the present invention. Examples of the present invention may use some or all of the components shown in FIG.

The illustrated system includes payer 302 and a first mobile phone 304 associated with payer 302. The payer 302 has a payer account 316 at the payment institution 314. Similarly, the system includes a recipient 306 and a second mobile phone 308 associated with the recipient 306. Recipient 306 has a Recipient Account 320 at Receiving Institution 315.

In this example, the paying institution 314 and the receiving institution 315 are shown as separate institutions. In another embodiment of the invention, the payer 302 and the payee 306 may also use the same financial institution.

The paying institution 314 and the receiving institution 315 are generally banks that manage financial accounts for individuals or businesses. However, it may be a business entity such as a retail store.

The payer 302 and the payee 306 may be an organization such as an individual or a company that can participate in a financial transaction (eg, a payment transaction).

Payment processing network 310 may include authorization services, exception file services, and data processing subsystems, networks, and operations used to support and provide clearing and payment services. An exemplary payment processing network may include VisaNet . Payment processing networks such as VisaNet can process credit card transactions, debit card transactions and other types of financial transactions. VisaNet specifically includes a VIP system (Visa Integrated Payments system) for processing authorization requests and a Base II system for performing clearing and payment services.

The payment processing network 310 may include a payment server computer 312. A "server computer" is generally a high performance computer or cluster of computers. For example, a server computer may be a large mainframe, a minicomputer cluster, or a group of servers acting as a unit. In one embodiment, the server computer may be a database server coupled to a web server. The server computer 312 can form part of any suitable wired or wireless network, including the Internet.

The mobile gateway 332 can be operably coupled to the payment processing network 310, allowing the first mobile phone 304 and the second mobile phone 306 to communicate with the payment processing network 310. The mobile gateway 332 can be implemented with any suitable combination of hardware and / or software well known to those of skill in the art.

The system may also include a payer client computer 330 (a) as well as a payee client computer 330 (b). They can communicate with the registration server computer 326 running the host site 324 (eg, a website) via the communication medium 328. The communication medium 328 may include any suitable combination of wired and / or wireless networks, including the Internet. Registration server computer 326 can store aliases in the registration and alias database 322. The payment processing network 310 can then use the information stored in the registration and alias database 322 to identify the payee 302 and the payer 306. In other embodiments, there may be a separate registration database and a separate alias database.

FIG. 2 shows a typical component or subsystem of a computer device. Such components or any subset of such components reside within the various components shown in FIG. 1, including payment server computer 312, registration server computer 326, client computers 330 (a), 330 (b), and the like. obtain. The plurality of subsystems shown in FIG. 2 are interconnected via the system bus 775. Additional subsystems such as printer 774, keyboard 778, fixed disk 779, and monitor 776 coupled to display adapter 782 are shown. Peripherals and I / O devices coupled to the I / O control device 771 can be connected to the computer system by any number of art-well-known means, such as serial port 777. For example, serial port 777 or external interface 781 can be used to connect a computer device to a wide area communication network such as the Internet, a mouse input device, or a scanner. By interconnecting via system bus 775, central processing unit 773 can communicate with each subsystem and control the execution of instructions from system memory 772 or fixed disk 779 and the exchange of information between subsystems. .. The system memory 772 and / or the fixed disk 779 can embody a computer-readable medium.

FIG. 3 is a block diagram of some components of the first mobile phone 304. Some or all of the components of the first mobile phone 304 may also be present within the second mobile phone 308 (shown in FIG. 1).

The telephone 304 may include a computer-readable medium 304 (b) and a body 304 (h), as shown in FIG. The computer-readable medium 304 (b) may or may be removed from the body 304 (h). The body 304 (h) can take the form of a plastic substrate, housing, or other structure. The computer-readable medium 304 (b) may be a memory for storing data and may take any suitable form including a magnetic stripe, a memory chip, and the like.

Computer-readable media 304 (b) may include code for performing any of the functions described herein. A computer-readable medium 304 (b), for example, a code for sending a payment request message containing an alias associated with a recipient and an amount to be paid to a payment processing network using a mobile phone, the payment request message. It may include a code for receiving an authentication request message received via a mobile phone in response to, and a code for sending an authentication token in response to the authentication request message.

The telephone 304 may further include a non-contact element 304 (g) generally implemented in the form of a semiconductor chip (or other data storage element) having an associated wireless transfer (eg, data transmission) element such as an antenna. The non-contact element 304 (g) is associated with (eg, embedded in) the portable consumer device 304, and data or control instructions transmitted over the cellular network are non-contact element interfaces (shown). Is applied to the non-contact element 304 (g) using. The non-contact element interface functions to allow the exchange of data and / or control instructions between the circuit of the mobile device (and thus the cellular network) and the optional non-contact element 304 (g).

The non-contact element 304 (g) generally follows a standard protocol or data transmission mechanism (eg, ISO14443 / NFC) and uses NFC (near field communications) capabilities (or NFC media) to transmit data. And can receive. NFC functions can be used to exchange data between RFID, Bluetooth®, infrared, or telephone 304 and payment processing network 26, or data between telephone 304 and an access device (eg, POS terminal). It is a short-range communication function such as other data transmission functions that can be used to exchange. Thus, the telephone 304 can transmit and transfer data and / or control instructions via both the cellular network and NFC function.

The telephone 304 is a processor 304 (c) (eg, a microprocessor) for processing the functions of the telephone 304 and a display 304 (d) for allowing the recipient to see the telephone number and other information and messages. ) Can also be included. The telephone 304 also includes an input element 304 (e) that allows the recipient to enter information into the device, a speaker 304 (f) that allows the recipient to listen to voice communications, music, etc. It may include a microphone 304 (i) to allow the recipient to transmit its voice over the telephone 304. The telephone 304 may also include an antenna 304 (a) for wireless data transfer (eg, data transmission).

II. How to register

In an embodiment of the invention, the payer and payee can first register with the system. Recipients and payers can register in any suitable manner. For example, referring to FIG. 1, payees and payers can use client computers 330 (a), 330 (b) to register with the system via host site 324. Registration information such as name and account number can be stored by the server computer 326 in the registration and alias database 322. This information can be used in the next payment process to identify payer 302 or payee 306.

In some cases, financial institutions such as Receiving Institution 315 or Paying Institution 314 may "push" pre-registration data to the registration and alias database 322. The paying institution 314 can, for example, authenticate the payer 302 in advance. The paying institution 314 knows the payer 302 and the payer's credit history and account balance information, so it can do this in advance. After the payer 302 is registered in the system, the payer 302 can set up an appropriate alias to use the system. The same is true for recipient 306. Therefore, in some embodiments, the payer 302 does not need to do anything to register, just set its own payment alias.

In the examples of the present invention, several aliases can be used. Aliases are payment processing organization aliases for payment processing organizations that operate payment processing networks, payee aliases associated with payees and payee phones, and payer aliases associated with payers and payer phones. May include. Examples of payer and payee aliases include "world traveler" and "beachbum". "Myvisa", a payment processing organization such as Visa, can be an example of a service alias.

Other aliases that can be registered include mobile consumer device aliases (payment card aliases). For example, payer 302 may have first and second credit cards and aliases CC1 and CC2. An alias for such a portable consumer device may or may not be uniquely associated with its owner.

Referring to FIGS. 1 and 4, in the first step 202, the recipient 306 requests the assignment of an alias. In a preferred embodiment, the recipient 306 can specify a particular alias. However, in other embodiments, the payment processing organization can assign an alias to recipient 306. To register the alias, recipient 306 can use client computer 330 (b) to contact host site 324 on server computer 326. Host site 324 may include wizards and other mechanisms to allow payer 302 and recipient 306 to enter information.

In the next step 204, the server computer 326 examines the registration and alias database 322 to see if the requested alias has already been used by another payee or payer. If the requested alias already exists, recipient 306 may be asked to provide another alias (step 212). Alternatively or additionally, if the proposed alias is offensive or is a third party trademark or service mark, the alias registration request may reject the proposed alias.

If that alias has not been previously registered, then server computer 326 may register the requested alias for the recipient208. This information can be stored in the registration and alias database 322. After an alias has been created for recipient 306, the payment processing organization can undertake to allow recipients to receive payments made using that alias (step 210).

This method and other related embodiments of the present invention enable efficient inter-institutional payments by uniquely identifying individuals, businesses, etc. through aliases. Aliases can optionally be associated with a number of accounts or services operated by individuals or groups. In some embodiments, these various aliases can be registered for a fee, and consumers may be charged a registration and renewal fee to use a particular alias. In other embodiments, the registration and alias database can be provided as a free service, or billed only to a particular class of organization (eg, billed only to the beneficiary or commercial legal entity).

III. Payment method

FIG. 6 is a flowchart illustrating a payment method according to an embodiment of the present invention. In step 102, payer 302 decides to pay recipient 306 using first mobile phone 304.

The payer 302 then uses the first mobile phone 304 to send a payment request message to the payment processing network 310, which receives the payment request message (step 104). The payment request message contains at least the payment amount and the recipient's alias. The payment request message may also include other information, such as an alias or number identifying the particular financial account from which the payment is to be made, or a future time when the payment will begin.

As mentioned above, payment request messages can take many different forms. For example, a payment request message can take the form of an SMS message. The request may also arrive in the form of an email or a voice dialogue using an IVR (Interactive Voice Response Recorder). The request could also be made via a software application on the phone that sends one or more network packets containing the request data.

In the next step 106, the registration and alias database 322 is used by the server computer 312 in the payment processing network 310 to analyze the payment request message and the payee alias in the payment request message is used to pay the recipient 306. , And the payer 314 and payer account 316.

To provide security to the system, an optional authentication request message is sent from the payment processing network to the first mobile phone 304 operated by the payer 108. The authentication request message can be initiated by a payment institution 314 or a payment processing organization that subscribes to the payment processing network 310. It may also require you to enter personal information such as a password or address or social security number to verify the payer's identity108. The authentication request message can take various forms as described above for the payment request message 104. In a preferred embodiment, the authentication request message will be sent to the payer's mobile phone 304. The authentication request message can also be sent to the payer's client computer 330 (a).

In the next step 110, the payer 302 provides the payment processing network 310 with an authentication token. For example, the payer 302 can enter a PIN (personal identification number) into the first mobile phone 304 and then send the authentication token back to the payment processing network 310, which the payment processing network 310 does. It may or may not be transferred to the payment institution 314. Other examples of authentication tokens include passwords, dates of birth, and other personal information related to payer 302.

Payment processing network 310 (or payment institution 314) then validates authentication token 112. If the authentication token is invalid, the payment request in the payment request message may be rejected. Alternatively, the payment processing network 310 can revalidate the authentication token by sending another authentication request message to the payer 302 via the first mobile phone 304 (step 120).

If the payer 302 and / or the first mobile phone 304 is authenticated, the payment processing network 310 may send a payment request message to the payment institution 314 for approval. The payment request message can be reformed to remove various aliases and contain the correct information, if desired. The paying institution 314 may then approve the payment request if the payer account 316 has sufficient funds and / or deposits, or disapprove the payment request if there are insufficient funds or deposits. If the payment request is approved, at some point (for example, immediately or at the end of the day if there is a need for liquidation or settlement), the actual funds will be paid from the payer account 316 to the payee account 320. It can be transferred via network 310.

Once the funds have been transferred from the payer account 316 to the payee account 320, the mobile phone 308 and / or the client computer 330 operated by the payer 118 after the payment request in the payment request message has been approved by the payment institution 314 ( You can send a payment notification message to b).

In a specific embodiment, payer 302 (eg Jane) and payee 306 (eg John) use their client computers 330 (a), 330 (b) on a remote server computer 326. Register at the operating host site 324.

As shown in Figure 5, Jane registers personal information 502, including her name, mobile phone number, first credit card membership number, second credit card membership number, and personal alias. John can also register the personal information 504. In this example, Jane creates the personal alias "worldtraveler" and John creates the personal alias "beachbum".

After registration, the payment processing organization may provide both John and Jane with a telephone number for services that facilitate subsequent payment processing. In other embodiments, the payment processing organization may also provide John and Jane with a service alias in place of or in addition to the service phone number. For example, instead of providing the service phone numbers 555-555-5555 to John and Jane, the payment processing organization can provide the service alias "myvisa" to John and Jane. Service aliases, sometimes referred to as "shortcodes," can contain variable-length strings.

In an exemplary transaction, Jane is payer 302 and may want to pay $ 15.00 to payee 306 named John. Payer Jane 302 enters a payment request message "myvisa pay beachbum $ 15.00" (myvisa pays beachbum $ 15) to her phone 304 and sends the message to a server in the payment processing network 310 via mobile gateway 332. -Start paying John by sending to computer 312 via SMS. The alias "beachbum" is used in place of John's phone number. The service alias "myvisa" is used instead of the service's phone number.

Jane can use an alias for a handheld consumer device, such as "CC2," to indicate the particular credit card Jane wants to use to pay John. For example, payer Jane 302 enters a payment request message "myvisa pay beachbum $ 15.00 CC2" on her phone 304 (myvisa pays beachbum $ 15 in CC2) to make the second payment to make the desired payment. You can instruct your credit card to be used. Alternatively or additionally, Jane may specify a default credit card membership number.

After entering the payment request message "my visa pay beachbum $ 15.00 CC2" on the mobile phone 304, the payment request message is sent from the mobile phone 304 to the payment processing network 310 (eg, as described above) and then (in this example). ) Sent to the issuer of the credit card (or other portable consumer device). In this example, the issuer of the credit card may be payment institution 314.

After receiving the payment request message, the payment processing network 310 can optionally respond by sending an authentication request message to the payer 302. In this example, the authentication request message is sent in the form of a call from an IVR, such as on a telecommunications company's server, asking payer Jane 302 to enter her mobile PIN (personal identification number) 510. After the payer Jane 302 enters the correct PIN into her phone 304, the payment institution 314 and / or the server computer 312 in the payment processing network 310 analyzes the payment request message and approves or rejects the payment request. be able to. If the payment request is approved, the appropriate funds can be transferred to the beneficiary account 320 at the receiving institution 315. For example, an account on John's portable consumer device (eg, a credit card account) at the recipient John's bank (eg, receiving institution 315) can receive a deposit of the payment amount. The payment amount can then be deducted from the payer Jane's account 316.

In some embodiments, a payment notification message is sent to the recipient's mobile phone 308 in the form of an SMS, email or other type of message, indicating that the payment has been made by the payer Jane 302. I can inform John 306. In a preferred embodiment, the payment notification message is sent to recipient John's mobile phone 308, but can also be sent to client computer 330 (b) operated by recipient John 306.

The embodiments of the present invention have several advantages. First, the use of aliases allows the transaction to be completed while keeping the personal information of the parties doing the transaction confidential. This is very useful, for example, because the payer may not want to reveal the phone number to the recipient and vice versa. Second, aliases allow payments to be made even if the recipient's phone number or financial account changes. Therefore, the payer should keep a list of aliases for the payees with whom the payer frequently trades and initiate repetitive payments without having to verify that the payees have the same phone number. Can be done. Third, aliases tend to be easier to remember than phone numbers or financial account numbers. As a result, the examples of the present invention will be easier to use than other methods. Fourth, embodiments of the present invention allow a large number of accounts to be accessed from a single mobile phone, eliminating the need to carry a large number of portable consumer devices.

Both of the above methods or steps of such methods use, for example, conventional or object-oriented techniques, such as Java®, C.⁺⁺Alternatively, it can be implemented as software code executed by the processor of a server computer using a suitable computer language such as Perl, or the proper combination of other devices. This software code runs on a series of computer-readable media such as RAM (read-write storage), ROM (read-only storage), magnetic media such as hard drives or floppy disks, or optical media such as CD-ROMs. It can be stored as a command or command.

It should be understood that the present invention can be implemented in the form of control logic, in a modulator or integrated form, using software, hardware, or a combination of both. Other methods and / or means for carrying out the present invention will be understood by those skilled in the art based on the disclosures and teachings described herein.

The aforementioned examples and / or any feature thereof may be combined with any other (one or more) examples and / or (one or more) features without departing from the scope of the invention. it can.

The above content is exemplary and not limiting. Examination of the present disclosure will reveal to those skilled in the art a number of variants of the invention. Therefore, the scope of the present invention should not be determined with respect to the aforementioned content, but instead with respect to the pending claims and all or equivalent.

The description of "one" or "that" "this" is intended to mean "one or more" unless otherwise stated.