U.S. patent application number 10/025092 was filed with the patent office on 2004-02-12 for financial transaction account usage parameter access and control method.
This patent application is currently assigned to First Data Resources, Inc.. Invention is credited to Holm-Blagg, Lynn, Kathol, Eugene F., Lindsay, Carol Ann.
Application Number | 20040030657 10/025092 |
Document ID | / |
Family ID | 23150430 |
Filed Date | 2004-02-12 |
United States Patent
Application |
20040030657 |
Kind Code |
A1 |
Holm-Blagg, Lynn ; et
al. |
February 12, 2004 |
Financial transaction account usage parameter access and control
method
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.
Inventors: |
Holm-Blagg, Lynn; (Omaha,
NE) ; Lindsay, Carol Ann; (Omha, NE) ; Kathol,
Eugene F.; (Omaha, NE) |
Correspondence
Address: |
SHUGHART THOMSON & KILROY, PC
120 WEST 12TH STREET
KANSAS CITY
MO
64105
US
|
Assignee: |
First Data Resources, Inc.
|
Family ID: |
23150430 |
Appl. No.: |
10/025092 |
Filed: |
December 19, 2001 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10025092 |
Dec 19, 2001 |
|
|
|
09298417 |
Apr 23, 1999 |
|
|
|
Current U.S.
Class: |
705/65 |
Current CPC
Class: |
G06Q 20/227 20130101;
G06Q 20/24 20130101; G06Q 30/02 20130101; G06Q 20/04 20130101; G06Q
40/00 20130101; G06Q 20/367 20130101; G06Q 30/0233 20130101; G06Q
30/0215 20130101; G06Q 40/02 20130101 |
Class at
Publication: |
705/65 |
International
Class: |
G06F 017/60 |
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; 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.
34. 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; if the submitted product usage parameters comply
with said usage criteria, implementing same in connection with the
account; rejecting the submitted product usage parameters if same
do not comply with the usage criteria; 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; impacting the product account or access thereto with
said changes; providing said account holder with alternative entry
modes into said access and control methodology; and providing
alternative impacts to said account or access.
Description
RELATED APPLICATIONS
[0001] 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.
[0002] 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.
BACKGROUND OF THE INVENTION
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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
[0024] 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.
[0025] 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.
[0026] 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
[0027] 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
[0028] FIG. 1 is a block diagram illustrating an exemplary
relationship between a card processing and service provider,
issuers and cardholders.
[0029] 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.
[0030] FIG. 3 is a block diagram illustrating the relationship
between a card processing and service provider, issuers and the
cardholders within a group.
[0031] FIG. 4A is a block diagram illustrating the files included
in the group master data financial records.
[0032] FIG. 4B is a block diagram illustrating some of the
component parts of group master data financial records.
[0033] FIG. 5 is a flow diagram illustrating steps for building a
group.
[0034] FIG. 6 is a flow diagram illustrating steps for creating a
group using existing accounts.
[0035] FIG. 7A is a flow diagram illustrating steps for adding a
dependent account to a group.
[0036] FIG. 7B is a flow diagram illustrating steps for authorizing
a request from a group member account.
[0037] FIG. 8A is a flow diagram illustrating steps for applying
payments.
[0038] FIG. 8B is a continuation of FIG. 8A.
[0039] FIG. 9 is a flow diagram illustrating steps for
statementing.
[0040] FIG. 10 is a flow diagram illustrating steps for redeeming
group reward points.
[0041] 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.
[0042] FIG. 12 is a flow diagram illustrating steps for access by
an account holder.
[0043] 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.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0044] 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.
[0045] 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.
[0046] 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.
[0047] Card Processing and Service Provider, Issuers, and
Cardholders
[0048] 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
service provider 100, a number of issuers 102a, 102b . . . 102c,
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
102b, 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.
[0049] An issuer can issue different types and versions of credit
card products. For example, issuer 102b 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 102b
issues a VISA product and a MASTERCARD product, then product/system
104a 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.
[0050] 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 106a could correspond to a geographic
region, such as the southeast, and agent block 110a 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.
[0051] 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.
1TABLE 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
[0052] 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.
[0053] 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 service provider
200 supports issuer 202. The issuer 202 issues a variety of credit
card products, including a standard VISA product 204a, a standard
MASTERCARD product 204b, a gold MASTERCARD product 204c, and a
private label product 204d. account 1 and account 5 are shown under
the standard VISA product 204a, account 6 and account 8 are shown
under the standard MASTERCARD product 204b, account 2 and account 3
are shown under the gold MASTERCARD product 204c, and account 4 and
account 7 are shown under the private label product 204d.
[0054] Groups and Group Relationships
[0055] 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.
[0056] 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).
[0057] FIG. 3 shows an exemplary group where the key account and
dependent account 1 are associated with the same agent 308a.
dependent account 2 is associated with a different agent 308b, but
is the same type of product 304a as the key account and dependent
account 1. dependent account 3 is associated with a different
principal 306b than the key account, Dependent account 1, and
dependent account 2 is associated with a different agent 308d than
dependent account 3, but is associated with the same principal
306b. Dependent account 5 is a different product 304b 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 302b. Furthermore, additional groups can exist under the
other issuers 302a, 302c.
[0058] 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 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.
[0059] In addition to the key financial record, the group also
includes 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 404. Each account is also associated with one or
more cardholders, e.g., the mother is the cardholder associated
with account 2.
[0060] The dependent accounts in the group can cross product lines.
In this example, 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.
[0061] 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.
[0062] Group Master Data
[0063] The 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.
[0064] 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.
[0065] The 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.
[0066] The 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.
[0067] The member relationship file 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.
[0068] The strategy definition file 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.
[0069] The 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.
[0070] The group statement file 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.
[0071] The information in the 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.
[0072] The group rewards 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.
[0073] The custom 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.
[0074] The 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.
[0075] The rejects file 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.
[0076] 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.
[0077] Dependent Strategies
[0078] Typically, 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. 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.
[0079] 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.
[0080] 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.
[0081] 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.
[0082] 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.
[0083] Building a Group
[0084] The steps associated with building a group are shown in FIG.
5. A new account is opened at 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.
[0085] Creating Group Using Existing Accounts
[0086] FIG. 6 shows a procedure for creating a group using existing
accounts. An account is selected as a key account at 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.
[0087] Adding a Dependent Account to a Group
[0088] 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.
[0089] 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 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.
[0090] If the determination in 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.
[0091] 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.
[0092] Group Processing
[0093] 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.
[0094] Authorizing a Transaction
[0095] 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.
[0096] 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.
[0097] 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
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.
[0098] 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.
[0099] 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. 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.
[0100] If the determination in 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.
[0101] If the dependent strategy specifies option A, then 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. 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.
[0102] If the dependent strategy specifies option B, then the
method proceeds from 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.
[0103] 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 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.
[0104] 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.
[0105] 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.
[0106] Payment Application
[0107] FIGS. 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.
[0108] An affirmative decision from 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.
[0109] A negative response at the 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.
[0110] Statementing
[0111] FIG. 9 shows the procedure for statementing whereat data is
calculated for key independent accounts at 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.
[0112] Redemption
[0113] FIG. 10 shows a procedure for redeeming group reward points
which commences with a request being received at 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.
[0114] Product Usage Parameter Access and Control
[0115] 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 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.
[0116] A 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.
[0117] A 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.
[0118] FIG. 12 shows a flow diagram of an account holder access
interface methodology of the present invention. From a 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.
[0119] At decision box 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.
[0120] At decision box 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.
[0121] FIG. 13 is a block diagram of various alternative interface
functionalities according to the methodology of the present
invention. 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.
[0122] The path of communication between the 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.
[0123] The impact to an account for access to the account is shown
at 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.
[0124] Conclusion
[0125] 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.
* * * * *