This application claims priority from united states provisional application No. 61/279,322, filed on 10/19/2009, which is incorporated herein by reference in its entirety.
Detailed Description
Preferred embodiments of the present invention will now be described with reference to the figures, where like reference numbers indicate identical or functionally similar elements. Also in the figures, the left-most digit(s) of each reference number corresponds to the figure in which the reference number is first used.
Reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase "in one embodiment" or "an embodiment" in various places in the specification are not necessarily all referring to the same embodiment.
Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps (instructions) leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, electromagnetic, radio, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It is convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. Furthermore, it is also convenient at times, to refer to particular arrangements of steps requiring physical manipulations or transformation of physical quantities or representations of physical quantities as modules or code devices, without loss of generality.
However, all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the written description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or "determining" or the like, refer to the action and processes of a computer system, or similar electronic computing device (such as a specific computing machine), that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.
Certain aspects of the invention include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions of the present invention could be embodied in software, firmware or hardware, and when embodied in software, could be downloaded to reside on and be operated from different platforms used by a variety of operating systems. The present invention may also be considered a computer program product for execution on a computing system.
The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the purposes of a particular computer, for example, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), Random Access Memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, Application Specific Integrated Circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. The memory may include any of the above and/or other devices that may store information/data/programs. Further, the computers referred to in this specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the method steps. The structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein, and any references below to specific languages are provided for disclosure of enablement and best mode of the present invention.
Moreover, the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.
FIG. 1 is a high-level block diagram illustrating a computing environment for initiating a transaction using a mobile device, according to one embodiment. The computing environment may include a mobile device 102, a mobile support center 106, a register of payment processing servers 108, a payment processing server 110, a merchant 104, and a financial institution 116.
FIG. 2 is a flow diagram illustrating a method of initiating a transaction using a mobile device according to one embodiment. For purposes of discussion, fig. 1 and 2 are discussed concurrently below.
In one embodiment, the mobile device 102 initiates a point-of-sale transaction. Mobile device 102 may include any computing device having a processor and capable of communicating with others over a network or a communication link. Examples of mobile device 102 include a cellular phone, a Personal Digital Assistant (PDA), a smart phone, a laptop computer, a desktop computer, or other device. The mobile device sends a merchant ID associated with the merchant to the payment processing server 106. The merchant ID number is a unique identifier associated with the merchant. The merchant ID may include any information used to identify or communicate with the associated number. For example, the merchant ID may include a point-of-sale terminal ID to be used by the merchant to perform the transaction. In other embodiments, the merchant ID may include an email address or phone number associated with the merchant.
In one embodiment, the consumer may enter the merchant ID on the mobile device 102 using an input system of the mobile device, such as a keyboard or touchpad. In other embodiments, the merchant ID information may be received by a camera on mobile device 102. In other embodiments, the merchant ID information may be displayed in a flat view for use by the consumer. In other embodiments, the merchant ID information may be displayed in alphanumeric or bar code format for use by the consumer. In other embodiments, the merchant ID information may be received by the mobile device 102 over a communication link, such as a bluetooth communication or RFID communication domain. For example, a merchant may have a point-of-sale terminal that broadcasts a merchant ID to a mobile device via a bluetooth, laser, radio, infrared, or small-range electromagnetic field communication link. In one embodiment, mobile device 102 sends the received merchant ID to the other party over a communication network.
The mobile device 102 may send the merchant ID to the mobile support center 106 using any available Communication (COMM) method. Which may use Unstructured Supplementary Service Data (USSD), Short Message Service (SMS), Multimedia Message Service (MMS), IVR, email, short message peer-to-peer (SMPP), internet browser, applications executing on a mobile device, applets executing on a computing device, hard buttons (push buttons), soft buttons (push buttons), or any communication method available in the art in a variety of wired or wireless technologies, such as but not limited to Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Integrated Digital Enhanced Network (iDEN), global system for mobile communications (GSM), one or more generations of wireless telephony technologies such as 2G, 3G, 4G, or any future generation of wireless telephony technology, bluetooth, WiFi, Worldwide Interoperability for Microwave Access (WiMAX), radio (short wave or other), infrared, or any other communication method or protocol known in the art. Such communications, or other examples of communications, are referred to herein as COMMs, among other names.
The mobile device 102 may send the merchant ID to the mobile support center 106 using any available communication method (COMM). In one embodiment, the mobile device 102 may send the merchant ID in an SMS message over a mobile communication network, such as a GSM, iDEN, or CDMA network that may be 2G, 3G, 4G, or any setting of future evolution of wireless technology. In other examples, the mobile device may send a Multimedia Message (MMS). For example, a consumer may take a photograph of a barcode or numeric identifier associated with a merchant ID and send the photograph over a communication network. In another example, an application executing on the mobile device 102 can parse or identify a barcode or numeric identifier associated with the merchant ID for transmission over the communication network. In other embodiments, the communication network used by the mobile device 102 depends on the network capabilities of the mobile device 102. For example, the mobile device may connect to a WiFi network and send the merchant ID to the payment processing server 110 via email over the network. In one embodiment, the consumer may enter the merchant ID from the landline phone via the IVR. In other embodiments, the consumer may send the merchant ID to the mobile support center 106 over a communications network using a user interface associated with an application executing on the mobile device 102. The network used to connect the mobile device 102, merchant 104, mobile support center 106, payment processing server 110, service data points 112, and financial institution 116 is described in more detail below.
In one embodiment, the merchant ID is sent to the appropriate payment processing server 110. For example, a consumer may provide pre-set preferences where all transactions performed with the mobile device 102 are associated with a particular financial institution and routed through a particular payment processing server 110. In one embodiment, the communication request may be routed to the appropriate payment processing server 110 using the IPV6 protocol. In another embodiment, mobile device 102 sends the merchant ID to be routed to the appropriate payment processing server 110 to mobile support center 106 through a communications network.
Mobile support center 106 is a platform that routes outgoing messages from mobile device 102 to the appropriate payment processing server 110. The mobile support center 106 may receive routing requests from several service broadcast operators, such as mobile phone network operators, including GSM or CDMA network operators, fixed phone operators, LAN operators, and the like. For example, when a mobile device 102, including a landline or VOIP phone, sends an outgoing message, a service broadcast operator associated with the device or phone number receives the outgoing message request. The serving broadcast operator routes the outgoing message to a broadcast operator associated with the intended recipient of the message. In an embodiment of the present invention, the mobile support center 106 receives the routing request from a service advertisement operator associated with the mobile device 102 or directly from the mobile device 102. In one embodiment, mobile support center 106 routes the message to the appropriate payment processing server 106 based on the phone number of the outgoing message, the phone number of the intended recipient, the merchant ID included in the message, or any other data associated with the phone number. For example, if the user's telephone number is associated with a particular financial institution 116, mobile support center 106 routes the message to a payment processing server 110 associated with the financial institution 116.
In one embodiment, the payment processing server 110 queries the registry 108 of the payment processing server to identify the appropriate payment processing server 110. For example, the payment processing server's registry 108 may include an enumeration of payment processing servers 110 based on routing numbers or other identifying information associated with each financial institution or based on collaborative new routing mechanisms that may be entrusted, planned or regulated, for example, by a standardized body, a government body or a consortium body of a company or leader in the field.
The payment processing server 110 is a platform for performing transactions between consumers, financial institutions 116 associated with the consumers, and merchants 104. Examples of payment processing servers 110 include databases maintained by Visa, MasterCard, American Express, and the like. In one embodiment, the payment processing server 110 receives 202 a merchant ID from the mobile device 102. In another embodiment, the payment processing server 110 receives 202 the merchant ID in a message routed by the mobile support center 106.
In one embodiment, the payment processing server 110 sends 204 a request for transaction information to the merchant 104 associated with the received merchant ID. Any communication method (COMM) known in the art may be used to communicate with the merchant 104. For example, the payment processing center may send an SMS message, an email message, or the like to a phone number or email address associated with the merchant 104. In one embodiment, the merchant ID may be associated with a unique point-of-sale terminal of the merchant. In such a case, the payment processing server 110 may send a communication to the point of a particular point of sale terminal.
The merchant 104 may provide transaction information to send to the payment processing server 110. The transaction information may include a purchase total for the item that the consumer wants to purchase, an account number associated with the merchant, a mobile phone number provided by the consumer, and the like. The merchant 104 may provide the transaction information to the payment processing server 110 using any communication method (COMM) known in the art. In one embodiment, the merchant may enter the purchase total on a keypad of the point-of-sale terminal. The point-of-sale terminal may include a station at which the merchant may swipe or key in the consumer's credit or debit card to perform a purchase transaction. In another embodiment, the point-of-sale terminal may include a computing device, such as a computer-to-computer (M2M) device, a mobile phone, a laptop or desktop computer, a tablet computer, or the like. In other embodiments, the point-of-sale terminal may comprise an established transaction terminal, such as an ATM or vending machine, or the like. In the case of using an existing transaction terminal such as an ATM or a card swipe terminal, the terminals may be updated via firmware update to enable them to receive transaction information requests from the payment processing server 110.
The payment processing server 110 receives 206 transaction information from the merchant 104. In one embodiment, the transaction information includes a phone number associated with the consumer mobile device 102. The payment processing server 110 authenticates the phone number associated with the mobile device 102. In one embodiment, the payment processing server 110 authenticates the phone number of the incoming message to the service broadcast operator network. For example, if the MOBILE phone number is associated with a T-MOBILE, the payment processing server 110 may query the T-MOBILE operator network 311 to identify an account associated with the MOBILE phone number.
In another embodiment, the payment processing server 110 queries a register of data points 414, as described in more detail below. In response to the query, the payment processing server 110 receives account information associated with the phone number of the mobile device 102 or the identity of the mobile support center 106 associated with the phone number of the mobile device 102. In one embodiment, payment processing server 110 queries mobile support center 106. In response to receiving the query, mobile support center 106 queries register 108 of the payment processing server to obtain account information associated with the phone number of mobile device 102. Once the payment processing server 110 receives the appropriate account information, the payment processing server 110 communicates with the mobile support center 106 associated with the phone number of the mobile device 102 and sends a transaction authorization request to the mobile device 102. In one embodiment, the payment processing server 110 sends a transaction authorization to the merchant 104. As described in more detail below, upon receiving a positive transaction authorization from the mobile device 102 or merchant 104, the payment processing server 110 initiates a transaction with the financial institution 116 associated with the account number.
As described above, the payment processing server 110 may identify an account associated with the mobile phone number 102. In one example, more than one account may be identified as being associated with a mobile phone number. In such an embodiment, payment processing server 110 queries mobile support center 106. Mobile support center 106 identifies accounts associated with more than one account, such as virtual accounts or real accounts identified as being associated with the mobile phone number. In such a case, mobile support center 106 may use additional logic to identify an account from a list of possible accounts associated with the mobile phone number. For example, a user may provide that a debit account should be used for purchases below a certain dollar amount, such as $ 5. In another embodiment, the consumer may associate a particular account with a particular merchant for use in performing the transaction. Thus, the payment processing server 110 may identify the debit account if the merchant ID is associated with the retail merchant.
In one embodiment, the payment processing server 110 authenticates the merchant in response to receiving transaction information from the merchant. For example, the merchant may be authenticated if the merchant confirms the merchant ID or consumer mobile phone number that initiated the transaction. In one example, once the authentication process is complete, the payment processing server 110 identifies an account associated with the merchant.
In one embodiment, the payment processing server 110 sends 208 an authorization request to the mobile device 102 that initiated the transaction request. For example, the payment processing server 110 sends a COMM, SMS message, or email to the customer's phone number or email address that initiated the transaction. In one embodiment, the payment processing server 110 may send 208 the account name and number to the mobile device 102 along with the authorization request. In another embodiment, the consumer may provide a phone number associated with the consumer account and a different communication phone number. For example, a consumer initiating a transaction may provide an account phone number by initiating a communication from a different phone number. In such a case, the consumer may initiate a transaction using an application executing on the communication mobile device 102 or use COMM messaging. In such a case, the payment processing server 110 sends 208 an authorization request to the communication phone number, where the consumer may provide authorization associated with the account phone number. This may be applied to a consumer browsing the mobile devices of others to perform his or her own transactions.
In one embodiment, the payment processing server 110 receives 210 an authorization from the mobile device 102. The authorization message may include a Personal Identification Number (PIN) associated with the consumer's account. The consumer may set multiple PINs for one or more accounts. For example, the consumer may set a PIN for purchases below a preset dollar amount and a different PIN for purchases above a dollar amount. Similarly, the consumer may set a separate PIN for a particular merchant. In another embodiment, the consumer may have a different PIN (or one-time-use PIN that expires after the first use) when the communication telephone number from which the transaction is initiated is different than the telephone number associated with the consumer. In one embodiment, the mobile device 102 associated with the communications telephone number is configured to delete all PIN instances from the mobile device's on-board or off-board memory. In such a case, the payment processing server 110 receives 210 an authorization PIN from the consumer over the communications network. In another embodiment, a consumer using a communication phone number different from the account phone number may use a one-time password (a one-time-use PIN that expires after the first use). For example, a consumer may preset a one-time password (which expires after the first use) for purchases over a particular dollar value when the communication phone number is different than the account phone number, or for purchases with a particular merchant.
In one embodiment, the payment processing server 110 executes 212 a transaction with a financial institution. For example, the payment processing server 110 identifies a financial institution associated with the consumer's account and a financial institution associated with the merchant account, where performance of the transaction includes debiting the purchase amount from the consumer's account and crediting the purchase amount to the merchant account. In one embodiment, the surcharges credited by the financial institution 116, the payment processing server 110, the mobile support center 106 may be credited to the purchase account.
In one embodiment, the payment processing server 110 sends 214 a transaction confirmation to the mobile device 102 and the merchant 104. Such as an SMS message, an email address, a phone call, or any of the communication methods (COMM) described below with reference to fig. 3 may be used to send 214 the acknowledgement. In one embodiment, the payment processing server 110 sends a confirmation to the point-of-sale terminal associated with the merchant ID. In such a case, the point-of-sale terminal may print a confirmation copy for the merchant's or consumer's record. In the case where the communication telephone number is different from the telephone number associated with the transaction account, the payment processing server 110 sends 214 a transaction confirmation to one or both of the telephone numbers. The confirmation communication may include details regarding whether the transaction was successfully completed, the date and time of confirmation, the total transaction amount, and the like. In another case, if one mobile device is identified by the merchant as the preferred delivery mechanism for confirmation, the payment processing server 110 sends a transaction confirmation to the merchant's mobile device via the COMM.
FIG. 3 is a high-level block diagram illustrating a functional view of a typical computer system 300 used as one of the entities shown in the computing environment of FIG. 1, in accordance with one embodiment. It should be noted that the computing machine 300 may also be a system or a portion of a system, such as two or more machines operating together or one or more machines operating with one or more other devices.
Fig. 3 illustrates components of a machine capable of reading instructions from a machine-readable medium and executing them in one or more processors and/or controllers. In particular, fig. 3 shows a diagrammatic representation of a machine in which mobile payment device instructions 324 (e.g., software code) may be executed to perform any one or more of the methods discussed herein. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server machine or a client machine in server-client network environment, or as an endpoint machine in a peer-to-peer (or distributed) network environment.
The machine may be a server computer, a client computer, a Personal Computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a smart phone, a web appliance, a network router, switch or bridge, or any machine capable of executing the instructions 324 (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute instructions 324 to perform any one or more of the methodologies discussed herein.
The example computer machine 300 includes a processor 302 (e.g., a Central Processing Unit (CPU), or a group of processors, or a group of processing machines, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), one or more Application Specific Integrated Circuits (ASICs), one or more Radio Frequency Integrated Circuits (RFICs), or any combination of these), a memory 304 including a main memory and a static memory, a network interface device 320 capable of interfacing with a network 310, an input/output device 312 (e.g., a keyboard, a cursor control device, a Plasma Display Panel (PDP), a Liquid Crystal Display (LCD), a projector, or a Cathode Ray Tube (CRT)), and a storage unit 316 configured to communicate with each other via a bus.
The storage unit 316 includes a machine-readable medium 322 on which are stored mobile payment device instructions 324 (e.g., software) implementing any one or more of the methods or functions described herein. The mobile payment instructions 324 (e.g., software) may also reside, completely or at least partially, within the main memory 304 or within the processor 302 (e.g., within a processor's cache memory) during execution thereof by the computer system 300, the main memory 304 and the processor 302 also constituting machine-readable media.
External storage 317 includes a machine-readable medium on which mobile device or merchant information may be stored. In one embodiment, the machine 300 may access the external storage 317 via a communication link, as described above. In an embodiment, all components of machine 300 may access storage medium 317.
While the machine-readable medium 322 is shown in an example embodiment to be a single medium, the term "machine-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that are capable of storing the instructions (e.g., the mobile payment device instructions 324). The term "machine-readable medium" shall be taken to include any medium that is capable of storing 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 the methodologies disclosed herein. The term "machine-readable medium" includes, but is not limited to, data storage libraries in the form of solid-state memories, optical media, and magnetic media.
The mobile payment device instructions 324 (e.g., software) may be transmitted or received over the network 310 via the network interface device 320. In one embodiment, network 310 is the Internet. Network 310 may also utilize dedicated or private communication links that are not necessarily part of the internet. In one embodiment, the network 114 uses standard communication technologies and/or protocols. Thus, the network 114 may include links using technologies such as Ethernet, Wi-Fi (802.11), Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), Asynchronous Transfer Mode (ATM), and the like. Similarly, networking protocols used on the network 114 may include multiprotocol label switching (MPLS), transmission control protocol/internet protocol (TCP/IP), hypertext transfer protocol (HTTP), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), and so forth. In one embodiment, at least some of the links use mobile networking technologies including General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), code division multiple access 2000(CDMA2000), and/or wideband CDMA (wcdma). Data exchanged over the network 114 may be represented using technologies and/or formats including hypertext markup language (HTML), extensible markup language (XML), Wireless Access Protocol (WAP), Short Message Service (SMS), and so on. Further, all or some of the links may be encrypted using conventional encryption techniques, such as Secure Sockets Layer (SSL), secure HTTP, and/or Virtual Private Network (VPN). In another embodiment, the entities may use custom and/or dedicated data communication techniques instead of or in addition to those described above.
The example computer machine 300 includes a mobile network support unit 325 that includes a node for connecting to any mobile network operator, any messaging node (such as a Short Message Service Center (SMSC), a Multimedia Message Service Center (MMSC), a mail transfer/transfer agent (MTA), a Wireless Access Protocol (WAP), a Database (DB), (session description protocol) SDP, a Service Control Point (SCP), a Mobile Switching Center (MSC), a central office of wireline Communications (CO), a Service Switching Point (SSP), authentication, authorization, and access/finance (AAA), a GPRS gateway (general packet radio service) support node (GGSN), a merge GPRS node (CGSN), a Packet Data Service Node (PDSN), or a future revision, a data access point (GGSN), whether technology (CDMA, WCDMA, iDEN, GSM, 2G, 3G, 4G, or wireless communication systems is used, Bluetooth, WiFi, WiMAX, radio (short wave or other), infrared, or any other communication method or protocol known in the art) may exist in the logic software (SLEE-service logic execution environment) and hardware that interfaces, controls, and communicates with any other node in the operator's network. The mobile network supporting unit 325 supports all communication protocols and standards including, but not limited to, Instant Messaging Service (IMS), signaling system 7(SS7), Internet Protocol (IP), transmission/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 alert protocol version 1(CAP v1), CAP v2, CAP v3, CAP v4, all Wireless Intelligent Network (WIN) standards, all Intelligent Network (IN) standards, and all enhanced intelligent network (AIN) standards, and the like. In one embodiment, the mobile network support unit 325 communicates with the mobile operator network 311. As described in more detail above, the mobile operator network 311 includes CDMA, WCDMA, iDEN, GSM, 2G, 3G, 4G or future amendments of wireless communication systems.
Referring now to FIG. 4, there is illustrated a high-level block diagram of a computing environment for initiating a transaction using a mobile device, in accordance with one embodiment. The computing environment may include the mobile device 102, the mobile support center 106, the register of payment processing servers 108, the payment processing servers 110, the merchant 104, the service data point 412, the register of service data points 414, and the financial institution 116.
FIG. 5 is a flow diagram illustrating a method for initiating a transaction using a service data point using a mobile device according to one embodiment. For purposes of discussion, fig. 4 and 5 are discussed concurrently below.
As described in more detail above, mobile device 102 initiates the transaction request by sending a merchant ID to mobile support center 106 or payment processing server 110. The payment processing server 110 receives 502 the merchant ID and sends 504 a transaction information request to the merchant associated with the merchant ID. As described above, any communication method (COMM) known in the art may be used to communicate with the merchant 104. For example, the payment processing center may send an SMS message, an email message, or the like to a phone number or email address associated with the merchant 104. In one embodiment, the merchant ID may be associated with a unique point-of-sale terminal of the merchant. In such a case, the payment processing server 110 may send a communication to the point of a particular point of sale terminal. The payment processing server 110 may also communicate with the point of sale terminal using the well-known ISO8583 interface.
A service data point (also referred to as SDP) is, for example, a computing machine having all of the components described above in 300, which are typically used by telecommunications operators to store service logic as well as balance of user accounts, subscriptions, services, service expiration dates, etc. SDP has multiple names in different operator and provider environments, and for purposes of this disclosure, SDP refers to any and all of those nodes that are functionally equivalent to those described herein.
In one embodiment, the SDP may be used for banking, financial, investment, and/or insurance operations, such as keeping track of account balances, debiting accounts, crediting accounts, and transferring account funds from one account to another. A centralized SDP or SDP register may be used to provide routing information to signals destined for a particular SDP. In one embodiment, the SDP registers may be under the control, jurisdiction (sponsorship), of a government or financial group entity that will program its functionality and management.
In one embodiment, the SDP communicates with the financial institution 116, ATM machine, point-of-sale terminal, mobile support center 106, and/or merchant 104 for the purpose of processing point-of-sale transactions with the financial institution or payment processing server 110. For example, the SDP will support any standard data communication protocol, as well as data security standards, such as, but not limited to, International Standards Organization (ISO)8583, Simple Object Access Protocol (SOAP)/extensible markup language (XML), SOAP, hypertext transfer protocol (HTTP), Secure Socket Layer (SSL), etc.
In one embodiment, the payment processing server 110 identifies 504 a Service Data Point (SDP) in response to a phone number provided by the mobile device 102. The phone number is the customer phone number associated with the customer's bank account controlled by the SDP. The service data point 412 is a database in which the customer's phone number is stored in addition to the customer's account information, and wherein the customer's account information may be retrieved based on its association with the provided phone number. In one embodiment, the service data points 412 may be used to control financial institution accounts.
In one embodiment, the payment processing server cannot identify the appropriate SDP based on the provided account phone number. In such a case, the payment processing system sends a query request to the registry 414 of the SDP to identify 504 the SDP associated with the account telephone number of the consumer. The registry 414 of the SDP provides routing information to the SDP 412 associated with the customer's bank account.
Once the appropriate SDP is identified 412, the payment processing server queries the SDP to receive 506 account information associated with the customer's phone number. SDP 412 may retrieve account information associated with the customer's phone number.
As described above, the payment processing server 110 sends 508 a transaction information request to the merchant identified by the merchant ID. In response to the request, the merchant may send transaction information to the payment processing server. In one embodiment, the payment processing server receives 510 transaction information from the merchant via communication means known in the art. As described above, the transaction information may include a total purchase price for the item that the consumer wants to purchase, an account number associated with the merchant, a mobile phone number provided by the consumer, and the like. The merchant 104 may provide the transaction information to the payment processing server 110 using any communication method (COMM) known in the art. In one embodiment, the merchant may enter the total purchase amount on a keypad of the point-of-sale terminal.
As described above, in one embodiment, the payment processing server 110 sends 512 an authorization request to the mobile device 102 that initiated the transaction request. For example, the payment processing server 110 sends a COMM, SMS message, or email to the customer's phone number or email address that initiated the transaction. In one embodiment, the payment processing server 110 may send 512 the account name and number to the mobile device 102 along with the authorization request. In another embodiment, the consumer may provide a phone number associated with the consumer account and a different communication phone number. For example, a consumer initiating a transaction may provide an account phone number by initiating a communication from a different phone number. In such a case, the consumer may initiate a transaction using an application executing on the communication mobile device 102, or do so using COMM messaging. In such a case, the payment processing server 110 sends 512 an authorization request to the communication phone number, where the consumer may provide authorization associated with the account phone number.
In one embodiment, the payment processing server 110 receives 514 an authorization message from the mobile device 102. The authorization message may include a Personal Identification Number (PIN) associated with the consumer's account. The consumer may set multiple PINs for one or more accounts. For example, the consumer may set a PIN for purchases below a preset dollar amount and a different PIN for purchases above a dollar amount. Similarly, the consumer may set a separate PIN for a particular merchant. In another embodiment, the consumer may have a different PIN (or one-time-use PIN that expires after the first use) when the communication telephone number from which the transaction is initiated is different than the telephone number associated with the consumer. In one embodiment, the mobile device 102 associated with the communications telephone number is configured to delete all PIN instances from the mobile device's on-board or off-board memory. In such a case, the payment processing server 110 receives 514 the authorization PIN from the consumer over the communications network. In another embodiment, a consumer using a communication phone number different from the account phone number may use a one-time password (or a one-time-use PIN that expires after the first use). For example, a consumer may preset a one-time password (which expires after the first use) for purchases over a particular dollar value when the communication phone number is different than the account phone number, or for purchases with a particular merchant.
Upon receiving the correct authorization code, e.g., PIN, from the mobile device 102, the payment processing server performs the requested transaction with the SDP 412. SDP 412 updates account information associated with the consumer. The payment processing server 110 sends a transaction confirmation to the mobile device 102 and the merchant 104. As described above, in one embodiment, the payment processing server 110 sends 518 a transaction confirmation to the mobile device 102 and the merchant 104. Any communication method (COMM) such as SMS message, email address, phone call, or the ones described above may be used to send 518 the acknowledgement. In one embodiment, the payment processing server 110 sends 518 a confirmation to the point-of-sale terminal associated with the merchant ID. In such a case, the point-of-sale terminal may print a confirmation copy for the merchant's or consumer's record. In the case where the communication telephone number is different from the telephone number associated with the transaction account, the payment processing server 110 sends 518 a transaction confirmation to one or both numbers. The confirmation communication may include details regarding whether the transaction was successfully completed, the date and time of confirmation, the total transaction amount, and the like.
FIG. 6 illustrates a high-level block diagram of a computing environment for performing transactions using a mobile device, in accordance with one embodiment. The computing environment may include a mobile device 102, a payment processing server 110, a merchant 104, and a financial institution 116.
FIG. 7 is a flow diagram illustrating a method for initiating a transaction using a service data point using a mobile device according to one embodiment. For purposes of discussion, fig. 6 and 7 are discussed concurrently below.
In one embodiment of the system and method described below, the point of sale is initiated by the merchant 104. In one embodiment, a point-of-sale terminal associated with the merchant 104 is used to enter and transmit point-of-sale information, such as transaction amount, communication telephone number, and account telephone number. The account telephone number is a telephone number associated with the financial institution. For example, a customer may preset a particular phone number to be associated with a particular account of a financial institution. The account may be a credit account, debit account, savings account, payroll account, or the like. The communication telephone number may be a telephone number associated with the consumer. In another example, the communication phone number is different from the account phone number, which allows the consumer to use a borrowed phone to perform a transaction. For example, if a consumer realizes that he or she is missing or forgetting his or her mobile phone, the consumer may borrow another person's phone by requesting that a communication be sent to a phone number associated with the borrowed phone. In other embodiments, the consumer may provide a communication email address or an account email address, where the email account is associated with an account of the consumer's financial institution.
In one embodiment, the payment processing server 110 receives 702 point-of-sale information from the merchant 104. The payment processing server 110 sends 704 an authorization request to the communication telephone number provided by the merchant 104. As described above, in one embodiment, the payment processing server 110 sends 704 an authorization request to a communication phone number or an account phone number as provided by the consumer. In one embodiment, the payment processing server 110 sends a COMM, SMS message, or email to the phone number or email address where the transaction was initiated. In one embodiment, the payment processing server 110 may send 704 an account name and number to the mobile device 102 along with the authorization request. For example, if the consumer has associated several credit or debit accounts with an account phone number, the payment processing server 110 may provide a list of all accounts available to the consumer. In such a case, the payment processing server 110 opens a data session to the mobile device 102 and provides a menu for selection from which the consumer can select an account with which to perform the transaction. In another embodiment, the payment processing server 110 communicates with a client on the mobile device 102 using USSD menu options (if available in the network) or WAP push messages with several links representing various accounts. Also, in such a case, the consumer may enter the authorized PIN for the account that the consumer wishes to use to perform the purchase. In another embodiment, the payment processing system requests a PIN even if the consumer has associated several accounts with an account phone number. In such a case, the consumer may enter an authorization PIN for the account that the consumer wants to use to execute the purchase. The payment processing server 110 may identify a credit or debit account based on whether the authorization PIN matches one of the accounts associated with the account phone number.
In one embodiment, the consumer may enter and send a message to the payment processing server 110 to authorize the transaction. The payment processing server 110 receives 706 authorization from the mobile device 102. The authorization message may include a Personal Identification Number (PIN) associated with the consumer's account. The consumer may set multiple PINs for one or more accounts. For example, the consumer may set a PIN for purchases below a preset dollar amount and a different PIN for purchases above a dollar amount. Similarly, the consumer may set a separate PIN for a particular merchant. In another embodiment, the consumer may use a one-time password (or a one-time-use PIN that expires after the first use) or PIN when using a communication telephone number other than the account telephone number. For example, a consumer may preset a one-time password (which expires after the first use) for purchases over a particular dollar value when the communication phone number is different than the account phone number, or for purchases with a particular merchant. In one embodiment, the mobile device 102 associated with the communications telephone number is configured to delete all PIN instances from the mobile device's on-board or off-board memory. In such a case, the payment processing server 110 receives 706 an authorization PIN from the consumer over the communications network.
In response to the consumer sending the authorization, the payment processing server 110 receives 706 the authorization from the mobile device 102. As described in greater detail above, the payment processing server executes 708 a point-of-sale transaction with a financial institution associated with the consumer and the merchant 104. Once the transaction is performed 708, the payment processing server sends a confirmation to the merchant 104, the communication associated with the consumer, and the account phone number. As described above, in one embodiment, the payment processing server 110 sends 710 a transaction confirmation to the mobile device 102 and the merchant 104. Such as an SMS message, an email address, a phone call, or any of the communication methods (COMM) described above may be used to send 710 the acknowledgement. In one embodiment, the payment processing server 110 sends 710 a confirmation to the point-of-sale terminal associated with the merchant ID. In such a case, the point-of-sale terminal may print a confirmation copy for the merchant or consumer's record. In the case where the communication telephone number is different from the telephone number associated with the transaction account, the payment processing server 110 sends 710 a transaction confirmation to one or both numbers. The confirmation communication may include details regarding whether the transaction was successfully completed, the date and time of confirmation, the total transaction amount, and the like.
Referring now to FIG. 8, there is illustrated a high-level block diagram of a computing environment for performing transactions associated with sub-accounts using a mobile device, in accordance with one embodiment. The computing environment may include the mobile device 102, the SDP 412, an account 810 associated with the mobile phone number, and a sub-account 812 associated with the mobile phone number.
FIG. 9 is a flow diagram illustrating a method for performing a transaction associated with a sub-account using a mobile device according to one embodiment. For purposes of discussion, fig. 8 and 9 are discussed concurrently below.
As described in more detail above, the mobile device 102 or merchant 104 may initiate a transaction request by sending a merchant ID and an account phone number to a Service Data Point (SDP) 412. In one embodiment, the SDP receives 902 a transaction request from a merchant 104 or from a mobile device 102. In one embodiment, the SDP is queried 904 to determine if the received account phone number is associated with a sub-account. The child account 812 is associated with the parent account 810, where the child account may have limited access to funds available to the parent account 810 or an account associated with the mobile phone number. If the SDP determines that the account phone number is associated with a sub-account, the SDP offer sub-account criteria are matched 906.
In other embodiments, the sub-account criteria may be matched 906 in other ways. For example, a phone number may be associated with a sub-account. In such a case, if the communication phone number matches the criteria of the sub-account 812, the SDP performs 912 a transaction with the sub-account in response to receiving the appropriate authorization. In other embodiments, the authorization PIN may be associated with a sub-account. If the sub-account criteria are met, the SDP sends an authorization request to one or more of the communication phone number, the phone number associated with the sub-account, or the phone number associated with the parent account 810. For example, the SDP or payment processing server 110 may send 908 an authorization request to an account phone number associated with the parent account 810, or a phone number associated with the child account, or both. In this way, the consumer may create sub-accounts for family members so that the consumer's children or other family members may make specific purchases using their own mobile devices. Similarly, in embodiments where the authorization request is sent to a phone number associated with the parent account 810, the parent may provide real-time approval or denial of a particular purchase initiated by the child account owner.
As described above, in one embodiment, the payment processing server 110 sends 908 an authorization request to the appropriate mobile device 102, including the mobile device 102 that initiated the transaction request, or to a phone number associated with the parent account 810. For example, the payment processing server 110 sends an SMS message or an email to the provided phone number or email address. In one embodiment, the payment processing server 110 may send 908 the account name and number to the appropriate mobile device 102 along with the authorization request. In another embodiment, the consumer may provide a phone number associated with the consumer account and a different communication phone number. For example, a consumer initiating a transaction may provide an account phone number by initiating a communication from a different phone number. In such a case, the consumer may use an application executing on the communication mobile device 102 to initiate a transaction or use COMM messaging. In such a case, the payment processing server 110 sends 908 an authorization request to the communication phone number, where the consumer may provide authorization associated with the account phone number.
The SDP may receive 910 authorization from a child account phone number, a communication phone number, or a phone number associated with the parent account 810. The authorization message may include a Personal Identification Number (PIN) associated with the consumer's account. The consumer may set multiple PINs for one or more accounts. For example, the consumer may set a PIN for purchases below a preset dollar amount and a different PIN for purchases above a dollar amount. Similarly, the consumer may set a separate PIN for a particular merchant. In another embodiment, the consumer may have a different PIN (or one-time-use PIN that expires after the first use) when the communication telephone number from which the transaction is initiated is different from the telephone number associated with the consumer. In one embodiment, the mobile device 102 associated with the communications telephone number is configured to delete all PIN instances from the mobile device's on-board or off-board memory. In such a case, the payment processing server 110 receives 910 an authorization PIN from the consumer over the communications network. In another embodiment, a consumer using a communication phone number different from the account phone number may use a one-time password (or a one-time-use PIN that expires after the first use). For example, a consumer may preset a one-time password (which expires after the first use) for purchases over a particular dollar value when the communication phone number is different than the account phone number, or for purchases with a particular merchant.
The SDP may initiate execution of a transaction between the consumer and the merchant 104. If the SDP does not receive the appropriate authorization or the child account criteria match, the SDP performs 914 a transaction with the parent account 810. As described in more detail above, a transaction confirmation is sent to the merchant, communication telephone number, account telephone number, or sub-account telephone number.
FIG. 10 is a high-level block diagram illustrating a computing environment for performing transactions using payroll cards, according to one embodiment. The computing environment may include a mobile device 102, a mobile support center 106, a register of payment processing servers 108, a payment processing server 110, a merchant 104, a service data point 112, a register of service data points 114, and a financial institution 116.
In one embodiment, the SDP may control an aggregated account in the bank that includes multiple sub-accounts that may represent payroll accounts (also referred to as nosro accounts). Such payroll accounts may be used for those who cannot establish an account themselves due to lack of sufficient funds or lack of good credit. Such aggregated accounts may be accessed by any of the payment processing servers 110 or SDPs if they are associated with a mobile phone number. One such sub-account in the aggregated account may have multiple virtual accounts. For example, an employee without a bank account would require the employer to use such a sub-account to directly deposit payroll. The sub-account will be associated with the employee's mobile phone number. The employee will be able to create multiple virtual sub-accounts on the SDP and move funds into those sub-accounts. Each sub-account will be associated with a mobile phone and can be accessed by phone, by means of any of the payment processing servers 110 or the mobile support center 106. In one embodiment, the SDP may replace or perform the functions of a mobile support center. In one embodiment, the SDP may control the transfer of funds between banks, telephone account numbers, and between merchants.
Fig. 11 is a flow diagram illustrating a method of performing a transaction using a payroll card according to one embodiment. For purposes of discussion, fig. 10 and 11 are discussed concurrently below.
In the embodiment discussed with reference to fig. 10 and 11, the point-of-sale transaction is initiated by the merchant 104 or the mobile device 102, with the account phone number associated with the payroll card 1002. Payroll card 1002 may be a debit card associated with a payroll account. An employer of a consumer using a payroll card may deposit a payroll check in a payroll account. For example, instead of giving a payroll check that can be exchanged for cash or deposit to a consumer every week, every two weeks, or every month, an employer may pay a payroll into a payroll account every week, every two weeks, or every month, so that the employer does not have to issue a new payroll check every payroll cycle. Such a system is beneficial because it reduces the cost of employers issuing checks. In addition, such systems are also beneficial to employees because they may access accounts associated with cards that are available to make purchases without having to open additional accounts or new lines of credit with another financial institution. Further, each payroll account may be associated with a payroll trust account. Payroll trust accounts are aggregated accounts that employers use to make deposits to each individual payroll account associated with an employee. Payroll trust accounts typically have a float (float) and cannot be closed. As described in more detail below, an additional benefit of the systems and methods described herein is to allow consumers to borrow funds from trusted accounts if the funds in their consumer payroll accounts are depleted. The payroll trust account may withhold (withhold) money due to the employee being in the next payroll period. The refused money may be a portion of the borrowed money, the whole borrowed money, or the whole borrowed money plus a fee and interest.
In one embodiment, the payment processing server receives 1102 a request for execution of a transaction from an account associated with payroll card 1002. For example, a merchant may swipe a card or enter an account number associated with a payroll card at a point-of-sale terminal. In such a case, the point-of-sale terminal may receive a firmware update to enable the consumer to perform the purchase using the payroll account card. In another embodiment, a mobile device may be used to initiate a point-of-sale transaction. As described above, the mobile device may send the account phone number and merchant identification to the Service Data Point (SDP)412 or the mobile support center 106. In another embodiment, the consumer may borrow a mobile computing device to initiate a point-of-sale transaction, as described above.
Upon receiving the request, the SDP sends 1104 appropriate authorization information to the mobile phone number or communication phone number associated with the payment account and receives 1106 appropriate authorization information. As described above, in one embodiment, SDP 412 sends 1104 an authorization request to mobile device 102 associated with a payroll account. For example, SDP 412 sends a COMM, SMS message, or email to the customer phone number or email address associated with the payroll account. In one embodiment, SDP 412 may send 1104 an account name and number to mobile device 102 along with the authorization request. In another embodiment, the payment processing server may send 1104 the authorization request to a communication telephone number different from the account telephone number associated with the payroll account. For example, the communication phone number may be provided in the received 1102 communication that provides payroll account information to perform the transaction. In such a case, the consumer may initiate the transaction using an application executing on the mobile device 102 associated with the communication telephone number.
In one embodiment, SDP 412 receives authorization from mobile device 102. The authorization message may include a Personal Identification Number (PIN) associated with the consumer's account. The consumer may set multiple PINs for one or more accounts. For example, the consumer may set a PIN for purchases below a preset dollar amount and a different PIN for purchases above a dollar amount. Similarly, the consumer may set a separate PIN for a particular merchant. In another embodiment, the consumer may have a different PIN (or one-time-use PIN that expires after the first use) when the communication telephone number from which the transaction is initiated is different than the telephone number associated with the consumer. In one embodiment, the mobile device 102 associated with the communications telephone number is configured to delete all PIN instances from the mobile device's on-board or off-board memory. In such cases, SDP 412 receives 1106 an authorization PIN from the consumer over the communication network. In another embodiment, a consumer using a communication phone number different from the account phone number may use a one-time password (or a one-time-use PIN that expires after the first use). For example, a consumer may preset a one-time password (which expires after the first use) for purchases over a particular dollar value when the communication phone number is different than the account phone number, or for purchases with a particular merchant.
The SDP logic identifies whether the payroll account has sufficient funds 1108 to perform the requested transaction. If so, the SDP performs 1112 a transaction with the bank associated with the payroll card. If the SDP determines that the payroll account does not have sufficient funds, the SDP performs 1110 a transaction with a payroll trust account. Once the transaction is completed, a transaction confirmation is sent to the merchant and the mobile device associated with the payroll account. In one embodiment, SDP 412 sends 1114 a transaction confirmation to mobile device 102 and merchant 104. Such as an SMS message, an email address, a phone call, or any of the communication methods (COMM) described above may be used to send 1114 the acknowledgement. In one embodiment, SDP 412 sends 1114 a confirmation to the point-of-sale terminal associated with the merchant ID. In such a case, the point-of-sale terminal may print a confirmation copy for the merchant's or consumer's record. In the case where the communication telephone number is different from the telephone number associated with the transaction account, SDP 412 sends 1114 a transaction confirmation to one or both telephone numbers. The confirmation communication may include details regarding whether the transaction was successfully completed, the date and time of confirmation, the total transaction amount, and the like.
While particular embodiments and applications of the present invention have been illustrated and described herein, it is to be understood that the invention is not limited to the precise construction and components disclosed herein and that various modifications, changes, and variations may be made in the arrangement, operation, and details of the method and apparatus of the present invention without departing from the spirit and scope of the invention as defined in the appended claims.