System and method for promotion processing and authorization

Abstract

An example funds facilitation system that facilitates transactions between a payer and payee includes a promotion processing system that facilitates the provision of promotions to account holders on the funds facilitation system. The party offering the promotion may be a merchant/payee that also has an account with the funds facilitation system. The promotion processing system applies promotion rules based on the identity of the merchant/payee and upon conditions placed on the promotion that identify a payer or a group of payers to receive the promotion. A user interface is provided for generating promotion rules and monitoring promotions. A user interface is also provided that displays unused promotion and gift codes and links to merchant/payee websites associated with the unused codes. The funds facilitation system can also provide authorization for purchases based on a condition, such as the age of the payer.

Description

TECHNICAL FIELD

The present disclosure relates generally to computer-implemented systems and methods for electronic commerce for promotion processing and authorization.

BACKGROUND AND SUMMARY

Electronic commerce, commonly known as electronic marketing, e-commerce, or eCommerce, consists of the buying and selling of products or services over electronic systems such as the Internet and other computer networks. The amount of trade conducted electronically has grown extraordinarily with widespread Internet usage. Commerce conducted in this manner utilizes a complex web of innovations in electronic funds transfer, supply chain management, Internet marketing, online transaction processing, electronic data interchange (EDI), inventory management systems, automated data collection systems, and many others. Modern electronic commerce typically uses the World Wide Web at least at some point in the transaction's lifecycle, although it can encompass a wider range of technologies such as e-mail as well.

With the continued increase in competition on the web, product, content, and service providers must strive to not only produce the best products, content, and services, but they must also compete to offer the most intuitive, secure, and fast mechanisms for accepting payments and providing their wares to interested consumers. The systems and methods disclosed herein offer enhanced capabilities for providing targeted promotions and transaction authorizations for individual merchant/payees, consumers/payers, and groups of the same.

In a funds facilitation system that facilitates transactions between a payer and a payee, a computer-implemented promotion processing system for generating and processing promotion rules for a promotion in the funds facilitation system, includes: a user interface configured to: receive promotion data, the promotion data comprising a promotion identification and a payee identification. The user interface is configured to associate the promotion identification with the payee identification. Additionally, a promotion processor is configured to generate the promotion rule from the promotion identification with the payee identification; receive transaction data identifying the payee and the payer, and to compare the transaction data with the promotion rules stored in the database to identify the promotion rule associated with the payee identification; and apply the promotion rule to the transaction data.

A computer-implemented method for processing promotions in a funds facilitation system that facilitates transaction between a payer and payee includes the steps of: receiving promotion data, the promotion data comprising a promotion identification and a payee identification; associating the promotion identification with the payee identification; generating a promotion rule based on the associated promotion identification and payee identification; storing the promotion rule in a promotion rules database; receiving at a promotion processor transaction data identifying the payee and the payer; and comparing the transaction data to the promotion rules stored in the database to identify the promotion rule associated with the payee identification; and applying the promotion rule to the transaction data. The receiving, generating, associating, storing, comparing, and applying steps are performed by software executable on one or more data processors.

In a funds facilitation system that facilitates transactions between a payer and a payee, a display device for displaying a user interface for determining rules and parameters for a promotion in the funds facilitation system comprises: a rule field for entering a promotion identification, the promotion identification identifying a type of promotion; a parameter field for entering a parameter that places a condition on the promotion; an account ID field for entering an account ID of the payee; wherein the promotion is applied to purchases made from the payee, and the condition on the promotion rule identifies a payer to receive the promotion.

In a funds facilitation system that facilitates transactions between a payer and a payee, a computer-implemented method for processing transactions in a funds facilitation system includes the steps of receiving age information associated with a payer; receiving an electronic transaction authorization request from a payee, the electronic transaction authorization request including information associated with an age-based condition; comparing the age information associated with the payer to the age-based condition; processing the transaction based upon whether the age information associated with the payer meets the age-based condition;

the receiving age information, receiving the electronic transaction authorization request, comparing, and processing steps being performed by software executable on one or more data processors.

In a funds facilitation system that facilitates transactions between a payer and a payee, a display device for displaying a promotion and gift code user interface for a funds facilitation system includes: a presentation of an unused gift code or promotion code associated with a payer user account on the funds facilitation system; a presentation of a link to a payee website associated with the gift code or promotion code.

In a funds facilitation system that facilitates transactions between a payer and a payee, a computer-implemented method for processing transactions in a funds facilitation system includes the steps of: receiving account data associated with a payer; receiving an electronic transaction authorization request from a payee, the electronic transaction authorization request including information associated with a condition; comparing the account data associated with the payer to the condition; and authorizing and processing the transaction based upon whether the account data associated with the payer meets the condition. The receiving account data, receiving the electronic transaction authorization request, comparing, and authorizing and processing steps are performed by software executable on one or more data processors.

The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the invention will become apparent from the description, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For the present disclosure to be easily understood and readily practiced, the present disclosure will now be described, for purposes of illustration and not limitation, in conjunction with the following figures.

FIG. 1 depicts a computer-implemented environment wherein users can interact with a merchant system and a funds facilitation system hosted on one or more servers through a network.

FIG. 2 shows an example promotion processing system.

FIG. 3 shows an example interface for generating and managing promotion rules.

FIG. 4 shows a second example interface for generating and managing promotion rules.

FIG. 5 is an example flow-chart for processing promotions in a funds facilitation system.

FIG. 6 is an example flow diagram for determining the application of age-based criteria.

FIG. 7 is a second example flow diagram for determining the application of age-based criteria.

FIG. 8 illustrates example hardware on which the various embodiments of the method of the present invention may be practiced.

Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

An example funds facilitation system that facilitates transactions between a payer and payee includes a promotion processing system that facilitates the provision of promotions to account holders on the funds facilitation system. The party offering the promotion may be a merchant/payee that also has an account with the funds facilitation system. (The term “payee” includes not only persons that receive payment directly from the payer, but includes promoters or sponsors, which are discussed below). The promotion processing system applies promotion rules based on the identity of the merchant/payee and upon conditions placed on the promotion that identify a payer or a group of payers to receive the promotion. A user interface is provided for generating promotion rules and monitoring promotions. A user interface is also provided that displays unused promotion and gift codes and links to merchant/payee websites associated with the unused codes. The funds facilitation system can also provide authorization for purchases based on a condition, such as the age of the payer.

FIG. 1 depicts at 100 a computer-implemented environment wherein users 102 can interact with a merchant system 104 hosted on one or more servers through a network 106. The merchant system 104 contains software operations or routines for receiving a transaction request from a user 102 and providing fulfillment or notice of fulfillment of the requested transaction or a denial of the transaction request to the user 102. The users 102 can interact with the merchant system 104 in a number of ways, such as over one or more networks 106. One or more servers accessible through the network(s) 106 can host the merchant system 104.

The computer-implemented environment further includes a funds facilitation system 108. The funds facilitation system 108 may be configured for identifying the availability of funds in a user account, acquiring funding for a user account, disbursing funding to a merchant to pay for a transaction, providing promotions to payees, and authorizing a transaction between a merchant and a payee, as well as other operations. Both payers and merchant/payees have user accounts with the funds facilitation system 108. The funds facilitation system 108 is hosted on one or more servers through one or more networks 106.

In an example operation, a payer user 102 accesses a web page hosted on the merchant system 104 via the one or more networks 106. For example, the web page may list a number of book titles that are available for download from the merchant system 104 in exchange for a payment from the payer user 102. The payer user 102 indicates his desire to download one of the listed books by clicking a button on the web page that initiates a transaction request to the merchant system 104.

Upon receipt of the transaction request, the merchant system 104 prepares a transaction authorization request for authorization of the transaction and facilitating payment for the transaction. The merchant system 104 may access one or more data stores 110a to acquire a merchant ID 112a identifying the merchant system 104. The merchant system 104 may further access the one or more data stores 110a to access a merchant payer user ID 114a associated with the payer user 102 that provided the transaction request. The merchant payer user ID 114a associated with the payer user 102 may be identified based on a prior user identification at the merchant system 104, such as the payer user 102a providing a username and password combination. The merchant system 104 packages the merchant ID 112a, the merchant payer user ID 114a, as well as a transaction amount associated with the transaction requested by the payer user 102 into a transaction authorization request that is transmitted to the funds facilitation system 108 via the one or more networks 106.

The funds facilitation system 108 receives the transaction authorization request from the merchant system 104 and accesses one or more data stores 110 responsive to the funds facilitation system 108 to identify the funds facilitation system user IDs 114 associated with the merchant ID 112a and the merchant payer user ID 114a included in the transaction authorization request. The funds facilitation system user ID 114 accessed by the funds facilitation system 108 provides a link to user account data 112 for the merchant/payee and payer user 102 that provided the transaction request. The user account data 112 may include data related to one or more accounts related to the payer-user 102 including prepaid accounts, stored value accounts, credit accounts, debit accounts, or the like. In one embodiment, the stored value accounts may be useful for conducting low value transactions. In another embodiment, the account may be a credit, debit, or other account, or an alias for such an account, that may be more appropriate for higher value transactions. The merchant/payee account data 112 may include account data for providing payment and charging the merchant/payee.

The funds facilitation system 108 may determine the viability of the transaction described in the transaction authorization request from the merchant system 104 based on the provided transaction amount, a funds available value from the payer user account data 112, as well as other user account settings and data and other criteria.

If the funds facilitation system 108 determines that the proper criteria for a transaction approval are met, the funds facilitation system 108 may transfer the transaction amount from the user's account to the merchant and provide a transaction authorization to the merchant system 104. Upon receipt of a transaction authorization from the funds facilitation system 108, the merchant system 104 may make the book title available for immediate download by the user 102 with the knowledge that compensation for the transaction has been provided to the merchant.

While the above example describes providing a digital book to a user 102 in response to a transaction request, the system 100 may be utilized in a multitude of other scenarios. For example, instead of providing immediate digital content, the merchant may instead mail a physical product to the user 102 or perform a service, such as a healthcare service, for the user 102 upon receipt of a transaction authorization.

The funds facilitation system 108 may comprise one or more servers containing software operations or routines for creating and maintaining accounts for the users; for enabling the users to conduct transactions with one or more websites; for enabling users to initiate dispute proceedings with one or more websites and to automate the communications related to the dispute and the resolution of the dispute; to initiate and transmit alerts to users, websites, and or system administrators based upon pre-defined and/or customizable parameters; to configure and apply fees to transactions; and to conduct reporting as may be relevant to the websites, the account processor and/or the users.

Furthermore, the one or more servers of the account processor may additionally contain software operations or routines related to managing the accounts (such as by updating billing addresses, delivery addresses, user preferences, and the like); for enabling users to authorize and manage recurring payments or to pre-authorize payments; for enabling users to pre-authorize or prohibit (i.e., blacklist) websites and/or transactions; and/or for enabling users to manage accounts and conduct transactions using mobile electronic devices or any other electronic device such as internet-connected gaming consoles, a digital set-top box, or similar devices. A user 102 can register with the funds facilitation system 108, such as by registering with a particular account in order to receive a promotion affiliated with that account.

FIG. 2 shows an example promotion processor 200 that is part of the funds facilitation system 108. The promotion processor 200 receives data from the data stores 110. In this example, the data stores 110 include a user account database 205 that stores user account and demographic information, and a promotion rules database 210 that stores promotion rules. The promotion processor 200 may also receive data from one or more merchant systems 104 through the network 106. In this example the merchant system is a payee website 215. The promotion processor 200 receives input defining and associating a promotion, a payee, and a condition from either or both of the payee user interface 220 and the administrator user interface 225. The user interface is provided on a display device. The administrator user interface may also receive input to define a price to charge the payee for the promotion. The promotion processor 200 processes the data it receives and facilitates a variety of promotion functionalities.

In an example funds facilitation system 108, the system can access payer profile data 112 and take action based upon one or more profile data values corresponding to one or more conditions. In these implementations, promotions can be based upon data corresponding to the one or more conditions. In an example implementation of the system, the promotion processor 200 generates promotion rules in response to the input received from the user interfaces 220, 225. It then stores the promotion rules in the promotion rules database 210. The promotion processor is configured to receive transaction data identifying the payee and the payer, and compares the transaction data with the promotion rules stored in the promotion rules database 210 to identify the promotion rule or rules associated with the payee identification and any additional conditions. The promotion processor 200 applies the promotion rule to the transaction data. The promotion processor then delivers any promotions to the payer. For example, delivering the promotion may include electronically sending a notification to the payer directly or through the payee, or it may include automatically applying the discount as part of the funds facilitation process. The promotion may be for the current transaction or a future transaction or may be a benefit not related to a transaction.

In some implementations, the funds facilitation system 108 can randomly and securely generate and apply rules to track promotion codes.

The funds facilitation system 108 can assign one or more promotion types. Due at least in part to the example system structure described in FIG. 1 and the example funds facilitation system 108 described herein, the system administrator or merchant/payee has a variety of options for generating and placing conditions (or parameters) on the promotions. For example, conditions for delivering, activating, deactivating, and customizing promotions can be established. The one or more promotions or promotion codes can be valid at a specific merchant, a specific list of merchants, a specific group of merchants (e.g., based on a set of common attribute(s) like a merchant category type), or all merchants. The promotion can even be tied to no merchants by being tied to an activity other than a purchase.

An example promotion can be a specific dollar value off of a purchase. The promotion can be a specific percentage discount value off of a purchase. The promotion code can be associated with a specific product ID, such as when the promotion code is used to receive a special price on a specific product. In these implementations, the specific product ID may signify that the product is only available with the promotion code. Alternatively, a promotion code can be a specific non-purchase value (e.g., an entry into a drawing or a competition).

In some examples, the funds facilitation system 108 can condition promotion validity or availability to all payer account holders, a specific account holder, a specific list of payer account holders, or a specific group of payer account holders defined by a common piece of data. For example, promotion availability/validity can be restricted based upon a common condition or set of conditions that are met in a payer's user account profile that is stored in the user account database 205. For example, the availability of the promotion may be conditioned upon a demographic indicator, state(s), postal code(s), age, account type, or account level. Additionally, promotion code availability/validity can be restricted based upon transaction history, such as transaction(s) conducted of a certain type or value, or at a specific merchant, group of merchants, or in general, over a specified date range. For example, a promotion code can be valid for all account holders who have made more than three purchases at Merchant X, Y and/or Z between Feb. 1, 2011 and Feb. 28, 2011.

Alternatively, or in addition to controlling promotion code validity as described above, the presentation and advertisement of promotional codes may also be controlled by the funds facilitation system 108.

An example funds facilitation system 108 can also set conditions or parameters on a promotion, for example, by using non-overlapping ranges, such as by awarding a different discount value depending upon the dollar value of the purchase being made. For example, if a user spends more than $5.00 (e.g., $5.01-$10.00), they get a $1.00 discount, and if a user spends more than $10.00 (e.g., $10.01 or more), they get a $3.00 discount. In another example, the percentage discount can be different depending on the dollar value of the purchase being made. For example, if a user spends up to $10.00 ($0.01-$10.00), they receive a 5 percent discount, if a user spends from $10.01 to $20.00, they receive a 10% discount, and if a user spends $20.01 or more, they receive a 15% discount.

In another example, a special price on a specific product can be applied only when the condition is met that another specific product is bought in the same purchase. For example, if a user buys product X, they receive product Y free, or at half-price.

In yet another example, the promotion may encompass a drawing instead of a discount. The number of entries in the drawing could be variable based upon an event or a value associated with an event that triggers the issuance of the promotion. For example, a user can spend $0.01-$5.00 for one free entry, $5.01-$10.00 for three entries, and $10.01 or more for five entries.

The funds facilitation system 108 may set activation and expiration date and time conditions for a promotion. In a related function, the funds facilitation system 108 can expire a promotion code early or extend the expiration date/time of a promotion code.

In some implementations, the funds facilitation system 108 can set universal conditions or parameters on a promotion to limit the use of the promotion. For example, a universal parameter can be based upon the total number of times the promotion code has been used. In one embodiment, the promotion is valid for the first 500 customers' uses only. In another example, a universal parameter can be based upon the total value of a promotion redemption, such as, when the total value of the redemption exceeds $10,000, the promotion is deactivated.

The universal parameters may also be applied to a group of promotions. For example, when there is more than one offer (e.g., three offers) available, all offers can cease to be valid when the total number of redemptions or a total value of the redemptions with respect to all three offers is reached or exceeded.

The funds facilitation system 108 may, for example, issue promotions to account holders based on a trigger event. For example, a trigger event can occur when the existing account attributes meet one or more of the defined parameters noted above, such as purchasing a certain amount. A trigger event can occur as a result of a specific purchase. A trigger event may also occur as a result of a specific user-initiated account activity such as inviting friends, a successful friend referral, a set-up of regular account top-ups, the addition of a specific card type to funding options, the setting of a specific card type as default, or the setting up of a sponsored account. In yet another example, a trigger event can occur as a result of a passive user “event,” such as the user's birthday or the length of time an account has been open and/or active.

The promotion processor 200 as a part of the funds facilitation system 108 can deliver promotions through a variety of vehicles. For example, a promotion can be delivered in a transaction response message to a merchant/payee that the merchant can display to the purchaser on a transaction successful screen. In this example, the promotion does not need to be an offer from the merchant/payee sending the transaction response message. For example, the promotion can be a cross-promotion from another merchant. In another example, a promotion code can be delivered in an email to an account holder(s). Alternatively, the promotion code can be presented in a graphical user interface of the funds facilitation website or in the payee website. In one example, the email can be automatically sent following a trigger event. In yet another example, a promotion code can be delivered using an out-of-service vehicle (e.g., in an advertisement by a merchant or the funds facilitation system operator).

The example promotion processor 200 as a part of the funds facilitation system 108 can facilitate promotion redemption 211 in multiple scenarios. For example, a promotion code can be entered manually (e.g., by a user on a transaction authorization screen in a merchant/payee website and passed in a transaction request message, or by an account holder on an account page where an activity is being authorized with a password. In another example, a promotion code can be entered automatically (e.g., by a merchant/payee website as part of the transaction request message). In yet another example, a promotion code is not entered at all, but is applied automatically by the funds facilitation system 108. For example, when a promotion code benefit is automatically triggered at the occurrence of a condition, such as a trigger event (e.g., when a payer spends more than $20.00 at merchant X in February, then $2.00 will be discounted from the price, or in another example, donated to charity Y). In this example, a confirmation message can be sent to the user upon the occurrence of the condition and associated promotion benefit.

The promotions and conditions can be input and managed using a user interface, such as the example graphic user interfaces shown in FIGS. 3 and 4. In an alternative example, the promotions and conditions can be managed through a server call.

FIG. 3 shows an example interface 300 for generating and managing promotion codes. The interface is provided on a display device. Example interface 300 can be an administrative interface that can facilitate the generation 301 and configuration of promotion rules. In this example, drop down menus present a number of possible selections. The interface 300 can also be used to subsequently modify 304 a promotion 302 or a condition 303 for an existing promotion rule. For example, an existing promotion rule can be selected in a previous user interface, which then opens the example interface 300 with the fields pre-filled with the existing promotion rule data. Similarly, the promotion could be configured and edited using a reference ID via specifically formatted messages communicated via server calls.

The example interface 300 can be used to designate a payee Account ID in an Account ID field 306 which can be used to manage a promotion code or group of promotion codes. A specific merchant/payee Account ID can be designated for a specific merchant promotion, or multiple Account IDs can be specified for a group merchant promotion. In this case, the promotion rule will associate the selected promotion with the selected Account IDs. In one example, ownership can be assigned to a specific group account, and then access permissions can be provided to that group account for use by all group participants. In some implementations, the Account ID field 306 may have an operator input to designate a specific promotion run by the funds facilitation system rather than a payee Account ID.

In one example, the user interface provides the ability to create an Account ID only for the purpose of managing a promotion code or group of promotion codes. For example, a third-party “promoter” who is not an account holder on the funds facilitation system may have an account opened solely for the purpose of managing promotions. For example, a sponsor or affiliate of a merchant may run a promotion to give account holders a free download or discount from the merchant's website.

For example, a third-party who is not an account holder (e.g., a third-party bank that is a sponsor of an event), can run a promotion to give bank account holders a free download from a sponsored event website or a discount on any purchase of merchandise from the sponsored website. Thus, even though the event organizers are a merchant/payee, the promotion is controlled by the third-party bank, not the event organizers.

The example interface 300 can be used to charge fees to one or more accounts. Fees can be fixed and/or percentage based. Fees can be applied to the issuance of a promotion rule with pricing parameters 305. Pricing parameters 305 can be based upon, for example, date range of validity, value of offer, or volume/size of payee/merchant(s). For example, a different fee can be charged to each participating merchant(s) depending on a parameter such as sales volume. In some implementations, a fee can be charged in addition to or in lieu of a standard transaction fee, for each use of the promotion. In some implementations, a fee can be charged for each change to promotion code configuration (e.g. early expiration, extension of validity, or a change to valid account parameters). The fee may be charged at the generation of the promotion rule, or when the promotion is delivered to the payer.

Although drop-down menus are indicated in FIG. 3, more than one entry may be made for each of the promotion 302, condition 303, Account ID 306, and Pricing 305 fields. In some examples, a separate operator may be input to determine if multiple entered conditions, such as A and B, are to be processed as requiring both A and B, or requiring either A or B.

FIG. 4 shows a second example user interface 400 for assigning promotion codes, which may be more easily utilized to assign multiple promotions, account IDs, and conditions, for generating a promotion rule than the example of FIG. 3. The user interface is provided on a display device. Furthermore, this user interface excludes the pricing input, so it may be more appropriate for use by a payee/merchant.

In the example user interface of FIG. 4, three columns are displayed. At one side of the user interface 400, a listing of promotions is shown in a column titled “Promotion ID Database” 405. At the opposite side thereof, another column titled “Payee User Account Database” 410 contains a listing of possible Payee Accounts that may be selected. In the same column, a separate row, beneath the “Payee User Account Database,” includes a number of conditions that are listed under the heading “Conditions Database” 415. In the middle column, titled “Promotion Rule” 420, a promotion field 422, an account ID field 424, and a condition field 426 are presented.

To populate each of the promotion field 422, account ID field 424, and condition field 426, the user may select one or more promotions from the promotion ID database 405, payee user account database 410, and condition database 415, and input the selection into the respective promotion rule field, by clicking (or otherwise activating) the respective “Add” arrow 430 pointing to the respective field of the promotion rule column. Items input to the promotion rule column 420 may be deselected and sent back to the respective field by clicking (or otherwise activating) the respective “Delete” arrow 435 pointing away from the promotion rule field. In this way a promotion rule for the desired payee user account and conditions is associated with the desired promotion. The promotion rule is generated and stored in a promotion rules database by clicking (or otherwise activating) the “Generate Rule” button 440, at the bottom of the promotion rule column 420.

A “New” button 450 corresponding to each of the promotion database, payee user account database, and condition database is provided in case the user does not see a desired promotion, payee user account, or condition in the listings of selectable items. Clicking (or otherwise activating) the “New” button 450 may cause a message window to be opened wherein the user can draft a request for the new item and send it to an administrator for creation. Alternatively, activation of the “New” button may directly open an interface for creating new items for the promotion database, payee user account database, and condition database.

In some implementations, either the example interface 300 of FIG. 3 or the example interface 400 of FIG. 4 can further be used to monitor promotion issuance and usage and to generate usage reports. For example, a previously generated promotion rule may be selected and a pop-up screen may show usage statistics, which may indicate that a promotion code is being passed around to more users than the payee intended. Thus, the interface 300 may function to modify the rule based on one or more conditions 303, such as limiting the times the promotion or promotion code may be used or the total amount of discount or drawing entries that are available, after which the promotion or promotion code will cease to be valid.

In some implementations, an interface can be used to provide one-time use promotions, such as a gift card, to a merchant/payee. In these implementations, a merchant/payee can configure and sell one-time use promotion codes (e.g., in the form of “gift codes”), to standard account holders from any enrolled merchant/payee account, or directly from the fund facilitation system 108 using the interface. A seller can set a face value for a gift code that is different than the purchase price. For example, a seller can allow a user to buy a discounted $20.00 gift code for $18.00. Alternately, a seller can attach a $2.00 purchase fee to a $20.00 gift code, causing the user to pay $22.00.

For example, a user can purchase one-time use promotion codes in the form of gift codes for themselves or for another user, for example for use at a merchant website that has an account with the funds facilitation system 108.

FIG. 5 shows an example flow chart of a computer-implemented method for processing promotions in a funds facilitation system 108 that facilitates a transaction between a payer and payee. In this example, promotion data comprising a promotion ID, payee ID, condition, and price are input in a user interface 502, and a promotion rule is generated 504 based on the input from the user interface 502. The promotion rule is stored in a promotion rules database. Optionally, the payee is charged according to the price of the promotion rule 506 shortly after the promotion rule is generated.

Transaction data is received 510 by a promotion processor operating on the funds facilitation system, for example, subsequent to a transaction request from the payee's website. The transaction data identifies the payee and payer and the transaction amount. Further information may also be provided, such as information regarding an item that is being purchased or a request to apply a condition before providing the promotion. The promotion processor then compares the transaction data to the promotion rules stored in the database 512 to identify the applicable promotion rule associated with the payee identification and any conditions. The one or more identified promotion rules are then applied to the transaction data 514. Again there is the option of charging the payee for the promotion 506 at this point, when the promotion is applied to a transaction. In one embodiment the payee may be charged both when the rule is generated and when it is applied.

Once the promotion rule is applied, the promotion is delivered to the payer. Delivering the promotion to the payer may, for example, include automatically applying a discount to the transaction, informing the payer of a promotion code to be used on a later transaction, or informing the payer of an entry in a drawing being held concurrently or at a future time. Each step of the example method is performed by software executable on one or more data processors.

The funds facilitation system 108 can additionally approve or decline the transaction (e.g., based upon whether the purchaser meets conditions set by a seller).

In an example transaction authorization system, the fund facilitation system 108 will provide information to a seller and approve or decline transactions based upon seller instructions (e.g., as reflected in age criteria). In these implementations, a privacy policy may indicate that the provision of age-related information to a seller is for a particular purpose. In one example, the user may not opt out of including this information (e.g., it will be a part of the standard terms and conditions for use of the service). Additionally, age indicator response data will be provided to a seller with a disclaimer. For example, the disclaimer can include language indicating that the fund facilitation system 108 holds no liability for the accuracy of age or other demographic-related information. Additionally, the disclaimer may state that the fund facilitation system 108 is providing the parameter-related information to the seller for information purposes only. Moreover, it may also state that decisions made based on condition-based information will be at the exclusive direction of the seller. In some examples, an additional field can be added to the transaction data in the purchase authorization request message. A merchant/payee can optionally use the purchase authorization request message to indicate an instruction (e.g., to apply a specific age-based condition to the approval of a purchase).

FIG. 6 is an example flow diagram for authorizing a transaction based on an age-based condition. Initially, a transaction authorization request is received that includes information associated with an age-based condition as part of the transaction data. This information may be the age-based condition itself as shown in step 602. Alternatively, the transaction authorization request contains item information as part of the transaction data 604, such as information identifying an item for purchase. In this case, the funds facilitation system 108 determines if the item is associated with an age-based condition previously stored in a database 606.

A payer establishes an account before the requested transaction takes place. This process includes a query to determine the age of the payer 610. After the age is determined, the payer account is created 612. In one example, an account cannot be opened unless an age is provided. Requesting age information at the outset of account generation at the funds facilitation system 108 should decrease untrue responses, since the request is made apart from any specific product purchase that may have an age-based condition. Optionally, the age of the payer can be verified electronically, e.g., through a third-party identification check on passport and/or driver's license, and/or through the association of other age-related indicators, e.g., a credit card in the user's name.

The funds facilitation system 108 compares the age-based condition, determined from the transaction data with the age information associated with the payer account to determine whether the age of the payer meets the age-based condition 620. If the payer does meet the age-based condition, then the system 108 processes the transaction and/or informs the payee that the payer meets the age-based condition 630. If the payer does not meet the age-based condition, then the system 108 terminates the transaction request and/or informs the payee that the payer does not meet the age-based condition 635.

In another example, instead of an age-based condition, the example shown in FIG. 6 can be performed based on a different condition. For example, other data from the user account is compared with a defined condition in order to determine if the transaction will be authorized and/or processed. Examples of user account data that may be used to determine whether to authorize the transaction and/or discount or special pricing to apply to the transaction and/or other promotional benefits to associate with the transaction includes payment source information, recent transaction activity information, or location information. Other data may also be used. In the case of location information, some items may be illegal for purchase in some locations, and thus the payee would want to determine whether the payer resides in such locations before processing the transaction. The payee may also want to only do business with or may only want to extend a promotional benefit to payers that have certain payment sources associated with their account or have certain data reflected in their transaction history.

The above steps may be performed by software executable on one or more data processors.

In a more specific embodiment of the transaction authorization process an additional field is displayed 701 to a payee/merchant (e.g., in a purchase authorization request message). A determination 702 is made as to whether the merchant/payee filled in the field and how the merchant/payee filled in the field. In some implementations, if the field is left blank, the funds facilitation system 108 will not check or apply 703 any age-based criteria.

If the field is populated by a positive integer 704, then the fund facilitation system 108 will interpret the instruction to indicate that the seller requires the user to be greater than or equal to the positive integer 708, in years of age, in order for the transaction to be approved.

In some implementations, if the field is populated by a negative integer 705, then the system will interpret the instruction to indicate that the seller requires the user to be less than or equal to the absolute value of the negative integer 706, in years of age, in order for the transaction to be approved.

If the field is populated by both a positive integer 704 and a negative integer 707 (including an appropriate separator), then the fund facilitation system 108 will interpret the instruction to indicate that the seller requires both criteria to be applied 709 in order for the transaction to be approved. For example, if the negative integer has an absolute value which is higher than the positive integer, then the purchaser must be in the age range from the positive integer to the negative integer. For example, “14;-17” would indicate the purchaser must be between 14 and 17 years of age, including both 14 and 17, to meet the criteria). In another example, if the positive integer has a value which is higher than the absolute value of the negative integer, then the purchaser must be of one of the two age ranges. For example, “65;-17” would indicate that the purchaser must be either 65 years of age or older, or 17 years of age or younger.

In some implementations, more than one set of age-based criteria may be provided with specific prices assigned to each age range. For example, this can be done to set the transaction value of an item at normal price unless a user is within a specific age-range criteria. If the user is within a specific age-range criteria, then the transaction value of an item can be set at a specific price associated with that age range. As another example, a specific percentage or value discount associated with that age range can be applied. Additionally, the discount can be indicated in a line item. Alternatively, all such parameters could be set as conditions in the promotion processing system described in the discussion of FIGS. 2-5.

In some implementations, merchants/payees can add additional instructions for determining acceptable age-related information for approving a transaction.

The merchant/payee can be provided with information related to what information was used to check the age in addition to the result; for example, in an additional field added to a purchase authorisation response message. In some implementations, a purchase authorization response message can include a result code indicative of which criteria were met or not met. For example, if no age-based criteria are met, the result code can be a “0” and the transaction would be declined. If a single set of age-based criteria are met, then the result code can be a “1” and the transaction would be approved. If multiple age criteria are provided, then a result code of “1”, “2”, “3”, . . . “n” can be provided (e.g., based on which age criteria is met).

In some implementations, a purchase authorization response message can include a date-of-birth code to indicate how the date of birth used in the age criteria check has been validated. For example, “S” can indicate that the date of birth was self-declared at time of registration. “V” can indicate that the date of birth was verified electronically (e.g., through a third-party identification check on passport and/or driver's license).

In some implementations, a purchase authorization response message can include a payment instrument code to indicate the highest ranking payment instrument associated with the account, from the following (listed in hierarchical order from highest ranking to lowest):

C=Credit

D=Debit

P=Prepaid

B=Bank Account

N=None

A response including age indicator data can include a notation embedded in the response which includes the text of the disclaimer, as noted above. Additionally, age indicator request criteria and age indicator response data, including the result code, date of birth, and payment instrument code, may be included in both the merchant/payee view and the administrative view of the transaction details, but not the payer's view. Moreover, an age indicator response field in the merchant/payee transaction details view may include a link to the disclaimer language noted above, which would load as a dialogue message box on a page when activated.

FIG. 7 shows an example user interface 700 for displaying gift and promotion codes to an associated payer. The user interface is provided on a display device. The promotion and gift codes, when obtained, are stored in a database and associated with the payer user account. The promotion and gift codes may be entered manually by the payer or they may be automatically electronically delivered by the promotion processing system. For example, the user account interface 700 displays the unused promotion codes 705 and gift codes 710 and includes links 720 to the merchant site where the unused promotion codes and gift codes may be used. The funds facilitation system may store in a database and display at a user interface a record of the date the promotion code or gift code was used and a link to the associated transaction information.

FIG. 8 is a block diagram of hardware 1010 which may be used to implement the various embodiments of the method of the present invention. The hardware 1010 may be a personal computer system comprised of a computer 1012 having as input devices keyboard 1014, mouse 1016, and microphone 1018. Output devices such as a monitor 1020 and speakers 1022 may also be provided. The reader will recognize that other types of input and output devices may be provided and that the present invention is not limited by the particular hardware configuration.

Residing within computer 1012 is a main processor 124 which is comprised of a host central processing unit 1026 (CPU). Software applications 1027, such as the method of the present invention, may be loaded from, for example, disk 1028 (or other device), into main memory 1029 from which the software application 1027 may be run on the host CPU 1026. The main processor 124 operates in conjunction with a memory subsystem 130. The memory subsystem 130 is comprised of the main memory 1029, which may be comprised of a number of memory components, and a memory and bus controller 1032 which operates to control access to the main memory 1029. The main memory 1029 and controller 1032 may be in communication with a graphics system 134 through a bus 1036. Other buses may exist, such as a PCI bus 1037, which interfaces to I/O devices or storage devices, such as disk 1028 or a CDROM, or to provide network access.

Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, data processing apparatus.

The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. The term “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them, A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.

A computer program (also known as a program, software, software application, script, or code), can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., on or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio player, a Global Positioning System (GPS) receiver, to name just a few. Computer-readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media, and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) to LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any from, including acoustic, speech, or tactile input.

Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

While this specification contains many specifics, these should not be construed as limitations on the scope of the invention or of what may be claimed, but rather as descriptions of features specific to particular embodiments of the invention. Certain features that are described in this specification in the context or separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed o a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Thus, particular embodiments of the invention have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results.

Claims

1. A method for processing promotions, performed by a funds facilitation system that facilitates transactions between payers and payees, the method comprising: storing, by the funds facilitation system, promotion rules in a database, each promotion rule associating a promotion with a payee;receiving, by the funds facilitation system, a transaction authorization request from a payee for a transaction, the transaction authorization request including identification of the payee, identification of a payer and a transaction amount;comparing, by the funds facilitation system, the identification of the payee to the promotion rules stored in the database to identify a promotion that is associated with the payee;determining, by the funds facilitation system, an age of the payer without being informed of the payer's age by the payee;authorizing, by the funds facilitation system, the transaction to the payee in which the promotion is applied to the transaction, wherein the authorization is conditioned on the payer's age meeting a predetermined age condition; andtransferring funds from the payer's account to the payee's account in response to the transaction being authorized.

2. The method of claim 1 wherein the promotion is a discount on the transaction amount, and the transferred funds correspond to the transaction amount minus the discount.

3. The method of claim 2 wherein the discount is a percentage of the transaction amount.

4. The method of claim 2 wherein the discount is a set monetary amount.

5. The method of claim 1 wherein the promotion is for a future purchase transaction.

6. The method of claim 1 wherein the promotion is for a non-purchase item.

7. The method of claim 6 wherein the non-purchase item is entry into a drawing.

8. The method of claim 1 further comprising: sending, to the payee, information about a second promotion that is available to the payer, for the payee to forward to the payer.

9. The method of claim 8 wherein the second promotion is a cross promotion from another payee.

10. The method of claim 1 further comprising: determining whether the payer's account has sufficient funds to pay for the transaction; andconditioning the authorization on determining that the payer's account has sufficient funds.

11. The method of claim 1 wherein the payee corresponds to a merchant website.

12. The method of claim 1 further comprising: the funds facilitation system determining the payer's age from age data that is linked to an account that the payer has with the funds facilitation system.

13. The method of claim 1 wherein the transaction authorization request identifies a purchase item, and the funds facilitation system determines, without being informed by the payee, applicability of the age condition to the transaction based on identity of the purchase item.

14. The method of claim 1 further comprising: conditioning the transaction authorization based on a condition, set by the payee about the payer, being met.

15. The method of claim 14 wherein the condition is age of the payer, and the funds facilitation system determining the payer's age without being informed of it by the payee.

16. The method of claim 1 further comprising: conditioning the authorization of the transaction of the promotion on a demographic fact, about the payer, meeting a predetermined demographic condition; andthe funds facilitation system determining the demographic fact about the payer without being informed of it by the payee.

17. The method of claim 16 wherein the demographic fact is selected from the payer's age, location and birthday.

18. The method of claim 16 wherein the conditioning is based on a condition that is, prior to receiving the transaction authorization request, stored in the database and linked to the promotion rule.

19. The method of claim 16 wherein the condition is included by the payee in the transaction authorization request.

20. The method of claim 16 further comprising: the funds facilitation system determining the demographic fact about the payer from demographic data that is linked to an account that the payer has with the funds facilitation system.

21. The method of claim 1 further comprising: conditioning the authorization of the transaction of the promotion on an action by the payer relating to accounts that are managed by the funds facilitation system.

22. A funds facilitation system comprising: a database that stores promotion rules, each promotion rule associating a promotion with a payee;a processor in communication with the database; andmemory in communication with the processor and storing instructions that, when executed by the processor, cause the funds facilitation system to: receive a transaction authorization request from a payee for a transaction, the transaction authorization request including identification of the payee, identification of a payer, and a transaction amount;compare the identification of the payee to the promotion rules stored in the database to identify a promotion that is associated with the payee;determine an age of the payer without being informed of the payer's age by the payee;authorize the transaction to the payee in which the promotion is applied to the transaction, wherein the authorization is conditioned on the payer's age meeting a predetermined age condition; andtransfer funds from the payer's account to the payee's account in response to the transaction being authorized.

23. The system of claim 22 wherein the promotion is a discount on the transaction amount, and the transferred funds correspond to the transaction amount minus the discount.

24. The system of claim 22 wherein the promotion is for a future purchase transaction.

25. The system of claim 22 wherein the promotion is for a non-purchase item.

26. The system of claim 22 wherein the memory further includes instructions to cause the system to send, to the payee, information about another promotion that is available to the payer, for the payee to forward to the payer.

27. The system of claim 22 wherein the memory further includes instructions to cause the system to condition the transaction authorization on the payer's age meeting a predetermined age condition and to determine the payer's age without being informed of it by the payee.

28. The system of claim 27 wherein the memory further includes instructions to cause the system to determine the payer's age from age data that is linked to an account that the payer has with the funds facilitation system.

29. The system of claim 22 wherein the memory further includes instructions to cause the system to condition the authorization of the transaction of the promotion on a demographic fact about the payer meeting a predetermined demographic condition and to determine the demographic fact about the payer without being informed of it by the payee.

30. The system of claim 22 wherein the memory further includes instructions to cause the system to condition the transaction authorization based on a condition, set by the payee about the payer, being met.

31. A tangible, non-transitory computer-readable medium storing instructions that, when executed by a funds facilitation system, cause the funds facilitation system to: store promotion rules in a database, each promotion rule associating a promotion with a payee;receive a transaction authorization request from a payee for a transaction, the transaction authorization request including identification of the payee, identification of a payer, and a transaction amount;compare the identification of the payee to the promotion rules stored in the database to identify a promotion that is associated with the payee;determine an age of the payer without being informed of the payer's age by the payee;authorize the transaction to the payee in which the promotion is applied to the transaction, wherein the authorization is conditioned on the payer's age meeting a predetermined age condition; andtransfer funds from the payer's account to the payee's account in response to the transaction being authorized.