Note: Descriptions are shown in the official language in which they were submitted.
~ Wo 95r590l0 2 1 8 0 6 3 5 r~u . ~
HOMl BANKING SYSTEM
~ach4L~ ld of the Invention
In the banking industry, Pcrpci~lly at the
~ r level, banks strive to make it convenient for
customers to make deposits, cash checks, pay bills and a
host of other banking I~L~ j onc. Most _ -
oriented banks have est~hl; chPd branches in urban,
, ~. ,t ;~n 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-
zlction information, make deposits, make withdrawals or to
shift funds from one account to another, the customer
must still make a p~rs~n~l visit to the bank. Some banks
have voice ,r,,eLc.ted systems for n~ - 1 ;ch;ng some of
these tasks which, however, nevertheless require a huma~,
~c Le~ L at the bank to receive instructions and provide
the nPcpcsAry information or make the desired
tri-nc~t~ti~
The advent of miul~,~rou~3sor-based
i~ations gygtems such as pPrFr~n~l computers
connected to tP~ Prh-~nP lines by modem has enabled users
to perform a variety of tasks t~tat previously had to be
done in person or through i nt~ ries. Using this
te~hnolQgy computer banking systems have been attempted
on an experimental basis using a customized software
package written for the host computer of a particular
f;n~n~ l in8titution which has enabled a limited numher
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 specif ic
bank's host computer. Furth~ ~, 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 i5 present in such operating environments
is essential in order to acc - ' Ite the potentially
WO95/19010 2 1 ~ 0 635
large number of users who would desire to have access to
the ~vanking system via modems and the like.
The problem inherent in this env; t,
however, is that there may be many different types of
5 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 c~nn~cted to via telephone lines. That is,
lO the users must connect to the bank' host _LeL through
a local computer ;~nc-~as~cl through the particular branch
bank computer. This local computer should inc,lude soft-
ware which is usable by the remote users through a
i C-ntions device which 5hould consist of no more
15 than a personal . L ~r and a modem . In other words, it
would be very ~ ~i r~hle for the user not to have to
acquire special purpose software in order to ; rnte
with the branch bank computer. Instead, this software
should be located at the branch bank's computer 50 that
20 all the user has to do in order to use the system is to
connect to the branch bank's L~r on his modem. The
problem remains, however, that if the software were stan-
dardized for the individual branch banks (50 that users
may ~ ; ~ate easily), there would still exist the
25 problem of how to interface this software with host
computers of different configurations without rewriting
the ~ranch bank's software for a plurality of different
host computers.
Other systems have been proposed for home
30 banking that utilize a multi-bank ATM network. An
example is shown in ~vawlor 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
35 special t~m;n~l that emulates an ATM and that requires
A~r, ~ ~ible PIN codes. These t~m;n;~l~ communicate
over telephone lines through an ATM network to connect
~ W09St~9010 . 2 1 8 0 635 Y~ 1;!2
with the user's bank. The use of such a system, however,
reyuires acceptance by ~OI~D~ -rS of a special purpose
t- rminAl . Also, constraints are imposed by the require
ment that the torm;nAl emulate the now-fAm;l;Ar ATM.
Finally, ~Lu~}~e~Live member banks may not embrace a
system that reyuires use of the ATM network.
rv of the Invention
The system of the invention i5 a data
proc~Ccin~ system for cnn~ t; n~ banking transactions
over telephone lines and includes a plurality of user-
operable . ; ~stion devices cnnn~ctAh] e 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
r- "]~n ~;ULL- ~ rlA;n~ to uger réyueDI ~:. The branch bank
computer includes software for interpreting the -~~ ; ~
from the users for reyuesting banking data and for
effecting selected banking trAncAct; nnc. The system
contemplates a host computer system serving the entire
banking network including a plurality of bL~r,~ lles, which
includes ayyLey~e 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 reyuests into 2
language understandable by the host computer and for
excerpting a ~yLc:y~te banking data supplied by the host
computer into display , 3F which cc,LLeDIJull~ to the
data needed to satisfy the user reyuest.
The host computer system ~ ù-~ds to the user's
reyuest by providing ayyL~y-te banking data CUL1~~ r~
to a specific user's account. The host interface module
parses the ayyLeyC-te banking data to select specif;~ data
items to be included in reyuested display r-- ; ~. The
module does this by ;nrl~ ;ng in the software a script
language to produce -- ~e understandable by the host
computer for pattern matching a desired string included
_ _ _ _ _ _ _ _ _ _ _ _ _ .
W095/l9010 21 80635 r~
within the ayyLey<lte banking data to COLLe~u~ld 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 ~- ; ration
5 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, fe~.l u ~s,
and advantages of the invention will be more readily
understood upon cnn~ ~ation of the followins detailed
description of the invention, taken in c;ul.ju..cLion with
the ~ ~ y ing drawings .
Brief Descril~tion of the Drawi n~
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 re~Le:Sell~iOn of a
sample user screen.
FIG. 5 is a flow diagram of the host interface
module .
Descri~tion of the Preferred El _l;~ l
FIG. 1 is a block diagram of the major
3 0 ~s of a banking system in accordance with the
present invention. Any number of users lOa, lOb, and lOc
can be cnnn~ct~d 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 1 ine with a modem can communicate to a
branch bank computer 20 for aCcpc~;n~ banking services.
~ WO 95~19010 : 2 1 8 0 6 3 5 r~
F;nAn-i 11 institutions permitting a user lo to access his
f; nAn~ accounts from a personal computer in a remote
location alleviates the prior requisite of a Cnn~ ~ r
personally coming into a fin~n~ l institution or
locating an ~utomated teller machine to conduct banking
services. To be ~ in-~d in detail later, users 10
operating their p~rfi~n~l computer are not required to
obtain custom software for using banking services,
rather, a user 10 only needs r~lA; ~ILy t~rrn;n~l emula--
tion software that supports some type of _ ; ca~; rm
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 5p~ l software
for using banking services and the bank is relieved of
the necessity of having to support spe~ od software
Referring to FIG. 2 in c<,l.j u--~;Lion with FIG. 1,
a description of the major functional block8 ;n~ A;n~
the data flow is illustrated. The branch bank ~ ~r
20 receives a user request 16 from a user 10 to initiate
a banking transaction . The message handler 22 ADpiot~A
on FIG. 1 is a combination of the sending function of tlie
branch bank computer 2 0, shown as the message requester
60 (FIG. 3 ~, and the receiving function of the host
interface module 26 (hereinafter referred to as HIN),
shown as the message router 62 (FIG . 3 ) . The branch ballk
computer 20 ~vcesses the user request 16 then the
message requester 60 sends a HIN protocol 24 request foe
banking data to the message router 62. After proc~c~:;nq
the HIM protocol 24 request the HIN 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 f;n~nt-j;ll insti-
tution. The host protocol 28 required will differ for
different hosts 30, therefore, the HIN 26 is designed t
be capable of generating an ~ru~L iate host protocol 2 3
for the particular host 30 containing aggregate banking
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ . . .
W095/l9010 Zl 80635 ~ [i~ ~
transaction data. The HIM 26 was designed wit~ a script
file (described later) to allow for easy modi~ications
for adapting to a new host 30. In Le ~u..se to receiving
the ~pLu~Liate host protocol 28 the host 30 returns a
5 host screen 32, comprising a formatted screen of text or
.II.fuL~ l l ed data, to the HIM 26. To avoid ~:u5t, i 7;n~
each host 30 for the HIM 26, the host screen 32 received
i5 the same screen which would be supplied to a teller's
1-~rm;ns~l making the same request. The HIM 26 then
10 excerpts the ~Lu~,liate data from the host screen 32.
Then the message router 62 sends a branch bank protocol
34 l~D~u..~,e to the message requester 60. After pLuCe~s-
ing the branch bank protocol 34 re~u.,se the branch bank
~ _Ler 20 replies to the user lO by providing a user
15 screen 36 as the r~ul~se 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
..~ . y delay in the ~ u-,=,e time. To provide
greater flexibility while reducing the l~=,~ullse time,
additional host intersace modules 76 can be added in
parallel for each additional five users. The pipes
between the branch bank computer, message handler, and
host interf~ce module, is a method of exchanging
information common in many systems, including ~NIX.
FIG. 3 shows a more detailed block diagram of
the branch bank computer 2 0 . 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 ~ ation
software 40. The ~ i r~tion software 40 is capable of
performing all the interface functions nP~ s~ry to
facilitate conn~ct;n~ 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
_ _ _ _ _ . _ _ _ _ _
~ WO 95119010 ~ 2 1 8 0 6 3 5 , ~." 9~ 2
multitasking operating system, also known as preemptive
multita6king. Under a preemptive multitasking environ-
ment the time-sharing requirements between different
users 10 is facilitated by the operating system and each
5 user 10 connecting to the branch bank computer 20 will
require a separate dedicated ~ i re~tion module 40 .
The c i c?~tion module 40 is cc~nn~c ted 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 keep6 track of user
speci fir 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 ~lO1-~rminc~#
15 that the user's display needs to be updated then control
is passed to the user screen create module 44. All
; cations 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
20 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
ClO1l~LC~ tr~ditional banking 80r~w~L~z executes on the
user's computer, while, irating with the branch bank
25 computer 20 only when a banking t- ~lA~ iOn is desired.
By locating the banking scrl w~ ~ at the branch bank com-
puter 20, individual users 10 are relieved from acquir-
ing, maintaining, and updating sp~ci ~1 i 70d banking soft-
ware. Further, the operator of the branch bank computer
30 20 may modify, at will, the interface with the users 10
thereby supplying all users 10 with the ~ ' i f i c~tions .
The branch bank computer 2 0 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
35 screen create module 44 fills in the main features that
the internal screen image should contain ~l~pe-n~l i n~ upon
W0 95/19010 2 1 8 0 6 3 5 P~ 1.. 5. 11~ ~
the option chosen. The 6pecific details required for a
particular user's 10 internal screen image is supplied
by several other modules. If the user 10 selects the
Loduu-ions'' screen or the branch bank computer 20 is
5 sending its first user screen 36 upon ~ nn~c~ n 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 il-LLuduuLion screen 46
moaule. If the user 10 selects the news screen, then as
10 with the i~lLLu-luu~ion 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
15 main fe~lLuL-=s of the screen image to cuL~e~lJul.d with the
option selected. The general screen display 50 then
completes the screen image with user 10 speri f i ' details .
FIG. 4 is a sample screen supplied by the
branch bank computer 20 for the user's 10 display. The
20 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
l;hows an activated pull-down menu of the "main menu".
The upper portion of the screen shows the 8p~c;f;c
25 details regarding a particular user's 10 account
h~l71nrDC. In FIG. 4, the general screen display 50 would
supply the account balance information and the r~ ; n~ r
of the user screen 36 would be sllrPl ;ed by the user
screen create module 44. Perio~l;c~lly~ a user 10 will
30 need to more than merely select a letter or function from
the keyboard, such as entering a desired withdrawal
amount from his account. The ; cation between the
user 10 and the branch bank computer 20 is effected by
single keystroke n~lc by the user 10. By limitiPg
35 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 lO,
~ WO95/19010 2 1 8 0 635 r~ ,S. 122
therefore, only needs a rllA~ ry, ; ~ation progra~
to facilitate the n~c~fiS~ny character transfer. To
provide for multiple keystroke fllnr~;~mc 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 proc~csin~ by other
modules. For example, when a withdrawal function is
chosen, the user screen create 44, general screen display
50, and field validate 52, Gnl lec~ively 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 pror~CEin~. Anytime the user's 10 display needs
to be updated for any reason; the user screen create 44,
in combination with the i.lLLv-lu.;l.ion screen 46, news
screen 48, general screen display 50 and/or field vali-
date 52, will send the completed screen image to the
i ration software 40 . The _ ; cation software 4~
then provides the user 10 with the screen image as a user
screen 36. The branch bank _~eL 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 a~ V~L iate pop-up menu .
If the valid user input 42 det~ n~c 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 n~c-~c8~ry information for transforming
the user request 16 to an a~Lv~Liate HIN 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
WO 95119010 2 ~ ~ 0 6 3 5 . ~ 'C 122
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
5 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 c~nnPc~ed host 3 0 . The
host translator 68 has a translation protocol file that
spDnif;e,s how the translation from the HIM protocol 24,
lO to the ~ v~Liate host protocol 28 is a ~ i :h~d. A
translation protocol file provides the flexibility for
modifying the host protocol 28 simply by nh~n~;i n~ the
translation protocol file whereby the HIM 26 can
ate with different hosts 30, or the same host
15 30 rP~;r~n~ a different host protocol 28.
Host 30 computers are primarily ~P~ ned 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
20 banking ~;UDt, ~ ~DpDnrl;n~ on the spPcifi~- request. To
maintain compatibility with existing host 30 systems, the
valid host input 64 is dPs:~nD~l to accept a ~ n~
screen of text and parse out the desired data for the
user 10. The host screen 32 is received by the host
25 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
30 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 spDc;Al;7Prl script language is employed for
35 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
Wo ss/lsolo 2 t 8 0 6 3 5 ~ v ~ 2
11
financial institution are typically Acc~ccecl through what
is known as a command string . The HIM 2 6 creates a
cr~ci~l ;7ed command string referred to as the host
protocol 28 for making a request to the host 30. An
5 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 f irst alternative is
10 the least desirable, namely, rewriting the application to
suit each host 3 0 . Rewriting the appl ication is an
e~L-~ -ly time-cnnCI~m;n~ and expensive task. The second
alternative is to create a specialized script language
that can i~-nte with the host 30 using its partic-
15 ular command string format. Typically, script files aredata files that can be read at run time for facilitating
_ ication with the host 30 application. Another
characteristic of these script 1~ Jec is that they are
generally human readable text files that can be il~d
20 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 ~ ign~cl to do is pattern
match for some string in a host screen 32. After the
25 script language has located a match, the script l~n~qe
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 ~LoyL
control, the script language should have control
30 constructs such as if-then and loop statements.
Listings 1, 2, and 3 disclose a functional
representation of script functions and a script listing.
WO 95/l9010 ~ 2 1 8 0 6 3 5
12
Listing 1 shows a sample script SEARCH
function .
<<LISTING 1>>
8EA~C~ (SCREEN, START, END, PATTERN)
5 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 : LI~E 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
15 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 ~Dfinin~ the starting
2md ending lines of the data to search. The SEARCH func-
tion has a pattern parameter which def ines the text to
20 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: " S~'C~ TM $NAME 99/99~9999.
That particular pattern would attempt to locate the key
25 word "SUFFIX: " followed by the user's account number, the
user's name, and a string of text that has a ~ u~;L
like 99/999/9999 (date).
Listing 2 shows a sample script SCAN function.
<<LISTING 2>>0 8CAN (KEYWORD, +/-LOC, $VAR, PREC, DEC, DTYPE, DELIM,
ATTRIB, NULL, ERR#)
FUNCTION NAME : SCAN ( )
INPUT(S) : (1) KEYWORD TO BEGIN SEARCH
(2) OFFSET FROM KEYWORD OR ~ NN ~ NG
3 5 OF LINE
3, LOCATION TO STORE VALUE
~4 l PRECISION (OR LENGTH)
DECIMAL (OR ZERO)
, 6j DTYPE (CHAR, DECIMAL, NUMERIC,
DATE)
7 ) DELIMITERS
(8) A~ ~S (TO BE APPLIED
=>JUSTIFY, CASE)
(9) EMPTY VALUE INDICATOR
(10) ERROR NUMBER IF EMPTY
..... . . .. . .
WO 95119010 2 1 8 0 6 3 5 r~ 5~
.
13
The SCAN function searches for spec;fi~cl 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-
5 tion. The data type ("DTYPE") parameter allows the SCANfunction to make assumptions about the ~LU~;LUl~ of the
data it is searching for, such as, character, decimal,
numeric, or date. The attribute field t"ATTRIB") is for
modifying the data after parsing it from the host screen
10 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 .
15 <<LISTING 3>>
O tMhIN]
SET(CLIN, 10, ABS)
2 X = SEARCH tSCREEN, CLIN, CLIN+10,
" SUFFIX: 5SHACCT * a [ ? 9 ] " )
4 IF X = TRUE BEGIN
5 LOOP
6 SET (CLIN, 2, REL)
7 Y = SEARCH (LINE, CLIN, CLIN, "SFX: ")
9 IF Y = TRUE
L = SCAN ("*3a", O, $SHCoDE, 4,0, ''l,:'',
11 RJUST, "" ,122)
12 L = SCAN ( ~ n, L $DESC, 12, 0 , " ~,; " , NONE ,
13 "", )
14 L = SCAN ("",L,$AMT, 10, 2, "~,;",DEC,
"00", 710)
16 ENDIF
17 LOOPEND Y
35 18 ENDIF
19 [END]
Listing 3 initially sets the current line
variable (CLIN) to 10. The "ABS" parameter denotes
40 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
45 if the desired data is located. The pattern parameter,
WO 95119010 2 1 8 0 6 3 5 r~
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 r~rrA~ L 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 $5HACCT 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 :.L u~;Lule is set up by lines 5 and 17 which causes
what is contained in lines 6-16 to be ~Y~cnt~d 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 fllnrti nn~ 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 SVAR param
eter, shown on listing 2, which in listing 3 is stored in
the variable $SHCODE, $DESC and $AIIT of respective lines
10, 12 and 14. In a regular eYpression search pattern
format; "*3a" means any number of characters followed by
3 alpha characters (A-Z), RJUST 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"/"dbname" are data base names which are
local variables used for the storage of data; "lab" is a
,
~0 95119010 5 P~ 122
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 f~r
a string (str~ in a particular data base (dbn) within a
5 specified area of the data.
~ ( LISTING 4~ ~
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
NAI~E h i r ' - . doc
DESCRIPTION Description of the script language
10f~ln~t j ~n~:
AUTHOR inh
CREATED 09/17/93
~AAAAAAAAAAAAA~I:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Script function names and descriptions:
2 0 l ocate ( int, int, dbname )
Will place the data at (column, len) into
the data base name ' -name ' .
plocate(int, int,dbname)
WilI place the data at column, len) into
the data base name ' -name ' and go to the
next l ine .
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
3 5 ' dbn ' and ' str ' are the same .
i . e . j umpeq ( -name , ' string ', Q @LaBEL~;
j umpbt (dbn, str, lab )
Jump
i.e. jumpbt(-Rame, 'string' ,QQLABEL)
j umpne (dbn, str, lab )
Jump to label 'lab' if content of 'dbn'
and 'str' are NOT the same
i.e. jumpne (-name,'string',QQLABEL);
rtrim (dbn)
Trim the data base field from spaces to
the right
i.e. rtrim(-name);
WO 95/l9010 2 1 8 0 6 3 5 ~ tDi~
16
ltrim ( dbn )
Trim the data base field from spaces to
the left
i . e . ltrim ( -name );
toupper (dbn)
Convert the data base f ield to upper case
letters
i . e . toupper ( -name);
tolower (dbn)
Convert the data base f ield 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)
2 0 Format a date or numerical value
i . e . f ormat ( -name
Ot=date)/l(=numeric), 'mm/dd/yyyy' (change
from), 'mm/dd/yy' (change to) )
2 5 TRANS ( int )
Defines the start of a transaction
i . e . TRANS ( 2 )
TR~NS~Nn ( int)
Defines the end of a l.. cl~Dc~ l ion
i.e. 'rRP~NCF-
toline(int) Go to line 'n'
i.e. toline(10);
incline(int) Increment line pointer by 'n'
i . e . incline ( 2 );
oto ( 1 ab ) Goto 1 abel ' lab '
4 0 i . e . goto ( Q QLABEL);
search(str,lab,int) i.e. search('string',QQLABEL,
errcode)
45nsearch(str,lab,int) - i.e. nsearch('string',QQLABEL,
errcode)
tassign(int,dbn,dbn,int) i.e. tassign
(table, -code, -name,dflt~
nextline() Go to the next line
prevline ( ) Go to the previous line
firstline() Go to the ~irst line
lastline ( ) Go to the last line
-- = . =
~ WO 95119010 . 2 1 8 0 6 3 5
17
lempty(int,int,lab) i.e. lempty(col,len,QQL~BEL);
rempty(int, int,lab) i.e. rempty(col,len,QQLABEL);
len(int,int,lab) i.e. len(col,len,QQLABEL);
nlen ( int , int , lab) i . e . nlen (col , len , Q QL~BEL);
5 error ( int)
table (str, str)
eompare(int, str, lab)
neompare ( int, str, lab)
r; ust ( dbn )
10 ljust (dbn)
strcat (dbn, dbn)
adaf ~dbn,dbn,dbn'
addc ~dbn, f lt, dbn
subf ~dbn,dbn,dbn
15 subc ~'dbn, flt, dbn,
FUNC 1' str)
FUNC- :ND ( str)
funeeall (lab, int, int)
label ( int)
2 0 pushc ( i nt )
setglobal (str, str)
print(str, dbn, int)
stripline (str)
stripdup ( )
2 5 'I'A RT ,~RT~G ( int )
TART ~ ~n ( int)
send(str, lab)
~ccuullL (int, int, str, lab)
dateemp(dbn,dbn,str,lab)
30 logoff (str, lab)
logon(str, lab)
resetsereen ( )
Listing 5 ( shown at the end) is an aetual
35 implementation of a seript text for the FISERV Galaxy
2000 host system. The start of the seript text sets up
tables 0, 1 and 2 as a translation table between a numer-
ieal eode in eolumn 1 and its textual deseription in
eolumn 2. Next, the seript text defines an errorhandler
40 funetion and a historyhandler funetion whieh are used by
the transaetion ~LuceduL~:s. The various transaetion
p~vceduL.2s, whieh are ealled by the host interfaee module
are exeeuted by ealling the funetion TRANS (#), where the
# denotes the number of the transaetion yruceduL~:~ Each
45 transaction ~ùceduL~: is ~o~;~n~d to perform some
specific function for the parsing of the host screen 32
The script interpreter 72 reads the script te~t
and sends the script text to the script eompiler 74 to
. .. _ _ . . .... .... _ . ... _ . . . . . _ _ _ _ _ _ _ _ _
WO 95119010 2 1~ 0 6 3 5 r~ 2~ ~
18
compile the script text into a Jinary format acceptable
for the script driver 71. Compiling the script text
creates a binary code that executes ~XLL~ ~1Y fast,
~:d to interpreting the script text, when parsing
5 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 fl7nrti~1nc
for use by the host translator 68. A compiled set of
10 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 t'le alternative, the host translator 68
15 can use a translation protocol f ile as previously
described .
The interf ace 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
20 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
25 contained in the protocol data file(s) contains all the
information noc~Cc:~ry 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
30 branch bank computer 20 and the HIM 26 so that any
changes/r-';ficltions 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
35 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
~ W095/19010 ~ - 21 80635 r~
19
hosts 3 0 . Likewise, any changes to the branch bank
computer 20 does not affect the E~IM 26. In other words,
the HIM sees the branch bank computer the same even if
the latter i5 modified.
The following functions would ideally be
included in a basic protocol data file(s~ in the messag~
handler 22: PIN VERIFY, PIN C~IANGE, MAIN INQUIRY,
HISTORY, TRANSFER and w~ nl~W~T The PIN (personal
identification number) VERIFY protocol could be modeled
as follows:
PIN VERIFY:
INPUT ( S ): ( 1 TELLER ID
(2) ~RAN~'TTON CODE
(3 l ACCOUNT NUMBER
(4; OLD PERSONAL ID NUMBER
OUTPUT ( S ): ( 1 ) ACCOUNT NUMBER
( 2 ) OPERATION STATUS
20 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
25 message router 62 after receiving the ~ iate infor~
mation from the script driver 68 would send a branch bank
protocol 34 response i n~ i ng the account number and
operation status.
The terms and expressions which have been
30 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
35 the scope of the invention is defined and limited only by
the claims ~bich follow.
