Source: http://www.google.com/patents/US7419094?dq=6011510
Timestamp: 2015-10-08 21:07:29
Document Index: 760827217

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'arty 101', 'arty 101', 'arty 101', 'arty 101']

Patent US7419094 - System for maintaining transaction data - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsAccording 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...http://www.google.com/patents/US7419094?utm_source=gb-gplus-sharePatent US7419094 - System for maintaining transaction dataAdvanced Patent SearchPublication numberUS7419094 B2Publication typeGrantApplication numberUS 10/972,149Publication dateSep 2, 2008Filing dateOct 22, 2004Priority dateFeb 24, 2004Fee statusPaidAlso published asUS20050185774, US20050185780, US20050187782, US20050187830, US20050187841, US20050187842, US20050187864, US20050187865, US20050187938, US20050192874, US20060093110Publication number10972149, 972149, US 7419094 B2, US 7419094B2, US-B2-7419094, US7419094 B2, US7419094B2InventorsMichael B. Grear, Thomas M. MillerOriginal AssigneeFirst Data CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (73), Non-Patent Citations (12), Referenced by (9), Classifications (27), Legal Events (5) External Links: USPTO, USPTO Assignment, EspacenetSystem for maintaining transaction data
US 7419094 B2Abstract
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.
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.
storing said transaction relationship type code and said first transaction internal identifier and said second transaction internal identifier in a transaction relationship database.
retrieving said first transaction internal identifier from said transaction database.
retrieving said second transaction internal identifier from said transaction database.
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
This application claims the benefit under 35 USC �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 �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.
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.
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.
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.
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.
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. Fo