System for maintaining transaction data Number:7,419,094 from the United States Patent and Trademark Office (PTO) owispatent According to one embodiment of the invention, an architecture for a data processing system can be implemented that processes data for a service provider itself or a client of a service provider as in the case of a third party processor. The elements of the architecture can be managed separately. For example, the architecture can be organized around eight subject areas, such as account, party, communication point, presentation instrument, rules, balances, transactions, and product. Relationships between each of the subject areas as well as between sub-types of each subject area can be established to provide flexibility in the management of the data.<H transaction, maintaining, System, for, main, 7419094.html, Patent, pto, 7419094

Title: System for maintaining transaction data

Abstract: According to one embodiment of the invention, an architecture for a data processing system can be implemented that processes data for a service provider itself or a client of a service provider as in the case of a third party processor. The elements of the architecture can be managed separately. For example, the architecture can be organized around eight subject areas, such as account, party, communication point, presentation instrument, rules, balances, transactions, and product. Relationships between each of the subject areas as well as between sub-types of each subject area can be established to provide flexibility in the management of the data.

Patent Number: 7,419,094 Issued on 09/02/2008 to Grear, et al.

Inventors: Grear; Michael B. (Omaha, NE), Miller; Thomas M. (Omaha, NE)
Assignee: First Data Corporation (Greenwood Village, CO)

Appl. No.: 10/972,149

Filed: October 22, 2004

Related U.S. Patent Documents


Application Number	Filing Date	Patent Number	Issue Date
60567891	May., 2004
60547651	Feb., 2004

Current U.S. Class: 235/380 ; 235/375

Current International Class: G06K 5/00 (20060101)

Field of Search: 235/380,375

References Cited [Referenced By]

U.S. Patent Documents


5334823	August 1994	Noblett, Jr. et al.
5343529	August 1994	Goldfine et al.
5357563	October 1994	Hamilton et al.
5386458	January 1995	Nair et al.
5404000	April 1995	Nair et al.
5428210	June 1995	Nair et al.
5432326	July 1995	Noblett, Jr. et al.
5479530	December 1995	Nair et al.
5625776	April 1997	Johnson
5649117	July 1997	Landry
5671279	September 1997	Elgamal
5812668	September 1998	Weber
5850446	December 1998	Berger et al.
5889863	March 1999	Weber
5943424	August 1999	Berger et al.
5950179	September 1999	Buchanan et al.
5978780	November 1999	Watson
5983208	November 1999	Haller et al.
5987132	November 1999	Rowney
5995976	November 1999	Walker et al.
5999596	December 1999	Walker et al.
6002767	December 1999	Kramer
6026379	February 2000	Haller et al.
6052674	April 2000	Zervides et al.
6058375	May 2000	Park
6061665	May 2000	Bahreman
6072870	June 2000	Nguyen et al.
6119105	September 2000	Williams
6128599	October 2000	Walker et al.
6178409	January 2001	Weber et al.
6253027	June 2001	Weber et al.
6283366	September 2001	Hills et al.
6304915	October 2001	Nguyen et al.
6308887	October 2001	Korman et al.
6324524	November 2001	Lent et al.
6327348	December 2001	Walker et al.
6330544	December 2001	Walker et al.
6373950	April 2002	Rowney
6449616	September 2002	Walker et al.
6468155	October 2002	Zucker et al.
6473500	October 2002	Risafi et al.
6473794	October 2002	Guheen et al.
6477571	November 2002	Ross
6519571	February 2003	Guheen et al.
6536037	March 2003	Guheen et al.
6578014	June 2003	Murcko, Jr.
6606744	August 2003	Mikurak
6609113	August 2003	O'Leary et al.
6615166	September 2003	Guheen et al.
6633788	October 2003	Riley et al.
6671818	December 2003	Mikurak
6685088	February 2004	Royer et al.
6704714	March 2004	O'Leary et al.
6708176	March 2004	Strunk et al.
6721713	April 2004	Guheen et al.
6760711	July 2004	Gillett et al.
7031939	April 2006	Gallagher et al.
7072847	July 2006	Ulenas et al.
7134096	November 2006	Brathwaite et al.
7272617	September 2007	Bayer et al.
2002/0120561	August 2002	Chin et al.
2002/0154114	October 2002	Christensen et al.
2003/0018549	January 2003	Fei et al.
2003/0069836	April 2003	Penney et al.
2003/0225772	December 2003	Sykes
2004/0010462	January 2004	Moon et al.
2004/0039679	February 2004	Norton et al.
2004/0143496	July 2004	Saenz
2004/0158522	August 2004	Brown et al.
2005/0182720	August 2005	Willard et al.
2005/0289024	December 2005	Hahn-Carlson et al.
2007/0094302	April 2007	Williamson et al.

Foreign Patent Documents


1225522	Jul., 2002	EP

Other References

USPTO; Non-final Office Action mailed Oct. 1, 2007; for U.S. Appl. No. 10/972,109. cited by other .
Anon. "Aquarius Technology Corporation Announces Strategic Partnership with Onyx Software," PR Newswire, Mar. 26, 1999. cited by other .
Khoo et al., "Investigation on a Prototype Customer-Oriented Information System for Product Concept Development, An" (Abstract Only), Computers in Industry, vol. 49, No. 2, pp. 157-174, Oct. 2002. cited by other .
Roebuck, K., "Platform Approach to Wealth Management Technology, The," Wal Street & Technology, vol. 21, No. 2, SS12, Feb. 2003. cited by other .
USPTO; Non-Final Office Action mailed Mar. 19, 2008; for U.S. Appl. No. 10/972,152. cited by other .
USPTO; Non-Final Office Action mailed Mar. 24, 2008; for U.S. Appl. No. 10/971,832. cited by other .
USPTO; Advisory Action mailed Mar. 27, 2008; for U.S. Appl. No. 10/971,831. cited by other .
USPTO; Final Office Aciton mailed Oct. 25, 2007; for U.S. Appl. No. 10/971,831. cited by other .
USPTO; Non-final Office Action mailed Jan. 10, 2008; for U.S. Appl. No. 10/971,951. cited by other .
USPTO; Non-final Office Action mailed Nov. 5, 2007; for U.S. Appl. No. 11/064,289. cited by other .
USPTO; Non-Final Office Action mailed Apr. 7, 2008; for U.S. Appl. No. 10/972,151. cited by other .
USPTO; Final Office Action mailed Apr. 22, 2008; for U.S. Appl. No. 10/972,109. cited by other.

Primary Examiner: Caputo; Lisa M
Attorney, Agent or Firm: Townsend and Townsend and Crew LLP

Parent Case Text

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit under 35 USC .sctn.119(e) of U.S. Patent Application No. 60/547,651, filed on Feb. 24, 2004 entitled "System and Method for Transaction Processing" as well as the benefit under 35 USC .sctn.119(e) of U.S. Patent Application No. 60/567,891, filed May 3, 2004, entitled "System and Method for Transaction Processing" and hereby incorporates by reference the content of both applications in their entirety and for all purposes.

Claims

What is claimed is:

1. A method of associating transaction entries for use by a data processor, said method comprising: providing a transaction database for storing transaction information; generating a first transaction internal identifier; assigning said first transaction internal identifier to data for a first transaction as a first transaction data entry; storing said first transaction data entry in said transaction database; generating a second transaction internal identifier; assigning said second transaction internal identifier to data for a second transaction as a second transaction data entry; storing said second transaction data entry in said transaction database; providing a transaction relationship type code for describing the relationship between two transaction entries; associating said transaction relationship type code with said first transaction internal identifier and with said second transaction internal identifier so as to describe the relationship between said first transaction data entry and said second transaction data entry; responding to a transaction query by utilizing said association of said transaction relationship type code with said first transaction internal identifier and with said second transaction internal identifier.

2. The method as described in claim 1 and further comprising: storing said transaction relationship type code and said first transaction internal identifier and said second transaction internal identifier in a transaction relationship database.

3. The method as described in claim 1 and further comprising: retrieving said first transaction internal identifier from said transaction database.

4. The method as described in claim 3 and further comprising: retrieving said second transaction internal identifier from said transaction database.

5. The method as described in claim 1 and further comprising: associating said first transaction internal identifier as identifying the subject of said relationship; and associating said second transaction internal identifier as identifying the object of said relationship.

6. The method as described in claim 1 wherein said first transaction internal identifier identifies an authorization transaction for a sale.

7. The method as described in claim 1 wherein said first transaction internal identifier identifies a sales transaction.

8. The method as described in claim 1 wherein said first transaction internal identifier identifies a chargeback transaction.

9. The method as described in claim 1 wherein said first transaction internal identifier identifies a chargeoff transaction.

10. The method as described in claim 1 wherein said first transaction internal identifier identifies retrieval request transaction.

11. The method as described in claim 1 wherein said first transaction internal identifier identifies a reversal transaction.

12. The method as described in claim 1 wherein said first transaction internal identifier identifies an adjustment transaction.

13. The method as described in claim 1 wherein said first transaction internal identifier identifies a return transaction.

14. The method as described in claim 1 wherein said first transaction internal identifier identifies a cash advance transaction.

15. The method as described in claim 1 wherein said first transaction internal identifier identifies a name change transaction for a party.

16. The method as described in claim 1 wherein said first transaction internal identifier identifies an address change transaction for a party.

17. The method as described in claim 1 wherein said first transaction internal identifier identifies a fee assessment transaction.

18. The method as described in claim 1 wherein said first transaction internal identifier identifies an interest assessment transaction.

19. The method as described in claim 1 wherein said first transaction internal identifier identifies bonus points earned transaction.

20. The method as described in claim 1 wherein said first transaction internal identifier identifies an allocation transaction.

21. The method as described in claim 1 wherein said first transaction internal identifier identifies a payment transaction.

22. The method as described in claim 1 wherein said first transaction internal identifier identifies a funds transfer transaction.

23. The method as described in claim 1 wherein said associating said transaction relationship type code with said first transaction internal identifier and with said second transaction internal identifier comprises: grouping said first transaction internal identifier with said second transaction internal identifier and with said transaction relationship type code.

24. The method as described in claim 1 and further comprising: determining successive transactions that originated from an original transaction.

Description

STATEMENT AS TO RIGHTS TO INVENTIONS MADE UNDER FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

NOT APPLICABLE

REFERENCE TO A "SEQUENCE LISTING," A TABLE, OR A COMPUTER PROGRAM LISTING APPENDIX SUBMITTED ON A COMPACT DISK.

NOT APPLICABLE

Embodiments of the invention relate generally to systems for processing data for service industries. For example, one embodiment of the invention relates to a system for processing utility usage transactions and generating bills. Yet another embodiment relates to processing credit card transactions for the credit card (retail, debit, consumer) industry. Still other embodiments of the invention relate to processing transactions generated on accounts for healthcare payments, home mortgage, consumer loans, telephone usage, for example.

BACKGROUND

Credit card transaction management and administration is an example of a processing system that has traditionally relied on storing a great deal of information with a single identifier used as a reference. For example, a credit card account typically includes information about the customer, the account, the billing address, the formal transaction information, and the credit card and physical credit card characteristics. All of this is handled from the perspective of a single account, so that the credit card company can track transactions for a particular customer. Thus, this results in a very static data processing system that is inflexible which makes it difficult to effect changes as the business it services evolves. Furthermore, the handling of this information is typically specific to a particular line of business within an industry such as a revolving credit product for the financial services industry. It is not readily aligned with a totally different service model, such as one's utility billing system, insurance claim payment processing system, phone billing system, or cable billing system.

Thus, a third party which handles the processing of transactions for a variety of different industries or services must create independent systems for handling each service's transactions. There currently appears to be no unique system which is capable of flexibly handling different types of services, such as credit card processing, healthcare claim payment, and utility bill processing, in the same processing system. Again, the static and inflexible nature of the current processing systems prevent this.

In addition, because the account information, party information, and presentation instrument information for a credit card system, for example, is referenced by a single identifier, it is quite difficult, if not impossible, under present systems, to manage the individual areas of account information, party information, or presentation instrument as independent data. Once again, the inflexible nature of a single reference to the data prevents this from happening.

As another example of the inflexibility of current systems, it is not easy to modify existing systems to add multiple parties and the requisite roles they play to an account and utilize multiple cards for that account. Again, this is difficult due to the fact that once an account is created under the static formatting of a particular account--such as the formatting of a Mastercard Gold Card with a single customer--it is extremely difficult to modify that record to reflect change--such as a second party, playing a previously unsupported role, on the account--without restructuring the processing system (underlying data structures and program code).

Another example of the inflexibility of credit card systems is that customers are typically prevented from playing dual roles in an account, such as the role of guarantor and authorized user. Instead, the credit card account is typically configured to identify one party as the authorized user and a different party as the guarantor. Once again, this prevents the flexibility that might be desired in certain circumstances.

Yet another example of the rigidity of current systems is that, for products offered by a bank, for example, which offers different credit card lines as well as brokerage accounts and mortgages, each of those individual accounts is typically processed separately, under separate systems. It is not possible to easily combine those systems at a later point in time under a master account which could be tailored to the services desired by a particular customer.

As yet another example, the static nature of current systems makes it difficult, if not impossible, to modify the mailing contact points for an individual during different times of the year. For example, a credit card statement is typically mailed to a home residence of the customer who is financially responsible for the account. Current systems do not provide the flexibility to allow a customer to designate varying locations during the year to which statements should be sent. This is due to the fact that only a single address is currently associated with a credit card account, for example, without the flexibility to designate different contact points throughout the year. To include such information would require a complete reworking of the credit card processing system because the credit card processing system operates by referring to all account information using a single reference identifier.

Thus, as can be seen from the above examples, current processing systems for service industries are typically configured in a static and inflexible way so as to effectively prevent the efficient management of information for an account. Other examples addressed by present embodiments of the invention will be apparent from the following specification.

Thus, there is a need for a data processing system which can handle the processing of data for service industries in a more flexible manner. For example, there is a need for a data processing system and requisite data architecture that can easily adapt to changing business requirements and is not tightly coupled with a specific aspect of any one service or any one industry.

SUMMARY

According to one embodiment of the invention, a method of associating transaction entries for use by a data processor wherein the method comprises providing a transaction database for storing transaction information; generating a first transaction internal identifier; assigning the first transaction internal identifier to data for a first transaction as a first transaction data entry; storing the first transaction data entry in the transaction database; generating a second transaction internal identifier; assigning the second transaction internal identifier to data for a second transaction as a second transaction data entry; storing the second transaction data entry in the transaction database; providing a transaction relationship type code for describing the relationship between two transaction entries; associating the transaction relationship type code with the first transaction internal identifier and with the second transaction internal identifier so as to describe the relationship between the first transaction data entry and the second transaction data entry.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram illustrating the architecture of a data processing system for managing service industry data according to one embodiment of the invention.

FIG. 1B illustrates a data processing system for implementing the architecture shown in FIG. 1A.

FIGS. 2A and 2B illustrate a flowchart for implementing a method of processing data for a service business according to one embodiment of the invention.

FIGS. 3A and 3B illustrate a flowchart for implementing a method of processing data according to one embodiment of the invention.

FIG. 4 illustrates a flowchart for processing data in a party-account relationship, according to one embodiment of the invention.

FIGS. 5A and 5B illustrate a flowchart demonstrating a method of processing data in a party-account relationship, according to one embodiment of the invention.

FIG. 6 illustrates a flowchart demonstrating a method of processing data for a party-account-presentation instrument relationship, according to one embodiment of the invention.

FIGS. 7A and 7B illustrate a flowchart for implementing a method of processing data for a party-account-presentation instrument relationship according to one embodiment of the invention.

FIG. 8 illustrates a flowchart for implementing a method of processing data for a party-communication point relationship according to one embodiment of the invention.

FIG. 9 illustrates a flowchart for implementing a method of processing data for a party-communication point relationship according to one embodiment of the invention.

FIG. 10 illustrates a flowchart for implementing a method of processing data for a product-account relationship, according to one embodiment of the invention.

FIG. 11 illustrates a flowchart for implementing a method of processing data for a product-account relationship, according to one embodiment of the invention.

FIG. 12 illustrates a flowchart for implementing a method of processing data for a product-account relationship, according to one embodiment of the invention.

FIG. 13 illustrates a block diagram of a computing system for implementing any of the computer processing systems in the embodiments of the invention described herein.

FIG. 14 illustrates a flowchart for implementing a method of processing data for an account-balance relationship, according to one embodiment of the invention.

FIG. 15 illustrates a flowchart for implementing a method of processing data for a product-balance relationship, according to one embodiment of the invention.

FIGS. 16A and 16B illustrates a block diagram of an exemplary configuration for the Communication Point subject area, according to one embodiment of the invention.

FIGS. 17A and 17B illustrate a block diagram of an exemplary configuration for the presentation instrument subject area, according to one embodiment of the invention.

FIG. 18 illustrates a block diagram of an exemplary configuration for the party subject area, according to one embodiment of the invention.

FIGS. 19A, 19B, 19C, 19C1, 19D, 19D1, and 19D2 illustrate a block diagram of another exemplary configuration for the party subject area, according to one embodiment of the invention.

FIGS. 20A, 20B, and 20C illustrate a block diagram of an exemplary configuration for the account subject area, according to one embodiment of the invention.

FIGS. 21A, 21B, and 21C illustrate a block diagram of an exemplary configuration for the transaction subject area, according to one embodiment of the invention.

FIG. 22 illustrates a block diagram of an exemplary configuration for the product subject area, according to one embodiment of the invention.

FIG. 23 illustrates a block diagram of an exemplary way of relating entries in different databases for facilitating one embodiment of the invention.

DETAILED DESCRIPTION

Referring now to FIG. 1A, a data architecture for implementing an embodiment of the invention is shown. Namely, in FIG. 1A, a data architecture is shown that is divided into eight different subject areas, relationships between the subject areas, and the resulting associations between them. For example, FIG. 1A illustrates in system 100 the following subject areas: party 101, account 102, presentation instrument 103, communication point 104, transaction 105, balance 106, product 107 and rules 108. Furthermore, between subject areas, different associations are shown. For example, between party 101 and communication point 104, party-communication point associations 130 is shown. Similarly, between party 101 and account 102, an account-party role association is shown. Furthermore, between presentation instrument 103 and account-party role associations 120, a presentation instrument-account-party role 122 relationship is shown. Similarly, communication point usage 132 is shown positioned between the party-communication point associations 130 and the account-party-role associations 120. FIG. 1A also shows between product 107 and balance 106, the product-balance associations 150. Furthermore, it shows between account 102 and product 107, an account-product associations 160. Finally, between account 102 and balance 106, FIG. 1A shows an account-balance associations 140.

FIG. 1B illustrates a processing system for implementing the data architecture shown in FIG. 1A. Furthermore, each of the subject areas, relationships, and associations shown in FIG. 1A are illustrated by a computer and database in FIG. 1B. A computer and database can be used to store independently the information for each subject area: party 101', account 102', presentation instrument 103', communication point 104', transaction 105', balance 106', product 107', and rules 108'. In addition, a database and computer can be utilized to store the information for each relationship established between the different subject areas. For example, the database can be used to store internal identifiers from the party database and account database in database 120' for storing information in regard to an account-party role. Similarly, a database can be utilized to store information for the party-communication point relationship as database 130'. Other databases are shown in FIG. 1B in conformance with FIG. 1A, such as communication point usage database 132', PI-account-party-role database 122', account-balance database 140', account-product database 160', and product-balance database 150'. Each database is designated in conformance with the architecture shown in FIG. 1A.

Each of the computers and databases shown in FIG. 1B can be implemented by the exemplary computer system illustrated in FIG. 13. FIG. 13 broadly illustrates how individual system elements can be implemented. System 1300 is shown comprised of hardware elements that are electrically coupled via bus 1308, including a processor 1301, input device 1302, output device 1303, storage device 1304, computer-readable storage media reader 1305a, communications system 1306 processing acceleration (e.g., DSP or special-purpose processors) 1307 and memory 1309. Computer-readable storage media reader 1305a is further coupled to computer-readable storage media 1305b, the combination comprehensively representing remote, local, fixed and/or removable storage devices plus storage media, memory, etc. for temporarily and/or more permanently containing computer-readable information, which can include storage device 1304, memory 1309 and/or any other such accessible system 1300 resource. System 1300 also comprises software elements (shown as being currently located within working memory 1391) including an operating system 1392 and other code 1393, such as programs, applets, data and the like.

System 1300 has extensive flexibility and configurability. Thus, for example, a single architecture might be utilized to implement one or more servers that can be further configured in accordance with currently desirable protocols, protocol variations, extensions, etc. However, it will be apparent to those skilled in the art that embodiments may well be utilized in accordance with more specific application requirements. For example, one or more system elements might be implemented as sub-elements within a system 1300 component (e.g. within communications system 1306). Customized hardware might also be utilized and/or particular elements might be implemented in hardware, software (including so-called "portable software," such as applets) or both. Further, while connection to other computing devices such as network input/output devices (not shown) may be employed, it is to be understood that wired, wireless, modem and/or other connection or connections to other computing devices might also be utilized. Distributed processing, multiple site viewing, information forwarding, collaboration, remote information retrieval and merging, and related capabilities are each contemplated. Operating system utilization will also vary depending on the particular host devices and/or process types (e.g. computer, appliance, portable device, etc.) Not all system 1300 components will necessarily be required in all cases.

The data architecture shown in FIG. 1 A provides a great deal of flexibility for managing data or providing data processing for a service industry. Prior data architectures in the credit card industry, for example, relied upon the referencing of all the information for a customer's account through the use of a single identifier. Similarly, in the utility billing system, all the information for a particular user is referenced as a single set of combined data. The architecture illustrated in FIG. 1A does not reference all of the information for a service by a single identifier for a static record. Rather, it separates information into distinct subject areas. Thus, one is capable of providing a great deal of flexibility to data processing. For example, one can modify the data for a particular party without disrupting processing of that party's account. Essentially, no restructuring of other subject areas is required because an individual subject area can be modified without impacting the other subject areas. Therefore, this type of system provides a great deal of flexibility and functionality that existing systems cannot accomplish.

Referring to FIG. 1A, the various subject areas can be seen. Furthermore, the relationships and resulting associations established between many of the different subject areas can be seen as well. These relationships and associations permit the processing of stored data for desired functionality.

Account

Referring to block 102 of FIG. 1A, the account subject area can be seen. The account subject area is a collection of data about the mechanism used to record, measure, and track financial and non-financial information related to a contractual agreement. Accounts can be characterized by specific components, terms or conditions of data of the service or product that prompted the account's creation. An account can further be characterized by financial and demographic data. Thus, according to one embodiment of the invention, the account facilitates the management, tracking, and reporting of transaction activities. The specific characteristics of an account may vary based on the type of product, product components, party, or terms and conditions established in the contractual agreement.

An account is associated to one or more parties who can use one or more presentation instruments to generate transactions. Furthermore, according to one embodiment of the invention, an account, a party, and a presentation instrument can operate as independent subject areas and can be related in an association to form a unique occurrence of the relationship.

The account subject area provides for the separation of account data from party data and presentation instrument data. Thus, the identity of a party who fulfills a specific business role for a particular account is not stored as part of the account database. Rather, it is kept in the party database and related to the account database where the assigned business role is maintained. Similarly, the data describing the presentation instrument, such as a credit card or smart card, is not stored as part of the account's data. Rather, this information can be related with the account's data by an association database.

An account can participate in one or more relationships with other accounts, for example, as a member of a business group or family group of accounts. Furthermore, multiple presentation instruments can generate transactions for a single account, a group of accounts, or a single member of a group. Thus, a single account could be related with a smart card, a magnetic stripe card, a biometric identifier, etc., each of which could be utilized to initiate a transaction associated with the account.

For example, an individual account associated with several parties can be related with one presentation instrument to generate transactions. Alternatively, a family account with each family member having individual or subordinate accounts can be implemented with the account subject area. Furthermore, a corporate account with one or more dependent accounts could be implemented through the account database. Thus, it is clear that by segregating data for an account, flexibility is provided under the data architecture shown in FIG. 1A.

Party

Referring to FIG. 1A, the party 101 subject area can be seen. The party subject area is a collection of data about individuals, organizations, or organization units that the service provider needs to have information about in order to carry out business operations either directly or indirectly. Parties can be related to other parties as well as to accounts, presentation instruments, balances, products, communication points, and transactions. They can participate in agreements, groups, and organizations. They can act as owners, stewards, contact points, and catalysts of business functions and rules.

For example, customer John Joseph Doe may be known to one client of the data processor as J. Doe, and to another client of the data processor as J. Joseph Doe, Sr. Each client (e.g., Bank One and XCEL Energy) may add a different address for John Doe even though both have the same social security number for him and both know that his birth date was Jun. 10, 1942. The names used by one client of the data processor are not combined with those used by the other clients of the data processor because each is relevant only within the context of the business that provided the information. The party subject area however can store identifying information for the party, such as name and social security number that can be related to many different accounts.

The account to which a party is associated is not stored as part of the party's database. Similarly, the communication point at which a party can be contacted is also not stored as part of the party's database. Rather, the account and/or communication point are related to the party by associative databases.

The party database can provide flexibility to maintain multiple names, statuses, and alternative identifiers for an individual, organization, or organizational unit. It also allows a service organization to manage multiple roles in relationships for an individual, organization, or organizational unit. It further allows one to build and maintain structural relationships between individuals, organizations, and/or organizational units such as peer-to-peer relationships or hierarchical relationships.

Examples of the relationships between parties are customers of a service provider (credit card companies, utility companies, healthcare providers), clients of a data processing system such as receiving banks, vendors, merchants, contacts, business partners, and employees.

Presentation Instrument

Referring again to FIG. 1A, a block 102 entitled "presentation instrument" is shown. The presentation instrument subject area is a collection of data about physical or virtual devices used as a transaction catalyst to generate transactions, either monetary or non-monetary. The presentation instrument data is stored independently from party and account data in order to facilitate its management. Characteristics of presentation instrument data can be modified without affecting the account or the account status. Presentation instruments are not restricted to being physical devices, such as paper invoices, plastic credit cards, plastic magnetic stripe cards, or smart cards. Rather, they can also be virtual devices, such as a stated account number or an electronic identifier. Any catalyst for initiating a transaction against an account is considered a presentation instrument.

The presentation instrument data can be independently managed. Thus, the presentation instrument data may be related to one or more party/product/account relationships. For example, a party could require reissuance of a "presentation instrument", such as a credit card, without affecting other credit cards on the same account. Similarly, a virtual presentation instrument could be created for an account to allow the party to enable e-commerce activity without affecting any associated physical presentation instruments.

Communication Point

Another subject area shown in FIG. 1A is communication point 104. The communication point subject area identifies the destination points used for the delivery of communications, e.g., the virtual or physical points where communication(s) can be received. A communication point can be a geographic address; an electronic address, such as an email address; a telecommunication number, such as a telephone or fax number; or any other type of destination point to which a communication can be addressed. Typically, an association will be established between a party and a communication point to describe the relationship of the party to a particular communication point; e.g., one geographic address might be related to a party as the party's home address, another to a party as the party's work address, etc. These associations can be stored in a different database and/or can be used to specify what types of communications can be delivered to them. However, the communication point database stores information about the communication point itself to which relationships are established and various types of communications are sent.

One of the benefits of storing information in a communication point database is that the information can readily be changed when the issuing body changes the content for the communication point. Furthermore, many different communication points can be utilized for a single party by relating the party to those communication points and/or a single communication point can be related to many parties. This provides great flexibility for sending communications to a party depending upon the type of relationship that party has with a communication point and the time at which that relationship is used. Another example of the inherent flexibility is that as business requirements change and new types of communication points are discovered they can be added to the processing system with very little effort.

For example, a communication point could be used to send a specific party the annual statement for a credit card company. The party may only live at its home address for part of the year and live at a different address for another part of the year, as is often the case for retirees. Thus, multiple communication points could be included in a communication point database and an association could be established with the party database to specify the relationship, timing, and usage of the communication point data. These associations can be stored in different databases such as party-communication point database 130 and communication point usage database 132. Thus, the annual statement could be directed to one or more geographic or e-mail addresses during a first part of the year and yet a single geographic address during another part of the year.

One of the benefits of storing information in a communication point database is that the communication point information can change without the relationship to a party changing. Thus, for example, if a district revises the zip code configuration for a city, the zip code for a location can change but the relationship as the primary mailing address will not change. Thus, only the communication point database needs to be updated with the revised zip code information. This can be important in some industries such as the credit card rating industry in which one's credit rating is determined in part by how many times one has moved. The arbitrary redistricting of zip codes, for example, would cause one's address to change, by definition, under the old data processing methods even though the geographic location did not change. Thus, the credit rating rules used to evaluate applicants would consider the change in zip code to be a change in address, causing the credit rating for an individual to worsen--even though the person never moved. However, the system shown in FIG. 1A allows the characterization of the geographic address, i.e., the revised zip code information, to be entered without indicating that the relationship to that geographic location has changed. Thus, under the system shown in FIG. 1 A, a post office that revises the zip codes for an individual would not affect the credit rating for that individual. This is yet another example of the flexibility and efficiency of the separation of data brought about by the data processing architecture shown in FIG. 1A.

As another example of the functionality that can be achieved with separated communication point data and unique party-communication point associations, one can envision all the different types of communications that can be sent for a credit card account. Thus, a monthly statement could be directed to a home address for six months of the year and a vacation address for the remaining six months of the year. Furthermore, an overcredit warning could be sent to an email address if one approaches the limit on a credit card. Furthermore, a late payment notice could be faxed to one's home address or a second late notice could be implemented by a telephone call to the individual's home phone. Each of the above communication destinations (i.e. home address, e-mail address, fax, telephone) could easily be altered and stored in the communication point database. However, associations between the party and any "address" in the communication point database can be maintained separately in a database. Thus, in comparison with traditional credit card systems in which a statement, for example, is always sent to the same address, this embodiment of the invention provides greater flexibility for communicating with a party.

Transaction

Referring again to FIG. 1A, the transaction subject area 105 is shown. The transaction subject area stores data relating to transactions conducted for a service. The transaction subject area stores a collection of data about business actions or events that impact implied financial worth or cause movement of funds from one account to another and/or impact non-financial properties (e.g., names, addresses, requests for new plastics). Thus, the transaction database can store information relating to previous purchases for a credit card account, for example. Similarly, it can store utility bill payments or billing statements for a utility service. Essentially, it stores all the data that memorializes transactions that occur for an account. In the case of the credit card industry, many of the service groups such as Mastercard and Visa have a predefined format for storing transaction information. The transaction subject area can understand these external formats, can document them as they are presented, and can broker them into internal format that can be posted to the appropriate balances on an associated account.

Balance

The balance subject area 106 in FIG. 1A is utilized to store balance information for products and accounts. Essentially, a balance is a total maintained by balance type and period for an account or account party role that serves as a mechanism for accumulating financial (debit/credit) activity. Examples of an account balance are the balance due on a utility bill or a credit card bill. This balance information can include the date of the balance, the amount of the balance, etc. The balance database keeps a balance history for each account as desired.

The balance database provides a great deal of flexibility in the types of balances that can be kept for an account. For example, a promotional balance can be used for a new product, such as a new credit card line. A late fee balance can be kept separate for a credit card as well. Similarly, an overlimit balance can be kept for an account. In addition, a big ticket promotional balance can be utilized for an account. Such promotional balances might include how much one pays toward a specific product such as a refrigerator. Thus, if a special promotional program is in existence for refrigerators, for example, the balance database can store how much money has been applied towards purchases which trigger the grant of the reward towards the refrigerator.

Thus, the balance database provides for all different kinds of balance information to be kept that can be utilized for an account or specified for a particular product line. It provides great flexibility in that the balance information can be varied and different balances can be selected for a product line.

Product

The product subject area 107 is a collection of data about a named item or service intended for sale by one party to another party for the purpose of generating revenue. Thus, parties who participate in product campaigns typically take on different roles such as those who offer products to market, those who service a product, and those who use the services provided by the product. As an example of those who offer a product to market, an issuing bank which issues credit cards to customers is one example. Similarly, a money transfer agent such as Western Union, which offers money transfer services to parties, is another example. Similarly, companies that operate as third parties for issuing and acquiring banks, such as First Data Resources and First Data Merchant Services, fall into this category as well. As an example of those who service a product, First Data Resources or any other third party processor is an example of one who performs this service. Finally, as an example of those who use the services provided by the product, a consumer using a credit card is an example of that category.

Products can be defined by party-selected component data. This replaces program-implemented features and functionality. Thus, an issuing bank party can select the components that it wishes to include as part of a new product to be offered to the purchasing public, each of which would be a separate party. This allows the issuing bank, for example, to select the interest rate, credit line, payment options, etc.

Another example of a product is a utility service. Thus, the rate for gas and electricity can be defined separately. In addition, the late fees can also be defined as separate comp