US20040030657A1

US20040030657A1 - Financial transaction account usage parameter access and control method

Info

Publication number: US20040030657A1
Application number: US10/025,092
Authority: US
Inventors: Lynn Holm-Blagg; Carol Lindsay; Eugene Kathol
Original assignee: First Data Resources LLC
Current assignee: First Data Corp; First Data Resources LLC
Priority date: 1999-04-23
Filing date: 2001-12-19
Publication date: 2004-02-12
Also published as: WO2000065502A8; US8606631B2; WO2000065502A2; AU2597200A; US20030182218A1; US20030135438A1; CA2403176A1; US20030120571A1; US20070203795A1; US20140172529A1

Abstract

A methodology for access, control and management of credit product usage parameters by an account holder. The methodology includes the steps of creating a credit/debit account and issuing a credit/debit card product for same. A group or family of accounts can optionally be created including a key account and one or more dependent accounts. An initially set of product usage parameters is established. The account holder access the product usage parameters through one of a number of alternative points of access. The account holder then modifies one or more of the product usage parameters and submits the same, optionally in real time. The submitted parameters are tested against allowable usage criteria implemented by the card processing and service provider or the card issuer, which can be based on applicable laws, rules and regulations. If the submitted usage parameter modifications are acceptable, same are implemented and control the product usage until further modified. In a group or family context the usage parameters can be specifically established for a key account and optionally, one or more dependent accounts. Optionally the dependent accounts in such a group can be provided with access, control and management over certain usage parameters.

Description

RELATED APPLICATIONS

This U.S. patent application relates to PCT Applications: PCT/US99/31203 filed on Dec. 30, 1999, published on Nov. 2, 2000; PCT/US99/31202, filed on Nov. 2, 2000; and PCT/US99/31315, filed on Dec. 30, 1999; and the U.S. patent applications related thereto. The disclosures of each of these documents, as well as the U.S. patent applications corresponding to these PCT applications, are entirely incorporated hereinto by reference. [0001]
This application is a continuation-in-part for U.S. application Ser. No. 09/298,417, entitled METHOD FOR PROCESSING A GROUP OF ACCOUNTS CORRESPONDING TO DIFFERENT PRODUCTS, filed Apr. 23, 1999.[0002]

BACKGROUND OF THE INVENTION

Financial transaction card products, i.e. credit and debit cards, are very popular for conducting a wide range of consumer and business transactions involving payments for various goods and services. They offer significant advantages over other payment methods, such as cash and checks. These advantages include convenience, security and acceptability to providers of goods and services. Another advantage is that such transactional cards can be used remotely, i.e. by telephone or by global computer network (“internet”), as well as at points-of-sale.

Multiple account/product relationships with a single issuer are common. They can accommodate the needs of individual account holders who use different products for different purposes. A typical example involves business and personal accounts with a single issuer. With this arrangement the account holder can separate business and personal purchases for record keeping and tax reporting purposes. Card issuers tend to foster relationships with their preferred customers by encouraging them to open additional accounts.

Many consumers are inundated with solicitations from card issuers. The proliferation of their respective products has provided consumers with a wide range of choices and considerable flexibility in managing their credit/debit finances, both personal and business-related. The card issuers, such as banks and other financial institutions, typically promote the use of their respective products through various incentive programs involving features of their products. These features can include increased spending limits, favorable interest rates and “reward points” for product usage. The general trend has been for the functionalities of such products to increase in scope and complexity as issuers offer more choices and flexibility. Such choices and flexibility are particularly desirable in multiple account/product relationships with single issuers.

Usage parameter flexibility and account holder control thereof are highly desirable in multiple account/product relationships with single issuers. For example, an account holder may procure a first product for his or her personal use, another product for the use of his or her dependents, a third product for business use, etc. The account holder may require different usage parameters for his or her respective products, which often share unique and dynamic relationships. As such multiple account/product relationships vary over time, the account holders may find it highly desirable to take advantage of the available usage parameter flexibility in order to accommodate the needs associated with various products and accounts and to manage their usage. Accordingly, a methodology which permits such usage parameter access and control is highly desirable.

Many credit/debit card account holders encounter personal and business circumstances which necessitate changing their financial transaction card product usage parameters. For example, account holders may procure multiple cards associated with individual credit/debit products. The additional cards are often distributed to family members for personal use and employees (where the account holder is a business) for business use, etc. Account holders can establish certain usage parameters for the additional cards on their credit/debit products. Over time, changing business and personal circumstances may alter the preferred usage parameters. Accordingly, in multiple account/product relationships there is a need for the account holders to have access to and control over the product usage parameters. In such relationships, it is also desirable to provide methodologies for controlling usage parameter access differently among the different accounts and products, which can emanate from single or multiple issuers. Moreover, there is a need for such products which permit continuous, interactive access to and control over such usage parameters by account holders. Such functionalities are desirable in applications which are related to relationship processing linking and also in connection with applications which are not. Thus, both single and multiple account applications can benefit from the methodology of the present invention.

Control over the increasingly flexible product usage parameters has generally remained in the hands of the product issuers. Changing usage parameters on existing accounts/products tends to be relatively labor-intensive and hence costly using current methodologies. Therefore, for cost-control purposes, the issuers tend to retain control over the usage parameters for their respective products. Thus, under current financial transaction product models, relatively little usage parameter flexibility is available to the account holders. Account holders can presently contact the card issuers through various points-of-access in order to affect such changes. Points-of-access available to consumers include telephone, automated response unit (“ARU”), global computer network (“internet”), written correspondence, etc. However, usage parameter modifications using current methodologies typically involve employees of the card issuer who receive the account holders' instructions. The instructions must then be implemented. Additional costs may be incurred by the issuers for recording, confirming and implementing such modifications. Since product usage parameters may require modification any number of times during the life of a particular account, the costs associated with providing such services can be significant. Therefore, from the standpoint of the card issuers, consumer-directed usage parameter modifications are generally undesirable and therefore limited. The card issuers generally need to make available such optionality to their customers, even though they have a disincentive for encouraging the exercise of same. Card issuers are presently confronted with the competing objectives of providing their customers with at least some degree of control over their card usage parameters versus minimizing changes in order to control costs.

From the standpoint of the consumer/account holder, usage parameter management typically involves finding the appropriate balance between risk and convenience. For example, credit card fraud is so pervasive that issuers must devote considerable resources to detecting and preventing fraudulent transactions. Fraud-control procedures include monitoring usage patterns such that unusual activity can be promptly detected and dealt with. Usage patterns that are observed for fraud detection include the geographical locations in which purchases are attempted and the types of purchases. These factors can provide early indications of a stolen card or the unauthorized use of an account number.

Credit card fraud can be controlled somewhat by closing and opening accounts. For example, some credit card issuers advise their customers to close their accounts after attending major international sporting events, such as the Wimbledon Tennis Tournaments, because the attendant risk of fraudulent activity is so high. Although effective, closing and reopening credit card accounts tends to be relatively expensive and thus not a particularly desirable solution.

Relatively powerful and sophisticated computer systems have been developed for analyzing data and comparing relationships therebetween quickly and cheaply. Such computerized systems enable the card issuers to handle the aforementioned parameters quickly and efficiently. A relatively high degree of control over the usage parameters associated with particular products is therefore feasible. The present invention takes advantage of such available capabilities by providing consumers with access to and control over such operating parameters associated with their transactional products. Consumers can thereby determine their thresholds of risk versus convenience in setting such parameters. For example, placing fewer usage restrictions on products generally makes their usage more convenient. However, the thresholds for detecting fraudulent activity are correspondingly lower. The present invention enables account holders to modify such usage parameters relatively quickly and efficiently through a wide range of access points. For example, a financial transaction product holder might vary the territorial parameters for his or her cards in advance of upcoming travel. Significant card usage in locations which are away from home for the account holder might therefore be permissible. Upon concluding the travel, the account holder can reset the usage parameters to their previous conditions whereby remote usage would activate fraud control procedures.

Moreover, the system and method of the present invention enable such control to be effected globally for multiple cards under individual products and for the accounts individually in a multiple account relationship. An account holder can thereby adjust the operating usage parameters to account for the activities of, for example, his or her dependents as they travel and as their other circumstances and credit needs change.

Account holder access to and control over such usage parameters has become increasingly desirable. Such optionality, particularly with respect to quantitative usage parameters, enables consumers to balance the risk/convenience factors discussed above. With the system and method of the present invention, consumers are provided with the ability to access and control such usage parameters at the card or dependent account level, as contrasted with previous technology which limited such control to the group or master account level. Such card level usage parameter management is accomplished by applying technology to a system-generated process for applying usage criteria to generate responses from the consumers. A dynamic control of known consumer needs can thus be provided.

The access and control methodology of the present invention recognizes the desirability of enabling usage parameter access, control and management by account holders and, optionally, by cardholders. From the standpoint of the account holders and cardholders, greater access, control and management facilitates tailoring the usage parameters associated with credit/debit products to changing personal and business circumstances, objectives and functionalities. Such user-based control can be very accommodating by providing multiple points of access, some of which are not limited to usage within normal business hours. Thus, the objective of maximizing account holder/cardholder access on a relatively continuous basis can be achieved. Moreover, such access can occur in real time whereby usage parameter modifications can be implemented almost instantaneously. Consumers are thus empowered to adapt their credit/debit products in rapid response to their needs and applications for same, as well as the needs and applications for the additional cardholders associated with particular credit/debit products. The products are thus tied to and highly responsive to relationship management imposed by the account holders, for example, among the multiple cardholders associated with their respective accounts. Such usage parameters can be highly customized by the account holders to accommodate the relationships with and among their respective cardholders.

As discussed above, an important advantage to the account holders is balancing and managing the threshold between risk and convenience through customizing the product usage parameters in real time in response to evolving circumstances. Still further, an advantage to the account holders relates to maintaining privacy with respect to their financial affairs and those of the cardholders associated with their accounts. By leveraging current technologies to facilitate the anonymous implementation of such usage parameter modifications, account holder concerns over privacy can be lessened. In particular, employees of the card processing and service provider organizations, and the card issuers, need not be involved in such usage parameter modifications. Various privacy and security features can be implemented to protect the account holders and cardholders.

The availability of such usage parameter access, control and management can be achieved by leveraging current technology in order to achieve such objectives. Consumers are thus given greater control over their credit/debit products. Part of the current technology which can be leveraged to facilitate the access, control and management features of the present invention involves relational databases. Data can thereby be manipulated and usage parameters can be modified in real time using various points of access in order to enhance the “realness”, speed and flexibility of the methodology of the present invention. Such performance enhancements can be achieved utilizing current technology without increasing costs significantly.

Another significant area of technological development relates to security enhancements. Hardware and software with increasing sophistication are being developed and commercialized to enhance security utilizing such technologies as biometrics, authentication functions, etc. These technologies can be implemented with the methodology of the present invention to enhance its security.

Circumstances giving rise to product usage modifications by consumers include the maturing of individual cardholders with corresponding greater financial needs and responsibilities, and budget changes in both personal and business contexts, for example in response to anticipated changes in usage. Such optionality provides dynamic control of known consumer needs and avoids the problems with product usage controls which are either too restrictive or too permissive.

From the standpoint of the card processing and service providers and the card issuers, shifting dynamic control of product usage to consumers has the effect of enhancing product value. Enhanced product value has a number of benefits, including greater consumer loyalty and more extensive use of the products of a particular provider. Moreover, card processing and service providers and card issuers can reduce their fraud exposure and liability to account holders by shifting access, control and management of usage parameters to the account holders, who are generally in the best position to be aware of and respond to their unique and dynamic circumstances.

Credit/debit products are typically subject to various rules regarding their usage. Such rules can be established by the card processing and service providers and the card issuers. Other rules and regulations are established by statute and regulation, including statutes, rules and regulations pertaining to financial institutions, credit and lending practices and credit reporting. The methodology of the present invention enables account holders to access, control and manage their usage parameters, all subject to compliance with such laws, rules and regulations. Account holders can be presented with various allowable functionality options under the methodology of the present invention. Once requested, such product usage parameter modifications can again be tested against allowable functionalities.

The financial transaction account prior art methodologies provided some access by the account holders to their account usage parameters. For example, various product usage parameters could be selected as options when the accounts were first opened. Such usage parameters were typically incorporated into product agreements among the account holders, issuers and processors. The prior art also provided for the submission of data for updating the account records for address changes and the like. Changes to conditions and limitations within the financial transactional products were managed by the employees of the issuers or the service providers. Speed, flexibility and interactiveness were all relatively limited with such prior art methodologies and the technologies formerly available.

The present invention thus represents a significant shift from the current model of issuer-controlled products to a new model characterized by consumer control. The new, consumer-controlled model benefits the issuer through less employee involvement and benefits the account holder through greater access to and control over the usage of the cards issued on their accounts.

Heretofore there has not been available a financial transaction account usage parameter access and control methodology with the advantages and features of the present invention.

SUMMARY OF THE INVENTION

The method embodying the present invention meets the needs described above, and other needs, by allowing account holders to easily access and modify usage parameters. Any activity outside such predefined parameters can be considered fraudulent and immediately declined. Thus, account transfers can be reduced. Costs incurred for investigating fraud and/or writing off fraudulent activity can also be reduced.

Issuers can provide account holders with access to their usage parameters via points of contact utilizing: global computer network (“internet”) web sites; telephone communications; automated teller machines (ATMs); written correspondence; personal contacts, automated response units (ARUs); and e-mail communications. Account holders can establish active and inactive dates for account access. Outside of the active date parameters such accounts are inaccessible.

If an account holder has a suite of related accounts (accounts that are linked together through relationship processing as described in the incorporated PCT application), he or she can specify the amount of credit and the time parameters to be used for an account. Relationship processing establishes a group level credit line and authorization parameters that define how an account has access to the group credit line. Using controlled access, some of these choices are placed in the hands of the account holder. He or she can determine how much of the group credit line is accessible to an account and the time during which it is accessible. Similarly, cards within an account can be added or temporarily revoked. Thus, the present invention has wide applicability to various financial transaction account applications, including but not limited to those involving grouped accounts.

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to the field of financial transaction card products, and in particular to methodologies for accessing and controlling account usage parameters.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an exemplary relationship between a card processing and service provider, issuers and cardholders. [0028]
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. [0029]
FIG. 3 is a block diagram illustrating the relationship between a card processing and service provider, issuers and the cardholders within a group. [0030]
FIG. 4A is a block diagram illustrating the files included in the group master data financial records. [0031]
FIG. 4B is a block diagram illustrating some of the component parts of group master data financial records. [0032]
FIG. 5 is a flow diagram illustrating steps for building a group. [0033]
FIG. 6 is a flow diagram illustrating steps for creating a group using existing accounts. [0034]
FIG. 7A is a flow diagram illustrating steps for adding a dependent account to a group. [0035]
FIG. 7B is a flow diagram illustrating steps for authorizing a request from a group member account. [0036]
FIG. 8A is a flow diagram illustrating steps for applying payments. [0037]
FIG. 8B is a continuation of FIG. 8A. [0038]
FIG. 9 is a flow diagram illustrating steps for statementing. [0039]
FIG. 10 is a flow diagram illustrating steps for redeeming group reward points. [0040]
FIG. 11 is a block diagram of some of the major components in a system for practicing the financial transaction account access methodology of the present invention. [0041]
FIG. 12 is a flow diagram illustrating steps for access by an account holder. [0042]
FIG. 13 is a block diagram of a system showing alternative points of entry for an account holder interfacing with the financial transaction account system. [0043]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present invention in virtually any appropriately detailed structure. [0044]
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. [0045]
For purposes of this disclosure, a method or process is generally conceived to be a sequence of manual or 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 programable devices according to the teachings of this disclosure. [0046]
Card Processing and Service Provider, Issuers, and Cardholders [0047]
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 [0048] 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, 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/systems (BIN/IIN), principal, and agent hierarchy shown in FIG. 1. The cardholders 120 are typically individuals holding a general purpose credit card or general purpose 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, [0049] 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/systems 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 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, [0050] 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. 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 based on the teaching of this disclosure, 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.

TABLE 1


	STANDARD	STANDARD	GOLD	PRIVATE
Cardholder	VISA	MC	MC	LABEL

MOTHER	account
1		account 2
FATHER			account	3	account 4
SON	account	5
DAUGHTER		account	6		account 7
GRAND-		account 8
FATHER

Each of the accounts shown in Table 1 is an independent account from the issuer's perspective. 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). The processing options used by the issuer to process the accounts shown in Table 1 can differ by product. [0052]
The relationships between the different accounts shown in Table 1, the issuer, and the card processing and service provider are illustrated in FIG. 2. The card processing and [0053] service provider 200 supports 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 [0054]
The accounts shown in Table 1 and FIG. 2 can be linked together to create a group. A group can include any 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 the 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. [0055]
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). [0056]
FIG. 3 shows an exemplary group where the key account and [0057] 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 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 (such as a pre-designated account as will be discussed below) can exist under 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 the group master data for the group. FIG. 4A illustrates the linking of the accounts shown in Table 1 into a group. The [0058] group master data 400 includes information about the group, including group control settings, group aggregate data, and 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 dependent [0059] 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 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, [0060] 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 404 and the group master data 400 is independent of the relationship between the remaining dependent financial records 406 and 408 and the group master data 400.
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. [0061]
Group Master Data [0062]
The [0063] group master data 400 is further illustrated in FIG. 4B. FIG. 4B illustrates a number of files 442-448. 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 444 includes information about the group, such as a group identifier, a group cycle code, a group credit line, and a group collector code. The group identifier identifies the group. Each of the records associated with the group includes the group identifier. It is noted that FIG. 4A shows several dependent accounts. Any one of these dependent accounts could be the account associated with a pre-designated credit card, and the discussion that follows will be applicable to such a credit card.
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 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. [0064]
The [0065] primary owner file 442 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 is stored in the Primary Owner file 442. 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 [0066] group member file 448 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 448 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 446 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 [0067] 450 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 [0068] 452 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, including any parameters and limits that might be associated with a pre-designated credit card. 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. This will be used and particularly of interest in the pre-defined cards that are the subject of this disclosure.
The [0069] member statement file 451 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 451 is used to generate the group statement, dependent statement, and/or a courtesy statement. Dependent and courtesy statements are particularly helpful for a pre-designated card.
The group statement file [0070] 458 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, as well as any parameters associated with pre-designated cards that are non-monetary in nature. Typically, the group payment due date is the earliest due date of all the accounts in the group that are paid by the primary owner. The information stored in the group statement file 458 is used to generate the group statement.
The information in the [0071] member statement file 451 and the group statement file 458 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 [0072] file 454 includes a record for each of the reward programs for the group. Each record includes information about the reward program, such as reward program identifier and the amount of group points accumulated in that reward program.
The custom [0073] calculation definition file 456 and the custom calculation values file 460 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, including a pre-designated card account, in the group. The value that is calculated using the formula is stored in a custom calculation values record.
The [0074] group payment file 462 includes a record for each group payment received. Each record includes the amount of the group payment and the date the group payments was received. The payment allocations file 466 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 464 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 466 to determine how the payment was originally allocated.
The rejects file [0075] 468 includes records of rejections detected during the processing other than group processing. A record in the rejects file 468 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. [0076]
Dependent Strategies [0077]
Typically, the relationship shown in FIG. 4A between the dependent [0078] 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. As will occur to those skilled in the art based on the teaching of this disclosure, a dependent strategy can include the parameters and/or limits associated with a pre-designated credit card, and the disclosure of the dependent strategies herein can be applied to such a pre-designated credit card. 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, as will be the case with a pre-designated credit card. 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. This applies to a pre-designated card as well.
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. [0079]
The parameter values could be selected to create a dependent strategy appropriate for a dependent, college-age child that resides at school. Such parameters are particularly useful if the credit card is pre-designated to apply to certain purchases made at that school, such as books, restaurants in the immediate vicinity of the campus, any campus store, time limits associated with the school term, or the like. 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. A pre-designated card could also limit the types and locations of purchases made on the card. [0080]
The parameter values could also be selected to create a strategy for a dependent account held by the primary owner, such as a pre-designated card. The primary owner could use the key account and a dependent account to segregate expenses as discussed above. 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, adaptational strategies can also be created to address the needs of other situations. [0081]
Thus, the invention includes a method for creating a dependent strategy to customize a relationship between a dependent account and a group that comprises steps of: selecting a set of parameters from a group consisting of time limits, geographic limits, monetary limits, types of purchases made and use; defining values for the set of parameters to define group processing options; labeling the set of parameters and the values for the set of parameters as the dependent strategy; and associating the dependent strategy with the dependent account to customize the relationship between the decedent account and the group. The various parameters can be modified as necessary. [0082]
Building a Group [0083]
The steps associated with building a group are shown in FIG. 5. A new account is opened at [0084] 500 and is designated as the key account (relationship parameter=key) at 502. At decision box 504 a determination is made if the business rules are validated. A negative decision leads to an error determination at 520, which can activate appropriate error messaging, resetting the procedure, etc. An affirmative decision at 504 leads to initiating group build at 508 and thereafter to a decision at 510 to determine if a dependent document is to be added. A negative response leads to an end group build block at 506. An affirmative response leads to the step of opening a new account wherein the dependent relationship parameters apply. Next a dependent strategy is selected at 514 whereafter a determination of whether or not the business rules have been validated is made at 516, with a negative response leading to the error block at 520 and an affirmative response leading to the dependent strategy being selected at 518. The procedure then loops back to the decision box at 510 to determine if another dependent document is to be added, and continues to loop until all dependent documents have been added whereafter the end group build block 506 is reached.
Creating Group Using Existing Accounts [0085]
FIG. 6 shows a procedure for creating a group using existing accounts. An account is selected as a key account at [0086] 600 and a business rule validation decision is made at 602, with a negative response leading to an error routine at 616 and an affirmative response leading to initiating group build at 604. At decision box 606 a determination is made if a dependent document is to be added, with a negative response leading to a determination if business rules have been validated at 612, with a negative response from that leading to the error routine 616. If dependent documents are to be added from 606 (affirmative branch), an account is selected as a dependent account at 608 and a dependent strategy is selected at 610, whereafter the procedure loops back to the decision box 606. If the business rules are validated at 612, the procedure proceeds to update the group master data at 614.
Adding a Dependent Account to a Group [0087]
As discussed above, the pre-designated card can be viewed as being a dependent account. Therefore, the process for adding a dependent account will now be described. [0088]
Once a group is created, additional dependent accounts can be added to the group. The additional dependent accounts can be newly generated accounts or can be existing accounts. FIG. 7A illustrates the steps for adding a dependent account to an existing group. In [0089] step 700, a group is identified. Typically a group is identified using the group identifier. In step 702, the procedure determines if 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 relationship parameter for the account is set to dependent. A dependent strategy for the new account is selected in step 706. This dependent strategy can include the limits and parameters associated with the pre-designated card, such as time limits, geographic limits, use limits and the like as discussed above. In step 708, a determination is made as to whether the dependent account opened in step 704 satisfies the business rules or product usage criteria. If the dependent account satisfies the business rules or product usage criteria, then they are validated and the “Yes” branch is followed to step 710. In step 710, the group master data is updated. If the business rules or product usage criteria are not validated in step 708, then the “No” branch is followed to step 722 and an error occurs.
If the determination in [0090] 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 or product usage criteria in step 718. If the parameters for the dependent account satisfy the business rules or product usage criteria, then the usage criteria are validated and the “Yes” branch is followed to step 720. In step 720, the group master data is updated. However, if the usage criteria 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. [0091]
Group Processing [0092]
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. [0093]
Authorizing a Transaction [0094]
The dependent strategy for a dependent account, such as a pre-designated credit card, specifies the authorization option for the dependent account. The authorization option specifies the information that is used to authorize a transaction. In one form of the invention, several 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, a third option considers the credit line and the available credit of both the group and the dependent account. Yet other options are available for time, location, use and the like. The methods for such options are similar to the method for available credit and thus will not be described, with reference being made to the following discussion for teaching associated with such options. [0095]
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. [0096]
FIG. 7B illustrates exemplary steps for authorizing a transaction. The steps illustrated in FIG. 7B can be applied to any of the limits placed on a pre-designated card and are not intended to be limited to the credit authorization specifically shown. In [0097] 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, especially in relation to a pre-designated card. [0098]
If the determination in [0099] 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 [0100] 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 [0101] 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 [0102] 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.
Similar “Yes” and “No” branches are set up to correspond to the other limits and product usage parameters associated with a pre-designated card. Thus, for example, a “Yes” and “No” branch can be associated with a time limit. Once the above process is completed, and the transaction would otherwise be approved, the process can move on to the time limit loop. If the time limit has not been exceeded, a “Yes” branch would direct the process back to step [0103] 760 and the authorization request would be approved. On the other hand, if the time limit has been exceeded and the pre-designated card cannot be used during this time, the process would move back to the “No” loop and be directed back to step 756 and the authorization request declined. Similar loops can be used for any parameter and/or limit placed on the pre-designated card so that once the credit is authorized, the other limits and/or parameters are checked and the transaction either approved or declined accordingly. The above-discussed billing and reporting procedures will then be used as discussed above.
Payments can be made directly to the pre-designated credit card account or via the group payment method described above and in the incorporated documents. Furthermore, statements and communications can be generated either directly for the pre-designated card or for a group as described above and in the incorporated documents. [0104]
Reward points can be credited directly to the pre-designated card account, or to a group as discussed above and in the incorporated documents. A pre-designated credit card can be added to a group according to the methods discussed above and in the incorporated documents. [0105]
Payment Application [0106]
FIGS. [0107] 8A-8B show a procedure for applying payment. A group payment is received at 800 and a determination made at 802 if it is less than the group balance. If negative, payment is applied to satisfy the last statement balance for each dependent account at 804 and the remainder is applied to the key account at 806. If affirmative from 802, a determination is made if the payment is less than the group minimum payment due (“MPD”) at 808. An affirmative determination leads to determining the payment option at 810, whereafter a delinquency consideration decision block is reached at 812. A negative response at 812 leads to a calculation of the MPD ratio for key independent accounts at 814, and applying payment to key and dependent accounts based on MPD ratios at 816.
An affirmative decision from [0108] block 812 leads to an application of the delinquent amount to each account at 820. A determination is made at 822 if there is a remaining amount. If affirmative, the procedure leads to 814. If negative, the procedure ends.
A negative response at the [0109] decision block 808 leads to FIG. 8B whereat the MPD is applied to key independent accounts at 824 and a determination is made at 826 if there is a remaining balance. If negative, the procedure ends. If affirmative, the procedure proceeds to calculating the remaining balance ratio at 828 and applying the remaining payment using remaining balance ratio at 830.
Statementing [0110]
FIG. 9 shows the procedure for statementing whereat data is calculated for key independent accounts at [0111] 900 and statement data is provided for a key account for a group statement at 902. The dependent strategy is checked at 904, which leads to a determination of whether or not payment for a dependent account is due from the group at 906. If affirmative, the primary owner and intended recipient of statement data are identified and the statement data is provided for the dependent account for the group statement at 908. A determination is made at 910 if the dependent card holder receives a courtesy statement. If affirmative, the primary owner and the intended recipient of the statement data are identified and the statement data is provided for the dependent account for the group statement at 912. If negative, the procedure ends at 914. If the result of decision block 906 is negative, the dependent card holder is identified as the intended recipient of the statement data for the dependent account and the statement data for the dependent account for the dependent statement is provided at 916. A determination is made at 918 if dependent account details are included on the group statement. If affirmative, the primary owner is identified as the intended recipient of statement data for the dependent account and the statement data is provided for the group statement at 920. If negative, the primary owner is identified as the intended recipient of the statement data and the statement data is provided for the dependent account for the group statement at 922.
Redemption [0112]
FIG. 10 shows a procedure for redeeming group reward points which commences with a request being received at [0113] 1000. At decision block 1002, a determination is made if the requesting account is a member of a group. If negative, the procedure proceeds to redemption permitted from requested account only at 1016. If affirmative, a determination is made at the next decision block 1004 if the reward program pools. If negative, the procedure proceeds to 1016. If affirmative, the procedure proceeds to 1006 whereat a determination is made if the requesting account is a key account. If negative, the dependent strategy is checked at 1008 and a determination made at 1010 if the dependent strategy allows redemption, whereafter a negative response leads to 1016. An affirmative response from either 1006 or 1010 leads to a determination if there are sufficient group points to satisfy the redemption request at 1012. If affirmative, the redemption is authorized at 1018. If negative, the redemption is not authorized at 1014.
Product Usage Parameter Access and Control [0114]
FIG. 11 is a block diagram of major components of a system for practicing the usage parameter access and control methodology of the present invention. A financial [0115] transaction product issuer 1100 exercises control at 1102 over primary usage parameters 1104, which can include, but are not limited to, some or all of the product usage parameters discussed above. The primary usage parameters 1104 are associated with a financial transaction account 1106. Transactions 1108 involving the account 1106 are implemented with one or more presentation instruments 1110, which result in transaction records 1112 which are applied to the account as data at 1114. The account 1106 and presentation instrument 1110 associated therewith generally comprise a product offered by the issuer 1100.
A [0116] key account holder 1118 exercises control at 1120 over the primary usage parameters 1104, for example when he or she first establishes the account at 1106. Establishing a new account at 1106 provides a key account holder with an initial opportunity to establish the primary usage parameters 1104, subject to ongoing, interactive, real-time access thereby throughout the life of the account according the methodology of the present invention.
A [0117] dependent account holder 1122 exercises control at 1124 over dependent usage parameters 1126. The dependent usage parameters 1126 can overlap the primary usage parameters 1104 to any desired extent. Thus, the methodology of the present invention can accommodate dependent account holders 1122 being given any desired degree of control over the usage parameters associated with a particular account, with such degree of control being subject to continues change and updating to accommodate the needs of the account holders 1118 and 1122. For example, over a period of time a dependent account holder 1122 could be given a greater degree of control and access over the usage parameters by the key account holder 1118. The key account holder 1118, may be, but is not required to be, the primary owner of the account 1106.
FIG. 12 shows a flow diagram of an account holder access interface methodology of the present invention. From a [0118] start box 1202, an account holder enters the system at 1204. Points of entry are described in greater detail below and with reference to FIG. 13.
At decision box [0119] 1206 a determination is made if a consumer has a valid identification, such as a personal identification number (“PIN”), password, etc. A negative determination at 1208 moves the methodology to an end block 1210 and can produce an error or similar output from the system. An affirmative decision at 1212 from decision box 1206 causes the system to determine allowed actions at 1214 and provide (output) options relating thereto to the account holder at 1216. The account holder requests changes to the product usage parameters at 1218.
At decision box [0120] 1220 a determination is made if the requested parameter changes are within those allowed. A negative response at 1222 transfers the methodology to an end block 1210 and possibly the output of an error message or the like. An affirmative response at 1224 advances the methodology to a confirmation of request entry at 1226, thereafter resulting in a process change at 1228 with a resulting impact on the account usage parameters 1230 or access thereto. One of the possible usage parameters within the methodology of the present invention can consist of the access to the usage parameters, including the ability to modify same within certain predetermined limits.
FIG. 13 is a block diagram of various alternative interface functionalities according to the methodology of the present invention. [0121] Column 1302 depicts an entry mode whereby an account holder 1304 can access product usage parameters associated with his or her account. Alternative entry modes depicted therein include a website 1304 accessible through the global communications network (“Internet”), which can consist of the website of an issuer 1306, a third party 1308 or a processor 1310. Other alternative entry mode points include telephone 1312, written correspondence 1314 and e-mail 1316. Other points of entry are generally shown at 1318 and can include any suitable means for entry by the account holder 1304 to his or her account.
The path of communication between the [0122] account holder 1304 and his or her account is shown at 1322 and includes a point of entry 1320 (accessed by one or more of the entry modes discussed above) to the issuer 1306, the third party 1308 or the processor 1310. The issuer 1306, the third party 1308 and the processor 1310 can all be combined into a single functional unit. Within the financial transaction processing business community, various functions can be allocated to different product and service providers, including those depicted in the path 1322. For example, the third party 1308 can provide a wide range of products and/or services in connection with the financial transaction products issued by the issuer 1306. Financial transaction processing is another significant segment of the industry, which utilizes processors, such as the processor 1310 for performing the data processing and related functions associated with financial transactions by account holders.
The impact to an account for access to the account is shown at [0123] 1324 and includes such functionalities as communications 1326, an account's credit line 1328, a new user (dependent account, see FIG. 7A), a block user 1332, payment allocations 1334 and transaction authorization parameters 1336. Various other functionalities and usage parameters associated with an account or access thereto are collectively depicted at 1338, which is understood to be as broad as might be encountered in connection with financial transaction accounts and the various functionalities associated therewith.
Conclusion [0124]
It is to be understood that while certain forms of the present invention have been illustrated and described herein, it is not to be limited to the specific forms or arrangement of parts described and shown. [0125]

Claims

What is claimed and desired to be secured by Letters Patent is as follows:

1. A method of accessing usage parameters associated with a financial transaction account, which comprises the steps of:

establishing an account;

issuing a presentation instrument associated with said account;

establishing an initial set of product usage parameters for said account;

providing access to said product usage parameters by the account holder;

submitting modified product usage parameters by the account holder;

establishing product usage criteria by a card processing and service provider or a card issuer;

comparing the submitted product usage parameter modifications with the usage criteria;

if the submitted product usage parameters comply with said usage criteria, implementing same in connection with the account; and

rejecting the submitted product usage parameters if same do not comply with the usage criteria.

2. The method of claim 1 wherein said account comprises a first account, and which method includes the additional steps of:

establishing a second account; and

forming a group with said accounts.

3. The method of claim 2, which includes the additional steps of:

designating one of said accounts as a key account;

providing primary product usage parameters for said key account;

designating the other said account as a dependent account;

providing dependent product usage parameters for said dependent account; and

providing a holder of said key account with access to and control over the product usage parameters associated with said dependent account.

4. The method of claim 3, which includes the additional step of creating group master data financial records associated with said group.

5. The method of claim 1 wherein said product usage parameters include ranges of time during which said presentation instrument can be utilized.

6. The method of claim 1 wherein said product usage parameters include geographic restrictions on the usage of said presentation instrument.

7. The method of claim 1 wherein said product usage parameters include restrictions on the types of goods and services which can be purchased with said presentation instrument.

8. The method of claim 3, which includes the additional steps of:

establishing a credit line for said group with a group credit limit;

establishing a dependent credit line for said dependent account with a dependent account credit limit; and

said credit limits comprising product usage parameters.

9. The method of claim 1, which includes the additional steps of:

arranging for the allocation of account payments among said key and dependent accounts; and

allocating account payments among said key and dependent accounts.

10. The method of claim 3, which includes the additional steps of:

providing statements for said key and dependent financial accounts; and

providing the key account holder with access to the information provided in conjunction with such statements.

11. The method of claim 3 wherein said product usage parameters include the redemption of reward points for purchases by members of said group.

12. A method of accessing, controlling and managing the usage parameters for a group of financial transaction accounts including a key account and at least one dependent account, which method includes the steps of:

issuing by a card processing and service provider or by a card issuer a financial transaction product;

providing a key account for a key account holder;

providing at least one dependent account for a dependent account holder;

issuing presentation instruments to said account holders respectively;

establishing an initial set of product usage parameters;

providing said key account holder with access to said product usage parameters;

providing a set of usage criteria concerning said product usage parameters by said card processing and service provider or by said card issuer;

said key account holder submitting a proposed product usage parameter modification through a point of access;

comparing said submitted product usage parameter modification with said usage criteria;

implementing said submitted product usage parameter modification in connection with said account if same complies with said usage criteria; and

rejecting said submitted product usage parameter modification if same does not comply with said usage criteria.

13. The method of claim 12, which includes the additional steps of:

providing primary usage parameters associated with said key account;

providing dependent usage parameters associated with said dependent account;

providing said key account holder with access to and control over said primary and dependent usage parameters; and

providing said dependent account holder with control over said dependent usage parameters.

14. The method of claim 12 wherein said usage parameters comprise primary usage parameters, which method includes the additional steps of:

providing issuer control of said primary usage parameters;

providing key account holder control of said primary usage parameters subject to said usage criteria;

providing dependent usage parameters;

providing said dependent account holder with control of said dependent usage parameters; and

providing said key account holder with access to and control of said dependent usage parameters.

15. The method of claim 14, which includes the additional steps of:

providing an account;

subjecting said account to said primary usage parameters;

conducting transactions on said account with said presentation instruments;

maintaining a record of transactions conducted with said presentation instruments; and

providing transactional record data to said account.

16. The method of claim 12, which includes the additional steps of:

providing a unique identification for each account holder;

validating the account holder identification upon entry into the access methodology;

determining the actions allowed of the account holder;

providing the account holder with options pertaining to the product usage parameters;

comparing the account holders' requested changes with the usage criteria;

confirming entry of said changes;

processing said changes; and

impacting the product account or access thereto with said changes.

17. The method of claim 12, which includes the additional step of:

providing said account holder with alternative entry modes into said access and control methodology.

18. The method of claim 17 wherein one of said entry modes is via the global computer network (“internet”).

19. The method of claim 17 wherein one of said entry modes is via a telecommunications system.

20. The method of claim 17 wherein one of said entry modes is via written correspondence.

21. The method of claim 17 wherein one of said entry modes is via e-mail.

22. The method of claim 12, which includes the additional step of providing alternative paths for entry into said methodology.

23. The method of claim 22, wherein said alternative paths include a path from the entry mode through the issuer.

24. The method of claim 22, wherein said alternative paths include a path from said entry mode through a third party.

25. The method of claim 22 wherein said alternative paths include a path from said entry mode through a processor.

26. The method of claim 12, which includes the additional step of:

providing alternative impacts to said account or access.

27. The method of claim 26 wherein said impact is to communications usage parameters.

28. The method of claim 26 wherein said impact is to credit line usage parameters.

29. The method of claim 26 wherein said impact is to new user usage parameters.

30. The method of claim 26 wherein said impact is to block user usage parameters.

31. The method of claim 26 wherein said impact is to payment allocation usage parameters.

32. The method of claim 26 wherein said impact is to authorization usage parameters.

33. A method of accessing and controlling usage parameters associated with a financial transaction account, which includes the steps of:

providing a card processing and service provider;

providing a product issuer associated with said card processing and service provider;

issuing multiple presentation instruments associated with said account;

establishing a key account holder within said account;

establishing a dependent account holder within said account.

providing said account holders with respective presentation instruments;

providing the key account with primary usage parameters;

providing the dependent account with dependent usage parameters;

conducting transactions with said presentation instruments through said account;

providing transaction records from said transactions to said account;

establishing product usage criteria by the card processing and service provider or by the card issuer;

accessing said primary and dependent usage parameters by said key account holder;

submitting modified primary and secondary usage parameters by said key account holder;

comparing the submitted product usage parameter modifications with the product usage criteria;

34. A method of accessing and controlling usage parameters associated with a financial transaction account, which includes the steps of: