Patent Application
20140279097
When purchasing an item or service from a merchant, a customer typically has several options available for affecting their purchase. The customer, or purchaser, can pay with cash, a check, or choose from a number of credit or debit cards. The purchaser may also choose to make a partial payment for the total value of the purchase by using a gift card or coupon. In the case of an in-store purchase, the chosen option is physically handed to the merchant to process the purchase transaction using a point of sale terminal. The merchant may decide beforehand, or a priori, to disallow some forms of payment. For example, the merchant may not allow checks or may only accept certain credit cards.
Methods relating to the subject matter of the following disclosure allow a purchaser to choose a payment method electronically. These systems require a purchaser to select their payment method at the time of the transaction based on what methods of payment are acceptable to a given merchant. More user friendly interfaces for selecting a payment method are provided by sophisticated electronic devices. As a result, electronically available payment methods have mainly been made accessible via intelligent mobile interfaces on smart phones or web applications on a personal computers or sophisticated tablets. For example, certain electronic wallet applications have been made available for smart phones that allow a purchaser to select a particular funding option for a transaction using an application with multiple windows and menu options. As another example, purchasers have been able to store different funding sources with a particular online merchant using a web interface on a personal computer.
In one embodiment of the invention a process for conducting a purchase transaction is provided. The process includes storing a first prioritize set of funding sources received from a purchaser in a database. The process also includes storing a second prioritized set of funding sources received from a merchant in the database. The process also includes receiving a message containing information that identifies the purchaser from a point of sale terminal associated with the merchant. The process also includes receiving a message containing a transaction amount for the purchase transaction from the point of sale terminal associated with the merchant. The process also includes selecting a funding source to affect the purchase transaction based on the first and the second prioritized list. The process also includes conducting a transfer of funds from the funding source to affect the purchase transaction using a server in communication with a back end payment processing system. The first and second prioritized sets of funding sources are stored in the database prior to the step of receiving the message containing information that identifies the purchaser. The server retrieves the first and second prioritized sets of funding sources from the database to select the funding source for the purchase transaction.
In another embodiment of the invention a computer-implemented method for performing a purchasing transaction between a purchaser and a merchant is provided. The process includes receiving a request to purchase an item or service from the merchant comprising information about an item or service at a server device from a device associated with the merchant. The method also includes receiving information identifying the purchaser at a server device from the device associated with the merchant. The method also includes sending a funding source selection from a list of funding source options associated with the purchaser to the device associated with the merchant from the server device. The method also includes completing a purchase transaction where the funds used to purchase the item or service are taken from the funding source selected. The step of sending a funding source selection comprises selecting a funding source based on data associated with the purchaser or data associated with a history of purchases by the purchaser at the merchant. The list of funding source options associated with the purchaser are configured a priori by the purchaser using a message sent to the server device via SMS.
In another embodiment of the invention a process is provided. The process includes receiving a message contains an a priori funding source selection for a payment service used to conduct a purchase transaction that was sent via SMS from a purchaser. The process also includes receiving a request to transfer funds to the merchant on behalf of the purchaser at a server device from a device associated with a merchant. The process also includes completing the purchase transaction. The funds transferred to the merchant on behalf of the purchaser are taken from a funding source selected by the a priori funding source selection. The a priori funding source selection is stored so as to apply to all future transactions conducted by the purchaser using the payment service until the server device receives a second a priori funding source selection from the purchaser.
As used in this summary, the remainder of this disclosure, and in the amended claims; the term “prioritized set” references a group of at least two elements wherein each element is treated preferentially over another in the group. This preferential treatment is not static, as one element may be preferred over another in one situation to which the set is applied, while the two elements are treated with reversed preference in another situation to which the set is applied.
The present disclosure relates to methods of making purchases. In particular, the present disclosure relates to purchasing items or services wherein the method of payment is chosen a priori by a purchaser before a transaction begins. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be evident, however, to one skilled in the art, that the present disclosure as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein.
In this document, various methods, processes and procedures are detailed. Although particular steps may be described in a certain sequence, such sequence is mainly for convenience and clarity. A particular step may be repeated more than once, may occur before or after other steps (even if those steps are otherwise described in another sequence), and may occur in parallel with other steps. A second step is required to follow a first step only when the first step must be completed before the second step is begun. Such a situation will be specifically pointed out when not clear from the context. A particular step may be omitted; a particular step is required only when its omission would materially impact another step.
In this document, various computer-implemented methods, processes and procedures are described. It is to be understood that the various actions (receiving, storing, sending, communicating, displaying, etc.) are performed by hardware, even if the action may be authorized, initiated or triggered by a user, or even if the hardware is controlled by a computer program, software, firmware, etc. Further, it is to be understood that the hardware is operating on data, even if the data may represent concepts or real-world objects, thus the explicit labeling as “data” as such is omitted. For example, when the hardware device is described as “storing a record”, it is to be understood that the hardware device is storing data that represents the record.
Embodiments of the present invention allow electronic purchases to be made without sophisticated user interfaces, without excessive back-and-forth communications at a point-of-sale (POS) terminal, and without specialized code installed at the POS terminal. In certain approaches described below, a funding source for a transaction is selected automatically based on data provided a priori by both the purchaser and merchant before the transaction begins. These approaches exhibit certain advantages for merchants because they do not require specialized devices or software at the POS, and allows merchant to prioritize their choice of payment method. As a result, the merchant may pay lower fees with some credit cards, and thus be able to charge a lower purchase price if desired. In addition, a purchaser may avoid carrying various physical payment methods such as disparate credit cards, gift cards, or coupons. In certain approaches described below, a funding source for a transaction can be configured via an SMS message sent by a potential purchaser. This may be desirable as it provides the benefits of a configurable payment service to a wider array of potential users. Although the market penetration of smart phones and personal computers is substantial, both markets are minimal when compared to the penetration of basic handsets with more limited interfaces. In addition, SMS messaging used in accordance with certain embodiments disclosed below provide a streamlined method for configuring a purchaser's account prior to conducting a transaction which makes both payment selection and the actual purchase transaction more convenient.
Embodiments of the present invention allow for a convenient a priori choice of funding sources for a purchase. Prior to making a purchase, the purchaser sets up a database on a server with funding sources (e.g., credit cards, debit cards, gift cards, coupons, and the like), and, optionally, will give permission for the choice of a funding source for later purchases to be made automatically. At the time of a purchase, the choice of funding source is made automatically, based on criteria set up by the merchant. The criteria set up by the merchant could include a prioritized set of funding sources that the merchant will accept in a similar format to the choice of funding source that set up by the purchaser. The purchaser may have some input into the criteria used for the selection of funding source. Optionally, the purchaser may confirm or deny the selected funding source. If the funding source is confirmed, the purchase transaction will proceed and be completed using the selected funding source.
The server that receives the request to transfer funds could be similar to the MOBI account server, described in U.S. Patent Publication No. 2009/0024533 A1 for “Payment Systems and Methods” filed Aug. 29, 2007, or U.S. patent application Ser. No. 13/755,421 for “Self-authenticating peer-to-peer transaction” filed Jan. 31, 2013, both of which are owned by the assignee of the present invention, and both are incorporated by reference herein in their entirety. Such a server may maintain a database containing, for example, personal identification information, for example, mobile phone numbers. The database would associate this identification information with other information; for example, funding sources, financial account information, and the like.
Method 200 and could include step 205 in which information is received by the server that identifies the purchaser. The information could be a mobile telephone number of the user. As mentioned previously, merchant device 150 can be a point of sale terminal and the purchaser can communicate with the payment service via a communication channel that includes an SMS message system. However, the purchaser, or the merchant, or both, may communicate with the payment service's servers via any means; for example, sending a text message or making a phone call with a mobile device, or through a smart phone application, or through a web site on a stationary device.
The purchaser may prioritize their funding source selections. Referring back to
Method 200 could include step 204 in which a second funding source selection method is received by the payment service such as by server 130. The second funding source selection message could add another funding source to the set of prioritized funding sources. For example, the last funding source added could be set as the lowest ranked funding source in the prioritized set. As another example, the last funding source added could be set as the highest ranked funding source in the prioritized set. The second funding source message could also reconfigure the already identified funding sources in the set of prioritized funding sources. In situations where the messages were being sent via a communications channel that included an SMS system, it could be beneficial to allow the prioritized set to be configured using multiple messages so that the content of each message could be kept simple.
Multiple funding sources from within the set of funding source selections could be applied to affect payment for a single payment transaction. Funding sources from among these multiple funding sources may be exhausted during that single payment transaction. For example, a purchaser may not have enough money in their checking account to pay for an item and may have their checking account prioritized above one of their credit cards. In this example, all of the funds in the checking account could be withdrawn to affect payment for the transaction and then the remaining balance of the transaction could be covered by the purchaser's credit card. This type of payment flow could be conducted using a recursive request to a highly ranked funding source such that the request would continuously request a smaller and smaller portion of the overall purchase price until the request for funds was approved at which point the balance of the overall purchase price would be pulled from the next highest ranked funding source. Not all of the funds in a funding source need to be withdrawn or extracted from that funding source before the payment service would begin to draw funds from the next acceptable funding source. The purchaser may be able to set minimum amounts that must be left available in a funding source; and may likewise set maximum amounts that can be taken from a particular funding source before moving on to the next highest ranked funding source.
A funding source is then selected to affect the purchase transaction in step 305. The funding source can be selected based on the lists received in steps 301 in 302, and the selection process can be conducted in various ways. The prioritized sets of funding source can be retrieved from a database and operated on by the payment system server to select the funding source for the transaction. Since both parties have provided a list of funding sources they prefer, method 300 is able to provide advantages to both the merchant and the purchaser. Even if either party to the transaction is not able to use their most preferred funding source, it is likely that the overall utility of the transaction will be increased because the preferences of both parties have been taken into account. As a basic example, the most highly ranked funding source in either list is selected based on whether or not it appears anywhere in the other party's list. As another example, the payment service may rank every funding source in both lists by summing the rank value of each of those funding sources and dividing by two. This resulting average rank would then be used to select a funding source for funding the transaction by selecting the funding source with the highest average rank. The payment service may also allow purchasers or merchants to provide weights to the various funding sources that would be taken into account when calculating a combined rank based on both the purchaser's and merchant's preferred payment method. These weights could then be taken into account when determining which funding source to use such that a more heavily weighted funding source would be more likely to be selected. The transaction would then be conducted in step 306 through a transfer of funds affected by a server in communication with a back end payment processing system. The server could have the characteristics of server 135.
The method described with reference to
In step 430 of
In the case where the funding source choice is determined by data associated with the purchase, a look-up-table such as that shown in Table A below could be used:
In this case, the data associated with the purchase used to select a funding source for the transaction is the purchase price. Other purchase data that could be used as criteria for funding source selection include the purchase type (service, item, etc.), the time of day or the day of the week, the number of items, or other criteria, as well as combinations of these criteria. Although this example shows a single prioritized funding source for each potential range of the purchase price, it is also possible for multiple funding sources to be prioritized for each potential range. This particular approach would be beneficial in situations where certain funding sources were not allowed by potential merchants for the purchaser's transactions or where the payment service offered merchants the option to specify their prioritized funding sources as was discussed with references to
In the case where the funding source choice is determined by on a history of purchases made by the purchaser at the merchant, various factors can be taken into account. For example, if the purchaser had established a sufficient relationship with the merchant through repeat business and/or with transactions that exceed a certain size, the merchant might be able to specify that certain less reliable funding sources may be used by purchaser. As another example, a purchaser history of the user may be used to select a coupon or discount that is specific to the user to be applied to the purchase transactions. The discount or coupon could be based on the purchaser buying a certain quantity of a particular item, or could be awarded based on a total amount of money spent by the purchaser in transactions with the merchant.
In step 440 of
The purchaser, possibly in combination with the merchant, may set up the database 135 a priori. The purchaser may input a list of funding sources, for example, using a web site form, or by filling out a physical form and mailing it. The purchaser may also input a list of merchants who are able to use this service. The purchaser may allow a different set of funding sources for each merchant. The purchaser may also submit identification information, for example, a mobile phone number, which the server may use to verify the purchaser's identity during later transactions. The external server 130 would ultimately receive this information (funding sources, merchants included, and identity data), and store it in the database 135. The server may then issue a compact identity code to the purchaser, for example, a secure personal identification number, or secure PIN, to be used during later transactions. The server may send this PIN to the purchaser, for example, in an e-mail, or via a postal service.
For merchants who maintain a database on-site (connected to the POS device via a LAN, for example), server 130 may download the database (or changes in the database) periodically to merchant's network, for example, hourly, or daily, or weekly. If the POS device is not connected to an open or external network, the database can be updated physically, for example, using a memory device via a Universal Serial Bus (USB) or Secure Digital (SD) port or slot on a computer connected to the POS device via a LAN.
Embodiments of the present invention include on-line purchase transactions as well as POS transactions.
The above description illustrates various embodiments along with examples of how aspects of the present invention may be implemented. For example, direct communication, U.S. mail, phone calls, text messages, data messages or e-mail through wired or wireless voice or data channels, encrypted or not encrypted, and the like may all be considered communication means for sending any messages required by the system. A mobile device may be a mobile phone, two-way pager, tablet or notebook computer, and the like. A compact identity code may be a PIN, or a pseudorandom code, or the like.
The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present disclosure as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents will be evident to those skilled in the art and may be employed without departing from the spirit and scope of the disclosure as defined by the claims.
This application claims the benefit of U.S. Provisional Application No. 61/782,593, filed Mar. 14, 2013, which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61782593 | Mar 2013 | US |
