Appendix — Dann v. Johnston

Supreme Court brief1976

Ask Donna

What actually matters in this document.

Text

APPENDIX

Supreme Court of the United States

OCTOBER TERM, 1974

No. 74-1033

C. MARSHALL DANN, COMMISSIONER OF PATENTS AND

TRADEMARKS,

Petitioner

—v.—

THOMAS R. JOHNSTON

ON WRIT OF CERTIORARI TO THE UNITED STATES

COURT OF CUSTOMS AND PATENT APPEALS

PETITION FOR A WRIT OF CERTIORARI FILED FEBRUARY 18, 1975

CERTIORARI GRANTED MAY 12, 1975

ae de

Supreme Court of the United States

OCTOBER TERM, 1974

No. 74-1033

C. MARSHALL DANN, COMMISSIONER OF PATENTS AND

TRADEMARKS,

Petitioner

—?)

THOMAS R. JOHNSTON

ON WRIT OF CERTIORARI TO THE UNITED STATES

COURT OF CUSTOMS AND PATENT APPEALS

INDEX

Page

RT RRC LN KL TTY te UE ORB Ow tS a ee OL 1

ERENT RRO OOO SOTO OR AIT EEE POTTS SOOO 3

Fe Te algeria butignegpigtibeenennneen 68

Examiner’s Answer dated November 3, 1970 00. 86

Portion of Dirks Patent 3,348,188 ............................................ 94

RRR a RSE SE SEITE SCR ASE SR A a re a 107

Notice of Appeal to Court of Customs and Patent Appeals

dated December 28, 19711 ............ SA ated aki a a 110

*Opinion of the United States Court of Customs and Patent

Appeals dated September 19, 1974 00000000....00..ccccececccccceeeeceeee 1A

Supreme Court’s Order of May 12, 1975, granting the peti-

I as 116

* Not reprinted in Joint Appendix. Citations are to appendix of

Petition for Writ of Certiorari.

DOCKET ENTRIES

IN THE MATTER OF THE APPLICATION

oF THOMAS R. JOHNSTON

Board of Appeals Serial No. 624,741

Filing Date March 20, 1972

Term and Docket No. 9088

Date Proceedings and Orders

Counsel for appellant: Morton C. Jacobs

Commissioner of Patents

March 28, 1972 Motion of appellant to suspend all pro-

ceedings in this appeal until final action of the Su-

preme Court in Ex parte Bension, et al No. 71-485

P A No. 8376, filed.

March 31, 1972 Above motion, granted.

February 15, 1973 Suspension lifted pursuant to letters

of counsel dated January 26, and February 15, 1973.

September 10, 1973 PRINTED RECORD, FILED.

October 12, 1973 Stipulation to extend time for filing

appellant’s brief to November 19, 1973, filed and ap-

proved.

November 13, 1973 Stipulation to extend time for filing

appellant’s brief to December 19, 1973, filed.

November 15, 1973 Above stipulation, approved. See

letter in jacket.

December 13, 1973 Motion (joint) to extend time for

filing appellant’s brief to January 18, 1974 and Com-

missioner’s brief to 60 days from filing of appellant’s

brief, filed and granted.

Date Proceedings and Orders

January 21, 1974 BRIEF FOR APPELLANT, FILED.

March 21, 1974 BRIEF FOR COMMISSIONER,

FILED.

April 4, 1974 Motion of appellant to extend time for

filing a Reply Brief to April 25, 1974, filed.

April 9, 1974 Above motion, granted.

April 24, 1974 REPLY BRIEF FOR APPELLANT,

filed.

May 8, 1974 Argued and submitted.

August 12, 1974 Motion of appellant for leave to file

publication, filed.

August 26, 1974 Opposition by Commissioner of Patents

to above motion filed.

August 30, 1974 Appellant’s reply in support of mo-

tion to filed publication filed.

September 3, 1974 Above motion denied, Markey, Chief

Judge.

September 19, 1974 REVERSED, Baldwin, Judge. Dis-

senting opinion by C. J. Markey. Dissenting opinion

by Judge Rich.

October 11, 1974 FINAL MANDATE ISSUED TO

COMMISSIONER OF PATENTS.

Feb. 18, 1975 Writ of Certiorari No. 74-1033 filed in

Supreme Court on Feb. 18, 1975.

[SPECIFICATION |

APPLICATION OF THOMAS R. JOHNSTON, FILED

MARCH 21, 1967, SERIAL NUMBER 624,741, FOR

MACHINE SYSTEM FOR AUTOMATIC RECORD

KEEPING OF BANK CHECKS AND DEPOSITS

Abstract of the Disclosure. An automatic record-keep-

ing system is provided which is based on machine-read-

able records of the financial transactions (checks or de-

posit slips) of a bank customer. In addition to the usual

data provided on the transaction slips, a set of code

characters identifying the bookkeeping category is also

provided. A data processor, such as a stored program

digital computer, processes all of the machine-readable

records, together with a master file carrying individual

charts of accounts (i.e. the bookkeeping categories) for

the different customers. Output reports are periodically

generated on simple forms which present the customer’s

records in accordance with his own chart of accounts

and accounting procedures.

This invention relates to an automatic record-keeping

machine system, and more particularly to such a system

suitable for record keeping and bank checks and deposits.

Automatic data processing equipments employing digi-

tal computers have been developed for the handling of

much of the record-keeping operations involved in a bank-

ing system. The checks and deposit slips are automati-

cally processed by forming those items as machine-read-

able records; that is, magnetic ink characters are im-

printed on the check, so that magnetic readers are en-

abled to process these checks and enter the data in a

computer system in the form of coded electrical signals.

Other character-reading machines operating on an optical

principle for automatically reading special optical type

fonts are also employed. With such machine systems,

most of the extensive data handling required in a bank

can be performed automatically.

It has been found that such data processing equipment,

with certain additions and modifications, can be em-

ployed to process automatically much, if not all, of the

individual record keeping required by a bank’s customers

to maintain their own personal and business financial

records. That is, as a supplement to the conventional,

periodic bank statement furnished to a bank customer,

a record summary is provided with makes unnecessary

much or all of the tedious bookkeeping and accounting

that the customers would otherwise have to perform.

Accordingly, it is among the objects of this invention

to provide a new and improved machine system for

automatic record keeping.

Another object is to provide a new and improved

machine system for automatic record keeping that func-

tions with an automatic system for banking operations.

Another object is to provide a new and improved

automatic record-keeping system whereby financial rec-

ords are kept and maintained with a minimum of manual

operation.

Another object is to provide a new and improved

automatic record-keeping system for many customers, in

which a chart of accounts is provided for each customer

which is individually adapted to his requirements.

Another object is to provide a new and improved

automatic record-keeping system for supplying financial

reports to many different customers on printed forms that

are small in size and simple in format and adaptable to

various accounting procedures.

In accordance with an embodiment of this invention,

an automatic record-keeping system is provided which is

especially adapted for use with automatic banking de-

vices for machine handling of the transactions (i.e. checks

or deposits) of demand-deposit accounts of bank cus-

tomers. Machine-readable records of each bank transac-

tion are generated directly on the check or the deposit

ticket. The data of such records incorporate those re-

quired for conventional banking system presently carried

on checks (or deposit tickets); namely, the customer’s

account number, amount of the transaction, and the type

of transaction (that is, whether a check or a deposit).

Another set of data forming a machine-readable record

is provided on each transaction, namely, a set of code

characters that identify the bookkeeping classification of

each transaction; this classification code is called the

“category number.” The category number is entered by

the customer on each transaction slip (check or deposit)

at the time it is prepared, in the form of a machine-

readable record by means of an appropriate device, or

in the form of a set of hand-written numeric characters

which are converted to a machine-readable record by the

customer’s bank.

In the customer’s bank, upon a deposit being made or

a check clearing the bank, the machine-readable transac-

tion records on the imprinted checks or deposit tickets

are read by a suitable document-reader device and stored

in a transaction file. To process the transaction file, the

automatic record-keeping system employs a data processor,

such as a programmable electronic digital computer, hav-

ing certain data storage files and a control system. In

addition to the transaction file, a master record-keeping

file is used to store all of the records required for each

customer in accordance with the customer’s own chart

of accounts. The latter is individually designed to the

customer’s needs and also constructed to cooperate with

the control system in the processing of the customer’s

transactions. The control system directs the generation

of periodic output reports for the customer which pre-

sent the customer’s transaction records in accordance

with his own chart of accounts and desired accounting

procedures. Printed forms of conventional size can be

used for the output reports, and a simple format can

be employed that is adaptable for automatic printing of

the different charts of accounts.

The foregoing and other objects of this invention, the

various features thereof, and the invention itself may

be more fully understood from the following description

when read together with the accompanying drawing, in

which:

Fig. 1A is a schematic block diagram of a computing

machine system for automatic handling of banking trans-

actions and record-keeping thereof in accordance with this

invention ;

Fig. 1B is a schematic block diagram of certain work-

ing storage sections of the memory of Fig. 1A;

Fig. 2 is a schematic flow diagram of a portion of

the machine system of Fig. 1A;

Fig. 3 is a schematic flow diagram of another portion

of the machine system of Fig. 1A;

Fig. 4 is a face view of a bank check having machine-

readable records in accordance with this invention for

automatic record keeping in the system of Fig. 1A;

Fig. 5A is a schematic block diagram of the organiza-

tion of variable data fields for a plurality of bank ac-

counts in a demand-deposit-account (DDA) master filed

as employed in the system of Fig. 1A;

Fig. 5B is a schematic block diagram of the organiza-

tion fields in DDA and record-keeping (RK) transaction

files as employed in the system of Fig. 1A;

Fig. 5C is a schematic block diagram showing the

organization of data fields in an RK master file as

employed in the system of Fig. 1A;

Fig. 5D is a schematic block diagram of the organiza-

tion of data fields in a portion of the file of Fig. 5C;

Fig. 5E is a schematic block diagram of the organiza-

tion of data fields in another portion of the file of Fig.

5C;

Fig. 6 is a schematic block and flow diagram of a por-

tion of the system of Fig. 3, for the master file main-

tenance run;

Fig. 7 is a schematic block and flow diagram of another

portion of the system of Fig. 3, for the transaction file

maintenance run;

Figs. 8A, B, C and D are schematic block and flow

diagrams of another portion of the system of Fig. 3,

for the transaction journal run;

Figs. 9A, B and C are schematic block and flow dia-

grams of another portion of the system of Fig. 3, for

summary sheet run;

Fig. 10 is a face view of a printed transaction journal

report form utilized in the transaction journal run;

Fig. 11 is a face view of a printed summary sheet

report form utilized in the summary sheet run;

Fig. 12 is a modified form of summary sheet report

form;

Fig. 13 is a top view with parts broken away of a

check imprinting device for making machine-readable rec-

ords directly on bank checks for use in this invention; and

Figs. 14A and Bare, respectively, perspective and frag-

mentary front face views of a check-folder and imprint-

ing device embodying this invention and for use in the

system of Fig. 1A.

In the drawing, corresponding parts are referenced

throughout by similar numerals.

In the system of Fig. 1A, a data processor (e.g. a

stored-program digital computer) embodying this in-

vention is employed. The computer may assume many

different forms that are well known in the art. For

example, it includes a memory 10 having a working stor-

age section 11, an arithmetic unit or processor 12, and a

control unit 14. Input devices are provided in the form

of a reader device 16 which accepts machine-readable

records 18 such as documents (e.g. bank checks and de-

posit slips) having special character formations. The

reader 16 is a suitable document reader for reading

prescribed character fields (imprinted on the documents

18 in magnetic ink or special optical type fonts, or

presented in punch-card form). A document imprinter

19 is used to enter the prescribed fields on the checks

or deposit slips 18 (e.g. it may be magnetic ink or special

type font imprinter or a card punch).

Supplementing the memory 10 are various storage-

filed devices such as a disc or drum memory or magnetic-

tape stores. One set of filed devices takes the form of

a set of tapes or discs 20 carrying the transaction, mas-

ter-file and other data that are supplied to appropriate

sections of memory 10 and are employed in the data

processor. Another set 22 carries updated files cor-

responding to the files 20 after certain processing opera-

tions have been performed. Another set of files 24

supply control programs or runs to the memory 10 for

directing various control operations in proper sequence.

The machine may be one operating with binary coded

electrical signals, with the signal combinations coded to

represent alphabetic and numeric characters in accord-

ance with any desired system. The files 20, 22, 24 con-

tain successive records having fields formed of such

character signal combinations. Fixed or variable char-

acter lengths may be used for these fields.

An output unit 26 for producing printed records may

take various forms that are available in the art. One

suitable form is a high-speed printer, and a plurality of

such printers may be used for concurrently handling

different types of printed output forms. The overall

control unit 14 for the data processor performs certain

sequences of operation in accordance with the run of

the control programs established in the memory 10, and

effectuates control of the various portions of the system.

In accordance with the operations to be performed in

the system of Fig. 1A, the paths of information flow

between the various sections of the system and the

memory 10 are shown in full lines, while the paths of

flow of control signals from the control unit 14 to the

other portions of the system are shown in broken lines.

The system of Fig. 1A is illustrated further by the

flow diagrams of Figs. 2 and 3. A plurality of ordinary

bank checks 40, bank deposit slips 42, and other types of

bank transaction slips 44 are currently handled in a

manual fashion in present-day banking systems. Batches

of such transactions 40, 42 and 44 are proved 45 (checked

for accuracy) by an operator, such as the bank teller,

and the various data sections thereof are placed in

machine-readable form directly on the transaction slips

by the imprinter 19. One form of well known device used

for this purpose is a magnetic-ink imprinter customarily

used by banks for ordinary processing of checks and the

like.

A suitable form of check embodying this invention is

shown in Fig. 4. This check may assume any of the

customary printed formats for bank checks and, in ad-

dition, has a three-digit field 46 at a suitable location

on the check (for example, just in front of the signature

line thereof). This check, when it is employed with the

well known form of magnetic-ink coding, receives a

plurality of data fields along the lower edge thereof.

One such field is the transit-number field 48 which carries

the bank number and routing number for automatic

processing of the check in accordance with present-day

systems. Another field 50 incorporates the account num-

ber (Acctno) of the customer on whose account the

check is drawn. The fields 48 and 50 are customarily

imprinted on bank checks prior to their being issued

to the bank customer. Customarily, an amount field 52

is imprinted on the check at the time of proofing (45)

by the imprinter 19 in the bank on which it is drawn

(or at the clearing house) for automatic processing of

the checks. In addition, a check number (Chkno) may

be imprinted in the field 54 prior to issuance of the

checks to the customer, or subsequently by the bank.

A two-digit transaction code (Tranco) field 56 is

employed to identify the particular type of bank transac-

tion represented by the instrument. That is, the code

in field 56 indicates whether the document is a check,

a deposit slip, or some other particular type of bank

transaction. For checks, which represent the largest

number of transactions, this code field 56 is often left

blank. An additional field 56 carries the category num-

ber (Catno) inserted in the field 46 the writer of

the check. This Catno is entered in field 58 either by

the writer of the check (if he has an appropriate device

for completing the machine-readable record in accord-

ance with this invention) or by the bank on which the

check is drawn or which operates the record-keeping sys-

tem of this invention.

It has been found that a three-digit Catno is suitable

for classifying the record-keeping categories in account-

ing systems employed by most individuals in their per-

sonal bank accounts, by most businesses and professional

offices, and by most farmers. Such a three-digit Catno

is able to provide a simple technique for the writer of

checks to classify the RK category of the particular

transaction, and similarly to classify the source of in-

come represented by a bank deposit. In a very large

number of instances, less than a hundred such categories

are required to suitably classify a bank customer’s in-

dividual “chart of accounts” (i. e. for each customer,

his own list of Catnos, their descriptions, and record-

keeping interrelationships). A three-digit code affords

the flexibility of separating large areas of records; e. g.

categories in the 100 and 200 series may represent

different classes of income, and categories in the 300

and 400 series may represent different classes of ex-

penditures. Another example found suitable for family

RK classifications is to use the 300 series for family

income (both primary and secondary), the 400 series

for fixed family expenses (e. g. rent or mortgage), the

500 series for variable family expenses (e. g. food), the

600 series for other income (e. g. dividends, loans), the

700 series for family asset expenses (e. g. investments).

For agricultural accounts, it has been found suitable to

use the 000 series for family records, the 100 and 200

series for various crops, the 300 and 400 series for live-

stock, the 500, 600, 700 and 800 series for other farm

income and expenses, and the 900 series for capital

improvements (e. g. buildings and equipment). For some

applications, a two-digit Catno filed may be sufficient

to meet the needs of a wide range of customers (this

may be treated as a three-digit field, with the first digit

handled as “0”). Moreover, the Catno field may be

augmented by a fourth digit to afford the flexibility

of a more detailed breakdown of any particular area in

a customer’s chart of accounts (preferably provision for

a fourth digit is made in field 58, as indicated in Fig.

4). Such a breakdown may identify particular sales

regions or customers for a narticular business category,

or particular models within a product line. Moreover,

after a customer has developed and used his chart of

accounts, he may readily modify any desired part thereof

(as explained in more detail below) by adding or delet-

ing various Catnos and by inserting (with the fourth

digit) additional ones between two successive three-

digit codes. Generally, in setting up a particular chart

of accounts, certain Catnos in the sequence may be left

unused (blank) and undefined so that the customer has

the flexibility of using them at a later time as his

record keeping changes. If desired, an alphabetic code

may be used for the Catno, which may be easier for

certain customers to use.

As is described hereinbelow, a bank customer, in ac-

cordance with this invention, is individually supplied with

his own choice of a chart of accounts in which he selects

his own Catnos and the descriptive titles associated

therewith. Thereby, each check (Fig. 4) or correspond-

ing deposit slip (which generally has the same format as

that of Fig. 4, except that it has a different transaction

code in field 56 and the transit field 48 may be omitted

since it does not leave the bank) receives a Catno in

the code field 46 (if a handwritten field is utilized) and

in the machine-readable field 58 for automatic process-

ing thereafter as machine-readable records.

In the system of Fig. 2, as indicated above, the proc-

essing operation 45 (which forms part of the initial

processing known as the “entry run”) completes the

coding for the machine-readable fields of the checks 40

and deposit slips 42 if they have not previously been

completed. The bank operator also develops a proof tape

60 with the dollar amounts of the batches of checks and

deposit slips, and a proof tape 62 of the Catnos of all

of the checks and deposit slips. The outputs of the proc-

essing operation 45 are the machine-encoded checks 4,

deposit slips 42’, and other transactions 44’ which are

utilized, as machine-readable records, as inputs to the

system of Fig. 1A as they are read by the document

reader 16 in the machine operation 64 (Fig. 2).

In present-day automatic demand-deposit-account

(DDA) banking systems in which automatic data proc-

essing is provided, the document reader 16 is controlled

by an appropriate program to read the successive trans-

action records 40’, 42’, 44’ and assemble them as a daily

transaction file (TRAFI) 70. Each transaction 71, 73

(Fig. 5B) of such a file in accordance with this inven-

tion contains data fields respectively representing the

Acctno, Catno, Tranco, amount, Chkno, and the date as-

sociated with the transaction, as well as any other data

desired to be carried along. The TRAFI 70 consists of

such transaction records (TRAFR) 71, 73 assembled suc-

cessively on an output file 22 as they are read by the

document reader 16. The fields forming each TRAFR

(and the other records of Fig. 5) are preferably located

at prescribed portions of the record, which has a fixed

length, so that the desired fields may be readily located

and processed in accordance with the known techniques.

The TRAFI (Fig. 5B) ends with a special end-of-file

record, in accordance with standard techniques, which

follows the last TRAFR of the file; the other files are

similarly constructed with suitable end-of-file records.

The operation of the computer (Fig. 1A) is under the

control of a DDA Run of the control program which is

stored in the memory 10 at this time. In one conventional

form of such DDA run, the control] 14 operates the proc-

essor 12 to produce an accumulated net total of all of

the amounts in the transactions 40’, 42’, 44’ making up

a particular batch and controls the memory 10 and out-

put printer 26 to provide a proof listing 66 of all such

amounts and the accumulated net total thereof. In ac-

cordance with the system of this invention, the DDA run

is modified so that the control 14 similarly operates the

system to produce a listing of all Catnos and an accumu-

lated absolute total thereof. Thereafter, visual checks

(or, if desired, automatic comparisons and checks if the

contents of lists 60 and 62 are read into the machine)

may be made of the corresponding totals provided by the

proof listing of amounts 66 with the corresponding

amounts of the proof tape 60 to check on the accuracy

of the machine entry of the data. An additional such

check is provided by the comparison of the Catno totals

in the proof listing 68 with the corresponding total of the

proof tape 62; thereby an improved accuracy check is

provided.

In ordinary DDA processing, the daily TRAFI 70 is

sorted into Acctno sequence; in this invention the Acctno

field 50 and Catno field 58 are treated as one combined

field, and the sorting in operation 72 is by both. The

DDA Run controls the posting of the sorted TRAFRS to

the DDA master balance file 75 as indicated by operation

74.

The format of the DDA master balance file 75 is shown

in Fig. 5A, in which the sub-files 76. 77 making up each

account are assembled in Acctno sequence and the data

fields that form each account’s sub-file include successive-

ly those for Acctno (which may include the bank number

where a central processor for several banks is used), the

name and address of the bank customer, the account bal-

ance amount, an RK flag (if the account is to be proc-

essed in the record-keeping system), and one or more

other fields for data such as service charges to the cus-

tomer and bank statement cycle times. The DDA Run

locates a particular sub-file 76 or 77 in the master bal-

ance file 75 corresponding to a TRAFR Acctno and posts

the amount of the TRAFR to develop a new account bal-

ance in the corresponding field of that sub-file.

The output of the processing operation 74 is an up-

dated DDA master balance file 78. Subsequent to the

posting of each transaction, the RK flag field in that ac-

count’s sub-file 76 or 77 is tested (80) to determine if it

is an account that receives automatic record-keeping. If

so, the particular TRAFR is also transferred to an RK

TRAFI 82 that is built up for that day’s transactions.

The TRAFI 82 contains only those TRAFR 71, 73 for

RK Acctnos, which are arranged sequentially on one of

the output file devices 22. The DDA operation is com-

pleted for each account periodically in the usual fashion;

i. e. on those days when bank statements are to be gen-

erated, the customary bank statement 85 is printed out

(83) for each account, which statement carries the ac-

count balance as well as a listing of all of the transac-

tions for the statement period. The transactions for each

account during the bank statement period are indicated

either in a cumulative transaction file (which is assem-

bled on successive days by adding the current day’s trans-

action file to the previous day’s file) or by carrying the

cumulative transactions in the DDA master balance file

as a listing of transactions following the “other data”

field. In this invention, an additional output file 87 is

generated from the DDA processing 83; this file con-

tains a series of records for the RK Acctnos. Each such

record (148 in Fig. 5C) contains a “credit” field 150

(consisting of the total deposits on the monthly state-

ment), a “debit” field 151 (consisting of the total checks)

and a field 149 for a special identifier of that record.

These records are added to the RK master file, as ex-

plained below for Fig. 6, and for that purpose each rec-

ord also contains a change-instruction field that is coded

so that the record is added to the proper account sub- ile

of the RK master file.

The flow chart of Fig. 3 illustrates the processing of

the RK data to printed RK reports that are sent to the

bank customers and ordinarily with the usual bank state-

ments. The daily RK TRAFI 82 developed from each

day’s transactions for the RK accounts is added to the

RK TRAFI 84 (one of the files 20), which stores the

accumulated transactions of previous days. The proc-

essing 86 updates file 84 by inserting the TRAFR of file

82 in the proper order by Acctno, Catno and date. The

update processing 86 also serves to correct any errors

that may exist in the TRAFI 84, and correction records

88 are also suppiied to direct the desired changes in the

TRAFI. The output of the processing 86 is the updated

RK transaction file 92 (on one of the files 22), together

with a printed list 90 of all of the new TRAFR supplied

by the file 82 and all of the changes from the records 88.

An RK master file (MAFI) 94 (one of the files 20)

is utilized which contains all of the required RK infor-

mation about each RK account, including the customer’s

individual chart of accounts, as explained below. This

MAFI 94 is maintained by update processing 96, which

controls the performance of any changes, additions or

deletions of entire accounts, or parts of accounts, that

are specified by records 95. The output is an updated

RK MAFI 98, as well as a list 97 of changes. The up-

dated files 92 and 98 are the inputs to a transaction jour-

nal (Tr-Jrnl) Run 100. This run processes each account

of MAFI 94 in the individual fashion determined by the

customer’s chart of accounts and in accordance with all

of the customer’s transactions for the particular state-

ment period. The output is a printed transaction journal

102 for each account. Another input to this run 100 is

a set of records 101 which determine the particular ac-

counts to be processed on any given date (e. g. a par-

ticular sequence of account numbers may be set up to be

processed at certain regular periods); also special re-

quests for reports of particular accounts can be made by

any of these records 101. The input records 88, 95 and

101 may be stored on predetermined sections of one or

more of the files 20; they may be punch-card records

where appropriate for the computer hardware, or they

may be entered manually via the computer console where

few in number.

The Tr-Jrnl 102 contains a separate printed listing

(see Fig. 10 for a pre-printed format) for each account

of all of the transactions (checks and deposits) that were

cleared during the cycle period. These are arranged in

columns by Catno, Chkno, date, the amount, and the type

of transaction, as well as by comments indicating the

absence of a Catno (Non-Code) on the check or deposit

slip, the use thereon of an invalid code in the customer’s

chart of accounts stored in the MAFI, or by the incon-

sistency of an income Catno being employed on a check

or that of an expense Catno on a deposit slip, all is deter-

mined by the chart of accounts in MAFI 98. In addition,

a sub-total for each Catno is indicated by “* * *” on the

Tr-Jrnl.

The Tr-Jrn! Run 100 also flags all of the TRAFR of

file 92 that it processes, and the flagged TRAFR are re-

tained in case a re-run is required for a particular ac-

count. All of the TRAFR that were flagged on the previ-

ous cycle (i. e. those TRAFR in file 92 that contain flags

and are presented as inputs to run 100) are not processed,

but are conditioned to be dropped automatically by the

subsequent Update TRAFI Run 86. Thus the output 104

from run 100 is a flagged and purged TRAFI, which is

used as the input file 84 for the next TRAFI Update Run

86, as indicated by the connectors in Fig. 3.

The run 100 also augments all of the year-to-date

(YTD) balances carried for each account in its sub-file

of the RK MAFI 98 (as explained below for Fig. 5C).

That is, as the run 100 develops the totals within each

category which is utilized for the Tr-Jrnl, the correspond-

ing totals on a YTD basis are augmented in MAFI 98.

The output is MAFI 106, having the new YTD totals

and also carrying the current cycle period’s totals of trans-

actions for each Catno. Thus the MAFI 106 temporarily

stores the current month’s totals for each category, which

are utilized in the next run 108 for processing the sum-

mary-sheet reports (Fig. 11 or 12).

The Summary Sheet Run 108 receives the MAFI file

106 as its input, as well as the cycle and request records

101. The Summary Sheet Run 108 produces as outputs,

different summary sheets 110, 112 and 114 (in one form

of the invention), which have somewhat different format

characteristics to meet the special record-keeping needs

of different classes of customers; that is, the summary

sheets 110 are for personal bank accounts, sheets 112

for business accounts, and sheets 114 for agricultural

accounts. A summary sheet format suitable for the per-

sonal and business accounts is illustrated in Fig. 11, and

such a format suitable for agricultural accounts is illus-

trated in Fig. 12. However, these formats are not re-

stricted to any particular type of account, and each cus-

tomer’s chart of accounts also specifies the particular

format for his summary sheet, as explained below.

The summary sheet of Fig. 11 is simple in format,

having a space 120 for printing the name and address

of the customer and the Acctno, which data are obtained

from the name record (described below) of the account’s

sub-file in MAFI 106, and a space 122 for the month

and year, which information is obtained from the cycle

record 101. The summary sheet of Fig. 11 is arranged

with a plurality of columns having (in one form of the

invention) pre-printed captions. The first column 124

contains the Catno, which the output printer inserts

therein for each item of the customer’s chart of accounts

from MAFI 106, which also supplies the category de-

scription for that Catno to be imprinted in column 126.

Columns 128 and 130, respectively, receive the printed

amounts from MAFI 106 corresponding to the current-

period’s amount totals for a particular Catno and the

YiD total. The run 108 does not modify the data of

MAFI 106 and consists essentially of a print-out of the

MAFI for the particular account (modifications of this

run are described hereinafter). After the run 108, MAFI

106 is subsequently utilized as the file 94 for the input

of the next MAFI Change Run 96. In other forms of

the invention, the summary sheet is not arranged with

preprinted captions, but instead the columns and captions

are arranged in accordance with the customer’s individual

chart of accounts on the Summary Sheet Run. Likewise,

the Jrnl format (Fig. 10) may have the captions inserted

by the Jrnl Run 100 instead of being pre-printed. There-

by, a standard blank report form may be used for each

type of report, with the differences being composed by

the runs themselves.

The various portions of the RK Runs shown in Fig. 3

are described hereinafter in some detail. These runs

refer to the file formats which are described with respect

to Fig. 3.

FILE FORMATS. DDA Master File. As described

above, a standard DDA file 75 (Fig. 5A) provides a sub-

file 76, 77 (or set of data) for each demand-deposit ac-

count, with the sub-files for all of the accounts being ar-

ranged in a certain sequence such as an ascending Acctno

order. The DDA master file, in accordance with this

invention, has a specified field provided for the RK flag.

This field may consist of a single bit that identifies

whether the account is one to be processed by the RK

system or not. Alternatively, different classifications of

RK processing may be provided by using more than one

bit; e. g. three RK flags may be provided corresponding

respectively to three classes of record-keeping for agri-

cultural, business and personal bank accounts, where

separate daily TRAFIS 84 are to be set up for each class

of accounts.

Transaction File. The transaction files (Fig. 5B) are

each made up of a sub-file 71, 73 of records carrying the

data of the various transactions, as described above.

Record-Keeping Master File. Fig. 5C illustrates the

format of the RK MAFI, which is made up of a series

of sub-files 140 for each account number, with these sub-

files following one after the other and arranged in as-

cending numeric order. Within each account sub-file, a

number of records are set up in a prescribed order; each

record is assumed (in this embodiment) to be of a pre-

scribed length, and contains various fields at prescribed

locations. The first record is a name record 142 for the

particular account, and it carries ordered fields 143, 144

for the Acctno and the name and address of the customer,

a field 145 (usually the initial field) identifying the

record as a name record, a system-flag field 146 defining

the particular classification of account (e. g. business,

personal or agricultural), a cycle flag 147 which identi-

fies by a code the time periods in which the account is

to be ultimately processed to a customer report, as well

as flags that define the accounting time periods for zero-

ing YTD totals (e. g. the fiscal-year month). A second

record 148 has an identifier field 149 and net-credit and

net-debit fields 150, 151 which are used ultimately for

proofing the Jrn] totals against the DDA balance (these

records are obtained from file 87, Fig. 2). The remain-

ing records are each associated with a different Catno

and together they make up the customer’s individual

chart of accounts. These records are of two types: one

is a title (or title and total) record 160 (Fig. 5D), the

other a year-to-date (YTD) record 162 (Fig. 5E). Each

record 162 contains the titles for its Catnos, as well as

the associated numeric amount totals on which the RK

reporting is based. This series of records, which may be

selected and varied in any desired fashion, incorporates

the individual chart of accounts provided for each cus-

tomer. Certain sections of the chart of accounts may be

the same for a number of customers (e. g. income and,

expense sections for the business type of records) and,

as described below, variations are also provided for. Gen-

erally, each record is formed with a certain basic char-

acter length (e. g. that of a standard punch card), and

certain records (e. g. that of the name record 142) are

formed of a multpile of the basic length. The title and

YTD records 160 and 162 each have the Catno and other

fields at specified locations.

In Fig. 5C, the chart of accounts section of each ac-

count sub-file 140 is shown divided into a number of

records which are initiated by a “General Title” record

152 which carries the alphabetic Catno. As shown in

Fig. 5D, title records 160 have an initial identifier field

164 specifying the type of record and the type of totaliz-

ing operation to be performed, if any; thereafter, a title

description and Catno fields 165 and 166.

Following a first “General Title” are a plurality of

YTD records 153, 154. As many of these are provided

as may be required for the customer’s chart of accounts.

As shown in Fig. 5E, each YTD record contains an ini-

tial identifier 167 followed by fields 168 and 168’ in which

the numeric totals for YTD and current month, respec-

tively, are accumulated for the associated Catno, where

the latter is an expense item. Similarly, fields 169 and

169’ store totals for the same Catno where the latter is

an income item. Flags 170 and 171 specify respectively

whether either or both of the fields 168 (168’) anc 169

(169’) are active for the particular Catno. That is, the

flags 170 and 171 are provided depending on whether the

chart of accounts follows the form shown in Fig. 11 or

12 (namely, depending on whether the Catno applies to

either expense or to income, or to both, respectively).

Following a first series of YTD records 153, 154 is a

Level-I total (i. e. a sub-total) record 155 (of the type

shown in Fig. 5D). This record contains an operator

field 164 that specifies the particular control operations

to be performed in the Summary Run 108. Successive

such sub-file sections are provided as may be required for

individual accounts (each including a group of records

such as 152, 153, 154, 155), and a final Level-II total

field 157 is provided where an accumulated grand or net

total is stored; its operator field 164 is coded to specify

the particular Level-II totalizing to be performed. Each

total record 155 or 157 operates with all of the category

data set forth in the preceding records up to any pre-

ceding total record of the same or higher level. As shown

in Fig. 5C, only two levels of totalizing are illustrated

(those of records 155 and 157). This invention contem-

plates the use of as many such levels as may be required

for any particular account. The identifier 164 is coded

to specify at which particular level the total is taken.

The working storage section 11 of memory 10 is shown

in Fig. 1B. For many of the runs, two input files 20’

and 20” are used with two associated output files 22’ and

22”, respectively. Each record from the Input-I file 20’

is transferred to an associated input register 180, from

whence it is transferred to the output register 182 and

therefrom the Output-I file 22’. Similarly, input and out-

put registers 184 and 186 operate with Input-II and Out-

put-II files 20” and 22”. Various other storage registers

are identified hereinafter in connection with the associated

runs.

Master-File Change Run (Fig. 6). The inputs to this

portion (run) of the system are (1) the RK MAFI 94

(Fig. 3), if one already exists, and (2) a maintenance

or change file (CHFI) 95, which may be a set of records

(e. g. punch cards, magnetic tape, or dise file) that set

forth the changes and additions to be made to the master

file. Each record of the CHFI 95 is identified by a field

containing the associated Acctno, and all of these records

are sorted in ascending order, as are those of MAFI 94.

Four types of CHFI records are provided (in this em-

bodiment) which are similar in format to the correspond-

ing MAFI records (Figs. 5C, D and E), and carry cer-

tain modifications as noted (the reference numerals of the

corresponding MAFI fields are referred to for identifying

the CHFI fields) :

(1) A CHFI name record carries any changes in the

customer’s name and address 144 and system and cycle

flags 146 and 147 in a format similar to the MAFI rec-

ord 142. The same special identifier field 145 is provided

for this CHFI record. In addition, a predetermined

change-instruction field carries a code that identifies ei-

ther (a) delete a complete account, (b) add an entire new

account, or (ce) change the fields of the MAFI name

record 142 to contain the data carried in the corresponding

fields of the CHFI record.

(2) CHFI YTD records (similar to the MAFI record

162, Fig. 5E) have fields for the Catno and name, as

well as for YTD expenses and YTD income; these CHFI

YTD records carry a special identifier (i. e. the same as

field 167) as well as a change-instruction field that identi-

fies by code the type of maintenance operation to be per-

formed (e. g. a code specifying a change of the entire

~ ti

MAFI YTD record in accordance with the fields of this

CHFI record). Another operational code may specify the

deletion of the complete MAFI record corresponding to

the Catno of the CHFI YTD record, or the addition of

the entire CHFI YTD record. Another operational code

may specify that one or more fields of a corresponding

MAFI record should be changed in accordance with the

data set forth in the corresponding CHFI fields (which

may include an algebraic identifier for adding or sub-

tracting dollar amounts).

(8) A CHFI title record (similar to MAFI record 160,

Fig. 5D) carries a Catno and title description fields. The

CHFI title record also has a field to provide a unique

identifier corresponding to that of 164 in the MAFI rec-

ords for general title, and Level-I and -II totals. A

change-instruction field in the CHFI title record also de-

termines whether the maintenance is to be a change in

part of the MAF title record, or an addition or deletion

of the entire record.

(4) A CHFI record for net credit and net debit records

carries a special identifier in field 149 and corresponding

fields for credit and debit which are to replace the cor-

responding data fields 150 and 151 in the MAFI record.

Where the MAF file does not exist, the CHFI contains

all of the records required to compose the MAFI file.

Where a new account is to be added, the CHFI file con-

tains all of the records composing this new account and

the change MAFI Run is designed to insert the succes-

sive records in the proper Acctno and Catno order in the

MAFI file. If an entire account is to be deleted, the

CHFI name record identifies this deletion and the run is

designed to delete all of the records of that account sub-

file from the MAFI.

The MAFI 94 is set up as Input-II file 20” (Fig. 1B)

and the updated MAFI 98 is generated as Output-II file

22”. The CHF file 95 is set up as Input-I file 20’, and no

corresponding output file is generated. The CHFI file 95

(Fig. 3) is previously sorted in ascending Acctno order,

and within each Acctno the records are sorted by identi-

fier code numbers 145 and 149 to provide (a) a name rec-

ord 142 and (b) a net cred-deb record 148, and there-

after (c) title and YTD records 152, 153, 154, 155, 157

are arranged in ascending Catno order.

In the flow charts (Figs. 6, 7, 8 and 9) standard sym-

bols and representation are employed. Main control flow

is represented by a rectangle for a processing operation,

a trapazoid for processing that includes an input or out-

put operation, and a hexagon for a predefined process

such as a subroutine; a diamond is used for a decision

or test with the main and branch flow paths indicated,

and a subroutine may itself contain one or more decisions.

Connector circles set forth the reference numerals of suc-

ceeding branch and main-flow operations. Generally, the

flow paths are from top to bottom and from left to right;

however, for simplicity of illustration minor variations

therefrom are employed. The details and interrelation-

ships of the operations are described in the specification

with reference to the flow charts. The operations con-

sist of basic machine operations or combinations thereof

which are generally of an elementary nature, such as the

basic arithmetic, comparison, code-recognition and input-

output and transfer operations, and will be readily ap-

parent to those skilled in the art.

Initially in this run (Fig. 6) the first operation 200

GETS a record CHFR from the CHFI file 20’ (Fig. 1B)

and places it in working-storage input register 180 (Fig.

1B) in memory. Then test 202 determines if it is an end-

of-change-file record (EQCHF) by looking for the asso-

ciated identifier code at a prescribed field location). If

NO, the next operation 204 GETS a record MAFR from

the MAFI file 20”, places it in input register 184, and

test 206 similarly determines if it is an end-of-file record

(EOMF). If NO, test 208 determines whether the rec-

ords are equal on control. This test 208 is composed of

several tests, and initially determines whether the Acct-

nos for the two obtained records (CHFR and MAFR) are

identical.

After equality of Acctno is deterinined, a test de-

termines whether there is equality on the identifier 145

associated with name records 142. If not, a test is made

to determine if there is equality on the cred-deb identi-

fier 149; and if not, a test determines if there is equality

on Catno. Thus the tests 208 obtain equality on control

for the CHFR and MAFR records by first obtaining equal-

ity on Acctno, and thereafter equality by testing the suc-

cessive records as they would ordinarily exist within the

master file. Test 208 proves YES whenever one of the

additional subsidiary tests proves YES, and it proves NO

whenever any test is NO.

Upon obtaining equality on control, the next test 210

determines whether the changeirstruction field of the

CHFR in register 180 calls for a “change”. If YES, the

appropriate fields of the MAFR in register 184 are

changed (212) accordingly. A message print-out 214

identifies the change that was made; and the changed

MAFR is PUT (216) on the updated MAFI 22” in prop-

er sequence (the PUT operation may vary for different

computers; it is assumed, by way of example, that it con-

sists of transferring the contents of output register 186,

namely, the preceding record, to file 22” and transferring

the contents of register 184 to register 186).

The CHFR in register 180 is discarded after its change

is made; i. e. the program returns to GET (200) the next

CHFR without PUTTING the previous CHFR, so that

the latter is written over in register 180. This loop is

repeated, by GETTING the next CHFR and MAFR, since

the preceding records of each were fully processed. This

processing continues, and if the test 210 proves that the

CHFR is not a “change”, the next test 218 determines if

its change-instruction field calls for the deletion of a rec-

ord. If not, an error is indicated, since equality of con-

trol at test 208 requires either a change or a deletion,

which error is handled by the print-out 220 of an error

message. The unchanged MAFR in working storage 184

is PUT (216) to the updated MAFI, and the program

returns to GET (200) the next CHFR. If the Delete test

218 proves YES, the program branches for a print-out

222 of a message identifying the deletion. Thereafter, the

program returns to GET (200) the next CHFR and

MAFR without a PUT to the updated MAFT; that is, the

record is effectively deleted by its not being put out to

the MAFI, and it is written over in register 184 by the

next MAFR. If desired, a single CHFR may be em-

ployed for deleting all of the records of a particular ac-

count. For this purpose, a special loop would be provided

in the branch from test 218. In this loop (not shown)

a first test would determine whether the deletion was of

a single record or of the entire account. If a single rec-

ord, then the operating 222 would be performed, as shown

in Fig. 6. If the full account is to be deleted, a subsidiary

loop proceeds to GET MAFR, then a test EOMF; and if

NO, a test for equality on Acctno. If YES, the MAFR is

deleted by printing a message and returning in the same

loop to GET the next MAFR. This subsidiary loop con-

tinues iteratively until the test for equality on Acctno

is NO. Thereupon, the loop exits to GET the next CHFR,

testing for EOCHF, and returning to the main flow at

the input to test 208.

If test 208 indicates that CHFR and MAFR are not

equal on control, the program branches to test 224 in

order to proceed with the control operations required to

find the next such equality. Test 224 determines whether

the CHFI record is higher in sequential record than the

MAFR (the order, as noted above, being determined first

by Acctno and thereafter by the identifiers 145 and 149 in

the name and cred-deb records 142, 148, and subsequently

by Catno. If the CHFR is high (and since the records

are arranged in ascending order), test 224 indicates that

no CHFI records exist calling for changes to be made

in that particular MAFR; and it is PUT (226) to the

updated MAFI unchanged, and the program returns to

re-entry 204 to obtain the next MAFR. However, if the

CHFR is not higher in sequence (test 224 is NO), then

the CHFR in input register 180 should properly be a

record to be added, since its sequence falls in place be-

fore the current MAFR. Therefore, the next test 228

checks the charge-instruction code in the CHFR looking

for an ADD; if it is not, the program branches to print

out 230 for an error message and proceeds to GET (232)

the next CHFR. The test 234 for EOCHF is again per-

formed at this point; and if not the end-of-file, the pro-

gram returns for the equality test 208 with the MAFR

that remained in register 184. If the ADD test 228 is

YES, the proper fields of the CHFR then in register 180

are PUT (236) to the updated MAFI via output register

186, and an appropriate message is printed out (not

shown). Thereafter, a GET 238 of the next CHFR is

followed by a test 240 for EOCHF, and if NO, the pro-

gram returns to the test 208 for equality.

The foregoing outlines the overall control program that

produces the updated MAFI 98 in file 22”. Remaining are

certain control operations that are performed when a test

finds EOMF or EOCHF. Either of the latter can occur

first, and the run terminates upon both occurring. When

test 206 for EOMF is YES before that for EOCHF, the

remaining CHFI records are those for new records for

the last account and/or records for new accounts of higher

account number; for this processing the program branch-

es to test 242. The latter determines whether the CHFR

is one to be added (which it should be except as an er-

ror); and, if not an ADD, the program branches to

print out 244 for an appropriate error message. The

program proceeds to GET (246) the next CHFR, performs

the EOCHF test 248; and if NO, the program returns to

ADD test 242. If the latter 242 finds an ADD record,

that CHFR is PUT (250) to the updated MAFI file

with a message print-out 252, and the next program steps

to GET 246, and so on as described. These alternative

loops are repeated until the EOCHF test 248 is YES, and

the program branches to the end-of-the run process 254,

which performs the particular housekeeping followed to

wrap up this run and bring in the next one.

If the EOCHF test 202 is YES before that for

EOMF, no further changes are to be made, and the

program branches to GET (258) the next MAFR with

a test 260 for EOMF. If the latter tests NO, the pro-

gram returns to PUT (256) the MAFR and GET (258)

the next one, and so on. In this way, the remaining

MAFI records are successively GOTTEN and merely

PUT to complete the updated MAFI until EOMF tests

YES, and the run ends. Similarly, when test 240 is YES,

the current MAFR in register 184 is PUT 256, and the

run winds up as described.

In operation of the MAFI Run, test 208 determines

if the correct MAFR is located to which a correction

is to be made as specifically by the CHFR. Thereafter,

tests 210 and 218 identify the character of the correc-

tion which is then carried out by the associated branches

212 and 222, respectively. If the CHFR does not call

for a correction, test 208 is NO and the record should

be an ADD, absent some error. The loop of test 224,

PUT 226 and back via GET 204 locates the correct

position in the MAFI sequence in which the CHFR

is to be added, and when it is (absent an error), the

CHFR is inserted by PUT 236. When EOMF occurs

prior to EOCHF, the remaining CHFI records are added

to the end of the MAFI via branch from test 206 to test

242 and PUT 250, and so on. When EOCHF occurs

first, the remaining MAFI records are read out to the

updated MAFI via a branch from test 202 or 234.

Transaction File Update and Change Run (Fig. 7).

Processing 86 of TRAFI primarily calls for acding the

new transactions of the daily TRAFI 82 (Fig. 3) to the

accumulated TRAFI 84 of the previous days’ operations.

This operation can be considered to be a daily vperation

in which the new transactions are merged with those

of TRAFI 84 in proper sequential order at the end of

each day’s DDA processing. Alternatively, the daily

TRAFIS 82 for an entire statement period can be ieft

unprocessed until the statement time, and then an overall

sort performed on them. In actual operation, it is found

generally desirable (where the work load warrants it)

to perform this merging of each daily TRAFI with the

accumulated TRAFI on a day-to-day basis. In addition,

it is found that a certain amount of maintenance is

required of the transaction file due to errors that may

occur in the bank processing or due to customer errors.

The TRAFI Update and Change Run described below

assumes the latter type of situation where a day-to-day

maintenance of the transaction files is desired in order

to handle such error correction.

The TRAFI Run (Fig. 7) is substantially similar to

the MAFI Change Run described above with respect to

Fig. 6. The inputs to the TRAFI Run (as shown in

Fig. 3) are the RK TRAFI 84, which contains the ac-

cumulations of the transactions of previous days, the

current daily TRAFI 82, which is presorted in ascending

sequence order (at least by Acctno, Catno and date), and

(as a prefatory addendum to TRAFI 82) the records

88 of changes to be made in the RK TRAFI. Each change

to be made in file 84, in this embodiment, is represented

by two change records 88; i. e. a record having a

change-instruction field that calls for a deletion from

file 84 of the entire identified transaction that is in error,

followed by a record adding the entire transaction with

the correct data.

For simplicity of illustration, the TRAFI Run of Fig.

7 omits certain portions of the run which are substan-

tially the same as those described above with respect to

Fig. 6. In Fig. 7, parts corresponding to those of Fig.

6 are referenced by similar numerals, with the addition

of a. In reading Fig. 7 together with Fig. 6, references

to “MAFR” are read as “TRAFR”; that is, for purposes

of Fig 7, the file being updated is the TRAFI (just as

the MAF is updated in Fig. 6). The change-file records

(CHFR) of Fig. 7 are composed of the records 82 and

88 (Fig. 3) pre-sorted to be in proper sequence.

The TRAFI Run starts with GET 200a CHFR, a test

202a for end-of-filee GET 204a TRAFR, a test 206a

for end-of-file, followed by a test 270 to determine

whether the Acctno is blank (which condition comes

about, as described below, when processed TRAFRS are

flagged in the Jrn! Run, and then in a subsequent Jrnl

Run their Acctno fields are blanked). If test 270 is

YES, the program loops back to GET 204a the next

TRAFR, without a PUT of the TRAFR with the blank

Acctno, and thereby dropping it. If test 270 proves NO,

the program then tests 272 to determine if the change

record contains a Delete change-instruction field. If it

does not, then it must be an ADD record (since only two

types are used), and the program branches to test 224a

to determine if the CHFR sequence order (Acctno, Catno

and date) is greater than that of the TRAFR. If it is,

the TRAFR is PUT 226a and the program returns to

GET 204a the next TRAFR; and if it is not, the CHFR

must be an ADD, and it is PUT 236a. A message print-

out (not shown) of the ADD record is performed, which

is followed by GET 238a the next CHFR. Thereafter,

the program proceeds to test 240a for EOCHF, and the

program follows the corresponding operation described

above for Fig. 6.

If test 272 finds a Delete record, test 274 then de-

termines whether there is equality on control on a first

set of criteria which are limited to the Acctno, the Catno

and the date. If that equality is found, test 276 checks

a second set of criteria for equality of control to locate

the precise TRAFR identified in the Delete record; i. e.

the criteria include the Chkno (the check or deposit

number), the Tranco, and the amount of the transac-

tion. If test 276 finds equality, a print-out 278 of a

Delete message follows, and the program returns to

GET 200a the next CHFR and GET 204a the next

TRAFR without a PUT of the TRAFR or CHFR, and

thereby deleting the TRAFR. If test 276 does not find

equality, the TRAFR is PUT 280 and the program

returns to GET 204a the next TRAFR. This control

loop continues via equality tests 274 and 276 until the

precise TRAFR to be deleted is located and effectively

deleted via the path 278.

If the test for the first criteria proves NO, the pro

gram branches to test 282, which determines if the

CHFR sequence order (Acctno, Catno and date) is

greater than that of the TRAFR. If it is not, an

error is indicated in the data of the CHFR, which error

is identified by a print-out 284 of an error message, and

the program continues to GET 238a the next CHFR.

If the test 274 proves NO, and test 282 proves YES, the

program branches to PUT 280 the TRAFR and returns

to GET 204a the next TRAFR, and so on until test

974 is YES. If EOTRF test 206a is YES, the branch

is to test 242a to determine if the CHFR currently in

input register 180 is a DePete or an ADD. If a Delete,

an error is indicated by a print-out 244a; otherwise,

the program proceeds to PUT 250a the remaining CHFRS

until test 248a finds EOCHF and the run ends (254a).

In other respects, the TRAFI Run (ex i

respect noted hereinafter) is the same —~ 4 ‘MAF!

ny = the general control procedures to be followed.

=: the TRAFI Run, the special addition of handling

ank Acctno fields is dealt with following each test

for EOTRF _(such as test 206a and that corresponding

to test 260 in Fig. 6). This is done by performing a

test similar to test 270 to determine if the TRAFR

Acctno field is blank; if YES, the program loops back

. GET the next TRAFR without a PUT of the current

RAFR and thereby dropping it. If the Acctno field is

<n the loop back is PUT for the current TRAFR

ae , that record) and then GET the next

In operation of the TRAFI Run, test 272 distinguishes

between the two types of CHFI records. In an ADD.

the addition is made by locating the position in the

TRAFI sequence in which the CHFR is to be added

This is done via the loop of test 224a, PUT 226a and

back to GET 204a, and so on, until test 224a finds a

TRAFR with the same or lower sequence order, at which

the CHFR is PUT 236a. If the CHFR is a Delete, the

correction is made by locating the precise TRAFR that

is to be deleted. A first loop (tests 274 and 282, PUT

280, GET 204a, and so on) locates the section of the

TRAFI having the same sequence order (Acctno, Catno

and date). Thereafter, a second loop (test 276 PUT

280, GET 204a, and so on) locates the precise TRAFR

(same Chkno, Tranco, and amount) and that TRAFR is

ae via path 278. The TRAFI Run also drops

RAFRS that have been previously processed in the

Jrnl Run which results in a blanking of their Acctnos

_ band wry hoa blank Acctno and that TRAFR

ones om A as oop back to GET 204a without a

Transaction Journal Run (Fig. 8) The Jrn

(Fig. 3) generates a printed report for bon oot

of his transactions for the reporting period. The inputs

to this Jrnl Run are the undated RK MAFI 98 ( ee

as Input-II file 20” of Fig. 1B) and the updated RK

TRAFI 92 (Input-I file 20’). The TRAFI is updated

and corrected by the TRAFI Run 86, so that all of the

TRAFI records are in proper sequential order consistent

with that of the MAFI. The updated MAFI 106 is put

out to Output-II file 22”, and the processed TRAFI

104 to Output-I file 20’. Other inputs include a cycle-

number record (CYC) 101 which sets forth the be-

ginning and ending Acctnos to be processed by the Jrn)

Run (these Acctnos are entered in the cycle working-

storage register 190), and a set of special request records

(REQ) 101 identifying particular Acctnos to be pro-

cessed. The REQ Acctnos are presented in assending

numeric order and may include Acctnos that are either

within or outside the cycle range (these REQ Acctnos

are established in storage register 192). —

The printing of the Jrn! for a_ particular Acctno is

controlled by the Acctno being specified by a REQ or by

the Acctnos of the CYC. Thus, a Jrnl is printed where

the MAFI and TRAFI records match on Acctno, and the

Acctno matches either a CYC or a REQ. Where the

Acctno of a MAFR matches the REQ or the CYC, but

the TRAFI does not have the corresponding Acctno, the

account is one in which there was no activity during the

month, and the Jrnl Run prints out the Acctno and name

data to indicate that that account was not skipped over

by error. All of the TRAFRS that are processed are

flagged, and any TRAFR that was flagged the previous

month has its Acctno blanked so that there is no further

processing of that record’s data. The totals that are gene-

rated in the Jrnl report are Catno sub-totals for deposits

and checks as well as the overall account totals for de-

osits and checks.

‘ A flow chart of one form of Jrn! Run begins with

certain control operations shown in Fig. 8A. It starts

with GET 301 MAFR and GET 302 TRAFR. Test 303

determines if the TRAFR is an end-of-file record and,

if so, the program branches to the EOTF subroutine

304 (Fig. 8B) at test 350. If not, the program pro-

ceeds to a predetermined process or subroutine 305, which

incorporates a sequence of operations described in de-

tail below (operations 444, 446 and 448 of Fig. 8C).

That is, subroutine 305 tests to determine if the Acctno

of the TRAFR in register 180 is blank and, if so, it is

PUT 306 (and not processed) and the program loops

back to GET 302 the next TRAFR. A second test in

subroutine 305 determines if the TRAFR was previously

processed and flagged; if so, its Acctno is blanked, it is

PUT 306, and the loop back GETS 302 the next TRAFR,

and so on until subroutine 305 finds a TRAFR that is

suitable for processing, whereupon the next steps are to

GET 307 the CYC record (i. e. enter the range in register

190) and to GET 308 the next REQ record (i. e. enter

it in register 192). ‘

When the four different records have been set up in

storage registers 180, 184, 190, 192, test 310 determines

whether the REQ and MAFR are equal on Acctno. If

YES, a REQ-reentry switch is set 312 and the program

continues with a test 314 for equality on Acctno be-

tween MAFR and TRAFR. If Yes, the program exits to

a subroutine 316 (Figs. 8C, D and E) that performs the

processing of all the TRAFR and MAFR for that ac-

count, and thereafter reenters via test 318, which steers

the program to the appropriate reentry point, depending

on whether or not the REQ-switch had been set at oper-

ation 312. Thus, if test 318 proves YES, the exit to sub-

routine 316 was initiated by equality on REQ and the

program returns to GET 308 the next REQ. In subrou-

tine 316 (as explained, below) the processing of all the

records for the current Acctno is completed, and initial

MAFR and TRAFR for the next Acctno in each file are

obtained before exiting.

If test 314 proves NO. the program branches to test

320 to determine if the TRAFR Acctno is higher than

that of the MAFR. If YES, the program exits to sub-

routine 316 and the MAFR Acctno and name only are

printed out (this situation arises when there was no

activity in the account for that particular month. If test

310 proves NO, test 322 determines if the MAFR Acctno

is high with respect to the REQ Acctno. If test 322 is

YES, an invalid REQ is indicated and control branches

to a print-out 323 of an error message, and the control

returns to GET 308 the next REQ. However, if test 322

is NO, the MAFR Acctno must be low with respect to

that of the REQ, and thereafter a test 324 determines if

the MAFR Acctno is equal to the current CYC (i. e.

determines if it lies within the Acctno range of the cur-

rent CYC). If YES, the branch goes to test 314 for

comparison with the TRAFR Acctno and any processing

that is required in subroutine 316. Upon leaving sub-

routine 316 under these circumstances, the result of test

S18 is NO, and the reentiy is to test 310, where the Acctno

of the new MAFR obtained in subroutine 316 is first

tested against the current REQ, and so on as described.

If test 324 proves NO, the test 326 determines if all

the REQS and the CYC range have been processed (e. g.

by testing a switch set at the end-of-request records, and

by testing if the MAFR Acctno exceeds the upper bound

of the CYC range). If YES, the branch is to wind-up

328 and thence to end-run 330. If test 326 is NO, the

next Acctno is obtained from the MAFI file. That is, a

loop is provided as follows: PUT .332 the MAFR, GET

334 the next one, test 336 for EOMF and, if NO, test

338 for the same MAFR Acctno, and if the latter is YES,

the loop returns to entry 332. Test 338 may be performed

by looking for the identification field 145 in the new

MAFR which would indicate a name record 142 and

therefore a new Acctno. Alternatively, each MAFR may

have an additional field carrying the associated Acctno

(which has been found desirable for greater reliability)

and test 338 is there performed by comparing Acctnos

in the input and output registers 184, 186.

If test 338 is NO, control returns to reentry 310 for

a test against the current REQ Acctno. If test 336 is

YES, control branches to wind-up 328. The wind-up 328

performs a number of operations to tie up certain loose

ends that may remain; i. e. a test is made to determine

if any REQ records remain unprocessed (which may

arise due to an invalid Acctno having been utilized in the

REQ record), and error messages are printed out. In

addition, it is necessary to process any remaining TRAFR

for the last Acctno that was being processed, which

TRAFR may have invalid Catnos, and therefore they

remain to be processed even though the MAFI for that

Acctno has been completed. Thus the wind-up 328

processes all of the succeeding TRAFI records for the

same Acctno, which operation terminates upon a new

Acctno appearing for the TRAFI. Upon completion

of the processing of all of the transactions for the last

Acctno, the wind-up 328 completes whatever totals (such

as the Catno totals and the final account total) that may

remain, and it proofs these account totals of the Jrnl

against the DDA balaive, as explained below. When the

last MAFI Acctno has been completely processed, the

control steps to end-run 330 which completes the house-

keeping operations on the various files to terminate the

current run and bring in the next run.

When the program obtains a match of the MAFR

Acctno and that of a REQ record (via test 310) or of the

CYC range (via test 324), the program branches to test

314 to determine if there is also a match on the TRAFR

Acctno. If not, test 320 determines if the TRAFR Acctno

is greater than that of the MAFR. Test 320 proves NO

where the TRAFRS for that TRAFI Acctno are not to

be processed during the current CYC; e. g. the Acctno

is outside the CYC range and is not one of the accounts

specified by an REQ. Thereupon, the program proceeds

with a loop to locate the TRAFR having the matching

Acctno; this starts with a PUT 340 of the TRAFR,

a GET 342 of the next TRAFR, a test 344 for end-of-

file, the blank and fiagged subroutine 305, and a test

346 to determine if the Acctno of the new TRAFR

is the same as that of the preceding TRAFR (which is

located in output register 182). If it is the same, a loop

is formed back to PLT 340 to repeat the operation until

test 346 locates a new TRAFI Acctno. When it does,

the program loops back to test 314 to determine if there

is now an Acctno match for MAFR and TRAFR. If

there is not, the loop is again repeated until the match

is found, or the TRAFR Acctno is greater than that of

the MAFR, and the program then enters subroutine 316

to process the TRAFR and update the corresponding

MAFR.

EOTF (MAFI Wind-Up, Fig. 8B). The EOTF sub-

routine is entered whenever the end of the TRAFI oc-

curs. Initially, a test 350 determines if the Acctno

for the REQ record and MAFR are the same. If YES,

the REQ switch is set 352 and program control con-

tinues (if the current MAFR is the name record 142)

with the print-out 354 of the account name and Acctno,

since this account receives a TR-Jrn] without any trans-

actions for the CYC period. The program continues

thereafter to wind up that MAFI account with PuT

356 the current MAFR and GET 358 the next one, which

test 360 checks for end-of-file. If YES, test 357 de

termines if the account totals of the current Jrnl (the

MAFR Acctno in output register 186) are in balance

with the account’s DDA balance (as explained below for

test 460). If it is in balance, the subroutine exits to

wind-up 328; if not, that exit is preceded by a print-out

359 of an error message.

If not EOMTF, test 362 determines if the Acctno

remains the same. If it is the same, certain housekeeping

operations have to be performed on YTD records, and

test 364 determines if the current MAFR is a YTD type

(from the identifier field 167). If it is not, the program

loops back to PUT 356 the MAFR. If it is a YTD

record, test 366 determines from the CYC flag 147

(stored in register 425 when the name record 142 is

put out to file 22”, which register 425 is cleared upon

a change in MAFI Acctno) whether the current CYC

period is that for zeroing the YTD files, as explained

below in connection with Figs. 8C and D. If it is the

time to zero YTD, the program steps to operation 368,

which performs the zeroing of the appropriate YTD

field 168, 169 of the current MAFR and then steps to

process 370 to zero the current-month field 168’, 169

(which contains the previous month’s figures) and the

program loops back to PUT 356. If the current CYC

period is not that for zeroing the YTD, from test 366

the program steps directly to process 370. This loop

continues until test 362 indicates a different MAFI

Acctno; the branch flow is via DDA-proof test 369 (and

if NO, via print-out 371): if YES, to test 372 to de-

termine whether the REQ switch is set. If NO, the

branch is to test 350; if YES, the program proceeds

to GET 3874 the next REQ before going to test 350.

Whenever an end-of-file for the REQ record comes up,

a switch ‘noted above for test 326) is set and the REQ

Acctno in register 192 is set to the highest end of the

CYC range. Thereby, when the program returns from

operation 374 to test 350, the latter will prove NO

because the REQ Acctno is necessarily greater than that

of the MAFR. Thereafter, test 376 tests if the MAFR

account numeral is higher than that of the REQ. If

YES, an error-message print-out 378 is made, and the

program proceeds via operation 374 to GET the next

REQ, as described above. If test 376 proves NO, test

380 tests for equality of the MAFT Acctno and the

CYC; if YES, the program branches to the loop be-

ginning with print-out 354. If test 380 proves NO, test

382 determines if a!l the REQS and the CYC range

have been processed. If YES, the program branches

to wind-up 328; and if NO, the program branches to a

loop that includes PUT 384 the current MAFR and

GET 386 the next one, a test 388 for end-of-file, and a

test 390 for same MAFR Acctno. If the Acctno is the

same, the program loops back to PUT and GET MAFI

records until a new Acctno is obtained, and the program

then loops back to the beginning 350 of the subroutine.

If test 388 is YES, the control branches to wind-up 328.

In operation, the Jrn] Run begins with obtaining an

Acctno match between the name MAFR of an account

and either the REQ or the CYC record (test 310 or

324). Thereafter, an Acctno match between the MAFR

and TRAFR is obtained (or, if the account had no

activity for that month, test 320 would find the MAFR

Acctno greater than the TRAFR) and the program exits

to subroutine 316 to process the MAFRS of that Acctno

with the associated TRAFRS, if any. After this process-

ing, control returns via switch test 318, which steers

the control to different reenteries depending on whether

the previous exit was due to an REQ or CYC match.

If test 314 does not obtain an Acctno match for the ©

MAFR and TRAFR, and the latter has the lower Acctno,

the loop via PUT 340 through test 346 operates re

peatedly to locate the required TRAFR Acctno. Simi-

larly, if the MAFR Acctno does not match on REQ or

CYC, the loop of PUT 332 through test 338 obtains the

next MAFI Acctno.

At the end of the TRAFI, after it has been processed,

the program enters the EOTRF subroutine (Fig. 8B) to

wind up the MAFI. If the current MAFR is the name

record, a print-out 354 of the name data is made upon

a match of the MAFR on the REQ or CYC (test 350

or 380). Thereafter, the loop of PUT 356 through opera-

tion 370 transfers the remaining MAFRS of that ac-

count to the update file with any processing that may

be required such as the zeroing (368 and 370) of YTD

and current-month totals. When the next Acctno is de-

tected by test 362, the loop exits back to test 350 (via

DDA proof test 369 for the Jrnl just completed and

test 372). If there is no match on REQ or CYC, the

loop (384-390) obtains the next MAFI Acctno. Finally,

at the end of MAFI, the test 360 branches control (via

DDA proof test 357 for the Jrnl just completed, or

test 388 directly since there was no Jrnl then in

process) to the TRAFI wind-up 328. If the MAFI should

end before the TRAFI, the wind-up 328 processes the

remaining TRAFRS for the last Acctno and completes

the totals for the Jrn] therefor and proofs the totals

with the DDA balance.

Processing TR-Jrnl. The processing of the TRAFI and

MAF'I files to produce the transaction journal (i.e. the

subroutine 316, Fig. 8A) is illustrated in flow-chart form

in Figs. 8C and D. In working storage 11, additional

sets of registers are employed for this processing; namely,

a YTD Cat-total register 400 having individual sections

for income and expense (to store MAFR fields 169 and

168, respectively), a current-period Cat-total register 402

having individual income and expense sections (to store

MAFR fields 169’ and 168’, respectively). Additional

registers used for developing the summary sheet reports

are Level-I total registers 404 and 405 for YTD current-

period, respectively, and each having income and expense

sections (as many such Level-I registers are provided

as Level-I totals may occur in any particular chart of

accounts; for example, several of these may occur in busi-

ness accounts), and Level-II total registers 406 and 407

(for YTD and current-period, respectively, and each

having income and expense sections) which accumulate

the overall totals for each account. The Level-I and

Level-II registers 404-407 operate only with the data

reported in the summary sheet (Fig. 11), where the

totals are those of validly coded items and not of in-

valid codes or non-coded items. Another register 408

contains the account total (‘Acct-tot) for the current

period in income and expense and incorporates all items

whether coded or not, validly or not.

The first operation 410 tests for equality of MAFR

and TRAFR (since this subroutine may be entered from

test 320 or test 314, Fig. 8A, and operates differently

accordingly). If test 410 is YES, the name and address

of the account from the name record 142 in input

transaction journal form (Fig. 10). Thereafter, the pro-

gram proceeds to PUT 414 the current MAFR and GET

416 the next MAFR. The test 418 determines if this

MAFR in register 184 is the end of file, and if not,

test 420 determines if the new MAFR continues the

same Acctno (i. e. determines if its identification field

is other than that 145 for a name record). If YES,

test 422 determines if the MAFR is a YTD record from

identifier field 167, and if NO, the program loops back

to PUT 414 and GET until a YTD record is obtained.

(General-Title and Total Records 160 ‘Fig. 5D) are

not utilized in this run.) When test 422 finds a YTD

record, test 424 determines if this is the month to zero

the YTD records (i. e. if it is the end of the fiscal

accounting period as indicated by the cycle flags 147

for the current Acctno, which flags are stored in work-

ing register 425 after the name record 142 is put out to

file 22’). If YES, the YTD fields 168, 169 of the

MAFR in register 184 are zeroed 426 and the program

proceeds to zero 428 the current-period fields 168’, 169’

in that same YTD record. If test 424 is NO, the pro-

gram steps to operation 428 directly. If test 418 is

YES, control branches to wind-up 328.

Thereafter, test 430 determines if the TRAFR and

MAFR records are equal on Catno. If YES, test 432

determines if either MAFR flag 170 or 171 is set con-

sistent with the Tranco. That is, the Tranco (check or

deposit) of the TRAFR calls for a flat in MAFR field

170 or 171, and this test 432 determines if the flag

is in that field of the MAFR. Thus, the test 432 de-

termines whether the check writer has inserted a de

posit Catno on a check or a check Catno on a deposit

by error. If test 432 is YES (i. e. it finds that the flat

corresponding to the Tranco is set, the program proceeds

with print-out-436. The latter controls the print-out on

the TR-Jrnl form (Fig. 10) of the current TRAFR;

i. e. it prints out the TRAFR fields of the Catno, Chkno,

the date, and the amount, and points the amount in the

appropriate column depending on the Tranco indicating a

check or a deposit. In addition, this control 436 in-

itiates various accumulating operations in the working

storage; that is, the amount field of the TRAFR is

added to the previous YTD total (income or expense as

is appropriate) for that Catno obtained from the MAFR

record located in the input register, and the sum is

stored in the appropriate income or expense section of

in the appropriate income or expense section of register

402 with those of other TRAFRS of the same Catno.

The Acct-tot register 408 is also incremented in its ap-

propriate income or expense section by this transaction

amount.

To complete the processing of the current TRAFR, and

to identify it as processed, a flag is inserted in the FLG

field 437 (Fig. 5B) of that record, and since it is now

completely processed it is PUT 438 to the output file

22’. If test 432 is NO, an invalidly coded TRAFR is

indicated by a print-out 434 of an error message to that

effect on the TR-Jrnl (Fig. 10). In addition, the TRAFR

data is printed out, as explained above, and the amount

is accumulated only in register 408 since the Catno is

invalid; a “processed” flag is inserted in FLG field 437,

and the program steps to PUT 438, followed by GET

440.

After the next TRAFR is obtained, test 442 de-

termines if it is the end-of-file. If YES, the subroutine

exits to the EOTF subroutine (Fig. 8B) at entry point

ae ee eee

356; since the current MAFR requires no further process-

ing it is PUT 356; the next MAFR must be obtained and

it and the rest of the MFI processed. If test 442 is

NO, test 444 determines if the Acctno field of the new

TRAFR is blank (which field would have been blanked

during the preceding month’s Jrn] Run (see 448 be-

low) if that TRAFR had been flagged the month prior

to that. If test 444 is YES, the TRAFR is not a record

to be processed and the program loops back to entry

438 to PUT and GET the next TRAFR. If test 444 is

NO, test 446 determines if the TRAFR is flagged (in

its FLG field 437), and if YES, control 448 proceeds

to blank the Acctno field, and the program loops back

to entry 438.

If test 446 is NO, test 450 determines if the current

TRAFR is continuing with the same Acctno (i. e. whether

it has the same Acctno as that in the TRAFR output

Catno is continued, and if YES, the program returns

to test 432 to determine if it is a valid Catno for the

Tranco and to process it accordingly. If test 452 is NO,

a number of processing operations 454 are handled. That

is, the Cat-totals in register 402 are printed out in the

next line of the TR-Jrnl and marked as a total (e. g.

with the three asterisks representing such a total in

Fig. 10); the totals in registers 400 and 402 are also

transferred to the corresponding fields of the MAFR in-

put register, and then registers 400 and 402 are blanked.

Thereafter, the program returns to entry 414 to PUT

the current MAFR and GET the next one, and to repeat

the above described loop.

When test 450 detects a change in the Acctno of the

TRAFI record, the program branches to control 456

(Fig. 8D) to perform the same operations as those of

process 454, and thereafter, in control 458, the Acct-tot

in register 408 is printed out on the TR-Jrnl report.

Then test 460 determines if that Acct-tot of the current

TR-Jrnl is the same as the current-period totals of the

DDA bank statement of the same Acctno. This operation

is performed by comparing the contents of register 408

with those of the debit-credit working register 401 (to

which are transferred the fields 150 and 151 of record

148, Fig. 5C, for the same Acctno prior to that record

having been PUT 414). This comparison may be per-

formed by subtracting the contents of register 401 from

those of register 408 and checking for a zero balance.

If test 460 is NO, there is an error-message print-out

461, and at the same time the register 408 is blanked

since it is not zero, and the program steps to subroutine

462. If test 460 is YES, the program steps directly

to subroutine 462.

The control operations of subroutine 462 correspond

generally to those described above and identified as 414

through 428, except that the subroutine 462 is per-

formed at the termination of the TRAFRS for the Jrnl

currently being processed, and it is only necessary to

wind up the MAFRS of this Acctno. At this time, the

MAFR records for the current Jrnl’s Acctno are all

processed in the same fashion to zero YTD records if it

is the end of the fiscal period, and to zero all of the

current-period fields in those records (since these fields

correspond to the preceding month’s sub-totals). When

the test for same Acctno (corresponding to test 420)

detects a change in Acctno in the MAFR, a branch exits

from the subroutine 462 and back to test 318, Fig. 8A (as

indicated by the connector circle). The branch from the

test for a YTD record (corresponding to test 422) is a

return loop to the beginning of the subroutine, as is the

step from the operation of zeroing the previous current-

period field (corresponding to control 428), and the latter

loop back is indicated by the connecting line in the

drawing.

When test 430 finds inequality of the Catnos for the

TRAFR and the MAFR, the program branches to test

478 (Fig. 8D) to determine if the Catno for the TRAFR

is greater than that for the MAFR. If YES, there are

no current transactions for that MAFR and the pro-

gram branches back to the entry 414 to PUT the cur-

rent MAFR and GET the next one. This loop con-

tinues until] test 430 finds equality, or until test 478

finds that the Catno of the current TRAFR is less than

that of the new MAFR. Thus, when test 478 is NO,

an invalid Catno in the current TRAFR is indicated,

and the program steps to print-out 480 (which is similar

to control 434) to print the TRAFR data on the current

Jrni and to mark it as an invalid Catno, and to handle

that TRAFR as described above for control 434. There-

after, a predefined process or subroutine 482 establishes

program control. It is made up of operations which are

similar to the operations 438 through 450, except that the

subroutine 482 is concerned with handling invalid Catnos

and with completing the processing of them until a new

Acctno is obtained, which provides an exit for the loop

in which the program is operating, to control 456. If

the Acctno is the same, subroutine 482 exits to test

452’, which (like test 452) determines if the Catno

is the same; if YES, the control loops back to print-out

480 for another invalid Catno; if NO, print-out 454’

(like 454) completes the operations for the previous

TRAFR, and control returns to test 430 to determine

if the Catno of the new TRAFR is valid.

When test 420 is NO (i. e. the new MAFR contains

a change in Acctno), the program branches to test 484,

which determines if the Acctno for the input TRAFR

is the same as that of the previous MAFR (which now

has been PUT and therefore lies in the MAFR output

to subroutine 486, made up of operations which are

generally the same as the operations 456, 458, 460 and

461. That is, subroutine 486 performs the remaining

operations that are necessary to complete the printing

of the current Jrnl, and to blank the appropriate work-

ing registers. In subroutine 486, the test corresponding

to test 460 checks to determine whether the Acct-tots

(register 408) for the TR-Jrnl are in balance with

those of the DDA bank statement (fields 150, 151), and

if YES, the overall processing subroutine 316 in Fig.

8A (of which subroutine 486 is a part) exits and re-

turns to the initial control section of the program at

test 318. The same exit to test 318 occurs following

— os of an error message corresponding to con-

trol 461.

If test 484 proves YES (i. e. the Acctno of the input

TRAFR is the same as that of the previous MAFR),

the program steps to 488 to print the data of that TRAFR

on the current Jrnl and to mark it as invalid, to ac-

cumlate it in the Acet-tot register 408, and to flag it

as “processed.”’ Thereafter, the program moves into sub-

routine 490 (which is genera'ly similar to subroutine

482, employing operations similar to 438 through 450) ;

its function is to complete the handling of all of the

remaining transactions having the same Acctno as that

of the previous MAFR (i. e. the current Jrnl) and to

complete that processing. The subroutine is a self-con-

tained loop from which the exits are either via the

EOTRF test (to subroutine EOTRF 350, Fig. 8A) or

via the test finding a different Acctno in the TRAFR,

which calls for an exit to test 318.

If test 410 is NO (corresponding to an entry from

test 320), there are no TRAFRS for that MAFI Acctno

during the current period. Print-out 492 prints the name

and address, and control steps to test 460 to check the

zero Acct-tot against th DDA bank statement.

In operation, the processing of the TR-Jrnl starts with

a print-out 412 (Fig. 8C) of the account name and ad-

dress from the name MAFR 142. Thereafter, loop 414-

422 obtains the next YTD MAFR for the same Acctno,

and the appropriate fields thereof (at least the current-

period fields 168’, 169’) are zeroed. A match between

MAFR and TRAFR is obtained (test 430), the TRAFR

Catno is checked (test 432) for valid code, print-out 436

sets up the TRAFR data for a valid Catno on the Jrnl

{print-out 434 for an invalid Catno), and Acct-tot reg-

ister 408 is accumulated by the TRAFR amount, as well

as the registers 400, 402 for a valid Catno. Thereafter,

loop 438-448 obtains the next TRAFR to be processed

(i, e. not previously processed and therefore not flagged

and Acctno not blanked), and if the same Acctno and

Catno, there is a loop back via tests 450, 452 and 432

to repeat the processing (print-out 436 or 434) on the

TRAFR data, and so on. Where the next TRAFR has

a different Catno, print-out 454 steps up the Cat-total

on the Jrnl, the totals in registers 400, 402 are placed

in the corresponding MAFR fields, and these registers

are blanked. Thereupon, the control loops back to PUT

414 to GET the next MAFR, if any, for this Acctno,

and repeats the processing for the current TRAFR

which does have the same Acctno (as established by test

450). Where all of the TRAFRS of the Acctno have

been processed, control branches (from test 450) to

print-out 456, which performs the Cat-total operations.

Thereafter, print-out 458 prints the Acct-tot from regis-

ter 408, which totals are used to proof (test 460) the

totals of the DDA bank statement for the same current

period, and subroutine 462 winds up the MAFRS, if any,

for the Acctno of the Jrn] just completed. When there

is no match on Catnos (test 430), test 478 determines if

there are no TRAFRS for the MAFR Catno, or if the

TRAFR Catno is invalid. If the latter, loop 480, 482,

452 processes the successive TRAFRS with invalid Catnos

until the next Catno is found. Similarly, where the

MAFRS terminate for a particular Acctno (test 420)

and TRAFRS remain for that Acctno, the latter have

invalid Catnos and loop 484-490 processes them.

Summary Sheet Run. The Summary Run 108 makes

use of the MAFI 106 as updated by the Jrn] Run 100.

There is no further updating of the MAFI, so there are

no file outputs in this run 108, and the outputs are the

printed summary sheets (Fig. 11 or 12) that present

the record-keeping data and analysis developed from the

customer’s transactions and chart of accounts. The

TRAFI is not required in this run, since all of its data

has been extracted during the Jrn! Run and utilized to

update the MAFI.

Different forms of summary sheets (e. g. those of

Figs. 11 and 12) are utilized, depending upon the char-

acter of the account; for example, a personal account

will generally require a simpler form of record-keeping

and a business or professional account a more elaborate

form of record-keeping and analysis. It has been found

that agricultural accounts have special characteristics

which may call for a somewhat different form of sum-

mary sheet, such as that of Fig. 12. In this format, the

same Catno may be used for both expenses and income.

An example of this is in crops, or any particular variety

thereof, where the farmer’s record-keeping is more help-

fully presented to him if he can identify both his ex-

penses and his income in connection with the same crop

activity. Thus the use of the same Catno for both has

been found to be helpful. This form of summary sheet

(Fig. 12) can also be used for personal and business

accounts if desired.

In a personal account, it has been found to be suffi-

cient to provide two general areas of record-keeping,

namely, one for income and the other for expenses, with

individual totals for each area. If a customer desires,

the income can be broken up into more than one level

(e. g. taxable and non-taxable income) with totals pro-

vided for each, as well as an overall income total. Simi-

larly, the expenses can be broken up (e. g. deductible

and non-deductible), with Level-I totals, as well as the

overall Level-II total therefor. In a business type of ac-

count, for example, a format may consist of an area for

income with a Level-I total, an area for cost of income

with a Level-I total therefor, and a Level-II total in the

form of “Gross Profit” consisting of the difference there-

between, with the foregoing followed by another area for

Overhead Expenses with a Level-I total therefor, followed

by another Level-II total in the form of Net Profit or

Loss, representing the difference between the first Level-I

total and the total of overhead expenses. Various other

formats of business record-keeping summary sheets may

be employed, and with the transaction data supplied and

the chart of accounts in the system of this invention, a

balance sheet summary may be provided.

For purposes of distinguishing between the different

classifications or types of account, the name record 142

and each account’s master sub-file 140 (Fig. 5C) con-

tains a system-flag field 146 which identifies the type

number of the account. In performing the summary run

it may be restricted at any time to a single type of sum-

mary sheet format (e. g. personal, business or agricul-

tural, Fig. 11 or 12) since, for efficiency and reasons of

cost, only a single output printer may be available. For

this reason, the cycle record specifying the account

numbers to be processed at any time would specify the

particular account type number (Typno) to be handled

during a run. This typno is stored in a working register

500. Alternatively, a console entry or punch card may

be used to establish the Typno to which the run is to be

restricted at the time that the operator sets up the

particular summary sheet to be run through the printer.

The same cycle range 101 and the same requests that

determined the Jrnl-Run processing are employed in

overall control of the Summary Run, and the Acctnos of

the cycle range and the requests are established in the

working registers 190 and 192. The Summary Run starts

with GET 502 the MAFR, and thereafter proceeds with

GET 507 the cycle record, and GET 508 the request

record to establish the latter in registers 190 and 192.

The input control section of the Summary Run, made

up of operations 507-512 and 522-526, is generally the

same as the corresponding input control operations of

the Jrni Run (Fig. 8A) and are referenced by the same

numerals except that in the Summary Run they are in

the 500-series while in the Jrnl Run they are in the

300-series. Details of the operation of these portions of

the Summary Run will be readily understood from the

corresponding description of Fig. 8A.

When test 510 finds equality of the MAFR with that

of the REQ record, the REQ switch is set 512; there-

after (or after test 524 finds the Acctno within the CYC

range), the program proceeds with test 528. The latter

determines if the system flag in field 146 of that MAFR

is the same as the preset Typno stored in register 500.

If test 528 is NO, test 530 checks the setting of the

REQ switch, and if it is set, an error-message print-

out 532 indicates that the Acctno of the REQ card did

not have the proper system flag. Thereafter the pro-

gram returns to perform the operation to GET 508 the

next REQ record, and the process is repeated. If test

530 is NO (the Acctno is within the CYC range, but

it is not the type of account (Typno) requested in

550, EMOF test 552 and same-Acctno test 554) to find

the next MAFI Acctno.

If test 528 finds the proper system flag correspond-

ing to the Typno, set 534 determines if the Typno

corresponds to a business account. If YES, the program

branches to the subroutine 536 for processing business

summary sheets. If test 534 is NO, a test 538 de-

termines if the Typno is for personal summary sheets.

If YES, the program branches to subroutine 540 to

process the records for the personal summary sheet. If

test 538 is NO, the program proceeds with subroutine

542 to process the agricultural type of summary sheet.

All of the subroutines 536, 540 and 542 exit to test 544

to determine whether the processing had originated from

a REQ record or the CYC range, and the program

returns to re-entry points 510 or 508 accordingly.

If test 526 determines that all of the Acctnos specified

by the REQ and CYC records have been processed, the

program proceeds to the end run 546; its operations

consist of the usual wrap-up housekeeping together with

printing out any REQ records that remained unprocessed

upon coming to the end of the MAFI (such requests

necessarily being invalid). If test 526 is NO, the program

enters the loop 548 to GET a new MAFI Acctno. That

is, loop 548 is entered under conditions of the current

Acctno not being within the CYC range nor specified by

a REQ, and it is necessary to run through the MAFR

of the current Acctno until test 554 finds that the next

one is obtained, and the loop exits with control return-

ing to test 510.

The subroutine 540 for processing personal summary

sheets is shown in Fig. 9B. It is assumed that the RK

summary statement may take the form shown in Fig.

11, in which the amount data are to be supplied, but

not percentage data (the latter is described with ref-

erence to Fig. 9C). The initial operation 556 consists

of printing on the summary sheet 110, in the appropriate

areas 120, 122, the name and address together with the

Acctno, the month and year of the period for the sum-

mary sheet, and any other required data that may not

be supplied by the name record 142 then currently in the

MAFR input register 184. Thereafter, GET 558 brings

the next MAFR into the input register 184, which record

~ —

is the cred-deb record 148. This record is handled by a

loop 559 that includes the series of record-identifying

tests 560 through 570, and it fails all of these tests

(except same-Acctno test 562, which it passes), and

the branch from the last test 570 returns the loop to

GET 558, whereby the next MAFR is obtained. Gen-

erally speaking, this next record is a General-Title record

152 which passes tests 562 and 566 ‘and fails the tests

560 and 564), and the program branches to a print-out

572 of the title record portion 165 (i. e. the Catno and

description, such as “100-Income” shown in the first row

of Fig. 11 in columns 124 and 126. Thereafter, control

returns to GET 558 the next MAFR. This next record is

usually a YTD record 153, which is identified as such

in test 564, from which the program branches to control

574 to accumulate the YTD amount of this record in

depending on the identifying flags in fields 170 and 171

of the YTD re*ord (if the Fig. 12 format of summary

sheet is used, the YTD MAFR may contain both income

and expense amounts, both fields 170 and 171 would

have flags, and both sections of register 404 would

accumulate the corresponding amounts from fields 169

and 168). Likewise, the current-month amount of the

YTD record is accumulated in register 405 and in the

corresponding income and/or expense section thereof.

In addition. the accumulation takes place in the Level-IT

registers 406 and 407 in the same fashion as that de-

scribed for the Level-I registers. By way of example,

the Level-I registers 404 and 405 may initially ae-

cumulate taxable income and thereafter non-taxable in-

come and, subsequently, deductible and non-deductible

expenses, while the Level-II registers 406 and 407 ac-

cumulate total income and, subsequently, tota! expenses.

Print-out 574 also calls for the printing of this YTD

record; the title name or description 163 is printed in

column 126, together with the Catno field 161. and the

current-month amount and YTD amount fields 168, 168’

(or 169, 169’) are printed in the appropriate columns 128

and 130. All of the data to be printed out comes from

certain specified fields of the YTD record and go to

specified locations on the summary sheet, so that routine

procedures may be used to perform the print-out 574.

Thereafter, the program returns to GET 558 the next

MAFR, which may be a second YTD record 154, and

the processing thereof is similar to that described.

. After a first group of YTD records are processed, a

Level-I total record 155 may be the next MAFR in in-

put register 184, and this record is detected by test

568 and the program branches to print-out 576. Here

the contents of the record are printed out. That is, the

Catno 166 and title name 165 retained in this record

(Fig. 5D) are printed out as well as the contents of

the corresponding portions of working registers 404 and

405. In order to determine which section (income or

expense) of each register 404 or 405 is to be printed

out, a simple procedure may be employed; the income

section of each is tested for All-Zeros, and if not such

the income section is printed out, but if it is All-Zeros,

the expense section is printed out. The control 576

thereafter blanks the Level-I registers 404 and 405 and

the program returns to GET 558 for the next MAFR.

In a similar fashion, a new section of the summary

statement may start with a General-Title Record (cor-

responding, for example, to “120-Expenses” in Fig. 11)

and the program operates in the manner described to

print out this Catno and title and to process the succeed-

ing YTD records. Thereafter, an additional Level-I total

may be provided and processed in the manner described.

Where a Level-II total record 157 is provided in the

chart of accounts, this record is identified in test 570

and is processed by control 578. The latter prints out

the Catno and title-name of the Level-II total record,

as well as the contents of the Level-II working registers

406 and 407 (in a manner similar to that described

above for the Level-I print-out), and the contents of

the Level-I and Level-II registers are blanked. The pro-

gram returns to GET 558 the next MAFR, which may

be a new Acctno record that is identified by test 562,

from which the program branches to control 580 for

blanking all totalizing registers 404-407 in order to en-

sure that they are in that condition with the termination

of the summary statement for the previous Acctno, and

the program returns to test 544 (Fig. 9A) which leads

to the proper re-entry for the input control section of

this run. After all of the MAFI has been processed,

test 560 detects the end-of-file record and the program

returns to end run 546 for the wrap-up.

In operation, the Summary Run provides a complete

record-keeping report in accordance with the customer's

own individual charts of accounts, which controls the

generation of the customer’s summary report on a form

that is blank except, for example, for the captions of

the columns and a suitable heading. The customer’s own

master sub-file (his chart of accounts) determines the

record-keeping system, and the format and descriptive

titles on the summary sheet. The Summary Run operates

to print reports that may be different for each customer.

The master sub-file controls the operation of the run

in that the latter comprises a series of tests for recogniz-

ing the different types of MAFRS (YTD, title or total

records) and a set of controls associated with each test

for producing the appropriate print-out, register accumu-

lation avd totalizing. The customer’s title records 160

are selected and serve to provide headings for different

sections of the report and are used to label the par-

ticular record-keeping system chosen by the customer.

The customer’s total records 155 or 157 are selected

and serve to complete the definition of the customer's

record-keeping system; these records initiate different

types of totalizing control operations built into the

Summary Run to report the customer-selected totals at

the required levels. The YTD records supply category

sub-totals, which were accumulated in the Summary Run

and are printed out in the Summary Run at the same

time that they are further accumui.ced for the totals

at different summary levels. Thus, the mechanization

of this system makes it possible for each customer to

select his own chart of accounts of categories, of a

record-keeping system and of report captions. This selec-

tion consists essentially of identifying his own areas of

financial activity and describing them himself for the

category breakdown and names, or of choosing categories

and names from a list that may be composed for his

convenience. The particular record-keeping system to be

used for the reports may also be individually selected.

Thereafter, the customer merely categorizes each trans-

action in accordance with his own chart, and he may

revise any part of that chart whenever he desires. The

actual summary report may be generated on a largely-

blank form and compactly and individually reports the

customer’s financial transactions.

The subroutine 542 for the agricultural summary

sheets is generally the same as that described for the

personal summary sheets (Fig. 9B), with certain minor

modifications. For example, the summary sheet format

found most vseful for the agricultural report is of the

type shown in Fig. 12. wherein both expenses and income

can be applied to the same Catno. In this case, the fields

168, 169 (168’, 169’) both carry category totals, and the

accumulation controls 574, 576 for these YTD records

are directed to both the income and expense sections of

the Level-I and Level-II registers 404-407, rather than

in just one section as described above for the personal

summary sheet. In this system, a farmer may select his

own chart of accounts, and the report print-out is com-

posed accordingly on largely-blank forms.

In connection with business reports, more detailed ac-

counting analysis is generally desired, and this analysis

may all be supplied with the MAFI chart of accounts

of any business and with the Catno data supplied with

the original transactions of the business. By way of

example, the processing subroutine 536 for business sum-

mary sheets may take the form shown in Fig. 9C, where

parts corresponding to those described with respect to

9B are referenced by the same numerals, with the addi-

tion of a prime. Initially. print-out 556’ sets up (as de-

scribed above for Fig. 9B) the name and address of the

account on the summary sheet (of the type illustrated

in Fig. 11, in which the percentage columns 582 and 584

for current month and YTD are employed. The next

control 590 consists of saving the file address in file 20”

of the start of the master sub-file for the current Acctno.

his address is then available, since it corresponds to the

beginning of the current name record then in the input

file address register, knowing the size of the block of

data read into the MAFR input register 184). This

STRT-ACCT is inserted in a working register 592.

The next control 594 GETS the next MAFR, which is

the cred-deb record 148, identified as such in test 600,

and since it is not used here, the program then loops

back to GET 594, the next MAFR. This record will

usually be a title record 152, and is recognized again as

such by test 600 when the program loops back again to

GET 594 the next MAFR. This MAFR ordinarily will

be a YTD Catno for income, which will be recognized

as such by test 602, and the program passes to control

604 to accumulate the YTD and current-period income

amounts in an additional register 606, similar to the

Level-I and Level-II registers, and used for accumulating

the total income for valid Catno items, and as a base

for computing percentages for the remainder of the ac-

count. Any other base may be accumulated for this pur-

pose; it has been found that this total of income is one

which has broad acceptance and meets the needs of many

customers. The customer’s master sub-file may incorpo-

rate an extra flag in field 170 or 171 which may be used

by test 602 to identify the percentage base field ‘income

or expense), and the loop operates to accumulate all such

records unti! test 598 initiates a branch to control 608.

Thereafter, the program loops back to GET 594 the

next MAFR, and this processing of successive income

Catno records proceeds in the manner described above

until the end of the income Catno records is reached and

detected by test 602, which corresponds to the condition

of register 604 having the complete accumulation and the

proper base for computing percentages. This approach

relies on a uniform procedure used in setting up charts

of accounts, that all initial records correspond to income

records, which in turn are followed by expense records.

Where a different chart of accounts procedure is used,

such as that corresponding to the summary sheet of Fig.

12, or where different areas of expense may interleave

areas of income, an alternative procedure can be used

Ve ee

for caleulating the percentage base, as noted above in

the use of a flag to identify base records. If the test 602

identifies the end of income Catno records, the program

branches to operation 608 for the next stage of the proc-

essing. Similarly, if a new Acctno is detected by test

598, the accumulation likewise ends and the branch to

operation 608 takes place; and similarly if test 598 finds

the end-of-file.

The operation 608 uses the STRT-ACCT address in

working register 592 for the next GET 558’. In effect,

the read heads on the input file 20” are reset to go back

to the first record of the Acctno whose percentage base

was just accumulated in register 606. GET 558’ and

the series of tests following thereafter that form a loop

559’ all correspond to similar operations and tests in the

subroutine of Fig. 9B, and the parts corresponding to

those described above are referenced by the same nu-

merals with the addition of a prime. As described for

Fig. 9B, the first record to be processed is the first Gen-

eral-Title record 152, which is detected by test 566’ and

printed out by operation 572’. Thereafter the YTD rec-

ord 153 is detected by test 564’, and operation 610 ac-

cumulates it in the Level-I registers 404 and 405, and

also computes the percentages of these amounts on the

basis established in the two sections of register 606.

Thereafter, operation 612 prints out the category record

with the appropriate current-month and YTD amounts

being printed in the corresponding columns 128, 130 of

the summary sheet of Fig. 11 and the corresponding

current-month and YTD percentages being printed in the

associated columns 582, 584. Thereafter, test 614 deter-

mines if the current YTD record is an income record.

If YES, its amouxts are added to the appropriate Level-

II registers 406 and 407, and if No, its amounts are

subtracted from the corresponding Level-II registers 406

and 407. This net accumulation in the Level-II registers

406 and 407 provides a running total, for example, of

the gross prefit, with the income being incremented and

the expenses or costs of that income being decremented.

From either contro! 616 or 618 the program returns to

GET 558’. When a Level-I total record 155 is detected

;

by test 568’, control 620 computes the percentages of the

two totals in registers 404, 405 on the bases established

in the two sections of the register 606, and print-out 622

prints on the summary sheet the total Catno, the descrip-

tion, and the Level-I totals established respectively in

registers 404 and 405 and the corresponding percentages;

the Level-I totals are blanked. The next MAFR is ob-

tained and the process continues, depending upon the type

of record, in the manner described, and when a Level-Il

record is detected by test 570’, control 624 computes the

Level-II percentages, using the amounts in registers 406

and 407 and based on the totals established in the two

sections of register 606. The Level-I totals are also

blanked at this time. Print-out 626 prints the Level-Il

total, the Catno, its description, and the Level-Il per-

centages, and blanks the Level-IJ totals. Thereafter, test

562’ detects a different Acctno in a succeeding MAFR

and control 628 blanks all of the total registers and the

percentage-base register 606, and the program returns

to 544 (Fig. 9A) to process the next account. If the end

of MAFR is detected by test 560’, the program branches

to end-run 546.

In operation, the controls 594 through 604 are con-

nected as a loop 605 to develop the base of percentage

computation. This loop 605 operates as a preliminary to

the remainder of the processing of a particular account,

and after the percentage base has been fully accumulated

in register 606 by control 604 for a particular account,

the control 608 resets the address of the input file 20”

to the start of that account. Thereafter, loop 559’ oper-

ates to process the successive MAFRS of that account’s

sub-file to print out the various areas of the summary

sheet and to accumulate and print out totals as defined

in the total MAFRS of the sub-file, as well as to calculate

and print out percentages on the accumulated basis in

to accumulate gross profit as the difference between in-

come and expense.

This invention is not restricted to any particular num-

ber of levels of totalizing. It has been found that a Level-

II control is generally desirable for presenting a major

or grand total of two or more Level-l or intermediate

totals. These total levels may be readily specified in set-

ting up any chart of accounts. In addition, a third type

of level is often desirable for the purpose of showing

differences between other totals (e. g. for profit and loss).

That is, a Level-Ii1 total record is inserted in any chart

of accounts by specifying a particular identifier therefor,

which is recognized by a particular test (similar to test

568’ or 570’) that is provided to generate a series of

control operations (similar to 624, 626) in connection

with Level-lll register (similar to registers 406, 407)

which is automatically incremented and decremented by

suitable controls (similar to 614, 616, 618). The Level-

ill totalizing affords the flexibility of providing a net or

difference between precedent sum totals of the Level-l or

Level-il variety. Thereby, a net profit or loss may be

furnished in the Summary Sheet Run, as described above.

In addition, where it is desired to provide a balance sheet

statement for a business, a Level-IV totalizing can be

specitied by a specific total record inserted in the chart

of accounts. The operation performed likewise consists

of an incrementing and decrementing, and the Level-III

operation consists of testing the contents of its register

for a zero-balance; if it is a zero-balance, it is printed

out, and if it is not, the difference is printed out and

the register reset. In a Level-III control, the register is

not reset until a new account is indicated or until a

Level-IV or -V control is called for. Another variation

in the form of a Level-V control is used with increment-

ing and decrementing of the register in the manner de-

scribed above; the Level-V control calls for a print-out

at the specified ievel, and the register is reset. This

Level-V is used to obtain a net cash flow at intermediate

record-keeping levels, and has application, for example,

in multi-branch businesses or in multi-farm agricultural

accounts where the individual cash flow for each business

or farm is shown on the account. The Level-III control,

as distinguished from a Level-V, provides a register-

total print-out whenever Level-III is callea for, but it

— EL &

~~eo—_—-—

does not reset the register. Each type of total control

at any level is effective to reset all lower level registers.

Various modifications, in addition to those noted above,

will be apparent to those skilled in the art from the above

description. For example, in ordinary banking operations,

a customer often makes a deposit incorporating a number

of diverse items on the same deposit slip. It is not neces-

sary with this invention that a separate deposit slip be

used for each Catno. Instead, a separate Catno may be

applied to each item on the deposit slip, and when the

bank processes that deposit a separate TRAFR for each

of the items associated with a different Catno is gener-

ated, and thereafter the system processes these machine

records in the same fashion as described above. In a

similar fashion, a check is sometimes written covering

a number of different record-keeping items, such as a

check to cover a credit card bill, where the general credit

card may be applicable to a wide variety of charge

account items. For this purpose, the check may have

printed areas for different items associated under the

total check, and each such item is given a separate Catno

in accordance with the customer’s own chart of accounts.

Here again this multi-item check may be processed by

the bank into a separate TRAFR for each item within

the check, whereby the customer’s record keeping is fully

and automatically processed.

The transaction journal may be used in place of the

conventional bank statement by the addition to the Jrnl

of the beginning and ending DDA balance for each ac-

count. With relatively minor modification of the system

this combining of the two statements can be developed;

that is, an additional record is provided in the MAFI for

each account, which carries the account DDA balance

for the beginning of each statement period, and the date

associated therewith. At statement time, the TR-Jrn! is

processed in the manner described and an accumulator

cremented and decremented by each deposit and check,

respectively, to obtain a final DDA balance which is

printed out on the check and utilized as the beginning

balance for the next statement period.

inted

noted above, the TR-Jrnl need not be a pre-prin

Pa -4 but actually may - a —_ hd bg Lene es

s the run is performed. at is, the

oe on the Jrnl may be automatically printed

from a control operation specifying that the print-ou

to be a journal, with the general format of the pope

stored in a look-up table that controls the — up 0

that report form in accordance with known tec —.

The individual captions in each column and the nag

the columns likewise can be set up in a er ~

with the particular specifications of each account (in 1 :

master sub-file) being controlling as to which section ~

the look-up table controls the setting up of the oa

format. Thereafter, in other respects the developmen =

the journal report is in the manner described —

the particular locations of the amounts to be — =

being established by the look-up table controls. yl

similar fashion the summary sheet can likewise be a!

veloped from a blank form and its format “¥ is e

in a look-up table, with provision for different —

in accordance with the record-keeping system = A a

by the customer’s chart of accounts. The use of the -

of accounts of the MAFI for this purpose will be readily

apparent to those skilled in the art from the foregoing

iption.

rae Cadition, the transaction journal and summary sheet

runs may be combined into a single run. For this pur-

pose, separate printers may be used each et >

printed journal and summary sheet forms, or —

printer may be used with an unprinted form (whic ; :

composed in the manner described above) to —— ™

journal format or the summary format called for by e

customer’s chart of accounts as well as by the — ar

section, journal or summary sheet, of the run ing

operated at that time. For this purpose, the journa beony

is performed generally in the manner described above,

except that the updated MAFI file is written out on a

working file that takes but one account's output data as

it is processed by the Jrnl section of the run. Thereafter,

the updated MAFI on the working file is utilized to com-

plete the Summary portion of the run to print out the

summary sheet in the manner described above. As each

record from the working file is processed in the Summary

Run, it is then written out to the update file 22” for the

MAF'I, as described above, to produce a combined up-

dated file. Another approach for a combined journal and

summary run employs a wide, pre-printed sheet which

has the journal format on one half and the summary

format on the other. As each active Catno of the Jrnl

Run is processed, the summary for that active Catno is

then printed out on the summary part of the report.

That is, as the Jrnl is processed for any Catno, all the

data for the summary print-out exist in working storage

at that time, as will be apparent from the description

of Fig. 8 above. This process is repeated for each active

Catno; in order to have a parallel presentation of corres-

ponding rows of the two reports, the data for any in-

active Catno are not printed out. The general titles may

be printed out and spaces left for corresponding rows on

the transaction journal without destroying the neat pre-

sentation of that report. The totals may be omitted from

the summary sheet, or instead they may be accumulated

and printed out, but generally would be limited to totals

for the active Catnos. As a supplement to this monthly,

abbreviated summary statement, periodically (such as on

a semi-annual basis) a full summary statement is pro-

vided in the manner described above for Fig. 9.

For the purpose of saving master file storage, one may

modify the MAFI format from that shown in Figs. 5C, D

and E. That is, for certain Catnos, such as those which

experience shows are most commonly used and in which

uniform descriptions are accepted by customers, the de-

scriptive portion of the Catno may be omitted from the

MAFR and stored instead in a look-up table. The MAFR

for that Catno carries a flag instead of the description,

and the flag during the Summary Sheet Run calls for an

entry inte the look-up table at the proper Catno for read-

ing out the description to be printed. Though this can

be done with all of the Catnos, generally for versatility

in meeting the varied needs of businesses and personal

financial record keeping, it is desirable also to make pro-

vision for the storing of specific descriptive titles in the

Ee a re ee

MAFI, as described above. Even where the pre-assigned

titles are used for Catnos, and they are stored in a look-

up table, nevertheless the customer can be afforded the

versatility of selecting his own chart of accounts from

an overall category listing. In the pre-assigned system,

if a customer does not wish to utilize the pre-assigned

description, he may still employ the same Catno and sup-

ply his own description; in the absence of the afore-

mentioned flag, the look-up table is not entered and the

customer’s own choice of description is printed out in-

stead. It has been found desirable in many cases to em-

ploy a combination of pre-assigned descriptions with the

flexibility of customer-chosen descriptions. One use of

such a system is for purposes of information retrieval of

the pre-assigned categories; certain classes of accounts

(e.g. farmers dealing with certain classes of crops or

livestock) would have total data in the Catno types of

MAFRS that could be extracted and analyzed on a sta-

tistical basis to provide valuable interpretative data of a

particular region or community. Other examples of the

use of such systems are to determine what the general

population is spending for medical expenses or housing,

and the like.

In the processing of accounts at the cycle period, in-

stead of processing them by a specified range of Acctnos

as described above, the cycle flag 147 may be used. There-

by, at each particular Jrnl and Summary Sheet Run, the

operator need only specify a particular cycle flag, and

the operation of selecting the proper account is by way of

a match on the cycle flag rather than determining

whether the Acctno fell in the specified CYC range.

In Fig. 13, a top view of a check imprinting device

640 is shown, with parts broken away to show the use of

a customer service or credit card 642, which is used to

develop certain portions of the check. The service card

642 may be a plastic dise of the conventional form used

for credit cards, in which raised imprinting characters

are provided for the payer’s bank name 644, payer's

Acctno 646, the bank routing number 648, and payer’s

name 650. This credit card is positioned at a predeter-

mined location on the printing bed 652 by guides 654

which position the various edges of the card 642. A key-

board 656 is provided having slidable keys 658, each

movable in a slot 660 and connected by appropriate link-

ages (not shown) to an individually rotatable number

wheel 662 having raised characters for imprinting. A

bank 664 of such keys 658 and associated wheels 662

is used for entering the amount of the check in dollars

and cents. A second bank 666 of similar keys 668 and

wheels 670 is used for entering the Catno of the check.

A set of imprinting wheels 672 is readily adjustible to

present the date of the check, and a semi-permanent

template 674 contains the name and account number of

the payee organization, as well as the name and transit

number of the payee bank. The check writer 640 operates

in a fashion similar to the conventional credit card im-

printer, in which the credit card is inserted in the guides

654, the position of wheels 672 is adjusted to enter the

date, keys 658 are adjusted to enter the amount of the

check in wheels 662, and keys 668 are adjusted to enter

the Catno in wheels 670.

Positioned on top of the bed 652, service card 642 and

wheels is a multi-leaf document with interleaved carbons,

such as is commonly employed with credit card im-

printers. The hinged head 676 of the imprinter moves

down over the printing bed 652 and positions the docu-

ment 678 therebetween. The head 676 may contain a

printing roller (not shown) which is connected to a

handle 680 slidable in a slot 682. Movement of the handle

from left to right through the slot 682 applies roller

pressure to the paper document to receive the impression

from the raised lettering of the service card, the template

674, and the number wheels 662, 670 and 672. Thereby

a document is printed which may be used as a machine-

readable record; that is, the type fonts of all of the raised

lettering on the service card 642, the template 674 and

the number wheels are chosen to be of suitable special

type for optical or, if desired, magnetic-ink reading de-

vices. The printed checks developed by the imprinter 640

have their transaction fields at specified locations for a

document reader 16 to handle and to transfer into suit-

able combinatorial electrical signals. This imprinter 640

may be used by sales organizations in place of the usual

charging systems. Thereby, a machine-readable document

is developed directly by the writer of the check, with the

Catno entered in machine-codable form when and where

he check originates.

; The ya 678, when in the form of a check, would

be pre-printed to carry the usual “Pay to the Order of

information at an appropriate place adjacent to the tem-

plate 674, as well as the signature line and other appro-

priate data. Thereby, the bank check that comes out of

the printer 640 is complete both as a machine-readable

record and as a check. For such purposes the template

674 need not be employed, but it is preferred in order

to carry the data required for automatic processing of

the payee Acctno and payee’s bank transit number. With

these machine-readable records, the check serves the dual

function of a debit against the account of the credit-card

holder as well as a credit to the business s payee) extend-

ing the credit. Such a check (or credit-card receipt )

would be handled in the same fashion as described above

when treated as a debit to be charged against the payer's

account, and would be processed for account balance and

record-keeping purposes in the manner described above

(Figs. 2 and 3). In addition, this check is used as a

credit transaction record for purposes of automatically

crediting to the payee’s account as though it were a

deposit slip, in the same manner as described above for

such deposits. For record-keeping purposes of the payee’s

account, a “credit” category code field can be added at

a specified machine-readable location associated. for ex-

ample, with the template 674. Thereby, all of the infor-

mation for automatic record keeping of the payee’s ac-

count is also provided on this “check.” Accordingly. the

imprinted check document 678 provided by this device

640 is a uniquely constructed machine-readable record

in that it contains, in machine-readable form, the infor-

mation provided by template 674. That is, the check

carries data fields 677 and 675, respectively, for the

payee’s account number and that of his bank (with the

appropriate routing information) so that it can be proc-

essed automatically as a machine-readable document for

the payee Accordingly, the check assumes a double char-

acter fur automatic processing; in addition to serving

all of the functions of previous checks, it also serves as

the equivalent of a deposit slip, since the data required

for routing to the payee’s bank and for posting to the

payee’s account therein is in machine-readable form on

the check. The complete processing can be performed

without composing additional documents as is presently

required and without the manual labor and successive

handlings associated therewith, each of which often re-

sults in the entry of errors on hand-composed documents.

The large amount of labor required by banks to com-

pose the machine-readable records is eliminated, and the

responsibility for accurate entry of the machine-readable

data fields is placed in the hands of the originators of

the documents.

Similarly, a check imprinter 19 of the type shown in

Fig. 13 is adopted for use by the bank customer in his

own establishment for writing checks directly with the

RK Catno directly on the check in machine-readable form.

Where the device 640 is used by the payer to write his

own checks, the template 674 is not utilized, nor is serv-

ice-card 642 required; for the document 678 is in the

form of pre-printed checks of conventional machine-

readable form carrying all of the data required for proc-

essing the check, and the device 640 serves to supply the

remaining machine-readable character fields for the cate-

gory number and the dollar amount. Thereby, the payer

writes a check that carries in machine-readable form all

of the data required for automatic processing through

his own bank, so that it can be automatically posted to

his DDA account and automatically processed for record

keeping in the manner described above. For this purpose

a simply constructed device is formed of the essential

character of the device of Fig. 13, but small enough and

compact enough to be carried in one’s pocket in the same

fashion as a conventional check folder. An embodiment

of this device is illustrated in Figs. 14A and B.

In the pocket check-folder 690 of this invention, two

body members 692 and 694 are hinged together and a

stack of checks 696 is attached to the bottom member

ee enna ee

694 and retained in position between the two members

692 and 694. Preferably, a fold-over flap 698 is hinged

to member 694 and folds over the checks 696 and cover

member 692 to prevent accidental imprinting. The flap

698 is also used to carry the conventional register book

699 in which the payee records the check data. Such

checks are pre-printed and carry (as in currently avail-

able systems) machine-readable fields of the account num-

ber of the payer as well as the routing data of the

payer’s bank. In accordance with this invention, the

pocket check-folder is constructed so that the payer com-

pletes the imprinting of the check as a machine-readable

document for automatic processing in the system described

above. For this purpose, the cover 692 is provided with

two sets 700 and 702 of slidable tapes 704 each carrying

a sequence of spaced numeric printing type characters

706 attached to the inner tape surface (e. g. each tape

contains the numerals 0 through 9). A suitable number

(e. g. three or four) of such tapes 704 form set 700

for the Catno and a suitable number (e. g. five or six)

form set 702 for the dollar and cent amount. The raised

imprinting type characters 706 may be of the rubber-

stamp type carrying the ink in the imprinting type

material; or alternatively, impact type paper may be

used for the checks 696 in which the ink is formed in

small, separated globules which are embedded in the

surface of the paper, and which are burst by the type

during the imprinting process. The type fonts are suit-

able for any particular document reader 18 that is used.

These tapes carry the type characters 706 in reverse

printing relation.

The check-folder and writer 690 is preferably formed

of inexpensive plastic materials so that it can be dis-

carded after a stack of checks 696 are used. The inside

surfaces c* the members 692, 694 and 698 are formed

of a sheet of soft plastic material such as that used for

conventional check folders. The bottom and flap mem-

bers 694 and 698 are preferably formed of at least

two layers of such plastic, whereby checks 696 and

The checks 696 are preferably secured to a stiff paper-

board or plastic backer which, in turn, 1s secured (e. g.

by bonding) to the inside layer of member 694. There-

by, the checks are retained in pre“etermined relation

to the type characters 706 for printing at predetermined

areas 708 and 710 respectively associated with the Catno

tapes 700 and the amount tapes 702. The plastic between

the members 692 and 694 is grooved to form an integral

hinge 712. A similar hinge 714 is grooved in the

plastic material between members 690 and 698. The

outer surface 716 of cover 692 is formed as a sheet of

relatively stiff plastic material that is bonded to the

inner plastic face. Extending across the width of the

outer face 716 (Fig. 14B) are a series of deep de-

pressions 718, which are spaced the width of each tape

704, so that each adjacent pair of depressions form a

guide channel for a tape 704. Each tape is retained and

slides smoothly between a pair of guides 718. A cut-out

opening 720 in face 716 is formed between each adjacent

pair of guides 718, and extends about half-way from

near the upper edge to about the middle of the cover.

The tapes 704 are formed as flexible, rectangular plastic

or metallic members, and each has a projection or hook

722 at the upper end which extends through the open-

ing 720 to be accessible to the finger nail of the user.

Along the outer face of each tape 704 is a sequence of

numeric characters that are uniformly spaced and ar-

ranged in positions directly opposite to the type char-

acters 796. A window 724 in face 716 is formed as a

clear plastic section at about the center of the face

716, and extends down from the lower edges of the

openings 720 about the height of the numeric character.

The length of each tape 704 is about half or less the

width of the cover face 716. Each tape slides as a

simple linear device in the channels formed by guides

718 up or down from a media! position at which, for

example, the character “4” is positioned in the window

724 as illustrated in Fig. 14B. All of the characters

may be positioned at that window either by running the

slide up to half its length up the channel (with “9”

in position at the window 724, in the extreme upper

adjusted position), or down the channel to about haif

its length (with “0” being in the window at the extreme

lower position). The operator can quickly and easily

make these adjustments by manipulating hook 722 on

each tape (or by providing somewhat larger openings

720 and knurling the tape surface, whereby the user’s

finger can engage the tape directly to manipulate it).

The section of the cover face 716 below the medial window

724 is preferably made opaque or diffused, so that the

window 724 clearly presents and identifies the characters

to be printed. In the inner, flexible surface of cover

692, two windows 726 and 728 are provided at positions

diametrically opposite to the window 724 (and the cor-

responding window, not shown, for the amount tapes

702). The type characters 706 for the Catno tapes 700

can project through the window 726, and similarly, the

type for the amount tapes 702 can project through the

window 728.

In operation, the checks 690 have the pre-printed

coded fields 730 in a suitable area of the check (e. g.

along the lower edge), in a suitable manner, such as

described above with respect to Fig. 4. The user may

write his check in the conventional manner, except that

the numerals for the Catno and the dollar amount are

imprinted directly in machine-readable form. That is,

the user sets the tapes ‘700 for the Catno by sliding

them up or down to position the desired Catno in the

window 724, and similarly, positions the tapes 702 for

the dollar amount. Thereafter, the cover 692 is pressed

down toward the bottom member 694 so that the inner

face of the cover rests against the top check 696. The

user slides his finger across, or individually presses down

on, each character at the window 724. The stiff plastic

cover 716 transmits the finger pressure to the flexible

tapes 704, so that the corresponding type characters on

the reverse sides of the tape project through the windows

726 and 728 and are impressed to print on the top check

696 at the areas 708 and 710, respectively. Thereby,

the encoding of the check as a machine-readable docu-

ment for automatic record-keeping at the bank is com-

pleted. When a check is not being written, the flap

698 folds over between members 692 and 694 to prevent

any false imprinting.

Accordingly, with the check writing device 690, the

ordinary bank customer may directly encode his check

as a machine-readable document so that it may be auto-

matically processed thereafter. The bank need not re-

encode the document and thereby avoids the problem

of making errors in its customer’s records, and the

relatively expensive manual labor of encoding such docu-

ments is largely eliminated.

The service or credit card 642 may be constructed

to carry the Catno characters directly. That is, credit

card 642 may be constructed with a set of number

wheels or slidable number tapes, having a few raised

numerals for imprinting. When the card is used, the

owner adjusts the wheels or tapes to set up the Catno

for the particular transaction. In addition, on the re

verse side of the credit card a space may be provided

for listing appropriate Catnos and category descriptions,

so that the customer can readily enter the Catno for

each transaction to which his credit card is applied.

Thereby, the credit card operating company may supp!y

the user of the card with a periodic record-keeping re-

port of his transactions as well as with a record-keeping

analysis and report thereof in the manner described above.

Various other forms of machine-readable records may

be used with this invention. For example, punch cards

or punched paper tape may be used to develop transac-

tion records that carry data fields in machine-readable

ag (e. g. the fields described above with respect to

ig. 4).

This invention is not limited to use with demand-

deposit banking accounts; the record-keeping may be

performed separately from any banking operations and,

as noted above with respect to Fig. 13, the record-

keeping system may be applicable to credit-card accounts

in a similar fashion. The RK system of this invention

may be fully integrated with the DDA system. For

example, the DDA master file may be combined with the

RK master file, so that a single master sub-file is provided

with each account and all of the transactions are stored

with each master subfile ‘or a separate transaction

file may be provided). It is not necessary for the DDA

master file to carry RK flags that identify the RK ac-

counts; the checks and deposit slips may be pre-printed

with a machine-readable field (e. g. by specially assigned

Acctnos) to identify the account as such. That field

is carried in the TRAFRS and the daily RK TRAFI 82

(Fig. 2) may be constructed via a test similar to test

80 which identifies the TRAFRS for RK processing.

Similarly, credit-card accounts may be appropriately iden-

tified for RK processing. The system is not limited to

using the MAFI Change Run for correcting the RK

MAFI records where, for example, a Catno had been

omitted from a transaction and therefore was not re-

flected in the accumulated YTD totals. The correction

may be made in the Jrn! Run by generating a TRAFR

with the Catno and appropriate data so that the YTD

record can be properly updated by control 436 (Fig.

SC). Such a TRAFR is supplied with an appropriate

flag so that control 436 is limited to accumulation in

the Acct-tot is not changed since it had previously ac-

cumulated all transactions, with or without valid Catnos.

Such modified systems will be readily apparent to those

skilled in the art from the foregoing description.

As described above, this invention provides control

mechanisms for a stored-program digital computer, where-

by the record-keeping of financial transactions of dif-

ferent types of persons and businesses can be auto-

matically performed. This invention is adaptable for use

with various types of computers including those with

large or smal! memory capacities and those with dif-

ferent types of storage files and input-output devices.

In addition, the principles of this invention are ap-

plicable for use with a special purpose computer having

all of the control mechanisms of the various runs and

the files built into the computer in the form of equivalent

logic design. For example, various ones of the above-

described runs may be built into the control system 14

by suitable logic circuits. The RK MAFI may take

various known forms and it functions as a logic board

or control program in that each master sub-file specifies

the control operations to be performed in accordance

Cees SOUPS errs = _-

with the sub-file’s particular chart of accounts. How-

ever, the stored-program form of the invention described

above is preferred in that it is comparatively much less

expensive and more compact. In addition, the stored-

program enables one to modify, enlarge or simplfiy

the system by modification of one or more portions of

the runs; such modification is readily performed without

rewiring of the machine circuitry. Similarly, each cus-

tomer’s chart of accounts may be readily modified to

meet the customer’s changing record-keeping require-

ments simply by inserting or deleting the various records

making up his master sub-file. The RK MAFI may be

constructed to have a greater or lesser amount of vari-

ability among the accounts. For example, instead of

the totalizing records 155 and 157 that are inserted

in and made part of the master sub-file, pre-assigned

Catnos (such as 100, 200, 300, etc.) may be used solely

to initiate the totalizing operations in the Summary

Run; and each time a master sub-file is processed, tests

similar to tests 568 and 570 (Fig. 9B) would determine

when any of the pre-assigned Catnos fal] between those

in the registers 184 and 186 and eal! in the associated

totalizing operations. In constructing each chart of ac-

counts, with such pre-assigned totalizing Catnos, the cate-

gory areas are similarly predetermined by the total

Catnos. Various other modifications of this invention will

be apparent to those skilled in the art from the above

descriptions of illustrative forms of this invention. The

appended claims are intended to cover such modifications

as are encompassed by the scope and spirit of this in-

vention.

Appended hereto is a print-out of a complete program

of one form of this invention for use in the IBM 1400-

series computers. The print-out is written in the Auto-

code assembly language, and the program when assembled

into the machine language for said IBM computer, con-

trols and directs the operation of that computer in ac-

cordance with the invention and particularly with the

form thereof illustrated in Figs. 6-9. Also appended

hereto is a detailed flow chart of said complete program.

[APPLICATION DRAWINGS]

“SSNIIAI| Waid INIdaND ‘to’ op} TSH zaxA| Celt INTAANI 2S

FMUOONIN «TAT: 10001\ I IT F2

NITED oo ral gor fee ZS

JViO2NI . ‘ svi0oni| F44 ETAT ec

o”

ETVIELTE)

80r~ ~ VOONI LOL LDH :

SDUTA DAD FSV >

it) na LOL 8IQA AI2az9

ACY LNNOII LALS 7 VES

zee FH AFLSIDIA 1NA1NO

= ee SH -909 Aad

aLA ISUE Yo oos-f_ ON dAL SAS

| ISNIAXI| STHOL LUD L. IFA FTIAI

HHODN \Add INZLAAN OV r4

Vysiiadxa | s7L0L| ead

~ FONT LU2 GLA

Z(sASLSIDIA LNA LNOY IF IFA LSINOIA

zy?

oox-f Fw wals/ 2a INdnl

& 7s AILSIDTA NANI yoy 02

* -_ é

Gy As0HIIW

ben :

ée Je y

V FOLa :

' — &

OS ot dan Be

s 7 aid

ANMUS ANUA Uda FavdIed ANVILS ANUS

IJUW NA FLUAANA

47/4aL H-a 3lwdadn

Wa FLYUAdN ANY, SNOILIUSNUAL 150d

a a ee ee ee ee ee oe oe ee ee

vF 70aINOD

t “T

\ i tiednaiaie

1 FOWAOLS

i TF-r_. DNIAAOM

a7 amd

1 L925 Aas 00 LAND

1 an te

SIVIV

ve JONYMD 11M J Vvad

Swng vad

{ ECE

; fala OF

[wos sworay——

ajavia

Ca09027A

BEST COPY AVAILABLE

CHECKS*

€ DEPOSITS

MCODE CLS

68~

PROOF MACHINE

ToT RECO? DS ARF

CAT NO PP00FED TO

PrOOF TAPES

PROOF

664 NET TOTAL

AMOUNTS.

CHANGES ll

82 YPAF/ 84

“ RK NCES

| Ss MAF f° 94 88.

CHANG UPDA

RK i tal

TRAFI -

(86

re ae

TRAFI

OUEST W MAFI TOTALS op.

RECORDS FLAG TRAF/ +) TR-JRNL

PROOF TO DDA

101 102

PRINT SULMARRY

BY TYPE

BUSINESS

SUMMARY

SHEETS.

112

Hin. 3.

SHEETS \n~-408

| PERSONAL

SUMAARY

SHEETS

210

INVENTOR.

THOMAS R, JOHNSTON

MdaiihLe

. = ° oO

‘7g OT agsag

| | |r |. | be Gor do] =? iss

FWHN) ON | izan2|aLA| 1xANI\ALA\ ay ‘| ON | aun | LOL a

FILL) 19 | : Aor LU) FILL) 7 “

= hy SHMOINI | ISNIAXT L oe 3

697? 9 a er “gar or Spor

‘Of ‘ALT si . - :

_ FF SSF WT ESFy UST IHINNA. BHT» OFF '

eco ri-:- ~_ = LOL: LOL} } H uu i

vior' TWLOL* gui | waza L1a7a9;| 977\ 574 ON |

| 33s | T°TAT! 21 TaN} LIN dan 7DA9| SAS 2 4990} | St

i ls s ‘Z be 4 a “a

oD aoe «lL . =o — =% - rad 4

- oor? Yr vot FSP OsF ef Sor dor bye “SrF

sJdath Aa puaa :

L: Zwasvyl coh 41. Fy atsvaL gil

—

CTT Tyee] on | ow |D on] 41 ,.,| a0] on | on

‘2S bur ; ‘ H t NuezL| £49 |129"/) 1, 4H y LVS) puzeta| 4 99\ 499

ler

Lh, WUWIAUSINUAA «gn yw @Z

! i Cl vival ours qua\%\z on| wsvalov7s| wa\%| ron

VE 'FLM — ¢_ | wanso| wt] £500) fh | 2294) x2ns0} 4a [42 0u) 4) 4920) ,

= 1) 65 4° oy Zz

hienuened Ls on | esann iNno22u Lismpah = | 77) es

wall 29 =

slels|t|olololololol. Elalt :

ON 12 7

sau110d _— — FF ems NIFLKIS

: ) JO w#7dto

4 $ IHL OL Ald

eS , SOHN WUS

ZLE-2L OS ON

E> = s NIKI ON wn

SISNIAXT THIOINI | SISi oo7LU)

oo Nl a\ ainta-oL 2Uah| ATHINOW | ATHLNOW | ZUM Ae 402

/ 3 aA,ON

ININILULS AABHNAS —

ON -1290

sszadau SHUN |

: SS

74 75

ROC

TRAFIE

MAFI

382

78 Li

are

eg? Ly ad

yes 486

per tne) Tor’

INVLD PROC ‘

TRAFR =

488

490

TRAF I

(re! es)

438) a)

éD.

INVENTOR

THOMAS R. JOHNSTON

[ito aole

TOTALS

THOMAS R. VOHNS TON

Nt sToarks

—

55 Siaa/ SET ADDR 449 r Ie.

STRT-OF ACCT L608

FOR GET

‘SAVE ADDR

5 sol sive nODR

+ lo

‘

TRANSACTION JOURNAL

TERIOR W|ACCOUNTNO| NEME

Ss TeT] L21.212_ 3) ADDRESS

taro" YR|"

CAP TeHECK | WECOUNTS '

wo | wo | 287* Menzies |pévost COMMENTS

104 \03\25 66 2 87 | | NON CODE

it 2'87 ' xx

128 03 3/166 } $1 \46| INVALID CODE

to a S/ \46| exe

134 |0101 103'3/'\66 6:77

13} |0/03 \04:04'b6 2:00 :

it 8'77 | | xex

a —— : uw Oe

i i ts. 11:64) °° $1:46, ACCNT TOT. |

4A °

” fps.

| “ecer-No "| = SUMMARY STATEMENT

I :

J. norval 222 ~ gi

24, . ¢12e (428 £30) 4875 4845

CAT RECOUNTS || PERCENTAGES |

No. | CATEGORY NAME txTsaRrF 7a \vERe TO DATE | CURRENT WO. \YFAP 70 DATE

100 | INCOME ee =a) , '

04 | D/V/DENDS = 8 901 || \ \

107 | WAGES 511 48! | 1464193, || ; ’

me pi il ! i

TOTAL INCOME 377 \46\ 7473 \83, |, H

i so 1 :

120 | EXPENSES? % od SA :

Se a8) : '

12/ | AUTO 40/3; 160 .95' || H 1

125 | CLOTHING 5 1001 67 14), || }

SS t ——

= ce ) Hl

TOTAL EXPENSES | 293112; | 1240 6); mn H

€ INVENTOR

Lo Fioti, THOMAS R. JOHNSTON

[ldechiceachs

BEST COPY AVAILABLE

aoa

—4

hand

# NATIONAL BANK '

i uy £VADA, 1OWA

‘e 0372-648

[mel

Bta 0134~646 450

¥: ONS TIN

st a bat Ss a

ANY BANK

ANYWHERE, USA

47/§ OG72 7

62 o4/7 67

ANY BUS/NESS 652

CSNY WHER PE USA

SDD OOSOOOO . “699

Gs cAT NO

n *p nen Pr on 9- 9A 9R FP In

| 8}; 8}; 8] 8]| 8) 81) 8 Bs :

71] 7H) Fit 7iL 7h) 7} 7 a 711 7 :

-&{| al} 6}) 6) 6) gh euicic se

_ st] sil sil si} s OL sil sills 7

4|| 4|| 4/| 4 uy aii ail all all.

3|| 3|| 3 abl 3\, 3|| 3|| s|| 3 |

al| 2i| AXaty all ai] i] 2 2

t aI a} dial} atl allall all tease

j golf oU od off oU oU oU ob tat

b40——~" : ry 7

THOMAS R I OHNS TON

eae

® " ~

~_ 2 ST OS Ds w

g ee oe nts fee ai | ,

~ atu iy = = Ny ne 8 Oy 2

of on Fete a Sete oe of =e b -

stots Bor Vo! ry ' iy

EXAMINER’S ANSWER, NOVEMBER 3, 1970.

This is in answer to an appeai from the Final Re-

jection of Claims 1 through 11 and 16 through 27.

Claims 12 through 15 were withdrawn from considera-

tion when applicant acceded, without traverse, to an

election requirement. No claim is allowed.

A correct listing of the claims under appeal appears

in Pages 3 through 17 of applicant’s Appeal Brief.

THE REFERENCES RELIED UPON FOR THE FI-

NAL REJECTION ARE:

3,274,554 Hopper et al September 20, 1966

3,308,439 Tink et al May 7, 1967

3,343,133 Dirks September 19, 1967

3,374,462 Best et al May 19, 1968

3,407,387 Looschen et al October 22, 1968

APPELLANT'S INVENTION:

Appeiiant’s invention is a financial record keeping

process for monitoring the various dealings of persons

using the services of a bank. It is a process that is

designed to elicit information from transaction documents,

to update the bank’s records for such persons, and to

then produce monthly bank statements for mailing to such

persons.

The process is set forth in the form ef a computer

program which is to function with an automatic system.

Appellant’s disclosed best mode is a computer program

listing which is to be used with an IBM 1400 series

computer. It is noted that appellant’s “preferred em-

bodiment” as set forth in lines 11-16 on Page 19 of his

Appeal Brief is contradictory in some very important

aspects (i.e, elements 10 and 14 on Fig. 1A) to his

“preferred embodiment” as set forth in lines 14-22 on

page 7 and lines 1-3 on page 92 of his specification.

;

The various subroutines or phases of appellant’s process

are set out in Pages 20-40 of his Appea! Brief. It is

noted that appellant uses the term “mechanisms” to

describe his various program subroutines or phases and

concedes that his invention (i.e. process) “is adaptable

for use with various types of computers” (see Page 40

of his Appeal Brief).

EXPLANATION OF THE REFERENCES:

The patent to Hopper et al shows a document reader

and operating console for input data, magnetic tape

transports for master and updated files, memory and

processing modules with controls therefore, and a docu-

ment printer and a magnetic drum as output devices.

The various mechanisms of Hopper et al are computer

programmed controlled.

The patent to Tink et al shows a banking system

having multiple teller stations interconnected with a

data processor and a random access unit operating under

program control. A bank customer can get full informa-

tion of his account, updated, at the time he engages in -

a transaction with a bank teller. Non-personal contact

transactions also can be entered in the data processor

for recordation and updating of files, however, when

it is most convenient to the bank.

The patent to Dirks shows a program controlled data

handling system having an input means and input file,

a central processing file system, output file and a printer

output unit (ie. Fig. 49 and Columns 3-5) which is

used for file maintenance, up-dating for current balances

and generating printed output documents.

The patent to Best et al shows an operator as well

as program controlled computer, a memory with controls

therefore for computational purposes and a printer out-

put unit.

The patent to Looschen et al shows a program con-

trolled banking system similar to Tink et al, and which

has all of the features and abilities of Tink et al. In

addition, Looschen et al includes a polling system pri-

marily to establish interconnection between a central

control and a particular window machine.

It is noted that appellant admits that all of the

cited references are adaptable, when properly program-

med, to carry out the methods of his invention (see Page

41 of his Appeal Brief) as is set forth in his computer

program.

THE FINAL STATUS OF THE CLAIMS:

Claims 1-8, 10, 11 and 16-24 are rejected under 35

U.S.C. 112 for failing to particularly point out and

distinctly claim the subject matter which the appellant

considers as his invention, as was stated in Paragraph

13 of the January 6, 1970 Final Action which is in-

corporated herein. Appellant’s claims are considered as

misleading and hiding his true contribution in that he

is claiming a program as structure using the means-

plus-function format.

Claims 1-8, 10, 11 and 16-24 are rejected under 35

U.S.C. 112 as claiming a program in means-plus-func-

tion language (in apparatus form) as indicated in Para-

graph 15 of the January 6, 1970 office action which is

incorporated herein. The claims are considered to be

directed to a use for a known machine.

Claims 1-11, and 16-24 are rejected under 35 U.S.C.

102 as being anticipated by Hopper et al, Tink et al,

Dirks or Best et al as indicated in Paragraph 16 of

the January 6, 1970 Final Action which is incorporated

herein. Appellant’s “banking system limitation” is not

considered controlling.

Claims 25-27 are also rejected under 35 U.S.C. 102

as being anticipated by Tink et al or Looschen et al, as

indicated in Paragraph 18 of the Final Action and which

is incorporated herein.

RESPONSE TO APPELLANT'S ARGUMENTS:

Since the appellant has chosen to argue the patent-

ability of his claims in several categories, this RE-

SPONSE will follow such format in order to provide con-

tinuity between Argument and Response.

1. The Rejections on Prior Art

The first claims considered by appellant are Claims

25-27, which are method claims which were submitted

by the appellant by supplemental amendment. Such claims

stand rejected under 35 U.S.C. 102 as being anticipated

by Tink et al or Looschen et al.

The two cited references are considered to comprise

all of the computer elements specified in appellant’s

claims, i.e., a computer master and sub files, account

numbers, records for category codes and monthly state

ment generators. ;

Appellant places great weight for the patentability of

his method claims on his terms “demand deposit banking

accounts” and “category code numbers”. The theory be-

hind “demand deposit banking” accounting and “savings

accounts” accounting is essentially the same. Transac-

tions against specific bank accounts are normally or-

ganized by “category codes” (i.e. deposit, withdrawals,

charges against or interest earned). Whereas, the ap-

pellant uses code numbers for his individual transactions

and Tink et al or Looschen et al do not, both procedures

end with the same result (i.e. updated bank records

and the monthly generation of bank statements).

In essence, the appellant is seeking patent coverage

for a process which (1) he has assigned a particular

name to and (2) uses numbers. No new steps over the

prior art methods are considered to be found in such

“numbered particularly narmed” process. Certainly, what

one can do with bank savings accounts he can obviously

do with bank demand deposits.

Claims 1-11 and 16-24, as apparatus claims, are treated

next. Such claims stand rejected under 35 U.S.C. 102

as being anticipated by Hopper et al, Tink et al, Dirks

or Best et al.

Appellant admits (1) that his so-called apparatus

system is defining process steps in the means-pl

This text is long and has been trimmed here. Open the source document for the complete record.

This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.