Software Technology for “Mobile payment station system”

Communications – Marwan Monir Afana, MOBILE EQUITY CORP

Abstract for “Mobile payment station system”

A mobile device can be used to initiate and complete a transaction between a customer (or merchant) and the customer. A mobile device can be used to initiate a point-of-sale transaction. In this case, a merchant ID will be sent to a payment processing service. The payment processing server responds to a mobile device’s communication and requests transaction information. This allows the merchant to be identified using the merchant ID. The merchant can give transaction information to the payment processing service, such as the total amount of the sale. The merchant can authenticate the customer to initiate a purchase transaction with the merchant and appropriate financial institutions. The merchant and the mobile device can be sent a confirmation by the payment processing server of an executed transaction.”

Background for “Mobile payment station system”

It is now common to use a credit card or debit card, a payroll card, ATM card, ATM card, or any other stored value card (hereafter credit cards) to purchase one or more items at a merchant. A merchant can, for example, enter the total amount of the sale in a terminal to initiate a point-of-sale. To process the sale, the merchant can request a customer’s credit card. The customer’s credit card information will be entered into a point-of-sale terminal. This information is then sent to clearinghouse servers. The clearinghouse can verify the credit information and route transactions based on routing numbers associated to the credit card. A clearinghouse can authorize a financial institution to execute a transaction and send a confirmation of the transaction to the merchant’s terminal. To receive customer approval, the merchant can print a copy of the transaction confirmation.

This method is fast and reliable, which is why it’s so popular. The customer can also make a purchase anytime, regardless of whether they have cash available to buy a product. To be able to execute such transactions, the customer must have a credit or debit card. If the customer has a debit account, he/she can use the card’s convenience to make transactions using a debit card. Many customers don’t have bank accounts and do not have debit cards. Customers under 18 may not be eligible for credit cards. However, they may still need to have a safe way to purchase goods.

A customer who uses a credit card is also at risk of fraudulent transactions or credit card fraud. If a customer’s card is stolen or lost, any other person can use the card to make a transaction by simply showing the card to the merchant. The clearing house and financial institutions will not be able to catch fraudulent transactions if the card owner has not reported it.

A customer might not be able use credit processing systems to make a purchase if they don’t have their card at the merchant site. A customer cannot use another person’s credit card to make a purchase. Credit cards and cards linked to financial institutions offer a less-than-optimal method of executing transactions associated with a customer?s financial or credit account.

A customer might not be able use credit processing systems to make a purchase if their card has a defective magnetic strips, chips or electronic near field communication (NFC). A customer might not be able to use credit processing systems for executing a purchase if their point of sale terminal is defective or contains a defective NFC receiver. This prevents the NFC receiver from reading card information.

“It is a general purpose of the present invention that a customer can use a mobile communication device to initiate and complete a transaction by reversing conventional point-of-sale transaction initiation. That is, the processing server opens communications toward point of sales terminal using merchant ID or point-of sale terminal ID instead of the traditional method of point terminal opening communications towards processing servers.”

“It is the general object of this invention to enable a customer to use mobile communications device to initiate or execute a transaction. This overcomes the problems associated with using a debit or credit card. It also takes advantage of the availability of mobile communications devices and their communications capabilities.

“It is also a general purpose of the present invention that a customer can use other methods, such as calling an interactive voice reply (IVR) system and using voice (or dual-tone multifrequency (DTMF), commands on a landline to initiate or execute a transaction. This overcomes the aforementioned issues with using a debit or credit card and takes advantage of the abundance of telecommunications methods available today.

A mobile device can be used for initiating and executing a transaction with merchants. A mobile device can be used to initiate a point-of-sale transaction. This involves a merchant ID, or, for instance, a point terminal ID (hereafter referred to as?merchantID?). The information is sent to a payment processor server. The payment processing server responds to a mobile device communication and requests transaction information from merchants. This allows merchants to be identified using the provided merchant ID. The merchant can give transaction information to the payment processing service, such as the total amount of the sale. The merchant can authenticate the customer to initiate a purchase transaction with the merchant and appropriate financial institutions. The merchant and the mobile device can be sent a confirmation by the payment processing server of an executed transaction.”

“It is another object of the present invention that a point-of-sale terminal associated with a retailer can be used to execute a transaction between a customer and a merchant. Point of sale information can be provided by merchants, including purchase amount, merchant ID, and account number. An account phone number may include the customer’s financial institution account number, the phone number associated with the customer’s financial account number, and the phone number used to access the account in a financial establishment, hereafter called the?account number.? A payment processing server responds to merchant point-of-sale information and identifies the account associated with the account number. It then sends authorization requests to the account number. The customer can use a communication device to enter authorization personal information and send it off to the payment processing servers. The payment processing server can authenticate and initiate a purchase transaction between the customer’s financial institution and the merchant. The merchant and the mobile device can be sent a confirmation by the payment processing server of an executed transaction.”

“It is another object of the present invention that a payroll account can be used with an account number to execute a transaction between merchant and customer. A merchant can initiate the point-of-sale transaction using the point of sales terminal, or a customer can use a communication device or IVR call to initiate the transaction. The service data point (SDP), receives the merchant ID and account phone number. The authorization request is sent to the account number by the payment processing server. The authorization personal identification number can be entered by the customer on a mobile device that is associated with the account number. This number will then be sent to the SDP. The SDP can authenticate customers associated with their payroll accounts and initiate purchase transactions between the merchants and the associated payroll account. SDPs can confirm the transaction to the merchant or the mobile device. An SDP’s functionality can be integrated into the mobile enablement centre 106. It can be called SDP, Mobile enablement center or vice versa. The functionality of the mobile enablement function center can also be integrated into an SDP. This is called either the mobile enablement centre or the SDP. An example of this is the implementation that can be done in an SDP.

“The specification does not contain all the features and benefits. A person of ordinary skill in art will see many more features and advantages in the specification, drawings, and claims. It is important to note that the language in the specification was selected primarily for its readability and instructional purpose and may not be used to define or circumscribe the inventive subject matter.

“The preferred embodiment of this invention is described using reference to the figures, where like reference numbers indicate identical elements or functionally comparable elements. The figure’s leftmost digit corresponds to the first time the reference number was used.

“Refer in the specification to?one? embodiment? Or to?an embodiment? It means that at least one embodiment contains a particular feature, structure or characteristic. It is possible to see the phrase “in one embodiment?” or ?an embodiment? “The specification does not always refer to the same embodiment in different places.”

“Some parts of the following description are described in terms of symbolic representations and algorithms of operations on data bits within computer memory. These representations and algorithmic descriptions are used by data processing artists to communicate the essence of their work to others. An algorithm can be described as a sequence of steps that leads to the desired result. These steps require physical manipulations of certain quantities. These quantities are usually stored in the form of electromagnetic, radio, or electrical signals that can be combined, stored, transferred, compared, and manipulated in any other way. These signals can be referred to as bits, values or elements, symbols, terms, numbers, terms or characters. This is primarily for common usage. It is also possible to refer to certain steps that require physical manipulations, transformations, or representations physical quantities in code devices or modules, without losing their generality.

“All of these terms and similar terms must be associated with the relevant physical quantities. They are not merely labels that are applied to these quantities. It is not clear from the discussion that discussions using terms like?processing? will be included in the description. Or?computing? Or?calculating? Or?determining? Or?displaying? Or?determining? The action and processes of a computer or similar electronic computing device (such a specific computer machine) that manipulates or transforms data stored in computer system memories, registers, or other information storage, transmission, display, and transmission devices.

Certain aspects of the invention include instructions and process steps described in an algorithm. The process steps and instructions described in the present invention can be embedded in software, firmware, or hardware. When embedded in software, they could be downloaded to be used on a variety operating systems. It is also possible to include the invention in a computer program product that can be executed on a computer system.

“The invention also includes an apparatus for performing these operations. The apparatus can be a particular computer or a general purpose computer that is activated or reconfigured using a computer program. This computer program can be stored on a non-transitory computer-readable storage medium. It could include, but not limit to, floppy disks and optical disks. Memory can include any of the above and/or other devices that can store information/data/programs. The specification can also refer to computers that have a single processor, or architectures with multiple processor designs to increase computing power.

“The algorithms and displays described herein do not necessarily relate to any particular apparatus or computer. You can use the programs with other general-purpose systems, or you may need to build more specific apparatus to accomplish the method steps. Below is a description of the structure that can be used to create a variety system. The present invention does not refer to any particular programming language. You will appreciate that the present invention can be implemented using a variety programming languages. Any references below specific languages are made for disclosure of enablement or best mode of implementation.

“In addition, the language in the specification was selected principally for readability and instruction purposes and may not have been chosen to define or circumscribe the inventive subject material. The disclosure of the present invention is meant to illustrate, but not limit, the invention’s scope, as set forth in the claims.

“FIG. “FIG. A computing environment could include a mobile device (102), a mobile enablement centre 106, a register payment processing servers 110, a merchant (104), and a financial institution (116).

“FIG. 2. This flowchart illustrates one method for using a mobile device in order to initiate a transaction. FIGS. FIGS. 1 and 2 will be discussed simultaneously.

“In one embodiment, the point of sale transaction is initiated by the mobile device 102. Any computing device that can communicate over a network or communications link with another mobile device 102 is considered a mobile device 102. A mobile device 102 could be a cell phone, personal device assistant, smart phone, laptop computer, desktop or any other device. The mobile device transmits a merchant ID to the payment processing server. A merchant ID number is a unique identifier that is associated with a merchant. Any information that can be used to identify the merchant or communicate with it is possible. A merchant ID could include a point of sale terminal ID that can be used by merchants to execute transactions. Other embodiments of the merchant ID include an email address or a telephone number.

“In one embodiment, the customer can enter a merchant ID onto the mobile device102 by using the input system of the device, such as a keyboard, touchpad, etc. Other embodiments allow the customer to view the merchant ID information via the camera on their mobile device 102. Other embodiments allow the customer to see the merchant ID information in plain sight. Other embodiments allow the merchant ID information to be displayed in plain view for customers. Other embodiments allow the mobile device to receive the merchant ID information via a communication link, such as BLUETOOTH communications and RFID communications fields. A merchant may have a point of sale terminal that broadcasts the merchant’s ID to mobile devices using a BLUETOOTH or laser, radio, infrared, close range electromagnetic field communications link, and/or radio. One embodiment sends the merchant ID received by the mobile device 102 to another party via a communications network.

The mobile device 102 can send the merchant ID to mobile enablement center (106) using any communication method. It can use unstructured service data (USSD), SMS, multi-media message (MMS), IVR and email to send the merchant ID to the mobile enablement center 106. This communication, or any other example of communication, is referred to as COMM.

The mobile device 102 is able to use any communication method (COMM), to send the merchant identification to the mobile enablement centre 106. One embodiment of the invention allows the mobile device 102 to send the merchant ID via SMS over a mobile communication network such as GSM, iDEN, CDMA networks, in any configuration that can be 2G, 3G and 4G. The mobile device can also send multi-media messages (MMS) in other cases. The customer can also take a picture of the barcode or number identifier associated to the merchant ID, and then send it over a communications network. Another example is that an application running on the mobile device102 can read or recognize the barcode and number identifier associated to the merchant ID in order to send it over a communication network. Other embodiments depend on the capabilities of the mobile device. The mobile device can connect via WiFi to send the merchant ID via email over the network to the payment processing server (106). One embodiment allows the customer to enter the merchant ID using an IVR via a landline phone. Other embodiments allow the customer to use an interface that is part of the application running on the mobile device, 102 to send the merchant identification to the mobile enablement centre 106 via a communications network. Below is a description of the network that connects the mobile device 102, merchant 104 and mobile enablement centre 106. The payment processing server 110, service data point 112 as well as the financial institution are also described.

“In one embodiment, the merchant identification is sent to a payment processing server 110. A customer may choose to set a preference that all transactions made with the mobile device102 will be associated with a specific financial institution and routed through a certain payment processing server 110. An embodiment uses IPV6 protocols to route communications requests to the appropriate payment processing servers 110. Another embodiment is that the mobile device 102 transmits the merchant ID over a communications network to a mobile enablement centre 106. This will then route the request to the appropriate payment processing server 110.

“The mobile enablement centre 106 is a platform which routes outgoing messages from mobile devices 102 to appropriate payment processing servers 110. The mobile enablement centre 106 can receive routing request from multiple service broadcast operators such as mobile phone network operator GSM/CDMA network operators, landline operators, LAN operators, and others. Mobile devices 102, including landline and VOIP phones, can send outgoing messages to the service broadcast operator. The number or device associated with the request receives the message. The outgoing message is routed to the broadcast operator that corresponds with the intended recipient by the service broadcast operator. The invention’s mobile enablement center (106) receives routing requests from the service broadcast operator for the mobile device. One embodiment of the invention states that the mobile enablement centre 106 routes the message from the mobile device 102 to the appropriate payment processing server106. This is based on the outgoing text’s phone number and the intended recipient’s number. It also includes the merchant ID in the message. If a user’s number is associated to a financial institution 116 then the mobile enablement centre 106 routes the message directly to the payment processing server 110.

“In one embodiment, the payment processor server 110 queries a registry of payments processing servers 108 in order to identify an appropriate payment server 110. A registry of payment processor servers 108 may include a list of payment processing server 110 that is based on routing numbers, other identification information, or coordinated new routing mechanisms that could be mandated, devised, or supervised, for example, by a standardization body or governmental body, consortium body of companies, or leaders in this field.

“A payment processing server 110” is a platform that executes transactions between a customer, financial institution 116 and a merchant. 104 A payment processing server 110 could be any database maintained by American Express, Visa, MasterCard, American Express, or other financial institutions. One embodiment of the payment processing server 110 receives from the mobile device 101 202 the merchant identification. Another embodiment is that the payment processing server 110 receives the merchant ID from the mobile device 102 in a message sent by the mobile enablement centre 106.

“In one embodiment, the payment processor 110 sends 204 an inquiry for transaction information to merchant 104 that is associated with the received merchant identification. The merchant can communicate with any communications method (COMM), as is known to the art. The payment processing center may send an SMS, an e mail message, etc. to a merchant’s phone number or email address 104. One embodiment allows the merchant ID to be linked with a unique point-of sale terminal. In this case, the payment processing server 110 could send a message to the specific point-of-sale device.

“The merchant 104 may provide transaction information to the payment processing server 110. Transaction information may include the customer’s total purchase price, the merchant account number, and the customer’s mobile phone number. To provide transaction information to the payment processing servers 110, the merchant 104 may use any communication method (COMM), which is known to art. One embodiment allows the merchant to enter the total amount of the purchase on the keypad of a point-of sale terminal. Point of sale terminals can have a station that allows the merchant to swipe or enter a customer’s debit or credit card in order to complete a purchase transaction. Another embodiment of the point-of-sale terminal may include a computing device such as a machine or desktop computer, tablet, laptop, or mobile phone. Other embodiments allow point-of-sale terminals to include existing transaction terminals such as an ATM, vending machine, etc. If existing terminals, such as ATMs or card-swipe machines are being used, they can be updated with a firmware update in order to receive transaction information requests via a payment processing server 110.

“The merchant 104 sends the payment processing server 110 206 transaction data. One embodiment of transaction information includes the phone number associated to the customer’s mobile device 102. The payment processing server 110 authenticates 102’s phone number. One embodiment of this method is that the payment processing server 110 authenticates the incoming call’s phone number against a service broadcast operator network. If a mobile number is associated to the T-MOBILE network, the payment processing servers 110 can query the TMOBILE operator network 311, in order to identify an account associated with that mobile number.

“In an alternative embodiment, the payment processing service 110 queries a register 414. This is described in more detail below. The query is answered by the payment processing server 110, which receives account information associated to the phone number of the device 102 and the identity of mobile enablement centre 106. In one embodiment, the payment processor 110 queries the mobile enabledment center 106. The mobile enablement server 106 responds to the query by querying a register of payment processor 108 to retrieve account information for the mobile device’s number 102. After receiving the correct account information, the payment processor 110 contacts the mobile enablement centre 106 to retrieve the account information associated with the 102 number of the mobile device and sends a request for authorization to the mobile device. One embodiment of the payment processing server 110 transmits a transaction authorization (102) to the merchant. The payment processing server 110 initiates an account number-related transaction when it receives a positive transaction authorization from the mobile device 102 and the merchant 104.

“As mentioned above, the payment processing service 110 can identify an account that is associated with the mobile number 102. Multiple accounts may be associated with the same mobile number in one case. In this case, the payment processing service 110 queries a mobile enabledment center 106. The mobile enablement centre 106 can identify an account that is associated with multiple accounts, such as virtual accounts and real accounts that are associated with the mobile number. The mobile enablement centre 106 can use additional logic to identify the account from the list of accounts that are associated with the mobile number. A user may specify that a debit card should only be used for purchases below a specific dollar amount. For example, $5 could be an example. Another embodiment allows the customer to associate certain accounts with transactions executed with a specific merchant. If the merchant ID is associated to a retail merchant, then the payment processing server 110 will be able to identify a debit card.

“In one embodiment, the payment processor 110 authenticates merchant upon receiving transaction information from merchant. The merchant can be authenticated, for example, if the merchant confirms either the merchant ID or customer’s mobile number that initiated the transaction. Once the authentication process has been completed, the payment processing server 110 will identify the merchant’s account.

“In one embodiment, the payment processor 110 sends 208 a authorization request to the mobile phone 102 that initiated the transaction request. The payment processing server 110 can send a COMM (an SMS message or an email) to the customer’s phone number or to the email address that initiated the transaction. One embodiment of the payment processing server 110 sends 208 the account number and name to the mobile device. Another embodiment allows the customer to provide both a phone number and a different communication phone number. The customer can initiate a transaction by providing an account number and initiating communication from another number. To initiate the transaction, the customer can either use COMM messaging or an application running on the communications mobile device. In such an example, the payment processing server 110 sends to 208 an authorization request at the communications number. The customer can then provide authorization associated with the account number. This could be used to allow a customer to borrow another’s mobile phone to complete his or her transaction.

“In one embodiment, the payment processing service 110 receives 210 authorization from a mobile device. An authorization message may include a customer’s personal identification number (PIN). Customers can create multiple PINs to be used for different accounts. A customer may set up a PIN to limit purchases below a certain dollar amount, and another PIN to limit purchases above a dollar amount. The customer can also set up a different PIN for specific merchants. A different PIN can be created by the customer in another embodiment. This is a unique PIN that expires after the first use. It applies when the communication phone number used to initiate the transaction is different than the one associated with the customer. One embodiment allows the mobile device 102 to erase all PINs from its on-board and off-board memory. The payment processing server 110 receives 210 an authorization PIN from the customer via a communications network. A customer can also use a one-time password (one-time use PIN that expires after the first use) using a different communications number than their account number. A customer may, for example, set a one-time password that expires after the first use. This can be used for purchases exceeding a certain amount or purchases made with a specific merchant.

“In one embodiment, a payment processing server 110 executes 221 transactions with a financial institution. The payment processing server 110, for example, identifies the financial institution associated to the customer’s bank account and the financial institution associated to the merchant’s bank account. In this case, the execution of the transaction consists of debiting the customer account of the purchase amount and crediting it to the merchant account. Additional fees can be added by financial institutions 116 or payment processing servers 110, mobile capability centers 106 to the purchase amount.

“In one embodiment, the payment processing servers 110 send 214 a transaction verification to the mobile device (102) and the merchant (104). Any communication method (COMM), including an SMS message, email address, or phone call, can be used. Refer to FIG. To send 214 confirmations, you can use the number 3. One embodiment sends the confirmation to the point-of-sale terminal associated the merchant ID. The point-of-sale terminal may print a copy for the merchant or customer. If the communication phone number of the customer is different from the one associated with the transaction account’s transaction account, the payment processing servers 110 will send 214 a transaction verification to either one or both numbers. You can include information about the transaction, such as the date and time, total transaction amount, and details about whether it was successful. If the merchant has chosen COMM as the preferred delivery method for confirmations, the payment processing server 110 will send 214 the transaction verification via COMM to the merchant.

“FIG. “FIG. 1. According to one embodiment. The computing machine 300 could also be considered a part or system of another system, such as two or more computers operating together, or one or several machines operating with one or both of the other devices.

“FIG. “FIG. Specifically, FIG. FIG. 3 is a diagrammatic representation showing a machine in which mobile payment device instructions 324, e.g. software code, can be executed to execute any or all of the methods discussed herein. Alternative embodiments allow the machine to operate as a standalone device, or connected (e.g. networked) with other machines. The machine can be used in a networked environment as a server machine, client machine, or peer machine in a peer to peer (or distributed) network environment.

“The machine can be a server, client, or a computer that is capable of executing instructions 324 that are sequential or not. Although only one machine is shown, the term “machine” can also be used. It shall be understood that any machine or collection of machines that execute instructions 324 individually or collectively to perform any or all of the methods discussed herein is a machine.

The example computer machine 300 contains a processor 302, which can be a central processing unit, group of processors or a group processing machines, one or more application-specific integrated circuits or (ASICs), one of more radio frequency integrated circuits or (RFICs), one of more radio-frequency circuits or (RFICs), one of more radio-frequency circuits or (any combination thereof), and a memory 304. It also includes a network interface device (320) capable of interfacing with a projector tube (LCD), a plasma display (PDP), a LCD), a display panel (LCD), an LCD), a display (LCD), and ray tube (CRT), and a projector or ray tube (CRT), and ray tube (CRT), and ray tube (CRT), and a) and a bus).

“The storage unit 312 includes a machine-readable media 322 on which are stored mobile payment device instruction 324 (e.g. software) that embody any of the methods or functions described herein. The mobile payment instructions (e.g. software) can also be stored in the main memory 302 or the processor 302 during execution by the computer system 300. Both the main memory 302 and the processor 302.

“The external storage 317 contains a machine-readable medium that can store merchant or mobile device information. The machine 300 can, in one embodiment, access the external storage 317 via communications links. All components of the machine 300 are able to access the storage medium 317 in an embodiment.

In an example embodiment, machine-readable medium 322 has been shown to be one medium. However, the term “machine-readable media” is used. It should be understood that a single medium can also include multiple media (e.g. a distributed or centralized database or associated caches or servers) capable of storing instructions (e.g. mobile payment device instructions 324). “Machine-readable medium” is also used. Any medium capable of storing instructions (e.g. mobile payment device instructions 324) that can be executed by the machine, and that causes the machine to perform any of the methods disclosed herein, shall also be considered a machine-readable medium. “Machine-readable medium” is a term that refers to any media that can store instructions (e.g., mobile payment device instructions 324) for execution by the machine and that cause the machine to perform any one or more of these methodologies. This includes but is not limited to data repositories that are made up of solid-state memories, optical and magnetic media.

“The mobile payment device instructions 324, e.g. software, may be transmitted over the network310 via the network interface device 322. One embodiment of the network 310 is an Internet. The network 310 may also use dedicated or private communication links that aren’t necessarily part of the Internet. The network 114 can use standard communication technologies and/or protocols in one embodiment. The network 114 may include links that use technologies such as Ethernet and Wi-Fi (802.11), integrated digital network (ISDN), digital subscriber (DSL), asynchronous transport mode (ATM), and others. The network 114’s networking protocols can also include multiprotocol label shifting (MPLS), transmission control protocol/Internet protocol TCP/IP, hypertext transport protocol HTTP, simple mail transfer protocol SMTP, file transfer protocol FTP, and others. One embodiment uses mobile networking technologies for at least some links, such as general packet radio service, enhanced data GSM environment, (EDGE), code Division Multiple Access 2000 (CDMA2000) and/or wide band CDMA (WCDMA). Data exchanged over network 114 may be represented using various technologies and formats, including hypertext markup languages (HTML), extensible markup languages (XML), wireless access protocol (WAP), short message service (SMS), etc. All or part of the links can also be encrypted with conventional encryption technologies like Secure HTTP, Secure Sockets Layer (SSL), and/or Virtual Private Networks (VPNs). Another embodiment allows entities to use customized and/or specific data communication technologies in place of or in addition the ones mentioned above.

The example computer machine 300 contains a mobile network enabled unit 325. This includes the logic software (SLEE?) and hardware to connect to any node of a mobile network operator, including any messaging node such as a short message center (SMSC), a multi-media message center (MMSC), and mail transport/transfer agent(MTA), wireless access protocol [WAP], gateway GPRS (general packet wireless service) support node GGSN), combined GPRS center (CGSN), and any other, infrared, radio (short wave or another), and other), and other), and other), and other, infrared, infrared, Bluetooth, WiFi, WiMax, Bluetooth, WiFi, WiMax Mobile network enablement unit 325 supports all communication protocols and standards including but not limited to instant messaging service (IMS), signaling system 7 (SS7), internet protocol (IP), transport/transmission control protocol (TCP), transaction capabilities application part (TCAP), intelligent network application protocol (INAP), mobile application part/multiple access protocol (MAP), CS1, CS2, CS3, CS4, common alerting protocol version 1 (CAP v1), CAPv2, CAPv3, CAPv4, all wireless intelligent network (WIN) standards, all intelligent network (IN) standards and all advanced intelligent network (AIN) standards, etc. One embodiment of the mobile network enablement device 325 connects to a mobile operator network 311. The mobile operator network 311 can include CDMA, WCDMA and iDEN. It also includes GSM, CDMA, WCDMA and future revisions of wireless communications system.

Referring to FIG. “Referring now to FIG. 4, it illustrates the high-level block diagram for a computing environment that allows a mobile device to initiate transactions according to one embodiment. A computing environment could include a mobile device (102), a mobile enablement centre 106, an register of payment processor servers 108, 110, and merchant 104.

“FIG. “FIG. FIGS. FIGS. 4 and 5 will be discussed below concurrently.

“As explained in more detail above, the mobile device102 initiates a transaction by sending a merchant identification to the mobile enablement centre 106 or the payment processor server 110. The payment processing server 110 receives 502 a merchant ID and then sends 504 an information request to the merchant that is associated with the merchant ID. Any communication method (COMM), as described above, can be used to communicate directly with merchant 104. The payment processing center may send an SMS, an e mail message, etc. to a merchant’s phone number or email address 104. One embodiment allows the merchant ID to be linked with a unique point-of sale terminal. The payment processing server 110 could send a communication to that point-of-sale terminal in such an instance. To communicate with the point-of-sale terminal, the payment processing server 110 may also use the well-known ISO8583 interface.

“Service data point (also known as SDP) refers to a computing machine that has, for example, all components described in 300. It is used by telecommunication operators to store subscriber account balances, service subscriptions, service expirations, and other information. Although SDPs can have multiple names in different vendor and operator environments, this disclosure refers to all SDPs that are equivalent in function.

The SDP may be used in one embodiment for financial, investment, and/or insurance operations. This includes keeping track of account balances and debiting and crediting accounts as well as transferring funds from one account into another. An SDP Register or centralized SDP can be used for routing information to specific SDP signals. An embodiment of an SDP Register can be managed and controlled by a consortium or governmental body.

“In one embodiment, the SDP communicates to financial institutions 116. ATM machines, point-of-sale terminals, mobile enablement centers 106, and/or merchants 104 for the purpose processing point-of sale transactions with financial institution or payment processing servers 110. SDP supports any standard data communication protocol or data security standards, such as International Standards Organization (ISO 8583), simple object access protocol/extensible Markup Language (XML), SOAP, and hypertext transfer protocol(HTTP), secure sockets layers (SSL), etc.

“In one embodiment, the payment processor 110 identifies 504 as a service point (SDP), responsive to a mobile number provided by the device 102. The phone number refers to a customer number that is associated with the customer’s bank account. It is controlled by SDP. The service data point 412 stores customer phone numbers in addition to customer information. It is also where the customer’s account information can easily be retrieved using the phone number. The service data point 412 may be used in one embodiment to manage financial institution accounts.

“In one embodiment, the payment processor server cannot identify the appropriate SDP based upon the provided account number. In such an instance the payment processing system sends an Interrogation Request to the Registry of SDPs 414 in order to identify 504 the SDP associated to the customer’s account number. The registry of SDPs 414, which provides routing information for an SDP 412 associated to the customer’s bank account, gives this information.

“Once the appropriate SDP 412 has been identified, the payment processing servers interrogates it to obtain 506 account information associated the customer’s telephone number. The SDP 412 can retrieve account data associated with the customer?s phone number.

“The payment processing server 110 sends 508 transaction information requests to the merchant. The merchant ID is used as the merchant ID. The merchant can respond to the request by sending transaction information to the payment processor server. One embodiment of the method is that the payment processing server receives transaction information from the merchant via communications methods known in the arts. The transaction information may include the total price of the item, the account number associated with merchant, and the customer’s mobile number. To provide transaction information to the payment processing servers 110, the merchant 104 may use any communication method (COMM), which is known to art. One embodiment allows the merchant to enter the total amount of the purchase on the keypad of a point-of sale terminal.

“As mentioned above, in one embodiment the payment processing server 110 sends to 512 an authorization request the mobile device that initiated the transaction request. The payment processing server 110 can send a COMM (an SMS message or an email) to the customer’s phone number or to the email address that initiated the transaction. One embodiment of the payment processing server 110 sends 512 the account number and name to the mobile device. This is in addition to the authorization request. Another embodiment allows the customer to provide both a customer’s phone number and a different communication phone number. The customer can initiate a transaction by providing an account number. To initiate the transaction in such an instance, the customer could use the application running on the communications mobile device (102), or use COMM messaging. In such an example, the payment processing server 110 sends to 512 an authorization request at the communications number. The customer can then provide authorization associated with the account number.

“In one embodiment, the payment processing system 110 receives 514 authorization messages from a mobile device. An authorization message may include a customer’s personal identification number (PIN). Customers can create multiple PINs to be used for different accounts. A customer may set up a PIN to limit purchases below a certain dollar amount, and another PIN to limit purchases above a dollar amount. The customer can also set up a different PIN for specific merchants. A different PIN can be created by the customer in another embodiment. This is a unique PIN that expires after the first use. It applies when the communication phone number used to initiate the transaction is different than the one associated with the customer. One embodiment allows the mobile device 102 to erase all PINs from its on-board and off-board memory. The authorization PIN is received by the payment processing server 110 via a communications network. A customer can use a different communications number than their account number to create a one-time password or a PIN that expires after the first use. A customer may, for example, set a one-time password that expires after the first use. This can be used for purchases exceeding a certain amount or purchases made with a specific merchant.

“Once the correct authorization code, e.g. a PIN, is received from the mobile phone 102, the payment processing servers executes the requested transaction using the SDP 412. The SDP 412 update the customer’s account information. The transaction confirmation is sent by the payment processing server 110 to the mobile device (102) and the merchant (104). In one embodiment, the payment processor 110 sends 518 transaction confirmations to the merchant 104 and the mobile device 102. 518 confirmations can be sent using any communication method (COMM), including an SMS message, email address or phone call. One embodiment of the method is that the payment processing server 110 sends 518 confirmations to the point-of-sale terminal associated the merchant ID. In this case, the point of sale terminal can print a copy for the merchant or customer. If the communication phone number of the customer is different from the one associated with the transaction account’s transaction account, the payment processing servers 110 send 518 a transaction verification to either one or both numbers. You can include information about the transaction, such as the date and time, transaction amount, etc. in the confirmation communication.

“FIG. “FIG. 6 illustrates a block diagram that shows a high-level computing environment to use a mobile device to perform a transaction according one embodiment. A computing environment could include a mobile device (102), a payment processing system 110, a merchant (104), and a financial institution (116).

“FIG. 7 is a flowchart that illustrates a method for using a mobile device in order to initiate a transaction using service data points according to one embodiment. FIGS. FIGS. 6 and 7 will be discussed below concurrently.

The merchant initiates the point-of-sale in one embodiment of the described system and method. One embodiment uses a point-of-sale terminal that is associated with the merchant 104 to enter and transmit point of sales information, such as transaction amount and communications phone number. An account phone number refers to a number that is associated with a financial institution. A customer may, for example, choose to have a specific phone number associated with a certain account at a financial institution. You can have a credit, debit, savings, or payroll account. An account can have a communications number, which is the number associated with the customer. Another example is that the communications number can be different from an account number. This allows a customer to borrow a phone and execute a transaction. If a customer loses or forgets his mobile phone, they can request that a communication is sent to the number associated with the borrowed telephone. Other embodiments allow the customer to provide either a communications email address, or an account email address, wherein the email account is linked with the customer’s financial institution account.

“In one embodiment, payment processing server 110 receives 702 point-of-sale information from merchant 104. The merchant 104 provides the payment processing server 110 with 704 authorization requests. In one embodiment, the payment processor 110 sends 704 authorization requests to the customer’s account number or communications phone number. One embodiment of the payment processing server 110 sends a SMS message, COMM or email to the number or email address that initiated the transaction. One embodiment of the payment processing server 110 is capable of sending 704 an account number and name to the mobile device102 together with the authorization request. The payment processing server 110 can list all accounts that the customer has access to, such as credit and debit accounts associated with a phone number. In this case, the payment processing server 110 opens data sessions to the mobile device 102, and presents a menu from which the customer can select the account they wish to use to complete the transaction. Another embodiment uses the payment processing server 110 to open a USSD menu option, if it is available, or a WAP Push message with multiple links denoting different accounts. This allows the client to communicate with the server via the mobile device 102. In such cases, the customer can also enter the authorization PIN for the account they wish to use to complete the purchase. Another embodiment requests one PIN from the payment processing system, even if multiple accounts have been associated with the account number. The customer can then enter the authorization pin for the account they wish to use to complete the purchase. Based on the authorization PIN matching one of the accounts associated with the account number, the payment processing server 110 will identify a credit account or debit account.

“In one embodiment, the customer may enter and send a message (to the payment processing server 110) to authorise the transaction. 706 authorizations are received by the payment processing server 110 from a mobile device. An authorization message may include a personal identification code (PIN), associated with the customer’s account. Customers can create multiple PINs to be used for different accounts. A customer may set up a PIN to limit purchases below a certain dollar amount, and another PIN to limit purchases above a dollar amount. The customer can also set up a different PIN for specific merchants. A customer can also use a one-time password or a PIN that expires after the first use. This is possible when using a different communications number than their account number. A customer may, for example, set a one-time password that expires after the first use for any purchases exceeding a certain amount or with a specific merchant. One embodiment of this invention is that the mobile device 102 associated to the communications number is configured so that all PINs from the mobile devices’ off-board or on-board memory are deleted. The payment processing server 110 receives 706 authorization PINs from customers via a communications network.

“In response to the customer’s authorization, the payment processing servers 110 receives 706 authorizations from the mobile device. The payment processing server executes 708 point-of-sale transactions with financial institutions associated to the customer and merchant 104, as described in more detail above. After the transaction has been completed 708, the payment processing servers sends the merchant 104 a confirmation. This includes the communication as well as the account number. In one embodiment, the payment processor 110 sends 710 transaction confirmations to the merchant 104 and the mobile device 102. You can send 710 confirmations using any communication method (COMM), including an SMS message, email address or phone call. One embodiment of the method is that the payment processing server 110 sends 710 confirmations to the point-of-sale terminal associated the merchant ID. The point-of-sale terminal may print a copy for the merchant or customer. If the communication phone number of the customer is different from the one associated with the transaction account’s transaction account, the payment processing servers 110 send 710 a transaction verification to either one or both numbers. You can include information about the transaction, such as the date and time, transaction amount, etc. in the confirmation communication.

Referring to FIG. 8 illustrates a high level block diagram of a computing ecosystem for using a mobile phone to execute a transaction associated to a sub-account in accordance with one embodiment. A computing environment could include a mobile device, an SDP 412 account, a sub-account and an account associated to the mobile number 812.

“FIG. “FIG. 9 is a flowchart that illustrates one method for using a mobile device in order to execute a transaction associated to a sub-account. FIGS. FIGS. 8 and 9 will be discussed below concurrently.

“As explained in more detail above, the merchant 104 or the mobile device 102 can initiate a transaction by sending a merchant number and an account phone number (SDP) 412. One embodiment of the SDP receives 902 transaction requests either from merchant 104 or mobile device 102. One embodiment of the SDP’s interrogation 904 is to determine if the account phone number received is associated with a subaccount. A sub-account 812 may be associated with a parent account 810. The sub-account might have restricted access to funds in the parent account 810, or the account associated to the mobile number. If the SDP finds that an account phone number is associated to a subaccount, it will provide that a subaccount criteria has been matched 906.

“In other embodiments the sub-account criteria may be matched 906 in another way. A sub-account can also be associated with a phone number. If a communications number matches the sub account 812 criteria, then the SDP 912 executes a transaction with that sub-account upon receiving authorization. An authorization PIN may also be associated with a sub account in other embodiments. The SDP will send an authorization request to the appropriate communications phone number, one or more associated with the sub account, or the parent account 810. The authorization request can be sent by the SDP, or the payment processing servers 110 to 908, for example, to the account phone number associated the parent account 810, or the phone number associated the sub-account. A customer can also create a sub-account to allow family members, such as children, to make purchases on their mobile devices. In a similar fashion, a parent can approve or reject certain purchases made by the sub-account holder in real time via an authorization request sent to a number associated with the parent 810.

“As explained above, the payment processing servers 110 send 908 authorization requests to the appropriate mobile devices 102, including the one that initiated the transaction, or to the phone number associated to the parent account 810. The payment processing server 110 can send an SMS message, an email to the provided phone numbers, or an email address. One embodiment of the payment processing server 110 sends 908 the account number and account name to the relevant mobile device 102 together with an authorization request. Another embodiment allows the customer to provide both a customer’s phone number and a different communication phone number. The customer can initiate a transaction by providing an account number and initiating communication from another number. To initiate the transaction, the customer can either use COMM messaging or an application running on the communications mobile device. In such an example, the payment processing server 110 sends 908 a authorization request to the communications number. The customer can then provide authorization associated with the account number.

“The SDP may receive 910 authorization from the subaccount phone number. The communications phone number and the number associated with the parent 810 account. An authorization message may include a customer’s personal identification number (PIN). Customers can create multiple PINs to be used for different accounts. A customer may set up a PIN to limit purchases below a certain dollar amount, and another PIN to limit purchases above a dollar amount. The customer can also set up a different PIN for specific merchants. A different PIN can be created by the customer in another embodiment. This is a unique PIN that expires after the first use. It applies when the communication phone number used to initiate the transaction is different than the one associated with the customer. One embodiment allows the mobile device 102 to erase all PINs from its on-board and off-board memory. The payment processing server 110 is able to receive 910 the authorization pin from the customer via a communications network. A customer can use a different communications number than their account number to create a one-time password or a PIN that expires after the first use. A customer may, for example, set a one-time password that expires after the first use. This can be used for purchases exceeding a certain amount or purchases made with a specific merchant.

“The SDP may initiate the execution of the transaction between customer and merchant 104. The SDP will execute 914 the transaction with the parent account 810 if it does not have the appropriate authorization. A transaction confirmation is sent to merchant, communications phone number, account phone number, or sub-account number.

“FIG. “FIG. A computing environment could include a mobile device (102), a mobile enablement centre 106, a register payment processing servers 110, a merchant (104), a service point 112, a registry of service points 114, and a financial institution (116).

“In one embodiment, the SDP could manage an aggregate account (also known as a Nostro Account in a bank that contains multiple sub accounts that can be used to represent payroll accounts. These payroll accounts can be used by those who are unable to open an account themselves due to insufficient funds or poor credit. If they are linked to a mobile number, such aggregate accounts can be accessed via any payment processing server 110 and SDP. Multiple virtual accounts can be created from one subaccount of an aggregate account. A worker without a bank account might ask his employer to open a subaccount to deposit payroll directly. The worker’s mobile number would be associated with the subaccount. A worker could create virtual sub-subaccounts via the SDP and transfer funds to these sub-subaccounts. Each sub-subaccount could be linked to a mobile phone. They can be accessed via any mobile enablement center (106) or payment processing server 110. The SDP may be used to replace or perform functions performed by the mobile enablement centre in one embodiment. One embodiment of the SDP allows fund transfer control between banks, merchants and phone accounts.

“FIG. “FIG. 11. is a flowchart that illustrates one method for using a payroll card in order to execute a transaction. FIGS. FIGS. 10 and 11 will be discussed simultaneously below.

“In the embodiment described in reference to FIGS. 10, 11 and 10 respectively, the point-of-sale transaction is initiated either by a merchant (104) or a mobile device (102), wherein the account number is associated to a payroll card 1002. A payroll card 1002 is a debit card that can be linked to a payroll account. The payroll card 1002 can be used by the customer’s employer to deposit payroll checks into the account. Instead of sending a customer a weekly, biweekly, or monthly payroll check that can be cashed or deposited or sent to them, the employer can deposit weekly, biweekly, or monthly payroll checks to the payroll account. This will eliminate the need for the employer to issue new payroll checks every payroll cycle. This system reduces the cost for employers to issue checks. Employees also benefit from such a system because they can access a card account that is associated with the card. This allows them to purchase without opening new accounts or credit lines with other financial institutions. Each payroll account can also be linked to a payroll trust account. A payroll trust account is a group of accounts that an employer uses to make payments to each employee’s individual payroll account. Payroll trust accounts are generally non-renewable and have a float. The trust account can be used to lend funds to customers if funds in their customer payroll accounts run out. This is an added benefit, which will be explained in more detail below. The payroll trust account may withhold money due from employees in the next payroll period. You can withhold money from the borrow money, all of it, or just a portion.

“In one embodiment, the payment processor server receives 1102 requests to execute transactions from an account associated the payroll card 1002. A merchant may swipe or enter the account number associated to the payroll card at a point-of-sale terminal. A firmware update can be applied to the terminal to allow customers to use their payroll card to make purchases. A mobile device can also be used to initiate point-of-sale transactions. The mobile device can transmit a merchant identification and account number to a service data center (SDP) 412 as well as a mobile enablement centre 106. A second embodiment is that the customer can borrow a device for a mobile computing purpose to start a point-of-sale transaction.

The SDP receives the request and sends 1104 authorization information to the mobile number associated with the communications number or payroll account. In one embodiment, the SDP412 sends 1104 authorization requests to the mobile device number 102 that is associated with the payroll account. The SDP 412 can send a COMM, SMS, or email to the customer’s phone number or email address associated with the payroll accounts. One embodiment of the SDP 412 allows the sending of 1104 account numbers and names to the mobile device 102. This authorization request can also be sent by the SDP 412. A different embodiment of the authorization request can be sent by the payment processing server to a communications phone number other than the one associated with the payroll account. In the communication 1102 containing information about the payroll account, a communications number can be provided to enable a transaction to be executed. To initiate the transaction, the customer can use an app executing on a mobile device (102 associated with the communications number).

“In one embodiment, SDP 412 receives 1106 authorization from a mobile device102. An authorization message may include a personal identification code (PIN), which can be associated with the customer’s account. Customers can create multiple PINs to be used for different accounts. A customer may set up a PIN to limit purchases below a certain dollar amount, and another PIN to limit purchases above a dollar amount. The customer can also set up a different PIN for specific merchants. A different PIN can be created by the customer in another embodiment. This is a unique PIN that expires after the first use. It applies when the communication phone number used to initiate the transaction is different than the one associated with the customer. One embodiment allows the mobile device 102 to be configured to erase all PINs from any of its on-board or offline memory. The SDP 412 is able to receive 1106 authorization PINs from customers via a communications network. A customer can use a different communications number than their account number to create a one-time password or a PIN that expires after the first use. A customer may, for example, set a one-time password that expires after the first use. This can be used for purchases exceeding a certain amount or purchases made with a specific merchant.

“An SDP logic determines if the payroll account has sufficient funds 1108 for the transaction requested. If the answer is yes, the SDP executes 1112 a transaction with a bank associated to the payroll card. If the SDP finds that the payroll account is not in sufficient funds, the SDP executes 1110 transactions with the payroll trust account. After the transaction is completed, a transaction confirmation will be sent to the merchant and the mobile phone associated with the payroll account. One embodiment sends 1114 transaction confirmations to the mobile device (102, 104), and the merchant (104). You can send 1114 confirmations using any communication method (COMM), including an SMS message, an email address or a telephone call. One embodiment sends 1114 confirmations to the point-of-sale terminal associated the merchant ID. In this case, the point of sale terminal can print a copy for the merchant or customer. If the communication phone number of the transaction account is different from the one used to confirm the transaction, the SDP 412 will send 1114 a confirmation message to either one or both numbers. You can include information about the transaction, such as the date and time, transaction amount, etc. in the confirmation communication.

“While certain embodiments and uses of the invention have been described and illustrated herein, it should be understood that the invention does not limit itself to the construction and components listed herein. Various modifications, changes and variations can be made to the operation and details of the methods or apparatuses of this invention without departing completely from the spirit and scope thereof as defined in the appended claims.

Summary for “Mobile payment station system”

It is now common to use a credit card or debit card, a payroll card, ATM card, ATM card, or any other stored value card (hereafter credit cards) to purchase one or more items at a merchant. A merchant can, for example, enter the total amount of the sale in a terminal to initiate a point-of-sale. To process the sale, the merchant can request a customer’s credit card. The customer’s credit card information will be entered into a point-of-sale terminal. This information is then sent to clearinghouse servers. The clearinghouse can verify the credit information and route transactions based on routing numbers associated to the credit card. A clearinghouse can authorize a financial institution to execute a transaction and send a confirmation of the transaction to the merchant’s terminal. To receive customer approval, the merchant can print a copy of the transaction confirmation.

This method is fast and reliable, which is why it’s so popular. The customer can also make a purchase anytime, regardless of whether they have cash available to buy a product. To be able to execute such transactions, the customer must have a credit or debit card. If the customer has a debit account, he/she can use the card’s convenience to make transactions using a debit card. Many customers don’t have bank accounts and do not have debit cards. Customers under 18 may not be eligible for credit cards. However, they may still need to have a safe way to purchase goods.

A customer who uses a credit card is also at risk of fraudulent transactions or credit card fraud. If a customer’s card is stolen or lost, any other person can use the card to make a transaction by simply showing the card to the merchant. The clearing house and financial institutions will not be able to catch fraudulent transactions if the card owner has not reported it.

A customer might not be able use credit processing systems to make a purchase if they don’t have their card at the merchant site. A customer cannot use another person’s credit card to make a purchase. Credit cards and cards linked to financial institutions offer a less-than-optimal method of executing transactions associated with a customer?s financial or credit account.

A customer might not be able use credit processing systems to make a purchase if their card has a defective magnetic strips, chips or electronic near field communication (NFC). A customer might not be able to use credit processing systems for executing a purchase if their point of sale terminal is defective or contains a defective NFC receiver. This prevents the NFC receiver from reading card information.

“It is a general purpose of the present invention that a customer can use a mobile communication device to initiate and complete a transaction by reversing conventional point-of-sale transaction initiation. That is, the processing server opens communications toward point of sales terminal using merchant ID or point-of sale terminal ID instead of the traditional method of point terminal opening communications towards processing servers.”

“It is the general object of this invention to enable a customer to use mobile communications device to initiate or execute a transaction. This overcomes the problems associated with using a debit or credit card. It also takes advantage of the availability of mobile communications devices and their communications capabilities.

“It is also a general purpose of the present invention that a customer can use other methods, such as calling an interactive voice reply (IVR) system and using voice (or dual-tone multifrequency (DTMF), commands on a landline to initiate or execute a transaction. This overcomes the aforementioned issues with using a debit or credit card and takes advantage of the abundance of telecommunications methods available today.

A mobile device can be used for initiating and executing a transaction with merchants. A mobile device can be used to initiate a point-of-sale transaction. This involves a merchant ID, or, for instance, a point terminal ID (hereafter referred to as?merchantID?). The information is sent to a payment processor server. The payment processing server responds to a mobile device communication and requests transaction information from merchants. This allows merchants to be identified using the provided merchant ID. The merchant can give transaction information to the payment processing service, such as the total amount of the sale. The merchant can authenticate the customer to initiate a purchase transaction with the merchant and appropriate financial institutions. The merchant and the mobile device can be sent a confirmation by the payment processing server of an executed transaction.”

“It is another object of the present invention that a point-of-sale terminal associated with a retailer can be used to execute a transaction between a customer and a merchant. Point of sale information can be provided by merchants, including purchase amount, merchant ID, and account number. An account phone number may include the customer’s financial institution account number, the phone number associated with the customer’s financial account number, and the phone number used to access the account in a financial establishment, hereafter called the?account number.? A payment processing server responds to merchant point-of-sale information and identifies the account associated with the account number. It then sends authorization requests to the account number. The customer can use a communication device to enter authorization personal information and send it off to the payment processing servers. The payment processing server can authenticate and initiate a purchase transaction between the customer’s financial institution and the merchant. The merchant and the mobile device can be sent a confirmation by the payment processing server of an executed transaction.”

“It is another object of the present invention that a payroll account can be used with an account number to execute a transaction between merchant and customer. A merchant can initiate the point-of-sale transaction using the point of sales terminal, or a customer can use a communication device or IVR call to initiate the transaction. The service data point (SDP), receives the merchant ID and account phone number. The authorization request is sent to the account number by the payment processing server. The authorization personal identification number can be entered by the customer on a mobile device that is associated with the account number. This number will then be sent to the SDP. The SDP can authenticate customers associated with their payroll accounts and initiate purchase transactions between the merchants and the associated payroll account. SDPs can confirm the transaction to the merchant or the mobile device. An SDP’s functionality can be integrated into the mobile enablement centre 106. It can be called SDP, Mobile enablement center or vice versa. The functionality of the mobile enablement function center can also be integrated into an SDP. This is called either the mobile enablement centre or the SDP. An example of this is the implementation that can be done in an SDP.

“The specification does not contain all the features and benefits. A person of ordinary skill in art will see many more features and advantages in the specification, drawings, and claims. It is important to note that the language in the specification was selected primarily for its readability and instructional purpose and may not be used to define or circumscribe the inventive subject matter.

“The preferred embodiment of this invention is described using reference to the figures, where like reference numbers indicate identical elements or functionally comparable elements. The figure’s leftmost digit corresponds to the first time the reference number was used.

“Refer in the specification to?one? embodiment? Or to?an embodiment? It means that at least one embodiment contains a particular feature, structure or characteristic. It is possible to see the phrase “in one embodiment?” or ?an embodiment? “The specification does not always refer to the same embodiment in different places.”

“Some parts of the following description are described in terms of symbolic representations and algorithms of operations on data bits within computer memory. These representations and algorithmic descriptions are used by data processing artists to communicate the essence of their work to others. An algorithm can be described as a sequence of steps that leads to the desired result. These steps require physical manipulations of certain quantities. These quantities are usually stored in the form of electromagnetic, radio, or electrical signals that can be combined, stored, transferred, compared, and manipulated in any other way. These signals can be referred to as bits, values or elements, symbols, terms, numbers, terms or characters. This is primarily for common usage. It is also possible to refer to certain steps that require physical manipulations, transformations, or representations physical quantities in code devices or modules, without losing their generality.

“All of these terms and similar terms must be associated with the relevant physical quantities. They are not merely labels that are applied to these quantities. It is not clear from the discussion that discussions using terms like?processing? will be included in the description. Or?computing? Or?calculating? Or?determining? Or?displaying? Or?determining? The action and processes of a computer or similar electronic computing device (such a specific computer machine) that manipulates or transforms data stored in computer system memories, registers, or other information storage, transmission, display, and transmission devices.

Certain aspects of the invention include instructions and process steps described in an algorithm. The process steps and instructions described in the present invention can be embedded in software, firmware, or hardware. When embedded in software, they could be downloaded to be used on a variety operating systems. It is also possible to include the invention in a computer program product that can be executed on a computer system.

“The invention also includes an apparatus for performing these operations. The apparatus can be a particular computer or a general purpose computer that is activated or reconfigured using a computer program. This computer program can be stored on a non-transitory computer-readable storage medium. It could include, but not limit to, floppy disks and optical disks. Memory can include any of the above and/or other devices that can store information/data/programs. The specification can also refer to computers that have a single processor, or architectures with multiple processor designs to increase computing power.

“The algorithms and displays described herein do not necessarily relate to any particular apparatus or computer. You can use the programs with other general-purpose systems, or you may need to build more specific apparatus to accomplish the method steps. Below is a description of the structure that can be used to create a variety system. The present invention does not refer to any particular programming language. You will appreciate that the present invention can be implemented using a variety programming languages. Any references below specific languages are made for disclosure of enablement or best mode of implementation.

“In addition, the language in the specification was selected principally for readability and instruction purposes and may not have been chosen to define or circumscribe the inventive subject material. The disclosure of the present invention is meant to illustrate, but not limit, the invention’s scope, as set forth in the claims.

“FIG. “FIG. A computing environment could include a mobile device (102), a mobile enablement centre 106, a register payment processing servers 110, a merchant (104), and a financial institution (116).

“FIG. 2. This flowchart illustrates one method for using a mobile device in order to initiate a transaction. FIGS. FIGS. 1 and 2 will be discussed simultaneously.

“In one embodiment, the point of sale transaction is initiated by the mobile device 102. Any computing device that can communicate over a network or communications link with another mobile device 102 is considered a mobile device 102. A mobile device 102 could be a cell phone, personal device assistant, smart phone, laptop computer, desktop or any other device. The mobile device transmits a merchant ID to the payment processing server. A merchant ID number is a unique identifier that is associated with a merchant. Any information that can be used to identify the merchant or communicate with it is possible. A merchant ID could include a point of sale terminal ID that can be used by merchants to execute transactions. Other embodiments of the merchant ID include an email address or a telephone number.

“In one embodiment, the customer can enter a merchant ID onto the mobile device102 by using the input system of the device, such as a keyboard, touchpad, etc. Other embodiments allow the customer to view the merchant ID information via the camera on their mobile device 102. Other embodiments allow the customer to see the merchant ID information in plain sight. Other embodiments allow the merchant ID information to be displayed in plain view for customers. Other embodiments allow the mobile device to receive the merchant ID information via a communication link, such as BLUETOOTH communications and RFID communications fields. A merchant may have a point of sale terminal that broadcasts the merchant’s ID to mobile devices using a BLUETOOTH or laser, radio, infrared, close range electromagnetic field communications link, and/or radio. One embodiment sends the merchant ID received by the mobile device 102 to another party via a communications network.

The mobile device 102 can send the merchant ID to mobile enablement center (106) using any communication method. It can use unstructured service data (USSD), SMS, multi-media message (MMS), IVR and email to send the merchant ID to the mobile enablement center 106. This communication, or any other example of communication, is referred to as COMM.

The mobile device 102 is able to use any communication method (COMM), to send the merchant identification to the mobile enablement centre 106. One embodiment of the invention allows the mobile device 102 to send the merchant ID via SMS over a mobile communication network such as GSM, iDEN, CDMA networks, in any configuration that can be 2G, 3G and 4G. The mobile device can also send multi-media messages (MMS) in other cases. The customer can also take a picture of the barcode or number identifier associated to the merchant ID, and then send it over a communications network. Another example is that an application running on the mobile device102 can read or recognize the barcode and number identifier associated to the merchant ID in order to send it over a communication network. Other embodiments depend on the capabilities of the mobile device. The mobile device can connect via WiFi to send the merchant ID via email over the network to the payment processing server (106). One embodiment allows the customer to enter the merchant ID using an IVR via a landline phone. Other embodiments allow the customer to use an interface that is part of the application running on the mobile device, 102 to send the merchant identification to the mobile enablement centre 106 via a communications network. Below is a description of the network that connects the mobile device 102, merchant 104 and mobile enablement centre 106. The payment processing server 110, service data point 112 as well as the financial institution are also described.

“In one embodiment, the merchant identification is sent to a payment processing server 110. A customer may choose to set a preference that all transactions made with the mobile device102 will be associated with a specific financial institution and routed through a certain payment processing server 110. An embodiment uses IPV6 protocols to route communications requests to the appropriate payment processing servers 110. Another embodiment is that the mobile device 102 transmits the merchant ID over a communications network to a mobile enablement centre 106. This will then route the request to the appropriate payment processing server 110.

“The mobile enablement centre 106 is a platform which routes outgoing messages from mobile devices 102 to appropriate payment processing servers 110. The mobile enablement centre 106 can receive routing request from multiple service broadcast operators such as mobile phone network operator GSM/CDMA network operators, landline operators, LAN operators, and others. Mobile devices 102, including landline and VOIP phones, can send outgoing messages to the service broadcast operator. The number or device associated with the request receives the message. The outgoing message is routed to the broadcast operator that corresponds with the intended recipient by the service broadcast operator. The invention’s mobile enablement center (106) receives routing requests from the service broadcast operator for the mobile device. One embodiment of the invention states that the mobile enablement centre 106 routes the message from the mobile device 102 to the appropriate payment processing server106. This is based on the outgoing text’s phone number and the intended recipient’s number. It also includes the merchant ID in the message. If a user’s number is associated to a financial institution 116 then the mobile enablement centre 106 routes the message directly to the payment processing server 110.

“In one embodiment, the payment processor server 110 queries a registry of payments processing servers 108 in order to identify an appropriate payment server 110. A registry of payment processor servers 108 may include a list of payment processing server 110 that is based on routing numbers, other identification information, or coordinated new routing mechanisms that could be mandated, devised, or supervised, for example, by a standardization body or governmental body, consortium body of companies, or leaders in this field.

“A payment processing server 110” is a platform that executes transactions between a customer, financial institution 116 and a merchant. 104 A payment processing server 110 could be any database maintained by American Express, Visa, MasterCard, American Express, or other financial institutions. One embodiment of the payment processing server 110 receives from the mobile device 101 202 the merchant identification. Another embodiment is that the payment processing server 110 receives the merchant ID from the mobile device 102 in a message sent by the mobile enablement centre 106.

“In one embodiment, the payment processor 110 sends 204 an inquiry for transaction information to merchant 104 that is associated with the received merchant identification. The merchant can communicate with any communications method (COMM), as is known to the art. The payment processing center may send an SMS, an e mail message, etc. to a merchant’s phone number or email address 104. One embodiment allows the merchant ID to be linked with a unique point-of sale terminal. In this case, the payment processing server 110 could send a message to the specific point-of-sale device.

“The merchant 104 may provide transaction information to the payment processing server 110. Transaction information may include the customer’s total purchase price, the merchant account number, and the customer’s mobile phone number. To provide transaction information to the payment processing servers 110, the merchant 104 may use any communication method (COMM), which is known to art. One embodiment allows the merchant to enter the total amount of the purchase on the keypad of a point-of sale terminal. Point of sale terminals can have a station that allows the merchant to swipe or enter a customer’s debit or credit card in order to complete a purchase transaction. Another embodiment of the point-of-sale terminal may include a computing device such as a machine or desktop computer, tablet, laptop, or mobile phone. Other embodiments allow point-of-sale terminals to include existing transaction terminals such as an ATM, vending machine, etc. If existing terminals, such as ATMs or card-swipe machines are being used, they can be updated with a firmware update in order to receive transaction information requests via a payment processing server 110.

“The merchant 104 sends the payment processing server 110 206 transaction data. One embodiment of transaction information includes the phone number associated to the customer’s mobile device 102. The payment processing server 110 authenticates 102’s phone number. One embodiment of this method is that the payment processing server 110 authenticates the incoming call’s phone number against a service broadcast operator network. If a mobile number is associated to the T-MOBILE network, the payment processing servers 110 can query the TMOBILE operator network 311, in order to identify an account associated with that mobile number.

“In an alternative embodiment, the payment processing service 110 queries a register 414. This is described in more detail below. The query is answered by the payment processing server 110, which receives account information associated to the phone number of the device 102 and the identity of mobile enablement centre 106. In one embodiment, the payment processor 110 queries the mobile enabledment center 106. The mobile enablement server 106 responds to the query by querying a register of payment processor 108 to retrieve account information for the mobile device’s number 102. After receiving the correct account information, the payment processor 110 contacts the mobile enablement centre 106 to retrieve the account information associated with the 102 number of the mobile device and sends a request for authorization to the mobile device. One embodiment of the payment processing server 110 transmits a transaction authorization (102) to the merchant. The payment processing server 110 initiates an account number-related transaction when it receives a positive transaction authorization from the mobile device 102 and the merchant 104.

“As mentioned above, the payment processing service 110 can identify an account that is associated with the mobile number 102. Multiple accounts may be associated with the same mobile number in one case. In this case, the payment processing service 110 queries a mobile enabledment center 106. The mobile enablement centre 106 can identify an account that is associated with multiple accounts, such as virtual accounts and real accounts that are associated with the mobile number. The mobile enablement centre 106 can use additional logic to identify the account from the list of accounts that are associated with the mobile number. A user may specify that a debit card should only be used for purchases below a specific dollar amount. For example, $5 could be an example. Another embodiment allows the customer to associate certain accounts with transactions executed with a specific merchant. If the merchant ID is associated to a retail merchant, then the payment processing server 110 will be able to identify a debit card.

“In one embodiment, the payment processor 110 authenticates merchant upon receiving transaction information from merchant. The merchant can be authenticated, for example, if the merchant confirms either the merchant ID or customer’s mobile number that initiated the transaction. Once the authentication process has been completed, the payment processing server 110 will identify the merchant’s account.

“In one embodiment, the payment processor 110 sends 208 a authorization request to the mobile phone 102 that initiated the transaction request. The payment processing server 110 can send a COMM (an SMS message or an email) to the customer’s phone number or to the email address that initiated the transaction. One embodiment of the payment processing server 110 sends 208 the account number and name to the mobile device. Another embodiment allows the customer to provide both a phone number and a different communication phone number. The customer can initiate a transaction by providing an account number and initiating communication from another number. To initiate the transaction, the customer can either use COMM messaging or an application running on the communications mobile device. In such an example, the payment processing server 110 sends to 208 an authorization request at the communications number. The customer can then provide authorization associated with the account number. This could be used to allow a customer to borrow another’s mobile phone to complete his or her transaction.

“In one embodiment, the payment processing service 110 receives 210 authorization from a mobile device. An authorization message may include a customer’s personal identification number (PIN). Customers can create multiple PINs to be used for different accounts. A customer may set up a PIN to limit purchases below a certain dollar amount, and another PIN to limit purchases above a dollar amount. The customer can also set up a different PIN for specific merchants. A different PIN can be created by the customer in another embodiment. This is a unique PIN that expires after the first use. It applies when the communication phone number used to initiate the transaction is different than the one associated with the customer. One embodiment allows the mobile device 102 to erase all PINs from its on-board and off-board memory. The payment processing server 110 receives 210 an authorization PIN from the customer via a communications network. A customer can also use a one-time password (one-time use PIN that expires after the first use) using a different communications number than their account number. A customer may, for example, set a one-time password that expires after the first use. This can be used for purchases exceeding a certain amount or purchases made with a specific merchant.

“In one embodiment, a payment processing server 110 executes 221 transactions with a financial institution. The payment processing server 110, for example, identifies the financial institution associated to the customer’s bank account and the financial institution associated to the merchant’s bank account. In this case, the execution of the transaction consists of debiting the customer account of the purchase amount and crediting it to the merchant account. Additional fees can be added by financial institutions 116 or payment processing servers 110, mobile capability centers 106 to the purchase amount.

“In one embodiment, the payment processing servers 110 send 214 a transaction verification to the mobile device (102) and the merchant (104). Any communication method (COMM), including an SMS message, email address, or phone call, can be used. Refer to FIG. To send 214 confirmations, you can use the number 3. One embodiment sends the confirmation to the point-of-sale terminal associated the merchant ID. The point-of-sale terminal may print a copy for the merchant or customer. If the communication phone number of the customer is different from the one associated with the transaction account’s transaction account, the payment processing servers 110 will send 214 a transaction verification to either one or both numbers. You can include information about the transaction, such as the date and time, total transaction amount, and details about whether it was successful. If the merchant has chosen COMM as the preferred delivery method for confirmations, the payment processing server 110 will send 214 the transaction verification via COMM to the merchant.

“FIG. “FIG. 1. According to one embodiment. The computing machine 300 could also be considered a part or system of another system, such as two or more computers operating together, or one or several machines operating with one or both of the other devices.

“FIG. “FIG. Specifically, FIG. FIG. 3 is a diagrammatic representation showing a machine in which mobile payment device instructions 324, e.g. software code, can be executed to execute any or all of the methods discussed herein. Alternative embodiments allow the machine to operate as a standalone device, or connected (e.g. networked) with other machines. The machine can be used in a networked environment as a server machine, client machine, or peer machine in a peer to peer (or distributed) network environment.

“The machine can be a server, client, or a computer that is capable of executing instructions 324 that are sequential or not. Although only one machine is shown, the term “machine” can also be used. It shall be understood that any machine or collection of machines that execute instructions 324 individually or collectively to perform any or all of the methods discussed herein is a machine.

The example computer machine 300 contains a processor 302, which can be a central processing unit, group of processors or a group processing machines, one or more application-specific integrated circuits or (ASICs), one of more radio frequency integrated circuits or (RFICs), one of more radio-frequency circuits or (RFICs), one of more radio-frequency circuits or (any combination thereof), and a memory 304. It also includes a network interface device (320) capable of interfacing with a projector tube (LCD), a plasma display (PDP), a LCD), a display panel (LCD), an LCD), a display (LCD), and ray tube (CRT), and a projector or ray tube (CRT), and ray tube (CRT), and ray tube (CRT), and a) and a bus).

“The storage unit 312 includes a machine-readable media 322 on which are stored mobile payment device instruction 324 (e.g. software) that embody any of the methods or functions described herein. The mobile payment instructions (e.g. software) can also be stored in the main memory 302 or the processor 302 during execution by the computer system 300. Both the main memory 302 and the processor 302.

“The external storage 317 contains a machine-readable medium that can store merchant or mobile device information. The machine 300 can, in one embodiment, access the external storage 317 via communications links. All components of the machine 300 are able to access the storage medium 317 in an embodiment.

In an example embodiment, machine-readable medium 322 has been shown to be one medium. However, the term “machine-readable media” is used. It should be understood that a single medium can also include multiple media (e.g. a distributed or centralized database or associated caches or servers) capable of storing instructions (e.g. mobile payment device instructions 324). “Machine-readable medium” is also used. Any medium capable of storing instructions (e.g. mobile payment device instructions 324) that can be executed by the machine, and that causes the machine to perform any of the methods disclosed herein, shall also be considered a machine-readable medium. “Machine-readable medium” is a term that refers to any media that can store instructions (e.g., mobile payment device instructions 324) for execution by the machine and that cause the machine to perform any one or more of these methodologies. This includes but is not limited to data repositories that are made up of solid-state memories, optical and magnetic media.

“The mobile payment device instructions 324, e.g. software, may be transmitted over the network310 via the network interface device 322. One embodiment of the network 310 is an Internet. The network 310 may also use dedicated or private communication links that aren’t necessarily part of the Internet. The network 114 can use standard communication technologies and/or protocols in one embodiment. The network 114 may include links that use technologies such as Ethernet and Wi-Fi (802.11), integrated digital network (ISDN), digital subscriber (DSL), asynchronous transport mode (ATM), and others. The network 114’s networking protocols can also include multiprotocol label shifting (MPLS), transmission control protocol/Internet protocol TCP/IP, hypertext transport protocol HTTP, simple mail transfer protocol SMTP, file transfer protocol FTP, and others. One embodiment uses mobile networking technologies for at least some links, such as general packet radio service, enhanced data GSM environment, (EDGE), code Division Multiple Access 2000 (CDMA2000) and/or wide band CDMA (WCDMA). Data exchanged over network 114 may be represented using various technologies and formats, including hypertext markup languages (HTML), extensible markup languages (XML), wireless access protocol (WAP), short message service (SMS), etc. All or part of the links can also be encrypted with conventional encryption technologies like Secure HTTP, Secure Sockets Layer (SSL), and/or Virtual Private Networks (VPNs). Another embodiment allows entities to use customized and/or specific data communication technologies in place of or in addition the ones mentioned above.

The example computer machine 300 contains a mobile network enabled unit 325. This includes the logic software (SLEE?) and hardware to connect to any node of a mobile network operator, including any messaging node such as a short message center (SMSC), a multi-media message center (MMSC), and mail transport/transfer agent(MTA), wireless access protocol [WAP], gateway GPRS (general packet wireless service) support node GGSN), combined GPRS center (CGSN), and any other, infrared, radio (short wave or another), and other), and other), and other), and other, infrared, infrared, Bluetooth, WiFi, WiMax, Bluetooth, WiFi, WiMax Mobile network enablement unit 325 supports all communication protocols and standards including but not limited to instant messaging service (IMS), signaling system 7 (SS7), internet protocol (IP), transport/transmission control protocol (TCP), transaction capabilities application part (TCAP), intelligent network application protocol (INAP), mobile application part/multiple access protocol (MAP), CS1, CS2, CS3, CS4, common alerting protocol version 1 (CAP v1), CAPv2, CAPv3, CAPv4, all wireless intelligent network (WIN) standards, all intelligent network (IN) standards and all advanced intelligent network (AIN) standards, etc. One embodiment of the mobile network enablement device 325 connects to a mobile operator network 311. The mobile operator network 311 can include CDMA, WCDMA and iDEN. It also includes GSM, CDMA, WCDMA and future revisions of wireless communications system.

Referring to FIG. “Referring now to FIG. 4, it illustrates the high-level block diagram for a computing environment that allows a mobile device to initiate transactions according to one embodiment. A computing environment could include a mobile device (102), a mobile enablement centre 106, an register of payment processor servers 108, 110, and merchant 104.

“FIG. “FIG. FIGS. FIGS. 4 and 5 will be discussed below concurrently.

“As explained in more detail above, the mobile device102 initiates a transaction by sending a merchant identification to the mobile enablement centre 106 or the payment processor server 110. The payment processing server 110 receives 502 a merchant ID and then sends 504 an information request to the merchant that is associated with the merchant ID. Any communication method (COMM), as described above, can be used to communicate directly with merchant 104. The payment processing center may send an SMS, an e mail message, etc. to a merchant’s phone number or email address 104. One embodiment allows the merchant ID to be linked with a unique point-of sale terminal. The payment processing server 110 could send a communication to that point-of-sale terminal in such an instance. To communicate with the point-of-sale terminal, the payment processing server 110 may also use the well-known ISO8583 interface.

“Service data point (also known as SDP) refers to a computing machine that has, for example, all components described in 300. It is used by telecommunication operators to store subscriber account balances, service subscriptions, service expirations, and other information. Although SDPs can have multiple names in different vendor and operator environments, this disclosure refers to all SDPs that are equivalent in function.

The SDP may be used in one embodiment for financial, investment, and/or insurance operations. This includes keeping track of account balances and debiting and crediting accounts as well as transferring funds from one account into another. An SDP Register or centralized SDP can be used for routing information to specific SDP signals. An embodiment of an SDP Register can be managed and controlled by a consortium or governmental body.

“In one embodiment, the SDP communicates to financial institutions 116. ATM machines, point-of-sale terminals, mobile enablement centers 106, and/or merchants 104 for the purpose processing point-of sale transactions with financial institution or payment processing servers 110. SDP supports any standard data communication protocol or data security standards, such as International Standards Organization (ISO 8583), simple object access protocol/extensible Markup Language (XML), SOAP, and hypertext transfer protocol(HTTP), secure sockets layers (SSL), etc.

“In one embodiment, the payment processor 110 identifies 504 as a service point (SDP), responsive to a mobile number provided by the device 102. The phone number refers to a customer number that is associated with the customer’s bank account. It is controlled by SDP. The service data point 412 stores customer phone numbers in addition to customer information. It is also where the customer’s account information can easily be retrieved using the phone number. The service data point 412 may be used in one embodiment to manage financial institution accounts.

“In one embodiment, the payment processor server cannot identify the appropriate SDP based upon the provided account number. In such an instance the payment processing system sends an Interrogation Request to the Registry of SDPs 414 in order to identify 504 the SDP associated to the customer’s account number. The registry of SDPs 414, which provides routing information for an SDP 412 associated to the customer’s bank account, gives this information.

“Once the appropriate SDP 412 has been identified, the payment processing servers interrogates it to obtain 506 account information associated the customer’s telephone number. The SDP 412 can retrieve account data associated with the customer?s phone number.

“The payment processing server 110 sends 508 transaction information requests to the merchant. The merchant ID is used as the merchant ID. The merchant can respond to the request by sending transaction information to the payment processor server. One embodiment of the method is that the payment processing server receives transaction information from the merchant via communications methods known in the arts. The transaction information may include the total price of the item, the account number associated with merchant, and the customer’s mobile number. To provide transaction information to the payment processing servers 110, the merchant 104 may use any communication method (COMM), which is known to art. One embodiment allows the merchant to enter the total amount of the purchase on the keypad of a point-of sale terminal.

“As mentioned above, in one embodiment the payment processing server 110 sends to 512 an authorization request the mobile device that initiated the transaction request. The payment processing server 110 can send a COMM (an SMS message or an email) to the customer’s phone number or to the email address that initiated the transaction. One embodiment of the payment processing server 110 sends 512 the account number and name to the mobile device. This is in addition to the authorization request. Another embodiment allows the customer to provide both a customer’s phone number and a different communication phone number. The customer can initiate a transaction by providing an account number. To initiate the transaction in such an instance, the customer could use the application running on the communications mobile device (102), or use COMM messaging. In such an example, the payment processing server 110 sends to 512 an authorization request at the communications number. The customer can then provide authorization associated with the account number.

“In one embodiment, the payment processing system 110 receives 514 authorization messages from a mobile device. An authorization message may include a customer’s personal identification number (PIN). Customers can create multiple PINs to be used for different accounts. A customer may set up a PIN to limit purchases below a certain dollar amount, and another PIN to limit purchases above a dollar amount. The customer can also set up a different PIN for specific merchants. A different PIN can be created by the customer in another embodiment. This is a unique PIN that expires after the first use. It applies when the communication phone number used to initiate the transaction is different than the one associated with the customer. One embodiment allows the mobile device 102 to erase all PINs from its on-board and off-board memory. The authorization PIN is received by the payment processing server 110 via a communications network. A customer can use a different communications number than their account number to create a one-time password or a PIN that expires after the first use. A customer may, for example, set a one-time password that expires after the first use. This can be used for purchases exceeding a certain amount or purchases made with a specific merchant.

“Once the correct authorization code, e.g. a PIN, is received from the mobile phone 102, the payment processing servers executes the requested transaction using the SDP 412. The SDP 412 update the customer’s account information. The transaction confirmation is sent by the payment processing server 110 to the mobile device (102) and the merchant (104). In one embodiment, the payment processor 110 sends 518 transaction confirmations to the merchant 104 and the mobile device 102. 518 confirmations can be sent using any communication method (COMM), including an SMS message, email address or phone call. One embodiment of the method is that the payment processing server 110 sends 518 confirmations to the point-of-sale terminal associated the merchant ID. In this case, the point of sale terminal can print a copy for the merchant or customer. If the communication phone number of the customer is different from the one associated with the transaction account’s transaction account, the payment processing servers 110 send 518 a transaction verification to either one or both numbers. You can include information about the transaction, such as the date and time, transaction amount, etc. in the confirmation communication.

“FIG. “FIG. 6 illustrates a block diagram that shows a high-level computing environment to use a mobile device to perform a transaction according one embodiment. A computing environment could include a mobile device (102), a payment processing system 110, a merchant (104), and a financial institution (116).

“FIG. 7 is a flowchart that illustrates a method for using a mobile device in order to initiate a transaction using service data points according to one embodiment. FIGS. FIGS. 6 and 7 will be discussed below concurrently.

The merchant initiates the point-of-sale in one embodiment of the described system and method. One embodiment uses a point-of-sale terminal that is associated with the merchant 104 to enter and transmit point of sales information, such as transaction amount and communications phone number. An account phone number refers to a number that is associated with a financial institution. A customer may, for example, choose to have a specific phone number associated with a certain account at a financial institution. You can have a credit, debit, savings, or payroll account. An account can have a communications number, which is the number associated with the customer. Another example is that the communications number can be different from an account number. This allows a customer to borrow a phone and execute a transaction. If a customer loses or forgets his mobile phone, they can request that a communication is sent to the number associated with the borrowed telephone. Other embodiments allow the customer to provide either a communications email address, or an account email address, wherein the email account is linked with the customer’s financial institution account.

“In one embodiment, payment processing server 110 receives 702 point-of-sale information from merchant 104. The merchant 104 provides the payment processing server 110 with 704 authorization requests. In one embodiment, the payment processor 110 sends 704 authorization requests to the customer’s account number or communications phone number. One embodiment of the payment processing server 110 sends a SMS message, COMM or email to the number or email address that initiated the transaction. One embodiment of the payment processing server 110 is capable of sending 704 an account number and name to the mobile device102 together with the authorization request. The payment processing server 110 can list all accounts that the customer has access to, such as credit and debit accounts associated with a phone number. In this case, the payment processing server 110 opens data sessions to the mobile device 102, and presents a menu from which the customer can select the account they wish to use to complete the transaction. Another embodiment uses the payment processing server 110 to open a USSD menu option, if it is available, or a WAP Push message with multiple links denoting different accounts. This allows the client to communicate with the server via the mobile device 102. In such cases, the customer can also enter the authorization PIN for the account they wish to use to complete the purchase. Another embodiment requests one PIN from the payment processing system, even if multiple accounts have been associated with the account number. The customer can then enter the authorization pin for the account they wish to use to complete the purchase. Based on the authorization PIN matching one of the accounts associated with the account number, the payment processing server 110 will identify a credit account or debit account.

“In one embodiment, the customer may enter and send a message (to the payment processing server 110) to authorise the transaction. 706 authorizations are received by the payment processing server 110 from a mobile device. An authorization message may include a personal identification code (PIN), associated with the customer’s account. Customers can create multiple PINs to be used for different accounts. A customer may set up a PIN to limit purchases below a certain dollar amount, and another PIN to limit purchases above a dollar amount. The customer can also set up a different PIN for specific merchants. A customer can also use a one-time password or a PIN that expires after the first use. This is possible when using a different communications number than their account number. A customer may, for example, set a one-time password that expires after the first use for any purchases exceeding a certain amount or with a specific merchant. One embodiment of this invention is that the mobile device 102 associated to the communications number is configured so that all PINs from the mobile devices’ off-board or on-board memory are deleted. The payment processing server 110 receives 706 authorization PINs from customers via a communications network.

“In response to the customer’s authorization, the payment processing servers 110 receives 706 authorizations from the mobile device. The payment processing server executes 708 point-of-sale transactions with financial institutions associated to the customer and merchant 104, as described in more detail above. After the transaction has been completed 708, the payment processing servers sends the merchant 104 a confirmation. This includes the communication as well as the account number. In one embodiment, the payment processor 110 sends 710 transaction confirmations to the merchant 104 and the mobile device 102. You can send 710 confirmations using any communication method (COMM), including an SMS message, email address or phone call. One embodiment of the method is that the payment processing server 110 sends 710 confirmations to the point-of-sale terminal associated the merchant ID. The point-of-sale terminal may print a copy for the merchant or customer. If the communication phone number of the customer is different from the one associated with the transaction account’s transaction account, the payment processing servers 110 send 710 a transaction verification to either one or both numbers. You can include information about the transaction, such as the date and time, transaction amount, etc. in the confirmation communication.

Referring to FIG. 8 illustrates a high level block diagram of a computing ecosystem for using a mobile phone to execute a transaction associated to a sub-account in accordance with one embodiment. A computing environment could include a mobile device, an SDP 412 account, a sub-account and an account associated to the mobile number 812.

“FIG. “FIG. 9 is a flowchart that illustrates one method for using a mobile device in order to execute a transaction associated to a sub-account. FIGS. FIGS. 8 and 9 will be discussed below concurrently.

“As explained in more detail above, the merchant 104 or the mobile device 102 can initiate a transaction by sending a merchant number and an account phone number (SDP) 412. One embodiment of the SDP receives 902 transaction requests either from merchant 104 or mobile device 102. One embodiment of the SDP’s interrogation 904 is to determine if the account phone number received is associated with a subaccount. A sub-account 812 may be associated with a parent account 810. The sub-account might have restricted access to funds in the parent account 810, or the account associated to the mobile number. If the SDP finds that an account phone number is associated to a subaccount, it will provide that a subaccount criteria has been matched 906.

“In other embodiments the sub-account criteria may be matched 906 in another way. A sub-account can also be associated with a phone number. If a communications number matches the sub account 812 criteria, then the SDP 912 executes a transaction with that sub-account upon receiving authorization. An authorization PIN may also be associated with a sub account in other embodiments. The SDP will send an authorization request to the appropriate communications phone number, one or more associated with the sub account, or the parent account 810. The authorization request can be sent by the SDP, or the payment processing servers 110 to 908, for example, to the account phone number associated the parent account 810, or the phone number associated the sub-account. A customer can also create a sub-account to allow family members, such as children, to make purchases on their mobile devices. In a similar fashion, a parent can approve or reject certain purchases made by the sub-account holder in real time via an authorization request sent to a number associated with the parent 810.

“As explained above, the payment processing servers 110 send 908 authorization requests to the appropriate mobile devices 102, including the one that initiated the transaction, or to the phone number associated to the parent account 810. The payment processing server 110 can send an SMS message, an email to the provided phone numbers, or an email address. One embodiment of the payment processing server 110 sends 908 the account number and account name to the relevant mobile device 102 together with an authorization request. Another embodiment allows the customer to provide both a customer’s phone number and a different communication phone number. The customer can initiate a transaction by providing an account number and initiating communication from another number. To initiate the transaction, the customer can either use COMM messaging or an application running on the communications mobile device. In such an example, the payment processing server 110 sends 908 a authorization request to the communications number. The customer can then provide authorization associated with the account number.

“The SDP may receive 910 authorization from the subaccount phone number. The communications phone number and the number associated with the parent 810 account. An authorization message may include a customer’s personal identification number (PIN). Customers can create multiple PINs to be used for different accounts. A customer may set up a PIN to limit purchases below a certain dollar amount, and another PIN to limit purchases above a dollar amount. The customer can also set up a different PIN for specific merchants. A different PIN can be created by the customer in another embodiment. This is a unique PIN that expires after the first use. It applies when the communication phone number used to initiate the transaction is different than the one associated with the customer. One embodiment allows the mobile device 102 to erase all PINs from its on-board and off-board memory. The payment processing server 110 is able to receive 910 the authorization pin from the customer via a communications network. A customer can use a different communications number than their account number to create a one-time password or a PIN that expires after the first use. A customer may, for example, set a one-time password that expires after the first use. This can be used for purchases exceeding a certain amount or purchases made with a specific merchant.

“The SDP may initiate the execution of the transaction between customer and merchant 104. The SDP will execute 914 the transaction with the parent account 810 if it does not have the appropriate authorization. A transaction confirmation is sent to merchant, communications phone number, account phone number, or sub-account number.

“FIG. “FIG. A computing environment could include a mobile device (102), a mobile enablement centre 106, a register payment processing servers 110, a merchant (104), a service point 112, a registry of service points 114, and a financial institution (116).

“In one embodiment, the SDP could manage an aggregate account (also known as a Nostro Account in a bank that contains multiple sub accounts that can be used to represent payroll accounts. These payroll accounts can be used by those who are unable to open an account themselves due to insufficient funds or poor credit. If they are linked to a mobile number, such aggregate accounts can be accessed via any payment processing server 110 and SDP. Multiple virtual accounts can be created from one subaccount of an aggregate account. A worker without a bank account might ask his employer to open a subaccount to deposit payroll directly. The worker’s mobile number would be associated with the subaccount. A worker could create virtual sub-subaccounts via the SDP and transfer funds to these sub-subaccounts. Each sub-subaccount could be linked to a mobile phone. They can be accessed via any mobile enablement center (106) or payment processing server 110. The SDP may be used to replace or perform functions performed by the mobile enablement centre in one embodiment. One embodiment of the SDP allows fund transfer control between banks, merchants and phone accounts.

“FIG. “FIG. 11. is a flowchart that illustrates one method for using a payroll card in order to execute a transaction. FIGS. FIGS. 10 and 11 will be discussed simultaneously below.

“In the embodiment described in reference to FIGS. 10, 11 and 10 respectively, the point-of-sale transaction is initiated either by a merchant (104) or a mobile device (102), wherein the account number is associated to a payroll card 1002. A payroll card 1002 is a debit card that can be linked to a payroll account. The payroll card 1002 can be used by the customer’s employer to deposit payroll checks into the account. Instead of sending a customer a weekly, biweekly, or monthly payroll check that can be cashed or deposited or sent to them, the employer can deposit weekly, biweekly, or monthly payroll checks to the payroll account. This will eliminate the need for the employer to issue new payroll checks every payroll cycle. This system reduces the cost for employers to issue checks. Employees also benefit from such a system because they can access a card account that is associated with the card. This allows them to purchase without opening new accounts or credit lines with other financial institutions. Each payroll account can also be linked to a payroll trust account. A payroll trust account is a group of accounts that an employer uses to make payments to each employee’s individual payroll account. Payroll trust accounts are generally non-renewable and have a float. The trust account can be used to lend funds to customers if funds in their customer payroll accounts run out. This is an added benefit, which will be explained in more detail below. The payroll trust account may withhold money due from employees in the next payroll period. You can withhold money from the borrow money, all of it, or just a portion.

“In one embodiment, the payment processor server receives 1102 requests to execute transactions from an account associated the payroll card 1002. A merchant may swipe or enter the account number associated to the payroll card at a point-of-sale terminal. A firmware update can be applied to the terminal to allow customers to use their payroll card to make purchases. A mobile device can also be used to initiate point-of-sale transactions. The mobile device can transmit a merchant identification and account number to a service data center (SDP) 412 as well as a mobile enablement centre 106. A second embodiment is that the customer can borrow a device for a mobile computing purpose to start a point-of-sale transaction.

The SDP receives the request and sends 1104 authorization information to the mobile number associated with the communications number or payroll account. In one embodiment, the SDP412 sends 1104 authorization requests to the mobile device number 102 that is associated with the payroll account. The SDP 412 can send a COMM, SMS, or email to the customer’s phone number or email address associated with the payroll accounts. One embodiment of the SDP 412 allows the sending of 1104 account numbers and names to the mobile device 102. This authorization request can also be sent by the SDP 412. A different embodiment of the authorization request can be sent by the payment processing server to a communications phone number other than the one associated with the payroll account. In the communication 1102 containing information about the payroll account, a communications number can be provided to enable a transaction to be executed. To initiate the transaction, the customer can use an app executing on a mobile device (102 associated with the communications number).

“In one embodiment, SDP 412 receives 1106 authorization from a mobile device102. An authorization message may include a personal identification code (PIN), which can be associated with the customer’s account. Customers can create multiple PINs to be used for different accounts. A customer may set up a PIN to limit purchases below a certain dollar amount, and another PIN to limit purchases above a dollar amount. The customer can also set up a different PIN for specific merchants. A different PIN can be created by the customer in another embodiment. This is a unique PIN that expires after the first use. It applies when the communication phone number used to initiate the transaction is different than the one associated with the customer. One embodiment allows the mobile device 102 to be configured to erase all PINs from any of its on-board or offline memory. The SDP 412 is able to receive 1106 authorization PINs from customers via a communications network. A customer can use a different communications number than their account number to create a one-time password or a PIN that expires after the first use. A customer may, for example, set a one-time password that expires after the first use. This can be used for purchases exceeding a certain amount or purchases made with a specific merchant.

“An SDP logic determines if the payroll account has sufficient funds 1108 for the transaction requested. If the answer is yes, the SDP executes 1112 a transaction with a bank associated to the payroll card. If the SDP finds that the payroll account is not in sufficient funds, the SDP executes 1110 transactions with the payroll trust account. After the transaction is completed, a transaction confirmation will be sent to the merchant and the mobile phone associated with the payroll account. One embodiment sends 1114 transaction confirmations to the mobile device (102, 104), and the merchant (104). You can send 1114 confirmations using any communication method (COMM), including an SMS message, an email address or a telephone call. One embodiment sends 1114 confirmations to the point-of-sale terminal associated the merchant ID. In this case, the point of sale terminal can print a copy for the merchant or customer. If the communication phone number of the transaction account is different from the one used to confirm the transaction, the SDP 412 will send 1114 a confirmation message to either one or both numbers. You can include information about the transaction, such as the date and time, transaction amount, etc. in the confirmation communication.

“While certain embodiments and uses of the invention have been described and illustrated herein, it should be understood that the invention does not limit itself to the construction and components listed herein. Various modifications, changes and variations can be made to the operation and details of the methods or apparatuses of this invention without departing completely from the spirit and scope thereof as defined in the appended claims.

Click here to view the patent on Google Patents.

How to Search for Patents

A patent search is the first step to getting your patent. You can do a google patent search or do a USPTO search. Patent-pending is the term for the product that has been covered by the patent application. You can search the public pair to find the patent application. After the patent office approves your application, you will be able to do a patent number look to locate the patent issued. Your product is now patentable. You can also use the USPTO search engine. See below for details. You can get help from a patent lawyer. Patents in the United States are granted by the US trademark and patent office or the United States Patent and Trademark office. This office also reviews trademark applications.

Are you interested in similar patents? These are the steps to follow:

1. Brainstorm terms to describe your invention, based on its purpose, composition, or use.

Write down a brief, but precise description of the invention. Don’t use generic terms such as “device”, “process,” or “system”. Consider synonyms for the terms you chose initially. Next, take note of important technical terms as well as keywords.

Use the questions below to help you identify keywords or concepts.

• What is the purpose of the invention Is it a utilitarian device or an ornamental design?
• Is invention a way to create something or perform a function? Is it a product?
• What is the composition and function of the invention? What is the physical composition of the invention?
• What’s the purpose of the invention
• What are the technical terms and keywords used to describe an invention’s nature? A technical dictionary can help you locate the right terms.

2. These terms will allow you to search for relevant Cooperative Patent Classifications at Classification Search Tool. If you are unable to find the right classification for your invention, scan through the classification’s class Schemas (class schedules) and try again. If you don’t get any results from the Classification Text Search, you might consider substituting your words to describe your invention with synonyms.

3. Check the CPC Classification Definition for confirmation of the CPC classification you found. If the selected classification title has a blue box with a “D” at its left, the hyperlink will take you to a CPC classification description. CPC classification definitions will help you determine the applicable classification’s scope so that you can choose the most relevant. These definitions may also include search tips or other suggestions that could be helpful for further research.

4. The Patents Full-Text Database and the Image Database allow you to retrieve patent documents that include the CPC classification. By focusing on the abstracts and representative drawings, you can narrow down your search for the most relevant patent publications.

5. This selection of patent publications is the best to look at for any similarities to your invention. Pay attention to the claims and specification. Refer to the applicant and patent examiner for additional patents.

6. You can retrieve published patent applications that match the CPC classification you chose in Step 3. You can also use the same search strategy that you used in Step 4 to narrow your search results to only the most relevant patent applications by reviewing the abstracts and representative drawings for each page. Next, examine all published patent applications carefully, paying special attention to the claims, and other drawings.

7. You can search for additional US patent publications by keyword searching in AppFT or PatFT databases, as well as classification searching of patents not from the United States per below. Also, you can use web search engines to search non-patent literature disclosures about inventions. Here are some examples:

• Add keywords to your search. Keyword searches may turn up documents that are not well-categorized or have missed classifications during Step 2. For example, US patent examiners often supplement their classification searches with keyword searches. Think about the use of technical engineering terminology rather than everyday words.
• Search for foreign patents using the CPC classification. Then, re-run the search using international patent office search engines such as Espacenet, the European Patent Office’s worldwide patent publication database of over 130 million patent publications. Other national databases include:
• European Patent Office (EPO) provides esp@cenet to access a network of Europe’s patent databases with access to machine translation of European patents. 
• Japan Patent Office (JPO) – with access to machine translations of Japanese patents.
• World Intellectual Property Organization (WIPO) offers PATENTSCOPE with a full-text search of published international patent applications and machine translations for some documents, as well as a list of international patent databases.
• Korean Intellectual Property Rights Information Service (KIPRIS)
• State Intellectual Property Office (SIPO) with machine translation of Chinese patents.
• Other International Intellectual Property Offices with online patent databases include Australia, Canada, Denmark, Finland, France, Germany, Great Britain, India, Israel, Netherlands, Norway, Sweden, Switzerland, and Taiwan.
• Search non-patent literature. Inventions can be made public in many non-patent publications. It is recommended that you search journals, books, websites, technical catalogs, conference proceedings, and other print and electronic publications.

To review your search, you can hire a registered patent attorney to assist. A preliminary search will help one better prepare to talk about their invention and other related inventions with a professional patent attorney. In addition, the attorney will not spend too much time or money on patenting basics.

Download patent guide file – Click here