Multi-processing financial transaction processing system

• US 6,442,533 B1
• Filed: 10/28/1998
• Issued: 08/27/2002
• Est. Priority Date: 10/29/1997
• Status: Expired due to Fees

• Current Assignee: N_Gine Incorporated
• Original Assignee: N_Gine Incorporated
• Inventors: Hinkle, William H.
• Primary Examiner(s): Hafiz, Tariq R.
• Assistant Examiner(s): Robinson-Boyce, Akiba
• Application Number:
  US09/181,698
• Time in Patent Office: 1,399 Days
• Field of Search: 705/37, 705/38, 705/36, 705/35, 705/30, 705/32
• US Class Current: 705/36.00R
• CPC Class Codes: G06Q 10/1091 Recording time for administrative or management purposes
• CPC Class Codes: G06Q 20/401 Transaction verification
• CPC Class Codes: G06Q 40/00 Finance; Insurance; Tax strategies; Processing of corporate or income taxes
• CPC Class Codes: G06Q 40/02 Banking, e.g. interest calculation or account maintenance credit or loans G06Q40/03
• CPC Class Codes: G06Q 40/03 Credit; Loans; Processing thereof
• CPC Class Codes: G06Q 40/04 Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
• CPC Class Codes: G06Q 40/06 Asset management; Financial planning or analysis
• CPC Class Codes: G06Q 40/12 Accounting
• CPC Class Codes: G06Q 40/125 Finance or payroll
• CPC Class Codes: G06Q 40/128 Check-book balancing, updating or printing arrangements
• CPC Class Codes: G06Q 99/00 Subject matter not provided for in other groups of this subclass

Abstract

A financial transaction processing system is disclosed, wherein substantial processing efficiencies are provided with, additionally, a substantial decrease in the size of the executable code. Each transaction processed by the transaction processing system is described by a transaction data descriptor that includes a series of subtransaction data descriptions of actions that can be performed independently of one another. Thus, complex transaction processing logic is substantially removed from the executable code, and instead such transaction data descriptors are processed interpretatively. Moreover, the independence of the subtransactions allows the subtransactions of a transaction to be processed in parallel when performed on a multiprocessor computer. Additionally, the transaction processing system provides account balancing enhancements in that there are control columns in various data tables that are automatically updated during transaction processing so that by comparing control column totals, an indication of the integrity of current financial records is provided. Additionally, the transaction processing system provides full auditability in that any changes to financial data can be traced for any effective period of time into the past so that auditors can periodically perform a full audit of the financial transaction data retained by the transaction processing system.

Claims

1. A method for processing financial transactions for disparate applications, comprising:

providing a system that facilitates (1) flexibility to satisfy customized needs of an enterprise or individual, (2) auditability to track all financial transactions from data inception to permanent archives, without substantial error, and (3) multi-processing of each individual transaction to expedite response times, said user definability consists essentially of steps a-e;

(a) defining a set of driven tables comprising a set of data records or a set of financial reports selected from the group consisting of balance sheets, income statements, cash flow statements, performance measurements, capital gains, pending income/expense, pending capital adjustments, general ledger, and transaction ledger;

(b) defining a set of data records that provides verification of incoming data for the processing of accounts, financial entities, account structures, management philosophies, management information, and any of said financial reports;

(c) defining a first driving table comprising a set of disparate financial transactions used to update any one or more of said reports set forth in step (a), each said transaction having one entry in a transaction master table which identifies a transaction name;

(d) defining a second driving table comprising a set of disparate processing algorithms in a transaction processing table for each transaction in step (c), each of said algorithms containing one operator and first and second operands, said first operand identifying a specific input variable in said data records and said second operand identifying a specific output value to be updated in one more of the financial tables set forth in step (a);

(e) aggregating a set of incoming random disparate financial transactions into a single machine readable input table;

wherein said step of multi-processing consists essentially of;

(f) reading an input record from said input table, said input table containing at least three or more variables, two of said variables which comprise at least a licensee identifier and a transaction identifier, with all remaining of said variables representing input values;

(g) matching said licensee identifier and said transaction identifier with a like licensee identifier and transaction identifier in said transaction master table, said transaction master table containing a list of all financial transactions as set forth in step (c);

(h) matching said licensee identifier and said transaction identifier on said data record with a set of algorithms in said transaction processing table as set forth in step (d);

(i) assigning the next available algorithm matched in step (h) from said transaction processing table to be processed to the next available processor in a multi-processing machine to update one or more values in said driven table with a specific value identified in said data record;

(j) returning to said next algorithm identified in step (d) and continuing processing until all of said algorithms for said specific transaction are processed;

(k) repeating step (f) to read a next input record until all of said input records are processed;

(l) adding subsequent data records to said driven tables as set forth in step (a);

(m) adding subsequent data records to said transaction master as set forth in step (c); and

(n) adding subsequent data records to said transaction processing table sot forth in step (d).

2. The method as set forth in claim 1, further comprising:

(a) creating at least three control fields for every one of said data records in at least three control tables;

(b) updating said three control fields for a specific one of said data records in each of said three control tables with thee values from each transaction process; and

(c) aggregating said at least three control fields in all of said data records in at least said three control tables.

3. The method as set forth in claim 1, wherein at least some of said data records are transferred from a first set of tables to a second set of tables, wherein data records in said second set of tables cannot be changed.

4. The method as set forth in claim 1, wherein sad data records comprise a data field selected from the group consisting of:

(1) Insert Date;

(2) Insert Sequence Number;

(3) Insert User Identifier;

(4) Insert Update Date;

(5) Update Sequence Number;

(6) Update User Identifier;

(7) Delete Date;

(8) Delete Sequence Numbers;

(9) Delete User Identifier; and

(10) Number of Times Updated.

5. The method as set forth in claim 1, further comprising reversing at least one of said individual transaction.

6. The method as set forth in claim 1, wherein said algorithms are processed on separate processors.

7. The method as set forth in claim 1, wherein said step of multi-processing comprises overlapping of at least one of said algorithms.

8. The method as set forth in claim 1 wherein said step of processing is performed on a multi-processing machine.