Financial Data Processing System With Distributed Data Input Devices and Method of Use

This invention relates to a financial data processing system and a method of operating the system for keeping accounts of loans, loan histories, leases and other financial transactions, and pertinent information relevant to each loan, lease and transaction.

More particularly, this invention relates to a financial data processing system having a "level" of distributed processors, such as micro-computers which also are known as personal computers ("PC's"), coupled to a higher "level" of mini-computers, such that the micro-computers are directly connected to and interface with the mini-computers, and although not directly connected to a host computer, are capable of communicating with it via the mini-computers.

This invention further relates to a financial data processing system having a lower level of distributed processors at the micro-computer level, which are capable of receiving user input data in real-time and providing a temporary storage of such data in a memory storage device of the micro-computer or in a more permanent storage medium such as a disk file readable by the micro-computer, for either processing by the micro-computer or for later transmission to and processing by the next-higher level of distributed processors, e.g. the mini-computers, in batch-mode.

This invention also relates to a financial data processing system having the capability of inputting data in real-time using means other than a conventional computer keyboard to enter the data, particularly such as by means of using an optical character reader directly connected to computer memory storage means.

Prior to the invention described below, financial data processing, utilizing a system such as is described in our co-pending U.S. Pat. Application, Ser. No. 750,912, was performed using an essentially bi-level system comprising a plurality of distributed processors at the mini-computer level, each having a plurality of interactive video display terminals ("VDT's") and other peripheral equipment, such as printers, associated therewith, with each distributed mini-computer processor further being connected to and interfacing with a mainframe host computer.

Although this bi-level system operates satisfactorily, it is believed that the efficiency of the overall system can be improved. The operation of this system is dependent, to a large part, on the rate at which data can be input into the system by the individual operators using the VDT's connected to the distributed mini-computer processors, in real-time, and in a time-sharing mode. The capability of each individual distributed mini-computer processor to accept data being input thereto greatly exceeds the rate at which individual operators can manually input such data via the computer keyboard. The full data processing capability of the mini-computers, moreover, is not utilized even where a plurality of VDT's are connected thereto in time-sharing mode. The system is limited, in some instances, particularly at large branch office sites, by the relatively small number of VDT's which can actually be connected to a single distributed mini-computer because of hardware limitations, such as the number of VDT ports that a single mini-computer can accommodate. In other instances, the full data processing capability of the mini-computer is not utilized because of the relatively small number of VDT's, less than the maximum number which can be connected to a single mini-computer in time-sharing mode, which actually interface with a single mini-computer serving one or more branch offices. Finally, even when a plurality of VDT's connected to a mini-computer are simultaneously being utilized for the manual input of data into the memory storage devices associated with the mini-computer, in real-time, or time-sharing modes, since the process is relatively slow it prevents the mini-computer from performing other important processing tasks internally.

For these reasons, a further improvement to the financial data processing system as set forth in co-pending U.S. Pat. Application Ser. No. 750,912, has been developed specifically to overcome the above limitations and to avoid unduly restricting the processing capability of the mini-computers in the system by releasing them from the function of processing input data being entered into the system by relatively slow-speed manual entry via keyboard from VDT's connected to the mini-computer in time-sharing mode, thereby increasing the overall data processing efficiency of this system.

Therefore, it is object of the present invention to provide a further, lower level of data entry and distributed processing capability for the overall financial data processing system of our invention, by means of a network (or subsystem) of micro-computers, also generally known as personal computers, below the level of the mini-computers. This sub-system is provided in order to facilitate the entry of data into the financial data processing system by first inputting data into the micro-computers either by direct manual entry of the data from the micro-computer keyboard (i.e. from the level of micro-computers coupled to a mini-computer), or alternatively, by means of an optical character reader to enter and store the data. The input data is copied onto a permanent storage means (such as a floppy or hard disk) of the micro-computer from the volatile working storage memory, for more permanent storage. After a batch of data has been so accumulated, the data is transmitted to the next-higher level of distributed processors, i.e. the mini-computer connected thereto, by means of a communication interface and link, such as a modem and standard telephonic communication line, or by means of an optical fiber link, connecting the micro-computer to a mini-computer. The transmitted data is then entered into a direct access memory storage device connected to the mini-computer, for master file updating and for further processing of the data.

A further object of this invention is to provide a financial data processing system having a lower level of distributed processors, i.e. micro-computers, connected to a next-higher level of distributed processors, i.e. mini-computers, the latter being connected to a mainframe central host computer, such that the individual micro-computers are capable of inputting file data into the system relating to all financial functions performed by the system, in real-time. The inputted data subsequently is transmitted to the mini-computers for file updating and data processing in high-speed batch mode. Thus, the central processing units of the mini-computers are thereby utilized more efficiently.

Various other objects, advantages and features of the present invention will become readily apparent from the detailed description that follows, and the novel features of the invention are particularly pointed out in the appended claims.

Heretofore, a financial data processing system utilizing several levels of interactively linked distributed processors has not been possible because of the unavailability of system operating and control software to accomplish such an objective. The financial data processing system of the present invention, which integrates a micro-computer sub-system with a higher level of distributed processor, therefore, represents a significant advancement of the state of the art. The system of this invention is made possible by adapting Application Program Interface ("API") software developed by IBM to the particular requirements of the financial data processing field.

API software provides the means for operating an integrated hardware system, such as that of the present invention based on PC's and mini-computers. The API software enables hardware sub-systems to be linked in a way that permits the exchange of data between the PC and the mini-computer and allows the PC to perform certain designated processing functions, such as high volume, routine data processing operations, thereby freeing the central processing unit of the mini-computer to perform other tasks. Through the adaption and use of API software, the overall capabilities, flexibility, operating speed and efficiency of the integrated financial data processing system are greatly enhanced.

In the present invention, the API software has been modified to create an integrated system of hardware which links one or more PC's to at least one mini-computer. The system is structured in such a way as to provide an essentially unidirectional flow of operational control which is established from the PC and can be extended to the mini-computer for select designated operations. A tie-in from a PC to the mini-computer is initiated from the PC. The link enables the PC to interrogate the mini-computer and obtain data from data files corresponding to the designated functions which the PC's are authorized to access. For certain operations, the PC's may have "read only" access to data contained in files at the mini-computer level. For other operations, particularly those involving the processing of data which is used to update information in the permanent data files at the mini-computer level, the PC's have the further capability of transmitting the processed data to the mini-computer and writing the data to memory at that level. A step-by-step detailed description of how the system operates is presented below.

The PC/mini-computer interface is also structured such that, on the other hand, the mini-computer cannot independently access a PC and transfer data to it at the mini-computer's instance. Data transfer from the mini-computer to a PC must be initiated as a request from the PC.

In accordance with a broad, general feature of this invention, a financial data processing system and a method of operating that system are provided. Included in this system are a central processor with a data bank into which financially-related data is written and from which data is read. Also provided is a higher level of distributed processors with associated direct access storage devices and other peripherals, including video display terminals (VDT's) and printers, into which data is also written and from which data is also read. This higher level of distributed processors (mini-computers) performs data processing for substantially all financial functions programmed into the system. The aforesaid elements of the system hardware and the financial functions performed by the system are more fully described in co-pending U.S. Pat. Application Ser. No. 750,912. Also integrated as part of the overall system, as particularly disclosed in the present specification, is a second, lower level of distributed processors, for example, micro-computers which are used essentially to input data into the system in real-time and to retrieve data processed or otherwise provided at the mini-computer level for real-time display and/or printout.

The financial data maintained and processed by the functions performed by the system, and which the micro-computers are capable of inputting, accessing and transmitting interactively with the system include, but are not limited to, financial loan information representing the balance of outstanding loans, the interest rate payable on a loan, the principal and interest due and payable for each periodic loan payment, information on the identity of each debtor, a record of any delinquency in payment of a loan, the cumulative collection histories of each loan and financial information relating to leases and leased property.

The input means of each micro-computer, including, e.g. a keyboard or an optical character reader, are operable to write into the memory storage area of the micro-computer, and optionally, to store on a disk file of the micro-computer, data pertaining to financial loan information. In particular, this includes multiple loan payment data representing principal and interest payments and the identities of respective debtors, for a batch of loan payments, multiple lease payment data, and loan application data representing the identity of each applicant, the amount, type and duration of the requested loan, the interest rate payable on the requested loan and credit data representing the applicant's ability to repay the requested loan.

The display means of each micro-computer, such as a video display screen or the like, is operable to display data stored in and read from memory storage of the microcomputer or from a disk file. Data can be input to memory storage from a keyboard for newly entered data or it can be input by reading-in previously entered data which has been retained on a disk, from a permanent disk file. Disk files, containing previously entered data, are a convenient means of playback for the purpose of verification and/or reentry. The display means of the micro-computers are also operable to access and retrieve processed data directly from the mini-computers or from the central host computer, via the mini-computers.

In a preferred embodiment, each micro-computer, such as an IBM 3270-PC, is provided with a keyboard, a multi-colored video display screen, a memory storage area for the micro processor, means such as a floppy disk drive or a hard disk drive, for permanently recording data that has been entered into the memory storage and, alternatively for transferring data therefrom into the memory storage. Optionally, an optical character reader is used as an alternative to the manual entry of data from the keyboard.

Each micro-computer is connected to a direct access peripheral storage device associated with the next-higher level of distributed processor, i.e. a mini-computer such as an IBM 8100 processor/8101 storage device combination. The mini-computer systems, with which the micro-computers are interconnected may include one or more additional memory storage devices, such as an IBM 8102 and one or more tape drive units, such as an IBM 8809. A full description of the operation of the mini-computer system and the financial data processing functions which are performed at this level of the overall system is described in the co-pending application referred to above and is not herein described in detail. A detailed description of the operation of the micro-computer level of distributed processors in conjunction with the operation of the overall system is discussed below, with particular emphasis on a detailed description of the operation of these terminals in performance of the multiple payment processing function .

The following detailed description is best understood in conjunction with the accompanying drawings in which:

FIGS. 1-3; 4A-B; 5; 5a; 6A-C; 7-9; 10A-B; 11A-C; 12-20 as described in our co-pending U.S. Pat. Application referred to hereinabove.

FIG. 21 is a schematic representation of the components of the micro-computer sub-system and their relationship to one another and to the mini-computer level of distributed processors.

FIGS. 22A-22E are a flow chart representation of the program which the micro-computer sub-system utilizes to perform the operation of data input for the multiple payment processing function.

FIG. 23A is a display of the personal computer (PC) main menu for the customer payments multiple mail option.

FIG. 23B is an illustration of the PC display screen for the main menu help map.

FIG. 24A is a representation of the PC display screen for the input of payment data.

FIG. 24B is a representation of the PC display screen for the multiple input help map.

FIG. 25 is a representation of the PC display screen for the payment input results.

FIG. 26 is a representation of the PC display screen for the payment restart status map.

FIG. 27 is a representation of the PC display screen for the payment and help screen restart.

FIG. 28 is a representation of the display screen for the instructions for the input data verification procedure.

The following detailed description is intended to provide an understanding of the method of operation of the micro-computer sub-system of the present invention, which is a part of the overall financial data processing system described in detail in co-pending U.S. Pat. Application, Ser. No. 750,912. Particular emphasis is given in the following to application of the micro-computer sub-system of the present invention to the multiple payment processing financial transaction option. It is to be understood, however, that the micro-computer sub-system of the present invention can generally be utilized to perform any of the financial data processing transaction options which can be selected by the user from the main menu of all financial transactions that may be carried out by the overall system as described in the aforementioned patent application. The specific sequence of steps followed in the performance of other options varies accordingly. The determination of the specific steps for other financial transaction options will be obvious to one skilled in the art of computer programming based on the disclosure herein and on the disclosure in our above mentioned co-pending application.

FIG. 21 is an overall view of a micro-processor terminal as utilized according to the invention, including a keyboard, central processing unit (CPU) and a video display terminal (VDT), together with an optical character reader (OCR) for alternative means of data entry into the CPU instead of the keyboard. Also shown is a data communications link between the micro-computer sub-system and the next highest "level" of distributed processor in the overall financial data processing system, namely the mini-computer level, utilizing, for example, an IBM 8100 mini-computer and its peripherals such as an IBM 8101 direct access storage device, one or more IBM 8102 disk drives and an IBM 8809 tape drive for tape back-up of data stored on hard disk. The two-way data transmission link between the micro-computer and mini-computer sub-systems is established with an appropriate interface at each terminal, such as a modem in the case of interconnection over conventional telephonic lines. Alternatively, a fiber optic link can be established between the two systems. Several micro-computers may be coupled to a common mini-computer subsystem.

Referring to FIG. 22A, the operator first turns on the VDT and PC of the micro-computer subsystem as at 1002 of the illustrated multiple payment processing flow chart. Assuming the PC is provided with a hard disk drive, the VDT screen shows a c> prompt as the last symbols echoed to the VDT, as is conventional. If the c> prompt is not shown on the screen, the operator is put on notice that there is a PC problem as represented by the inquiry at 1004, that the system is not operating properly and that branch support, which is a central user help desk, should be contacted to determine the nature of the problem and to provide assistance. If the c> prompt is properly shown on the screen, the inquiry at 1004 is answered in the affirmative and the operator is apprised that he may proceed with the session. The operator next presses the designated key (JUMP) or combination of keys to tie-in the PC to the mini-computer, such as IBM 8100, with which it interfaces, as at 1006. This interconnection can be established by means of a modem utilizing standard telephonic communication lines or the interface can be established by means of other devices such as a dedicated fiber-optic link. If a successful interconnection is not confirmed, the inquiry at 1008 is answered in the negative and the operator may first take corrective measures on his own, and if still unsuccessful in establishing a link-up, he may call on branch support for assistance. When a link-up is successfully established, the inquiry at 1008 is answered in the affirmative and the operator proceeds by logging-on to the system main menu, as at 1010. The Main Menu display screen is illustrated in FIG. 7. As an illustrative example, any one of eighteen separate financial transactions may be selected by the terminal operator. After selecting one of the transaction options, the operator enters a user identification number and password needed top verify that the operator has the authority to access the selected option, as at 1012. The program then checks at 1014 if the user has multiple office selection capability. If the inquiry is answered in the negative, the program bypasses the next step and advances to 1018 which requires the selection of a payment sub-menu. If the response to the inquiry at 1014 is in the affirmative, the program proceeds to 1016, requiring the selection of an input option number for the number of the user's branch office, as selected from a displayed screen of numbers for all branch offices. After a number has been entered by the user designating the user's branch office, the program then proceeds to 1018. If the response to the inquiry at 1018 is in the negative, this indicates that the payment option, option 4, was not selected by the operator and the program loops back to 1012. However, if the inquiry at 1018 is answered in the affirmative, the program advances to display the customer payments sub-menu on the VDT screen.

When an affirmative response has been made to the inquiry at 1018, the program advances to segment "B" on FIG. 22B. At this point, the VDT screen displays a menu similar to that shown in FIG. 8. Assuming as in the present embodiment, the financial transaction option to be selected is the multiple mail option of the customer payments transaction option, wherein batches of customer return mail payments are processed, the operator may select either option 1 relating to loan payments or option 15, relating to lease payments from the displayed menu. The program then ascertains at 1022 whether a Multiple Input Map is displayed. If the response to the inquiry at 1022 is in the negative, the program loops back to 1020. If the response to this inquiry is in the affirmative, the program advances to 1024 which requires the operator to press a key (JUMP) or combination of keys to the PC.

If option 1 for multiple mail customer payments has been selected, the operator then types the entry "PAYMENTS" at 1026. If option 15 has been selected, the operator types the term "PAYLEASE" at 1028.

The program then ascertains whether a RESTART is required, as at 1030. A RESTART enables the operator to resume a data entry session which may have inadvertently been terminated because of such factors as a break in the communication link to the mini-computer or due to some other hardware failure in the micro-computer or mini-computer system, resulting in the loss of part or all of the batch of data being input during that session. If the VDT screen displays a non-zero number count for the number of entries in the data files, thereby indicating that the data files contain previously input data which may have been either successfully or unsuccessfully processed, the user can institute a data verification procedure ("RESTART") which causes the previously input data to be redisplayed for review and entry of any corrections prior to attempting to reprocess the data. Where a previous session has been interrupted or has been terminated by other than the standard log-off procedures, to be described, the data files have a non-zero number count for the number of entries in the data files, therefore a RESTART procedure can be initiated to enable review of the existing data, and correction if required. If the RESTART procedure is elected, the user next determines whether a RESTART procedure which shows the status of each previously entered account is required. The inquiry at 1031 asks whether a RESTART is required. If the inquiry at 1031 is answered in the affirmative indicating that a RESTART has been requested, the program displays a Restart Status Map, which is a summary of the number of accounts previously entered and their processing status, as shown in FIG. 26. The user can then make appropriate corrections to the previously entered data. The program then continues to test whether the number of accounts to be verified has been reduced to zero by appropriate correction of the data in the accounts, as by the inquiry at 1034. If the number of accounts to be verified has been reduced to zero, the program jumps to segment "D", which causes the Multiple Input Map to be displayed, and sends the program into a new data input mode, wherein new payment data is entered for accounts. If the response to inquiry 1034 is in the negative, indicating that the number of accounts to be verified has not been reduced to zero, the program continues to 1036 which enables the user to take further steps to verify the data.

The inquiry at 1030 tests the contents of the data file registers which maintain a running count of the number of accounts entered for processing to ascertain whether the count is zero or non-zero, that is, whether the data files still contain previously entered account data, either unprocessed or processed. THE VDT displays a restart map if the count is non-zero. If the inquiry at 1030 is answered in the affirmative, the VDT screen is caused to display a message such as shown in FIG. 27 prior to displaying the restart map of FIG. 26. The message displayed in FIG. 27 alerts the user that the account data entered during a previous session may not have been completely successfully processed for one of several reasons, and that election of Restart processing to review the status of such previously entered accounts and make corrections to such data, if required, or to add additional account data, if desired, is recommended.

Where a data verification procedure is not needed, the inquiry at 1034 is answered in the affirmative and the program advances to segment "D", as shown in FIG. 22D, where additional new data can be entered. Where data verification is needed or requested, the program advances to 1036, where the operator can review the previously entered data to determine the status of the accounts represented by the data and whether information related thereto was previously successfully or unsuccessfully processed. In the data verification mode (commencing at 1036), the VDT screen displays a message such as shown in FIG. 28, followed by a listing of the accounts which may not have been successfully processed by the mini-computer. After completion of this data verification step, the program advances to segment "D", as is shown in FIG. 22D.

Where the response to the inquiry at 1030 is in the negative, i.e., no RESTART procedure is required, the program advances via inquiry 1032 to segment "C", as shown in FIG. 22C, whereupon the PC Main Menu of the multiple mail option is displayed.

The VDT screen display for the PC Main Menu of the multiple mail option is shown in FIGS. 23A and B. As shown in FIG. 22C, the program checks to insure that the PC Main Menu is displayed at this time, as at 1038. If the response to the inquiry at 1038 is in the negative, the operator is advised to call upon branch support for assistance to correct the problem of failure to display the multiple mail Main Menu. However, if the response to the inquiry at 1038 is in the affirmative, the routine affords the operator a choice of four programmed function (PF) keys from which to choose in order to continue and this choice is displayed on the VDT screen (FIG. 23A). If the operator selects the PF1 key, as at 1040, additional on-screen operator help is provided. If the PF1 key is not depressed, the program ascertains whether the PF2 key has been selected, as at 1041. If the response to this inquiry is in the affirmative, the program loops to 1052 in segment "D", as shown in FIG. 22D. This segment of the program commences processing of the data entered by the operator via a keyboard or optical character reader and writes input data to a storage means, such as a disk, to be sent to the mini-computer for processing when the mini-computer is available for processing payments. If the response to the inquiry at 1041 is in the negative, the program ascertains whether the PF3 key option has been selected as at inquiry 1042. If the response to this inquiry is in the affirmative, the program loops to 1052 in segment "D", as shown in FIG. 22D, where processing of the entered data is commenced. If the response to the inquiry at 1042 is in the negative, the program then ascertains whether the PF4 key option has been selected as at 1044. If the response to inquiry 1044 is in the negative, the system displays an error message at 1046 and loops back to 1032 to display the PC Main Menu. If the response to the inquiry at 1044 is in the affirmative, the program advances to 1048, which calls-up an EXIT routine to the PC. The program then continues to 1050, which requires the operator to follow a standard log-off procedure, including entry of a command such as "LOGOFF" or its equivalent.

If the response to any one of the inquiries at 1034, 1036 (FIG. 22B), 1041 or 1042 (FIG. 22C) is in the affirmative, the program advances to segment "D" in FIG. 22D, commencing at 1052.

At 1052, the program displays a Multiple Input Map requesting input payment data for the multiple mail customer payments, with provision for entry of up to twelve sets of payment information, such as is shown in FIG. 24A. After a full screen of data has been entered (i.e. data relating to up to twelve customer payment transactions), the operator has five options for exiting the payment data input mode, by selecting any one of five PF keys as shown at the bottom of the screen. The program then sequentially determines which, if any, PF key has been depressed and takes the appropriate action represented by the illustrated flow chart.

In an alternative embodiment of the invention, at 1052 in the program sequence, the operator alternatively has the option of inputting the payment data utilizing an optical character reader, instead of manually entering the data via the keyboard. Each loan payment made by a customer generally is accompanied by the return of a payment statement indicating all of the relevant information, including, for example, the customer's name, address, account number, amount of the payment, and the sequential payment number or time period for which the payment is to be applied. This information is pre-printed on the payment statement in a predetermined format according to designated data fields which the micro-computer is programmed to recognize and utilizing a character type face that is easily read by a standard optical character reader (OCR). The customer payment statements which are returned by the customers together with their payments are printed with a special ink which enables the OCR to read a line containing fields which provide information on the account number and the amount of the payment due. When utilizing this option the operator employs a character-scanning device which is passed over the payment statement and converts the information contained in the sensitized fields to digitized data. After scanning a batch of twelve such statements, the digitized information is stored in one of the permanent storage devices of the PC for future processing, or, the batch of data can be transmitted to the mini-computer for immediate processing, utilizing the PF3 key.

The use of OCR's, such as those manufactured by Caere Corporation, to enter payment data significantly reduces the amount of time required for this task. For example, in a large branch office the time required is typically reduced from nine- person-hours (three persons at three hours each) to two person-hours (one person at two hours).

In the program segment shown in FIG. 22D the PF1 key is used as a HELP key which enables the operator to obtain additional on-line information about the various other PF option keys available in this routine. If the response to the inquiry at 1056 whether the PF1 key has been selected is in the affirmative, the program jumps to 1058 where the VDT screen displays a multiple input payments help map, as is shown in FIG. 24B. After displaying this screen, the program then loops back to 1052 upon the operator pressing the ENTER key. If the response to the inquiry at 1056 is in the negative, the program advances to 1060, where inquiry is made as to whether the PF3 key has been depressed.

If the PF2 key was depressed at 1041, while displaying the PC Main Menu, and causing the program to advance to 1052 of segment "D", where data is written to permanent storage, the operator selects the PF3 key at 1060.

The PF3 key instructs the PC to either only log input payment data or to transmit the entered data to the mini-computer for processing, depending upon whether the PF2 or PF3 key had previously been depressed while in the PC Main Menu. If the response to the inquiry at 1060 is in the affirmative, and the PF2 key was depressed while in the PC Main Menu, the PC causes the data to be only written to disk at 1062. If the PF3 key was depressed while in the PC Main Menu, the PC causes the data to be written to disk and transmitted to the IBM 8100 processor at 1062.

If processing resources of the mini-computer are not available when the PC attempts to transmit the data, the program repeats such transmission attempts which, if successful, returns a response to the PC. The absence of a response signifies that a problem may exist at the PC or the mini-computer. In this case, the VDT displays a screen to inform the operator and suggest that branch support services be called for assistance.

After executing 1062, the program loops back to 1052, upon the operator pressing the ENTER key. If the response to the inquiry at 1060 is in the negative, the program advances to 1064 to inquire whether the PF4 key has been depressed. Depression of the PF4 key enables the program to jump to that portion of the program, segment "C", where the PC Main Menu is displayed. The PF4 key is depressed when the screen displays a message that there is previously entered account data which has not been processed still in the system. If the response to the inquiry at 1064 is in the affirmative the program seeks to confirm the response at 1066. This check enables the operator to confirm the last PF key pressed. This confirmation is for accounts that have been displayed for correction or verification only. If the confirmation is in the affirmative, the program loops back to display the Multiple Input Map which allows the input of new data. If the confirmation is in the negative, the program returns control to the PC Main Menu at 1032 in program segment "C".

If the response to inquiry 1064 is in the negative, the program advances to inquiry 1068, where the program ascertains whether the PF5 key has been depressed. The PF5 key is used to terminate the input of payment data. If the response to inquiry 1068 is in the affirmative, the program advances to 1070 in program segment "F", which processes the input payment information at the PC level.

If the response to the inquiry at 1068 is in the negative, the program advances to 1072, to inquire whether the PF6 key has been depressed. The PF6 key enables the operator to view and correct any previously entered payment data which the computer indicates by error messages may not have been correctly entered or were rejected due to subsequent transmission difficulties. If the response to the inquiry at 1072 is in the negative, the program jumps to 1074 where the VDT screen displays the error message relating to the previously input data. The program then loops back to 1052 at the beginning of program segment "D".

If the response to inquiry 1072 is in the affirmative, the program seeks to confirm the response at inquiry 1076. This check enables the operator to confirm the last PF key pressed. This confirmation is for accounts that have been displayed for correction or verification only. If the response to the inquiry at 1076 is in the affirmative, the program loops back to 1052 at the beginning of segment "D". If the response to the inquiry at 1076 is in the negative, the program advances to 1077, at which an inquiry is made to determine if there are payments to correct.

If the response to the inquiry at 1077 is in the affirmative, the program advances to 1078 in program segment "G", which displays the payments to be corrected on the Multiple Payment Map. The program then advances to 1080 which enables such corrections to be made by re-entry or erasure of the data, after which the program loops-back to program segment "E" at 1056.

If the response to the inquiry at 1077 is in the negative, there are no payments to be corrected, and the program advances to 1082 at which the VDT screen displays a message that there are no payments to be corrected and then loops-back to the beginning of program segment "D".

Where the response to the inquiry at 1068 is in the affirmative, that is, where there are no more payments to be entered, the program jumps to 1070 in program segment "F", as shown in FIG. 22E. A summary of the results of the data which have been processed is produced at 1070, and this is displayed on the VDT screen at 1090, indicating the total number of payments which were entered, the number of payments which were processed, the number which were rejected and the number which need to be corrected or acknowledged, as is shown in FIG. 25.

The operator then has three PF key options from which to select. The program then sequentially ascertains which of these PF keys has been depressed and takes the appropriate action in response thereto.

The program first inquires whether the PF3 key has been depressed, as at 1082. Pressing the PF3 key instructs the computer that the operator wishes to enter more payment data. If the response to the inquiry at 1082 is in the affirmative, the program loops to 1052 in program segment "D" where the Multiple Input Map is displayed.

If the response to the inquiry at 1082 is in the negative, the program next inquires at 1084 as to whether the PF4 key has been depressed. Pressing the PF4 key instructs the computer to display the main PC menu, as at 1032, by jumping to program segment "C". If the response to the inquiry at 1084 is in the negative, the program advances to 1086, at which inquiry is made whether the PF6 key has been depressed. Pressing the PF6 key permits the operator to view and correct payment data which has previously been entered. If the response to the inquiry at 1086 is in the negative, the program displays an error message at 1088, indicating that a key other than one of the three designated PF keys has been depressed and requests that a valid response be entered, and then automatically loops-back to display on the VDT the payment input results screen, as at 1090. If the response to the inquiry at 1086 is in the affirmative, the program advances to 1091 where it inquires whether there are payment inputs to be corrected. If the response to the inquiry at 1091 is in the negative, the program displays a message at 1092 that there are no payments in error to view or correct and automatically loops-back to display the payment input results screen at 1090, shown in FIG. 25. If the response to the inquiry at 1091 is in the affirmative, the program jumps to 1078 in program segment "G" to display a Multiple Input Map on the VDT screen.

The foregoing has described the sequence of program steps followed to execute the multiple payment input data option for the customer payment financial transaction option utilizing the micro-computer sub-system of the overall financial data processing system. It is, however, not intended that this is to be interpreted as a limitation on the scope of utility and applicability of the micro-computer sub-system. As has been stated above, the micro-computer sub-system can be utilized to enter data pertaining to any of the other financial transaction options of the overall system. Specific micro-computer program routines for the other options will be apparent to those skilled in the art based on the foregoing and in further view of the co-pending parent case.

Other hardware implementations than those discussed above are also encompassed in the scope of the foregoing.