US20140195431A1 - Aggregate Constraints for Payment Transactions - Google Patents
Aggregate Constraints for Payment Transactions Download PDFInfo
- Publication number
- US20140195431A1 US20140195431A1 US14/181,444 US201414181444A US2014195431A1 US 20140195431 A1 US20140195431 A1 US 20140195431A1 US 201414181444 A US201414181444 A US 201414181444A US 2014195431 A1 US2014195431 A1 US 2014195431A1
- Authority
- US
- United States
- Prior art keywords
- aggregate
- constraints
- act
- user
- price
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/405—Establishing or using transaction specific rules
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
Definitions
- Sellers offer and buyers purchase countless products and services over the Internet. To do so, buyers and sellers typically authorize a payment transaction for each purchase.
- This document describes tools capable of authorizing or enabling authorization of multiple payment transactions without requiring that a buyer or seller authorize each transaction separately.
- the tools may do so by enabling a buyer or seller to select aggregate constraints, such as a total price and number of transactions. Based on these selected constraints, the tools may authorize every payment transaction that meets the aggregate constraints without requiring the buyer to authorize every transaction separately.
- FIG. 1 illustrates an exemplary operating environment in which various embodiments of the tools may operate.
- FIG. 2 illustrates an exemplary flow diagram in which the tools enable a human buyer to select aggregate constraints for multiple payment transactions.
- FIG. 3 illustrates an exemplary flow diagram in which the tools enable a computing-entity buyer to select aggregate constraints for multiple payment transactions.
- FIG. 4 illustrates an exemplary flow diagram in which the tools determine whether or not to authorize a payment transaction based on the aggregate constraints selected in FIG. 2 or FIG. 3 .
- FIG. 5 is an exemplary process illustrating some ways in which the tools may act to authorize or enable authorization of multiple payment transactions without requiring that a buyer or seller authorize each transaction separately.
- FIG. 1 illustrates one such operating environment generally at 100 having four parties to a payment transaction: a buyer 102 ; a seller 104 ; a caller 106 ; and a payment authorizer 108 .
- Each of these parties is shown with a computing device—three with servers and one with a desktop—though each may comprise one or multiple computing devices of various types.
- Each party may comprise one or more processor(s) 110 b, 110 s, 110 c , and 110 pa , respectively, which is capable of accessing and/or executing computer-readable media (CRM) 112 b, 112 s, 112 c, and 112 pa , also respectively.
- CRM computer-readable media
- the buyer, seller, caller, and payment authorizer interact and manage their parts of a payment transaction with a buying module 114 b, a selling module 114 s, a calling module 114 c, and an authorizing module 114 pa , respectively.
- Each communicates with at least one of the others, such as through one or more communication networks 116 (e.g., a company intranet and/or the Internet) or other communication path. If any of these parties share computing resources in a similar location, such communication may either be unnecessary or may be performed without a communication network.
- communication networks 116 e.g., a company intranet and/or the Internet
- Buying module 114 b may include a network browser or other software capable of interacting with the seller and/or caller, either with a human buyer or a computing-entity buyer (e.g., a program interacting with the other parties through Application Program Interfaces (APIs)).
- the selling module similarly acts to provide online sales or services from a website intended for human use or through navigation to a program providing services to a computing-entity buyer.
- Each of the buyer, seller, and caller has associated payment instructions 118 b, 118 s, and 118 c, respectively.
- These payment instructions indicate what types or parameters of payments are approved by each, ways in which payment transactions are desired to be handled, and other information.
- the payment instructions reference contextual data (e.g., variables in payment transactions), parties to the transaction, and the parties' accounts as well as other information.
- the buyer's instructions may be defined or specified such that only payments of less than $100 are authorized.
- the seller's instructions may stipulate that only payments greater than $1.00 be authorized.
- the caller's instructions may require that payments be made through particular banks or other financial entities.
- payment instructions also include a party's preferences or information useful to other entities.
- a seller may indicate that it is willing to pay all fees for a payment transaction but preferably only if the buyer has not specifically agreed to do so.
- a buyer's instructions may include information about the buyer that is useful to the seller but doesn't affect whether or not the payment transaction will be authorized (e.g., the buyer's purchasing trends or extra identifying information).
- any one of these sets of payment instructions may also include aggregate constraints 120 b, 120 s, and 120 c, respectively.
- Aggregate constraints are those that may apply to multiple payment transactions.
- An aggregate constraint may limit a number of payment transactions or a defined number of transactions in a predefined period of time, such as three in one day or five to one seller.
- An aggregate constraint may also limit a dollar amount for a set of multiple payment transactions, such as a $100 maximum to a same seller or $1,000 maximum for one year regardless of the number of sellers. Thus, for example, where the maximum is set to $100, if two payment transactions were previously approved, one for $13.56 and the other for $65.44 for a subtotal of $79.00, the third may only be authorized if it is $21.00 or less.
- Aggregate constraints are described further in other sections.
- the caller 106 includes the calling module 114 c , which is capable of requesting authorization of a payment transaction, also referred to as making a payment “call.”
- This request includes the payment instructions for itself, the buyer, and the seller.
- the buyer and seller sets up or selects an account, payment instructions, and/or aggregate constraints through the calling module or authorizing module.
- the payment authorizer's authorizing module 114 pa is capable of receiving a request for payment from the caller, determining if it should be authorized based on the payment instructions, and then authorizing and/or executing the payment transaction.
- the authorizing module may build and retain a history of prior payment transactions authorized or not authorized. This history may be used to determine if an aggregate constraint is met based on a currently requested payment transaction and prior, related payment transactions.
- FIGS. 2 and 3 show actions by and between calling module 114 c, authorizing module 114 pa , and two buyers.
- the first example is illustrated in FIG. 2 at flow diagram 200 , which shows a human buyer 102 h.
- calling module 114 c enables buyer 102 h to select a set of one or more aggregate constraints for aggregate multiple payment transactions.
- the calling module includes or has access to a user interface 202 through which the user may select from these aggregate constraints.
- the user interface may provide human-readable text indicating selectable aggregate constraints and receive a selected set of aggregate constraints through selection of the human-readable text or graphical indicia associated with the human-readable text.
- the calling module may also enable selection of a user account and other payment instructions.
- the calling module may enable these selections as part of a first purchase (e.g., the first time a buyer attempts to purchase a product or service from a website) or otherwise.
- the calling module enables the buyer to select from the following aggregate constraints: a maximum number of payment transactions; a total monetary cost; a time period for the maximum number; a time period for the total monetary cost; a total maximum monetary cost regardless of any time period; and a total maximum number of payment transactions regardless of any time period.
- a maximum number of payment transactions Assume that the buyer selects a maximum number of payment transactions at 5, the maximum monetary cost at $50, the time period for the maximum number of transactions at one week, the time period for the maximum monetary cost at one month, and a total maximum monetary cost regardless of any time period of $500.
- the calling module builds, at arrow 2-2, the set of constraints 120 b. These constraints are included with payment instructions 118 b as shown in FIG. 2 at 120 b .
- the constraint For a maximum number of payment transactions of 5 with a time period of one week, the constraint may be expressed as:
- the constraint For a maximum monetary cost of $50 with a time period of one month, the constraint may be expressed as:
- the calling module may enable the buyer to select all of these constraints at one time (i.e., as part of a discrete set of interactions). Also note that these constraints may be selected prior to a first requested payment transaction being requested or authorized, such as by enabling a buyer to go online, set up an account, decide on other, non-aggregate payment instructions, and decide on aggregate constraints prior to requesting any payment transactions. A human buyer may do this through the buying module (e.g., a network browser) and user interface 202 of the calling module 114 c.
- a network browser e.g., a network browser
- the set of multiple payment transactions to which the aggregate constraints applies may be governed by payment instructions as well as the aggregate constraints themselves. For example, if a particular buyer attempts to purchase a product, the aggregate constraints may or may not apply to a payment transaction for that purchase. If the payment transaction is not within either of the two selected time periods, then the aggregate constraints may not apply. If they do not apply, the payment transaction may not be authorized or may simply be handled without reference to the aggregate constraints (e.g., require a separate authorization). Or the payment instructions may indicate that the set of multiple payment transactions is only for some sellers, or a particular seller, or for a particular bank, and so forth. Thus, in some cases the aggregate constraints may indicate that requested payment transactions must follow the aggregate constraints but only within a time period and only for a particular seller.
- aggregate constraints e.g., an amount and number of payment transactions
- aggregate constraints may indicate that requested payment transactions must follow the aggregate constraints without regard to a particular time period.
- the buyer “Billy” from the Background Section may be enabled by the calling module to select a set of five online-gaming sellers and a time-period of one month. He may also select that the total monetary cost for payment transactions requested through those sellers and during a defined period be $100. But he may forgo setting a maximum number of transactions during that period. In so doing, he may choose to play a game online for $0.30, a hundred separate times within that month, and some other games from other sellers, so long as the total of the payment transactions add up to $100 or less within the one-month time-period. Here, he may play over a hundred separate games in a month without separately authorizing any of them. Billy simply begins playing the games whenever and however he likes so long as the cumulative cost of the games does not exceed his $100 limit per month.
- the calling module passes payment instructions 118 b and aggregate constraints 120 b to authorizing module 114 pa .
- the authorizing module receives the payment instructions and aggregate constraints.
- the authorizing module then builds a unique identifier 204 for those aggregate constraints, shown at arrow 2-4.
- This unique identifier also called a “token”, may indicate aggregate constraints by including the aggregate constraints within the unique identifier. It may also or instead indicate a location to find the constraints or a manner in which to determine those constraints, such as in history 122 of FIG. 1 .
- the unique identifier is usable to determine the payment instructions and aggregate constraints, is cryptographically unique (e.g., encoded), and is a long string of alphanumeric characters.
- the authorizing module retains a copy of this unique identifier 204 and associates it with the payment instructions (including the aggregate constraints). It then passes the unique identifier to the calling module at arrow 2-5.
- the calling module passes the unique identifier to the buyer module at arrow 2-6.
- the buying module may later use this unique identifier to purchase items without requiring the buyer to separately authorize payment transactions for each purchase.
- FIG. 3 shows a computing-entity buyer 102 ce .
- the tools enable computing-entity buyer 102 ce to select aggregate constraints for multiple payment transactions.
- This example shows the entities and actions of the above example except as noted below.
- Computing-entity buyer 102 ce may include or interact with buying module 114 b of FIG. 1 to select aggregate constraints.
- the buying module here does not include a network browser but instead contains application program interfaces (API) through which the buying module may enable the computing-entity buyer to select aggregate constraints made available through program interface 304 .
- API application program interfaces
- the buying module uses APIs effective to cause the program interface to receive selected aggregate constraints.
- the other actions and interactions at arrows 3-2 to 3-6 may act is substantially the same manner as their counterparts in FIG. 2 but in the context of a computing-entity buyer.
- This and other computing-entity buyers and sellers may desire to purchase or sell items without separately authorizing payment transactions for each. Examples of these include websites that desire to purchase items and services from other computing entities.
- a search website may wish to use a mapping service of another computing entity (e.g., a computing-entity seller) and pay for each use so long as such use is within certain aggregate constraints. Every time a user of the buyer's search website uses the mapping service through the buyer's website, the buyer may authorize a payment transaction for one cent, for example.
- the buyer and/or seller may purchase or sell this mapping service without a separate authorization for each (or any authorization outside of selecting constraints and payment instructions).
- the tools permit selection of aggregate constraints.
- the tools permit buyers and sellers (or even callers) to authorize payment transactions for items and services without separate authorizations for each.
- buyer 102 e.g., 102 ce or 102 h
- buying module 114 b interacts with selling module 114 s to purchase an item or service.
- the buying module may send, and the selling module may receive, the unique identifier 204 built in FIG. 2 or 3 .
- the buyer may not have made any explicit authorization for a payment transaction. Instead, a human buyer desiring to play video games may just select to play the game. Or, also instead, a human buyer may simply select an item (e.g., a CD in the above example) with nothing more.
- a payment request is made.
- a payment transaction may be authorized, also without further interaction from the buyer.
- the buyer may enable users to use the seller's mapping service automatically and without any explicit authorization by the buyer or its users.
- the selling module transmits the buyer's unique identifier and the seller's payment instructions 118 s (including aggregate constraints 120 s, if any), to the caller 106 .
- the seller's payment instructions may be sent in total or the selling module may send a seller's unique identifier built similarly to that of the buyer's unique identifier (not shown). This seller's unique identifier is usable to determine the seller's payment instructions and aggregate constraints at a future part of the process.
- the caller receives the buyer's unique identifier 204 and the seller's payment instructions 118 s at arrow 4-2.
- the caller's calling module combines the buyer's unique identifier, the seller's payment instructions, and the caller's payment instructions into a payment request, shown at arrow 4-3.
- This request is shown at 402 and includes this information as well as information specific to the purchase 404 .
- This information here includes the buyer's identity (though this is also determinable with the buyer's unique identifier), the seller's identity (also determinable), the caller's identity (also determinable), the date of the attempted purchase (e.g., Dec. 13, 2005), and the cost (e.g., an online game to be played for $1.12).
- the payment request may include the following: 1) the caller's payment instructions 118 c indicating the caller's identity and that the caller is not paying any fees for this payment transaction; 2) the seller's payment instructions 118 s indicating the seller's identity, that the payment transaction can only be for receiving money (i.e., the seller is not sending money), that payments may be received only from credit cards and bank accounts, that the amount of payment must be at least $0.10, and that the seller agrees to pay the fee for this payment transaction; 3) the buyer's unique identifier 204 , which is associated with the buyer's payment instructions and aggregate constraints; and 4) information 404 including the price of $1.12 and the date of Dec. 13, 2005.
- the buyer's payment instructions indicate which sellers may receive payments (e.g., one of five online game sellers), that money may only be sent (not received), and the credit card number in the buyer's account.
- the buyer's aggregate constraints indicate that the maximum monetary cost is $100 in a period of one month beginning Dec. 1, 2005 and that there are no maximum number of payment transaction or any period for a number of payments.
- the authorizing module 114 pa receives the payment request from the caller.
- the authorizing module determines what are the payment instructions 118 b and aggregate constraints 120 b based on the unique identifier 204 .
- the authorizing module retained the buyer's payment instructions including aggregate constraints in the history 122 as part of the actions illustrated in FIG. 2 or 3 .
- the authorizing module decodes the unique identifier and determines the appropriate instructions and constraints. As noted above, these include the maximum monetary cost and the purchase date.
- the result of arrows 4-4 is a decoded payment request 406 including all payment instructions (and aggregate constraints) for the buyer, seller, and caller, and information 404 .
- the authorizing module determines whether or not the aggregate constraints of the payment request are met.
- the buyer has aggregate constraints of $100 within a period of one month beginning Dec. 1, 2005.
- the authorizing module determines whether this particular payment request, when aggregated with all prior authorized payment requests within this period or associated with this unique identifier, are or are not met.
- the authorizing module refers to the history 122 .
- the history 122 shows that this unique identifier has been used twice before and that two payments were authorized. These two were also for online games within the Dec. 1, 2005 to Dec. 31, 2005 time-period. The first was on Dec. 2, 2005 for $3.43 and the second was on Dec. 4, 2005 for $1.11.
- the authorizing module determines that the aggregate constraints are met and the transaction proceeds.
- the authorizing module determines if the other, non-aggregate payment instructions are also met. For example, the authorizing module may determine if the seller is one of the five authorized sellers. If the authorizing module determines that all of the payment instructions for all three entities are met, the authorizing module authorizes or enables execution of the payment transaction at arrow 4-6. This authorization may indicate to some other entity to actually make the payment, here payer 408 .
- the authorizing module records the authorization, payment instructions, and information in the history 122 .
- the history now includes three payments authorized for the buyer's unique identifier.
- the authorizing module may use this history for the next requested payment having this unique identifier.
- FIGS. 2 through 4 may be implemented in any suitable hardware, software, firmware, or combination thereof; in the case of software and firmware, this process and any of these flow diagrams represent sets of operations implemented as computer-executable instructions stored in computer-readable media and executable by one or more processors.
- Block 502 of FIG. 5 enables a user to select a set of one or more aggregate constraints for aggregate multiple payment transactions.
- aggregate constraints may include many factors or conditions that a buyer, seller, or caller may want to select for a set of aggregate payment transactions, such as a maximum total monetary cost of the multiple transactions, a maximum total number of multiple transactions, and time periods for each or both.
- Block 502 may enable a user to select these aggregate constraints prior to or incident with an attempt to purchase.
- a buyer may select constraints when he or she attempts to purchase a first of many items or services.
- a seller or caller may do the same.
- Users may also select constraints prior to any purchases, such as a buyer setting up an account on the seller's website either with or without help from the caller.
- Block 502 may also enable a user to select aggregate constraints for many transactions at one time. As described in the above examples, this enables a user (be it buyer, seller, or caller), to implicitly authorize many transactions without explicitly or separately authorizing any of them.
- Block 502 may enable these actions for people or remote software applications, such as with a user interface for a human buyer or APIs for computing-entity buyers or sellers. Examples of these are set forth above.
- block 504 Responsive to the act of enabling the user to select constraints, block 504 receives a selected set of one or more aggregate constraints. As noted in the examples above, this may be through a user interface or a program interface using APIs or other known manner.
- the calling module 114 c of FIGS. 1-4 may enable, in some embodiments, both of blocks 502 and 504 , either with direct communication with a user or through another entity. In the above examples the calling module interacts directly with a buyer, though it may also work in conjunction with a seller to interact with the buyer (e.g., by enabling a buyer to set up an account and select constraints through the seller's website).
- Block 506 builds a unique identifier associated with the selected aggregate constraints.
- this unique identifier may include or be usable to determine the selected aggregate constraints.
- the unique identifier is an encoded alphanumeric string built and usable by the authorizing module to find the associated aggregate constraints.
- the unique identifier may be retained by the user for multiple uses, such as if the buyer retains its unique identifier and passes it to many different sellers for many different requests to purchase items or services.
- Block 508 receives a request to execute a payment transaction constrained by the selected set of aggregate constraints.
- the tools determine if a particular requested payment transaction is associated with the selected set of aggregate constraints. The tools may do so based on an association between the payment transaction and the unique identifier, such by the payment transaction including the unique identifier as part of a payment call.
- Block 510 determines whether the selected set of aggregate constraints are satisfied based on information associated with the payment transaction and, in many cases, a history of one or more prior payment transactions of the aggregate multiple payment transactions. This information may include a price, time, and identify of the parties to the transaction. The history may indicate time periods in which aggregate constraints apply, an aggregate price of payments previously authorized for payment, and a number of transactions previously authorized.
- the tools will not authorize the payment.
- the history indicates that 100 payment transactions have previously been authorized or executed and which are associated with these aggregate constraints, the tools will not authorize a requested 101 st payment transaction if the maximum total number of payment transactions is 100. This assumes that there is no time period set or that they are all within a set time period.
- block 510 determines that the aggregate constraints are satisfied, the tools may proceed to block 512 or 514 along either “Yes” path. If they are not satisfied, block 510 proceeds along the “No” path to block 516 .
- the tools may—but are not required—to authorize execution of or execute the requested payment transaction if the aggregate constraints are met. If the tools proceed to block 512 , they first determine whether other, non-aggregate payment instructions are met. Block 512 may do so by receiving an indication that other non-aggregate payment instructions (e.g., payment instructions 118 excluding aggregate constraints 120 ) are or are not satisfied. Block 512 may also do so by itself analyzing the non-aggregate payment instructions to determine if they are met.
- non-aggregate payment instructions e.g., payment instructions 118 excluding aggregate constraints 120
- block 510 determined that the requested payment transaction meets the selected aggregate constraints.
- block 512 determines that the selected payment transaction is for $0.70 and that the non-aggregate payment instructions indicate that the minimum payment transaction is $1.00. In this case block 512 will not authorize the payment transaction even though the aggregate constraints are met.
- Other examples of how the tools may determine to authorize requested payment transactions are set forth above.
- block 512 determines that the non-aggregate payment instructions are also satisfied, it proceeds along a “Yes” path to block 514 . Otherwise it proceeds along a “No” path to block 516 . Block 516 refrains from authorizing or executing the requested payment transaction.
- Block 514 authorizes or executes the requested payment transaction in response to block 510 or 512 .
- the tools proceed to block 518 .
- Block 518 records information about the authorized payment transaction, such as its price, time period, and identity of the parties to the transaction. This record (e.g., history 122 of FIG. 1 ) is usable for successive iterations of process 500 or its parts (e.g., blocks 508 - 514 ) by which the tools may determine if aggregate constraints of future requested payment transactions are met.
- the above-described tools are capable of authorizing or enabling authorization of multiple payment transactions without requiring that a buyer or seller authorize each transaction separately. By so doing, the tools enable parties to payment transactions to forgo authorizing each payment transaction.
- a buyer for example, may forgo tens, hundreds, or even millions of separate payment authorizations by selecting aggregate constraints for those payment transactions.
Abstract
This document describes tools capable of authorizing or enabling authorization of multiple payment transactions without requiring that a buyer or seller authorize each transaction separately. The tools may do so by enabling a buyer or seller to select aggregate constraints, such as a total price or number of transactions. Based on these selected constraints, the tools may authorize every payment transaction that meets the aggregate constraints without requiring the buyer to authorize every transaction separately.
Description
- This application is a divisional of U.S. patent application Ser. No. 11/694,459, filed on Mar. 30, 2007, which claims the benefit of U.S. Provisional Application No. 60/882,855, filed on Dec. 29, 2006. The entire contents of both of these applications are incorporated herein by reference.
- Sellers offer and buyers purchase countless products and services over the Internet. To do so, buyers and sellers typically authorize a payment transaction for each purchase.
- Assume, for example, that a buyer named “Bonnie” purchases three items from a seller named “Sam”. Bonnie purchases a book from Sam on Monday, a DVD on Wednesday, and downloads a song on Friday. To pay for these items, Bonnie first sets up an account on Sam's website, enters her name, credit-card number, and address. On Monday she selects the book, is directed to a purchase screen where she checks on the price and other details, and then selects to purchase the book. On Wednesday she selects the DVD and, even if her account information is saved and readily available, she still has to check through the price and other details before she can select to purchase the DVD. On Friday she selects the song, checks that the price and other details are correct, and then selects to purchase the music. Bonnie separately authorized three different payment transactions.
- Assume, also for example, that a buyer name “Billy” wants to purchase the right to play video games online from many different sellers of online gaming services. Each time he wants to play a game he may need to authorize a payment transaction. If he plays two games on Monday, one on Tuesday, and twelve games on Saturday, he may need to separately authorize fifteen payment authorizations. As this and the other example illustrates, requiring a buyer to separately authorize payment transactions for multiple items or services can be tedious and time consuming.
- This document describes tools capable of authorizing or enabling authorization of multiple payment transactions without requiring that a buyer or seller authorize each transaction separately. The tools may do so by enabling a buyer or seller to select aggregate constraints, such as a total price and number of transactions. Based on these selected constraints, the tools may authorize every payment transaction that meets the aggregate constraints without requiring the buyer to authorize every transaction separately.
- This Summary introduces, in a simplified form, a subset of the concepts that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The term “tools,” for instance, may refer to system(s), method(s), computer-readable instructions, and/or technique(s) as permitted by the context above and throughout the document.
-
FIG. 1 illustrates an exemplary operating environment in which various embodiments of the tools may operate. -
FIG. 2 illustrates an exemplary flow diagram in which the tools enable a human buyer to select aggregate constraints for multiple payment transactions. -
FIG. 3 illustrates an exemplary flow diagram in which the tools enable a computing-entity buyer to select aggregate constraints for multiple payment transactions. -
FIG. 4 illustrates an exemplary flow diagram in which the tools determine whether or not to authorize a payment transaction based on the aggregate constraints selected inFIG. 2 orFIG. 3 . -
FIG. 5 is an exemplary process illustrating some ways in which the tools may act to authorize or enable authorization of multiple payment transactions without requiring that a buyer or seller authorize each transaction separately. - The same numbers are used throughout the disclosure and figures to reference like components and features.
- An environment in which the tools may enable these and other actions is set forth below in a section entitled Exemplary Operating Environment. This section is followed by another section describing exemplary ways in which the tools may act to enable selection of aggregate constraints for multiple payment transactions and is entitled Aggregate Constraints. The next section is entitled Multiple Payment Transactions, and describes exemplary ways in which the tools enable authorization of multiple payment transactions without a separate payment authorization for each or an explicit authorization for any of the payments. A final section describes various other embodiments and manners in which the tools may act, and is entitled Other Embodiments of the Tools. This overview, including these section titles and summaries, is provided for the reader's convenience and is not intended to limit the scope of the claims or the entitled sections.
- Before describing the tools in detail, the following discussion of an exemplary operating environment is provided to assist the reader in understanding some ways in which various inventive aspects of the tools may be employed. The environment described below constitutes but one example and is not intended to limit application of the tools to any one particular operating environment. Other environments may be used without departing from the spirit and scope of the claimed subject matter.
-
FIG. 1 illustrates one such operating environment generally at 100 having four parties to a payment transaction: abuyer 102; aseller 104; acaller 106; and apayment authorizer 108. Each of these parties is shown with a computing device—three with servers and one with a desktop—though each may comprise one or multiple computing devices of various types. - Each party may comprise one or more processor(s) 110 b, 110 s, 110 c, and 110 pa, respectively, which is capable of accessing and/or executing computer-readable media (CRM) 112 b, 112 s, 112 c, and 112 pa, also respectively. The buyer, seller, caller, and payment authorizer interact and manage their parts of a payment transaction with a
buying module 114 b, a sellingmodule 114 s, acalling module 114 c, and an authorizing module 114 pa, respectively. Each communicates with at least one of the others, such as through one or more communication networks 116 (e.g., a company intranet and/or the Internet) or other communication path. If any of these parties share computing resources in a similar location, such communication may either be unnecessary or may be performed without a communication network. - Buying
module 114 b may include a network browser or other software capable of interacting with the seller and/or caller, either with a human buyer or a computing-entity buyer (e.g., a program interacting with the other parties through Application Program Interfaces (APIs)). The selling module similarly acts to provide online sales or services from a website intended for human use or through navigation to a program providing services to a computing-entity buyer. - Each of the buyer, seller, and caller has associated
payment instructions - The buyer's instructions, for example, may be defined or specified such that only payments of less than $100 are authorized. The seller's instructions, for example, may stipulate that only payments greater than $1.00 be authorized. The caller's instructions may require that payments be made through particular banks or other financial entities. In some cases, payment instructions also include a party's preferences or information useful to other entities. A seller, for example, may indicate that it is willing to pay all fees for a payment transaction but preferably only if the buyer has not specifically agreed to do so. Or, also for example, a buyer's instructions may include information about the buyer that is useful to the seller but doesn't affect whether or not the payment transaction will be authorized (e.g., the buyer's purchasing trends or extra identifying information).
- Any one of these sets of payment instructions may also include
aggregate constraints - In one implementation, the
caller 106 includes thecalling module 114 c, which is capable of requesting authorization of a payment transaction, also referred to as making a payment “call.” This request includes the payment instructions for itself, the buyer, and the seller. The buyer and seller sets up or selects an account, payment instructions, and/or aggregate constraints through the calling module or authorizing module. - The payment authorizer's authorizing module 114 pa is capable of receiving a request for payment from the caller, determining if it should be authorized based on the payment instructions, and then authorizing and/or executing the payment transaction. The authorizing module may build and retain a history of prior payment transactions authorized or not authorized. This history may be used to determine if an aggregate constraint is met based on a currently requested payment transaction and prior, related payment transactions.
- This section describes two examples where the tools enable selection of aggregate constraints for multiple payment transactions. These examples are implementations of the tools but are not intended to limit the scope of the tools or the claimed embodiments.
- These examples are illustrated in
FIGS. 2 and 3 , which show actions by and between callingmodule 114 c, authorizing module 114 pa, and two buyers. The first example is illustrated inFIG. 2 at flow diagram 200, which shows ahuman buyer 102 h. - At arrow 2-1 in
FIG. 2 , callingmodule 114 c enablesbuyer 102 h to select a set of one or more aggregate constraints for aggregate multiple payment transactions. Here, the calling module includes or has access to auser interface 202 through which the user may select from these aggregate constraints. For example, the user interface may provide human-readable text indicating selectable aggregate constraints and receive a selected set of aggregate constraints through selection of the human-readable text or graphical indicia associated with the human-readable text. The calling module may also enable selection of a user account and other payment instructions. The calling module may enable these selections as part of a first purchase (e.g., the first time a buyer attempts to purchase a product or service from a website) or otherwise. - The calling module enables the buyer to select from the following aggregate constraints: a maximum number of payment transactions; a total monetary cost; a time period for the maximum number; a time period for the total monetary cost; a total maximum monetary cost regardless of any time period; and a total maximum number of payment transactions regardless of any time period. Assume that the buyer selects a maximum number of payment transactions at 5, the maximum monetary cost at $50, the time period for the maximum number of transactions at one week, the time period for the maximum monetary cost at one month, and a total maximum monetary cost regardless of any time period of $500. Responsive to this selection, the calling module builds, at arrow 2-2, the set of
constraints 120 b. These constraints are included withpayment instructions 118 b as shown inFIG. 2 at 120 b. For a maximum number of payment transactions of 5 with a time period of one week, the constraint may be expressed as: -
- MyTokenUsageLimit1<=5;
- MyTokenUsageLimit1Type=‘Count’;
- MyTokenUsageLimit1Duration=1 week;
- MyTokenUsageLimit1Start=‘2005-05-01 12:00 PST’;
- For a maximum monetary cost of $50 with a time period of one month, the constraint may be expressed as:
-
- MyTokenUsageLimit2<=50;
- MyTokenUsageLimit2Type=‘Amount’;
- MyTokenUsageLimit2Duration=1 Month;
- MyTokenUsageLimit2Start=‘2005-05-01 12:00 PST’;
- For a total maximum monetary cost regardless of any time period of $500, the constraint may be expressed as:
-
- MyTokenUsageLimit3<=500;
- MyTokenUsageLimit3Type=‘Amount’;
- Note that the calling module may enable the buyer to select all of these constraints at one time (i.e., as part of a discrete set of interactions). Also note that these constraints may be selected prior to a first requested payment transaction being requested or authorized, such as by enabling a buyer to go online, set up an account, decide on other, non-aggregate payment instructions, and decide on aggregate constraints prior to requesting any payment transactions. A human buyer may do this through the buying module (e.g., a network browser) and
user interface 202 of thecalling module 114 c. - The set of multiple payment transactions to which the aggregate constraints applies may be governed by payment instructions as well as the aggregate constraints themselves. For example, if a particular buyer attempts to purchase a product, the aggregate constraints may or may not apply to a payment transaction for that purchase. If the payment transaction is not within either of the two selected time periods, then the aggregate constraints may not apply. If they do not apply, the payment transaction may not be authorized or may simply be handled without reference to the aggregate constraints (e.g., require a separate authorization). Or the payment instructions may indicate that the set of multiple payment transactions is only for some sellers, or a particular seller, or for a particular bank, and so forth. Thus, in some cases the aggregate constraints may indicate that requested payment transactions must follow the aggregate constraints but only within a time period and only for a particular seller.
- In some other cases, however, aggregate constraints (e.g., an amount and number of payment transactions) are not bound to a particular time period. In these cases the aggregate constraints may indicate that requested payment transactions must follow the aggregate constraints without regard to a particular time period.
- The buyer “Billy” from the Background Section, for example, may be enabled by the calling module to select a set of five online-gaming sellers and a time-period of one month. He may also select that the total monetary cost for payment transactions requested through those sellers and during a defined period be $100. But he may forgo setting a maximum number of transactions during that period. In so doing, he may choose to play a game online for $0.30, a hundred separate times within that month, and some other games from other sellers, so long as the total of the payment transactions add up to $100 or less within the one-month time-period. Here, he may play over a hundred separate games in a month without separately authorizing any of them. Billy simply begins playing the games whenever and however he likes so long as the cumulative cost of the games does not exceed his $100 limit per month.
- At arrow 2-3 in
FIG. 2 , the calling module passespayment instructions 118 b andaggregate constraints 120 b to authorizing module 114 pa. The authorizing module receives the payment instructions and aggregate constraints. The authorizing module then builds aunique identifier 204 for those aggregate constraints, shown at arrow 2-4. This unique identifier, also called a “token”, may indicate aggregate constraints by including the aggregate constraints within the unique identifier. It may also or instead indicate a location to find the constraints or a manner in which to determine those constraints, such as inhistory 122 ofFIG. 1 . - In this embodiment the unique identifier is usable to determine the payment instructions and aggregate constraints, is cryptographically unique (e.g., encoded), and is a long string of alphanumeric characters. The authorizing module retains a copy of this
unique identifier 204 and associates it with the payment instructions (including the aggregate constraints). It then passes the unique identifier to the calling module at arrow 2-5. The calling module then passes the unique identifier to the buyer module at arrow 2-6. The buying module may later use this unique identifier to purchase items without requiring the buyer to separately authorize payment transactions for each purchase. - Another example is illustrated in
FIG. 3 at flow diagram 300, which shows a computing-entity buyer 102 ce. In this embodiment, the tools enable computing-entity buyer 102 ce to select aggregate constraints for multiple payment transactions. This example shows the entities and actions of the above example except as noted below. - Computing-
entity buyer 102 ce may include or interact withbuying module 114 b ofFIG. 1 to select aggregate constraints. The buying module here does not include a network browser but instead contains application program interfaces (API) through which the buying module may enable the computing-entity buyer to select aggregate constraints made available throughprogram interface 304. Thus, at arrow 3-1 the buying module uses APIs effective to cause the program interface to receive selected aggregate constraints. The other actions and interactions at arrows 3-2 to 3-6 may act is substantially the same manner as their counterparts inFIG. 2 but in the context of a computing-entity buyer. - This and other computing-entity buyers and sellers may desire to purchase or sell items without separately authorizing payment transactions for each. Examples of these include websites that desire to purchase items and services from other computing entities. A search website, for example, may wish to use a mapping service of another computing entity (e.g., a computing-entity seller) and pay for each use so long as such use is within certain aggregate constraints. Every time a user of the buyer's search website uses the mapping service through the buyer's website, the buyer may authorize a payment transaction for one cent, for example. If the buyer or seller selects aggregate constraints permitting a maximum number of payment transactions in a period, e.g., 100,000 per day, with a minimum and maximum cost of one cent, the buyer and/or seller may purchase or sell this mapping service without a separate authorization for each (or any authorization outside of selecting constraints and payment instructions).
- In any case, whether the entity selecting aggregate constraints is a buyer or seller or human or computing entity, the tools permit selection of aggregate constraints. With these aggregate constraints—here indicated with
unique identifier 204—the tools permit buyers and sellers (or even callers) to authorize payment transactions for items and services without separate authorizations for each. These examples continue in the following section in which the unique identifier is used by the authorization module to determine whether or not to authorize payment transactions. - This section continues the above examples in part and describes ways in which the tools determine whether or not to authorize payment transactions based on the aggregate constraints selected above and indicated in the
unique identifier 204 ofFIGS. 2 and 3 . These examples are implementations of the tools but are not intended to limit the scope of the tools or the claimed embodiments. - At arrow 4-1 illustrated in
FIG. 4 at 400, buyer 102 (e.g., 102 ce or 102 h) throughbuying module 114 b interacts with sellingmodule 114 s to purchase an item or service. As part of this interaction the buying module may send, and the selling module may receive, theunique identifier 204 built inFIG. 2 or 3. Note that the buyer (whether human or not) may not have made any explicit authorization for a payment transaction. Instead, a human buyer desiring to play video games may just select to play the game. Or, also instead, a human buyer may simply select an item (e.g., a CD in the above example) with nothing more. Following this selection and without requiring an explicit authorization (or, in some cases, an additional interaction of any kind) from the buyer, a payment request is made. After the request is made, a payment transaction may be authorized, also without further interaction from the buyer. In the case of the above computing-entity buyer, the buyer may enable users to use the seller's mapping service automatically and without any explicit authorization by the buyer or its users. - At arrow 4-2 the selling module transmits the buyer's unique identifier and the seller's
payment instructions 118 s (including aggregate constraints 120 s, if any), to thecaller 106. The seller's payment instructions may be sent in total or the selling module may send a seller's unique identifier built similarly to that of the buyer's unique identifier (not shown). This seller's unique identifier is usable to determine the seller's payment instructions and aggregate constraints at a future part of the process. - The caller receives the buyer's
unique identifier 204 and the seller'spayment instructions 118 s at arrow 4-2. In response, the caller's calling module combines the buyer's unique identifier, the seller's payment instructions, and the caller's payment instructions into a payment request, shown at arrow 4-3. This request is shown at 402 and includes this information as well as information specific to thepurchase 404. This information here includes the buyer's identity (though this is also determinable with the buyer's unique identifier), the seller's identity (also determinable), the caller's identity (also determinable), the date of the attempted purchase (e.g., Dec. 13, 2005), and the cost (e.g., an online game to be played for $1.12). - Continuing one of the above examples, the payment request may include the following: 1) the caller's
payment instructions 118 c indicating the caller's identity and that the caller is not paying any fees for this payment transaction; 2) the seller'spayment instructions 118 s indicating the seller's identity, that the payment transaction can only be for receiving money (i.e., the seller is not sending money), that payments may be received only from credit cards and bank accounts, that the amount of payment must be at least $0.10, and that the seller agrees to pay the fee for this payment transaction; 3) the buyer'sunique identifier 204, which is associated with the buyer's payment instructions and aggregate constraints; and 4)information 404 including the price of $1.12 and the date of Dec. 13, 2005. - The buyer's payment instructions indicate which sellers may receive payments (e.g., one of five online game sellers), that money may only be sent (not received), and the credit card number in the buyer's account. The buyer's aggregate constraints indicate that the maximum monetary cost is $100 in a period of one month beginning Dec. 1, 2005 and that there are no maximum number of payment transaction or any period for a number of payments.
- At arrow 4-3 the authorizing module 114 pa receives the payment request from the caller. At arrows 4-4 the authorizing module determines what are the
payment instructions 118 b andaggregate constraints 120 b based on theunique identifier 204. The authorizing module retained the buyer's payment instructions including aggregate constraints in thehistory 122 as part of the actions illustrated inFIG. 2 or 3. With the prior association between the unique identifier and the payment instructions and aggregate constraints, the authorizing module decodes the unique identifier and determines the appropriate instructions and constraints. As noted above, these include the maximum monetary cost and the purchase date. The result of arrows 4-4 is a decodedpayment request 406 including all payment instructions (and aggregate constraints) for the buyer, seller, and caller, andinformation 404. - At arrow 4-5 the authorizing module determines whether or not the aggregate constraints of the payment request are met. Here the buyer has aggregate constraints of $100 within a period of one month beginning Dec. 1, 2005. Thus, the authorizing module determines whether this particular payment request, when aggregated with all prior authorized payment requests within this period or associated with this unique identifier, are or are not met. To do so, the authorizing module refers to the
history 122. Thehistory 122 shows that this unique identifier has been used twice before and that two payments were authorized. These two were also for online games within the Dec. 1, 2005 to Dec. 31, 2005 time-period. The first was on Dec. 2, 2005 for $3.43 and the second was on Dec. 4, 2005 for $1.11. As the total for these two prior authorized payments is $4.54 and, combined with the requested payment of $1.12 is only $5.66, the aggregate cost for this and prior payments is well under the maximum of $100. Thus, the authorizing module determines that the aggregate constraints are met and the transaction proceeds. - Also as part of arrow 4-5, the authorizing module determines if the other, non-aggregate payment instructions are also met. For example, the authorizing module may determine if the seller is one of the five authorized sellers. If the authorizing module determines that all of the payment instructions for all three entities are met, the authorizing module authorizes or enables execution of the payment transaction at arrow 4-6. This authorization may indicate to some other entity to actually make the payment, here
payer 408. - At arrow 4-7, the authorizing module records the authorization, payment instructions, and information in the
history 122. The history now includes three payments authorized for the buyer's unique identifier. The authorizing module may use this history for the next requested payment having this unique identifier. - Note that the buyer, here Billy—who wanted to play an online video game—was able to do so without an express or explicit authorization. Note also that Billy didn't separately authorize this payment or the other two recorded in the history.
- The above sections describe particular examples where specific entities of the exemplary embodiment, such as the buying, selling, calling, and authorizing modules act and interact to authorize payment transactions. In this section, other embodiments of the tools are described in which the tools are capable of authorizing or enabling authorization of multiple payment transactions without requiring that a buyer or seller authorize each transaction separately.
- These other exemplary embodiments are described as part of
process 500 ofFIG. 5 . This process and the flow diagrams described and illustrated inFIGS. 2 through 4 may be implemented in any suitable hardware, software, firmware, or combination thereof; in the case of software and firmware, this process and any of these flow diagrams represent sets of operations implemented as computer-executable instructions stored in computer-readable media and executable by one or more processors. -
Block 502 ofFIG. 5 enables a user to select a set of one or more aggregate constraints for aggregate multiple payment transactions. These aggregate constraints may include many factors or conditions that a buyer, seller, or caller may want to select for a set of aggregate payment transactions, such as a maximum total monetary cost of the multiple transactions, a maximum total number of multiple transactions, and time periods for each or both. Some of the above examples, for instance, provide for an aggregate price and an aggregate number of transactions. -
Block 502 may enable a user to select these aggregate constraints prior to or incident with an attempt to purchase. Thus, a buyer may select constraints when he or she attempts to purchase a first of many items or services. Likewise, a seller or caller may do the same. Users may also select constraints prior to any purchases, such as a buyer setting up an account on the seller's website either with or without help from the caller. -
Block 502 may also enable a user to select aggregate constraints for many transactions at one time. As described in the above examples, this enables a user (be it buyer, seller, or caller), to implicitly authorize many transactions without explicitly or separately authorizing any of them. -
Block 502 may enable these actions for people or remote software applications, such as with a user interface for a human buyer or APIs for computing-entity buyers or sellers. Examples of these are set forth above. - Responsive to the act of enabling the user to select constraints, block 504 receives a selected set of one or more aggregate constraints. As noted in the examples above, this may be through a user interface or a program interface using APIs or other known manner. The calling
module 114 c ofFIGS. 1-4 may enable, in some embodiments, both ofblocks -
Block 506 builds a unique identifier associated with the selected aggregate constraints. As noted above, this unique identifier may include or be usable to determine the selected aggregate constraints. In the above examples the unique identifier is an encoded alphanumeric string built and usable by the authorizing module to find the associated aggregate constraints. The unique identifier may be retained by the user for multiple uses, such as if the buyer retains its unique identifier and passes it to many different sellers for many different requests to purchase items or services. -
Block 508 receives a request to execute a payment transaction constrained by the selected set of aggregate constraints. In some cases the tools determine if a particular requested payment transaction is associated with the selected set of aggregate constraints. The tools may do so based on an association between the payment transaction and the unique identifier, such by the payment transaction including the unique identifier as part of a payment call. -
Block 510 determines whether the selected set of aggregate constraints are satisfied based on information associated with the payment transaction and, in many cases, a history of one or more prior payment transactions of the aggregate multiple payment transactions. This information may include a price, time, and identify of the parties to the transaction. The history may indicate time periods in which aggregate constraints apply, an aggregate price of payments previously authorized for payment, and a number of transactions previously authorized. - For example, if the information indicates that the price for the requested payment transaction is above a maximum monetary cost when aggregated (e.g., summed) with the aggregate monetary cost of previously authorized payment transactions that are associated with the same set of aggregate constraints, the tools will not authorize the payment. Similarly, if the history indicates that 100 payment transactions have previously been authorized or executed and which are associated with these aggregate constraints, the tools will not authorize a requested 101st payment transaction if the maximum total number of payment transactions is 100. This assumes that there is no time period set or that they are all within a set time period.
- If
block 510 determines that the aggregate constraints are satisfied, the tools may proceed to block 512 or 514 along either “Yes” path. If they are not satisfied, block 510 proceeds along the “No” path to block 516. - The tools may—but are not required—to authorize execution of or execute the requested payment transaction if the aggregate constraints are met. If the tools proceed to block 512, they first determine whether other, non-aggregate payment instructions are met.
Block 512 may do so by receiving an indication that other non-aggregate payment instructions (e.g., payment instructions 118 excluding aggregate constraints 120) are or are not satisfied.Block 512 may also do so by itself analyzing the non-aggregate payment instructions to determine if they are met. - Assume, for example, that
block 510 determined that the requested payment transaction meets the selected aggregate constraints. Assume also thatblock 512 determines that the selected payment transaction is for $0.70 and that the non-aggregate payment instructions indicate that the minimum payment transaction is $1.00. In this case block 512 will not authorize the payment transaction even though the aggregate constraints are met. Other examples of how the tools may determine to authorize requested payment transactions are set forth above. - If
block 512 determines that the non-aggregate payment instructions are also satisfied, it proceeds along a “Yes” path to block 514. Otherwise it proceeds along a “No” path to block 516.Block 516 refrains from authorizing or executing the requested payment transaction. -
Block 514 authorizes or executes the requested payment transaction in response to block 510 or 512. Once authorized, the tools proceed to block 518.Block 518 records information about the authorized payment transaction, such as its price, time period, and identity of the parties to the transaction. This record (e.g.,history 122 ofFIG. 1 ) is usable for successive iterations ofprocess 500 or its parts (e.g., blocks 508-514) by which the tools may determine if aggregate constraints of future requested payment transactions are met. - By way of review, consider the online-gaming example given above in the context of
process 500. In this example thehistory 122 showed that a unique identifier had been used twice before and that two payments were authorized. These two were for online games within the Dec. 1, 2005 to Dec. 31, 2005 time-period. The first was on Dec. 2, 2005 for $3.43 and the second was on Dec. 4, 2005 for $1.11. The total for these two prior authorized payments is $4.54. Assume that the tools authorized a requested payment transaction for $1.12 because when summed with the prior-authorized payment transactions the sum is only $5.66, which is well under the maximum of $100. The tools, having now authorized a payment transaction for $1.12, record information associated with this payment transaction intohistory 122. Thus, the history may now indicate that three transactions have been authorized for three different sellers and that the total amount authorized is $5.66. If another request is received atblock 508 that also is associated with the same set of aggregate constraints, it may be authorized if the requested amount is less or equal to $94.34 ($100.00−5.66=$94.34). - The above-described tools are capable of authorizing or enabling authorization of multiple payment transactions without requiring that a buyer or seller authorize each transaction separately. By so doing, the tools enable parties to payment transactions to forgo authorizing each payment transaction. A buyer, for example, may forgo tens, hundreds, or even millions of separate payment authorizations by selecting aggregate constraints for those payment transactions. Although the tools have been described in language specific to structural features and/or methodological acts, it is to be understood that the tools defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the tools.
Claims (20)
1. A method implemented at least in part by a computing device comprising:
enabling a user to select an aggregate price or aggregate quantity of transactions for a set of multiple payment transactions;
receiving, from the user and responsive to the act of enabling, a selected aggregate price or aggregate quantity; and
providing a unique identifier associated with the selected aggregate price or aggregate quantity effective to: enable a payment transaction requested by or associated with the user to be associated with the selected aggregate price or aggregate quantity; and enable a determination of whether the requested payment transaction satisfies the selected aggregate price or aggregate quantity when aggregated with a previously authorized or executed payment transaction of the set of multiple payment transactions.
2. The method of claim 1 , wherein the act of enabling the user further enables the user to select a time period for the selected aggregate price or aggregate quantity.
3. The method of claim 2 , wherein the act of providing enables a determination of whether the requested payment transaction satisfies the selected aggregate price or aggregate quantity when aggregated with the previously authorized or executed payment transaction and where the previously authorized or executed payment transaction was requested within the time period.
4. The method of claim 1 , wherein the act of enabling the user provides a user interface with human-readable text indicating selectable aggregate constraints and the act of receiving receives the aggregate price or aggregate quantity through selection of the human-readable text or graphical indicia associated with the human-readable text.
5. The method of claim 1 , wherein the act of enabling the user provides an application program interface (API) through which a remote software application may interact sufficient to select the aggregate price or aggregate quantity and the act of receiving receives the aggregate price or aggregate quantity through the API.
6. The method of claim 1 , wherein the act of providing enables a determination of whether the requested payment transaction satisfies the selected aggregate price or aggregate quantity without explicit authorization from the user.
7. The method of claim 1 , wherein the act of enabling the user enables the user to select all of the constraints at one time.
8. The method of claim 1 , wherein the unique identifier is a token having a character string.
9. The method of claim 1 , wherein the act of receiving the selected aggregate price or aggregate quantity receives the selected aggregate price or aggregate quantity prior to authorization of or execution of the previously authorized or executed payment transaction.
10. The method of claim 1 , wherein the selected aggregate price or aggregate quantity comprises both a selected aggregate price and a selected aggregate quantity.
11. The method of claim 1 , wherein the selected aggregate price or aggregate quantity comprises only one of a selected aggregate price and a selected aggregate quantity.
12. A method implemented at least in part by a computing device comprising:
enabling a user to select a set of one or more aggregate constraints for aggregate multiple payment transactions; and
receiving, from the user and responsive to the act of enabling, a selected set of one or more aggregate constraints constraining the aggregate multiple payment transactions, the selected set of aggregate constraints effective to enable a determination of whether or not a requested payment transaction meets the selected set of aggregate constraints when the requested payment transaction is aggregated with previously requested payment transactions that met the selected set of aggregate constraints.
13. The method of claim 12 , wherein the act of enabling the user to select the set of one or more aggregate constraints enables the user to select the constraints at one time.
14. The method of claim 12 , wherein the act of receiving the selected set of one or more aggregate constraints receives the set of one or more aggregate constraints prior to authorization of or execution of any of the previously requested payment transactions.
15. The method of claim 12 , wherein the act of enabling the user provides an application program interface (API) through which a remote software application may interact sufficient to select the selected set of aggregate constraints and the act of receiving receives the selected set of aggregate constraints through the API.
16. The method of claim 12 , wherein the act of enabling the user provides a user interface with human-readable text indicating selectable aggregate constraints and the act of receiving receives the selected set of aggregate constraints through selection of the human-readable text or graphical indicia associated with the human-readable text.
17. The method of claim 12 , further comprising receiving a request to authorize or execute the requested payment transaction.
18. The method of claim 17 , further comprising determining that the requested payment transaction meets the selected set of aggregate constraints when the requested payment transaction is aggregated with the previously requested payment transactions that met the selected set of aggregate constraints.
19. The method of claim 12 , wherein one of the selected set of aggregate constraints sets a maximum total monetary cost for the aggregate multiple payment transactions.
20. The method of claim 12 , wherein the one of the selected set of aggregate constraints setting the maximum total monetary cost for the aggregate multiple transactions comprises a time period in which the maximum total monetary cost is based and outside of which transactions are not considered part of the aggregate multiple payment transactions.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/181,444 US20140195431A1 (en) | 2006-12-29 | 2014-02-14 | Aggregate Constraints for Payment Transactions |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US88285506P | 2006-12-29 | 2006-12-29 | |
US11/694,459 US8655786B2 (en) | 2006-12-29 | 2007-03-30 | Aggregate constraints for payment transactions |
US14/181,444 US20140195431A1 (en) | 2006-12-29 | 2014-02-14 | Aggregate Constraints for Payment Transactions |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/694,459 Division US8655786B2 (en) | 2006-12-29 | 2007-03-30 | Aggregate constraints for payment transactions |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140195431A1 true US20140195431A1 (en) | 2014-07-10 |
Family
ID=39585349
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/694,459 Active 2030-02-09 US8655786B2 (en) | 2006-12-29 | 2007-03-30 | Aggregate constraints for payment transactions |
US14/181,444 Abandoned US20140195431A1 (en) | 2006-12-29 | 2014-02-14 | Aggregate Constraints for Payment Transactions |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/694,459 Active 2030-02-09 US8655786B2 (en) | 2006-12-29 | 2007-03-30 | Aggregate constraints for payment transactions |
Country Status (3)
Country | Link |
---|---|
US (2) | US8655786B2 (en) |
EP (1) | EP2102803A4 (en) |
WO (1) | WO2008082960A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016200687A1 (en) * | 2015-06-10 | 2016-12-15 | Chicago Mercantile Exchange Inc. | Transaction processing system performance evaluation |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8175938B2 (en) | 2004-04-13 | 2012-05-08 | Ebay Inc. | Method and system for facilitating merchant-initiated online payments |
US20090106148A1 (en) * | 2007-10-17 | 2009-04-23 | Christian Prada | Pre-paid financial system |
FR2959042A1 (en) * | 2010-04-20 | 2011-10-21 | Marc Guedj | SYSTEM AND METHOD FOR ONLINE PAYMENT FOLLOWING THE PRINCIPLE OF "MIRROR AUTHORIZATION SERVER" |
WO2012112941A2 (en) * | 2011-02-18 | 2012-08-23 | Visa International Service Association | Method and system for managing data and enabling payment transactions between multiple entities |
US20170255935A1 (en) * | 2014-10-10 | 2017-09-07 | Sequitur Labs, Inc. | Policy-Based Control of Online Financial Transactions |
US20200111075A1 (en) * | 2018-10-05 | 2020-04-09 | Visa International Service Association | Method, System, and Computer Program Product for Automatically Combining a Plurality of Separate Orders |
US11699193B2 (en) * | 2020-05-04 | 2023-07-11 | International Business Machines Corporation | Scalable enforcement of aggregation constraints within transactions |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020087427A1 (en) * | 2000-12-28 | 2002-07-04 | Ravi Ganesan | Electronic greeting card with gift payment |
US20070017973A1 (en) * | 2005-07-20 | 2007-01-25 | Arthur Blank & Company, Inc. | Transaction card and envelope assembly |
Family Cites Families (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7028187B1 (en) * | 1991-11-15 | 2006-04-11 | Citibank, N.A. | Electronic transaction apparatus for electronic commerce |
AU2241195A (en) * | 1994-04-06 | 1995-10-30 | Morgan Stanley Group Inc. | Data processing system and method for financial debt instruments |
US20040185830A1 (en) * | 1996-08-08 | 2004-09-23 | Joao Raymond Anthony | Apparatus and method for providing account security |
US7096003B2 (en) * | 1996-08-08 | 2006-08-22 | Raymond Anthony Joao | Transaction security apparatus |
US6636833B1 (en) * | 1998-03-25 | 2003-10-21 | Obis Patents Ltd. | Credit card system and method |
US7742967B1 (en) * | 1999-10-01 | 2010-06-22 | Cardinalcommerce Corporation | Secure and efficient payment processing system |
US8793160B2 (en) * | 1999-12-07 | 2014-07-29 | Steve Sorem | System and method for processing transactions |
US20020111907A1 (en) | 2000-01-26 | 2002-08-15 | Ling Marvin T. | Systems and methods for conducting electronic commerce transactions requiring micropayment |
US7979347B1 (en) * | 2000-03-16 | 2011-07-12 | Goldman Sachs & Co. | Automated online sales risk management |
AUPQ844600A0 (en) * | 2000-06-29 | 2000-07-27 | Australian Loyalty Systems Pty Ltd | Protecting against impluse expenditure |
US20030018561A1 (en) * | 2000-06-30 | 2003-01-23 | Kitchen Louise J. | Single party buying and selling commodities with multiple counterparties |
US8015084B1 (en) * | 2000-09-06 | 2011-09-06 | Jpmorgan Chase Bank, N.A. | System and method for linked account having sweep feature |
EP1325599A1 (en) * | 2000-09-08 | 2003-07-09 | Guy S. Tallent | System and method for providing authorization and other services |
US20030236728A1 (en) * | 2000-09-20 | 2003-12-25 | Amir Sunderji | Method and apparatus for managing a financial transaction system |
US20020152179A1 (en) * | 2000-10-27 | 2002-10-17 | Achiezer Racov | Remote payment method and system |
US20020111886A1 (en) | 2001-02-12 | 2002-08-15 | Chenevich William L. | Payment management |
CA2354372A1 (en) * | 2001-02-23 | 2002-08-23 | Efunds Corporation | Electronic payment and authentication system with debit and identification data verification and electronic check capabilities |
US7249092B2 (en) * | 2001-05-29 | 2007-07-24 | American Express Travel Related Services Company, Inc. | System and method for facilitating a subsidiary card account with controlled spending capability |
US20030158811A1 (en) * | 2001-07-18 | 2003-08-21 | Ventanex | System and method for rules based electronic funds transaction processing |
US7103576B2 (en) * | 2001-09-21 | 2006-09-05 | First Usa Bank, Na | System for providing cardless payment |
AU2003213021A1 (en) * | 2002-02-11 | 2003-09-04 | Zoe Boza | Multiparty transaction system |
US20030208439A1 (en) * | 2002-05-03 | 2003-11-06 | Rast Rodger H. | Automated soft limit control of electronic transaction accounts |
US20030222138A1 (en) * | 2002-05-31 | 2003-12-04 | Carole Oppenlander | System and method for authorizing transactions |
EP1579298A4 (en) * | 2002-11-05 | 2006-08-09 | Aaron Whiteman | Remote purchasing system and method |
US8156042B2 (en) * | 2003-08-29 | 2012-04-10 | Starbucks Corporation | Method and apparatus for automatically reloading a stored value card |
WO2005114517A2 (en) * | 2004-05-14 | 2005-12-01 | Hedgestreet, Inc. | Risk management contracts and method and apparatus for trading same |
CA2566978A1 (en) * | 2004-05-18 | 2005-12-08 | Rba International, Inc. | Systems and methods for remote account control |
US7383231B2 (en) | 2004-07-19 | 2008-06-03 | Amazon Technologies, Inc. | Performing automatically authorized programmatic transactions |
US7324976B2 (en) | 2004-07-19 | 2008-01-29 | Amazon Technologies, Inc. | Automatic authorization of programmatic transactions |
US20060089906A1 (en) * | 2004-10-21 | 2006-04-27 | Michael Rowley | Method for securing a payment transaction over a public network |
AU2005299252B2 (en) * | 2004-10-26 | 2012-01-19 | The Coca-Cola Company | Transaction system and method |
US8744937B2 (en) * | 2005-02-25 | 2014-06-03 | Sap Ag | Consistent set of interfaces derived from a business object model |
US20060213979A1 (en) * | 2005-03-25 | 2006-09-28 | Bluko Information Group | Method and system of detecting fraud and incremental commitment of value |
US8996423B2 (en) * | 2005-04-19 | 2015-03-31 | Microsoft Corporation | Authentication for a commercial transaction using a mobile module |
US9245270B2 (en) * | 2005-07-22 | 2016-01-26 | Gtj Ventures, Llc | Transaction security apparatus and method |
US20070038560A1 (en) * | 2005-08-12 | 2007-02-15 | Carl Ansley | Transaction payment system and processing |
US20070168260A1 (en) * | 2005-09-30 | 2007-07-19 | Mastercard International Incorporated | Payment apparatus and method |
US20060026073A1 (en) * | 2005-10-24 | 2006-02-02 | Kenny Edwin R Jr | Methods and Systems for Managing Card Programs and Processing Card Transactions |
US7513418B2 (en) * | 2005-12-20 | 2009-04-07 | First Data Corporation | Systems and methods for performing a simplified risk assessment |
-
2007
- 2007-03-30 US US11/694,459 patent/US8655786B2/en active Active
- 2007-12-18 EP EP07865817A patent/EP2102803A4/en not_active Withdrawn
- 2007-12-18 WO PCT/US2007/087968 patent/WO2008082960A1/en active Application Filing
-
2014
- 2014-02-14 US US14/181,444 patent/US20140195431A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020087427A1 (en) * | 2000-12-28 | 2002-07-04 | Ravi Ganesan | Electronic greeting card with gift payment |
US20070017973A1 (en) * | 2005-07-20 | 2007-01-25 | Arthur Blank & Company, Inc. | Transaction card and envelope assembly |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2016200687A1 (en) * | 2015-06-10 | 2016-12-15 | Chicago Mercantile Exchange Inc. | Transaction processing system performance evaluation |
US10311516B2 (en) | 2015-06-10 | 2019-06-04 | Chicago Mercantile Exchange Inc. | Transaction processing system performance evaluation |
Also Published As
Publication number | Publication date |
---|---|
EP2102803A4 (en) | 2012-01-11 |
US20080162365A1 (en) | 2008-07-03 |
US8655786B2 (en) | 2014-02-18 |
EP2102803A1 (en) | 2009-09-23 |
WO2008082960A1 (en) | 2008-07-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11568478B2 (en) | Apparatus to provide liquid funds in the online auction environment | |
US10984403B2 (en) | Systems and methods for brokered authentification express seller links | |
US20140195431A1 (en) | Aggregate Constraints for Payment Transactions | |
US20190311380A1 (en) | System and method for conducting a gift value transaction | |
US8838501B1 (en) | Methods and systems for permissions management | |
JP5684717B2 (en) | Financial gadgets | |
US7742994B1 (en) | Providing payments automatically in accordance with predefined instructions | |
US8255328B1 (en) | System, method, and computer readable medium for settling micropayment transactions to a pre-paid instrument | |
US20070022375A1 (en) | Apparatus, system, and method for an electronic payment system | |
US20160132884A1 (en) | Real-time payments through financial institution | |
US20120166311A1 (en) | Deferred payment and selective funding and payments | |
US20100161399A1 (en) | Instant payout incentive system | |
US20130268442A1 (en) | Secure payment system | |
US20130325719A1 (en) | Related party payment system | |
US20020019781A1 (en) | Method and system for facilitating the anonymous purchase of goods and services from an e-commerce website | |
US20010034720A1 (en) | System for facilitating a transaction | |
KR100583181B1 (en) | System and method for providing partial payment in the electronic commerce | |
JP2003067652A (en) | Electronic commercial transaction system and method | |
JP2010507151A (en) | Method and system for processing micropayment transactions | |
US20080162233A1 (en) | Method and system for soliciting charitable contributions using digital content over a network | |
JP2009116894A (en) | System and method for electronic commerce transaction | |
US20120072306A1 (en) | Payment Service Provision With Reduced Transaction Costs | |
KR101074617B1 (en) | System and method for providing partial payment in the electronic commerce | |
AU2013100977A4 (en) | Deferred payment and selective funding and payments | |
KR20090096270A (en) | ESCROW Transaction Providing System and Method With an Price Input Panel |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: AMAZON TECHNOLOGIES, INC., NEVADA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LAKKAPRAGADA, RAGHU;VENUGOPAL, JEYANDRAN;LAWSON, JEFFREY GORDON;SIGNING DATES FROM 20070601 TO 20070709;REEL/FRAME:041277/0743 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |