CA2180635A1 - Home banking system - Google Patents
Home banking systemInfo
- Publication number
- CA2180635A1 CA2180635A1 CA 2180635 CA2180635A CA2180635A1 CA 2180635 A1 CA2180635 A1 CA 2180635A1 CA 2180635 CA2180635 CA 2180635 CA 2180635 A CA2180635 A CA 2180635A CA 2180635 A1 CA2180635 A1 CA 2180635A1
- Authority
- CA
- Canada
- Prior art keywords
- host
- computer
- data
- user
- protocol
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
- G07F19/20—Automatic teller machines [ATMs]
- G07F19/201—Accessories of ATMs
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- General Physics & Mathematics (AREA)
- Finance (AREA)
- Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Pit Excavations, Shoring, Fill Or Stabilisation Of Slopes (AREA)
- Vehicle Body Suspensions (AREA)
- Investigation Of Foundation Soil And Reinforcement Of Foundation Soil By Compacting Or Drainage (AREA)
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
~ 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
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
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
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 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 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
, 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, 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~
.
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 ] " )
~ 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 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 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
, 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, 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~
.
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) 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 ~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~
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 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~ ~
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~
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.
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) 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 ~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~
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 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~ ~
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~
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.
Claims (7)
1. A data processing system for conducting banking transactions over telephone lines comprising:
(a) a plurality of personal computers suitable for operation at a user's residence connectable to a branch bank computer over telephone lines, each of said personal computers having at least a display screen and communication means for imputing messages corresponding to user requests;
(b) said branch bank computer including computer software to interpret said messages from said personal computers 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 messages corresponding to data needed to satisfy said user requests.
(a) a plurality of personal computers suitable for operation at a user's residence connectable to a branch bank computer over telephone lines, each of said personal computers having at least a display screen and communication means for imputing messages corresponding to user requests;
(b) said branch bank computer including computer software to interpret said messages from said personal computers 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 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 multi-tasking operating system.
6. The data processing system of claim 1 wherein said branch bank computer is located proximate said host computer.
7. A method of conducting banking transactions over telephone lines, comprising the steps of:
(a) providing a plurality of personal computers suitable for operating at a user's residence having a display screen and communication means for imputing messages corresponding to user requests of data and effecting selected banking transactions;
(b) receiving said messages by said personal computer and transmitting said messages over telephone lines from said personal computer to a remotely located branch bank computer which receives said messages;
(c) interpreting said messages by said branch bank computer and said branch bank computer translating said messages into a first protocol suitable for a host interface module operating within said branch bank computer;
(d) transmitting said first protocol from said branch bank computer to said host interface module which receives said first protocol;
(e) converting said first protocol by said host interface module into a second protocol suitable for a host computer system containing aggregate banking transaction data;
(f) transmitting said second protocol from said host interface module to said host computer system located at a location proximate to said branch bank computer, and receiving by said host interface module from said host computer system a host screen of data in response to transmitting said second protocol;
(g) excerpting data from said host screen by said host interface module and producing a third protocol in response to said first protocol;
(h) transmitting said third protocol to said branch bank computer which receives said third protocol; and (i) transmitting a response from said branch bank computer to said remotely located personal computer corresponding to data needed to satisfy said user requests.
(a) providing a plurality of personal computers suitable for operating at a user's residence having a display screen and communication means for imputing messages corresponding to user requests of data and effecting selected banking transactions;
(b) receiving said messages by said personal computer and transmitting said messages over telephone lines from said personal computer to a remotely located branch bank computer which receives said messages;
(c) interpreting said messages by said branch bank computer and said branch bank computer translating said messages into a first protocol suitable for a host interface module operating within said branch bank computer;
(d) transmitting said first protocol from said branch bank computer to said host interface module which receives said first protocol;
(e) converting said first protocol by said host interface module into a second protocol suitable for a host computer system containing aggregate banking transaction data;
(f) transmitting said second protocol from said host interface module to said host computer system located at a location proximate to said branch bank computer, and receiving by said host interface module from said host computer system a host screen of data in response to transmitting said second protocol;
(g) excerpting data from said host screen by said host interface module and producing a third protocol in response to said first protocol;
(h) transmitting said third protocol to said branch bank computer which receives said third protocol; and (i) transmitting a response from said branch bank computer to said remotely located personal computer corresponding to data needed to satisfy said user requests.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US17810794A | 1994-01-06 | 1994-01-06 | |
| US08/178,107 | 1994-01-06 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2180635A1 true CA2180635A1 (en) | 1995-07-13 |
Family
ID=22651226
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2180635 Abandoned CA2180635A1 (en) | 1994-01-06 | 1995-01-06 | Home banking system |
Country Status (6)
| Country | Link |
|---|---|
| EP (1) | EP0739518A4 (en) |
| JP (1) | JPH09507595A (en) |
| AU (1) | AU689202B2 (en) |
| CA (1) | CA2180635A1 (en) |
| NZ (1) | NZ278782A (en) |
| WO (1) | WO1995019010A1 (en) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5696909A (en) * | 1995-01-27 | 1997-12-09 | Hypercom, Inc. | Virtual POS terminal |
| US6006242A (en) * | 1996-04-05 | 1999-12-21 | Bankers Systems, Inc. | Apparatus and method for dynamically creating a document |
| DE29612118U1 (en) * | 1996-07-11 | 1996-09-05 | Esd Information Technology Ent | Arrangement of an integration system for financial services for the integration of bank branches in networks |
| DE19628044A1 (en) * | 1996-07-11 | 1998-01-22 | Esd Information Technology Ent | Arrangement of an integration system and method for managing financial services for integrating bank branches into networks |
| FR2762543B1 (en) * | 1997-04-28 | 1999-07-16 | Investix Sa | PRINTER FOR VOICE SERVER TYPE INFORMATION TRANSFER SYSTEM AND VOICE SERVER SYSTEM COMPRISING SUCH PRINTERS |
| EP1131759A2 (en) * | 1998-11-13 | 2001-09-12 | The Chase Manhattan Bank | System and method for multicurrency and multibank processing over a non-secure network |
| KR100420073B1 (en) * | 2000-05-22 | 2004-02-25 | 주식회사 한국외환은행 | Money exchange system utilizing internet and the method of the same |
| KR20030012065A (en) * | 2001-07-30 | 2003-02-12 | (주)메일캐스터 | Method for proxy execution of on-line real time foreign exchange and remittance service |
| CA2414205C (en) | 2002-10-15 | 2008-10-14 | Electronic Imaging Systems Corporation | System and method for detecting cheque fraud |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4091448A (en) * | 1976-10-29 | 1978-05-23 | Clausing Martin B | Off-line, one-level/on-line, two-level timeshared automated banking system |
| US4734858B1 (en) * | 1983-12-05 | 1997-02-11 | Portel Services Network Inc | Data terminal and system for placing orders |
| US4604686A (en) * | 1984-01-27 | 1986-08-05 | Martin Marietta Corporation | Associative data access method (ADAM) and its means of implementation |
| US4774655A (en) * | 1984-10-24 | 1988-09-27 | Telebase Systems, Inc. | System for retrieving information from a plurality of remote databases having at least two different languages |
| US4747127A (en) * | 1985-12-23 | 1988-05-24 | American Telephone And Telegraph Company, At&T Bell Laboratories | Customer programmable real-time system |
| US4935870A (en) * | 1986-12-15 | 1990-06-19 | Keycom Electronic Publishing | Apparatus for downloading macro programs and executing a downloaded macro program responding to activation of a single key |
| US5109515A (en) * | 1987-09-28 | 1992-04-28 | At&T Bell Laboratories | User and application program transparent resource sharing multiple computer interface architecture with kernel process level transfer of user requested services |
| US5195130A (en) * | 1988-05-05 | 1993-03-16 | Transaction Technology, Inc. | Computer and telephone apparatus with user friendly computer interface and enhanced integrity features |
| US5025373A (en) * | 1988-06-30 | 1991-06-18 | Jml Communications, Inc. | Portable personal-banking system |
| US5339421A (en) * | 1991-03-22 | 1994-08-16 | International Business Machines Corporation | General data stream parser for encoding and decoding data and program interface for same |
| US5361353A (en) * | 1991-10-02 | 1994-11-01 | International Business Machines Corporation | System for parsing message units from an unstructured message stream of interleaved message units to form structured messages |
-
1995
- 1995-01-06 AU AU15227/95A patent/AU689202B2/en not_active Ceased
- 1995-01-06 WO PCT/US1995/000122 patent/WO1995019010A1/en not_active Application Discontinuation
- 1995-01-06 EP EP95906762A patent/EP0739518A4/en not_active Withdrawn
- 1995-01-06 CA CA 2180635 patent/CA2180635A1/en not_active Abandoned
- 1995-01-06 JP JP7518598A patent/JPH09507595A/en active Pending
- 1995-01-06 NZ NZ27878295A patent/NZ278782A/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| AU1522795A (en) | 1995-08-01 |
| EP0739518A1 (en) | 1996-10-30 |
| JPH09507595A (en) | 1997-07-29 |
| MX9602636A (en) | 1998-08-30 |
| NZ278782A (en) | 1997-03-24 |
| WO1995019010A1 (en) | 1995-07-13 |
| EP0739518A4 (en) | 2001-04-25 |
| AU689202B2 (en) | 1998-03-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8543982B2 (en) | Delivering financial services to remote devices | |
| US7908222B2 (en) | Method and system for automatically harmonizing access to a software application program via different access devices | |
| US7672994B2 (en) | Data relay method and information processing method | |
| US20120078794A1 (en) | System and Method for Delivering Financial Services | |
| US5898838A (en) | Editor for developing statements to support i/o operation on open network using segregator for segregating protocol statements from application statements upon verification of correspondence | |
| US20040049458A1 (en) | Payment statement issuing system and charge paying system | |
| US20030033249A1 (en) | System and method for facilitating electronic commerce transactions at an automatic teller machine | |
| WO2004068322A2 (en) | Methods and systems for consolidating financial reporting information | |
| CA2180635A1 (en) | Home banking system | |
| ZA200200813B (en) | Automated transaction execution system with a plurality of user interfaces. | |
| WO2002045034A2 (en) | Transaction execution system and method with user proxy and middleware | |
| WO2001071679A2 (en) | Method and apparatus of customized automated vending machines and vending machine systems | |
| JPH05108689A (en) | Transfer operation processor | |
| MXPA96002636A (en) | Bank system in c | |
| KR100388624B1 (en) | IC card for registered business card | |
| KR20010084922A (en) | System & method for real-time account transfers with firm banking network based on network | |
| JP3973426B2 (en) | Financial terminal system and information processing method for financial terminal | |
| CN111754217A (en) | Payment method and device, storage medium and processor | |
| KR970007696A (en) | Cash card machine that can pay giro payments and giro payment method using the same | |
| CA2414812A1 (en) | Multipersonality automated transaction execution system with macro account | |
| KR20010078829A (en) | Manless credit card authorization method and system allowing joint use by a plurality of stores, and method of inquiring transaction record for each store | |
| JPH08202789A (en) | Account transfer collating system | |
| JP2001076079A (en) | Data processing system and japanese syllabary character input method | |
| KR20010095791A (en) | Method for an account-transfer service in merchant shop | |
| JPS6351762A (en) | Collation system to plural hosts |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead |