System for transaction processing

• US 20050187842A1
• Filed: 10/22/2004
• Published: 08/25/2005
• Est. Priority Date: 02/24/2004
• Status: Abandoned Application

• Current Assignee: First Data Corporation (Fiserv Incorporated)
• Original Assignee: First Data Corporation (Fiserv Incorporated)
• Inventors: Grear, Michael B., Donlin, Gretchen, Bell, Richard T., Harrington, Teresa M.
• Application Number:
  US10/972,151
• Publication Number:
  US 20050187842A1
• Time in Patent Office: Days
• US Class Current: 705/35
• CPC Class Codes: G06Q 20/10 specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
• CPC Class Codes: G06Q 20/382 insuring higher security of transaction
• CPC Class Codes: G06Q 30/0601 Electronic shopping [e-shopping]
• CPC Class Codes: G06Q 40/00 Finance; Insurance; Tax strategies; Processing of corporate or income taxes
• CPC Class Codes: G06Q 40/12 Accounting
• CPC Class Codes: H04L 12/66 Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
• CPC Class Codes: H04M 15/48 Secure or trusted billing, e.g. trusted elements or encryption
• CPC Class Codes: H04M 15/68 Payment of value-added services
• CPC Class Codes: H04M 2215/0156 Secure and trusted billing, e.g. trusted elements, encryption, digital signature, codes or double check mechanisms to secure billing calculation and information
• CPC Class Codes: H04M 2215/0196 Payment of value-added services, mainly when their charges are added on the telephone bill, e.g. payment of non-telecom services, e-commerce, on-line banking

Abstract

According to one embodiment of the invention, an architecture is provided for a data processing system 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.

Claims

1. A method of storing data for a service business, said method comprising:

storing party data for said business as a separate set of data;

storing account data for said business as a separate set of data;

storing presentation instrument data for said business as a separate set of data;

storing product data for said business as a separate set of data;

storing communication point data for said business as a separate set of data;

storing balance data for said business as a separate set of data; and

storing rules data for said business as a separate set of data.

2. The method as described in claim 1 and further comprising:

storing each of said sets of data on separate databases.

3. The method as described in claim 1 wherein each of said separate sets of data is stored without reference to any of said other sets of data.

4. The method as described in claim 1 and further comprising:

storing a set of associative data for relating said account data and said party data.

5. The method as described in claim 4 wherein said storing a set of associative data comprises:

storing as part of said set an internal identifier for an entry from said account data; and

storing as part of said set an internal identifier for an entry from said party data.

6. The method as described in claim 1 and further comprising:

storing a set of associative data for relating said party data and said communication point data.

7. The method as described in claim 6 wherein said storing a set of associative data comprises:

storing as part of said set an internal identifier for an entry from said party data; and

storing as part of said set an internal identifier for an entry from said communication point data.

8. The method as described in claim 1 and further comprising:

storing a set of associative data for relating said account data and said balance data.

9. The method as described in claim 8 wherein said storing a set of associative data comprises:

storing as part of said set an internal identifier for an entry from said account data; and

storing as part of said set an internal identifier for an entry from said balance data.

10. The method as described in claim 1 and further comprising:

storing a set of associative data for relating said account data and said product data.

11. The method as described in claim 10 wherein said storing a set of associative data comprises:

storing as part of said set an internal identifier for an entry from said account data; and

storing as part of said set an internal identifier for an entry from said product data.

12. The method as described in claim 1 and further comprising:

storing a set of associative data for relating said balance data and said product data.

13. The method as described in claim 12 wherein said storing a set of associative data comprises:

storing as part of said set an internal identifier for an entry from said balance data; and

storing as part of said set an internal identifier for an entry from said product data.

14. A method of storing data for a service business, said method comprising:

storing party data identifying a party as a separate set of data;

storing account data identifying an account as a separate set of data;

relating said party data with said account data so as to identify said party as playing a role on said account.

15. The method as described in claim 14 wherein said relating said party data with said account data comprises:

assigning a first identifier with said party data;

assigning a second identifier with said account data;

associating said first identifier with said second identifier

assigning a role to the association so as to relate said party data with said account data and define the relationship.

16. The method as described in claim 14 wherein said party data comprises:

a name of said party; and

a role played by said party.

17. The method as described in claim 14 wherein said account data comprises:

an account type for describing an account; and

an account identifier for identifying a specific account of said account type.

18. A system for storing data for a service business, said system comprising:

a party database for storing party data identifying a party as a separate set of data;

an account database for storing account data identifying an account as a separate set of data;

wherein said party data and said account data identify a party on an account.

19. The system as described in claim 18 wherein said party database and said account database each have a separate processor.

20. The system as described in claim 18 and further comprising:

an account-party database for relating said party data with said account wherein said party data data comprises;

a name of said party.

21. The system as described in claim 20 wherein said account data comprises:

an account type for describing an account; and

an account identifier for identifying a specific account of said account type.