EP0739518A4

EP0739518A4 - Home banking system

Info

Publication number: EP0739518A4
Application number: EP95906762A
Authority: EP
Inventors: Michael D Boyle; Irene N Hansen; Daniel C Larlee
Original assignee: CFI Proservices Inc
Current assignee: CFI Proservices Inc
Priority date: 1994-01-06
Filing date: 1995-01-06
Publication date: 2001-04-25
Also published as: AU1522795A; NZ278782A; EP0739518A1; AU689202B2; MX9602636A; CA2180635A1; WO1995019010A1; JPH09507595A

Abstract

A data processing system for conducting banking transactions over telephone lines includes a plurality of user-operable communication devices (10) connectable to a branch bank computer (20) over telephone lines. The user-operable communications devices (10) have at least a display screen and a means such as a keyboard for inputting messages corresponding to user requests (16). The branch bank computer (20) includes software for interpreting messages from users and making protocol requests (24) to a host interface module (26). The host interface module (26) in turn makes command string requests (28) to a host (30), which responds with a screen of text (32). The host interface module (26), using a script file, parses the screen of text (32) extracting data which is sent to the branch bank computer (20) as a protocol response (34). Then the branch bank computer displays that information to the user in the form of a text screen display (36).

Description

HOME BANKING SYSTEM

Background of the Invention

In the banking industry, especially at the consumer level, banks strive to make it convenient for customers to make deposits, cash checks, pay bills and a host of other banking transactions. Most consumer- oriented banks have established branches in urban, suburban and rural areas to make such banking trans- actions more convenient; however, banking must still be done in person. In order to obtain balance or trans¬ action information, make deposits, make withdrawals or to shift funds from one account to another, the customer must still make a personal visit to the bank. Some banks have voice operated systems for accomplishing some of these tasks which, however, nevertheless require a human operator at the bank to receive instructions and provide the necessary information or make the desired transaction. The advent of microprocessor-based communications systems such as personal computers connected to telephone lines by modem has enabled users to perform a variety of tasks that previously had to be done in person or through intermediaries. Using this . technology computer banking systems have been attempted on an experimental basis using a customized software package written for the host computer of a particular financial institution which has enabled a limited number of users to access information^* at the bank and effect transfers.

The problem with custom designed systems of this type is that they are built to work with a specific bank's host computer. Furthermore, such a system may not have the multi-tasking ability of systems operating in UNIX or OS/2 operating environments. The multi-tasking capability that is present in such operating environments is essential in order to accommodate the potentially large number of users who would desire to have access to the banking system via modems and the like.

The problem inherent in this environment, however, is that there may be many different types of host computers. This being the case, it would be neces¬ sary to write special applications software for each and every type of host computer in order to tie that computer to the software which would drive any local computer that users were connected to via telephone lines. That is, the users must connect to the bank' host computer through a local computer accessed through the particular branch bank computer. This local computer should incJLude soft¬ ware which is usable by the remote users through a communications device which should consist of no.,more than a personal computer and a modem. In other words, it would be very desirable for the user not to have to acquire special purpose software in order to communicate with the branch bank computer. Instead, this software should be located at the branch bank's computer so that all the user has to do in order to use the system is to connect to the branch bank's computer on his modem. The problem remains, however, that if the software were stan¬ dardized for the individual branch banks (so that users may communicate easily) , there would still exist the problem of how to interface this software with host computers of different configurations without rewriting the branch bank's software for a plurality of different host computers.

Other systems have been proposed for home banking that utilize a multi-bank ATM network. An example is shown in Lawlor et al. , U.S. Patent No. 5,220,501 issued June 15, 1993 and entitled "Method and System for Remote Delivery of Retail Banking Services." The system of Lawlor et al. provides the user with a special terminal that emulates an ATM and that requires ATM-compatible PIN codes. These terminals communicate over telephone lines through an ATM network to connect with the user's bank. The use of such a system, however, requires acceptance by consumers of a special purpose terminal. Also, constraints are imposed by the require¬ ment that the terminal emulate the now-familiar ATM. Finally, prospective member banks may not embrace a system that requires use of the ATM network.

Summary of the Invention

The system of the invention is a data processing system for conducting banking transactions over telephone lines and includes a plurality of user- operable communication devices connectable to branch bank computer over telephone lines. The user-operable communications devices have each at least a display screen and a means such as a keyboard for inputting messages corresponding to user requests. The branch bank computer includes software for interpreting the messages from the users for requesting banking data and for effecting selected banking transactions. The system contemplates a host computer system serving the entire banking network including a plurality of branches, which includes aggregate banking transaction data such as the account files of the users. A host interface module interacts between the branch bank computer and the host computer system for translating the user requests into a language understandable by the host computer and for excerpting aggregate banking data supplied by the host computer into display messages which correspond to the data needed to satisfy the user request. The host computer system responds to the user's request by providing aggregate banking data corresponding to a specific user's account. The host interface module parses the aggregate banking data to select specific data items to be included in requested display messages. The module does this by including in the software a script language to produce messages understandable by the host computer for pattern matching a desired string included within the aggregate banking data to correspond to items selected by the user. For ease of use, the script may be in the form of a human readable text file.

The host interface module permits communication between a standardized branch bank computer including its user software and host computer systems of differing configurations. This module thus obviates the need to custom design the branch bank computer software for every possible host computer system configuration. The foregoing and other objectives, features, and advantages of the invention will be more readily understood upon consideration of the following_^ detailed description of the invention, taken in conjunction with the accompanying drawings.

Brief Description of the Drawings

FIG. 1 is a block diagram of the banking system.

FIG. 2 is a data flow diagram between the various blocks of the banking system.

FIG. 3 is a flow diagram of the branch bank computer.

FIG. 4 is a pictorial representation of a sample user screen. FIG. 5 is a flow diagram of the host interface module.

Description of the Preferred Embodiment

FIG. 1 is a block diagram of the major components of a banking system in accordance with the present invention. Any number of users 10a, 10b, and 10c can be connected to the banking system using their own personal computer or other type of user-operable communi¬ cation device. A user at a remote location, such as his home or office, operating a personal computer connected to a telephone line with a modem can communicate to a branch bank computer 20 for accessing banking services. Financial institutions permitting a user 10 to access his financial accounts from a personal computer in a remote location alleviates the prior requisite of a consumer personally coming into a financial institution or locating an automated teller machine to conduct banking services. To be explained in detail later, users 10 operating their personal computer are not required to obtain custom software for using banking services, rather, a user 10 only needs rudimentary terminal emula- tion software that supports some type of communication protocol, such as VT-100. Since a user 10 is not required to have custom software, the user 10.is relieved from the necessity of obtaining, maintaining, updating, or purchasing potentially expensive specialized software for using banking services and the bank is relieved of the necessity of having to support specialized software.

Referring to FIG. 2 in conjunction with FIG. 1, a description of the major functional blocks including the data flow is illustrated. The branch bank computer 20 receives a user request 16 from a user 10 to initiate a banking transaction . The message handler 22 depicted on FIG. 1 is a combination of the sending function of the branch bank computer 20, shown as the message requester 60 (FIG. 3) , and the receiving function of the host interface module 26 (hereinafter referred to as HIM) , shown as the message router 62 (FIG. 3) . The branch bank computer 20 processes the user request 16 then the message requester 60 sends a HIM protocol 24 request for banking data to the message router 62. After processing the HIM protocol 24 request the HIM 26 sends an appro¬ priate host protocol 28 request to the host 30. A host 30 is typically the actual banking computer at the bank, savings and loan, credit union or other financial insti¬ tution. The host protocol 28 required will differ for different hosts 30, therefore, the HIM 26 is designed to be capable of generating an appropriate host protocol 28 for the particular host 30 containing aggregate banking transaction data. The HIM 26 was designed with a script file (described later) to allow for easy modifications for adapting to a new host 30. In response to receiving the appropriate host protocol 28 the host 30 returns a host screen 32, comprising a formatted screen of text or unformatted data, to the HIM 26. To avoid customizing each host 30 for the HIM 26, the host screen 32 received is the same screen which would be supplied to a teller's terminal making the same request. The HIM 26 then excerpts the appropriate data from the host screen 32. Then the message router 62 sends a branch bank protocol 34 response to the message requester 60. Afte process¬ ing the branch bank protocol 34 response the branch bank computer 20 replies to the user 10 by providing a user screen 36 as the response to the original user request 16. A typical host 30 can only efficiently handle five users with a single HIM 26 serial interface line without unnecessary delay in the response time. To provide greater flexibility while reducing the response time, additional host interface modules 76 can be added in parallel for each additional five users. The pipes between the branch bank computer, message handler, and host interface module, is a method of exchanging information common in many systems, including UNIX. FIG. 3 shows a more detailed block diagram of the branch bank computer 20. A user 10 sends a user request 16 to the branch bank computer 20, selected from a set of options on his display provided by the branch bank computer 20, which is received by the communication software 40. The communication software 40 is capable of performing all the interface functions necessary to facilitate connecting and communication with the user 10. Such functions may include; initially connecting to the user 10, receiving user 10 specific configuration data, receiving/sending data, and uploading/downloading files. The branch bank computer 20 and HIM 26 are preferably implemented on a computer using an OS/2 or UNIX multitasking operating system, also known as preemptive multitasking. Under a preemptive multitasking environ¬ ment the time-sharing requirements between different users 10 is facilitated by the operating system and each user 10 connecting to the branch bank computer 20 will require a separate dedicated communication module 40.

The communication module 40 is connected to the valid user input 42 which analyzes the particular user request 16 to determine where to route the user request 16. Further, the valid user input 42 keeps track of user specific- information, such as, display type, computer system, emulation mode, modem protocol, status^ and available options for the branch bank computer 20.

If the valid user input module 42 determines that the user's display needs to be updated then control is passed to the user screen create module 44. All communications with each user 10 are done in the form of a complete text display (user screen 36) transmitted each time a change is required to the user's 10 display. The branch bank computer 20 keeps track of what display the user 10 should be viewing at any particular time, includ¬ ing program options currently available to that user. In contrast, traditional banking software executes on the user's computer, while communicating with the branch ban computer 20 only when a banking transaction is desired. By locating the banking software at the branch bank com¬ puter 20, individual users 10 are relieved from acquir¬ ing, maintaining, and updating specialized banking soft¬ ware. Further, the operator of the branch bank computer 20 may modify, at will, the interface with the users 10 thereby supplying all users 10 with the modifications. The branch bank computer 20 uses a two-stage process to create an internal screen image that is trans¬ ferred to the user 10 as a user screen 36. The user screen create module 44 fills in the main features that the internal screen image should contain depending upon the option chosen. The specific details required for a particular user's 10 internal screen image is supplied by several other modules. If the user 10 selects the "introductions" screen or the branch bank computer 20 is sending its first user screen 36 upon connection to the user 10, the user screen create 44 fills in the main features of the screen image. The introduction screen image is then completed by the introduction screen 46 module. If the user 10 selects the news screen, then as with the introduction screen, the user screen create 44 fills in the main features of the screen image then the news screen module 48 completes the screen image. For all other functions that necessitate changing the user's 10 display, the user screen create module 44 fills in the main features of the screen image to correspond with the option selected. The general screen display 50 then completes the screen image with user 10 specific details.

FIG. 4 is a sample screen supplied by the branch bank computer 20 for the user's 10 display. The lower lines of the screen show the status of the banking system. The central portion of the screen shows the available options. The upper left portion of the screen shows an activated pull-down menu of the "main menu". The upper portion of the screen shows the specific details regarding a particular user's 10 account balances. In FIG. 4, the general screen display 50 would supply the account balance information and the remainder of the user screen 36 would be supplied by the user screen create module 44. Periodically, a user 10 will need to more than merely select a letter or function from the keyboard, such as entering a desired withdrawal amount from his account. The communication between the user 10 and the branch bank computer 20 is effected by single keystroke commands by the user 10. By limiting each user 10 request to a single keystroke or a series of single keystrokes, the user banking software can be located at the branch bank computer 20. The user 10, therefore, only needs a rudimentary communication program to facilitate the necessary character transfer. To provide for multiple keystroke functions the field vali¬ date module 52 interfaces with the general screen display 50 and valid user input 42, to allow a complete entry to be entered. The completed entry is then sent to the valid user input 42 for further processing by other modules. For example, when a withdrawal function is chosen, the user screen create 44, general screen display 50, and field validate 52, collectively provide a display to the user 10 whereby the user 10 inputs the amount of the withdrawal and upon completion, the field validate 52 will send the amount to the valid user input 42 for further processing. Anytime the user's 10 display needs to be updated for any reason; the user screen create 44, in combination with the introduction screen 46, news screen 48, general screen display 50 and/or field vali¬ date 52, will send the completed screen image to the communication software 40. The communication software 40 then provides the user 10 with the screen image as a user screen 36. The branch bank computer 20 can also provide pop-up menus by the valid user input 42 routing a user request 16 to the pop-up menu driver 54 and user field look-up 56. Collectively, the pop-up menu driver 54 and user field look-up 56 act to modify the screen image by including an appropriate pop-up menu.

If the valid user input 42 determines that the user request 16 requires data from the host 30 then the user request 16 is sent to the message requester 60. The message requester 60 has an associated protocol file containing all the necessary information for transforming the user request 16 to an appropriate HIM protocol 24 request. The message requester 60 then sends the HIM protocol 24 request to the message router 62. Referring to FIG. 5, the message router 62 receives the HIM protocol 24 request and forwards it to the router receiver 66 of the valid host input 64. The router receiver 66 in conjunction with the host trans¬ lator 68 operates on the HIM protocol 24 request trans¬ lating it to the host protocol 28 format, for sending to the host 30. Additionally, the router receiver 66 informs the script driver 71 what to extract from the host screen 32. The host protocol 28 is designed to be compatible with the particular connected host 30. The host translator 68 has a translation protocol file that specifies how the translation from the HIM protocol 24, to the appropriate host protocol 28 is accomplished. A translation protocol file provides the flexibility for modifying the host protocol 28 simply by chanq-ing the translation protocol file whereby the HIM 26 can communicate with different hosts 30, or the same host 30 requiring a different host protocol 28.

Host 30 computers are primarily designed for use with bank tellers, and accordingly respond with a screen of text containing all relevant information about the account, which the teller selectively relays to the banking customer depending on the specific request. To maintain compatibility with existing host 30 systems, the valid host input 64 is designed to accept a standard screen of text and parse out the desired data for the user 10. The host screen 32 is received by the host receiver 70, which in conjunction with the script driver 71 operates on the host screen 32 to parse out the desired data. The script driver 71 sends the desired data to the message router 62. The message router 62 has a router protocol file for translating the received information from the script driver 71 to the branch bank protocol 34, for sending to the message requester 60. The message requester 60 receives the branch bank protocol 34 and sends it to the user screen create 44. A specialized script language is employed for faster and more flexible parsing of the host screen 32 and possibly transformation of the HIM protocol 24 to the host protocol 28. Host 30 applications residing at a financial institution are typically accessed through what is known as a command string. The HIM 26 creates a specialized command string referred to as the host protocol 28 for making a request to the host 30. An existing problem is that each host 30 application will require this command string presented in a different configuration. Since the branch bank computer 20 should always react in the same manner to the end user 10, there are two feasible alternatives. The first alternative is the least desirable, namely, rewriting the application to suit each host 30. Rewriting the application is an extremely time-consuming and expensive task. The second alternative is to create a specialized script language that can communicate with the host 30 using its partic- ular command string format. Typically, script files are data files that can be read at run time for facilitating communication with the host 30 application. Another characteristic of these script languages is that they are generally human readable text files that can be compiled on site and distributed to potential clients. By main¬ taining a human readable form the script files are much easier to change for new host applications. The task that the HIM script language is designed to do is pattern match for some string in a host screen 32. After the script language has located a match, the script language contains the control constructs to permit going forward or backward within the host screen 32 text for locating desired data. Further, to allow for greater programmer control, the script language should have control constructs such as if-then and loop statements.

Listings 1, 2, and 3 disclose a functional representation of script functions and a script listing. Listing 1 shows a sample script SEARCH function.

«LISTING 1»

SEARCH (SCREEN, START, END, PATTERN) FUNCTION NAME: SEARCH()

INPUT(S) : (1) SCREEN OR LINE OF DATA SEARCH

(2) STARTING LINE OF SEARCH

(3) ENDING LINE OF SEARCH

(4) PATTERN TO MATCH OUTPUT : LINE OF MATCH

The SEARCH function is used for searching the host screen 32 for a text pattern, such as key words within a line. The key concept is that the script driver 71 is searching a report-type output, and items searched for may exist within a line or a range of lines. There¬ fore, the SEARCH function permits defining the starting and ending lines of the data to search. The SEARCH func¬ tion has a pattern parameter which defines the text to search for, which may be run-time variables. Run-time variables are those whose value is known only at run¬ time, such as the user account number. A sample pattern make look like: "SUFFIX:" $ACCTNUM $NAME 99/99/9999. That particular pattern would attempt to locate the key word "SUFFIX:" followed by the user's account number, the user's name, and a string of text that has a structure like 99/999/9999 (date) .

Listing 2 shows a sample script SCAN function.

«LISTING 2» SCAN (KEYWORD, +/-1DC, $VAR, PREC, DEC, DTYPE, DELIM,

ATTRIB, NULL, ERR#) FUNCTION NAME : SCAN() INPUT(S) : (1) KEYWORD TO BEGIN SEARCH

(2) OFFSET FROM KEYWORD OR BEGINNING OF LINE

(3) LOCATION TO STORE VALUE

(4) PRECISION (OR LENGTH)

(5) DECIMAL (OR ZERO)

(6) DTYPE (CHAR, DECIMAL, NUMERIC, DATE)

(7) DELIMITERS

(8) ATTRIBUTES (TO BE APPLIED

=>JUSTIFY, CASE)

(9) EMPTY VALUE INDICATOR (10) ERROR NUMBER IF EMPTY The SCAN function searches for specified data elements within a host screen 32 looking after a key word, or a hard coded location. The location parameter ("LOC") is used to control the offsetting from a particular loca- tion. The data type ("DTYPE") parameter allows the SCAN function to make assumptions about the structure of the data it is searching for, such as, character, decimal, numeric, or date. The attribute field ("ATTRIB") is for modifying the data after parsing it from the host screen 32. "NULL" and "ERR#" allow a response indicating that particular data was not located.

Listing 3 shows a sample script text_^that could be used to parse the host screen 32 for desired information. «LISTING 3»

0 [MAIN]

1 SET(CLIN, 10, ABS)

2 X = SEARCH (SCREEN, CLIN, CLIN+10,

"SUFFIX: $SHACCT *a[?9]") 3

4 IF X = TRUE BEGIN

5 LOOP

6 SET(CLIN, 2, REL)

7 Y = SEARCH (LINE, CLIN, CLIN, "SFX:") 8

9 IF Y = TRUE

10 L = SCAN ("*3a", 0, $SHCODE, 4,0, "j,;",

11 RJUST,"",122)

12 L = SCAN ("",L $DESC, 12, 0, "!,;",N0NE, 13 "", 0)

14 L = SCAN ("",L,$AMT, 10, 2, "j,;",DEC,

15 "00", 710)

16 ENDIF

17 LOOPEND Y 18 ENDIF

19 [END]

Listing 3 initially sets the current line variable (CLIN) to 10. The "ABS" parameter denotes absoluteness, which means the value of CLIN is not set in relation to its prior value. The parameters of the SEARCH and SCAN functions use a regular expression search pattern. The SEARCH function on line 2 returns a TRUE (X=l)/FALSE (X=0) value to the variable X depending upon if the desired data is located. The pattern parameter, as shown in listing 1, is passed the pattern "SUFFIX: $SHACCT *a[?9]" to locate. This pattern causes the SEARCH function to search for the text "SUFFIX: " followed by the run-time variable replacement of $SHACCT (account number) which is followed by another string of text. The * delimiter provides for any number of characters to be spaced between the $SHACCT and an "a". The expression in brackets does not need to be present to satisfy the search function, but if present, must be one character (as denoted by the ?) followed by a 9. If the pattern is located in the specified lines of data to be searched (CLIN to CLIN+10) then X is set to a true value, otherwise, X is set to a false value. Lines 4 and 18 set up a standard if-then structure based on if X is true. A loop structure is set up by lines 5 and 17 which causes what is contained in lines 6-16 to be executed until Y is false. Line 6 sets CLIN to CLIN + 2 because "REL" denotes a value relative to what was previously contained in CLIN. Line 7 performs another SEARCH function similar to line 2. If Y is true then lines 10-15 will be executed, otherwise, control is passed to line 17. The SCAN functions on lines 10-14 return a numerical value to the variable L of the location of the data that was found. The data scanned for is stored in the $VAR param-*- eter, shown on listing 2, which in listing 3 is stored in the variable $SHC0DE, $DESC and $AMT of respective lines 10, 12 and 14. In a regular expression search pattern format; "*3a" means any number of characters followed by 3 alpha characters (A-Z) , RJUSΪ means to right justify, NONE means to do nothing and DEC means to use a decimal format.

Listing 4 is a list of the actual script functions implemented for a host interface module. The function parameters relate to the following type of fields: "int" refers to an integer value; "str" refers to a string; "dbn^,l/^,,dbname" are data base names which are local variables used for the storage of data; "lab" is a label to jump program control to. For example, jumpeq compares the content of "dbn" and "str" and if they are the same jumps to the label "lab". Pslocate searches for a string (str) in a particular data base (dbn) within a specified area of the data.

<<LISTING 4>> *********************************************************

NAME himcommands.doc

DESCRIPTION Description of the script language functions

AUTHOR inn

CREATED 09/17/93

********************************************************

Script function names and descriptions:

1ocate(int,int,dbname)

Will place the data at (column,len) into the data base name '-name'. plocate(int,int,dbname) Will place the data at column,len) into the data base name '-name' and go to the next line. i.e. plocate(col,len,-name) ; pslocateIint,int,dbn,str) i.e. pslocate(col,len,-name,str) ; jumpeq(dbn,str,lab)

Jump to the label 'lab' if the content of 'dbn' and 'str' are the same. i.e. jumpeq(-name, 'string', @θLABEL) ; jumpbt(dbn,str,lab)

Jump i.e. jumpbt(-name, 'string',@§LABEL) jumpne(dbn,str,1ab)

Jump to label 'lab' if content of 'dbn' and 'str' are NOT the same i.e. jumpne (-name, 'string' ,@@LABEL) ; rtri (dbn)

Trim the data base field from spaces to the right i.e. rtrim(-na e) ; ltri (dbn)

Trim the data base field from spaces to the left i.e. ltrim(-name) ; toupper(dbn)

Convert the data base field to upper case letters i.e. toupper(-name) ; tolower(dbn)

Convert the data base field to lower case letters i.e. tolower(-name) ; assign(dbn,str)

Assign a value to the data base element i.e. assign(-name, 'string') ; format(dbn,int,str,str) Format a date or numerical value i.e. format(-name, 0(=date)/1(=numeric) , 'mm/dd/yyyy' (change from) , 'mm/dd/yy' (change to) ) TRANS(int)

Defines the start of a transaction i.e. TRANS(2)

TRANSEND(int) Defines the end of a transaction i.e. TRANSEND(2) toline(int) Go to line 'n' i.e. toline(lθ) ; incline(int) Increment line pointer by 'n' i.e. incline(2) ; goto(lab) Goto label 'lab' i.e. goto(§§LABEL) ; search(str,lab,int) i.e. search('string',@@LABEL, errcode) nsearch(str,lab,int) i.e. nsearch('string',@@LABEL, errcode) tassign(int,dbn,dbn,int) i.e. tassign (table,-code,-name,dfIt) nextline() Go to the next line prevline() Go to the previous line firstline() Go to the first line lastline() Go to the last line lempty(int,int,lab) i.e. 1empty(col,1en,@@LABEL) ; rempty(int,int,lab) i.e. rempty(col,len,@@LABEL) ; len(int,int,lab) i.e. len(col,len,@§LABEL) ; nlen(int,int,lab) i.e. nlen(col,len,@@LABEL) ; error(int) table(str,str) compare(int,str,lab) ncompare(int,str,lab) rjust(dbn) 1just(dbn) strcat(dbn,dbn) addf(dbn,dbn,dbn) addc(dbn,flt,dbn) subf(dbn,dbn,dbn) subc(dbn,flt,dbn)

FUNC(str)

FUNCEND(str) funccall(lab,int,int) label(int) pushc(int) setglobal(str,str) print(str,dbn,int) stripline(str) stripdup() TABLEBEG(int)

TABLEEND(int) send(str,lab) reccount(int,int,str,lab) datecmp(dbn,dbn,str,lab) logoff(str,lab) logon(str,lab) resetscreen()

Listing 5 (shown at the end) is an actual implementation of a script text for the FISERV Galaxy

2000 host system. The start of the script text sets up tables 0, 1 and 2 as a translation table between a numer¬ ical code in column 1 and its textual description in column 2. Next, the script text defines an errorhandler function and a historyhandler function which are used by the transaction procedures. The various transaction procedures, which are called by the host interface module are executed by calling the function TRANS(#), where the # denotes the number of the transaction procedure. Each transaction procedure is designed to perform some specific function for the parsing of the host screen 32.

The script interpreter 72 reads the script text and sends the script text to the script compiler 74 to compile the script text into a binary format acceptable for the script driver 71. Compiling the script text creates a binary code that executes extremely fast, compared to interpreting the script text, when parsing each host screen 32. The script interpreter 72 may also read a set of command functions that defines the appro¬ priate command string for the particular host 30. The script compiler 74 then may compile the command functions for use by the host translator 68. A compiled set of script functions allows the host translator 68 to quickly translate the HIM protocol 24 request to a host protocol 28 request, but the time savings involved is not nearly as great as using a compiled code for parsing the host screen 32. In the alternative, the host translator 68 can use a translation protocol file as previously described.

The interface between the branch bank computer 20 and the host interface module 24 is defined by a protocol which is preferably defined by a protocol data file(s) which is read by the message handler 22 (message requester 60 and message router 62) upon start-up. As an alternative, the message handler 22 could be constructed in a manner similar to the valid host input 64 to permit the use of a compiled code. The transaction set contained in the protocol data file(s) contains all the information necessary for communication between the message requester 60 and message router 62.

A key concept is that the protocol in the message handler 22 provides a logical demarcation between the branch bank computer 20 and the HIM 26 so that any changes/modifications to one does not affect the other. If the host 30 is changed, the script text may require rewriting but the branch bank computer 20 would not require any modification. In other words, the branch bank computer sees the HIM the same even if the latter is modified for a different host. This demarcation allows the banking system to be easily modified for different hosts 30. Likewise, any changes to the branch bank computer 20 does not affect the HIM 26. In other words, the HIM sees the branch bank computer the same even if the latter is modified. The following functions would ideally be included in a basic protocol data file(s) in the message handler 22: PIN VERIFY, PIN CHANGE, MAIN INQUIRY,

HISTORY, TRANSFER and WITHDRAWAL. The PIN (personal identification number) VERIFY protocol could be modeled as follows:

PIN VERIFY:

INPUT(S): (1) TELLER ID

(2) TRANSACTION CODE

(3) ACCOUNT NUMBER (4) OLD PERSONAL ID NUMBER

OUTPUT(S): (1) ACCOUNT NUMBER

(2) OPERATION STATUS The message requester 60 would make an HIM protocol request in the following form: P100, PINN, 123456789, 1234. Each field in the HIM protocol 24 request refers to the different fields defined by the input section of the particular function in the protocol data file. The message router 62 after receiving the appropriate infor¬ mation from the script driver 68 would send a branch bank protocol 34 response including the account number and operation status.

The terms and expressions which have been employed in the foregoing specification are used therein as terms of description and not of limitation, and there is no intention, in the use of^* such terms and expres¬ sions, of excluding equivalents of the features shown and described or portions thereof, it being recognized that the scope of the invention is defined and limited only by the claims which follow.

Claims

What is Claimed is:

1. A data processing system for conducting banking transactions over telephone lines comprising: (a) a plurality of user operable communications devices connectable to a branch bank computer over telephone lines, said device having at least a display screen and communication means for inputting messages corresponding to user requests;

(b) said branch bank computer including software means for interpreting said messages from the user operable communi- cation devices for requesting data and effecting selected banking transactions;

(c) a host computer system containing aggregate banking transaction data;

(d) a host interface module interacting between the branch bank computer and the host computer system for translating said user requests into language understandable by said host computer and for excerpting data supplied by said host computer into display messages corresponding to data needed to satisfy said user requests.

2. The data processing system of claim 1 wherein said host computer responds to said user requests by providing aggregate banking data corresponding to a specific user and said host interface module includes means for parsing said aggregate banking data to select specific data items to be included in said display messages. 3. The data processing system of claim 2 wherein said means for parsing said host interface module includes software means comprising a script language understandable by said host computer for pattern matching a desired string included within said aggregate banking data.

4. The data processing system of claim 3 wherein said script language is in the form of a human- readable text file.

5. The data processing system of claim 1 wherein said branch bank computer includes a multitasking operating system.