US20140372315A1 - Method and system for managing data and enabling payment transactions between multiple entities - Google Patents

Abstract

A system for conducting payment transaction includes a network-enabled server that communicates with one or more user devices, other network-enabled server computers, and a payment processing network server computer. The network-enabled server facilitates transactions between one or more merchants and users by a managing data flow and interactions between the merchants and the users, providing storage area for storing of all transaction related documents, and providing seamless integration with a payment processing network for payment processing.

Description

CROSS REFERENCES TO RELATED APPLICATIONS
• This application claims priority under 35 USC §119(e) to U.S. Provisional Patent Application No. 61/444,276, filed on Feb. 18, 2011, the disclosure of which is incorporated by reference herein in its entirety for all purposes.
BACKGROUND
• In a traditional payment transaction scenario, a user uses a payment device at an access device to pay for a product or service. The payment device information is sent to a payment processing network, which communicates with an issuer of the payment device to authorize the transaction. The issuer merely checks if the user has enough balance/credit left in the account to cover the amount of transaction.
• Thus, in the conventional method there is no validation of the transaction itself. For example, the issuer cannot request additional documentation from either the merchant or the user to verify whether the service/product that is subject of the transaction is actually required and/or provided to the user. In other words, nothing is done to check whether the transaction is genuine, proper, or actually initiated by the payment device holder. In the conventional system, if the user has enough balance/credit in his account and the required transaction details are provided by the merchant, the transaction is processed without additional verification. The problem is especially acute when there are more than two entities involved in a transaction where the entity paying for the product/service is not the entity that actually receives the product/service.
• Currently, the existing payment processing systems are not equipped to handle the extra traffic that may be generated by the information/documentation related to each payment transaction that involves multiple entities. Thus, there is a need for a new infrastructure that can handle the increased traffic generated because of the extra validation processes and thereafter process payment once the transaction is validated.
SUMMARY
• Embodiments of the present invention are generally related to processing payment transactions. In particular, certain embodiments of the present invention provide a system that enables end-user devices to interact directly with payment processing systems without having to go through another entity. Other embodiments of the present invention provide a method for performing payment transactions with added security and validation. The system provides a mechanism for managing all transactions associated with getting paid for performing a service or getting paid for selling a product. The system and method disclosed herein minimize the delay between performance of a service and getting paid for the performed service and/or selling a product and getting paid for selling a product.
• Some embodiments of the present invention provide a system for processing transactions. The system comprises a payment processing network server computer configured to communicate with an issuer to process payment requests and a network-enabled server computer configured to communicate with one or more external systems. The network-enabled server computer is further configured to receive a payment request from a merchant computer for authorizing payment for a transaction, request additional information associated with the transaction from the merchant computer and send a validation request to a user device to validate the payment request. The network-enabled server computer further receives a response to the validation request and alias information about the user. network-enabled server computer then determines payment account information based on the alias. The network-enabled server computer communicates the payment account information to the payment processing network server computer.
• In some embodiments, the network-enabled server computer may also receive information from the payment processing network server computer indicating successful processing of the payment transaction and communicate the information to the merchant computer and/or the user device. In some embodiments, the network-enabled server computer communicates with the user device and the merchant computer using WSDL messaging techniques, RESTful computing techniques, and/or JSON.
• Some embodiments of the present invention provide a network-enabled server computer. The network-enabled server computer includes an alias database comprising information about one or more aliases, an alias hierarchy database comprising association information between an alias and one or more objects associated with the alias, an application interface configured to communicate with one or more external devices, and a data storage configured to store data. In some embodiments, the one or more aliases comprise identifiers associated with a plurality of entities, wherein an entity includes an individual or a company. In some embodiments, the alias database includes payment account information associated with an alias. In some embodiments, the one or more objects include mobile communication devices, televisions, and gaming consoles. The application interface may be configured to communicate with the one or more external devices using WSDL and/or JSON messaging techniques.
• Some embodiments of the present inventions provide a method for processing a payment transaction. The method includes receiving a first message from a merchant server computer requesting authorization for a transaction, sending a second message to the merchant server computer requesting additional information related to the transaction, and receiving a third message from the merchant server computer including the requested information. The method further includes sending a fourth message to a user device requesting a user to validate the transaction, receiving a fifth message from the user device including validation information, and receiving a sixth message from the user device including payment account information. Thereafter, the method further includes sending a seventh message to a payment processing network server computer including the payment account information and transaction information, receiving an eight message from the payment processing network server computer including results of the payment transaction processing, and sending a ninth message to the merchant server computer including the results of the payment transaction processing.
• In some embodiments, the additional information related to the transaction may include documents, images, audio, video, or graphics. In some embodiments, one or more of the first message, the second message, the third message, the fourth message, the fifth message, the sixth message, and the ninth message are sent using WSDL techniques. In some embodiments, one or more of the first message, the second message, the third message, the fourth message, the fifth message, the sixth message, and the ninth message are sent using RESTful computing techniques. In other embodiments, one or more of the first message, the second message, the third message, the fourth message, the fifth message, the sixth message, and the ninth message are created using JSON. In some embodiments, the first message includes alias information of the user. In an embodiment, prior to sending the fourth message, the server computer may consult an alias database to determine the user device associated with the alias. In some embodiments, the payment account information is stored in the server computer.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is a flow diagram of a traditional payment processing process.
• FIG. 2 is a functional block diagram of a system according to an embodiment of the present invention.
• FIG. 2A illustrates an alias data structure according to an embodiment of the present invention.
• FIG. 3 is a block diagram of a server computer according to an embodiment of the present invention.
• FIG. 4 is a flow diagram of a process for a method for processing payment transaction according to an embodiment of the present invention.
• FIG. 5 is a block diagram of a computer system.
• FIG. 6 is a block diagram of an exemplary user device.
DETAILED DESCRIPTION
• Embodiments of the present invention provide a system for validating and processing payment transactions between multiple parties. The system includes a payment processing network sever computer, data management server computer, a user and one or more merchants.
• In order to provide a better understanding of the present disclosure, a brief review of transaction processing as it exists today is provided with reference to FIG.1. For ease of discussion, a transaction conducted in a physical store is described, however it should be understood that similar steps occur in any type of transaction, including online transactions. In a typical transaction, auser100 may select goods or services to purchase at a merchant. The user may then pay for the goods or services by presenting a transaction card, such as a debit or credit card, to the merchant. The merchant may then swipe the transaction card through anaccess device102, e.g., a Point of Sale (“POS”) terminal, to read the account number from the transaction card.
• Access device102 may then send the account number to a merchant system, where other information related to the transaction, such as purchase amount, may be added. It should be noted that in some cases, the access device and the merchant system are a single device, in which the account number is read, and the purchase amount is keyed in by the merchant. The transaction details, such as the account number and purchase amount are then sent from the merchant system to anacquirer system104 to request transaction authorization. An acquirer is generally a bank that holds an account for the merchant in which funds resulting from the transaction may eventually be deposited.
• Theacquirer system104 then receives the transaction details, and determines apayment processing network106 that may process the transaction. Theacquirer104 routes the transaction to the appropriatepayment processing network106, which in turns determines theissuer108 of the transaction card. As mentioned above, anissuer108 may provide the user with an account that holds cash or a line of credit. Thepayment processing network106 then routes the transaction to thecorrect issuer108 for a transaction authorization decision. If the user has sufficient funds in the account or sufficient available credit, theissuer108 may authorize the transaction. The authorization response is transmitted back to the merchant, through thepayment processing network106, theacquirer104, and theaccess device102. The user has then completed the purchase of the goods or services. At a later point in time, a settling and clearing process may occur, in which the funds are actually transferred from the user's account (or drawn on the line of credit) to the merchant's account at the acquirer. The settlement and clearing process occurs using the account number, wherein a request for funds may be compared to a previous authorization, and if an authorization exists, the funds are transferred.
• Transactions may become even more complicated when a Personal Identification Number (“PIN”) is required. For example, in the case of some debit card transactions, a PIN must be entered by the user. The PIN is typically entered into the access device in clear form by the user. The PIN is then encrypted using a Pin Encryption Key (PEK) in the access device and is sent to a merchant system, which also knows the PEK. The merchant system, then decrypts the PIN using the PEK, and encrypts it again using an acquirer working key (AWK), which is a key known by the merchant and the acquirer. The acquirer then decrypts the PIN using the AWK and encrypts again using a payment processor key. The payment processor in turn decrypts the PIN and encrypts using an issuer working key. The issuer then decrypts the PIN and determines if the PIN is correct.
• In the traditional payment processing process described above, the transaction is usually between a single entity that is purchasing a product or a service and a single entity that is providing the product or a service. There is no mechanism to validate or request more information about a transaction, as part of payment processing process, before approving that transaction. For example, if a user is requesting a service from a first merchant which may be paid for by a second merchant contracted by the user, currently there is no mechanism by which the second merchant can ensure, as part of the payment processing operation, that (a) the service is actually needed and (b) proper documentation is available in order to authorize that service. In most of these situation, the first merchant, the second merchant, and the user end up exchanging information among themselves either prior to performance of the service or after the service is rendered in order to authorize payment for the service.
• The traditional process is very cumbersome and slow. In many cases, it often takes weeks or months before the first merchant gets paid for the service he has provided. Also, since most of the processing for payment authorization involves printed paperwork and communication via regular mail, instances of lost documentation a plentiful, which further delays the performance of a service and/or payment for a service already performed. In addition, the traditional process is labor intensive and is costly for the merchants who generally recover pat of the costs from the users. Embodiments of the present invention serve to alleviate these and many other issues with the current mechanism.
• Embodiments of the current invention provide a mechanism for integrating the payment processing infrastructure with a new infrastructure for handling the supporting documentation and information needed to effect the payment processing. Many advantages can be realized with the system and methods described below. First, by automating most of the traditional mechanisms for service and payment authorization, the proposed system can greatly enhance the speed and efficiency of execution. Second, the system leverages use of billions of network connected servers and user devices such as cell phones, mobile computing devices, TVs', etc. to enable a user and a merchant to interact quickly and efficiently without having to resort to traditional methods like mailing of documents. This may greatly enhance the speed of processing both the transaction authorization and payment processing aspects of a transaction. Third, since the system uses a web-based cloud server configuration to store data, the data is available for access virtually anywhere in the world at anytime further reducing the delay in the entire process. Fourth, the system uses WSDL, JSON, and/or RESTful messaging, which are universally supported by virtually all the current network enabled servers and devices. This is may greatly reduce the cost/message for communicating with the cloud server computer(s). These cost savings can be passed on to the merchants/users. Finally, the system provides a secure means of conducting transactions in which the user need not provide his payment details to any merchant, but rather uses only an alias to conduct transactions. The user's payment details are stored safely on the cloud server computer. Thus there is virtually no payment details exchanged between a user and a merchant, which reduces the instances of fraud and identity theft.
• FIG. 2 illustrates a functional block diagram of asystem200 according to an embodiment of the present invention.System200 includes a payment processingnetwork server computer202 that communicates with anacquirer204 and anissuer206. Payment processingnetwork server computer202 can be implemented, e.g., using the computer system ofFIG. 5. Payment processingnetwork server computer202 receives payment authorization requests and communicates withacquirer204 andissuer206 to complete the payment transaction. In some embodiments, payment processingnetwork server computer202 is similar to the payment processingnetwork server computer106 ofFIG. 1.
• Payment processingnetwork server computer202 also communicates with adata store208 that stores payment related information. In some embodiments,data store208 may include, for a particular account, account number, payment device identifier(s) associated with the account, the CVV code associated with the payment device(s), account holder information, etc. In operation, payment processingnetwork server computer202 consults withdata store208 to retrieve the information needed to process the payment transaction. In some embodiments,data store208 may be integrated into the payment processingnetwork server computer202. In other embodiments,data store208 may be external to payment processingnetwork server computer202 and may comprise shared data resources.Data store208 may be implemented using any non-volatile storage medium such as optical disks, HDD, or flash memory. In some embodiments,data store208 may also include addressing and control circuitry for accessing the data indata store208.
• System200 may also include acloud server computer210 that may be operated by the same entity that operates payment processingnetwork server computer202.Cloud server computer210 may be implemented, e.g., by computer system ofFIG. 5.Cloud server computer210 may include adatabase212, one or more application interfaces214,storage device216, and analias database218.
• Database212 may have a subset of information present indata store208. In some embodiments,database212 may include all the information fromdata store208. Periodically,database212 is synchronized withdata store208 to ensure thatdatabase212 has the most current information related to user accounts. In some embodiments, for security purposes certain information that is present indata store208 may not be present indatabase212.Database212 can be implemented using appropriate hardware and software components commonly available. In some embodiments,database212 can used shared memory architecture. Shared memory is memory that may be simultaneously accessed by multiple programs with intent to provide communication among them or avoid redundant copies. Shared memory is an efficient means of passing data between programs. Depending on context, programs may run on a single processor or on multiple separate processors.
• Application interface214 can include hardware and software for communicating with various external devices. In some embodiments, application interface may include requisite functionality for sending and receiving WSDL messages, JavaScript Object Notation (JSON), and RESTful computing messages. WSDL (Web Services Description Language) is an XML-based language that provides a model for describing Web services. WSDL is often used in combination with SOAP and an XML Schema to provide web services over the Internet. A client program connecting to a web service can read the WSDL file to determine what operations are available on the server. Any special data types used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the operations listed in the WSDL file. WSDL is widely used for communications over a network. REST (Representational State Transfer) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. REST-style architectures consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses. Requests and responses are built around the transfer of representations of resources. A resource can be essentially any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource.
• JSON is a lightweight text-based open standard designed for human-readable data interchange. It is derived from the JavaScript scripting language for representing simple data structures and associative arrays, called objects. Despite its relationship to JavaScript, it is language-independent, with parsers available for most languages. The JSON format is often used for serializing and transmitting structured data over a network connection. It is used primarily to transmit data between a server and web application, serving as an alternative to XML.
• Storage device216 can be implemented using a non-transitory, non-volatile storage media such as hard disks, optical disks, flash memory, etc. In some embodiments,storage device216 can include several individual storage media. In some embodiments, storage device can have a capacity in excess of 100 terabytes. In some embodiments,storage device216 may store all the supporting information for a particular transaction.
• Alias database218 may include information about an alias. An alias may be a representation of an individual or a business. In some embodiments,alias database218 may include biographical information about an alias, information about devices associated with the alias, etc. A detailed description of an alias database is provided in the pending commonly-owned U.S. patent application Ser. No. 12/846,767, filed on Jul. 29, 2010, the contents of which are incorporated by reference herein in its entirety for all purposes. In some embodiments,alias database218 may be part ofdatabase212.FIG. 2A illustrates an example of data that may be store inalias database218.
• As illustrated inFIG. 2A, alias hierarchy anddata structure tree250 includes a top-level alias251 to which all other aliases and objects are linked. As described above date illustrated inFIG. 2A may be stored inalias database218. Thealias251 may be associated with an entity/organization, a person/individual, or a device. In some embodiments,alias251 may be linked to other aliases within or outside a particular tree.Alias251 may be linked tovarious hierarchy groups260,270, and280. The hierarchy groups are used to arrange the data in a manageable form and for ease of search using standard database queries. Each of these hierarchy groups may represent a particular area, e.g., devices, household, individual, entity/business, etc. InFIG. 2A, thehierarchy group260 is referred to as the business domain. This hierarchy group relates to a business entity that may be owned or operated by owner of thealias251. Thehierarchy group260 may have several objects linked to it. Each of the objects linked to thehierarchy group260 in turn may have an alias associated with them. As illustrated, thehierarchy group260 may have anobject261 associated with it. Theobject261 may be a network used by the business entity. Theobject261 may further haveobjects262 and263 associated with it. In an embodiment, object262 may be the internet service provider (ISP) used by the business entity and theobject263 may be the telephone company that provides telephone service to the business entity. In addition, thehierarchy group260 may have other network type objects linked to it. Theobject263 may also haveother objects264 and265 linked to it. Theobject263 may represent a financial institution, e.g., a bank, which issues acredit card264 and where the business entity has itschecking account265. Each of theobjects264 and265 may also have an alias associated with them. Similarly,hierarchy group260 may have anotherfinancial institution266 associated with it that may represent a different bank where the business entity has an account.
• Hierarchy group270 is related to an individual domain.Hierarchy group270 includes information about an individual and his household. For example,hierarchy group270 may have anobject271 that represents the spouse of the individual, anobject272 that specifies the gender of the individual, anobject273 that represent the children of the individual, and anobject274 that represents the household of the individual. Theobject274 may be further liked to one or more objects that represent, the address of the household, the parcel number of the household, etc. Similarly, object271 may be further linked to other objects that represent the spouse's age, gender, any other children of the spouse, etc.
• Hierarchy group280 is related to devices that may be used by a business entity or an individual. Thehierarchy group280 may also have various subjects associated with it. In an embodiment, the hierarchy group may haveobjects281,282,283, and284 associated with it. Theobject281 may represent the vehicle owned by the individual or the business entity. Theobject282 may represent the computer owned by the individual or the business entity. Theobject283 may represent various other electronic devices owned by the individual or the business entity. Theobject284 may represent a cell phone owned by the individual or the business entity. In some embodiments, theobject284 may have additional objects associated with it that may represent various attributes of theobject284. For example, theobject284 may have attributes that represent a phone number, serial number of the cell phone device, a serial number of a SIM card installed in the cell phone, associated with theobject284. In some embodiments, each of the attributes may be an object and have a unique alias associated with the object. As described earlier, each of the objects associated with any of the hierarchy groups may have a unique alias associated with them.
• In some embodiments, an object in one hierarchy group may also be associated with another object in a different hierarchy group. For example, object284 (cell phone) may be associated withobject264 in the instance where the cell phone is also a payment device, e.g., implementing contactless card technology. In some embodiments, one hierarchy group may be linked to another hierarchy group for the same alias or a different alias. For example, if a husband and wife share the same household, the hierarchy group associated with the household may be linked to alias of the husband as well as the alias of the wife, or to any other hierarchy groups that are linked to the alias of the husband or the wife.
• Thus it can be seen that each hierarchy group can include multiple levels of objects linked to each other within the same hierarchy group. In addition, objects in one hierarchy group can be linked to objects in different hierarchy groups. It is to be understood that the various objects and aliases illustrated inFIG. 2A are exemplary and the type and amount of objects associated with an alias may depend on whether the alias is an individual or an entity such as a merchant described above.
• Referring back toFIG. 2,system200 may also include one ormore user devices230 and one or moremerchant server computers232,234. User devices can include mobile communication devices, televisions, PDA's, PC's, and portable computing devices. Eachuser device230 may be associated with an alias belonging to the user. In this manner, any transaction originating or terminating atuser device230 can be tracked and properly attributed to the corresponding user.Merchant server computers232,234 can be any network enabled server computer that is associated with a merchant. A merchant as used herein can be a corporation (e.g., Google, Facebook, etc.), a service provider (e.g., an insurance company, auto body shop, gas station, etc.), retail outlets (e.g., Sears, Wal-Mart, etc.), a network-based information provider (e.g., search engines, social networks, etc.), or any other entity that provides either a product, a service, or information.
• Further, whilesystem200 is described herein with reference to particular blocks, it is to be understood that these blocks are defined for convenience of description and are not intended to imply a particular physical arrangement of component parts. Further, the blocks need not correspond to physically distinct components. Blocks can be configured to perform various operations, e.g., by programming a processor or providing appropriate control circuitry, and various blocks might or might not be reconfigurable depending on how the initial configuration is obtained.
• Now, the operation ofsystem200 will be described below using an example in which a user needs to get some dental work done, e.g., a root canal, and seeks authorization from his insurance company who may authorize payment for the service. It is to be understood that the scenario described below is given to explain the operation ofsystem200 and should not be construed to limit the embodiments described herein. Consider that inFIG. 2,user device230 is a mobile device,merchant232 is an insurance company, andmerchant234 is a doctor.
• After the user associated withuser device230 visits the doctor, the doctor proceeds to get authorization from the insurance company for performance of the service. In order to accomplish this, the doctor (234) may send a service authorization message to cloudserver computer210.Cloud server computer210 then relays the message to the insurance company (232). The insurance company may need additional information in order to authorize the service, e.g., a dental x-ray of the user. The insurance company may request the additional information from the doctor viacloud server computer210. The doctor may then upload the x-ray tocloud server computer210 where it may be stored instorage device216. The x-ray is then communicated to the insurance company, which may authorize the service. The authorization may be communicated to the doctor along with a transaction ID for that service request. The transaction ID may be used to track the service when a payment request for that service is made.
• After the doctor provides the service to the user, the doctor may submit a payment request tocloud server computer210 for the service along with the transaction ID for that service.Cloud server computer210 may relay the payment request to the insurance company. Before the insurance company pays the doctor, it may want to verify that the user has indeed received the service. Accordingly, the insurance company may send a validation request touser device230 viacloud server computer210. The user can validate that the service was provided by usinguser device230. Once the insurance company receives user validation, it can send payment details tocloud server computer210. In some embodiments,cloud server computer210 may have payment details for the insurance company stored indatabase212. At this pointcloud server computer210 may send the payment details topayment processing network202 for payment processing. Once the payment is successfully processed,payment processing network202 may informcloud server computer210 of the results, which may be stored bycloud server computer210. In some embodiments, the results may be communicated to the user and the doctor.
• As seen from above, for a single payment transaction for the dental service provided to the user, there are multiple steps that occur. In one embodiment of the present invention,cloud server computer210 handles all the supporting data and interaction that occurs prior to the payment transaction being processed. In some embodiments, for every 1 payment transaction there may be up to 9 supporting transactions that may occur. Since all the supporting transactions occur directly between end-users (user device230,merchants232 and234) andcloud server computer210, there is less delay and messages can be handled in an efficient manner.Cloud server computer210 provides the individual entities with a much faster way of completing a transaction. For example, for the illustrative scenario described above it would have taken weeks for the entire transaction to be completed not counting any scheduling delays between the user and the doctor. However, withsystem200, the entire transaction can be completed in matter of minutes and almost real-time. In addition, having a neutral third-party, e.g., VISA, operate the cloud server computer provides all the stake holders with assurance that their information will be properly safeguarded. In addition, it reduces the burden on the merchants and the users of having to track the paperwork and manage multiple channels of communication for every transaction.
• Another example where the embodiments of the present invention may be used are in a transactions that involves a user buying gas at a gas station. In thisinstance merchant232 may be the gas station where the user intends to buy gas for his car. Even before the user drives to the gas station, the user can communicate withcloud server computer210 using, e.g., a communication device in his car, to retrieve information associated with the gas station, e.g., gas price, gas availability, etc. The information associated with the gas station may be stored under the alias for the gas station inalias database218. This information may be updated periodically to reflect the most updated information. In an embodiment, the user device may communicate the alias of the gas station in order to retrieve the information. In addition to the information associated with the gas station,cloud server computer210 may also gather information about the gas station from one or more information providers, e.g.,merchant234. Such information may include travel time between user's current location to the gas station including traffic conditions, an optimal travel route, reputation of the gas station in terms of average wait time for fill-up, etc. All this information can be sent back to the user device.
• The user may then drive to the gas station. The user device may determine that the user is nearing the gas station, e.g., based on location information of the user device, and send an indication to the gas station that the user is about to arrive at the gas station. The indication may include the user's alias information. The gas station server computer may use the user's alias information to request preauthorization from the user's payment card issuer for a potential gas purchase. Since the user's alias information is stored inalias database218, cloud server computer can determine user's payment device and communicate with the issuer of the payment device to obtain the preauthorization. When the user actually enters the gas station and drives up to a particular pump, the user device may communicate with the gas station server viacloud server computer210 to indicate user's location. In response to this information, the gas station's server computer can enable that pump for use.
• The user may immediately start pumping gas from that pump without having to swipe this card or present any payment device. Once the user has finished dispensing the gas, the gas station server may send the final amount of purchase to cloudserver210 to be communicated to the user's issuer. In some embodiments, the issuer may send a confirmation message to the user's device, viacloud server computer210, to verify that the user indeed purchased the gas. Once the user confirms the purchase, the payment authorization may proceed according to conventional processes.
• Thus, in this exemplary scenario, the user may not have to provide his payment details to the gas station at all. All transactions can be conducted using an alias and the gas station gets paid without ever receiving the user payment details. In addition, providing a secure means for the user to conduct his transactions may result in encouraging user's to use the system.
• FIG. 3 is a functional block diagram of acloud server computer300 according to an embodiment of the present invention. Cloud server computer (or cloud server)300 may include apayment application302 that may be configured to interact with a payment processing network. The payment application can communicate a payment authorization request to the payment processing network and receive messages associated with payment processing, from the payment processing network.
• Cloud server300 may also include adata store304 that includes aalias database306 andalias hierarchy information308.Alias database306 may include information about an alias. An alias can be some form of an identifier (e.g., e-mail address) associated with an entity. The entity can either be an individual or a company. In some embodiments,alias database306 may include biographical information associated with an alias, such as contact information, address, etc. In some embodiments,alias database306 may also include information about a payment device associated with an alias. As used herein, a payment device can be a credit card, a debit card, a smart card, an account number, etc. In some embodiments,alias database306 may be synchronized with the database associated with the payment processing network (e.g.,data store208 ofFIG. 2).
• Data store304 may also includealias hierarchy information308. In an embodiment, alias hierarchy information may include associations between and alias and one or more objects (e.g., devices, real property, etc.) and between two or more aliases. For example, one of the objects may be the cell phone associated with the alias. So, in the example above, when the insurance company communicates with the user to validate that the service was provided by the doctor, it may send a message to the cloud server computer with the alias information for the user. The cloud server may look up the cell phone number of the user and send the message to the cell phone. When a reply is received from the user, the cloud server computer may verify that the cell phone from where the reply originated is associated with the user. Thus, this may provide an additional level of security and verification.
• Cloud server300 may also includedata storage310. Data storage may include multiple storage devices working in synchronization to provide data storage capability. In some embodiments, data storage may have a storage capacity in excess of 100 terabytes. In some embodiments, most of the supporting documentation associated with a particular transaction may be stored indata storage310. For example, in the example discussed above, the dental x-ray and any other documentation related to the service provided by the doctor may be stored indata storage310. For this reason, it is desirable to have the storage capacity ofdata storage310 as high as possible.
• Cloud server300 may also include anapplication interface312.Application interface312 may communicate with external systems such as other network-enabled user devices and other network-enabled server computers that may reside at merchant locations. It is estimated that are approximately 1 billion network-enabled user devices are in operation currently and are projected to grow at an annual rate of 1 billion/year. In order to interact with all these external systems,application interface312 may use WSDL messaging, JSON, and/or RESTful computing architecture. Use of these techniques ensures that the cost of processing the large amount of transactions with the external systems is kept at a minimum.Application interface312 can be implemented using any suitable hardware and/or software components that are designed to utilize WSDL, JSON, and/or RESTful messaging.
• Further, whilecloud server computer300 is described herein with reference to particular blocks, it is to be understood that these blocks are defined for convenience of description and are not intended to imply a particular physical arrangement of component parts. Further, the blocks need not correspond to physically distinct components. Blocks can be configured to perform various operations, e.g., by programming a processor or providing appropriate control circuitry, and various blocks might or might not be reconfigurable depending on how the initial configuration is obtained.
• FIG. 4 is a flow diagram of aprocess400 for processing a transaction according to an embodiment of the present invention.Process400 may be performed, e.g., bycloud server computer300 ofFIG. 3.
• Initially, the cloud server may receive a request for authorizing a transaction from a merchant (402). The cloud server may request additional information about the transaction from the merchant (404). In some embodiments, the additional information may include documentation, images, audio, etc. The cloud server may communicate with the other entity or entities involved in the transaction for validating the transaction (406). For example, if the transaction is a request from a merchant for getting paid for an item purchased by a user, the user may be asked to validate that he/she indeed purchased the item for which payment is being requested. Once the other entity validates the transaction, the cloud server may receive payment details from the other entity (408). In some embodiments, payment details may include information about a payment device to be used for paying for the item purchased. Once the payment details are received, the cloud server may send the payment details to a payment processing network (410) for further processing. In some embodiments, prior to sending the payment details, the cloud server may verify that the payment details are associated with the other entity, e.g., by consulting thealias database306 ofFIG. 3. Thereafter, the cloud server may receive results from the payment processing operation from the payment processing network (412). The cloud server may then communicate the results to the merchant and the user (414). In some embodiments, after completion of the transaction, the cloud server may archive all the data related to that transaction and associate an identifier to it for ease of retrieval later.
• It should be appreciated that the specific steps illustrated inFIG. 4 provide a particular method of processing a transaction according to an embodiment of the present invention. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Moreover, the individual steps illustrated inFIG. 4 may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step. Furthermore, additional steps may be added or removed depending on the particular applications. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.
• FIG. 5 is a high level block diagram of a computer system that may be used to implement any of the individual components described above and may include one or more of the subsystems or components shown inFIG. 5, which is a block diagram of a computer apparatus. The subsystems shown inFIG. 5 are interconnected via asystem bus545. Additional subsystems such asprinter544,keyboard548, fixeddisk549, monitor546, which is coupled todisplay adapter582, and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller541, can be connected to the computer system by any number of means known in the art, such asserial port584. For example,serial port584 orexternal interface581 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection viasystem bus545 allowscentral processor543 to communicate with each subsystem and to control the execution of instructions fromsystem memory542 or fixeddisk549, as well as the exchange of information between subsystems. Thesystem memory542 and/or fixeddisk549 may embody a computer readable medium.
• FIG. 6 is a block diagram of the basic components that may reside in anexemplary user device614, e.g., a mobile phone, a car stereo unit, etc. according to an embodiment of the present invention.User device614 comprises a computer readable medium (CRM)652.CRM652 may be present within abody670, or may be detachable from it.Body670 may be in the form a plastic substrate, housing, or other structure.CRM652 may be a memory that stores data and may be in any suitable form including a magnetic stripe, a memory chip, etc. The memory preferably stores information such as financial information, transit information (e.g., as in a subway or train pass), access information (e.g., as in access badges), etc. Financial information may include information such as bank account information, bank identification number (BIN), credit or debit card number information, account balance information, expiration date, user information such as name, date of birth, etc. Any of this information may be transmitted byuser device614.
• CRM652, or memory, may further comprise any suitable code. The code may be suitable to perform any or all of the functionality of usermobile device614 as described herein. In some embodiments,CRM614, or memory, comprises: (a) code for receiving information from the cloud server computer; (b) code for sending information to the cloud server computer; (c) code for sending information to the issuer computer; (d) code for sending information to the payment processing network computer; (e) code for receiving information from the payment processing network computer; and/or (f) code for receiving information from the issuer computer.
• User device614 also comprises acamera654.Camera654 is operable to take pictures (i.e., acquire images), video, etc. and may include any type of image-acquiring device known in the art.User device614 may also comprise aGPS antenna656.GPS antenna656 is operable to receive transmissions from GPS satellites for identifying a location ofuser device614.GPS antenna656 may include any type of antenna operable to receive transmissions from GPS satellites as is known in the art.
• User device614 may also comprise other elements typically included in a user mobile communication device. For example,user device614 may also include a processor650 (e.g., a microprocessor) for processing the functions of theuser device614 and an output device658 (e.g., a display) to allow a user to see phone numbers and other information and messages, e.g., an authentication request message or a verification message.User device614 may further includeinput elements660 to allow a user to input information into the device, aspeaker662 to allow the user to hear voice communication, music, etc., and amicrophone664 to allow the user to transmit his/her voice throughuser device614.User device614 may also include acellular antenna666 for wireless voice and data transfer (e.g., voice and data transmission).User device614 may also include acontactless element668, which is typically implemented in the form of a semiconductor chip (or other data storage element) with an associated wireless transfer (e.g., data transmission) element, such as an antenna.Contactless element668 functions to permit the exchange of data and/or control instructions between usermobile device614 and an optional contactless element included in a merchant access device.
• User device614 may also include anaccelerometer672.Accelerometer672 is typically implemented in the form of an integrated circuit chip.Accelerometer672 can measure the proper acceleration of usermobile device614. In some embodiments,accelerometer672 can be a multi-axis accelerometer. The accelerometer readings can be communicated to other external systems for further processing.
• AlthoughFIG. 6 shows a number of components,user device614 according to embodiments of the present invention may comprise any suitable combination or subset of such components.
• Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++, JSON, or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
• The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
• One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.
• A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.
• It should be understood that the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software.

Claims (21)

1-20. (canceled)

21. A server computer comprising:

a processor; and

a memory coupled to the processor, the memory comprising instructions executable by the processor to:

receive, from a first computer associated with a first entity, a request to authorize payment of a transaction corresponding to a service provided by the entity to a user;

send, to the first computer, a request for additional information associated with the transaction corresponding to the service;

in response to receiving the additional information, send, to a second computer associated with a second entity, the additional information to validate the transaction using the additional information;

receive, from the second computer, a response indicating validation of the transaction using the additional information;

send, to a device, a request to validate the payment request;

receive, from the device, a response to the request to validate the payment request; and

send, to a computer of a payment processing network, payment account information of the user to process the payment of the transaction using the payment account information.

22. The server computer ofclaim 21, wherein the additional information includes audio, video, documentation, or a combination thereof, and wherein the additional information is related to the service provided to the user.

23. The server computer ofclaim 21, wherein the transaction is associated with an identifier, and wherein a status corresponding to the payment is determined using the identifier.

24. The server computer ofclaim 21, wherein the instructions are further executable by the processor to:

receive, from the computer of the payment processing network, information indicating a result of processing the payment of the transaction; and

send, to the first computer, the received information.

25. The server computer ofclaim 21, wherein the instructions are further executable by the processor to:

receive, from the device, an alias identifier associated with the user; and

determine the payment account information for the user using the alias identifier.

26. The server computer ofclaim 21, wherein the request to authorize the payment of the transaction includes alias information associated with the user, and wherein the payment account information for the user is determined using the alias identifier.

27. The server computer ofclaim 26, wherein the instructions are further executable by the processor to:

determine information identifying the device based on the alias identifier.

28. The server computer ofclaim 26, wherein the instructions are further executable by the processor to:

determine that the response to the request to validate the payment request indicates that the service was provided to the user by the entity; and

upon determining that the service was provided to the user, send, to the second computer, a notification that the service was provided to the user by the entity.

29. A system comprising:

the server computer ofclaim 21; and

the second computer, wherein the second computer performs operations in communication with the computer, wherein the operations comprise:

receiving, from the server computer, information indicating the request to authorize payment of the transaction;

in response to receiving the information indicating the request to authorize payment of the transaction, sending, to the server computer, a verification request for additional information;

receiving the additional information to validate the transaction using the additional information;

validating the transaction based on the additional information; and

sending the response indicating validation of the transaction.

30. A method comprising:

receiving, from a first computer associated with a first entity, a request to authorize payment of a transaction corresponding to a service provided by the entity to a user;

sending, to the first computer, a request for additional information associated with the transaction corresponding to the service;

in response to receiving the additional information, sending, to a second computer associated with a second entity, the additional information to validate the transaction using the additional information;

receiving, from the second computer, a response indicating validation of the transaction using the additional information;

sending, to a device, a request to validate the payment request;

receiving, from the device, a response to the request to validate the payment request; and

sending, to a computer of a payment processing network, payment account information of the user to process the payment of the transaction using the payment account information.

31. The method ofclaim 30, wherein the additional information includes audio, video, documentation, or a combination thereof, and wherein the additional information is related to the service provided to the user.

32. The method ofclaim 30, wherein the transaction is associated with an identifier, and wherein a status corresponding to the payment is determined using the identifier.

33. The method ofclaim 30, further comprising:

receiving, from the computer of the payment processing network, information indicating a result of processing the payment of the transaction; and

sending, to the first computer, the received information.

34. The method ofclaim 30, further comprising:

receiving, from the device, an alias identifier associated with the user; and

determining the payment account information for the user using the alias identifier.

35. The method ofclaim 30, wherein the request to authorize the payment of the transaction includes alias information associated with the user, and wherein the payment account information for the user is determined using the alias identifier.

36. The method ofclaim 35, further comprising:

determining information identifying the device based on the alias identifier.

37. The method ofclaim 35, further comprising:

determining that the response to the request to validate the payment request indicates that the service was provided to the user by the entity; and

upon determining that the service was provided to the user, sending, to the second computer, a notification that the service was provided to the user by the entity.

38. A system comprising:

a processor; and

a memory coupled to the processor, the memory comprising instructions executable by the processor to:

receive first location information indicating that a location of a device satisfies a threshold distance from a location of an entity;

determine payment account information for a user associated with the device;

send, to an issuer, a request to preauthorize payment to the entity for a good or a service, wherein the request includes the payment account information, and wherein the payment to the entity is preauthorized using the payment account information;

receive, from the issuer, a response indicating that the payment to the entity for the good or the service is preauthorized;

receive second location information indicating that the location of the device corresponds to the location of the entity; and

send, to a computer of the entity, a message indicating that the payment for the good or the service is preauthorized, wherein the good or the service is provided to the user based on preauthorization of the payment for the good or the service.

39. The system ofclaim 38, wherein the instructions are further executable by the processor to:

send, to the device, information about the entity when the location of the device satisfies the threshold distance.

40. The system ofclaim 38, wherein the instructions are further executable by the processor to:

receive, from the computer, cost information indicating a cost of the good or the service provided to the user;

sending, to the issuer, the cost information to authorize payment of the cost using the payment account information; and

sending, to the device, the cost information.

Images