US20030171992A1 - System and methods for redeeming rewards associated with accounts - Google Patents

System and methods for redeeming rewards associated with accounts Download PDF

Info

Publication number
US20030171992A1
US20030171992A1 US10/386,027 US38602703A US2003171992A1 US 20030171992 A1 US20030171992 A1 US 20030171992A1 US 38602703 A US38602703 A US 38602703A US 2003171992 A1 US2003171992 A1 US 2003171992A1
Authority
US
United States
Prior art keywords
reward
account
group
dependent
accounts
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
Application number
US10/386,027
Inventor
Lynn Blagg
Carol Lindsay
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
First Data Corp
Original Assignee
First Data Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US09/298,521 external-priority patent/US7340423B1/en
Priority claimed from US09/298,505 external-priority patent/US7050996B1/en
Priority claimed from US10/172,378 external-priority patent/US20020198806A1/en
Priority claimed from US10/237,572 external-priority patent/US20040049452A1/en
Priority to US10/386,027 priority Critical patent/US20030171992A1/en
Application filed by First Data Corp filed Critical First Data Corp
Assigned to FIRST DATA CORPORATION reassignment FIRST DATA CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BLAGG, LYNN HOLM, LINDSAY, CAROL A.
Publication of US20030171992A1 publication Critical patent/US20030171992A1/en
Assigned to CREDIT SUISSE, CAYMAN ISLANDS BRANCH, AS COLLATERAL AGENT reassignment CREDIT SUISSE, CAYMAN ISLANDS BRANCH, AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: CARDSERVICE INTERNATIONAL, INC., DW HOLDINGS, INC., FIRST DATA CORPORATION, FIRST DATA RESOURCES, INC., FUNDSXPRESS, INC., INTELLIGENT RESULTS, INC., LINKPOINT INTERNATIONAL, INC., SIZE TECHNOLOGIES, INC., TASQ TECHNOLOGY, INC., TELECHECK INTERNATIONAL, INC., TELECHECK SERVICES, INC.
Priority to US11/956,235 priority patent/US20080091582A1/en
Priority to US11/956,256 priority patent/US20080097856A1/en
Priority to US11/956,221 priority patent/US8073736B2/en
Assigned to TASQ TECHNOLOGY, INC., FIRST DATA RESOURCES, LLC, FUNDSXPRESS, INC., DW HOLDINGS INC., CARDSERVICE INTERNATIONAL, INC., LINKPOINT INTERNATIONAL, INC., TELECHECK SERVICES, INC., SIZE TECHNOLOGIES, INC., INTELLIGENT RESULTS, INC., TELECHECK INTERNATIONAL, INC., FIRST DATA CORPORATION reassignment TASQ TECHNOLOGY, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/385Payment protocols; Details thereof using an alias or single-use codes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207Discounts or incentives, e.g. coupons or rebates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0215Including financial accounts
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0224Discounts or incentives, e.g. coupons or rebates based on user history
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0226Incentive systems for frequent usage, e.g. frequent flyer miles programs or point systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0226Incentive systems for frequent usage, e.g. frequent flyer miles programs or point systems
    • G06Q30/0233Method of redeeming a frequent usage reward
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0235Discounts or incentives, e.g. coupons or rebates constrained by time limit or expiration date
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes

Definitions

  • the present invention relates to rewards associated with accounts. More particularly, the present invention provides systems and methods for performing reward redemptions.
  • Rewards may be accrued in association with various accounts. For example, frequent flyer miles may be accrued in association with a credit card account, and based on activity in the credit card account. These frequent flyer miles may then be exchanged by the owner of the credit card account for travel. However, in general, the frequent flyer miles may not be exchanged by another individual unrelated to the credit card account.
  • such frequent flyer miles can be donated to a charitable organization, such as, the Make-a-WishTM foundation. These miles can then be used by someone other than the owner of the credit card account. However, the frequent flyer miles can no longer be used by the account owner as they are no longer associated with the account, but rather convert to the charitable organization.
  • value exchangeable for merchandise can be accrued in relation to another credit card account. This can become problematic as this value remains a liability on the books of an issuer of the credit card account. Further, existing mechanisms for controlling or reducing this liability by forcing redemption of the value are cumbersome, and unfriendly to an account owner. In addition, the forced redemption often involves direct intervention by the entity maintaining the account. This increases the costs of account maintenance.
  • the present invention provides systems and methods for fulfilling reward redemptions.
  • the present invention provides systems and methods for accruing and/or redeeming various rewards.
  • the systems and methods include receiving redemption requests associated with an account.
  • the redemption request can be satisfied from a reward associated with the account, by accessing a reward associated with another account, and/or by accessing a reward pool associated with a group of accounts.
  • Redeeming a reward from another account can involve grouping the related accounts and allowing members of the group to perform the settlement function, or by transferring value between accounts and thereby providing a standard reward settlement mechanism.
  • Various of the systems and methods further provide for performing automatic reward redemptions, either by an entity maintaining the account to which the reward is associated, or through use of a fulfillment entity.
  • Such reward redemptions can include redeeming rewards accrued in relation to account(s) based on activity of one or more parties associated with the account(s).
  • These rewards can include point based rewards and/or cash based rewards.
  • Such rewards can include, but are not limited to, frequent flyer miles, travel vouchers, travel certificates, travel tickets, reduced interest rates, value exchangeable at a particular retailer or group of retailers, cell phone minutes, mobile commerce value, sick days, vacation days, cash value rewards, and the like.
  • the accounts can be financial accounts, employee accounts, travel accounts, and/or other accounts associated with accruing rewards.
  • the account can be a credit card account that accrues frequent flyer miles based on purchases applied to the credit card account.
  • One particular embodiment of the present invention provides methods for accruing frequent flyer rewards held in an airline account or under contract with an airline.
  • the methods include providing an account associated with a frequent flyer reward that is augmented based at least in part on activity of a party.
  • a request is received to associate another party with the account, and this added party is associated with the account.
  • the frequent flyer reward accrues based at least in part on activity of the added party.
  • the methods further include receiving one or more requests to redeem the frequent flyer reward.
  • activity by either or both of the parties associated with the account can augment the frequent flyer reward.
  • Such activity can include, for example, travel and/or use of a credit card.
  • Another embodiment of the present invention provides methods for acquiring frequent flyer rewards.
  • the methods include providing at least two accounts that are each associated with frequent flyer rewards. Each account accrues a frequent flyer reward based on activity of the party or parties associated with the respective accounts.
  • the methods further include associating the two accounts such that a combination of the frequent flyer rewards from the respective accounts is accessible by a party associated with one of the accounts.
  • the method includes aggregating the frequent flyer reward from one account with the frequent flyer reward from the other account in a reward pool.
  • the reward pool can be linked with either one of the accounts, or with an account group in which the accounts are associated.
  • the methods further include reception of a reward redemption request from a party associated with one of the accounts.
  • This redemption request can be satisfied using the reward associated with the account with which the party is associated.
  • the redemption request can be satisfied using the reward pool, or an account in the account group other than that which the party is associated.
  • methods for redeeming rewards include receiving a reward redemption request that indicates the type of reward to be redeemed.
  • An account that accrues that type of reward is identified, and a reward of the indicated type is accessed to at least partially satisfy the reward redemption request.
  • a reward redemption request for a plane ticket obtainable using frequent flyer miles is received. Based on this redemption request, one or more accounts that accrue such frequent flyer miles is accessed. A portion of the frequent flyer miles from these one or more accounts are deducted from these account and used to satisfy the redemption request.
  • the reward redemption request is not necessarily associated with any of the accounts from which the rewards are obtained.
  • the redemption request is received in relation to an account associated with an account group, and the accounts from which the reward is deducted are also associated with the account group.
  • settlement of the reward transfer can be handled privately between members of the account group.
  • no settlement is provided, rather an open sharing system is implemented.
  • the account to which the redemption request is related is not related to the account(s) from which the reward is deducted.
  • a public settlement mechanism may be utilized to transfer value for the reward from one account to another.
  • the accounts can be sick days accounts maintained with an employer or insurance company, vacation days accounts maintained with an employer, financial accounts associated with one or more financial products, and the like.
  • the identified account is a first account
  • the reward associated with the first account is a first reward
  • the reward redemption request is associated with a second account.
  • a reward associated with the second account can also be accessed to at least partially satisfy the reward redemption request where the second reward is associated with the second account.
  • the identified account is a first account and the reward redemption request is associated with a second account.
  • the methods can further include converting the reward associated with the first account to a common value, and transferring the common value from the second account to the first account.
  • a certain type of reward can be shared, while another type of reward is not shared. As just one example, all frequent flyer miles might be shared, while cash back bonuses are not shared.
  • the identified account is a first account
  • the reward type is a first reward type
  • the reward redemption request is associated with a second account that accrues a second reward type.
  • the methods can further include converting the reward of the first reward type to a common value, converting a reward of the second reward type to the common value, and transferring the common value from the second account to the first account.
  • Such methods include receiving a reward redemption request associated with an account that includes a reward amount. It is determined that the reward amount is greater than a reward associated with the account. The reward redemption request is then pended, or stored in a pending state until a later event allows for the reward redemption request to be satisfied.
  • the reward redemption request remains pending until the reward associated with the account is augmented and becomes larger than that required to satisfy the redemption request. In other instances, the reward associated with the account is augmented and, while still less than that required by the redemption request, is within a predefined amount of the redemption request, thus allowing the redemption request to be satisfied on credit.
  • a reward accrual velocity or the rate at which the reward has been augmented over some period, can be calculated.
  • This reward accrual velocity can be used to calculate a point in time where the reward will be sufficient to satisfy the reward redemption request.
  • the reward redemption request can be satisfied on credit.
  • the redemption request can be satisfied immediately and the deficit portion of the reward deducted from the account over the succeeding month(s).
  • the methods further include determining that the reward amount is less than the reward associated with the account, and satisfying the reward redemption request, while in other instances, the methods include determining that the reward amount is within a predefined amount of the reward associated with the account, and satisfying the reward redemption request.
  • the predefined amount can be a reward amount, a time period, or the like.
  • the reward associated with the account is augmented based at least in part on activity in the account.
  • the account is a first account
  • the reward is a first reward
  • the first account and a second account are associated in an account group
  • a second reward associated with the second account is combined with the first reward in a reward pool
  • determining that the reward amount is greater than the reward associated with the first account further includes determining that the reward amount is greater than a reward available from a reward pool.
  • Yet other reward redemption embodiments provide for receiving a reward redemption request that includes a reward amount.
  • the methods further include identifying an account group to which the reward redemption request applies.
  • the identified account group includes at least two accounts. It is determined that the reward amount is greater than an accrued reward accessible via the account group, and the reward redemption request is pended.
  • a pended redemption request causes a reduction in the amount of reward that can be allocated to a future redemption request.
  • a request for ten-thousand miles may be pended.
  • a future request for thirty-thousand miles may be denied and not pended as the amount of reward that would remain pended would surpass a predefined threshold.
  • methods for redeeming rewards include monitoring activity associated with an account.
  • a reward associated with the account is augmented based at least in part on the monitored activity. Once it is determined that the augmented reward has achieved a defined level, the reward is automatically redeemed.
  • these methods further include providing an indication to a party associated with the account that the defined reward level is achieved, directing the party to an Internet web page, and presenting a group of options for redeeming the reward. In other instances, a regular letter can be sent. Based on this, one of ordinary skill in the art will recognize locations other than the Internet, or in addition to the Internet, to which the party may be directed to complete a redemption. For example, the party may directed to an interactive voice response (IVR) system, or other automated redemption system.
  • IVR interactive voice response
  • the methods can further include receiving an indication of an option selected by the party, and providing the selected option to the party.
  • options can include, but are not limited to, cell phone minutes, mobile commerce value, merchandise, reduced interest rates, cash back, and travel rewards.
  • providing the option can include uploading mobile commerce value to mobile commerce device maintained by the party.
  • the party can then use the mobile commerce value that was uploaded.
  • the party can, for example, make purchases at a mobile commerce enabled vending machine, or the like.
  • Various instances include identifying an accrued reward, and the identified party associated with the account to a fulfillment entity. It is also indicated that the fulfillment entity provided compensation for the accrued reward to the party associated with the account, and the amount of the compensation is deducted from the accrued reward.
  • the fulfillment entity is a retailer, or group of retailers, providing merchandise in exchange for the accrued reward. In such cases, the retailer(s) can provide all of the reward processing thus limiting the burden on an issuer maintaining the account.
  • the fulfillment entity may further, provide an indication to the party associated with the account that the defined reward level is achieved, direct the party to a fulfillment mechanism, and present a group of options for redeeming the reward.
  • FIG. 1 is a block diagram illustrating an exemplary relationship between a card processing and service provider, issuers and cardholders;
  • FIG. 2 is a block diagram illustrating an exemplary relationship between a card processing and service provider, an issuer and the cardholders within a group in accordance with an embodiment of the present invention
  • FIG. 3 is a block diagram illustrating the relationship between a card processing and service provider, issuers and the cardholders within a group in accordance with an embodiment of the present invention
  • FIG. 4A is a block diagram illustrating the files included in the group master data in accordance with an embodiment of the present invention.
  • FIG. 4B is a block diagram illustrating group master data in accordance with an embodiment of the present invention.
  • FIG. 5 is a flow diagram illustrating the steps for creating a group using new accounts in accordance with an embodiment of the present invention
  • FIG. 6 is a flow diagram illustrating the steps for creating a group using existing accounts in accordance with an embodiment of the present invention
  • FIG. 7A is a flow diagram illustrating the steps for adding a dependent account to a group in accordance with an embodiment of the present invention
  • FIG. 7B is a flow diagram illustrating the steps for authorizing a transaction in accordance with an embodiment of the present invention.
  • FIGS. 8A and 8B are flow diagrams illustrating the steps for applying a payment in accordance with an embodiment of the present invention.
  • FIG. 9 is a flow diagram illustrating the steps for identifying intended recipients of statement data and providing statement data in accordance with an embodiment of the present invention.
  • FIG. 10 is a flow diagram illustrating the steps for redeeming group reward points in accordance with an embodiment of the present invention.
  • FIG. 11 illustrates a system in accordance with embodiments of the present invention for accruing and redeeming rewards
  • FIG. 12 illustrates a flow diagram for receiving and pending reward redemption requests in accordance with embodiments of the present invention
  • FIG. 13 illustrates a flow diagram for redeeming reward redemption requests according to various embodiments of the present invention, where parties associated with an account initiate the reward redemption requests;
  • FIG. 14 illustrates a flow diagram for redeeming reward redemption requests in accordance with embodiments of the present invention, where an account that accrues a particular type of reward is identified and the reward obtained therefrom;
  • FIG. 15 illustrates a flow diagram for redeeming reward redemption requests in accordance with embodiments of the present invention, where redemption requests are automatically generated.
  • the present invention is directed to systems and methods for facilitating the redemption of rewards.
  • rewards are associated with accounts including, but not limited to, financial accounts, incentive accounts, employee accounts, insurance accounts, and the like.
  • rewards can include, but are not limited to frequent flyer miles, travel vouchers, travel certificates, travel tickets, reduced interest rates, value exchangeable at a particular retailer or group of retailers, cell phone minutes, mobile commerce value, sick days, vacation days, reduced interest rates, and the like.
  • the present invention further addresses issues related to pending rewards, accesssing rewards from related and unrelated accounts and/or account groups, automatic reward fulfillment, public and private settlement of reward exchanges, and associating parties and/or accounts to facilitate reward accrual and/or redemption.
  • aspects of the present invention are directed at systems and methods for for linking accounts corresponding to different products together to create a group so that group processing can be performed at the group level while independent processing of the accounts is performed at the account level.
  • the accounts in a group can span multiple products.
  • a typical group includes a key account and one or more dependent accounts.
  • Each group has a primary owner. Generally the primary owner corresponds to a cardholder for the key account.
  • Some of the methods include forming account groups and utilizing various redemption, fulfillment, and/or chasing ideas in relation to the account groups.
  • Such methods can include linking the accounts into a group by linking a financial record for each account to group master data for the group.
  • the group master data includes information about the group and the group members, including group control settings, group aggregate data, and a group identifier.
  • the financial records include information about the corresponding account, a relationship parameter specifying whether the corresponding account is a key account or a dependent account, and if the financial record corresponds to a dependent account, a dependent strategy identifier.
  • the relationship between a dependent account and the group is specified by a dependent strategy.
  • a dependent strategy specifies group processing options for the dependent account.
  • the relationship between a dependent account and the group can be changed by selecting a new dependent strategy.
  • FIG. 1 illustrates an exemplary relationship between a card processing and service provider 100 , a number of issuers 102 a , 102 b . . . 102 c , and a number of cardholders 120 .
  • the card processing and service provider 100 supports the issuers by authorizing and processing monetary transactions, as well as providing support for creating new accounts, modifying accounts, generating cardholder statements, applying payments to accounts, controlling communications to cardholders and building reward programs.
  • An issuer, such as, issuer 102 b is typically a bank or other financial institution that issues one or more credit card products.
  • the issuer manages transaction processing at the account level.
  • An issuer typically manages a number of accounts using a hierarchy, such as the Product/System, Principal, and Agent hierarchy shown in FIG. 1.
  • the cardholders 120 are typically individuals holding a credit card or charge card, such as a VISATM, MASTERCARDTM, or private label card.
  • additional elements may also be included. For example, additional issuers, Products/Systems, Principals, and Agents may exist.
  • An issuer can issue different types and versions of credit card products.
  • issuer 102 b could offer a VISATM product and a MASTERCARDTM product. Each product could be offered in standard, gold and platinum versions.
  • the Product/System blocks shown in FIG. 1 correspond to different products. If issuer 102 b issues a VISATM product and a MASTERCARDTM product, then Product/System 104 a could correspond to the VISATM product and Product/System 104 b could correspond to the MASTERCARDTM product.
  • An issuer typically uses either a BIN (bank identification number) or an IIN (issuer identification number) to identify its different credit card products.
  • FIG. 1 illustrates that below the Product/System level is the Principal level and below the Principal level is the Agent level.
  • the divisions between the Principal level and the Agent level are typically defined by the issuer.
  • Some issuers use the Principal level and the Agent level to make geographical divisions.
  • Principal block 106 a could correspond to a geographic region, such as the southeast, and Agent block 110 a could correspond to a state within that region.
  • the cardholders 120 are located below the Agent level.
  • a number of cardholders can be associated with a single Agent.
  • FIG. 1 illustrates an example of the hierarchical relationships that exist between an issuer and a cardholder. As will be apparent to those skilled in the art, alternative hierarchies are also possible.
  • An individual can hold a number of different cards corresponding to a number of different accounts. Although the same cardholder is associated with each of the accounts, each account is processed independently by the issuer. If several cardholders are in the same family, then each cardholder may hold several cards. In the case of a family, the cardholders may be related and the payments may be made from family funds, but each account is still processed independently. For example, Table 1 illustrates the credit cards held by a typical family including friends and co-workers.
  • Each of the accounts shown in Table 1 is an independent account from the perspective of the entity maintaining the account, whether it be an issuer, an insurance provider, an employer, or the like.
  • the standard MASTERCARDTM account associated with the daughter (Account 6) is independent of the standard MASTERCARDTM account associated with the grandfather (Account 8) and the gold MASTERCARDTM account associated with the mother (Account 2) is independent of the gold MASTERCARDTM account associated with the father (Account 3).
  • various accounts can be grouped including, but not limited to, financial accounts associated with one or more financial products, insurance benefit accounts, employer benefit accounts, and the like.
  • a reward account such as a frequent flyer miles account associated with one or more travel providers could be used in relation to the present inventions.
  • the processing options used by the issuer to process the accounts shown in Table 1 can differ by product.
  • the card processing and service provider 200 supports the issuer 202 .
  • the issuer 202 issues a variety of credit card products, including a standard VISATM product 204 a , a standard MASTERCARDTM product 204 b , a gold MASTERCARDTM product 204 c , and a private label product 204 d .
  • Account 1 and Account 5 are shown under the standard VISATM product 204 a
  • Account 6 and Account 8 are shown under the standard MASTERCARDTM product 204 b
  • Account 2 and Account 3 are shown under the gold MASTERCARDTM product 204 c
  • Account 4 and Account 7 are shown under the private label product 204 d.
  • the accounts shown in Table 1 and FIG. 2 can be linked together to create a group.
  • a group can include a number of accounts that correspond to a single issuer.
  • group processing can be performed on the accounts that are members of the group while maintaining independent processing of each of the accounts.
  • Each group has a primary owner.
  • the primary owner corresponds to a cardholder for a key account.
  • the standard VISATM account held by the mother could be designated as the key account for the group shown in Table 1 and FIG. 2.
  • the remaining accounts in the group are referred to as dependent accounts.
  • the relationship between a dependent account and the group is independent of the relationship between the remaining dependent accounts and the group.
  • the issuer defines the possible relationships between a dependent account and the group.
  • FIG. 2 shows one possible organization for a group. Other organizations are also possible.
  • the accounts in a group can be associated with different products. There are no restrictions on the placement of the accounts in a group at the Product/System, Principal or Agent levels. The accounts in a group can be split between different Products/Systems, Principals and Agents.
  • the key account and a dependent account can be associated with the same Agent. Multiple dependent accounts can also be associated with the same Agent. The accounts associated with an Agent are not required to be in the same group (or any group at all).
  • FIG. 3 shows an exemplary group where the key account and Dependent Account 1 are associated with the same Agent 308 a .
  • Dependent Account 2 is associated with a different Agent 308 b , but is the same type of product 304 a as the key account and Dependent Account 1.
  • Dependent Account 3 is associated with a different Principal 306 b than the key account, Dependent Account 1, and Dependent Account 2, but is the same type of product 304 a .
  • Dependent Account 4 is associated with a different Agent 308 d than Dependent Account 3, but is associated with the same Principal 306 b .
  • Dependent Account 5 is a different product 304 b than any of the other accounts in the group.
  • FIG. 3 only shows a single group, additional groups or individual accounts can exist under the issuer 302 b . Furthermore, additional groups can exist under the other issuers 302 a , 302 c.
  • FIG. 4A illustrates the linking of the accounts shown in Table 1 into a group.
  • the Group Master Data 400 includes information about the group, including group control settings, group aggregate data, and a group identifier.
  • the Group Master Data 400 is discussed in more detail below in connection with FIG. 4B.
  • the Key Financial Record 402 corresponds to the key or primary owner.
  • the Key Financial Record 402 can also correspond to a key account held by the primary owner.
  • the Key Financial Record 402 corresponds to the standard VISATM account held by the mother.
  • the relationship 420 between the Key Financial Record 402 and the Group Master Data 400 is a predefined relationship. Typically, the relationship is defined in part by the card processing and service provider and in part by the issuer.
  • the group also includes Dependent Financial Records 404 , 406 , 408 , 410 , 412 , 414 , and 416 that correspond to the dependent accounts.
  • a dependent account is associated with each dependent financial record.
  • Account 2 is associated with Dependent Financial Record 1 404 .
  • Each account is also associated with one or more cardholders, e.g. the mother is the cardholder associated with Account 2.
  • the dependent accounts in the group can cross product lines.
  • Account 2 and Account 3 are MASTERCARDTM products
  • Account 4 and Account 7 are private label products
  • Account 5 is a VISATM product
  • Account 6 and Account 8 are MASTERCARDTM products.
  • the relationship 422 between Dependent Financial Record 1 404 and the Group Master Data 400 is independent of the relationship between the remaining Dependent Financial Records and the Group Master Data.
  • the dependent accounts can also have different types of ownership.
  • the primary owner and a dependent cardholder can be jointly responsible for a dependent account
  • the primary owner can be responsible for a dependent account where a dependent cardholder is an authorized user, or a dependent cardholder can be solely responsible for a dependent account.
  • a dependent cardholder can be jointly liable with the primary owner for the group liability. If a dependent cardholder is jointly liable with the primary owner for the group, then the dependent account is a jointly liable dependent account.
  • FIG. 4B illustrates a number of files 402 - 428 .
  • Each of the files includes records that contain information about the group and the accounts that are members of the group.
  • the Group Data file 404 includes information about the group, such as a group identifier, a group cycle code, a group credit line, group available credit, and a group collector code.
  • the group identifier identifies the group.
  • Each of the records associated with the group includes the group identifier.
  • a group cycle code indicates the cycle code for the group. If the group includes a key account, then the cycle code for the key account typically is used as the group cycle code. If the group does not include a key account, then the group cycle code can be a default cycle code or can be based upon the cycle code of one of the dependent accounts in the group.
  • the group credit line specifies the credit available for the accounts in the group that authorize against the group credit line.
  • the group available credit specifies the current credit available for the accounts in the group that authorize against the group credit line.
  • the group collector code may be set once a collector is assigned to one of the accounts in the group. A collector may be assigned because the account is delinquent. If another account in the group becomes delinquent, then the group collector code is checked and the same collector is assigned to that account if a group collection option is used.
  • the Primary Owner file 402 includes information about the primary owner of the group.
  • the primary owner is the individual that is liable for the group. If more than one individual is liable for the group, then those individuals are jointly liable for the group and information about the individuals in stored in the Primary Owner file 402 .
  • a primary owner and a dependent cardholder could be jointly liable for the group.
  • the term “primary owner” is used herein to include a single primary owner or joint primary owners. Every group has a primary owner. If the group includes a key account, then the key cardholder is the primary owner.
  • the Group Member file 408 includes a record for each of the accounts that is (or was) a member of the group. Each record includes an account number, an indication as to whether the account is a key account or a dependent account, and group membership information. A record is maintained for an account in the Group Member file 408 even if the account is delinked from the group. Each record includes group membership information which indicates when the account was linked to the group and if the account is no longer a member of the group, when the account was delinked from the group.
  • the Address file 406 includes a record for each of the accounts that is (or was) a member of the group. Each record includes the mailing address of the cardholder associated with the account.
  • the Member Relationship file 410 includes a record for each of the accounts that is (or was) a member of the group.
  • a member relationship record contains information about the strategy associated with an account. If the strategy associated with the account has changed, then the member relationship record contains information about the previous strategy or strategies, as well as the current strategy. The member relationship record also contains information about the effective dates of each strategy.
  • the Strategy Definition file 412 includes a record for each of the defined strategies.
  • the strategy definition records include the parameters and the parameter values that define the strategies referred to in the member relationship records. If the definition of a strategy has changed, then the strategy definition record for that strategy also includes the parameter and the parameter values that defined the previous version or versions of the strategy, as well as the effective dates of each strategy definition.
  • the Member Statement file 411 includes records for each account that is (or was) a member of the group. Each record includes a number of fields that store statement data (monetary information) for the associated account. In addition, each record includes a flag that indicates whether the associated account cycles with the group (i.e. has the same cycle code as the group) or cycles independently. The information stored in the Member Statement file 411 is used to generate the group statement, dependent cardholder statement, and/or a courtesy statement.
  • the Group Statement file 418 includes records that contain group monetary and group non monetary information.
  • the group monetary information includes the group balances, as well as the group credit line and group available credit for a particular statement.
  • the group non monetary information includes the group payment due date. Typically, the group payment due date is the earliest due date of all the accounts of the group that are paid by the primary owner.
  • the information stored in the Group Statement file 418 is used to generate the group statement.
  • the information in the Member Statement file 411 and the Group Statement file 418 is used to determine the initial break up of a group payment.
  • the information is also used to support the on line display of statement information to an operator.
  • the Group Rewards file 414 includes a record for each of the reward programs for the group. Each record includes information about the reward program, such as a reward program identifier and the amount of group points accumulated in that reward program.
  • Custom Calculation Definition file 416 and the Custom Calculation Values file 420 support customized group calculations that appear in a field on the group statement.
  • Each custom calculation definition record includes a formula for a customized group calculation.
  • a formula specifies that a customized group calculation is calculated using monetary elements from the accounts in the group.
  • the value that is calculated using the formula is stored in a custom calculation values record.
  • the Group Payment file 422 includes a record for each group payment received. Each record includes the amount of the group payment and the date the group payment was received.
  • the Payment Allocations file 426 includes a record for each group payment received. Each record indicates how the group payment was allocated among the accounts in the group.
  • the Group Reversal file 424 includes a record for each group payment that has been reversed. If a group payment is reversed, then the reversal is made by referencing the Payment Allocation file 426 to determine how the payment was originally allocated.
  • the Rejects file 428 includes records of rejections detected during processing other than group processing.
  • a record in the Rejects file 428 includes a rejection report that provides details of the rejection.
  • the files shown in FIG. 4B are exemplary group master data files.
  • the group master data could be stored using alternative types of files and records.
  • the relationship shown in FIG. 4A between the Dependent Financial Records 422 , 424 , 426 , 428 , 430 , 432 , 434 and the Group Master Data 400 is defined by a set of parameters.
  • the parameters are typically provided by the card processing and service provider.
  • a set of parameters and parameter values can be selected to create a customized dependent strategy.
  • Either the card processing and service provider or the issuer can select the parameters and the parameter values to create a dependent strategy.
  • the card processing and service provider provides parameters and the issuer selects a set of parameter values that is suitable for a particular situation.
  • the card processing and service provider could provide strategies rather than parameters to define the strategies.
  • each of the issuers supported by the card processing and service provider chooses among the same group of strategies. However, if the card processing and service provider provides parameters, then each issuer can customize the strategies offered to its customers.
  • the dependent strategies are labeled. For example, a dependent strategy for a college-age child residing at school may have one label, whereas a dependent strategy for a second account for the primary owner may have another label.
  • a dependent strategy specifies the relationship between a dependent account and the group by specifying group processing options for the account.
  • the group processing options provide flexibility in the relationships between the dependent accounts and the group and provide for automatic processing at the group level.
  • the dependent strategy includes parameters that define how transactions are authorized for the dependent account, as well as whether payment for the account is due from the primary owner or from the dependent account cardholder.
  • the dependent strategy includes options for payment application, statement generation, cardholder communications, and reward pooling.
  • the parameter values could be selected to create a dependent strategy appropriate for a dependent, college age child that resides at school.
  • the parameter values could be selected so that the child is liable for the account and the parent receives information about the activity of the account.
  • the parameter values could be selected so that the parent and the child are jointly liable for the account and that both the parent and the child receive information about the activity of the account at their respective residences.
  • Another strategy could be created for a high school age child living at home.
  • the parameter values could be selected so that the primary owner, typically the parent, is financially liable for the account and the account has a predetermined limit. The primary owner could set the limit on the account.
  • the parameter values could also be selected to create a strategy for a dependent account held by the primary owner.
  • the primary owner could use the key account and the dependent account to segregate expenses.
  • the parameter values could be selected so that the primary owner is liable for the account and detailed information about the account is included on the group statement.
  • additional strategies can also be created to address the needs of other situations.
  • a group can be created using new accounts. Another way to create a group is to link a number of existing accounts together. Typically, a group is created by an issuer. The group can be created using either on line or batch processing. Once the first account is identified as being a member of the group, the group master data is automatically generated. Once a group is created, additional accounts can be added to the group or existing accounts can be removed from the group.
  • Business rules are used to insure that the relationships between the accounts in the group are valid.
  • the business rules define the types of accounts that can be linked together in a group.
  • the business rules are promulgated by the card processing and service provider.
  • the business rules are checked whenever group relationships are impacted. For example, the business rules are checked when a group is created or an account is added to or removed from a group. Shown below is a list of typical business rules. As will be apparent to those skilled in the art, the number and types of business rules may vary from that shown below.
  • a group must have one and only one primary owner.
  • a group will not exist without at least one account linked to it or a historical relationship to an account.
  • a dual account is an account that corresponds to two different credit card products.
  • a dual account could correspond to a VISATM product and a MASTERCARDTM product.
  • a Combine Account Transfer is a process that merges two accounts into a single joint account.
  • step 500 An exemplary method for creating a group using new accounts is shown in FIG. 5.
  • a new account is opened.
  • the new account is designated as the key account in step 502 by setting a relationship parameter for the account to “key.”
  • the relationship parameter defines the relationship between the account and the group.
  • a number of account parameters and group parameters are automatically set. For example, parameters defining the cycle code and method and the currency code are typically defined at the time the account is opened.
  • step 504 the parameters set in step 500 are compared to the set of business rules. If the parameters set in step 500 satisfy the business rules, then the business rules are validated.
  • step 508 the group build is initiated and the key financial record and the group master data are created.
  • the key financial record includes the account parameters for the key account plus the relationship parameter and a group identifier.
  • the group master data includes a group identifier and certain group parameters.
  • FIG. 5 illustrates that a key account is created in steps 500 and 502
  • a group can be created without a key account. If a key account is created, then the key account cardholder is the primary owner. However, if a group is created without a key account, a primary owner is required. A key financial record is created regardless of whether the group includes a key account.
  • step 510 a determination is made as to whether a dependent account is to be added to the group. If a dependent account is to be added to the group, then the “Yes” branch is followed to step 512 and a new account is opened. The new account is designated as a dependent account by setting the relationship parameter for the account to dependent. From step 512 , the method proceeds to step 514 where a dependent strategy is selected. Typically, an issuer provides a number of dependent strategies that can be used for dependent accounts within a group. Once a dependent strategy is selected, then a determination is made in step 516 as to whether the parameters selected in opening the dependent account and the dependent strategy satisfy the business rules.
  • step 518 the dependent financial record is created and the group master data is updated.
  • the dependent financial record includes account parameters for the dependent account, as well as the relationship parameter, a group identifier, and a dependent strategy identifier. Updating the group master data includes creating the link between the dependent financial record for the dependent account and the group master data.
  • step 518 the method returns to step 510 and a determination is made as to whether another dependent account is to be added. If another dependent account is to be added, then steps 512 , 514 , 516 , and 518 are repeated. Once all the dependent accounts have been added, then the method proceeds from step 510 via the “No” branch to step 506 and the method ends.
  • FIG. 5 illustrates that business rules are validated after the key account or a dependent account is opened. Alternatively, if the accounts are opened in an on line environment, then the business rules can be validated as the accounts are opened. For example, an operator can be prevented from creating an invalid relationship, such as creating two key accounts.
  • FIG. 5 also illustrates that the group master data is updated after the addition of each dependent account. However, the group master data can be updated at other times. For example, information for opening a key account and dependent accounts may be collected by the issuer and then submitted by the issuer to the card processing and service provider in batch. If the information is submitted in batch, then the group master data may be updated once with information for all of the accounts in the group.
  • FIG. 6 illustrates the steps for creating a group using existing accounts.
  • an existing account is selected as the key account by setting the relationship parameter for the account to key. If the account was not previously a member of a group, then the relationship parameter was blank.
  • a determination is made as to whether the business rules are validated. The business rules are validated if the parameters for the key account satisfy the business rules.
  • step 604 the group build is initiated. Initiating the group build includes creating the group master data, and linking the key account to the group by linking the key financial record to the group master data.
  • step 606 a determination is made in step 606 as to whether a dependent account is to be added to the group. If a dependent account is to be added to the group, then the “Yes” branch is followed to step 608 .
  • step 608 an account is selected as a dependent account. Once an account is selected as a dependent account, the relationship parameter for the selected account is set to dependent.
  • step 610 a dependent strategy is selected for the dependent account. From step 610 the method returns to step 606 and a determination is made as to whether another dependent account is to be added to the group.
  • step 612 a determination is made as to whether the business rules are validated.
  • the business rules are validated in step 612 , if the dependent accounts satisfy the business rules. If the business rules are validated in step 612 , then the “Yes” branch is followed to step 614 .
  • step 614 the group master data is updated with information for the dependent accounts. In addition, the dependent financial records for the dependent accounts are linked to the group master data.
  • the business rules are not validated in step 612 , then the “No” branch is followed to step 616 and an error occurs.
  • FIG. 6 illustrates that the group master data is updated after all the dependent accounts have been selected, those skilled in the art will appreciate that the group master data could be updated at other points in the process. For example, if the group is being created using on line processing, then validating the business rules and updating the group master data could occur after step 610 for each dependent account added.
  • the relationships between the accounts of the group are flexible and can be modified.
  • the relationship between a dependent account and the group can be changed by selecting a new dependent strategy.
  • the ability to modify, the dependent strategy allows the account to change as the cardholder's situation changes. For example, if the initial dependent strategy was a strategy suitable for a high school age child living at home, then the dependent strategy could be modified to a strategy suitable for a college age child living at school once the child enters college and moves away from home. Changing the dependent strategy of one of the dependent accounts does not impact the dependent strategies of the other dependent accounts.
  • a dependent account can be added to the group or deleted from the group without affecting the remaining accounts in the group.
  • the ability to add dependent accounts and delete dependent accounts allows the group to change to accommodate changes in the relationships between the primary owner and the dependent cardholders.
  • the dependent financial record for the dependent account is linked to the group master data. Adding a dependent account to a group may correspond to the primary owner or a dependent cardholder obtaining another card or may correspond to adding another dependent cardholder to the group.
  • a group could be established for a family that includes a mother, father and daughter. When the group is created, the group could include financial records corresponding to accounts held by the mother and father. Subsequently, a dependent financial record could be added for an account for the daughter.
  • the dependent financial record for the dependent account is delinked from the group master data.
  • Removing a dependent account from a group may correspond to a change in family status. For example, a group could be established for a married couple with the husband as the primary owner and the wife as a dependent cardholder. If the couple divorces, then the group could be modified to delete the dependent financial records that correspond to accounts held by the wife. As will be apparent to those skilled in the art, a dependent account can also be removed from a group for reasons other than a change in family status.
  • a single account can be removed from a group or a number of accounts can be removed from a group. If an account is removed from a group, it can be moved to an existing group, used to create a new group, or can be designated as an independent account that is not a member of any group. If a dependent account is moved to an existing group, then the group identifier in the dependent financial record is changed to correspond to the group identifier for the existing group. If a dependent account is removed from one group and is used to create another group, then the dependent account can remain a dependent account or can be “matured” into a key account. To mature a dependent account into a key account, the relationship parameter for the dependent account is changed from dependent to key.
  • the relationship parameter is set to blank.
  • the primary owner of the group can be changed.
  • the primary owner can be changed to a cardholder that corresponds to one of the dependent accounts or to a new primary owner.
  • the relationship parameter for the dependent account is changed from dependent to key.
  • the original key account can be converted to a dependent account by changing the relationship parameter from key to dependent.
  • the original key account can be removed from the group and transferred to another group (as either a key or dependent account) or established as an individual account in a manner similar to that described in the preceding paragraph.
  • a group history is maintained in the group master data. For example, as discussed above in connection with FIG. 4B, information on all the accounts that are or ever were members of the group are stored in the Group Member file. The history of any changes in the dependent strategy for a dependent account are maintained in the Member Relationship file and the history of any changes in the definition of a strategy is maintained in the Strategy Definition file. In addition to group history, account history is also maintained with each account. The account history follows the account notwithstanding changes in the account's membership in a group. For example, payment history for a dependent account follows the dependent account even if the dependent account is delinked from the group and is established as an individual account.
  • FIG. 7A illustrates the steps for adding a dependent account to an existing group.
  • a group is identified. Typically a group is identified using the group identifier.
  • a determination is made as to whether an existing account is to be added or whether a new account is to be added. If a new account is to be added, then the “Yes” branch is followed to step 704 .
  • a new account is opened and the relations hip parameter for the account is set to dependent.
  • a dependent strategy for the new account is selected in step 706 .
  • step 708 a determination is made as to whether the dependent account opened in step 704 satisfies the business rules. If the dependent account satisfies the business rules, then the business rules are validated and the “Yes” branch is followed to step 710 . In step 710 , the group master data is updated. If the business rules are not validated in step 708 , then the “No” branch is followed to step 722 and an error occurs.
  • step 702 determines whether an existing account is to be added. If the determination in step 702 is that an existing account is to be added, then the “No” branch is followed to step 712 .
  • step 712 an existing account is selected and the relationship parameter for the account is set to dependent.
  • a dependent strategy for the account is selected in step 714 .
  • the parameters for the dependent account created in step 712 are compared to the business rules in step 718 . If the parameters for the dependent account satisfy the business rules, then the business rules are validated and the “Yes” branch is followed to step 720 . In step 720 , the group master data is updated. However, if the business rules are not validated then the “No” branch is followed to step 722 and an error occurs.
  • FIG. 7A indicates that the group master data is updated after each dependent account is added to the group
  • the group master data can be updated at other points in the process. For example, if multiple accounts are to be added to an existing group, then the steps shown in FIG. 7A would be repeated for each account. Rather than updating the group master data after the addition of each dependent account, the group master data could be updated after the addition of all the dependent accounts. Updating the group master data after the addition of each account can be used to support on line processing, whereas updating the group master data after the addition of a number of dependent accounts can be used to support batch processing.
  • Group processing typically includes authorizing transactions, applying group payments, creating group statements, controlling cardholder communications, and administering reward programs for the accounts in the group.
  • Information from both the key account and the dependent accounts are used for group processing.
  • Each dependent account has an associated dependent strategy that specifies group processing options for the dependent account.
  • the dependent strategy for a dependent account specifies the authorization option for the dependent account.
  • the authorization option specifies the information that is used to authorize a transaction.
  • three authorization options are available for a dependent account. One authorization option considers only the credit line and available credit of the group, a second option considers only the credit line and available credit of the dependent account, and a third option considers the credit line and the available credit of both the group and the dependent account.
  • the authorization processing uses the group credit line and the group available credit and/or the dependent credit line and the dependent available credit.
  • the group credit line is a group parameter that typically is set when the group is created.
  • the dependent credit line is a dependent account parameter that is set when the dependent account is opened.
  • the group credit line and the dependent credit line can be modified.
  • the group available credit is calculated real time using activity from the key account (if any) and any dependent accounts that share the group credit line. A dependent account shares the group credit line if payment for the dependent account is due from the primary owner.
  • the group available credit is calculated by subtracting the current balances and any outstanding authorizations of the key account and the dependent accounts that share the group credit line from the group credit line.
  • the dependent available credit is calculated by subtracting the current balance and any outstanding authorizations of the dependent account from the dependent credit line.
  • FIG. 7B illustrates exemplary steps for authorizing a transaction.
  • an authorization request is received.
  • the authorization request includes a transaction amount and an account identifier, such as an account number.
  • a determination is made as to whether the account identifier corresponds to an account that is a member of a group. If the requesting account is not a member of a group, then the “No” branch is followed to step 752 .
  • step 752 normal authorization processing occurs using the credit line and the available credit for the account.
  • Normal authorization processing typically includes several calculations that use the credit line and the available credit. For example, authorization may include comparing the amount of the transaction to the available credit, comparing the amount of the transaction to a percentage expansion of the credit line, as well as comparing the transaction to past transactions for the account. Comparing the transaction to past transactions for the account may be used to detect possible fraudulent uses of a card and may result in the issuance of a referral code. As will be apparent to those skilled in the art, additional calculations can also be performed.
  • step 742 determines whether the requesting account is a member of a group. If the determination in step 742 is that the requesting account is a member of a group, then the “Yes” branch is followed to step 744 .
  • step 744 a determination is made as to whether the requesting account is a key account or a dependent account. If the requesting account is a key account, then the “Yes” branch is followed to step 748 .
  • step 748 normal authorization processing occurs using the group credit line and the group available credit.
  • step 744 determines whether the requesting account is a dependent account. If the determination in step 744 is that the requesting account is a dependent account, then the “No” branch is followed to step 746 .
  • step 746 the dependent strategy is checked to determine the authorization option that corresponds to the dependent account.
  • FIG. 7B illustrates three possible authorization options, A, B and C.
  • Option A specifies that the credit line and the available credit for the group are used for authorization processing.
  • Option B specifies that the credit line and the available credit for both the group and the dependent account are used for authorization processing.
  • Option C specifies that the credit line and the available credit for the dependent account are used for authorization processing.
  • step 746 the method proceeds from step 746 to step 748 and the credit line and the available credit for the group are used for normal authorization processing.
  • step 746 the method proceeds from step 746 to step 752 and the credit line and the available credit for the dependent account are used for normal authorization processing.
  • step 748 uses group information
  • step 752 uses dependent account information.
  • step 750 the credit line and the available credit for both the group and the dependent account are used for authorization processing.
  • step 750 the credit line and the available credit for the dependent account are used in normal authorization processing.
  • the authorization processing performed in step 750 is similar to that performed in step 752 . However, additional processing is required for option B.
  • step 754 a determination is made as to whether the processing performed in step 750 indicates that the authorization request is authorized. If the processing performed using the dependent account information indicates that the request is authorized, then the “Yes” branch is followed to step 758 .
  • step 758 a determination is made as to whether the transaction amount specified in the authorization request exceeds the group available credit.
  • step 760 If the amount does not exceed the group available credit, then the “Yes” branch is followed to step 760 and the authorization request is approved. If the processing performed in step 754 indicates that the authorization request is denied or if the comparison performed in step 758 indicates that the amount of the request exceeds the group available credit, then the “No” branch is followed to step 756 and the authorization request is declined.
  • the dependent strategy for a dependent account specifies whether payment of the dependent account balance is due from the primary owner or is due from the dependent cardholder. If payment of the dependent account is due from the dependent cardholder, then the entire amount of a payment received from the dependent cardholder is credited to the dependent account. However, if the dependent account is paid by the primary owner, then the amount of the group payment that is credited to the dependent account depends upon the amount of the group payment, as well as the control settings for the group. Payment of the key account is due from the group payment.
  • the allocation of a group payment is partially determined by the amount of the payment and partially determined by the group payment options.
  • the group payment options are typically set by the issuer.
  • the group payment options could be part of the group control settings in the group master data.
  • the group payment options could be stored in a separate file, such as a Product Control File, and associated with the group through the key account or through another means.
  • the group balances for the last group statement can be determined from the Group Statement files in the group master data.
  • the account balances for accounts in the group can be determined from the Member Statement files in the group master data.
  • the amount of the group payment is compared to one or more of the group balances.
  • the group balances include the Last Statement Balance (LSB) and the Minimum Payment Due (MPD) for the group.
  • the group balances may also include the group delinquency amount.
  • the group LSB is determined by adding the LSB of the key account (if any) to the LSB of all dependent accounts in the group that are paid by the primary owner. If payment for a dependent account is due from the dependent cardholder, then the LSB of that dependent account is not included in the group LSB.
  • the group MPD is calculated by adding the MPD for the key account (if any) to the MPD for each of the dependent accounts that are paid by the primary owner.
  • the group delinquency amount is determined by adding the account delinquency of the key account (if any) to the account delinquency of the dependent accounts that are paid by the primary owner.
  • FIGS. 8A and 8B illustrate an exemplary method for applying a group payment.
  • the group payment is received.
  • a determination is made in step 802 as to whether the payment is less than the group LSB. If the group payment is greater than or equal to the group LSB, then the “No” branch is followed to step 804 .
  • the payment is applied to the dependent accounts in an amount equal to the LSB for each account. The remainder of the group payment is applied to the key account in step 806 . If the payment is equal to the group LSB, then the amount applied to the key account is step 806 is equal to the LSB of the key account.
  • the group payment is greater than the group LSB
  • the amount applied to the key account in step 806 is greater than the LSB of the key account.
  • FIG. 8A illustrates that any overpayment is credited to the key account, an overpayment could be shared between the accounts of the group. Whether an overpayment is credited to the key account or shared between the accounts is typically determined by the group payment options.
  • step 802 determines whether the group payment is less than the group LSB. If the determination in step 802 is that the group payment is less than the group LSB, then the “Yes” branch is followed to step 808 .
  • step 808 a determination is made as to whether the group payment is less than the group MPD. If the group payment is less than the group MPD, then the “Yes” branch is followed to step 810 .
  • step 810 the group payment options are determined.
  • step 812 a determination is made as to whether the group payment options indicate that account delinquency is considered in applying a group payment. If account delinquency is not considered, then the “No” branch is followed to step 814 .
  • step 814 MPD ratios are calculated for the key account and the dependent accounts that are paid by the primary owner.
  • An MPD ratio is calculated for an account by comparing the MPD for the account with the group MPD. Once the MPD ratios for the key account and the dependent accounts that are paid by the primary owner are calculated in step 814 , then in step 816 the payment is applied to the key account and the dependent accounts in the group in accordance with the MPD ratios calculated in step 814 .
  • step 812 determines whether account delinquency is considered in applying the group payment. If the determination in step 812 is that account delinquency is considered in applying the group payment, then the “Yes” branch is followed to step 820 .
  • step 820 the group payment is applied to the key account and the dependent accounts paid by the primary owner to satisfy the delinquent amount for each account.
  • step 822 a determination is made as to whether there is any amount of the payment remaining. If there is an amount of the payment remaining, then the “Yes” branch is followed to step 814 and the remaining payment is allocated based upon the MPD ratios for the key account and the dependent accounts paid by the primary owner. If the determination in step 822 is that there is no remaining balance, then the method ends.
  • step 808 determines whether the group payment is greater than or equal to the group MPD. If the determination in step 808 is that the group payment is greater than or equal to the group MPD, then the “No” branch is followed to step 830 of FIG. 8B.
  • step 830 the group payment is allocated between the key account and the dependent accounts that are paid by the primary owner to satisfy the MPD for each account. A determination is made as to whether there is any amount of the group payment remaining in step 832 . If there is an amount of the group payment remaining, then the method proceeds to step 834 .
  • step 834 a remaining balance ratio is calculated for each of the accounts. A remaining balance ratio is calculated by comparing the remaining balance for an account to the remaining balance for the group. The remaining balance for an account is calculated by subtracting the MPD from the LSB for the account.
  • the remaining balance for the group is calculated by subtracting the group MPD from the group balance. Once the remaining balance ratios are calculated in step 834 , then the remainder of the payment is applied in accordance with the remaining balance ratios in step 836 . If the determination in step 832 is that there is no remaining balance, then the method ends.
  • the group payment could be allocated based upon a LSB ratio rather than an MPD ratio or based upon an account hierarchy.
  • An LSB ratio for an account can be calculated by comparing the LSB for the account to the LSB for the group.
  • An account hierarchy specifies the order in which the accounts of a group are to be paid.
  • MPD ratios could be used as an alternative to the remaining balance ratios illustrated in FIG. 8B.
  • other account conditions could be considered in allocating a group payment. For example, in addition to or as an alternative to considering delinquent amounts, disputed amounts could be considered.
  • the exemplary method for payment application illustrated by FIGS. 8A and 8B is based upon the amount of the group payment, the dependent strategies and the group payment options. Preferably, the steps illustrated in FIGS. 8A and 8B can be overridden. For example, an operator could manually allocate a group payment between the key account and the dependent accounts in accordance with specific allocation instructions.
  • the allocation instructions could be generated by the primary owner of the group or the issuer. If the group payment is an electronic payment, then instructions submitted with the electronic payment could determine how the payment is allocated.
  • the allocation instructions could be for a single payment or could be standing instructions that apply to all payments received. If the allocation instructions are standing instructions, then the instructions could be stored in the group master data.
  • a group statement is created for the group and is sent to the primary owner.
  • the group statement includes information about the activity of the key account (if any) and the activity of some or all of the dependent accounts of the group.
  • the amount of information that appears on the group statement about a dependent account is controlled by the dependent strategy.
  • the group statement can include details of the activity of the dependent account or a summary of the activity of the dependent account.
  • Statement data is calculated for each account in the group.
  • Statement data typically includes the MPD, LSB, reward information, finance charges, and late fees for the account.
  • the statement data is calculated on an account by account basis.
  • the statement data is used to create the group statement, a dependent statement, and/or a courtesy statement.
  • the statement data is also used to calculate group data.
  • Group data includes the group MPD, group LSB, group reward information, group available credit, group finance charges and group late fees.
  • the group data is calculated from the key account and any dependent accounts that are paid by the primary owner.
  • the group statement also includes information about the previous group payment, including the amount, the posting date, etc.
  • the group statement also includes information about the group, such as the primary owner, a listing of the accounts in the group, including the account numbers, and the dependent strategy for each dependent account in the group.
  • a dependent strategy specifies whether payment for the dependent account is due from the primary owner or from a dependent cardholder associated with the dependent account.
  • the dependent strategy can also specify that a courtesy statement is generated.
  • a courtesy statement is a statement that provides statement data to the cardholder, but does not require payment from the cardholder.
  • FIG. 9 illustrates exemplary steps for identifying the addressees or intended recipients of statement data and for providing statement data for inclusion on the group statement, a dependent statement, and a courtesy statement.
  • statement data for the key account (if any) and the dependent accounts are calculated. If the group includes a key account, then the statement data for the key account is provided for the group statement in step 900 .
  • the dependent strategy for a dependent account is checked to determine whether payment for the dependent account is due from the primary owner or from a dependent cardholder associated with the dependent account.
  • step 908 the primary owner of the group is identified as an intended recipient of the statement data for the dependent account and the statement data for the dependent account is provided for inclusion on the group statement.
  • step 910 a determination is made as to whether the dependent strategy specifies that the dependent cardholder receives a courtesy statement. If the dependent strategy specifies that the dependent cardholder receives a courtesy statement, then the “Yes” branch is followed to step 912 .
  • step 912 the dependent cardholder is identified as another intended recipient of the statement data for the dependent account and the statement data for the dependent account is provided for inclusion on the dependent statement. If the determination in step 910 is that the dependent strategy does not specify that the dependent cardholder receives a courtesy statement, then the “No” branch is followed to step 914 and the method ends.
  • step 916 the dependent cardholder of the group is identified as an intended recipient of the statement data for the dependent account and the statement data for the dependent account is provided for inclusion on a statement for the dependent cardholder.
  • step 918 a determination is made as to whether the dependent strategy specifies that the details of the activity of the dependent account are included on the group statement. If the details of the activity of the dependent account are included on the group statement, then the “Yes” branch is followed to step 920 .
  • step 920 the primary owner is identified as another intended recipient of the statement data for the dependent account and the statement data for the dependent account is provided for inclusion on the group statement. If the dependent account statements on the same day as the group, then current statement data is provided for inclusion on the group statement. However, if the dependent account statements on a different day than the group, then statement data associated with the last dependent statement is provided for inclusion on the group statement.
  • step 918 determines whether the details of the activity of the dependent account are not included on the group statement. If the determination in step 918 is that the details of the activity of the dependent account are not included on the group statement, then the “No” branch is followed to step 922 .
  • step 922 the primary owner is identified as another intended recipient of the statement data for the dependent account and a summary of the statement data for the dependent account is provided for inclusion on the group statement.
  • Step 904 illustrates that the dependent strategy for a dependent account is checked. As will be apparent to those skilled in the art, if the group includes multiple dependent accounts, then steps 904 through 922 are repeated for each dependent account.
  • the dependent strategy for a dependent account also provides cardholder communication options for the dependent account.
  • the communication options specify the intended recipient of an original communication, such as a letter, notice, or plastic, and, in the case of letters or notices, specify whether a courtesy copy of the communication is provided.
  • a communication is typically generated to provide information to the cardholder. For example, a communication can be generated to advise a cardholder of changes to the cardholder agreement or to advise a cardholder of special offers.
  • the dependent strategy can specify that the original communication is sent to the primary owner.
  • the dependent strategy can also specify that a courtesy copy of the communication is sent to the dependent cardholder.
  • the dependent strategy can specify that the original communication is sent to the dependent cardholder. If the dependent strategy specifies that the original communication is sent to the dependent cardholder, the dependent strategy can also specify that a courtesy copy of the communication is sent to the primary owner.
  • a dependent account could be jointly held by a first dependent cardholder and a second dependent cardholder. If the dependent strategy specifies that the first dependent cardholder receives the original communication and that the primary owner receives a courtesy copy, then in addition to the courtesy copy sent to the primary owner, a second courtesy copy is sent to the second dependent cardholder because the account is jointly held.
  • the dependent strategies for the dependent accounts can specify that the primary owner is to receive the original communication or a courtesy copy.
  • a group communication can include information about some or all of the accounts within a group. Typically, a group communication is sent to the primary owner of the group. Information about selected accounts of the group is obtained from the financial records corresponding to the accounts. The type of information obtained from the financial records can vary according to the type of communication. Typically, the type of information is specified by a processing option or variable associated with the communication. The information obtained from the financial records is combined into a single communication. The single communication can be automatically generated.
  • a group communication can also be manually created.
  • the group communication can include information about the accounts within the group.
  • an operator can use a series of on line screens to specify the accounts and the type of information to be included in the communication.
  • the primary owner and the dependent account cardholders may also receive notices. Notices are added to a group statement by considering what notices are required for the key account, what notices are required for each of the dependent accounts, and what notices are optional for the key account and the dependent accounts. If several accounts require the same notice, then preferably the notices are reviewed to insure that no duplicates are included.
  • Reward programs allow parties to earn reward points based on purchases and other account activity.
  • the processing of reward points at the account and/or group level can be determined by the reward program and the dependent strategies of the dependent accounts in a group group.
  • the availability of group level pooling is determined by the reward program. It may be that some programs permit group pooling, whereas other programs do not. If the accounts in a group are members of multiple reward programs, then it is possible that some programs permit pooling while other programs do not.
  • any reward points earned by one or more accounts in an account group can be combined into the group reward pool.
  • the dependent strategy specifies whether reward points earned by a dependent account are pooled or are maintained at the account level. In addition, the dependent strategy specifies whether the dependent account cardholder can redeem group reward points.
  • step 1000 An exemplary method for redeeming group reward points is shown in FIG. 10.
  • step 1000 a request to redeem group reward points is received.
  • step 1002 a determination is made as to whether the request is associated with an account that is a member of the group. If the request is from an account that is a member of the group, then the “Yes” branch is followed to step 1004 .
  • step 1004 a determination is made as to whether the reward program supports pooling. If the reward program supports pooling, then the “Yes” branch is followed to step 1006 .
  • step 1006 a determination is made as to whether the account making the request is the key account. If the requesting account is the key account, then the “Yes” branch is followed from step 1006 to step 1012 .
  • step 1008 the dependent strategy for the requesting dependent account is checked. A determination is made in step 1010 as to whether the dependent strategy specifies that the dependent account can redeem group reward points. If the dependent account can redeem group reward points, then the “Yes” branch is followed to step 1012 .
  • step 1012 a determination is made as to whether there are sufficient group points to satisfy the redemption request. If there are sufficient points, then the “Yes” branch is followed to step 1018 and the request to redeem group reward points is authorized. However, if there are not sufficient points, then the “No” branch is followed to step 1014 and the redemption request is not authorized.
  • step 1002 determines whether the request to redeem group reward points is made by an account that is not a member of a group or the determination in step 1004 is that the reward program does not support reward point pooling. If the determination in step 1010 is that the dependent account strategy does not allow the redemption of group reward points, then the method proceeds to step 1016 . In step 1016 the requesting account is permitted to redeem points that are associated with the requesting account, but is not permitted to redeem group points.
  • reward points can be shared between the accounts of a group via chasing. If chasing is implemented, then reward points earned by an account remain at the account level. The points can be chased or collected from the account level and used to satisfy a single redemption request.
  • chasing is enabled or disabled by the reward program. If chasing is enabled by the reward program, then the accounts that participate in the reward program can support chasing. If an account supports chasing, then the account permits another account to redeem its earned reward points. If the account is a key account, then the option to support chasing could be part of the predefined relationship between the key account and the group. If the account is a dependent account, then the option to support chasing could be part of the dependent strategy. The ability to chase reward points could expand beyond the group to accounts that are not members of the group.
  • a cardholder makes a redemption request that exceeds the reward points associated with the cardholder's account, then a determination is made as to whether the reward program supports chasing. If the reward program supports chasing, then the accounts that permit chasing in that reward program are identified. Points are chased from the identified accounts to satisfy the redemption request. The points are chased from the accounts based on a chasing option that specifies how the points are chased from the identified account. The chasing option could specify that the points are chased from the accounts on a pro rata basis, on the basis of an account hierarchy, or on some other basis. Chasing could be performed by an operator pursuant to instructions received by a cardholder.
  • FIG. 10 is directed to reward access in a group environment, such reward access can also be applied to redeeming rewards from a single account associated with a redeeming party, or even an account or account group unrelated to the redeeming party.
  • system 1100 is configured in accordance with an embodiment of the present invention for accruing rewards, identifying rewards, redeeming rewards and/or fulfilling reward redemption requests.
  • system 1100 includes a number of accounts 1105 , 1110 , 1115 .
  • One or more of the accounts are associated with rewards 1106 , 1111 , 1116 .
  • rewards 1106 can be associated with multiple reward types, or only a single reward type.
  • the reward associated with the account is maintained in a separate reward account, while in other cases, the account only serves to maintain the reward.
  • account 1105 can be a credit card account that accrues frequent flyer miles in a separate, but integrally related reward account 1106 .
  • account 1110 can be a frequent flyer account that is augmented based on travel activity, and the primary function of account 1110 is to account for reward 1111 .
  • System 1100 further includes an identification system 1125 , a request format system 1135 , a request reception system 1145 , an account association system 1150 , and a request fulfillment system.
  • Identification system 1125 comprises a computer capable of accessing accounts 1105 , 1110 , 1115 . In accessing accounts 1105 , 1110 , 1115 , identifying system 1125 can determine what type of rewards 1106 , 1111 , 1116 that are associated with accounts 1105 , 1110 , 1115 , as well as the amount of any accrued reward. When rewards are redeemed, or moved to another accounting entity, identification system 1125 can deduct any redeemed reward. In addition, where a reward is redeemed prior to being earned, identification system 1125 can maintain an accounting of the reward deficit until a sufficient reward has been accrued to cover the deficit.
  • identification system 1125 can compute the rate at which the identified rewards are accruing. As such, identification system 1125 can determine an approximate point in time when a sufficiently large award will be available to satisfy a reward redemption request. Further, in some cases, identification system 1125 can be responsible for identifying when a reward threshold has been achieved such that an automatic redemption is triggered. In various cases, identification system 1125 can further assign or otherwise determine a common value associated with any accrued reward. Thus, as further discussed below where rewards are exchanged on a public market, an exchange value for unrelated reward types can be fixed and used in relation to an effectuated exchange. Where such a public exchange is implemented, identification system 1125 can be responsible for transferring value between accounts to cover any exchange of rewards.
  • Request format system 1135 is a computer, or in some cases the same computer as identification system 1125 , that formats one or more requests that affect accounts 1105 , 1110 , 1115 .
  • request format system 1135 includes functionality to parse a reward redemption request and separate an account, a reward amount, and a reward type from a received request.
  • request format system 1135 can parse requests to group accounts, or otherwise modify group relationships as previously described.
  • request format system 1135 can parse fulfillment information such that rewards are deducted from the proper account 1105 , 1110 , 1115 upon redemption of one or more rewards.
  • Request reception system 1145 is a computer, or in some cases the same computer as identification system 1125 , that is responsible for receiving requests in relation to accounts 1105 , 1110 , 1115 .
  • request reception system can provide interfaces for receiving requests from account owners to group accounts and/or modify rules associated with the accounts and account groups.
  • request reception system 1145 serves Internet web pages that include user interfaces for receiving such requests.
  • request reception system 1145 supports an IVR, or other such automated equipment for receiving requests in relation to accounts 1105 , 1110 , 1115 .
  • such interfaces can be provided to receive reward redemption requests, and to view the status of accounts 1105 , 1110 , 1115 .
  • Account association system 1150 is a computer, or in some cases the same computer as identification system 1125 , that implements the business rules related to assembling accounts into account groups, and defining account group rules as previously described. Thus, when a request is received to modify one or more group relationships via request reception system 1145 , account association system 1150 can be accessed to approve the modification, and once approved, identification system 1125 can be accessed to implement the modification in relation to accounts 1105 , 1110 , 1115 .
  • Request fulfillment system 1155 is a computer, or in some cases the same computer as identification system 1125 , that is responsible for assuring that reward redemption requests are satisfied.
  • reward redemption requests are received from consumers and involve an indication of a reward to be redeemed and the person redeeming the reward.
  • such reward redemption requests involve identifying an account that has accrued sufficient rewards to be redeemed, and contacting a person associated with the account to obtain a selection of a reward to be redeemed.
  • request fulfillment system 1155 is maintained by an entity other than the entity maintaining accounts 1105 , 1110 , 1115 .
  • request fulfillment system 1155 can be maintained by a retailer contracted by the entity maintaining accounts 1105 , 1110 , 1115 to provide third party fulfillment of reward redemption requests. This can be advantageous as it allows an entity more capable of fulfilling redemption requests to perform the fulfillment requests, leaving the entity maintaining accounts 1105 , 1110 , 1115 largely unburdened.
  • a flow diagram 1200 illustrating a method for redeeming rewards in accordance with embodiments of the present invention is provided.
  • a reward redemption request is received (block 1205 ).
  • this reward redemption request is received from an owner of an account, while in other embodiments, this reward redemption request is received from a member of an account group.
  • the account and/or account group to which the reward redemption request is associated is then determined (block 1210 ).
  • a sufficient reward is associated with the account group and/or account to satisfy the reward redemption request (block 1215 ).
  • the reward redemption request is to be satisfied from a reward associated with an individual account, it is determined whether the reward associated with the individual account is sufficient to cover the request.
  • the reward is to be satisfied from an account group, it is determined whether a reward pool associated with the account group includes a reward large enough to satisfy the request.
  • the reward is to be satisfied from an account group, it can be determined whether rewards maintained in relation to one or more accessible accounts in the account group, either separate or aggregated, are sufficiently large to satisfy the request. Where the reward(s) are sufficiently large, then the reward redemption request is fulfilled and the reward(s) is/are deducted from the appropriate account(s) and/or account group (block 1220 ).
  • the reward(s) are not sufficiently large, it is determined whether the total rewards are within a predefined range of the reward redemption request (block 1225 ). In some cases, it may be determined that the available reward is within a particular threshold of meeting the reward redemption request. Thus, for example, it may be determined whether the available reward is within twenty percent of that required to satisfy the reward redemption request. Alternatively, a reward accrual velocity, or the rate at which the reward has been augmented over some period, can be calculated. This reward accrual velocity can be used to calculate a point in time where the reward will be sufficient to satisfy the reward redemption request. In this way, it can be determined whether, based on past and/or present performance, that the available reward will be sufficiently large within a set time period. Such a time limit can be, for example, one month. In yet other cases, a combination threshold and time limit test can be applied. Thus, for example, it can be determined whether a threshold required to meet the reward redemption request will be met in a given time period.
  • the reward redemption request is fulfilled and the reward(s) is/are deducted from the appropriate account(s) and/or account group (block 1220 ). Further, the deficit between the available reward(s) and the amount of the reward redemption request is recorded. This deficit is satisfied as the reward is augmented based on activity associated with the account(s) and/or account group.
  • the reward redemption request is stored and remains pending until it is either canceled, the required reward is achieved, or the available reward is augmented within the defined threshold and/or will increase to such levels within a defined time frame (block 1230 ).
  • the augmentation of the reward(s) is/are monitored to determine when the reward(s) is/are sufficiently large to allow fulfillment of the reward redemption request (block 12 ).
  • Such augmentation of the rewards can be based on use of an account and/or activity of person(s) associated with the account, or accounts within an account group.
  • a frequent flyer reward may be augmented based on travel of a person associated with an account or account group, and/or based on use of a financial account where frequent flyer miles accrue based on spending.
  • a reward redemption request can be received from a person owning an account associated with an account group, and requesting 35,000 frequent flyer miles to exchange for a plane ticket. It may be determined that the account owned by the person has only 25,000 frequent flyer miles available, and that the account is accruing frequent flyer miles at a rate of 3,000 per month.
  • a rule may exist that allows for redemptions to be fulfilled where eighty percent of the total required reward is available, and where the deficit reward will likely be repaid within three months.
  • the reward redemption request will be fulfilled in the following month where the balance will likely be 28,000 frequent flyer miles, or eighty percent of the required 35,000, and the accrual velocity indicates that the total reward will be available within the three succeeding months.
  • a flow chart 1300 illustrates another embodiment of the present invention for accruing and/or redeeming rewards.
  • a first account is provided (block 1305 ).
  • this can include setting up a financial record associated with the account, and where applicable, providing a presentation instrument for accessing the financial account.
  • this can include setting up various accounts for maintaining vacation days, sick days, insurance benefits, and the like.
  • this can include setting up a frequent travel account or other incentive account.
  • a reward and a party are associated with the first account (blocks 1310 , 1315 ). Activity of the first party is then monitored and the associated reward is augmented based upon the activity (block 1320 ). Such activity by the party can include any number of activities including, but not limited to, travel, purchases, use of a financial account, years of service to an employer, payment for insurance benefits, and the like. Where a reward redemption request is received from the party associated with the first account (block 1325 ), it is determined if a sufficient reward has accrued to satisfy the request, and the request is fulfilled by redeeming the reward (block 1335 ). Such a process includes exchanging the accrued reward, or portion thereof for merchandise, services, or other value obtainable thereby. Where neither a request to redeem (block 1325 ), nor a request to associate another party with the first account (block 1330 ) is received, monitoring activity associated with the first party continues as previously discussed (block 1320 ).
  • a request to associate another party with the first account is received (block 1330 )
  • another account is to be associated with the first account
  • the other account is grouped with the first account as previously discussed in relation to account grouping (block 1345 ).
  • any reward associated with the added account can be combined with that of the first account in a reward pool (block 1350 ).
  • the two rewards are combined and maintained in association with the first or second account, while in other cases, the rewards remain associated with the respective accounts and are chased when a reward redemption request is received.
  • the second party is also associated with the first account by, for example, adding the second party to the first account as a liable party (block 1355 ).
  • the second party can be added to a group that includes the first account, thereby making the reward associated with the first account accessible to the second party.
  • activity of both the first and second parties is monitored, and the reward augmented accordingly (block 1360 ).
  • a second account associated with the second party is grouped with the first account and the rewards are maintained in a reward pool, activity by either party will augment the reward pool.
  • a redemption request is received from the first party (block 1365 )
  • the redemption request is satisfied where a sufficient reward is available (block 1375 ).
  • the same process can be used to satisfy reward redemption requests from the second party (block 1370 ).
  • the reward used to fulfill the redemption request can be deducted from a reward pool associated with an account group, or the reward associated with the first account where a second account was not added and an account group does not exist.
  • some form of reward chasing can be implemented where the reward is satisfied first from an account owned by the requester, and secondarily from another account linked to the first account.
  • the reward redemption request is received from the first party and requires a reward of X
  • whatever portion of X is available from the first account is first accessed to satisfy the request, and then the remaining portion of X is accessed from the second account.
  • frequent flyer rewards are accrued.
  • an account is provided and associated with a frequent flyer reward that is augmented based at least in part on activity of a party.
  • a request is received to associate another party with the account, and this added party is associated with the account.
  • the frequent flyer reward accrues based at least in part on activity of the added party.
  • reward redemption requests from either party can be satisfied, and activity by either party augments the available frequent flyer reward.
  • frequent flyer rewards can be accrued to a commonly accessible account or account group where at least two accounts are provided that are each associated with frequent flyer rewards. Each account accrues a frequent flyer reward based on activity of the party or parties associated with the respective accounts. Reward redemption requests can then be satisfied from a combination of the rewards associated with the individual accounts.
  • a flow diagram 1400 illustrates yet another embodiment of the present invention for redeeming rewards.
  • a reward redemption request is received (block 1405 ).
  • the redemption request is parsed to identify the type of reward requested, and the amount of the reward requested (block 1410 ).
  • an account and/or account group that accrues the reward type is identified (block 1415 ). In some cases, this can include identifying an account within an account group to which the requestor is associated. In particular cases, this can include identifying an account owned by the requestor, while in yet other cases, this can involve identifying an account otherwise unrelated to the requestor.
  • a public settlement process can be implemented.
  • a reward accessed from an account can be converted to a common value, such as, a cash value (block 1435 ).
  • This value can be set by the account owner, or a market value may be used that represents a going rate for the reward type.
  • the common value of the reward is then transferred from an account associated with the requestor to the account from which the reward is being accessed (block 1440 ). With settlement for the reward exchange thus accomplished, the reward is redeemed, and the reward amount deducted from the identified and compensated account(s) (block 1450 ).
  • a public exchange could be provided and used in relation to account groups.
  • a hotel stay certificate requiring 10000 bonus points is requested, an account that accrues that type of bonus points is identified.
  • a person requesting the certificate is a member of an account group that includes the identified account.
  • the account group further includes dependent strategies regarding the redemption of rewards associated with the account group, and the members of the account group provide for private settlement of exchanges. Because of this, the hotel stay certificate is simply provided to the requester, and the 10,000 bonus points are deducted from the identified account.
  • the bonus points may be valued at one cent each. Based on this value, one hundred dollars is transferred from an account associated with the requestor to the identified account. Further, the requester is provided with the hotel stay certificate, and the 10,000 bonus points are deducted from the identified account.
  • a flow diagram 1500 illustrates another embodiment in accordance with the present invention for redeeming rewards.
  • augmentation of rewards associated with an account and/or account group is monitored (block 1510 ).
  • augmentation of a reward can be based on activities including, but not limited to, travel, purchases, use of a financial account, years of service to an employer, payment for insurance benefits, and the like.
  • the account information including the reward type and amount is provided to a fulfillment entity responsible for redeeming the reward (block 1530 ).
  • the fulfillment entity can be a party other than the party maintaining the accounts to which the various rewards are accruing.
  • the fulfillment entity can be a retailer supplying merchandise in exchange for the accrued reward(s).
  • the fulfillment entity can be a service provider, such as an airline, providing services in exchange for the accrued reward(s).
  • the account owner, or designated group owner is then directed to a fulfillment interface, or selection system (block 1540 ).
  • a fulfillment interface can include an Internet web page that includes a variety of selections offered by the fulfillment entity in exchange for the accrued bonus.
  • the web page may include a product catalog of a retailer with corresponding costs for items listed in terms of the reward type.
  • the fulfillment interface can be an IVR or other automatic interface system capable of providing an owner of a reward with exchange options.
  • a selection is received from the reward owner via the fulfillment interface (block 1550 ).
  • the cost of the selection in terms of the reward type is then computed, the corresponding amount of the reward deducted from the reward owner's account, and the redemption fulfilled by providing the selected merchandise, service, or other value to the reward owner (blocks 1555 , 1560 ).
  • group non-monetary transactions are also needed to support groups.
  • a non-monetary transaction is a transaction that affects information for one or more accounts within the group, but does not affect the monetary information for the account. For example, a change in billing address is a non-monetary transaction, whereas the application of a payment is a monetary transaction.
  • Other examples of non-monetary transactions include linking an account to an existing group, delinking one or more accounts from a group, changing the primary owner of a group, or changing the dependent strategy for a dependent account.
  • Group non-monetary transactions can be used in both batch and on line processing.
  • Group non-monetary transactions update multiple accounts within a group in response to a single input of the updated information.
  • To update the accounts in a group with updated group information the accounts within the group are identified.
  • the accounts are identified using the group master data.
  • the accounts in a group can be identified using the Group Member file. Once the financial records are identified, then the financial records are updated with the new information.
  • Group non-monetary transactions also support the selective updating of accounts within the group. For example, if only certain accounts within the group are to receive the updated information, then the accounts in the group are identified and one or more of the accounts is selected and the selected account(s) is updated with the new information. In an on-line environment, an operator can select the accounts that are to receive the updated information. In a batch environment, the updated information and the account numbers for the selected accounts can be submitted in batch.

Abstract

Among other things, the present invention provides systems and methods for fulfilling reward redemptions. In some cases, the systems and methods receive redemption requests associated with an account. The redemption request can be satisfied from a reward associated with the account, or by accessing a reward associated with another account. Redeeming a reward from another account can involve transferring value from one account to another, or grouping the related accounts and allowing members of the group to perform the settlement function. Various of the systems and method further provide for performing automatic reward redemptions, either by an entity maintaining the account to which the reward is associated, or through use of a fulfillment entity.

Description

    CROSS-REFERENCES TO RELATED APPLICATIONS
  • The present application is a continuation-in-part of multiple U.S. patent applications commonly assigned to First Data Corporation including: [0001]
  • (1) U.S. patent application Ser. No. ______ (Attorney Docket No. 020375-022020) entitled “Pooling Rewards Associated With Accounts”, and filed on Mar. 10, 2003, which is a continuation of U.S. patent application Ser. No. 09/298,417, entitled “Method for Processing a Group of Accounts Corresponding to Different Products”, and filed on Apr. 23, 1999. [0002]
  • (2) U.S. patent application Ser. No. 09/298505 entitled “Method for Linking Accounts Corresponding to Different Products Together to Create a Group”, and filed on Apr. 23, 1999. [0003]
  • (3) U.S. patent application Ser. No. 09/298521 entitled “Method for Defining a Relationship Between an Account and a Group”, and filed on Apr. 23, 1999. [0004]
  • (4) U.S. patent application Ser. No. 10/172378 entitled “System and Methods for Accessing and Modifying Usage Parameters Associated with a Financial Transaction Account”, and filed on Jun. 13, 2002, which is a continuation-in-part of of the following U.S. patent application Ser. No.: 09/298,417 filed Apr. 23, 1999, entitled “Methods for Processing a group of Accounts Corresponding to Different Products”; Ser. No. 09/298,505 filed Apr. 23, 1999, entitled “Method for Linking Accounts Corresponding to Different Products Together to Create a Group”; and Ser. No. 09/298,521 filed Apr. 23, 1999, entitled “Method for Defining a Relationship Between an Account an a Group”. [0005]
  • (5) U.S. patent application Ser. No. 10/237,572 entitled “Multiple Credit Line Presentation Instrument”, and filed on Sep. 9, 2002. [0006]
  • The application is further related to U.S. patent application Ser. No. ______ (Attorney Docket No. 020375-022040US), entitled “Chasing Rewards Associated With Accounts”, and filed on ______; U.S. patent application Ser. No. ______ (Attorney Docket No. 020375-022050US), entitled “Authorizing Transactions Associated With Accounts”, and filed on Dec. 12, 2002; and U.S. patent application Ser.No. ______ (Attorney Docket No. 020375-022060US), entitled “Systems and Method For Authorizing Transactions”, and filed on a date even herewith. All of the aforementioned patent applications are assigned to the assignee of the present invention, and the entirety of each of the aforementioned applications is incorporated herein by reference for all purposes.[0007]
  • BACKGROUND OF THE INVENTION
  • The present invention relates to rewards associated with accounts. More particularly, the present invention provides systems and methods for performing reward redemptions. [0008]
  • Rewards may be accrued in association with various accounts. For example, frequent flyer miles may be accrued in association with a credit card account, and based on activity in the credit card account. These frequent flyer miles may then be exchanged by the owner of the credit card account for travel. However, in general, the frequent flyer miles may not be exchanged by another individual unrelated to the credit card account. [0009]
  • As another example, such frequent flyer miles can be donated to a charitable organization, such as, the Make-a-Wish™ foundation. These miles can then be used by someone other than the owner of the credit card account. However, the frequent flyer miles can no longer be used by the account owner as they are no longer associated with the account, but rather convert to the charitable organization. [0010]
  • As yet another example, value exchangeable for merchandise can be accrued in relation to another credit card account. This can become problematic as this value remains a liability on the books of an issuer of the credit card account. Further, existing mechanisms for controlling or reducing this liability by forcing redemption of the value are cumbersome, and unfriendly to an account owner. In addition, the forced redemption often involves direct intervention by the entity maintaining the account. This increases the costs of account maintenance. [0011]
  • Thus, there exists a need in the art to address the various problems outlined above. As will be appreciated from the following disclosure, the systems and methods according to the present invention address these, and a number of other problems related to accruing and redeeming rewards. [0012]
  • BRIEF SUMMARY OF THE INVENTION
  • Among other things, the present invention provides systems and methods for fulfilling reward redemptions. As such, the present invention provides systems and methods for accruing and/or redeeming various rewards. [0013]
  • In some cases, the systems and methods include receiving redemption requests associated with an account. The redemption request can be satisfied from a reward associated with the account, by accessing a reward associated with another account, and/or by accessing a reward pool associated with a group of accounts. Redeeming a reward from another account can involve grouping the related accounts and allowing members of the group to perform the settlement function, or by transferring value between accounts and thereby providing a standard reward settlement mechanism. Various of the systems and methods further provide for performing automatic reward redemptions, either by an entity maintaining the account to which the reward is associated, or through use of a fulfillment entity. [0014]
  • Such reward redemptions can include redeeming rewards accrued in relation to account(s) based on activity of one or more parties associated with the account(s). These rewards can include point based rewards and/or cash based rewards. Such rewards can include, but are not limited to, frequent flyer miles, travel vouchers, travel certificates, travel tickets, reduced interest rates, value exchangeable at a particular retailer or group of retailers, cell phone minutes, mobile commerce value, sick days, vacation days, cash value rewards, and the like. Indeed, based on the disclosure provided herein, one of ordinary skill in the art will recognize a myriad of account types and reward types to which the present invention may be applied. For example, the accounts can be financial accounts, employee accounts, travel accounts, and/or other accounts associated with accruing rewards. Thus, as one example, the account can be a credit card account that accrues frequent flyer miles based on purchases applied to the credit card account. [0015]
  • One particular embodiment of the present invention provides methods for accruing frequent flyer rewards held in an airline account or under contract with an airline. The methods include providing an account associated with a frequent flyer reward that is augmented based at least in part on activity of a party. A request is received to associate another party with the account, and this added party is associated with the account. Upon association, the frequent flyer reward accrues based at least in part on activity of the added party. The methods further include receiving one or more requests to redeem the frequent flyer reward. In some instances, activity by either or both of the parties associated with the account can augment the frequent flyer reward. Such activity can include, for example, travel and/or use of a credit card. [0016]
  • Another embodiment of the present invention provides methods for acquiring frequent flyer rewards. The methods include providing at least two accounts that are each associated with frequent flyer rewards. Each account accrues a frequent flyer reward based on activity of the party or parties associated with the respective accounts. The methods further include associating the two accounts such that a combination of the frequent flyer rewards from the respective accounts is accessible by a party associated with one of the accounts. In some instances, the method includes aggregating the frequent flyer reward from one account with the frequent flyer reward from the other account in a reward pool. As such, the reward pool can be linked with either one of the accounts, or with an account group in which the accounts are associated. [0017]
  • In some instances, the methods further include reception of a reward redemption request from a party associated with one of the accounts. This redemption request can be satisfied using the reward associated with the account with which the party is associated. Alternatively, where the redemption request requires an amount greater than the reward associated with the account to which the party is associated, the redemption request can be satisfied using the reward pool, or an account in the account group other than that which the party is associated. [0018]
  • In yet other embodiments, methods for redeeming rewards are provided. Such methods include receiving a reward redemption request that indicates the type of reward to be redeemed. An account that accrues that type of reward is identified, and a reward of the indicated type is accessed to at least partially satisfy the reward redemption request. Thus, as just one of many examples, a reward redemption request for a plane ticket obtainable using frequent flyer miles is received. Based on this redemption request, one or more accounts that accrue such frequent flyer miles is accessed. A portion of the frequent flyer miles from these one or more accounts are deducted from these account and used to satisfy the redemption request. [0019]
  • Of note, the reward redemption request is not necessarily associated with any of the accounts from which the rewards are obtained. In particular cases, the redemption request is received in relation to an account associated with an account group, and the accounts from which the reward is deducted are also associated with the account group. In such cases, settlement of the reward transfer can be handled privately between members of the account group. In another instance, no settlement is provided, rather an open sharing system is implemented. Alternatively, in other cases, the account to which the redemption request is related is not related to the account(s) from which the reward is deducted. In such cases, a public settlement mechanism may be utilized to transfer value for the reward from one account to another. As just some examples, the accounts can be sick days accounts maintained with an employer or insurance company, vacation days accounts maintained with an employer, financial accounts associated with one or more financial products, and the like. [0020]
  • In a particular instance, the identified account is a first account, the reward associated with the first account is a first reward, and the reward redemption request is associated with a second account. In such cases, a reward associated with the second account can also be accessed to at least partially satisfy the reward redemption request where the second reward is associated with the second account. In another instance, the identified account is a first account and the reward redemption request is associated with a second account. As such, the methods can further include converting the reward associated with the first account to a common value, and transferring the common value from the second account to the first account. In some cases, a certain type of reward can be shared, while another type of reward is not shared. As just one example, all frequent flyer miles might be shared, while cash back bonuses are not shared. [0021]
  • In yet other cases, the identified account is a first account, the reward type is a first reward type, and the reward redemption request is associated with a second account that accrues a second reward type. In such cases, the methods can further include converting the reward of the first reward type to a common value, converting a reward of the second reward type to the common value, and transferring the common value from the second account to the first account. [0022]
  • In further embodiments, other methods for redeeming rewards are provided. Such methods include receiving a reward redemption request associated with an account that includes a reward amount. It is determined that the reward amount is greater than a reward associated with the account. The reward redemption request is then pended, or stored in a pending state until a later event allows for the reward redemption request to be satisfied. [0023]
  • In some cases, the reward redemption request remains pending until the reward associated with the account is augmented and becomes larger than that required to satisfy the redemption request. In other instances, the reward associated with the account is augmented and, while still less than that required by the redemption request, is within a predefined amount of the redemption request, thus allowing the redemption request to be satisfied on credit. [0024]
  • Alternatively, a reward accrual velocity, or the rate at which the reward has been augmented over some period, can be calculated. This reward accrual velocity can be used to calculate a point in time where the reward will be sufficient to satisfy the reward redemption request. Where the future date is within a predefined period, the reward redemption request can be satisfied on credit. Thus, for example, where a sufficient reward will be accrued within the next month, the redemption request can be satisfied immediately and the deficit portion of the reward deducted from the account over the succeeding month(s). [0025]
  • Thus, in some instances , the methods further include determining that the reward amount is less than the reward associated with the account, and satisfying the reward redemption request, while in other instances, the methods include determining that the reward amount is within a predefined amount of the reward associated with the account, and satisfying the reward redemption request. The predefined amount can be a reward amount, a time period, or the like. [0026]
  • In some cases, the reward associated with the account is augmented based at least in part on activity in the account. Further, in various instances, the account is a first account, the reward is a first reward, the first account and a second account are associated in an account group, a second reward associated with the second account is combined with the first reward in a reward pool, and determining that the reward amount is greater than the reward associated with the first account further includes determining that the reward amount is greater than a reward available from a reward pool. [0027]
  • Yet other reward redemption embodiments provide for receiving a reward redemption request that includes a reward amount. The methods further include identifying an account group to which the reward redemption request applies. The identified account group includes at least two accounts. It is determined that the reward amount is greater than an accrued reward accessible via the account group, and the reward redemption request is pended. In some cases, a pended redemption request causes a reduction in the amount of reward that can be allocated to a future redemption request. As one particular example, a request for ten-thousand miles may be pended. In such a case, a future request for thirty-thousand miles may be denied and not pended as the amount of reward that would remain pended would surpass a predefined threshold. [0028]
  • In yet other embodiments of the present invention, methods for redeeming rewards are provided that include monitoring activity associated with an account. A reward associated with the account is augmented based at least in part on the monitored activity. Once it is determined that the augmented reward has achieved a defined level, the reward is automatically redeemed. In some instances, these methods further include providing an indication to a party associated with the account that the defined reward level is achieved, directing the party to an Internet web page, and presenting a group of options for redeeming the reward. In other instances, a regular letter can be sent. Based on this, one of ordinary skill in the art will recognize locations other than the Internet, or in addition to the Internet, to which the party may be directed to complete a redemption. For example, the party may directed to an interactive voice response (IVR) system, or other automated redemption system. [0029]
  • The methods can further include receiving an indication of an option selected by the party, and providing the selected option to the party. Such options can include, but are not limited to, cell phone minutes, mobile commerce value, merchandise, reduced interest rates, cash back, and travel rewards. Thus, for example, where mobile commerce value is selected by the party, providing the option can include uploading mobile commerce value to mobile commerce device maintained by the party. The party can then use the mobile commerce value that was uploaded. The party can, for example, make purchases at a mobile commerce enabled vending machine, or the like. [0030]
  • Various instances include identifying an accrued reward, and the identified party associated with the account to a fulfillment entity. It is also indicated that the fulfillment entity provided compensation for the accrued reward to the party associated with the account, and the amount of the compensation is deducted from the accrued reward. In some cases, the fulfillment entity is a retailer, or group of retailers, providing merchandise in exchange for the accrued reward. In such cases, the retailer(s) can provide all of the reward processing thus limiting the burden on an issuer maintaining the account. To this end, the fulfillment entity may further, provide an indication to the party associated with the account that the defined reward level is achieved, direct the party to a fulfillment mechanism, and present a group of options for redeeming the reward. [0031]
  • This summary provides only a general outline of the embodiments according to the present invention. Many other objects, features and advantages of the present invention will become more fully apparent from the following detailed description, the appended claims and the accompanying drawings. [0032]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • A further understanding of the nature and advantages of the present invention may be realized by reference to the figures which are described in remaining portions of the specification. In the figures, like reference numerals are used throughout several to refer to similar components. In some instances, a sub-label consisting of a lower case letter is associated with a reference numeral to denote one of multiple similar components. When reference is made to a reference numeral without specification to an existing sub-label, it is intended to refer to all such multiple similar components. [0033]
  • FIG. 1 is a block diagram illustrating an exemplary relationship between a card processing and service provider, issuers and cardholders; [0034]
  • FIG. 2 is a block diagram illustrating an exemplary relationship between a card processing and service provider, an issuer and the cardholders within a group in accordance with an embodiment of the present invention; [0035]
  • FIG. 3 is a block diagram illustrating the relationship between a card processing and service provider, issuers and the cardholders within a group in accordance with an embodiment of the present invention; [0036]
  • FIG. 4A is a block diagram illustrating the files included in the group master data in accordance with an embodiment of the present invention; [0037]
  • FIG. 4B is a block diagram illustrating group master data in accordance with an embodiment of the present invention; [0038]
  • FIG. 5 is a flow diagram illustrating the steps for creating a group using new accounts in accordance with an embodiment of the present invention; [0039]
  • FIG. 6 is a flow diagram illustrating the steps for creating a group using existing accounts in accordance with an embodiment of the present invention; [0040]
  • FIG. 7A is a flow diagram illustrating the steps for adding a dependent account to a group in accordance with an embodiment of the present invention; [0041]
  • FIG. 7B is a flow diagram illustrating the steps for authorizing a transaction in accordance with an embodiment of the present invention; [0042]
  • FIGS. 8A and 8B are flow diagrams illustrating the steps for applying a payment in accordance with an embodiment of the present invention; [0043]
  • FIG. 9 is a flow diagram illustrating the steps for identifying intended recipients of statement data and providing statement data in accordance with an embodiment of the present invention; [0044]
  • FIG. 10 is a flow diagram illustrating the steps for redeeming group reward points in accordance with an embodiment of the present invention; [0045]
  • FIG. 11 illustrates a system in accordance with embodiments of the present invention for accruing and redeeming rewards; [0046]
  • FIG. 12 illustrates a flow diagram for receiving and pending reward redemption requests in accordance with embodiments of the present invention; [0047]
  • FIG. 13 illustrates a flow diagram for redeeming reward redemption requests according to various embodiments of the present invention, where parties associated with an account initiate the reward redemption requests; [0048]
  • FIG. 14 illustrates a flow diagram for redeeming reward redemption requests in accordance with embodiments of the present invention, where an account that accrues a particular type of reward is identified and the reward obtained therefrom; and [0049]
  • FIG. 15 illustrates a flow diagram for redeeming reward redemption requests in accordance with embodiments of the present invention, where redemption requests are automatically generated.[0050]
  • DETAILED DESCRIPTION OF THE INVENTION
  • Among other things, the present invention is directed to systems and methods for facilitating the redemption of rewards. In some cases, such rewards are associated with accounts including, but not limited to, financial accounts, incentive accounts, employee accounts, insurance accounts, and the like. Further, such rewards can include, but are not limited to frequent flyer miles, travel vouchers, travel certificates, travel tickets, reduced interest rates, value exchangeable at a particular retailer or group of retailers, cell phone minutes, mobile commerce value, sick days, vacation days, reduced interest rates, and the like. The present invention further addresses issues related to pending rewards, accesssing rewards from related and unrelated accounts and/or account groups, automatic reward fulfillment, public and private settlement of reward exchanges, and associating parties and/or accounts to facilitate reward accrual and/or redemption. [0051]
  • Yet further, aspects of the present invention are directed at systems and methods for for linking accounts corresponding to different products together to create a group so that group processing can be performed at the group level while independent processing of the accounts is performed at the account level. The accounts in a group can span multiple products. A typical group includes a key account and one or more dependent accounts. Each group has a primary owner. Generally the primary owner corresponds to a cardholder for the key account. [0052]
  • Some of the methods include forming account groups and utilizing various redemption, fulfillment, and/or chasing ideas in relation to the account groups. Such methods can include linking the accounts into a group by linking a financial record for each account to group master data for the group. The group master data includes information about the group and the group members, including group control settings, group aggregate data, and a group identifier. The financial records include information about the corresponding account, a relationship parameter specifying whether the corresponding account is a key account or a dependent account, and if the financial record corresponds to a dependent account, a dependent strategy identifier. [0053]
  • The relationship between a dependent account and the group is specified by a dependent strategy. A dependent strategy specifies group processing options for the dependent account. The relationship between a dependent account and the group can be changed by selecting a new dependent strategy. [0054]
  • The detailed description which follows is represented largely in terms of processes and symbolic representations of operations by a conventional computer. The processes and operations performed by the computer, in both a stand alone environment and a distributed computing environment, include the manipulation of signals by a processor and the maintenance of these signals within a data set, such as a database and a data structure. Each of these data sets and data structures are resident in one or more memory storage devices. Basically, a data set is a collection of related information in separate elements that are manipulated as a unit. A data structure is a structured organizational scheme that encapsulates data in order to support data interpretation and data operations. The data structure imposes a physical organization upon the collection of data stored within a memory storage device and represents specific electrical or magnetic elements. [0055]
  • For the purposes of this discussion, a method or process is generally conceived to be a sequence of computer executed steps leading to a desired result. These steps generally require physical manipulations of physical quantities. In addition, it should be understood that the methods and systems described herein are not related or limited to any particular computer (standalone or distributed) or apparatus. Furthermore, the methods and systems are not related or limited to any particular communication architecture. Thus, one skilled in the art will be able to implement the systems and methods of the present invention with general purpose machines or specially customized programmable devices according to the teachings described herein. [0056]
  • Referring now to the drawings, in which like numerals represent like elements throughout the several figures, aspects of the present invention and the preferred operating environment are described. [0057]
  • Card Processing and Service Provider, Issuers, and Cardholders [0058]
  • The processing of a credit card transaction typically involves the cardholder, a merchant, a merchant acquirer, the card issuer, and a card processing and service provider. FIG. 1 illustrates an exemplary relationship between a card processing and [0059] service provider 100, a number of issuers 102 a, 102 b . . . 102 c, and a number of cardholders 120. The card processing and service provider 100 supports the issuers by authorizing and processing monetary transactions, as well as providing support for creating new accounts, modifying accounts, generating cardholder statements, applying payments to accounts, controlling communications to cardholders and building reward programs. An issuer, such as, issuer 102 b, is typically a bank or other financial institution that issues one or more credit card products. The issuer manages transaction processing at the account level. An issuer typically manages a number of accounts using a hierarchy, such as the Product/System, Principal, and Agent hierarchy shown in FIG. 1. The cardholders 120 are typically individuals holding a credit card or charge card, such as a VISA™, MASTERCARD™, or private label card. In addition to the elements shown in FIG. 1, additional elements (not shown) may also be included. For example, additional issuers, Products/Systems, Principals, and Agents may exist.
  • An issuer can issue different types and versions of credit card products. For example, [0060] issuer 102 b could offer a VISA™ product and a MASTERCARD™ product. Each product could be offered in standard, gold and platinum versions. The Product/System blocks shown in FIG. 1 correspond to different products. If issuer 102 b issues a VISA™ product and a MASTERCARD™ product, then Product/System 104 a could correspond to the VISA™ product and Product/System 104 b could correspond to the MASTERCARD™ product. An issuer typically uses either a BIN (bank identification number) or an IIN (issuer identification number) to identify its different credit card products.
  • Issuers typically use additional levels of reporting structures below the Product/System level to manage large portfolios. FIG. 1 illustrates that below the Product/System level is the Principal level and below the Principal level is the Agent level. The divisions between the Principal level and the Agent level are typically defined by the issuer. Some issuers use the Principal level and the Agent level to make geographical divisions. For example, Principal block [0061] 106 a could correspond to a geographic region, such as the southeast, and Agent block 110 a could correspond to a state within that region. The cardholders 120 are located below the Agent level. As shown in FIG. 1, a number of cardholders can be associated with a single Agent. FIG. 1 illustrates an example of the hierarchical relationships that exist between an issuer and a cardholder. As will be apparent to those skilled in the art, alternative hierarchies are also possible.
  • An individual can hold a number of different cards corresponding to a number of different accounts. Although the same cardholder is associated with each of the accounts, each account is processed independently by the issuer. If several cardholders are in the same family, then each cardholder may hold several cards. In the case of a family, the cardholders may be related and the payments may be made from family funds, but each account is still processed independently. For example, Table 1 illustrates the credit cards held by a typical family including friends and co-workers. [0062]
    STANDARD STANDARD GOLD VACATION SICK INSURANCE
    Cardholder VISA ™ MC MC DAYS DAYS BENEFITS
    MOTHER Account 1 Account 2 Account 7 Account 9 Account 11
    FATHER Account 3 Account 12
    SON Account 5
    DAUGHTER Account 6
    GRANDFATHER Account 8
    FRIEND Account 13
    CO-WORKER Account 14 Account 10
  • Each of the accounts shown in Table 1 is an independent account from the perspective of the entity maintaining the account, whether it be an issuer, an insurance provider, an employer, or the like. Thus, for example, the standard MASTERCARD™ account associated with the daughter (Account 6) is independent of the standard MASTERCARD™ account associated with the grandfather (Account 8) and the gold MASTERCARD™ account associated with the mother (Account 2) is independent of the gold MASTERCARD™ account associated with the father (Account 3). As illustrated, various accounts can be grouped including, but not limited to, financial accounts associated with one or more financial products, insurance benefit accounts, employer benefit accounts, and the like. Based on the disclosure provided herein, one of ordinary skill in the art will recognize a myriad of other account types that can also be included in a group, or otherwise used in relationship with the inventions disclosed herein. For example, a reward account, such as a frequent flyer miles account associated with one or more travel providers could be used in relation to the present inventions. The processing options used by the issuer to process the accounts shown in Table 1 can differ by product. [0063]
  • The relationships between the different accounts shown in Table 1, the issuer, and the card processing and service provider are illustrated by FIG. 2. The card processing and [0064] service provider 200 supports the issuer 202. The issuer 202 issues a variety of credit card products, including a standard VISA™ product 204 a, a standard MASTERCARD™ product 204 b, a gold MASTERCARD™ product 204 c, and a private label product 204 d. Account 1 and Account 5 are shown under the standard VISA™ product 204 a, Account 6 and Account 8 are shown under the standard MASTERCARD™ product 204 b, Account 2 and Account 3 are shown under the gold MASTERCARD™ product 204 c, and Account 4 and Account 7 are shown under the private label product 204 d.
  • Groups and Group Relationships [0065]
  • In accordance with an embodiment of the present invention, the accounts shown in Table 1 and FIG. 2 can be linked together to create a group. A group can include a number of accounts that correspond to a single issuer. By linking accounts into a group, group processing can be performed on the accounts that are members of the group while maintaining independent processing of each of the accounts. Each group has a primary owner. Generally the primary owner corresponds to a cardholder for a key account. For example, the standard VISA™ account held by the mother could be designated as the key account for the group shown in Table 1 and FIG. 2. The remaining accounts in the group are referred to as dependent accounts. The relationship between a dependent account and the group is independent of the relationship between the remaining dependent accounts and the group. Typically, the issuer defines the possible relationships between a dependent account and the group. [0066]
  • FIG. 2 shows one possible organization for a group. Other organizations are also possible. As shown in FIG. 2, the accounts in a group can be associated with different products. There are no restrictions on the placement of the accounts in a group at the Product/System, Principal or Agent levels. The accounts in a group can be split between different Products/Systems, Principals and Agents. The key account and a dependent account can be associated with the same Agent. Multiple dependent accounts can also be associated with the same Agent. The accounts associated with an Agent are not required to be in the same group (or any group at all). [0067]
  • FIG. 3 shows an exemplary group where the key account and [0068] Dependent Account 1 are associated with the same Agent 308 a. Dependent Account 2 is associated with a different Agent 308 b, but is the same type of product 304 a as the key account and Dependent Account 1. Dependent Account 3 is associated with a different Principal 306 b than the key account, Dependent Account 1, and Dependent Account 2, but is the same type of product 304 a. Dependent Account 4 is associated with a different Agent 308 d than Dependent Account 3, but is associated with the same Principal 306 b. Dependent Account 5 is a different product 304 b than any of the other accounts in the group. Although FIG. 3 only shows a single group, additional groups or individual accounts can exist under the issuer 302 b. Furthermore, additional groups can exist under the other issuers 302 a, 302 c.
  • Linking the accounts into a group is accomplished by linking a financial record that corresponds to each account to group master data for the group. FIG. 4A illustrates the linking of the accounts shown in Table 1 into a group. The [0069] Group Master Data 400 includes information about the group, including group control settings, group aggregate data, and a group identifier. The Group Master Data 400 is discussed in more detail below in connection with FIG. 4B. The Key Financial Record 402 corresponds to the key or primary owner. The Key Financial Record 402 can also correspond to a key account held by the primary owner. In this example, the Key Financial Record 402 corresponds to the standard VISA™ account held by the mother. The relationship 420 between the Key Financial Record 402 and the Group Master Data 400 is a predefined relationship. Typically, the relationship is defined in part by the card processing and service provider and in part by the issuer.
  • In addition to the Key Financial Record, the group also includes [0070] Dependent Financial Records 404, 406, 408, 410, 412, 414, and 416 that correspond to the dependent accounts. Typically, a dependent account is associated with each dependent financial record. For example, Account 2 is associated with Dependent Financial Record 1 404. Each account is also associated with one or more cardholders, e.g. the mother is the cardholder associated with Account 2.
  • The dependent accounts in the group can cross product lines. In this example, [0071] Account 2 and Account 3 are MASTERCARD™ products, Account 4 and Account 7 are private label products, Account 5 is a VISA™ product, and Account 6 and Account 8 are MASTERCARD™ products. The relationship 422 between Dependent Financial Record 1 404 and the Group Master Data 400 is independent of the relationship between the remaining Dependent Financial Records and the Group Master Data.
  • The dependent accounts can also have different types of ownership. For example, the primary owner and a dependent cardholder can be jointly responsible for a dependent account, the primary owner can be responsible for a dependent account where a dependent cardholder is an authorized user, or a dependent cardholder can be solely responsible for a dependent account. In addition, a dependent cardholder can be jointly liable with the primary owner for the group liability. If a dependent cardholder is jointly liable with the primary owner for the group, then the dependent account is a jointly liable dependent account. [0072]
  • Group Master Data [0073]
  • The [0074] Group Master Data 400 is further illustrated in FIG. 4B. FIG. 4B illustrates a number of files 402-428. Each of the files includes records that contain information about the group and the accounts that are members of the group. The Group Data file 404 includes information about the group, such as a group identifier, a group cycle code, a group credit line, group available credit, and a group collector code. The group identifier identifies the group. Each of the records associated with the group includes the group identifier.
  • A group cycle code indicates the cycle code for the group. If the group includes a key account, then the cycle code for the key account typically is used as the group cycle code. If the group does not include a key account, then the group cycle code can be a default cycle code or can be based upon the cycle code of one of the dependent accounts in the group. The group credit line specifies the credit available for the accounts in the group that authorize against the group credit line. The group available credit specifies the current credit available for the accounts in the group that authorize against the group credit line. The group collector code may be set once a collector is assigned to one of the accounts in the group. A collector may be assigned because the account is delinquent. If another account in the group becomes delinquent, then the group collector code is checked and the same collector is assigned to that account if a group collection option is used. [0075]
  • The [0076] Primary Owner file 402 includes information about the primary owner of the group. The primary owner is the individual that is liable for the group. If more than one individual is liable for the group, then those individuals are jointly liable for the group and information about the individuals in stored in the Primary Owner file 402. For example, a primary owner and a dependent cardholder could be jointly liable for the group. For simplicity, the term “primary owner” is used herein to include a single primary owner or joint primary owners. Every group has a primary owner. If the group includes a key account, then the key cardholder is the primary owner.
  • The [0077] Group Member file 408 includes a record for each of the accounts that is (or was) a member of the group. Each record includes an account number, an indication as to whether the account is a key account or a dependent account, and group membership information. A record is maintained for an account in the Group Member file 408 even if the account is delinked from the group. Each record includes group membership information which indicates when the account was linked to the group and if the account is no longer a member of the group, when the account was delinked from the group. The Address file 406 includes a record for each of the accounts that is (or was) a member of the group. Each record includes the mailing address of the cardholder associated with the account.
  • The Member Relationship file [0078] 410 includes a record for each of the accounts that is (or was) a member of the group. A member relationship record contains information about the strategy associated with an account. If the strategy associated with the account has changed, then the member relationship record contains information about the previous strategy or strategies, as well as the current strategy. The member relationship record also contains information about the effective dates of each strategy.
  • The [0079] Strategy Definition file 412 includes a record for each of the defined strategies. The strategy definition records include the parameters and the parameter values that define the strategies referred to in the member relationship records. If the definition of a strategy has changed, then the strategy definition record for that strategy also includes the parameter and the parameter values that defined the previous version or versions of the strategy, as well as the effective dates of each strategy definition.
  • The Member Statement file [0080] 411 includes records for each account that is (or was) a member of the group. Each record includes a number of fields that store statement data (monetary information) for the associated account. In addition, each record includes a flag that indicates whether the associated account cycles with the group (i.e. has the same cycle code as the group) or cycles independently. The information stored in the Member Statement file 411 is used to generate the group statement, dependent cardholder statement, and/or a courtesy statement.
  • The Group Statement file [0081] 418 includes records that contain group monetary and group non monetary information. The group monetary information includes the group balances, as well as the group credit line and group available credit for a particular statement. The group non monetary information includes the group payment due date. Typically, the group payment due date is the earliest due date of all the accounts of the group that are paid by the primary owner. The information stored in the Group Statement file 418 is used to generate the group statement.
  • The information in the Member Statement file [0082] 411 and the Group Statement file 418 is used to determine the initial break up of a group payment. The information is also used to support the on line display of statement information to an operator.
  • The Group Rewards file [0083] 414 includes a record for each of the reward programs for the group. Each record includes information about the reward program, such as a reward program identifier and the amount of group points accumulated in that reward program.
  • The Custom [0084] Calculation Definition file 416 and the Custom Calculation Values file 420 support customized group calculations that appear in a field on the group statement. Each custom calculation definition record includes a formula for a customized group calculation. Typically, a formula specifies that a customized group calculation is calculated using monetary elements from the accounts in the group. The value that is calculated using the formula is stored in a custom calculation values record.
  • The [0085] Group Payment file 422 includes a record for each group payment received. Each record includes the amount of the group payment and the date the group payment was received. The Payment Allocations file 426 includes a record for each group payment received. Each record indicates how the group payment was allocated among the accounts in the group. The Group Reversal file 424 includes a record for each group payment that has been reversed. If a group payment is reversed, then the reversal is made by referencing the Payment Allocation file 426 to determine how the payment was originally allocated.
  • The Rejects file [0086] 428 includes records of rejections detected during processing other than group processing. A record in the Rejects file 428 includes a rejection report that provides details of the rejection. As will be apparent to those skilled in the art, the files shown in FIG. 4B are exemplary group master data files. The group master data could be stored using alternative types of files and records.
  • Dependent Strategies [0087]
  • Typically, the relationship shown in FIG. 4A between the [0088] Dependent Financial Records 422, 424, 426, 428, 430, 432, 434 and the Group Master Data 400 is defined by a set of parameters. The parameters are typically provided by the card processing and service provider. A set of parameters and parameter values can be selected to create a customized dependent strategy. Either the card processing and service provider or the issuer can select the parameters and the parameter values to create a dependent strategy. Preferably, the card processing and service provider provides parameters and the issuer selects a set of parameter values that is suitable for a particular situation. Alternatively, the card processing and service provider could provide strategies rather than parameters to define the strategies. If the card processing and service provider provides strategies, then each of the issuers supported by the card processing and service provider chooses among the same group of strategies. However, if the card processing and service provider provides parameters, then each issuer can customize the strategies offered to its customers. In some embodiments the dependent strategies are labeled. For example, a dependent strategy for a college-age child residing at school may have one label, whereas a dependent strategy for a second account for the primary owner may have another label.
  • A dependent strategy specifies the relationship between a dependent account and the group by specifying group processing options for the account. The group processing options provide flexibility in the relationships between the dependent accounts and the group and provide for automatic processing at the group level. Typically, the dependent strategy includes parameters that define how transactions are authorized for the dependent account, as well as whether payment for the account is due from the primary owner or from the dependent account cardholder. In addition the dependent strategy includes options for payment application, statement generation, cardholder communications, and reward pooling. [0089]
  • The parameter values could be selected to create a dependent strategy appropriate for a dependent, college age child that resides at school. The parameter values could be selected so that the child is liable for the account and the parent receives information about the activity of the account. Alternatively, the parameter values could be selected so that the parent and the child are jointly liable for the account and that both the parent and the child receive information about the activity of the account at their respective residences. Another strategy could be created for a high school age child living at home. The parameter values could be selected so that the primary owner, typically the parent, is financially liable for the account and the account has a predetermined limit. The primary owner could set the limit on the account. [0090]
  • The parameter values could also be selected to create a strategy for a dependent account held by the primary owner. The primary owner could use the key account and the dependent account to segregate expenses. The parameter values could be selected so that the primary owner is liable for the account and detailed information about the account is included on the group statement. As will be apparent to those skilled in the art, additional strategies can also be created to address the needs of other situations. [0091]
  • Creating a Group [0092]
  • There are a number of ways that a group can be created. One way to create a group is to create a group using new accounts. Another way to create a group is to link a number of existing accounts together. Typically, a group is created by an issuer. The group can be created using either on line or batch processing. Once the first account is identified as being a member of the group, the group master data is automatically generated. Once a group is created, additional accounts can be added to the group or existing accounts can be removed from the group. [0093]
  • Business rules are used to insure that the relationships between the accounts in the group are valid. The business rules define the types of accounts that can be linked together in a group. Typically, the business rules are promulgated by the card processing and service provider. The business rules are checked whenever group relationships are impacted. For example, the business rules are checked when a group is created or an account is added to or removed from a group. Shown below is a list of typical business rules. As will be apparent to those skilled in the art, the number and types of business rules may vary from that shown below. [0094]
  • (1) A group must have one and only one primary owner. [0095]
  • (2) A group will not exist without at least one account linked to it or a historical relationship to an account. [0096]
  • (3) Dependent accounts must have dependent strategies. [0097]
  • (4) All accounts that statement together must have the same cycle code and method. [0098]
  • (5) All accounts in the group must have the same issuer number. [0099]
  • (6) Accounts within a group cannot be dual. A dual account is an account that corresponds to two different credit card products. For example, a dual account could correspond to a VISA™ product and a MASTERCARD™ product. [0100]
  • (7) Accounts within a group cannot be included in a Combine Account Transfer. A Combine Account Transfer is a process that merges two accounts into a single joint account. [0101]
  • (8) Accounts in the group cannot have a commercial card relationship. [0102]
  • (9) The key account cannot have a status of bankrupt, closed or charge off without impacting the dependent accounts. [0103]
  • Creating a Group Using New Accounts [0104]
  • An exemplary method for creating a group using new accounts is shown in FIG. 5. In [0105] step 500, a new account is opened. The new account is designated as the key account in step 502 by setting a relationship parameter for the account to “key.” The relationship parameter defines the relationship between the account and the group. When the key account is opened, a number of account parameters and group parameters are automatically set. For example, parameters defining the cycle code and method and the currency code are typically defined at the time the account is opened. In step 504, the parameters set in step 500 are compared to the set of business rules. If the parameters set in step 500 satisfy the business rules, then the business rules are validated.
  • If the determination in [0106] step 504 is that the business rules are validated, then the “Yes” branch is followed to step 508. In step 508, the group build is initiated and the key financial record and the group master data are created. Typically, the key financial record includes the account parameters for the key account plus the relationship parameter and a group identifier. The group master data includes a group identifier and certain group parameters. If the determination in step 504 is that the business rules are not validated, then the “No” branch is followed to step 520 and an error occurs.
  • Although FIG. 5 illustrates that a key account is created in [0107] steps 500 and 502, a group can be created without a key account. If a key account is created, then the key account cardholder is the primary owner. However, if a group is created without a key account, a primary owner is required. A key financial record is created regardless of whether the group includes a key account.
  • The remaining steps in FIG. 5 illustrate adding dependent accounts to the group. In [0108] step 510, a determination is made as to whether a dependent account is to be added to the group. If a dependent account is to be added to the group, then the “Yes” branch is followed to step 512 and a new account is opened. The new account is designated as a dependent account by setting the relationship parameter for the account to dependent. From step 512, the method proceeds to step 514 where a dependent strategy is selected. Typically, an issuer provides a number of dependent strategies that can be used for dependent accounts within a group. Once a dependent strategy is selected, then a determination is made in step 516 as to whether the parameters selected in opening the dependent account and the dependent strategy satisfy the business rules. If the business rules are satisfied, then the business rules are validated in step 516 and the method proceeds to step 518. In step 518, the dependent financial record is created and the group master data is updated. Typically, the dependent financial record includes account parameters for the dependent account, as well as the relationship parameter, a group identifier, and a dependent strategy identifier. Updating the group master data includes creating the link between the dependent financial record for the dependent account and the group master data.
  • From [0109] step 518 the method returns to step 510 and a determination is made as to whether another dependent account is to be added. If another dependent account is to be added, then steps 512, 514, 516, and 518 are repeated. Once all the dependent accounts have been added, then the method proceeds from step 510 via the “No” branch to step 506 and the method ends.
  • FIG. 5 illustrates that business rules are validated after the key account or a dependent account is opened. Alternatively, if the accounts are opened in an on line environment, then the business rules can be validated as the accounts are opened. For example, an operator can be prevented from creating an invalid relationship, such as creating two key accounts. FIG. 5 also illustrates that the group master data is updated after the addition of each dependent account. However, the group master data can be updated at other times. For example, information for opening a key account and dependent accounts may be collected by the issuer and then submitted by the issuer to the card processing and service provider in batch. If the information is submitted in batch, then the group master data may be updated once with information for all of the accounts in the group. [0110]
  • Creating a Group Using Existing Accounts [0111]
  • FIG. 6 illustrates the steps for creating a group using existing accounts. In [0112] step 600, an existing account is selected as the key account by setting the relationship parameter for the account to key. If the account was not previously a member of a group, then the relationship parameter was blank. Once an existing account is selected as the key account, then in step 602 a determination is made as to whether the business rules are validated. The business rules are validated if the parameters for the key account satisfy the business rules.
  • If the business rules are validated, then the method follows the “Yes” branch to step [0113] 604. In step 604, the group build is initiated. Initiating the group build includes creating the group master data, and linking the key account to the group by linking the key financial record to the group master data.
  • Once the initial group build is complete, then a determination is made in [0114] step 606 as to whether a dependent account is to be added to the group. If a dependent account is to be added to the group, then the “Yes” branch is followed to step 608. In step 608, an account is selected as a dependent account. Once an account is selected as a dependent account, the relationship parameter for the selected account is set to dependent. In step 610, a dependent strategy is selected for the dependent account. From step 610 the method returns to step 606 and a determination is made as to whether another dependent account is to be added to the group.
  • Once all the dependent accounts have been added to the group, then the “No” branch is followed from [0115] step 606 to step 612. In step 612, a determination is made as to whether the business rules are validated. The business rules are validated in step 612, if the dependent accounts satisfy the business rules. If the business rules are validated in step 612, then the “Yes” branch is followed to step 614. In step 614, the group master data is updated with information for the dependent accounts. In addition, the dependent financial records for the dependent accounts are linked to the group master data. However, if the business rules are not validated in step 612, then the “No” branch is followed to step 616 and an error occurs.
  • Although FIG. 6 illustrates that the group master data is updated after all the dependent accounts have been selected, those skilled in the art will appreciate that the group master data could be updated at other points in the process. For example, if the group is being created using on line processing, then validating the business rules and updating the group master data could occur after [0116] step 610 for each dependent account added.
  • Changing Group Relationships [0117]
  • The relationships between the accounts of the group are flexible and can be modified. The relationship between a dependent account and the group can be changed by selecting a new dependent strategy. The ability to modify, the dependent strategy allows the account to change as the cardholder's situation changes. For example, if the initial dependent strategy was a strategy suitable for a high school age child living at home, then the dependent strategy could be modified to a strategy suitable for a college age child living at school once the child enters college and moves away from home. Changing the dependent strategy of one of the dependent accounts does not impact the dependent strategies of the other dependent accounts. [0118]
  • In addition, a dependent account can be added to the group or deleted from the group without affecting the remaining accounts in the group. The ability to add dependent accounts and delete dependent accounts allows the group to change to accommodate changes in the relationships between the primary owner and the dependent cardholders. To add a dependent account to a group, the dependent financial record for the dependent account is linked to the group master data. Adding a dependent account to a group may correspond to the primary owner or a dependent cardholder obtaining another card or may correspond to adding another dependent cardholder to the group. For example, a group could be established for a family that includes a mother, father and daughter. When the group is created, the group could include financial records corresponding to accounts held by the mother and father. Subsequently, a dependent financial record could be added for an account for the daughter. [0119]
  • To remove a dependent account from a group, the dependent financial record for the dependent account is delinked from the group master data. Removing a dependent account from a group may correspond to a change in family status. For example, a group could be established for a married couple with the husband as the primary owner and the wife as a dependent cardholder. If the couple divorces, then the group could be modified to delete the dependent financial records that correspond to accounts held by the wife. As will be apparent to those skilled in the art, a dependent account can also be removed from a group for reasons other than a change in family status. [0120]
  • A single account can be removed from a group or a number of accounts can be removed from a group. If an account is removed from a group, it can be moved to an existing group, used to create a new group, or can be designated as an independent account that is not a member of any group. If a dependent account is moved to an existing group, then the group identifier in the dependent financial record is changed to correspond to the group identifier for the existing group. If a dependent account is removed from one group and is used to create another group, then the dependent account can remain a dependent account or can be “matured” into a key account. To mature a dependent account into a key account, the relationship parameter for the dependent account is changed from dependent to key. If a dependent account is matured into a key account, the history for the dependent account that was accrued during the period that the dependent account was a member of the group follows the dependent account to the new group. If the dependent account is designated as an independent account, then the relationship parameter is set to blank. [0121]
  • If all the accounts in a group are removed from the group, then the group continues to exist for some pre defined period of time even though the group does not have any members. The group continues to exist so that audit history for the group can be maintained for the predefined period of time. [0122]
  • The primary owner of the group can be changed. The primary owner can be changed to a cardholder that corresponds to one of the dependent accounts or to a new primary owner. To change the primary owner to a dependent cardholder, the relationship parameter for the dependent account is changed from dependent to key. The original key account can be converted to a dependent account by changing the relationship parameter from key to dependent. Alternatively, the original key account can be removed from the group and transferred to another group (as either a key or dependent account) or established as an individual account in a manner similar to that described in the preceding paragraph. [0123]
  • A group history is maintained in the group master data. For example, as discussed above in connection with FIG. 4B, information on all the accounts that are or ever were members of the group are stored in the Group Member file. The history of any changes in the dependent strategy for a dependent account are maintained in the Member Relationship file and the history of any changes in the definition of a strategy is maintained in the Strategy Definition file. In addition to group history, account history is also maintained with each account. The account history follows the account notwithstanding changes in the account's membership in a group. For example, payment history for a dependent account follows the dependent account even if the dependent account is delinked from the group and is established as an individual account. [0124]
  • Adding a Dependent Account to a Group [0125]
  • Once a group is created, additional dependent accounts can be added to the group. The additional dependent accounts can be newly created accounts or can be existing accounts. FIG. 7A illustrates the steps for adding a dependent account to an existing group. In [0126] step 700, a group is identified. Typically a group is identified using the group identifier. In step 702, a determination is made as to whether an existing account is to be added or whether a new account is to be added. If a new account is to be added, then the “Yes” branch is followed to step 704. In step 704, a new account is opened and the relations hip parameter for the account is set to dependent. A dependent strategy for the new account is selected in step 706. In step 708, a determination is made as to whether the dependent account opened in step 704 satisfies the business rules. If the dependent account satisfies the business rules, then the business rules are validated and the “Yes” branch is followed to step 710. In step 710, the group master data is updated. If the business rules are not validated in step 708, then the “No” branch is followed to step 722 and an error occurs.
  • If the determination in [0127] step 702 is that an existing account is to be added, then the “No” branch is followed to step 712. In step 712, an existing account is selected and the relationship parameter for the account is set to dependent. A dependent strategy for the account is selected in step 714. The parameters for the dependent account created in step 712 are compared to the business rules in step 718. If the parameters for the dependent account satisfy the business rules, then the business rules are validated and the “Yes” branch is followed to step 720. In step 720, the group master data is updated. However, if the business rules are not validated then the “No” branch is followed to step 722 and an error occurs.
  • Although FIG. 7A indicates that the group master data is updated after each dependent account is added to the group, the group master data can be updated at other points in the process. For example, if multiple accounts are to be added to an existing group, then the steps shown in FIG. 7A would be repeated for each account. Rather than updating the group master data after the addition of each dependent account, the group master data could be updated after the addition of all the dependent accounts. Updating the group master data after the addition of each account can be used to support on line processing, whereas updating the group master data after the addition of a number of dependent accounts can be used to support batch processing. [0128]
  • Group Processing [0129]
  • Once a group is created it can be used to perform group processing. Group processing typically includes authorizing transactions, applying group payments, creating group statements, controlling cardholder communications, and administering reward programs for the accounts in the group. Information from both the key account and the dependent accounts are used for group processing. Each dependent account has an associated dependent strategy that specifies group processing options for the dependent account. Although the accounts of a group are subject to group processing for some functions, the accounts are treated as individual accounts for other functions. [0130]
  • Authorizing a Transaction [0131]
  • The dependent strategy for a dependent account specifies the authorization option for the dependent account. The authorization option specifies the information that is used to authorize a transaction. In one embodiment of the invention, three authorization options are available for a dependent account. One authorization option considers only the credit line and available credit of the group, a second option considers only the credit line and available credit of the dependent account, and a third option considers the credit line and the available credit of both the group and the dependent account. [0132]
  • Depending upon the authorization option selected, the authorization processing uses the group credit line and the group available credit and/or the dependent credit line and the dependent available credit. The group credit line is a group parameter that typically is set when the group is created. The dependent credit line is a dependent account parameter that is set when the dependent account is opened. The group credit line and the dependent credit line can be modified. The group available credit is calculated real time using activity from the key account (if any) and any dependent accounts that share the group credit line. A dependent account shares the group credit line if payment for the dependent account is due from the primary owner. Generally, the group available credit is calculated by subtracting the current balances and any outstanding authorizations of the key account and the dependent accounts that share the group credit line from the group credit line. Similarly, the dependent available credit is calculated by subtracting the current balance and any outstanding authorizations of the dependent account from the dependent credit line. [0133]
  • FIG. 7B illustrates exemplary steps for authorizing a transaction. In [0134] step 740, an authorization request is received. The authorization request includes a transaction amount and an account identifier, such as an account number. In step 742, a determination is made as to whether the account identifier corresponds to an account that is a member of a group. If the requesting account is not a member of a group, then the “No” branch is followed to step 752. In step 752, normal authorization processing occurs using the credit line and the available credit for the account.
  • Normal authorization processing typically includes several calculations that use the credit line and the available credit. For example, authorization may include comparing the amount of the transaction to the available credit, comparing the amount of the transaction to a percentage expansion of the credit line, as well as comparing the transaction to past transactions for the account. Comparing the transaction to past transactions for the account may be used to detect possible fraudulent uses of a card and may result in the issuance of a referral code. As will be apparent to those skilled in the art, additional calculations can also be performed. [0135]
  • If the determination in [0136] step 742 is that the requesting account is a member of a group, then the “Yes” branch is followed to step 744. In step 744, a determination is made as to whether the requesting account is a key account or a dependent account. If the requesting account is a key account, then the “Yes” branch is followed to step 748. In step 748, normal authorization processing occurs using the group credit line and the group available credit.
  • If the determination in [0137] step 744 is that the requesting account is a dependent account, then the “No” branch is followed to step 746. In step 746, the dependent strategy is checked to determine the authorization option that corresponds to the dependent account. FIG. 7B illustrates three possible authorization options, A, B and C. Option A specifies that the credit line and the available credit for the group are used for authorization processing. Option B specifies that the credit line and the available credit for both the group and the dependent account are used for authorization processing. Option C specifies that the credit line and the available credit for the dependent account are used for authorization processing.
  • If the dependent strategy specifies option A, then the method proceeds from [0138] step 746 to step 748 and the credit line and the available credit for the group are used for normal authorization processing. If the dependent strategy specifies option C, then the method proceeds from step 746 to step 752 and the credit line and the available credit for the dependent account are used for normal authorization processing. The difference between the authorization processing performed in step 748 and the authorization processing performed in step 752 is that step 748 uses group information, whereas step 752 uses dependent account information.
  • If the dependent strategy specifies option B, then the method proceeds from [0139] step 746 to step 750 and the credit line and the available credit for both the group and the dependent account are used for authorization processing. In step 750, the credit line and the available credit for the dependent account are used in normal authorization processing. The authorization processing performed in step 750 is similar to that performed in step 752. However, additional processing is required for option B. In step 754, a determination is made as to whether the processing performed in step 750 indicates that the authorization request is authorized. If the processing performed using the dependent account information indicates that the request is authorized, then the “Yes” branch is followed to step 758. In step 758, a determination is made as to whether the transaction amount specified in the authorization request exceeds the group available credit. If the amount does not exceed the group available credit, then the “Yes” branch is followed to step 760 and the authorization request is approved. If the processing performed in step 754 indicates that the authorization request is denied or if the comparison performed in step 758 indicates that the amount of the request exceeds the group available credit, then the “No” branch is followed to step 756 and the authorization request is declined.
  • Applying a Payment [0140]
  • The dependent strategy for a dependent account specifies whether payment of the dependent account balance is due from the primary owner or is due from the dependent cardholder. If payment of the dependent account is due from the dependent cardholder, then the entire amount of a payment received from the dependent cardholder is credited to the dependent account. However, if the dependent account is paid by the primary owner, then the amount of the group payment that is credited to the dependent account depends upon the amount of the group payment, as well as the control settings for the group. Payment of the key account is due from the group payment. [0141]
  • The allocation of a group payment is partially determined by the amount of the payment and partially determined by the group payment options. The group payment options are typically set by the issuer. The group payment options could be part of the group control settings in the group master data. Alternatively, the group payment options could be stored in a separate file, such as a Product Control File, and associated with the group through the key account or through another means. [0142]
  • Only accounts included in the group balances during the processing of the last group statement are included in the automatic allocation of a group payment. The group balances for the last group statement can be determined from the Group Statement files in the group master data. The account balances for accounts in the group can be determined from the Member Statement files in the group master data. [0143]
  • Typically, the amount of the group payment is compared to one or more of the group balances. The group balances include the Last Statement Balance (LSB) and the Minimum Payment Due (MPD) for the group. The group balances may also include the group delinquency amount. The group LSB is determined by adding the LSB of the key account (if any) to the LSB of all dependent accounts in the group that are paid by the primary owner. If payment for a dependent account is due from the dependent cardholder, then the LSB of that dependent account is not included in the group LSB. The group MPD is calculated by adding the MPD for the key account (if any) to the MPD for each of the dependent accounts that are paid by the primary owner. The group delinquency amount is determined by adding the account delinquency of the key account (if any) to the account delinquency of the dependent accounts that are paid by the primary owner. [0144]
  • FIGS. 8A and 8B illustrate an exemplary method for applying a group payment. In [0145] step 800, the group payment is received. A determination is made in step 802 as to whether the payment is less than the group LSB. If the group payment is greater than or equal to the group LSB, then the “No” branch is followed to step 804. In step 804, the payment is applied to the dependent accounts in an amount equal to the LSB for each account. The remainder of the group payment is applied to the key account in step 806. If the payment is equal to the group LSB, then the amount applied to the key account is step 806 is equal to the LSB of the key account. However, if the group payment is greater than the group LSB, then the amount applied to the key account in step 806 is greater than the LSB of the key account. Although FIG. 8A illustrates that any overpayment is credited to the key account, an overpayment could be shared between the accounts of the group. Whether an overpayment is credited to the key account or shared between the accounts is typically determined by the group payment options.
  • If the determination in [0146] step 802 is that the group payment is less than the group LSB, then the “Yes” branch is followed to step 808. In step 808, a determination is made as to whether the group payment is less than the group MPD. If the group payment is less than the group MPD, then the “Yes” branch is followed to step 810. In step 810, the group payment options are determined. In step 812, a determination is made as to whether the group payment options indicate that account delinquency is considered in applying a group payment. If account delinquency is not considered, then the “No” branch is followed to step 814. In step 814, MPD ratios are calculated for the key account and the dependent accounts that are paid by the primary owner. An MPD ratio is calculated for an account by comparing the MPD for the account with the group MPD. Once the MPD ratios for the key account and the dependent accounts that are paid by the primary owner are calculated in step 814, then in step 816 the payment is applied to the key account and the dependent accounts in the group in accordance with the MPD ratios calculated in step 814.
  • If the determination in [0147] step 812 is that account delinquency is considered in applying the group payment, then the “Yes” branch is followed to step 820. In step 820, the group payment is applied to the key account and the dependent accounts paid by the primary owner to satisfy the delinquent amount for each account. In step 822, a determination is made as to whether there is any amount of the payment remaining. If there is an amount of the payment remaining, then the “Yes” branch is followed to step 814 and the remaining payment is allocated based upon the MPD ratios for the key account and the dependent accounts paid by the primary owner. If the determination in step 822 is that there is no remaining balance, then the method ends.
  • If the determination in [0148] step 808 is that the group payment is greater than or equal to the group MPD, then the “No” branch is followed to step 830 of FIG. 8B. In step 830, the group payment is allocated between the key account and the dependent accounts that are paid by the primary owner to satisfy the MPD for each account. A determination is made as to whether there is any amount of the group payment remaining in step 832. If there is an amount of the group payment remaining, then the method proceeds to step 834. In step 834, a remaining balance ratio is calculated for each of the accounts. A remaining balance ratio is calculated by comparing the remaining balance for an account to the remaining balance for the group. The remaining balance for an account is calculated by subtracting the MPD from the LSB for the account. The remaining balance for the group is calculated by subtracting the group MPD from the group balance. Once the remaining balance ratios are calculated in step 834, then the remainder of the payment is applied in accordance with the remaining balance ratios in step 836. If the determination in step 832 is that there is no remaining balance, then the method ends.
  • As will be apparent to those skilled in the art, other payment ratios could be considered when allocating a group payment among the accounts in the group other than those shown in FIGS. 8A and 8B. For example, as an alternative to [0149] steps 814 and 816, the group payment could be allocated based upon a LSB ratio rather than an MPD ratio or based upon an account hierarchy. An LSB ratio for an account can be calculated by comparing the LSB for the account to the LSB for the group. An account hierarchy specifies the order in which the accounts of a group are to be paid. Similarly, MPD ratios could be used as an alternative to the remaining balance ratios illustrated in FIG. 8B. Moreover, other account conditions could be considered in allocating a group payment. For example, in addition to or as an alternative to considering delinquent amounts, disputed amounts could be considered.
  • The exemplary method for payment application illustrated by FIGS. 8A and 8B is based upon the amount of the group payment, the dependent strategies and the group payment options. Preferably, the steps illustrated in FIGS. 8A and 8B can be overridden. For example, an operator could manually allocate a group payment between the key account and the dependent accounts in accordance with specific allocation instructions. The allocation instructions could be generated by the primary owner of the group or the issuer. If the group payment is an electronic payment, then instructions submitted with the electronic payment could determine how the payment is allocated. The allocation instructions could be for a single payment or could be standing instructions that apply to all payments received. If the allocation instructions are standing instructions, then the instructions could be stored in the group master data. [0150]
  • There are times when the application of a group payment needs to be reversed. For example, reversal of a payment is necessary if a check for the payment is returned for insufficient funds. If a check for a group payment is returned for insufficient funds, then the payment allocations to the accounts in the group are reversed. To reverse the payment allocations, the original payment allocation must be recreated. For example, if a group payment of $100 was allocated $50 to the key account, $25 to one dependent account and $25 to another dependent account, then reversal of the group payment is made by reversing the $50 payment allocation to the key account, the $25 payment allocation to the first dependent account and the $25 payment to the second dependent account. To reverse a payment, the Payment Allocation file is used to determine how the payment was originally allocated. [0151]
  • Generating Group Statements and Courted Statements [0152]
  • A group statement is created for the group and is sent to the primary owner. The group statement includes information about the activity of the key account (if any) and the activity of some or all of the dependent accounts of the group. The amount of information that appears on the group statement about a dependent account is controlled by the dependent strategy. Depending upon the dependent strategy, the group statement can include details of the activity of the dependent account or a summary of the activity of the dependent account. [0153]
  • Statement data is calculated for each account in the group. Statement data typically includes the MPD, LSB, reward information, finance charges, and late fees for the account. The statement data is calculated on an account by account basis. The statement data is used to create the group statement, a dependent statement, and/or a courtesy statement. The statement data is also used to calculate group data. [0154]
  • Group data includes the group MPD, group LSB, group reward information, group available credit, group finance charges and group late fees. The group data is calculated from the key account and any dependent accounts that are paid by the primary owner. The group statement also includes information about the previous group payment, including the amount, the posting date, etc. The group statement also includes information about the group, such as the primary owner, a listing of the accounts in the group, including the account numbers, and the dependent strategy for each dependent account in the group. [0155]
  • A dependent strategy specifies whether payment for the dependent account is due from the primary owner or from a dependent cardholder associated with the dependent account. The dependent strategy can also specify that a courtesy statement is generated. A courtesy statement is a statement that provides statement data to the cardholder, but does not require payment from the cardholder. [0156]
  • FIG. 9 illustrates exemplary steps for identifying the addressees or intended recipients of statement data and for providing statement data for inclusion on the group statement, a dependent statement, and a courtesy statement. In [0157] step 900, statement data for the key account (if any) and the dependent accounts are calculated. If the group includes a key account, then the statement data for the key account is provided for the group statement in step 900. In step 904, the dependent strategy for a dependent account is checked to determine whether payment for the dependent account is due from the primary owner or from a dependent cardholder associated with the dependent account.
  • If payment for the dependent account is due from the primary owner, then the “Yes” branch is followed to step [0158] 908. In step 908, the primary owner of the group is identified as an intended recipient of the statement data for the dependent account and the statement data for the dependent account is provided for inclusion on the group statement. In step 910, a determination is made as to whether the dependent strategy specifies that the dependent cardholder receives a courtesy statement. If the dependent strategy specifies that the dependent cardholder receives a courtesy statement, then the “Yes” branch is followed to step 912. In step 912, the dependent cardholder is identified as another intended recipient of the statement data for the dependent account and the statement data for the dependent account is provided for inclusion on the dependent statement. If the determination in step 910 is that the dependent strategy does not specify that the dependent cardholder receives a courtesy statement, then the “No” branch is followed to step 914 and the method ends.
  • If payment for the dependent account is due from a dependent cardholder associated with the dependent account, then the “No” branch is followed to step [0159] 916. In step 916, the dependent cardholder of the group is identified as an intended recipient of the statement data for the dependent account and the statement data for the dependent account is provided for inclusion on a statement for the dependent cardholder. In step 918, a determination is made as to whether the dependent strategy specifies that the details of the activity of the dependent account are included on the group statement. If the details of the activity of the dependent account are included on the group statement, then the “Yes” branch is followed to step 920. In step 920, the primary owner is identified as another intended recipient of the statement data for the dependent account and the statement data for the dependent account is provided for inclusion on the group statement. If the dependent account statements on the same day as the group, then current statement data is provided for inclusion on the group statement. However, if the dependent account statements on a different day than the group, then statement data associated with the last dependent statement is provided for inclusion on the group statement.
  • If the determination in [0160] step 918 is that the details of the activity of the dependent account are not included on the group statement, then the “No” branch is followed to step 922. In step 922, the primary owner is identified as another intended recipient of the statement data for the dependent account and a summary of the statement data for the dependent account is provided for inclusion on the group statement.
  • [0161] Step 904 illustrates that the dependent strategy for a dependent account is checked. As will be apparent to those skilled in the art, if the group includes multiple dependent accounts, then steps 904 through 922 are repeated for each dependent account.
  • Cardholder Communications [0162]
  • The dependent strategy for a dependent account also provides cardholder communication options for the dependent account. The communication options specify the intended recipient of an original communication, such as a letter, notice, or plastic, and, in the case of letters or notices, specify whether a courtesy copy of the communication is provided. A communication is typically generated to provide information to the cardholder. For example, a communication can be generated to advise a cardholder of changes to the cardholder agreement or to advise a cardholder of special offers. [0163]
  • The dependent strategy can specify that the original communication is sent to the primary owner. The dependent strategy can also specify that a courtesy copy of the communication is sent to the dependent cardholder. Alternatively, the dependent strategy can specify that the original communication is sent to the dependent cardholder. If the dependent strategy specifies that the original communication is sent to the dependent cardholder, the dependent strategy can also specify that a courtesy copy of the communication is sent to the primary owner. [0164]
  • In some instances, it may be necessary to generate multiple courtesy copies. This situation may occur if two parties are jointly liable on an account. For example, a dependent account could be jointly held by a first dependent cardholder and a second dependent cardholder. If the dependent strategy specifies that the first dependent cardholder receives the original communication and that the primary owner receives a courtesy copy, then in addition to the courtesy copy sent to the primary owner, a second courtesy copy is sent to the second dependent cardholder because the account is jointly held. [0165]
  • If the group includes multiple dependent accounts, then the dependent strategies for the dependent accounts can specify that the primary owner is to receive the original communication or a courtesy copy. Preferably, it is recognized that multiple communications are being sent to the primary owner so that the communications can be merged into a single communication that includes the communications for all the dependent accounts. [0166]
  • A group communication can include information about some or all of the accounts within a group. Typically, a group communication is sent to the primary owner of the group. Information about selected accounts of the group is obtained from the financial records corresponding to the accounts. The type of information obtained from the financial records can vary according to the type of communication. Typically, the type of information is specified by a processing option or variable associated with the communication. The information obtained from the financial records is combined into a single communication. The single communication can be automatically generated. [0167]
  • A group communication can also be manually created. The group communication can include information about the accounts within the group. To manually create a group communication, an operator can use a series of on line screens to specify the accounts and the type of information to be included in the communication. [0168]
  • In addition to letter communications, the primary owner and the dependent account cardholders may also receive notices. Notices are added to a group statement by considering what notices are required for the key account, what notices are required for each of the dependent accounts, and what notices are optional for the key account and the dependent accounts. If several accounts require the same notice, then preferably the notices are reviewed to insure that no duplicates are included. [0169]
  • Pooling Rewards, Accruing Rewards, and Redeeming Rewards [0170]
  • Reward programs allow parties to earn reward points based on purchases and other account activity. The processing of reward points at the account and/or group level can be determined by the reward program and the dependent strategies of the dependent accounts in a group group. In some cases, the availability of group level pooling is determined by the reward program. It may be that some programs permit group pooling, whereas other programs do not. If the accounts in a group are members of multiple reward programs, then it is possible that some programs permit pooling while other programs do not. [0171]
  • If a reward program supports pooling, then any reward points earned by one or more accounts in an account group can be combined into the group reward pool. The dependent strategy specifies whether reward points earned by a dependent account are pooled or are maintained at the account level. In addition, the dependent strategy specifies whether the dependent account cardholder can redeem group reward points. [0172]
  • An exemplary method for redeeming group reward points is shown in FIG. 10. In [0173] step 1000, a request to redeem group reward points is received. In step 1002, a determination is made as to whether the request is associated with an account that is a member of the group. If the request is from an account that is a member of the group, then the “Yes” branch is followed to step 1004. In step 1004, a determination is made as to whether the reward program supports pooling. If the reward program supports pooling, then the “Yes” branch is followed to step 1006. In step 1006, a determination is made as to whether the account making the request is the key account. If the requesting account is the key account, then the “Yes” branch is followed from step 1006 to step 1012. However, if the requesting account is not the key account, then the requesting account is a dependent account and the “No” branch is followed from step 1006 to step 1008. In step 1008, the dependent strategy for the requesting dependent account is checked. A determination is made in step 1010 as to whether the dependent strategy specifies that the dependent account can redeem group reward points. If the dependent account can redeem group reward points, then the “Yes” branch is followed to step 1012.
  • In [0174] step 1012, a determination is made as to whether there are sufficient group points to satisfy the redemption request. If there are sufficient points, then the “Yes” branch is followed to step 1018 and the request to redeem group reward points is authorized. However, if there are not sufficient points, then the “No” branch is followed to step 1014 and the redemption request is not authorized.
  • If the determination in [0175] step 1002 is that the request to redeem group reward points is made by an account that is not a member of a group or the determination in step 1004 is that the reward program does not support reward point pooling, then the method proceeds to step 1016. Likewise, if the determination in 1010 is that the dependent account strategy does not allow the redemption of group reward points, then the method proceeds to step 1016. In step 1016 the requesting account is permitted to redeem points that are associated with the requesting account, but is not permitted to redeem group points.
  • As an alternative to reward point pooling, reward points can be shared between the accounts of a group via chasing. If chasing is implemented, then reward points earned by an account remain at the account level. The points can be chased or collected from the account level and used to satisfy a single redemption request. [0176]
  • Preferably, chasing is enabled or disabled by the reward program. If chasing is enabled by the reward program, then the accounts that participate in the reward program can support chasing. If an account supports chasing, then the account permits another account to redeem its earned reward points. If the account is a key account, then the option to support chasing could be part of the predefined relationship between the key account and the group. If the account is a dependent account, then the option to support chasing could be part of the dependent strategy. The ability to chase reward points could expand beyond the group to accounts that are not members of the group. [0177]
  • If a cardholder makes a redemption request that exceeds the reward points associated with the cardholder's account, then a determination is made as to whether the reward program supports chasing. If the reward program supports chasing, then the accounts that permit chasing in that reward program are identified. Points are chased from the identified accounts to satisfy the redemption request. The points are chased from the accounts based on a chasing option that specifies how the points are chased from the identified account. The chasing option could specify that the points are chased from the accounts on a pro rata basis, on the basis of an account hierarchy, or on some other basis. Chasing could be performed by an operator pursuant to instructions received by a cardholder. If chasing is performed by an operator, then the accounts that support chasing are displayed and the operator can select the accounts to chase. The operator can also determine the number of points chased from each account. Of course, while FIG. 10 is directed to reward access in a group environment, such reward access can also be applied to redeeming rewards from a single account associated with a redeeming party, or even an account or account group unrelated to the redeeming party. [0178]
  • Turning to FIG. 11, a system [0179] 1100 is configured in accordance with an embodiment of the present invention for accruing rewards, identifying rewards, redeeming rewards and/or fulfilling reward redemption requests. As will be appreciated from the disclosure provided herein, many other configurations of system 1100 are possible in accordance with the present invention. As illustrated, system 1100 includes a number of accounts 1105, 1110, 1115. One or more of the accounts are associated with rewards 1106, 1111, 1116. Further, it is possible that such accounts can be associated with multiple reward types, or only a single reward type. In some cases, the reward associated with the account is maintained in a separate reward account, while in other cases, the account only serves to maintain the reward. Thus, for example, account 1105 can be a credit card account that accrues frequent flyer miles in a separate, but integrally related reward account 1106. In contrast, account 1110 can be a frequent flyer account that is augmented based on travel activity, and the primary function of account 1110 is to account for reward 1111.
  • System [0180] 1100 further includes an identification system 1125, a request format system 1135, a request reception system 1145, an account association system 1150, and a request fulfillment system. Identification system 1125 comprises a computer capable of accessing accounts 1105, 1110, 1115. In accessing accounts 1105, 1110, 1115, identifying system 1125 can determine what type of rewards 1106, 1111, 1116 that are associated with accounts 1105, 1110, 1115, as well as the amount of any accrued reward. When rewards are redeemed, or moved to another accounting entity, identification system 1125 can deduct any redeemed reward. In addition, where a reward is redeemed prior to being earned, identification system 1125 can maintain an accounting of the reward deficit until a sufficient reward has been accrued to cover the deficit.
  • Further, in some cases, [0181] identification system 1125 can compute the rate at which the identified rewards are accruing. As such, identification system 1125 can determine an approximate point in time when a sufficiently large award will be available to satisfy a reward redemption request. Further, in some cases, identification system 1125 can be responsible for identifying when a reward threshold has been achieved such that an automatic redemption is triggered. In various cases, identification system 1125 can further assign or otherwise determine a common value associated with any accrued reward. Thus, as further discussed below where rewards are exchanged on a public market, an exchange value for unrelated reward types can be fixed and used in relation to an effectuated exchange. Where such a public exchange is implemented, identification system 1125 can be responsible for transferring value between accounts to cover any exchange of rewards.
  • [0182] Request format system 1135 is a computer, or in some cases the same computer as identification system 1125, that formats one or more requests that affect accounts 1105, 1110, 1115. For example, request format system 1135 includes functionality to parse a reward redemption request and separate an account, a reward amount, and a reward type from a received request. Further, request format system 1135 can parse requests to group accounts, or otherwise modify group relationships as previously described. Yet further, request format system 1135 can parse fulfillment information such that rewards are deducted from the proper account 1105, 1110, 1115 upon redemption of one or more rewards.
  • Request reception system [0183] 1145 is a computer, or in some cases the same computer as identification system 1125, that is responsible for receiving requests in relation to accounts 1105, 1110, 1115. For example, request reception system can provide interfaces for receiving requests from account owners to group accounts and/or modify rules associated with the accounts and account groups. Thus, in some cases, request reception system 1145 serves Internet web pages that include user interfaces for receiving such requests. Alternatively, request reception system 1145 supports an IVR, or other such automated equipment for receiving requests in relation to accounts 1105, 1110, 1115. As another example, such interfaces can be provided to receive reward redemption requests, and to view the status of accounts 1105, 1110, 1115.
  • [0184] Account association system 1150 is a computer, or in some cases the same computer as identification system 1125, that implements the business rules related to assembling accounts into account groups, and defining account group rules as previously described. Thus, when a request is received to modify one or more group relationships via request reception system 1145, account association system 1150 can be accessed to approve the modification, and once approved, identification system 1125 can be accessed to implement the modification in relation to accounts 1105, 1110, 1115.
  • [0185] Request fulfillment system 1155 is a computer, or in some cases the same computer as identification system 1125, that is responsible for assuring that reward redemption requests are satisfied. In some cases, such reward redemption requests are received from consumers and involve an indication of a reward to be redeemed and the person redeeming the reward. In other cases, such reward redemption requests involve identifying an account that has accrued sufficient rewards to be redeemed, and contacting a person associated with the account to obtain a selection of a reward to be redeemed. In some cases, request fulfillment system 1155 is maintained by an entity other than the entity maintaining accounts 1105, 1110, 1115. Thus, for example, request fulfillment system 1155 can be maintained by a retailer contracted by the entity maintaining accounts 1105, 1110, 1115 to provide third party fulfillment of reward redemption requests. This can be advantageous as it allows an entity more capable of fulfilling redemption requests to perform the fulfillment requests, leaving the entity maintaining accounts 1105, 1110, 1115 largely unburdened.
  • Referring to FIG. 12, a flow diagram [0186] 1200 illustrating a method for redeeming rewards in accordance with embodiments of the present invention is provided. As illustrated, a reward redemption request is received (block 1205). In some cases, this reward redemption request is received from an owner of an account, while in other embodiments, this reward redemption request is received from a member of an account group. The account and/or account group to which the reward redemption request is associated is then determined (block 1210).
  • It is then determined if a sufficient reward is associated with the account group and/or account to satisfy the reward redemption request (block [0187] 1215). Thus, where the reward redemption request is to be satisfied from a reward associated with an individual account, it is determined whether the reward associated with the individual account is sufficient to cover the request. Alternatively, where the reward is to be satisfied from an account group, it is determined whether a reward pool associated with the account group includes a reward large enough to satisfy the request. As yet another alternative, where the reward is to be satisfied from an account group, it can be determined whether rewards maintained in relation to one or more accessible accounts in the account group, either separate or aggregated, are sufficiently large to satisfy the request. Where the reward(s) are sufficiently large, then the reward redemption request is fulfilled and the reward(s) is/are deducted from the appropriate account(s) and/or account group (block 1220).
  • Alternatively, where the reward(s) are not sufficiently large, it is determined whether the total rewards are within a predefined range of the reward redemption request (block [0188] 1225). In some cases, it may be determined that the available reward is within a particular threshold of meeting the reward redemption request. Thus, for example, it may be determined whether the available reward is within twenty percent of that required to satisfy the reward redemption request. Alternatively, a reward accrual velocity, or the rate at which the reward has been augmented over some period, can be calculated. This reward accrual velocity can be used to calculate a point in time where the reward will be sufficient to satisfy the reward redemption request. In this way, it can be determined whether, based on past and/or present performance, that the available reward will be sufficiently large within a set time period. Such a time limit can be, for example, one month. In yet other cases, a combination threshold and time limit test can be applied. Thus, for example, it can be determined whether a threshold required to meet the reward redemption request will be met in a given time period.
  • Where it is determined that the available reward is or will be within a set range (block [0189] 1225), then the reward redemption request is fulfilled and the reward(s) is/are deducted from the appropriate account(s) and/or account group (block 1220). Further, the deficit between the available reward(s) and the amount of the reward redemption request is recorded. This deficit is satisfied as the reward is augmented based on activity associated with the account(s) and/or account group.
  • Where it is determined that the available reward is not within a defined limit (block [0190] 1225), the reward redemption request is stored and remains pending until it is either canceled, the required reward is achieved, or the available reward is augmented within the defined threshold and/or will increase to such levels within a defined time frame (block 1230). Where the reward redemption request is not canceled, the augmentation of the reward(s) is/are monitored to determine when the reward(s) is/are sufficiently large to allow fulfillment of the reward redemption request (block 12). Such augmentation of the rewards can be based on use of an account and/or activity of person(s) associated with the account, or accounts within an account group. Thus, for example, a frequent flyer reward may be augmented based on travel of a person associated with an account or account group, and/or based on use of a financial account where frequent flyer miles accrue based on spending.
  • As an example, a reward redemption request can be received from a person owning an account associated with an account group, and requesting 35,000 frequent flyer miles to exchange for a plane ticket. It may be determined that the account owned by the person has only 25,000 frequent flyer miles available, and that the account is accruing frequent flyer miles at a rate of 3,000 per month. A rule may exist that allows for redemptions to be fulfilled where eighty percent of the total required reward is available, and where the deficit reward will likely be repaid within three months. Thus, in this case, the reward redemption request will be fulfilled in the following month where the balance will likely be 28,000 frequent flyer miles, or eighty percent of the required 35,000, and the accrual velocity indicates that the total reward will be available within the three succeeding months. [0191]
  • Referring to FIG. 13, a [0192] flow chart 1300 illustrates another embodiment of the present invention for accruing and/or redeeming rewards. As illustrated, a first account is provided (block 1305). In some cases, this can include setting up a financial record associated with the account, and where applicable, providing a presentation instrument for accessing the financial account. In other cases, this can include setting up various accounts for maintaining vacation days, sick days, insurance benefits, and the like. In yet other instances, this can include setting up a frequent travel account or other incentive account. Based on the disclosure provided herein, one of ordinary skill in the art will recognize a myriad of other account types that can be set up in accordance with the various embodiments of the present invention.
  • A reward and a party are associated with the first account ([0193] blocks 1310, 1315). Activity of the first party is then monitored and the associated reward is augmented based upon the activity (block 1320). Such activity by the party can include any number of activities including, but not limited to, travel, purchases, use of a financial account, years of service to an employer, payment for insurance benefits, and the like. Where a reward redemption request is received from the party associated with the first account (block 1325), it is determined if a sufficient reward has accrued to satisfy the request, and the request is fulfilled by redeeming the reward (block 1335). Such a process includes exchanging the accrued reward, or portion thereof for merchandise, services, or other value obtainable thereby. Where neither a request to redeem (block 1325), nor a request to associate another party with the first account (block 1330) is received, monitoring activity associated with the first party continues as previously discussed (block 1320).
  • Alternatively, or in addition, where a request to associate another party with the first account is received (block [0194] 1330), it is further determined if an account associated with the other party will also be associated with the first account (block 1340). Where another account is to be associated with the first account, the other account is grouped with the first account as previously discussed in relation to account grouping (block 1345). Further, in some cases, any reward associated with the added account can be combined with that of the first account in a reward pool (block 1350). Alternatively, in some cases, the two rewards are combined and maintained in association with the first or second account, while in other cases, the rewards remain associated with the respective accounts and are chased when a reward redemption request is received.
  • The second party is also associated with the first account by, for example, adding the second party to the first account as a liable party (block [0195] 1355). Alternatively, the second party can be added to a group that includes the first account, thereby making the reward associated with the first account accessible to the second party. At this point, activity of both the first and second parties is monitored, and the reward augmented accordingly (block 1360). Thus, where a second account associated with the second party is grouped with the first account and the rewards are maintained in a reward pool, activity by either party will augment the reward pool. Alternatively, where a second account associated with the second party is grouped with the first account, but the rewards remain with the respective accounts, activity of the first party augments the reward associated with the first account, and activity of the second party augments the reward associated with the second account. As yet another alternative, where the second party is merely associated with the first account, activity of both the first and second party augment the reward associated with the first account. Based on the disclosure provided herein, one of ordinary skill in the art will recognize many other combinations for augmenting rewards maintained in relation to accounts and/or account groups.
  • Where a redemption request is received from the first party (block [0196] 1365), the redemption request is satisfied where a sufficient reward is available (block 1375). The same process can be used to satisfy reward redemption requests from the second party (block 1370). The reward used to fulfill the redemption request can be deducted from a reward pool associated with an account group, or the reward associated with the first account where a second account was not added and an account group does not exist. Alternatively, some form of reward chasing can be implemented where the reward is satisfied first from an account owned by the requester, and secondarily from another account linked to the first account. Thus, for example, where the reward redemption request is received from the first party and requires a reward of X, whatever portion of X is available from the first account is first accessed to satisfy the request, and then the remaining portion of X is accessed from the second account.
  • As one particular example of the method, frequent flyer rewards are accrued. In the example, an account is provided and associated with a frequent flyer reward that is augmented based at least in part on activity of a party. A request is received to associate another party with the account, and this added party is associated with the account. Upon association, the frequent flyer reward accrues based at least in part on activity of the added party. Once the party is added to the account, reward redemption requests from either party can be satisfied, and activity by either party augments the available frequent flyer reward. [0197]
  • As another example, frequent flyer rewards can be accrued to a commonly accessible account or account group where at least two accounts are provided that are each associated with frequent flyer rewards. Each account accrues a frequent flyer reward based on activity of the party or parties associated with the respective accounts. Reward redemption requests can then be satisfied from a combination of the rewards associated with the individual accounts. [0198]
  • Turning to FIG. 14, a flow diagram [0199] 1400 illustrates yet another embodiment of the present invention for redeeming rewards. As illustrated, a reward redemption request is received (block 1405). The redemption request is parsed to identify the type of reward requested, and the amount of the reward requested (block 1410). Next, an account and/or account group that accrues the reward type is identified (block 1415). In some cases, this can include identifying an account within an account group to which the requestor is associated. In particular cases, this can include identifying an account owned by the requestor, while in yet other cases, this can involve identifying an account otherwise unrelated to the requestor.
  • It is determined if the identified account has a sufficient award available to satisfy the reward redemption request (block [0200] 1420). Where the identified account has an insufficient reward, another account is identified that accrues the reward type (block 1425). It is then determined if a combination of the identified accounts have a sufficient reward to satisfy the request (block 1430). Where the reward is still insufficient, yet another account is identified and the process repeated until a sufficient reward is found (blocks 1425, 1430).
  • Once a sufficient reward is found ([0201] blocks 1420, 1430), it is determined if private or public settlement of a reward transfer is available (block 1445). Where the settlement is private, the reward is simply redeemed, and the amount of the reward deducted from the identified account(s) (block 1450). In general, where the identified accounts including a reward(s) used to satisfy the redemption request is within an account group, or is otherwise associated with the requestor, then private settlement is used. In such cases, an entity operating a reward exchange merely accesses rewards and fulfills reward redemption requests in accordance with rules, or dependent strategies, associated with various accounts and/or account groups. It is left to the members of a particular account group, or co-owners of a particular account to determine a value of the accessed reward and to settle between themselves terms for exchanging the reward.
  • Alternatively, where the requestor is otherwise unrelated to the account from which the reward is derived, a public settlement process can be implemented. In such a public settlement process, a reward accessed from an account can be converted to a common value, such as, a cash value (block [0202] 1435). This value can be set by the account owner, or a market value may be used that represents a going rate for the reward type. The common value of the reward is then transferred from an account associated with the requestor to the account from which the reward is being accessed (block 1440). With settlement for the reward exchange thus accomplished, the reward is redeemed, and the reward amount deducted from the identified and compensated account(s) (block 1450). Of course, it should be recognized that a public exchange could be provided and used in relation to account groups.
  • As an example, where a hotel stay certificate requiring [0203] 10000 bonus points is requested, an account that accrues that type of bonus points is identified. In this example, a person requesting the certificate is a member of an account group that includes the identified account. The account group further includes dependent strategies regarding the redemption of rewards associated with the account group, and the members of the account group provide for private settlement of exchanges. Because of this, the hotel stay certificate is simply provided to the requester, and the 10,000 bonus points are deducted from the identified account.
  • Alternatively, where the requestor is unrelated to the identified account, and a public settlement is used, the bonus points may be valued at one cent each. Based on this value, one hundred dollars is transferred from an account associated with the requestor to the identified account. Further, the requester is provided with the hotel stay certificate, and the 10,000 bonus points are deducted from the identified account. [0204]
  • Turning to FIG. 15, a flow diagram [0205] 1500 illustrates another embodiment in accordance with the present invention for redeeming rewards. As illustrated, augmentation of rewards associated with an account and/or account group is monitored (block 1510). As previously discussed, augmentation of a reward can be based on activities including, but not limited to, travel, purchases, use of a financial account, years of service to an employer, payment for insurance benefits, and the like. It is then determined if a reward exceeds a pre-defined level (block 1520). For example, it may be determined that an account has more than 20,000 bonus points available that can be exchanged for merchandise. Where the amount of the reward has not reached the pre-defined level, the monitoring continues.
  • Alternatively, where the threshold has been met, the account information including the reward type and amount is provided to a fulfillment entity responsible for redeeming the reward (block [0206] 1530). In some cases, the fulfillment entity can be a party other than the party maintaining the accounts to which the various rewards are accruing. Thus, for example, the fulfillment entity can be a retailer supplying merchandise in exchange for the accrued reward(s). As yet another example, the fulfillment entity can be a service provider, such as an airline, providing services in exchange for the accrued reward(s).
  • The account owner, or designated group owner is then directed to a fulfillment interface, or selection system (block [0207] 1540). Such a fulfillment interface can include an Internet web page that includes a variety of selections offered by the fulfillment entity in exchange for the accrued bonus. Thus, for example, the web page may include a product catalog of a retailer with corresponding costs for items listed in terms of the reward type. Alternatively, the fulfillment interface can be an IVR or other automatic interface system capable of providing an owner of a reward with exchange options.
  • A selection is received from the reward owner via the fulfillment interface (block [0208] 1550). The cost of the selection in terms of the reward type is then computed, the corresponding amount of the reward deducted from the reward owner's account, and the redemption fulfilled by providing the selected merchandise, service, or other value to the reward owner (blocks 1555, 1560).
  • Group Non-monetary Transactions [0209]
  • In addition to group monetary transactions, such as authorizing a transaction or allocating a payment, group non-monetary transactions are also needed to support groups. A non-monetary transaction is a transaction that affects information for one or more accounts within the group, but does not affect the monetary information for the account. For example, a change in billing address is a non-monetary transaction, whereas the application of a payment is a monetary transaction. Other examples of non-monetary transactions include linking an account to an existing group, delinking one or more accounts from a group, changing the primary owner of a group, or changing the dependent strategy for a dependent account. [0210]
  • Group non-monetary transactions can be used in both batch and on line processing. Group non-monetary transactions update multiple accounts within a group in response to a single input of the updated information. To update the accounts in a group with updated group information, the accounts within the group are identified. The accounts are identified using the group master data. As described in connection with FIG. 4B, the accounts in a group can be identified using the Group Member file. Once the financial records are identified, then the financial records are updated with the new information. [0211]
  • Group non-monetary transactions also support the selective updating of accounts within the group. For example, if only certain accounts within the group are to receive the updated information, then the accounts in the group are identified and one or more of the accounts is selected and the selected account(s) is updated with the new information. In an on-line environment, an operator can select the accounts that are to receive the updated information. In a batch environment, the updated information and the account numbers for the selected accounts can be submitted in batch. [0212]
  • The invention has now been described in detail for purposes of clarity and understanding. However, it will be appreciated that certain changes and modifications may be practiced within the scope of the appended claims. Accordingly, it should be recognized that many other systems, functions, methods, and combinations thereof are possible in accordance with the present invention. Thus, although the invention is described with reference to specific embodiments and figures thereof, the embodiments and figures are merely illustrative, and not limiting of the invention. Rather, the scope of the invention is to be determined solely by the appended claims. [0213]

Claims (71)

What is claimed is:
1. A method for processing rewards, the method comprising:
identifying a reward type;
providing an earning rule associated with the reward type, wherein the earning rule governs how a reward of the reward type is earned;
providing an accrual rule associated with the reward type, wherein the accrual rule governs how the reward of the reward type is maintained;
providing a redemption rule associated with the reward type, wherein the redemption rule governs how the reward of the reward type may be redeemed, wherein the redemption rule indicates a plurality of accounts through which a redemption can be initiated; and
providing a fulfillment rule associated with the reward type; wherein the fulfillment rule governs how a redemption of the reward of the reward type is performed.
2. The method of claim 1, wherein the reward type is selected from a group consisting of: a point based reward, and a cash based reward.
3. The method of claim 1, wherein the earning rule indicates that the reward of the reward type is earned whenever a defined activity is performed, and wherein the defined activity is selected from a group consisting of: travel, and use of a presentation instrument.
4. The method of claim 1, wherein the earning rule indicates that the reward of the reward type is earned at a first rate when an activity is performed in relation to an account group, and at a second rate when an activity is performed in relation to an individual account.
5. The method of claim 4, wherein the activity is use of a presentation instrument, and wherein the first rate is greater than the second rate.
6. The method of claim 1, wherein the accrual rule indicates that the reward of the reward type is maintained in a reward pool.
7. The method of claim 6, wherein the redemption rule indicates that redemption of the reward of the reward type is limited based at least in part on the prior history of redemptions performed in relation to the reward pool.
8. The method of claim 6, wherein the redemption rule indicates that redemption of the reward of the reward type is limited based at least in part on an attribute of the reward pool.
9. The method of claim 1, wherein the accrual rule indicates that the reward of the reward type is maintained in association with an account group.
10. The method of claim 1, wherein the redemption rule indicates that the reward of the reward type can be chased.
11. The method of claim 1, wherein the redemption rule indicates that the reward of the reward type is automatically redeemed.
12. The method of claim 1, wherein the fulfillment rule indicates that the reward of the reward type is fulfilled by an enumerated fulfillment entity.
13. The method of claim 12, wherein the enumerated entity is a merchandise retailer.
14. A method for accruing frequent flyer rewards, the method comprising:
providing an account, wherein the account includes a frequent flyer reward that accrues based at least in part on activity of a first party, and wherein the account is controlled by an airline;
receiving a request to associate a second party with the account;
associating the second party with the account, wherein the frequent flyer reward accrues based at least in part on activity of the second party; and
receiving a request to redeem the reward.
15. The method of claim 14, wherein the activity of the first party is travel.
16. The method of claim 14, wherein the activity of the first party is use of a credit card.
17. A method for acquiring frequent flyer rewards, the method comprising:
providing a first account, wherein the first account includes a first frequent flyer reward that accrues based at least in part on activity of a first party;
providing a second account, wherein the second account includes a second frequent flyer reward that accrues based at least in part on activity of a second party;
associating the first account with the second account, wherein a combination of the first frequent flyer reward and the second frequent flyer reward is accessible by the first party.
18. The method of claim 17, the method further comprising:
aggregating the first frequent flyer reward and the second frequent flyer reward in a reward pool.
19. The method of claim 18, wherein the reward pool is linked with the first account.
20. The method of claim 18, wherein the first account and the second account are linked in an account group, and wherein the reward pool is linked with the account group.
21. The method of claim 17, the method further comprising:
receiving a reward redemption request from the second party, wherein satisfying the reward redemption request requires an amount greater than the second frequent flyer reward; and
accessing at least a portion of the first frequent flyer reward to satisfy the reward redemption request.
22. A method for redeeming rewards, the method comprising:
receiving a reward redemption request, wherein the reward redemption request indicates a reward type;
identifying an account that accrues the reward type; and
accessing a reward of the reward type to at least partially satisfy the reward redemption request.
23. The method of claim 22, wherein the account is a first account, wherein the reward is a first reward, and wherein the reward redemption request is associated with a second account, the method further comprising:
accessing a second reward of the reward type to at least partially satisfy the reward redemption request, wherein the second reward is associated with the second account.
24. The method of claim 22, wherein the account is a first account, and wherein the reward redemption request is associated with a second account, the method further comprising:
converting the reward to a common value; and
transferring the common value from the second account to the first account.
25. The method of claim 22, wherein the account is a first account, wherein the reward type is a first reward type, and wherein the reward redemption request is associated with a second account that accrues a second reward type, the method further comprising:
converting the reward of the first reward type to a common value;
converting a reward of the second reward type to the common value; and
transferring the common value from the second account to the first account.
26. The method of claim 22, wherein the account is a sick days account, and wherein the reward type is sick days.
27. The method of claim 22, wherein the account is a vacation days account, and wherein the reward type is vacation days.
28. The method of claim 22, wherein the account is a financial account.
29. The method of claim 28, wherein the reward type is selected from a group consisting of: a point based reward and a cash based reward.
30. The method of claim 28, wherein the reward type is a reduced interest rate.
31. The method of claim 22, wherein the reward is a first reward, the method further comprising:
lending a second reward, wherein the second reward partially satisfies the reward redemption request.
32. The method of claim 31, wherein lending the reward includes defining terms of the lending, the method further comprising:
applying a penalty wherein the terms of the lending are not met.
33. The method of claim 32, wherein the terms of the lending define a period in which the second reward must be accrued.
34. The method of claim 32, wherein the account is a first account, wherein the reward redemption request is associated with a second account, and wherein the terms of the lending define a period in which the second account must remain active, such that an owner of the second account is given an incentive to maintain the second account.
35. A method for redeeming rewards, the method comprising:
receiving a reward redemption request associated with an account, wherein the reward redemption request includes a reward amount;
determining that the reward amount is greater than a reward associated with the account; and
pending the reward redemption request.
36. The method of claim 35, the method further comprising:
augmenting the reward associated with the account based at least in part on activity in the account.
37. The method of claim 36, the method further comprising:
determining that the reward amount is less than the reward associated with the account; and
satisfying the reward redemption request.
38. The method of claim 36, the method further comprising:
determining that the reward amount is within a predefined amount of the reward associated with the account; and
satisfying the reward redemption request.
39. The method of claim 38, wherein the predefined amount is a time period, the method further comprising:
determining a reward accrual velocity; and
wherein determining that the reward amount is within the predefined amount includes determining an estimated time until the reward amount is less than the reward associated with the account.
40. The method of claim 35, wherein the account is a first account, wherein the reward is a first reward, wherein the first account and a second account are associated in an account group, wherein a second reward associated with the second account is combined with the first reward in a reward pool, and wherein determining that the reward amount is greater than the reward associated with the first account further includes determining that the reward amount is greater than a reward available from a reward pool.
41. The method of claim 35, wherein the account is a vacation days account, and wherein the reward redemption request is for vacation days.
42. The method of claim 35, wherein the account is a financial account.
43. The method of claim 39, wherein the reward redemption request for a reward selected from a group consisting of: frequent flyer miles, value exchangeable for merchandise, and hotel stays.
44. A method for redeeming rewards, the method comprising:
receiving a reward redemption request, wherein the reward redemption request includes a reward amount;
identifying an account group to which the reward redemption request applies, wherein the account group includes at least a first account and a second account;
determining the reward amount is greater than an accrued reward accessible via the account group; and
pending the reward redemption request.
45. The method of claim 44, wherein the accrued reward is maintained in a reward pool.
46. The method of claim 45, wherein the accrued reward is augmented based on activity associated with the first account.
47. The method of claim 46, wherein the accrued reward is augmented based on activity associated with the second account.
48. The method of claim 45, wherein the reward pool accrues sick days, and wherein the reward redemption request is for sick days.
49. The method of claim 45, wherein the first account and the second account are financial accounts.
50. The method of claim 49, wherein the reward redemption request for a reward selected from a group consisting of: frequent flyer miles, value exchangeable for merchandise, and hotel stays.
51. The method of claim 44, the method further comprising:
augmenting the accrued reward based on activity associated with the first account;
determining that the reward amount is less than the augmented accrued reward; and
satisfying the reward redemption request.
52. The method of claim 44, the method further comprising:
augmenting the accrued reward based on activity associated with the first account;
determining that the reward amount is within a predefined amount of the augmented accrued reward; and
satisfying the reward redemption request.
53. The method of claim 44, wherein the predefined amount is a time period, the method further comprising:
determining a reward accrual velocity; and
wherein determining that the reward amount is within the predefined amount includes determining an estimated time until the reward amount is less than the reward associated with the account.
54. An automated method for redeeming rewards, the method comprising:
monitoring activity associated with an account, wherein the account is associated with a reward;
augmenting the reward based at least in part on the monitored activity;
determining that the augmented reward has achieved a defined level; and
automatically redeeming the reward.
55. The method of claim 54, wherein redeeming the reward includes:
providing an indication to a party associated with the account that the defined reward level is achieved;
directing the party to an Internet site; and
presenting a group of options for redeeming the reward.
56. The method of claim 55, wherein redeeming the reward further comprises:
receiving an indication of an option selected by the party; and
providing the selected option to the party.
57. The method of claim 56, wherein the options are selected from a group consisting of: cell phone minutes, mobile commerce value, merchandise, reduced interest rates, cash back, and travel rewards.
58. The method of claim 56, wherein the option selected by the party is mobile commerce value, and wherein providing the selected option includes uploading the mobile commerce value to a mobile commerce device.
59. The method of claim 54, wherein redeeming the reward includes:
providing an indication to a party associated with the account that the defined reward level is achieved;
directing the party to an phone redemption system; and
presenting a group of options for redeeming the reward.
60. The method of claim 54, wherein the account is a financial account.
61. The method of claim 60, wherein redeeming the reward comprises:
identifying an accrued reward to a fulfillment entity;
identifying the party associated with the account to the fulfillment entity;
receiving an indication that the fulfillment entity provided compensation for the accrued reward to the party associated with the account; and
deducting the accrued reward from the account.
62. The method of claim 61, wherein the fulfillment entity is a retailer providing merchandise in exchange for the accrued reward.
63. The method of claim 62, wherein the retailer performs the reward processing.
64. The method of claim 61, wherein the fulfillment entity is a group of retailers providing merchandise in exchange for the accrued reward.
65. The method of claim 61, wherein the fulfillment entity:
provides an indication to the party associated with the account that the defined reward level is achieved;
directs the party to a fulfillment mechanism; and
presents a group of options for redeeming the reward.
66. The method of claim 65, wherein the fulfillment mechanism is an Internet site maintained by the fulfillment entity.
67. The method of claim 65, wherein the fulfillment mechanism is an IVR.
68. The method of claim 60, wherein the financial account is associated with a credit card product.
69. A method for satisfying a unitary redemption request from rewards available from a plurality of accounts, the method comprising:
receiving a redemption request, wherein the redemption request identifies an amount of a reward type;
identifying a first account that accrues the reward type;
determining that the first account can only partially satisfy the amount;
identifying a second account that accrues the reward type; and
satisfying the redemption request, wherein the amount includes a first reward of the reward type from the first account and a second reward of the reward type from the second account.
70. The method of claim 69, wherein identifying the second account is done based on an indicator associated with the first account.
71. The method of claim 69, wherein identifying the second account is done in the same manner as identifying the first account.
US10/386,027 1998-04-24 2003-03-10 System and methods for redeeming rewards associated with accounts Abandoned US20030171992A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US10/386,027 US20030171992A1 (en) 1999-04-23 2003-03-10 System and methods for redeeming rewards associated with accounts
US11/956,221 US8073736B2 (en) 1998-04-24 2007-12-13 Systems and methods for redeeming rewards associated with accounts
US11/956,256 US20080097856A1 (en) 1998-04-24 2007-12-13 Systems and methods for redeeming rewards associated with accounts
US11/956,235 US20080091582A1 (en) 1998-04-24 2007-12-13 Systems and methods for redeeming rewards associated with accounts

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US09/298,521 US7340423B1 (en) 1998-04-24 1999-04-23 Method for defining a relationship between an account and a group
US09/298,505 US7050996B1 (en) 1998-04-24 1999-04-23 Method for linking accounts corresponding to different products together to create a group
US10/172,378 US20020198806A1 (en) 1998-04-24 2002-06-13 Systems and methods for accessing and modifying usage parameters associated with a financial transaction account
US10/237,572 US20040049452A1 (en) 2002-09-09 2002-09-09 Multiple credit line presentation instrument
US10/386,027 US20030171992A1 (en) 1999-04-23 2003-03-10 System and methods for redeeming rewards associated with accounts

Related Parent Applications (4)

Application Number Title Priority Date Filing Date
US09/298,505 Continuation-In-Part US7050996B1 (en) 1998-04-24 1999-04-23 Method for linking accounts corresponding to different products together to create a group
US09/298,521 Continuation-In-Part US7340423B1 (en) 1998-04-24 1999-04-23 Method for defining a relationship between an account and a group
US10/172,378 Continuation-In-Part US20020198806A1 (en) 1998-04-24 2002-06-13 Systems and methods for accessing and modifying usage parameters associated with a financial transaction account
US10/237,572 Continuation-In-Part US20040049452A1 (en) 1998-04-24 2002-09-09 Multiple credit line presentation instrument

Related Child Applications (3)

Application Number Title Priority Date Filing Date
US11/956,221 Division US8073736B2 (en) 1998-04-24 2007-12-13 Systems and methods for redeeming rewards associated with accounts
US11/956,256 Division US20080097856A1 (en) 1998-04-24 2007-12-13 Systems and methods for redeeming rewards associated with accounts
US11/956,235 Division US20080091582A1 (en) 1998-04-24 2007-12-13 Systems and methods for redeeming rewards associated with accounts

Publications (1)

Publication Number Publication Date
US20030171992A1 true US20030171992A1 (en) 2003-09-11

Family

ID=29554403

Family Applications (4)

Application Number Title Priority Date Filing Date
US10/386,027 Abandoned US20030171992A1 (en) 1998-04-24 2003-03-10 System and methods for redeeming rewards associated with accounts
US11/956,256 Abandoned US20080097856A1 (en) 1998-04-24 2007-12-13 Systems and methods for redeeming rewards associated with accounts
US11/956,235 Abandoned US20080091582A1 (en) 1998-04-24 2007-12-13 Systems and methods for redeeming rewards associated with accounts
US11/956,221 Expired - Fee Related US8073736B2 (en) 1998-04-24 2007-12-13 Systems and methods for redeeming rewards associated with accounts

Family Applications After (3)

Application Number Title Priority Date Filing Date
US11/956,256 Abandoned US20080097856A1 (en) 1998-04-24 2007-12-13 Systems and methods for redeeming rewards associated with accounts
US11/956,235 Abandoned US20080091582A1 (en) 1998-04-24 2007-12-13 Systems and methods for redeeming rewards associated with accounts
US11/956,221 Expired - Fee Related US8073736B2 (en) 1998-04-24 2007-12-13 Systems and methods for redeeming rewards associated with accounts

Country Status (1)

Country Link
US (4) US20030171992A1 (en)

Cited By (78)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030115134A1 (en) * 2001-12-18 2003-06-19 Kimio Kikuchi Credit account integration method
US20030120571A1 (en) * 1999-04-23 2003-06-26 First Data Corporation Authorizing transactions associated with accounts
US20030232281A1 (en) * 2002-02-20 2003-12-18 Fuji Photo Film Co., Ltd. Method for making lithographic printing plate
US20040010462A1 (en) * 2002-07-15 2004-01-15 Susan Moon Method and system for a multi-purpose transactional platform
US20040019543A1 (en) * 2002-07-25 2004-01-29 First Data Corporation Systems and methods for non-account based liability reporting
US20040049452A1 (en) * 2002-09-09 2004-03-11 First Data Corporation Multiple credit line presentation instrument
US20050021456A1 (en) * 2003-04-29 2005-01-27 Visa U.S.A. Method and system for facilitating switching of financial institution accounts
US20050080691A1 (en) * 2003-09-26 2005-04-14 First Data Corporation Systems and methods for participant controlled communications regarding financial accounts
US20050192862A1 (en) * 2004-02-27 2005-09-01 Capital One Financial Corporation Methods, systems, and articles of manufacture for providing incentives for a financial account
US20050240601A1 (en) * 2004-04-21 2005-10-27 Mairead Lyons System and method for transactional data collection and processing
US7083087B1 (en) 2000-09-18 2006-08-01 E-Micro Corporation Method and apparatus for associating identification and personal data for multiple magnetic stripe cards or other sources
US20060282377A1 (en) * 2005-06-10 2006-12-14 American Express Marketing & Development Corp., a New York Corporation System and method for delegating management of a financial transaction account to a designated assistant
US20070055628A1 (en) * 1999-04-23 2007-03-08 First Data Corporation Authorizing transactions associated with accounts
US20070130011A1 (en) * 1999-06-23 2007-06-07 Signature Systems Llc System for electronic barter, trading and redeeming points accumulated in frequent use reward programs
US20070198338A1 (en) * 2006-02-21 2007-08-23 First Data Corporation Customer selected coalition systems and methods
US20070233558A1 (en) * 2006-04-03 2007-10-04 Jones Kenneth A Mobile trading card redemption
US20080016003A1 (en) * 1999-06-18 2008-01-17 Echarge Corporation Method and apparatus for ordering goods, services, and content over an internetwork using a virtual payment account
US20080082420A1 (en) * 2006-10-03 2008-04-03 Kargman James B Method for Dynamic Group Formation and Purchasing
US20080097856A1 (en) * 1998-04-24 2008-04-24 First Data Corporation Systems and methods for redeeming rewards associated with accounts
US20080177672A1 (en) * 2007-01-23 2008-07-24 Robert Brunner Method for managing liability
US20080182724A1 (en) * 2007-01-25 2008-07-31 Nicole Lee Guthrie Activity Monitor with Incentive Features
US20080288396A1 (en) * 2007-05-16 2008-11-20 Jpmorgan Chase Bank, N.A. System and Method For Combined Reconciliation Of Co-Branded Card Promotion And Settlement Of Private Label Card Accounts
US20080307094A1 (en) * 2007-06-11 2008-12-11 Olli Karonen Association of peer-to-peer contribution credits with multiple devices
US20090055271A1 (en) * 2007-08-23 2009-02-26 Accenture Global Services Gmbh Travel reward accrual
US20090061831A1 (en) * 2007-08-31 2009-03-05 Vishwanath Shastry Mobile remittances/payments
US20090248506A1 (en) * 2008-03-31 2009-10-01 Maritz Inc. Merchant funded rewards network implementing cardholder loyalty rebate program
US20100086880A1 (en) * 2007-01-17 2010-04-08 Sony Corporation Developing solution and method for production of finely patterned material
US7708198B2 (en) 1998-05-29 2010-05-04 E-Micro Corporation Wallet consolidator to facilitate a transaction
US20100280896A1 (en) * 2009-01-14 2010-11-04 Signature Systems Llc Online reward point exchange method and system
US20100332382A1 (en) * 2007-06-04 2010-12-30 Monk Justin T Portability of financial tokens
US20110010238A1 (en) * 2004-03-01 2011-01-13 Richard Postrel Method and system for issuing, aggregating and redeeming merchant rewards
US7873574B1 (en) 1999-06-23 2011-01-18 Signature Systems Llc Method and system for using reward points to liquidate products
US7895098B2 (en) 2001-03-01 2011-02-22 Jpmorgan Chase Bank, N.A. System and method for measuring and utilizing pooling analytics
US7933835B2 (en) 2007-01-17 2011-04-26 The Western Union Company Secure money transfer systems and methods using biometric keys associated therewith
US7962391B2 (en) 2000-12-20 2011-06-14 Jpmorgan Chase Bank, N.A. System and method for determining elegibility and enrolling members in various programs
US7987501B2 (en) 2001-12-04 2011-07-26 Jpmorgan Chase Bank, N.A. System and method for single session sign-on
US20110191159A1 (en) * 2010-02-02 2011-08-04 Heitman Lynn Savings and rewards program
US8015085B2 (en) 2003-11-14 2011-09-06 First Data Corporation System for distributing funds
US8020754B2 (en) 2001-08-13 2011-09-20 Jpmorgan Chase Bank, N.A. System and method for funding a collective account by use of an electronic tag
US20110264489A1 (en) * 2010-04-23 2011-10-27 Ganz Dual-currency economy for a virtual social environment
US8078528B1 (en) 2008-02-21 2011-12-13 Jpmorgan Chase Bank, N.A. System and method for providing borrowing schemes
US20120030098A1 (en) * 2010-07-28 2012-02-02 The Western Union Company Receiver driven money transfer alert system
US8145549B2 (en) 2003-05-30 2012-03-27 Jpmorgan Chase Bank, N.A. System and method for offering risk-based interest rates in a credit instutment
US8160960B1 (en) 2001-06-07 2012-04-17 Jpmorgan Chase Bank, N.A. System and method for rapid updating of credit information
US8175908B1 (en) 2003-09-04 2012-05-08 Jpmorgan Chase Bank, N.A. Systems and methods for constructing and utilizing a merchant database derived from customer purchase transactions data
US8185940B2 (en) 2001-07-12 2012-05-22 Jpmorgan Chase Bank, N.A. System and method for providing discriminated content to network users
US20120271703A1 (en) * 1999-06-23 2012-10-25 Richard Postrel Portable hand-held multi-function device for storing, managing and combining rewards
US8301493B2 (en) 2002-11-05 2012-10-30 Jpmorgan Chase Bank, N.A. System and method for providing incentives to consumers to share information
US8447670B1 (en) 2005-05-27 2013-05-21 Jp Morgan Chase Bank, N.A. Universal payment protection
US8504473B2 (en) 2007-03-28 2013-08-06 The Western Union Company Money transfer system and messaging system
US8510160B1 (en) 2006-12-21 2013-08-13 Capital One Financial Corporation System and method for providing a reward
US8533031B2 (en) 2000-10-17 2013-09-10 Jpmorgan Chase Bank, N.A. Method and system for retaining customer loyalty
US20130262291A1 (en) * 2012-03-15 2013-10-03 Flextronics Ap, Llc Universal credit card
US8554631B1 (en) 2010-07-02 2013-10-08 Jpmorgan Chase Bank, N.A. Method and system for determining point of sale authorization
US8615428B2 (en) 2009-01-14 2013-12-24 Signature Systems, LLC. Point of sale device for online reward point exchange method and system
US8622308B1 (en) 2007-12-31 2014-01-07 Jpmorgan Chase Bank, N.A. System and method for processing transactions using a multi-account transactions device
US8768830B1 (en) 2011-09-08 2014-07-01 Citibank, N.A. Method and system for a multi-purpose transactional platform
US8793160B2 (en) 1999-12-07 2014-07-29 Steve Sorem System and method for processing transactions
US8818904B2 (en) 2007-01-17 2014-08-26 The Western Union Company Generation systems and methods for transaction identifiers having biometric keys associated therewith
US20140279799A1 (en) * 2013-03-14 2014-09-18 Bank Of America Corporation Providing rewards buckets and savings towards specific goals
US8849716B1 (en) 2001-04-20 2014-09-30 Jpmorgan Chase Bank, N.A. System and method for preventing identity theft or misuse by restricting access
US20150134437A1 (en) * 2012-05-16 2015-05-14 Rakuten, Inc. Point system, method for controlling point system, point management device, program, and information storage medium
US20150243175A1 (en) * 2014-02-25 2015-08-27 Kavita Raman Automated disciplinary and motivational system
US20170293930A1 (en) * 2016-04-06 2017-10-12 Mastercard International Incorporated Method and system for standalone real-time rewards
US9852438B2 (en) 2013-12-31 2017-12-26 Mastercard International Incorporated Systems and methods for peer-to-peer reward points transfer over mobile devices
US20180060896A1 (en) * 2016-08-30 2018-03-01 Ncr Corporation Collateralized rewards
US10074081B1 (en) 2009-08-14 2018-09-11 Citicorp Credit Services, Inc. (Usa) Methods and systems for use of a prepaid payment device
US10242382B1 (en) * 2005-09-20 2019-03-26 Capital One Services, Llc System and method for redeeming a reward
US10248964B1 (en) 2010-07-30 2019-04-02 American Express Travel Related Services Company, Inc. System and method for rewards redemption
US20190244203A1 (en) * 2018-02-05 2019-08-08 Capital One Services, Llc Real-time processing of requests related to facilitating use of an account
US10515427B1 (en) 2009-08-14 2019-12-24 Citicorp Credit Services, Inc. (Usa) Methods and systems for use of a prepaid payment device for a healthcare service or product
US20200043037A1 (en) * 2017-04-11 2020-02-06 Nomura Research Institute, Ltd. Point management system and point management program
US10607444B2 (en) 2017-02-10 2020-03-31 Bank Of America Corporation Third party activity performance cross entity integration
US10672021B2 (en) 2017-02-10 2020-06-02 Bank Of America Corporation System and method for location-based trafficking for resource accumulation
US11004052B2 (en) * 2009-02-13 2021-05-11 Visa International Service Association Point of interaction loyalty currency redemption in a transaction
US11093623B2 (en) 2011-12-09 2021-08-17 Sertainty Corporation System and methods for using cipher objects to protect data
US11386409B2 (en) 2016-03-04 2022-07-12 Sertintyone Corporation Systems and methods for media codecs and containers
US11423400B1 (en) * 1999-06-18 2022-08-23 Stripe, Inc. Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6636833B1 (en) 1998-03-25 2003-10-21 Obis Patents Ltd. Credit card system and method
EP1265202A1 (en) 2001-06-04 2002-12-11 Orbis Patents Limited Business-to-business commerce using financial transaction numbers
EP1402486A1 (en) 2001-06-27 2004-03-31 Snapcount Limited Transcation processing
US20060293953A1 (en) 2005-06-22 2006-12-28 Nicholson G R System and method for influencing customer behavior
US7742942B2 (en) 2005-06-22 2010-06-22 Excentus Corporation System and method for discounting fuel
US20090048897A1 (en) * 2007-08-13 2009-02-19 Accenture Global Services Gmbh Collections processing systems
US8447669B2 (en) 2008-08-26 2013-05-21 Visa U.S.A. Inc. System and method for implementing financial assistance programs
US20100301114A1 (en) 2009-05-26 2010-12-02 Lo Faro Walter F Method and system for transaction based profiling of customers within a merchant network
AU2011316955B2 (en) 2010-10-20 2016-12-01 Playspan Inc. Flexible monetization service apparatuses, methods and systems
US11157935B1 (en) 2010-12-03 2021-10-26 Excentus Corporation Systems and methods for self-generation of E-coupons
US8374934B1 (en) 2010-12-15 2013-02-12 United Services Automobile Association (Usaa) Credit card relationship derivation (AcctID) from historic data
WO2012097108A1 (en) * 2011-01-11 2012-07-19 Visa International Service Association Universal value exchange apparatuses, methods and systems
WO2012106655A2 (en) 2011-02-05 2012-08-09 Visa International Service Association Merchant-consumer bridging platform apparatuses, methods and systems
WO2012109628A2 (en) 2011-02-10 2012-08-16 Visa International Service Assocation Electronic coupon issuance and redemption apparatuses, methods and systems
CN103765453B (en) 2011-02-16 2018-08-14 维萨国际服务协会 Snap mobile payment device, method and system
US10586227B2 (en) 2011-02-16 2020-03-10 Visa International Service Association Snap mobile payment apparatuses, methods and systems
BR112013021057A2 (en) 2011-02-22 2020-11-10 Visa International Service Association universal electronic payment devices, methods and systems
AU2012223415B2 (en) 2011-02-28 2017-05-18 Visa International Service Association Secure anonymous transaction apparatuses, methods and systems
WO2012122060A1 (en) 2011-03-04 2012-09-13 Visa International Service Association Cloud service facilitator apparatuses, methods and systems
US20120278156A1 (en) * 2011-04-26 2012-11-01 International Business Machines Corporation Optimal Trading in Online Loyalty Point Exchanges
US9646291B2 (en) 2011-05-11 2017-05-09 Visa International Service Association Electronic receipt manager apparatuses, methods and systems
CN103797500A (en) 2011-06-03 2014-05-14 维萨国际服务协会 Virtual wallet card selection apparatuses, methods and systems
US9355393B2 (en) 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US9582598B2 (en) 2011-07-05 2017-02-28 Visa International Service Association Hybrid applications utilizing distributed models and views apparatuses, methods and systems
US10121129B2 (en) 2011-07-05 2018-11-06 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
US20130013478A1 (en) * 2011-07-08 2013-01-10 Jonathan Broadbent System and method for incentivizing retirement savings
US10438176B2 (en) 2011-07-17 2019-10-08 Visa International Service Association Multiple merchant payment processor platform apparatuses, methods and systems
US10242358B2 (en) 2011-08-18 2019-03-26 Visa International Service Association Remote decoupled application persistent state apparatuses, methods and systems
US10825001B2 (en) 2011-08-18 2020-11-03 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US10318941B2 (en) 2011-12-13 2019-06-11 Visa International Service Association Payment platform interface widget generation apparatuses, methods and systems
US9710807B2 (en) 2011-08-18 2017-07-18 Visa International Service Association Third-party value added wallet features and interfaces apparatuses, methods and systems
US9117225B2 (en) 2011-09-16 2015-08-25 Visa International Service Association Apparatuses, methods and systems for transforming user infrastructure requests inputs to infrastructure design product and infrastructure allocation outputs
US8768834B2 (en) 2011-09-20 2014-07-01 E2Interactive, Inc. Digital exchange and mobile wallet for digital currency
US10223730B2 (en) 2011-09-23 2019-03-05 Visa International Service Association E-wallet store injection search apparatuses, methods and systems
US20130124293A1 (en) * 2011-11-15 2013-05-16 Hartford Fire Insurance Company System and method for administration of loyalty program
US20130124294A1 (en) * 2011-11-15 2013-05-16 Hartford Fire Insurance Company System and method for managing loyalty program
US9953378B2 (en) 2012-04-27 2018-04-24 Visa International Service Association Social checkout widget generation and integration apparatuses, methods and systems
WO2013090611A2 (en) 2011-12-13 2013-06-20 Visa International Service Association Dynamic widget generator apparatuses, methods and systems
US10223710B2 (en) 2013-01-04 2019-03-05 Visa International Service Association Wearable intelligent vision device apparatuses, methods and systems
US10262148B2 (en) 2012-01-09 2019-04-16 Visa International Service Association Secure dynamic page content and layouts apparatuses, methods and systems
US11308227B2 (en) 2012-01-09 2022-04-19 Visa International Service Association Secure dynamic page content and layouts apparatuses, methods and systems
AU2013214801B2 (en) 2012-02-02 2018-06-21 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems
US9898733B1 (en) 2012-05-04 2018-02-20 Excentus Corporation System and method for combining disparate commercial transactions under a single identification mechanism
US20130304620A1 (en) * 2012-05-09 2013-11-14 Plastic Jungle, Inc. Using a value-ascertainable item to obtain credit at a third-party merchant
US9508096B2 (en) 2013-03-08 2016-11-29 Orbis Patents Limited Method and system for creating and processing personalized gift cards
US11216468B2 (en) 2015-02-08 2022-01-04 Visa International Service Association Converged merchant processing apparatuses, methods and systems
US11354698B1 (en) 2021-03-03 2022-06-07 The Toronto-Dominion Bank System and method for offsetting cost of a booking for a non-contributing member using loyalty points of a group of contributing members

Citations (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4321672A (en) * 1979-11-26 1982-03-23 Braun Edward L Financial data processing system
US4700055A (en) * 1985-10-15 1987-10-13 Kashkashian Jr Arsen Multiple credit card system
US4837422A (en) * 1987-09-08 1989-06-06 Juergen Dethloff Multi-user card system
US4900903A (en) * 1986-11-26 1990-02-13 Wright Technologies, L.P. Automated transaction system with insertable cards for transferring account data
US5025372A (en) * 1987-09-17 1991-06-18 Meridian Enterprises, Inc. System and method for administration of incentive award program through use of credit
US5155342A (en) * 1989-07-13 1992-10-13 Brother Kogyo Kabushiki Kaisha Prepaid card processing device
US5231569A (en) * 1990-06-12 1993-07-27 Sears Payment Systems, Inc. Account transaction system
US5483444A (en) * 1993-10-26 1996-01-09 Radisson Hotels International, Inc. System for awarding credits to persons who book travel-related reservations
US5483445A (en) * 1992-10-22 1996-01-09 American Express Trs Automated billing consolidation system and method
US5500513A (en) * 1994-05-11 1996-03-19 Visa International Automated purchasing control system
US5513102A (en) * 1994-06-28 1996-04-30 Auriemma Consulting Group, Inc. Data processing methods of implementing an award to an authorized user of a credit card
US5530232A (en) * 1993-12-22 1996-06-25 Datamark Services, Inc. Multi-application data card
US5537314A (en) * 1994-04-18 1996-07-16 First Marketrust Intl. Referral recognition system for an incentive award program
US5613012A (en) * 1994-11-28 1997-03-18 Smarttouch, Llc. Tokenless identification system for authorization of electronic transactions and electronic transmissions
US5614703A (en) * 1995-01-05 1997-03-25 Martin; Jay R. Hotel check-in system with wireless communication
US5615109A (en) * 1995-05-24 1997-03-25 Eder; Jeff Method of and system for generating feasible, profit maximizing requisition sets
US5621640A (en) * 1993-02-18 1997-04-15 Every Penny Counts, Inc. Automatic philanthropic contribution system
US5649117A (en) * 1994-06-03 1997-07-15 Midwest Payment Systems System and method for paying bills and other obligations including selective payor and payee controls
US5668993A (en) * 1994-02-28 1997-09-16 Teleflex Information Systems, Inc. Multithreaded batch processing system
US5770843A (en) * 1996-07-02 1998-06-23 Ncr Corporation Access card for multiple accounts
US5774870A (en) * 1995-12-14 1998-06-30 Netcentives, Inc. Fully integrated, on-line interactive frequency and award redemption program
US5819263A (en) * 1996-07-19 1998-10-06 American Express Financial Corporation Financial planning system incorporating relationship and group management
US5826243A (en) * 1994-01-03 1998-10-20 Merrill Lynch & Co., Inc. Integrated system for controlling master account and nested subaccount(s)
US5859419A (en) * 1995-09-28 1999-01-12 Sol H. Wynn Programmable multiple company credit card system
US5864830A (en) * 1997-02-13 1999-01-26 Armetta; David Data processing method of configuring and monitoring a satellite spending card linked to a host credit card
US5914472A (en) * 1997-09-23 1999-06-22 At&T Corp Credit card spending authorization control system
US5920847A (en) * 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system
US5937391A (en) * 1996-07-11 1999-08-10 Fujitsu Limited Point-service system in online shopping mall
US5953710A (en) * 1996-10-09 1999-09-14 Fleming; Stephen S. Children's credit or debit card system
US5970480A (en) * 1997-04-14 1999-10-19 Kalina; Dyan T. Centralized credit interchange system of converting purchase credit awards through credit exchange system for purchase of investment vehicle
US5978780A (en) * 1997-11-21 1999-11-02 Craig Michael Watson Integrated bill consolidation, payment aggregation, and settlement system
US5991736A (en) * 1997-02-26 1999-11-23 Ferguson; Henry Patronage incentive award system incorporating retirement accounts and method thereof
US5999596A (en) * 1998-03-06 1999-12-07 Walker Asset Management Limited Method and system for controlling authorization of credit card transactions
US6021943A (en) * 1996-10-09 2000-02-08 Chastain; Robert H. Process for executing payment transactions
US6044360A (en) * 1996-04-16 2000-03-28 Picciallo; Michael J. Third party credit card
US6049782A (en) * 1996-05-31 2000-04-11 Citibank, N.A. Relationship management system and process for pricing financial instruments based on a customer's relationship with a financial institution
US6061660A (en) * 1997-10-20 2000-05-09 York Eggleston System and method for incentive programs and award fulfillment
US6092055A (en) * 1997-05-14 2000-07-18 Portal Software, Inc. Method and apparatus for providing a clean accounting close for a real time billing system
US6105008A (en) * 1997-10-16 2000-08-15 Visa International Service Association Internet loading system using smart card
US6108641A (en) * 1994-01-03 2000-08-22 Merrill Lynch, Pierce, Fenner & Smith Integrated nested account financial system with medical savings subaccount
US6128599A (en) * 1997-10-09 2000-10-03 Walker Asset Management Limited Partnership Method and apparatus for processing customized group reward offers
US6128602A (en) * 1997-10-27 2000-10-03 Bank Of America Corporation Open-architecture system for real-time consolidation of information from multiple financial systems
US6128603A (en) * 1997-09-09 2000-10-03 Dent; Warren T. Consumer-based system and method for managing and paying electronic billing statements
US6260024B1 (en) * 1998-12-02 2001-07-10 Gary Shkedy Method and apparatus for facilitating buyer-driven purchase orders on a commercial network system
US6266623B1 (en) * 1994-11-21 2001-07-24 Phatrat Technology, Inc. Sport monitoring apparatus for determining loft time, speed, power absorbed and other factors such as height
US6273816B1 (en) * 1999-03-22 2001-08-14 At&T Corp Method and apparatus for rewarding groups of communication service users
US6289318B1 (en) * 1998-03-24 2001-09-11 Timothy P. Barber Method and architecture for multi-level commissioned advertising on a computer network
US6304860B1 (en) * 1997-10-03 2001-10-16 Joseph B. Martin, Jr. Automated debt payment system and method using ATM network
US6379247B1 (en) * 1997-07-07 2002-04-30 Walker Digital, Llc Method and system for awarding frequent flyer miles for casino table games
US6401079B1 (en) * 1999-10-01 2002-06-04 Inleague, Inc. System for web-based payroll and benefits administration
US20020123376A1 (en) * 1997-07-07 2002-09-05 Walker Jay S. System and method for providing reward points for casino play
US6549912B1 (en) * 1998-09-23 2003-04-15 Visa International Service Association Loyalty file structure for smart card
US20030074311A1 (en) * 2001-10-16 2003-04-17 Newattitude Inc. Self-administered automatic payroll deduction
US20030149660A1 (en) * 2002-02-05 2003-08-07 Talx Corporation Method and system for managing employee access to payroll information
US6607136B1 (en) * 1998-09-16 2003-08-19 Beepcard Inc. Physical presence digital authentication system
US6764013B2 (en) * 2002-04-17 2004-07-20 American Eps, Inc. Multi-purpose terminal, payroll and work management system and related methods
US6826243B1 (en) * 1998-10-29 2004-11-30 Koninklijke Philips Electronics N.V. Circuit arrangement for the processing of binary signals
US6925441B1 (en) * 1997-10-27 2005-08-02 Marketswitch Corp. System and method of targeted marketing
US6985867B1 (en) * 1997-01-29 2006-01-10 Sandia Corporation Method of predicting a change in an economy
US7225155B1 (en) * 1997-09-30 2007-05-29 Acs State & Local Solutions, Inc. Method and apparatus for payment processing using debit-based electronic funds transfer and disbursement processing using addendum-based electronic data interchange
US7305347B1 (en) * 1998-09-09 2007-12-04 Raymond Anthony Joao Apparatus and method for providing employee benefits and /or employee benefits information
US7340423B1 (en) * 1998-04-24 2008-03-04 First Data Corporation Method for defining a relationship between an account and a group

Family Cites Families (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US599624A (en) * 1898-02-22 Dotjgall
US138107A (en) * 1873-04-22 Improvement in buttons
FR2386080A1 (en) * 1977-03-31 1978-10-27 Cii Honeywell Bull ACCOUNTING SYSTEM FOR PREDETERMINED HOMOGENEOUS UNITS
US4679191A (en) * 1983-05-04 1987-07-07 Cxc Corporation Variable bandwidth switching system
US4816653A (en) * 1986-05-16 1989-03-28 American Telephone And Telegraph Company Security file system for a portable data carrier
US5644727A (en) 1987-04-15 1997-07-01 Proprietary Financial Products, Inc. System for the operation and management of one or more financial accounts through the use of a digital communication and computation system for exchange, investment and borrowing
US5852811A (en) 1987-04-15 1998-12-22 Proprietary Financial Products, Inc. Method for managing financial accounts by a preferred allocation of funds among accounts
US4918602A (en) * 1987-07-15 1990-04-17 Computer Associates International, Inc. Data processing system and method
US5121945A (en) * 1988-04-20 1992-06-16 Remittance Technology Corporation Financial data processing system
US5485370A (en) 1988-05-05 1996-01-16 Transaction Technology, Inc. Home services delivery system with intelligent terminal emulator
US5339392A (en) * 1989-07-27 1994-08-16 Risberg Jeffrey S Apparatus and method for creation of a user definable video displayed document showing changes in real time data
US5191522A (en) * 1990-01-18 1993-03-02 Itt Corporation Integrated group insurance information processing and reporting system based upon an enterprise-wide data structure
JP2691081B2 (en) 1990-05-16 1997-12-17 インターナショナル・ビジネス・マシーンズ・コーポレイション Computer network
AU656542B2 (en) 1990-10-01 1995-02-09 Thomas A. Bush Transactional processing system
US5783808A (en) * 1996-01-11 1998-07-21 J. D. Carreker And Associates, Inc. Electronic check presentment system having transaction level reconciliation capability
US5383113A (en) 1991-07-25 1995-01-17 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans
CA2076433C (en) 1991-10-31 1998-08-18 Brenda B. Amarant Monitoring of charges debited to an account having an assigned limit
US6009415A (en) 1991-12-16 1999-12-28 The Harrison Company, Llc Data processing technique for scoring bank customer relationships and awarding incentive rewards
US5940811A (en) * 1993-08-27 1999-08-17 Affinity Technology Group, Inc. Closed loop financial transaction method and apparatus
US5649118A (en) * 1993-08-27 1997-07-15 Lucent Technologies Inc. Smart card with multiple charge accounts and product item tables designating the account to debit
US5465206B1 (en) 1993-11-01 1998-04-21 Visa Int Service Ass Electronic bill pay system
US5560005A (en) * 1994-02-25 1996-09-24 Actamed Corp. Methods and systems for object-based relational distributed databases
US5457305A (en) 1994-03-31 1995-10-10 Akel; William S. Distributed on-line money access card transaction processing system
US5590038A (en) 1994-06-20 1996-12-31 Pitroda; Satyan G. Universal electronic transaction card including receipt storage and system and methods of conducting electronic transactions
EP0690399A3 (en) 1994-06-30 1997-05-02 Tandem Computers Inc Remote financial transaction system
JPH08214281A (en) 1995-02-06 1996-08-20 Sony Corp Charging method and system
US5650604A (en) * 1995-02-22 1997-07-22 Electronic Data Systems Corporation System and method for electronic transfer of funds using an automated teller machine to dispense the transferred funds
US5546523A (en) * 1995-04-13 1996-08-13 Gatto; James G. Electronic fund transfer system
US5866889A (en) 1995-06-07 1999-02-02 Citibank, N.A. Integrated full service consumer banking system and system and method for opening an account
US5648906A (en) * 1995-07-31 1997-07-15 Amirpanahi; Fardosht Networked computerized parking system of networked computerized parking meters and a method of operating said system
US5802511A (en) * 1996-01-02 1998-09-01 Timeline, Inc. Data retrieval method and apparatus with multiple source capability
US6138107A (en) 1996-01-04 2000-10-24 Netscape Communications Corporation Method and apparatus for providing electronic accounts over a public network
CA2254944A1 (en) * 1996-05-23 1997-11-27 Citibank, N.A. Global financial services integration system and process
US6332126B1 (en) 1996-08-01 2001-12-18 First Data Corporation System and method for a targeted payment system discount program
US5903830A (en) 1996-08-08 1999-05-11 Joao; Raymond Anthony Transaction security apparatus and method
US6119109A (en) * 1996-09-30 2000-09-12 Digital Vision Laboratories Corporation Information distribution system and billing system used for the information distribution system
US6311170B1 (en) 1996-12-04 2001-10-30 Mark C. Embrey Method and apparatus for making payments and delivering payment information
US6012048A (en) * 1997-05-30 2000-01-04 Capital Security Systems, Inc. Automated banking system for dispensing money orders, wire transfer and bill payment
US5897625A (en) 1997-05-30 1999-04-27 Capital Security Systems, Inc. Automated document cashing system
US5949044A (en) 1997-06-13 1999-09-07 Walker Asset Management Limited Partnership Method and apparatus for funds and credit line transfers
JP2861986B2 (en) * 1997-06-20 1999-02-24 日本電気株式会社 Data processing device, data transmitting device, data receiving device, data communication system, data processing method, information storage medium
US6292789B1 (en) 1997-08-26 2001-09-18 Citibank, N.A. Method and system for bill presentment and payment
US6018718A (en) 1997-08-28 2000-01-25 Walker Asset Management Limited Partnership Method and system for processing customized reward offers
US5984180A (en) 1997-10-06 1999-11-16 Albrecht; Jerry L. Method and system for gift credit card
US6021397A (en) 1997-12-02 2000-02-01 Financial Engines, Inc. Financial advisory system
US5943656A (en) * 1997-12-03 1999-08-24 Avista Advantage, Inc. Methods and systems for computerized bill consolidating, billing and payment authorization, computerized utility bill consolidating, utility billing access and payment and utility provider consolidated billing systems
US5930773A (en) 1997-12-17 1999-07-27 Avista Advantage, Inc. Computerized resource accounting methods and systems, computerized utility management methods and systems, multi-user utility management methods and systems, and energy-consumption-based tracking methods and systems
US6226364B1 (en) 1997-12-08 2001-05-01 Bellsouth Intellectual Property Management Corporation Method and system for providing prepaid and credit-limited telephone services
US6327577B1 (en) 1997-12-19 2001-12-04 Checkfree Services Corporation Electronic bill payment system with account-number scheming
US6081790A (en) 1998-03-20 2000-06-27 Citibank, N.A. System and method for secure presentment and payment over open networks
US6636833B1 (en) 1998-03-25 2003-10-21 Obis Patents Ltd. Credit card system and method
US6422462B1 (en) * 1998-03-30 2002-07-23 Morris E. Cohen Apparatus and methods for improved credit cards and credit card transactions
US7076465B1 (en) 1998-04-24 2006-07-11 First Data Corporation Methods for processing a group of accounts corresponding to different products
US7050996B1 (en) * 1998-04-24 2006-05-23 First Data Corporation Method for linking accounts corresponding to different products together to create a group
US20020198806A1 (en) 1998-04-24 2002-12-26 First Data Corporation Systems and methods for accessing and modifying usage parameters associated with a financial transaction account
US20030171992A1 (en) 1999-04-23 2003-09-11 First Data Corporation System and methods for redeeming rewards associated with accounts
US6405181B2 (en) * 1998-11-03 2002-06-11 Nextcard, Inc. Method and apparatus for real time on line credit approval
US6324524B1 (en) 1998-11-03 2001-11-27 Nextcard, Inc. Method and apparatus for an account level offer of credit and real time balance transfer
US6032136A (en) * 1998-11-17 2000-02-29 First Usa Bank, N.A. Customer activated multi-value (CAM) card
US6327573B1 (en) 1998-12-31 2001-12-04 Walker Digital, Llc Multiple party reward system utilizing single account
US20030212620A1 (en) 1999-04-23 2003-11-13 First Data Corporation Systems and methods for authorizing transactions
AU2597200A (en) * 1999-04-23 2000-11-10 First Data Resources, Inc. Methods for processing a group of accounts corresponding to different products
EP1182627B1 (en) 1999-04-30 2011-12-07 Fujitsu Limited Automatic teller's machine
US6829588B1 (en) 1999-10-08 2004-12-07 First Data Corporation Electronic payroll system & method
WO2001042965A1 (en) 1999-12-10 2001-06-14 Auripay, Inc. Method and apparatus for improved financial instrument processing
US20020069122A1 (en) 2000-02-22 2002-06-06 Insun Yun Method and system for maximizing credit card purchasing power and minimizing interest costs over the internet
KR100390029B1 (en) 2000-02-29 2003-07-02 이수성 A settlement system, method and computer readable media thereof using electronic card through internet
US7627531B2 (en) 2000-03-07 2009-12-01 American Express Travel Related Services Company, Inc. System for facilitating a transaction
US20050154664A1 (en) 2000-08-22 2005-07-14 Guy Keith A. Credit and financial information and management system
WO2002023445A2 (en) 2000-09-11 2002-03-21 Mygroupbuy, Inc. Customizable group initiative
US7228292B2 (en) * 2000-11-16 2007-06-05 First Data Corporation Card-based system and method for issuing negotiable instruments
US7689502B2 (en) 2001-02-12 2010-03-30 Capital One Financial Corporation System and method for providing extra lines of credit
US20020123962A1 (en) * 2001-03-02 2002-09-05 Bryman Evan L. System and method for providing a reaffirmation credit card including an increasing credit limit
US20030083933A1 (en) * 2001-10-29 2003-05-01 Mcalear James A. Systems and methods for providing rewards benefits to account holders
US6779319B2 (en) * 2001-11-08 2004-08-24 First Data Corporation Real-time intelligent packet-collation systems and methods
US6802500B2 (en) 2001-11-08 2004-10-12 First Data Corporation Systems and methods of providing inserts into envelopes
US20030115160A1 (en) * 2001-12-19 2003-06-19 First Data Corporation Weight measuring systems and methods for weighing items
US6661217B2 (en) 2001-12-21 2003-12-09 Telefonaktiebolaget L.M. Ericsson Wideband precision current sensor
US6623415B2 (en) * 2001-12-21 2003-09-23 First Data Corporation Sheet folding systems and methods
US6920588B1 (en) * 2002-04-08 2005-07-19 Sanera Systems Inc. Transmitting data in a communication network
US7571140B2 (en) * 2002-12-16 2009-08-04 First Data Corporation Payment management
US7490059B2 (en) * 2003-01-27 2009-02-10 First Data Corporation Methods and systems for consolidating financial reporting information

Patent Citations (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4321672A (en) * 1979-11-26 1982-03-23 Braun Edward L Financial data processing system
US4700055A (en) * 1985-10-15 1987-10-13 Kashkashian Jr Arsen Multiple credit card system
US4900903A (en) * 1986-11-26 1990-02-13 Wright Technologies, L.P. Automated transaction system with insertable cards for transferring account data
US4837422A (en) * 1987-09-08 1989-06-06 Juergen Dethloff Multi-user card system
US5025372A (en) * 1987-09-17 1991-06-18 Meridian Enterprises, Inc. System and method for administration of incentive award program through use of credit
US5155342A (en) * 1989-07-13 1992-10-13 Brother Kogyo Kabushiki Kaisha Prepaid card processing device
US5231569A (en) * 1990-06-12 1993-07-27 Sears Payment Systems, Inc. Account transaction system
US5483445A (en) * 1992-10-22 1996-01-09 American Express Trs Automated billing consolidation system and method
US5684965A (en) * 1992-10-22 1997-11-04 American Express Travel Related Services, Inc. Automated billing consolidation system and method
US5621640A (en) * 1993-02-18 1997-04-15 Every Penny Counts, Inc. Automatic philanthropic contribution system
US5483444A (en) * 1993-10-26 1996-01-09 Radisson Hotels International, Inc. System for awarding credits to persons who book travel-related reservations
US5920847A (en) * 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system
US5530232A (en) * 1993-12-22 1996-06-25 Datamark Services, Inc. Multi-application data card
US6108641A (en) * 1994-01-03 2000-08-22 Merrill Lynch, Pierce, Fenner & Smith Integrated nested account financial system with medical savings subaccount
US5826243A (en) * 1994-01-03 1998-10-20 Merrill Lynch & Co., Inc. Integrated system for controlling master account and nested subaccount(s)
US5668993A (en) * 1994-02-28 1997-09-16 Teleflex Information Systems, Inc. Multithreaded batch processing system
US5537314A (en) * 1994-04-18 1996-07-16 First Marketrust Intl. Referral recognition system for an incentive award program
US5500513A (en) * 1994-05-11 1996-03-19 Visa International Automated purchasing control system
US5649117A (en) * 1994-06-03 1997-07-15 Midwest Payment Systems System and method for paying bills and other obligations including selective payor and payee controls
US5513102A (en) * 1994-06-28 1996-04-30 Auriemma Consulting Group, Inc. Data processing methods of implementing an award to an authorized user of a credit card
US6266623B1 (en) * 1994-11-21 2001-07-24 Phatrat Technology, Inc. Sport monitoring apparatus for determining loft time, speed, power absorbed and other factors such as height
US5613012A (en) * 1994-11-28 1997-03-18 Smarttouch, Llc. Tokenless identification system for authorization of electronic transactions and electronic transmissions
US5614703A (en) * 1995-01-05 1997-03-25 Martin; Jay R. Hotel check-in system with wireless communication
US5615109A (en) * 1995-05-24 1997-03-25 Eder; Jeff Method of and system for generating feasible, profit maximizing requisition sets
US5859419A (en) * 1995-09-28 1999-01-12 Sol H. Wynn Programmable multiple company credit card system
US5774870A (en) * 1995-12-14 1998-06-30 Netcentives, Inc. Fully integrated, on-line interactive frequency and award redemption program
US6044360A (en) * 1996-04-16 2000-03-28 Picciallo; Michael J. Third party credit card
US6049782A (en) * 1996-05-31 2000-04-11 Citibank, N.A. Relationship management system and process for pricing financial instruments based on a customer's relationship with a financial institution
US5770843A (en) * 1996-07-02 1998-06-23 Ncr Corporation Access card for multiple accounts
US5937391A (en) * 1996-07-11 1999-08-10 Fujitsu Limited Point-service system in online shopping mall
US5819263A (en) * 1996-07-19 1998-10-06 American Express Financial Corporation Financial planning system incorporating relationship and group management
US5953710A (en) * 1996-10-09 1999-09-14 Fleming; Stephen S. Children's credit or debit card system
US6021943A (en) * 1996-10-09 2000-02-08 Chastain; Robert H. Process for executing payment transactions
US6985867B1 (en) * 1997-01-29 2006-01-10 Sandia Corporation Method of predicting a change in an economy
US5864830A (en) * 1997-02-13 1999-01-26 Armetta; David Data processing method of configuring and monitoring a satellite spending card linked to a host credit card
US5991736A (en) * 1997-02-26 1999-11-23 Ferguson; Henry Patronage incentive award system incorporating retirement accounts and method thereof
US5970480A (en) * 1997-04-14 1999-10-19 Kalina; Dyan T. Centralized credit interchange system of converting purchase credit awards through credit exchange system for purchase of investment vehicle
US6092055A (en) * 1997-05-14 2000-07-18 Portal Software, Inc. Method and apparatus for providing a clean accounting close for a real time billing system
US6379247B1 (en) * 1997-07-07 2002-04-30 Walker Digital, Llc Method and system for awarding frequent flyer miles for casino table games
US20020123376A1 (en) * 1997-07-07 2002-09-05 Walker Jay S. System and method for providing reward points for casino play
US6128603A (en) * 1997-09-09 2000-10-03 Dent; Warren T. Consumer-based system and method for managing and paying electronic billing statements
US5914472A (en) * 1997-09-23 1999-06-22 At&T Corp Credit card spending authorization control system
US7225155B1 (en) * 1997-09-30 2007-05-29 Acs State & Local Solutions, Inc. Method and apparatus for payment processing using debit-based electronic funds transfer and disbursement processing using addendum-based electronic data interchange
US6304860B1 (en) * 1997-10-03 2001-10-16 Joseph B. Martin, Jr. Automated debt payment system and method using ATM network
US6128599A (en) * 1997-10-09 2000-10-03 Walker Asset Management Limited Partnership Method and apparatus for processing customized group reward offers
US6105008A (en) * 1997-10-16 2000-08-15 Visa International Service Association Internet loading system using smart card
US6061660A (en) * 1997-10-20 2000-05-09 York Eggleston System and method for incentive programs and award fulfillment
US6128602A (en) * 1997-10-27 2000-10-03 Bank Of America Corporation Open-architecture system for real-time consolidation of information from multiple financial systems
US6925441B1 (en) * 1997-10-27 2005-08-02 Marketswitch Corp. System and method of targeted marketing
US5978780A (en) * 1997-11-21 1999-11-02 Craig Michael Watson Integrated bill consolidation, payment aggregation, and settlement system
US5999596A (en) * 1998-03-06 1999-12-07 Walker Asset Management Limited Method and system for controlling authorization of credit card transactions
US6289318B1 (en) * 1998-03-24 2001-09-11 Timothy P. Barber Method and architecture for multi-level commissioned advertising on a computer network
US7340423B1 (en) * 1998-04-24 2008-03-04 First Data Corporation Method for defining a relationship between an account and a group
US7305347B1 (en) * 1998-09-09 2007-12-04 Raymond Anthony Joao Apparatus and method for providing employee benefits and /or employee benefits information
US6607136B1 (en) * 1998-09-16 2003-08-19 Beepcard Inc. Physical presence digital authentication system
US6549912B1 (en) * 1998-09-23 2003-04-15 Visa International Service Association Loyalty file structure for smart card
US6826243B1 (en) * 1998-10-29 2004-11-30 Koninklijke Philips Electronics N.V. Circuit arrangement for the processing of binary signals
US6260024B1 (en) * 1998-12-02 2001-07-10 Gary Shkedy Method and apparatus for facilitating buyer-driven purchase orders on a commercial network system
US6273816B1 (en) * 1999-03-22 2001-08-14 At&T Corp Method and apparatus for rewarding groups of communication service users
US6401079B1 (en) * 1999-10-01 2002-06-04 Inleague, Inc. System for web-based payroll and benefits administration
US20030074311A1 (en) * 2001-10-16 2003-04-17 Newattitude Inc. Self-administered automatic payroll deduction
US20030149660A1 (en) * 2002-02-05 2003-08-07 Talx Corporation Method and system for managing employee access to payroll information
US6764013B2 (en) * 2002-04-17 2004-07-20 American Eps, Inc. Multi-purpose terminal, payroll and work management system and related methods

Cited By (136)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080097856A1 (en) * 1998-04-24 2008-04-24 First Data Corporation Systems and methods for redeeming rewards associated with accounts
US8073736B2 (en) 1998-04-24 2011-12-06 First Data Corporation Systems and methods for redeeming rewards associated with accounts
US7712658B2 (en) 1998-05-29 2010-05-11 E-Micro Corporation Wallet consolidator and related methods of processing a transaction using a wallet consolidator
US8225995B1 (en) 1998-05-29 2012-07-24 Frank Joseph Gangi Retail point-of-transaction system, program products, and related methods to provide a customized set of identification data to facilitate a transaction using electronic coupons
US8261978B2 (en) 1998-05-29 2012-09-11 E-Micro Corporation Wallet consolidator to facilitate a transaction
US7708198B2 (en) 1998-05-29 2010-05-04 E-Micro Corporation Wallet consolidator to facilitate a transaction
US7828208B2 (en) 1998-05-29 2010-11-09 E-Micro Corporation Retail point-of-transaction system, program products, and related methods to provide a customized set of identification data to facilitate a transaction using electronic coupons
US20030120571A1 (en) * 1999-04-23 2003-06-26 First Data Corporation Authorizing transactions associated with accounts
US20030182218A1 (en) * 1999-04-23 2003-09-25 First Data Corporation Chasing rewards associated with accounts
US8606631B2 (en) 1999-04-23 2013-12-10 First Data Corporation Chasing rewards associated with accounts
US20070055628A1 (en) * 1999-04-23 2007-03-08 First Data Corporation Authorizing transactions associated with accounts
US11423400B1 (en) * 1999-06-18 2022-08-23 Stripe, Inc. Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account
US9864990B2 (en) * 1999-06-18 2018-01-09 Cria Inc. Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account
US9864989B2 (en) * 1999-06-18 2018-01-09 Cria Inc. Method and apparatus for ordering goods, services, and content over an internetwork using a virtual payment account
US20080016003A1 (en) * 1999-06-18 2008-01-17 Echarge Corporation Method and apparatus for ordering goods, services, and content over an internetwork using a virtual payment account
US11551211B1 (en) * 1999-06-18 2023-01-10 Stripe, Inc. Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account
US20110137801A1 (en) * 1999-06-18 2011-06-09 Echarge Corporation Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account
US20140052628A1 (en) * 1999-06-23 2014-02-20 Signature Systems Llc Portable hand-held multifunction device with multiple transaction accounts
US7873574B1 (en) 1999-06-23 2011-01-18 Signature Systems Llc Method and system for using reward points to liquidate products
US20120271703A1 (en) * 1999-06-23 2012-10-25 Richard Postrel Portable hand-held multi-function device for storing, managing and combining rewards
US8781891B2 (en) * 1999-06-23 2014-07-15 Signature Systems Llc Portable multifunction device with multiple applications
US8712840B2 (en) * 1999-06-23 2014-04-29 Signature Systems, LLC. Portable hand-held multi-function device for storing, managing and combining rewards
US20070130011A1 (en) * 1999-06-23 2007-06-07 Signature Systems Llc System for electronic barter, trading and redeeming points accumulated in frequent use reward programs
US8452647B2 (en) * 1999-06-23 2013-05-28 Signature Systems Llc Portable hand-held multi-function device for storing, managing and combining rewards
US7680687B2 (en) * 1999-06-23 2010-03-16 Signature Systems Llc Method and system for reward points exchange between accounts
US7676393B2 (en) * 1999-06-23 2010-03-09 Signature Systems Llc Method and system for rewards accumulation and redemption
US20130282469A1 (en) * 1999-06-23 2013-10-24 Signature Systems Llc Portable hand-held multi-function device for storing, managing and combining rewards
US7624040B2 (en) * 1999-06-23 2009-11-24 Signature Systems Llc System for electronic barter, trading and redeeming points accumulated in frequent use reward programs
US7624041B2 (en) * 1999-06-23 2009-11-24 Signature Systems Llc System for electronic barter, trading and redeeming points accumulated in frequent use reward programs
US8793160B2 (en) 1999-12-07 2014-07-29 Steve Sorem System and method for processing transactions
US7083087B1 (en) 2000-09-18 2006-08-01 E-Micro Corporation Method and apparatus for associating identification and personal data for multiple magnetic stripe cards or other sources
US8533031B2 (en) 2000-10-17 2013-09-10 Jpmorgan Chase Bank, N.A. Method and system for retaining customer loyalty
US7962391B2 (en) 2000-12-20 2011-06-14 Jpmorgan Chase Bank, N.A. System and method for determining elegibility and enrolling members in various programs
US8255307B1 (en) 2001-03-01 2012-08-28 Jpmorgan Chase Bank, N.A. System and method for measuring and utilizing pooling analytics
US8577770B2 (en) 2001-03-01 2013-11-05 Jpmorgan Chase, N.A. System and method for measuring and utilizing pooling analytics
US7895098B2 (en) 2001-03-01 2011-02-22 Jpmorgan Chase Bank, N.A. System and method for measuring and utilizing pooling analytics
US8849716B1 (en) 2001-04-20 2014-09-30 Jpmorgan Chase Bank, N.A. System and method for preventing identity theft or misuse by restricting access
US10380374B2 (en) 2001-04-20 2019-08-13 Jpmorgan Chase Bank, N.A. System and method for preventing identity theft or misuse by restricting access
US8160960B1 (en) 2001-06-07 2012-04-17 Jpmorgan Chase Bank, N.A. System and method for rapid updating of credit information
US8185940B2 (en) 2001-07-12 2012-05-22 Jpmorgan Chase Bank, N.A. System and method for providing discriminated content to network users
US8020754B2 (en) 2001-08-13 2011-09-20 Jpmorgan Chase Bank, N.A. System and method for funding a collective account by use of an electronic tag
US8707410B2 (en) 2001-12-04 2014-04-22 Jpmorgan Chase Bank, N.A. System and method for single session sign-on
US7987501B2 (en) 2001-12-04 2011-07-26 Jpmorgan Chase Bank, N.A. System and method for single session sign-on
US20030115134A1 (en) * 2001-12-18 2003-06-19 Kimio Kikuchi Credit account integration method
US20030232281A1 (en) * 2002-02-20 2003-12-18 Fuji Photo Film Co., Ltd. Method for making lithographic printing plate
US8412623B2 (en) 2002-07-15 2013-04-02 Citicorp Credit Services, Inc. Method and system for a multi-purpose transactional platform
US20040010462A1 (en) * 2002-07-15 2004-01-15 Susan Moon Method and system for a multi-purpose transactional platform
US9818100B2 (en) 2002-07-15 2017-11-14 Citicorp Credit Services, Inc. (Usa) Method and system for a multi-purpose transactional platform
US20040019543A1 (en) * 2002-07-25 2004-01-29 First Data Corporation Systems and methods for non-account based liability reporting
US20040049452A1 (en) * 2002-09-09 2004-03-11 First Data Corporation Multiple credit line presentation instrument
US8301493B2 (en) 2002-11-05 2012-10-30 Jpmorgan Chase Bank, N.A. System and method for providing incentives to consumers to share information
US8521645B2 (en) * 2003-04-29 2013-08-27 Visa U.S.A. Inc. Method and system for facilitating switching of financial institution accounts
US20050021456A1 (en) * 2003-04-29 2005-01-27 Visa U.S.A. Method and system for facilitating switching of financial institution accounts
US20100280942A1 (en) * 2003-04-29 2010-11-04 Tolan Doak Steele Method and system for facilitating switching of financial institution accounts
US7742986B2 (en) * 2003-04-29 2010-06-22 Visa U.S.A. Inc. Method and system for facilitating switching of financial institution accounts
US7870069B2 (en) * 2003-04-29 2011-01-11 Visa U.S.A. Inc. Method and system for facilitating switching of financial institution accounts
US20110078075A1 (en) * 2003-04-29 2011-03-31 Tolan Doak Steele Method and system for facilitating switching of financial institution accounts
US8306907B2 (en) 2003-05-30 2012-11-06 Jpmorgan Chase Bank N.A. System and method for offering risk-based interest rates in a credit instrument
US8145549B2 (en) 2003-05-30 2012-03-27 Jpmorgan Chase Bank, N.A. System and method for offering risk-based interest rates in a credit instutment
US8175908B1 (en) 2003-09-04 2012-05-08 Jpmorgan Chase Bank, N.A. Systems and methods for constructing and utilizing a merchant database derived from customer purchase transactions data
US7949594B2 (en) 2003-09-26 2011-05-24 First Data Corporation Systems and methods for participant controlled communications regarding financial accounts
US20050080691A1 (en) * 2003-09-26 2005-04-14 First Data Corporation Systems and methods for participant controlled communications regarding financial accounts
US8015085B2 (en) 2003-11-14 2011-09-06 First Data Corporation System for distributing funds
US20050192862A1 (en) * 2004-02-27 2005-09-01 Capital One Financial Corporation Methods, systems, and articles of manufacture for providing incentives for a financial account
US20110010238A1 (en) * 2004-03-01 2011-01-13 Richard Postrel Method and system for issuing, aggregating and redeeming merchant rewards
US20050240601A1 (en) * 2004-04-21 2005-10-27 Mairead Lyons System and method for transactional data collection and processing
US8447672B2 (en) 2005-05-27 2013-05-21 Jp Morgan Chase Bank, N.A. Universal payment protection
US8473395B1 (en) 2005-05-27 2013-06-25 Jpmorgan Chase Bank, Na Universal payment protection
US8447670B1 (en) 2005-05-27 2013-05-21 Jp Morgan Chase Bank, N.A. Universal payment protection
US8700523B2 (en) * 2005-06-10 2014-04-15 American Express Travel Related Services Company, Inc. System and method for delegating management of a financial transaction account to a designated assistant
US20060282377A1 (en) * 2005-06-10 2006-12-14 American Express Marketing & Development Corp., a New York Corporation System and method for delegating management of a financial transaction account to a designated assistant
US11132708B2 (en) 2005-09-20 2021-09-28 Capital One Services, Llc System and method for redeeming a reward
US10242382B1 (en) * 2005-09-20 2019-03-26 Capital One Services, Llc System and method for redeeming a reward
US11861658B2 (en) 2005-09-20 2024-01-02 Capital One Services, Llc System and method for redeeming a reward
US20070198338A1 (en) * 2006-02-21 2007-08-23 First Data Corporation Customer selected coalition systems and methods
US20070233558A1 (en) * 2006-04-03 2007-10-04 Jones Kenneth A Mobile trading card redemption
US20080082420A1 (en) * 2006-10-03 2008-04-03 Kargman James B Method for Dynamic Group Formation and Purchasing
US8510160B1 (en) 2006-12-21 2013-08-13 Capital One Financial Corporation System and method for providing a reward
US7933835B2 (en) 2007-01-17 2011-04-26 The Western Union Company Secure money transfer systems and methods using biometric keys associated therewith
US9123044B2 (en) 2007-01-17 2015-09-01 The Western Union Company Generation systems and methods for transaction identifiers having biometric keys associated therewith
US20100086880A1 (en) * 2007-01-17 2010-04-08 Sony Corporation Developing solution and method for production of finely patterned material
US8818904B2 (en) 2007-01-17 2014-08-26 The Western Union Company Generation systems and methods for transaction identifiers having biometric keys associated therewith
US20080177672A1 (en) * 2007-01-23 2008-07-24 Robert Brunner Method for managing liability
US20080182724A1 (en) * 2007-01-25 2008-07-31 Nicole Lee Guthrie Activity Monitor with Incentive Features
US8504473B2 (en) 2007-03-28 2013-08-06 The Western Union Company Money transfer system and messaging system
US10311410B2 (en) 2007-03-28 2019-06-04 The Western Union Company Money transfer system and messaging system
US8762267B2 (en) 2007-03-28 2014-06-24 The Western Union Company Money transfer system and messaging system
US20080288396A1 (en) * 2007-05-16 2008-11-20 Jpmorgan Chase Bank, N.A. System and Method For Combined Reconciliation Of Co-Branded Card Promotion And Settlement Of Private Label Card Accounts
US7953653B2 (en) 2007-05-16 2011-05-31 Jpmorgan Chase Bank, N.A. System and method for combined reconciliation of co-branded card promotion and settlement of private label card accounts
US20100332382A1 (en) * 2007-06-04 2010-12-30 Monk Justin T Portability of financial tokens
US20080307094A1 (en) * 2007-06-11 2008-12-11 Olli Karonen Association of peer-to-peer contribution credits with multiple devices
US20090055271A1 (en) * 2007-08-23 2009-02-26 Accenture Global Services Gmbh Travel reward accrual
WO2009026585A1 (en) * 2007-08-23 2009-02-26 Accenture Global Services Gmbh Travel reward accrual
US8027873B2 (en) * 2007-08-23 2011-09-27 Accenture Global Services Limited Travel reward accrual
US8504450B2 (en) * 2007-08-31 2013-08-06 Ebay Inc. Mobile remittances/payments
US20090061831A1 (en) * 2007-08-31 2009-03-05 Vishwanath Shastry Mobile remittances/payments
US8622308B1 (en) 2007-12-31 2014-01-07 Jpmorgan Chase Bank, N.A. System and method for processing transactions using a multi-account transactions device
US8725611B1 (en) 2008-02-21 2014-05-13 Jpmorgan Chase Bank, N.A. System and method for providing borrowing schemes
US8706625B2 (en) 2008-02-21 2014-04-22 Jpmorgan Chase Bank, N.A. System and method for providing borrowing schemes
US8554652B1 (en) 2008-02-21 2013-10-08 Jpmorgan Chase Bank, N.A. System and method for providing borrowing schemes
US8538876B2 (en) 2008-02-21 2013-09-17 Jpmorgan Chase Bank, N.A. System and method for providing borrowing schemes
US8190522B1 (en) 2008-02-21 2012-05-29 Jpmorgan Chase Bank, N.A. System and method for providing borrowing schemes
US8078528B1 (en) 2008-02-21 2011-12-13 Jpmorgan Chase Bank, N.A. System and method for providing borrowing schemes
US20090248506A1 (en) * 2008-03-31 2009-10-01 Maritz Inc. Merchant funded rewards network implementing cardholder loyalty rebate program
US8615428B2 (en) 2009-01-14 2013-12-24 Signature Systems, LLC. Point of sale device for online reward point exchange method and system
US20100280896A1 (en) * 2009-01-14 2010-11-04 Signature Systems Llc Online reward point exchange method and system
US8407087B2 (en) 2009-01-14 2013-03-26 Signature Systems, LLC. Online reward point exchange method and system
US11004052B2 (en) * 2009-02-13 2021-05-11 Visa International Service Association Point of interaction loyalty currency redemption in a transaction
US11887093B2 (en) 2009-02-13 2024-01-30 Visa International Service Association Point of interaction loyalty currency redemption in a transaction
US10515427B1 (en) 2009-08-14 2019-12-24 Citicorp Credit Services, Inc. (Usa) Methods and systems for use of a prepaid payment device for a healthcare service or product
US11367155B1 (en) 2009-08-14 2022-06-21 Citicorp Credit Services, Inc. (Usa) Methods and systems for use of a prepaid payment device for a healthcare service or product
US10074081B1 (en) 2009-08-14 2018-09-11 Citicorp Credit Services, Inc. (Usa) Methods and systems for use of a prepaid payment device
US20110191159A1 (en) * 2010-02-02 2011-08-04 Heitman Lynn Savings and rewards program
US20110264489A1 (en) * 2010-04-23 2011-10-27 Ganz Dual-currency economy for a virtual social environment
US9111278B1 (en) 2010-07-02 2015-08-18 Jpmorgan Chase Bank, N.A. Method and system for determining point of sale authorization
US8554631B1 (en) 2010-07-02 2013-10-08 Jpmorgan Chase Bank, N.A. Method and system for determining point of sale authorization
US8510188B2 (en) * 2010-07-28 2013-08-13 The Western Union Company Receiver driven money transfer alert system
US20120030098A1 (en) * 2010-07-28 2012-02-02 The Western Union Company Receiver driven money transfer alert system
US10248964B1 (en) 2010-07-30 2019-04-02 American Express Travel Related Services Company, Inc. System and method for rewards redemption
US10373188B1 (en) * 2010-07-30 2019-08-06 American Express Travel Related Services Company, Inc. System and method for rewards redemption with a mobile device
US8768830B1 (en) 2011-09-08 2014-07-01 Citibank, N.A. Method and system for a multi-purpose transactional platform
US11093623B2 (en) 2011-12-09 2021-08-17 Sertainty Corporation System and methods for using cipher objects to protect data
US20130262291A1 (en) * 2012-03-15 2013-10-03 Flextronics Ap, Llc Universal credit card
US9898752B2 (en) * 2012-05-16 2018-02-20 Rakuten, Inc. Point system, method for controlling point system, point management device, program, and information storage medium
US20150134437A1 (en) * 2012-05-16 2015-05-14 Rakuten, Inc. Point system, method for controlling point system, point management device, program, and information storage medium
US20140279799A1 (en) * 2013-03-14 2014-09-18 Bank Of America Corporation Providing rewards buckets and savings towards specific goals
US9852438B2 (en) 2013-12-31 2017-12-26 Mastercard International Incorporated Systems and methods for peer-to-peer reward points transfer over mobile devices
US20150243175A1 (en) * 2014-02-25 2015-08-27 Kavita Raman Automated disciplinary and motivational system
US11386409B2 (en) 2016-03-04 2022-07-12 Sertintyone Corporation Systems and methods for media codecs and containers
US20170293930A1 (en) * 2016-04-06 2017-10-12 Mastercard International Incorporated Method and system for standalone real-time rewards
US20180060896A1 (en) * 2016-08-30 2018-03-01 Ncr Corporation Collateralized rewards
US10977898B2 (en) 2017-02-10 2021-04-13 Bank Of America Corporation Third party activity performance cross entity integration
US10672021B2 (en) 2017-02-10 2020-06-02 Bank Of America Corporation System and method for location-based trafficking for resource accumulation
US10607444B2 (en) 2017-02-10 2020-03-31 Bank Of America Corporation Third party activity performance cross entity integration
US20200043037A1 (en) * 2017-04-11 2020-02-06 Nomura Research Institute, Ltd. Point management system and point management program
US20190244203A1 (en) * 2018-02-05 2019-08-08 Capital One Services, Llc Real-time processing of requests related to facilitating use of an account

Also Published As

Publication number Publication date
US20080097856A1 (en) 2008-04-24
US20080091540A1 (en) 2008-04-17
US20080091582A1 (en) 2008-04-17
US8073736B2 (en) 2011-12-06

Similar Documents

Publication Publication Date Title
US8073736B2 (en) Systems and methods for redeeming rewards associated with accounts
US7050996B1 (en) Method for linking accounts corresponding to different products together to create a group
US7076465B1 (en) Methods for processing a group of accounts corresponding to different products
US8606631B2 (en) Chasing rewards associated with accounts
US7340423B1 (en) Method for defining a relationship between an account and a group
US20030212620A1 (en) Systems and methods for authorizing transactions
US8280809B2 (en) Linking a financial card with a merchant account
US6886741B1 (en) Electronic transaction system
US7424455B2 (en) Method and systems for providing merchant services with right-time creation and updating of merchant accounts
US7912774B2 (en) Transaction card system and approach
US8533111B1 (en) System and method for providing promotional pricing
US20020198806A1 (en) Systems and methods for accessing and modifying usage parameters associated with a financial transaction account
US20040243498A1 (en) Interest bearing gift card mechanisms
US20080177655A1 (en) Systems and methods of underwriting business credit
RU2639950C2 (en) Method and system for providing credit transactions and computer program related to them
US20200051108A1 (en) Paying a reward to a second account based on multiple account qualifications being met by a first account
US20070055628A1 (en) Authorizing transactions associated with accounts
CA2403172C (en) Method for linking accounts corresponding to different products together to create a group
WO2000065501A2 (en) Method for defining a relationship between an account and a group

Legal Events

Date Code Title Description
AS Assignment

Owner name: FIRST DATA CORPORATION, COLORADO

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BLAGG, LYNN HOLM;LINDSAY, CAROL A.;REEL/FRAME:013870/0025;SIGNING DATES FROM 20030227 TO 20030304

AS Assignment

Owner name: CREDIT SUISSE, CAYMAN ISLANDS BRANCH, AS COLLATERA

Free format text: SECURITY AGREEMENT;ASSIGNORS:FIRST DATA CORPORATION;CARDSERVICE INTERNATIONAL, INC.;FUNDSXPRESS, INC.;AND OTHERS;REEL/FRAME:020045/0165

Effective date: 20071019

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: DW HOLDINGS INC., COLORADO

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: TASQ TECHNOLOGY, INC., CALIFORNIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: CARDSERVICE INTERNATIONAL, INC., CALIFORNIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: INTELLIGENT RESULTS, INC., COLORADO

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: FIRST DATA RESOURCES, LLC, COLORADO

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: TELECHECK SERVICES, INC., TEXAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: LINKPOINT INTERNATIONAL, INC., CALIFORNIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: FUNDSXPRESS, INC., TEXAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: TELECHECK INTERNATIONAL, INC., TEXAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: FIRST DATA CORPORATION, COLORADO

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: SIZE TECHNOLOGIES, INC., COLORADO

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729