WO1998035478A1 - A system, method and article of manufacture for seamless serverapplication support of client terminals and personal automated tellers - Google Patents

Abstract

A plurality of clients are connected to one or more servers (210). These clients (200) include network terminals, and non-network terminals, including personal automated tellers. When a client (200) initiates a connection with a server (210), the server (210) responds to the request for connection by transmitting a message back to the client (200) to determine whether the client (200) is a network terminal or not. The client (200) responds with a message that is received by an application dispatcher at the server (210) which takes one of a pair of actions based on whether the client (200) is a network terminal (200). If the client terminal is a network terminal, then the application dispatcher spawns a server application in the server (210) which responds to the client (200) application in the client (200). Going forward, the server application responds to all future requests from the client application. If the client is not a network terminal, then the application dispatcher initiates a client application in the server to service the client terminal application requirements. If the client is a personal automated teller, the client application is a personal automated teller application. Requests from the client application on behalf of the client terminal are subsequently serviced by a server application at the server which communicates to the client terminal via the client application at the server. A new communication protocol is also defined for processing automated teller transactions.

Description

A SYSTEM, METHOD AND ARTICLE OF MANUFACTURE

FOR SEAMLESS SERVER APPLICATION SUPPORT OF

CLIENT TERMINALS AND PERSONAL AUTOMATED TELLERS

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of co-pending U.S. Patent Application Serial No. 08/692,489 filed August 6, 1996 the disclosure of which is hereby incorporated by reference.

COPYRIGHT NOTIFICATION

Portions of this patent application contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document, or the patent disclosure, as it appears in the Patent and Trademark Office.

Field of the Invention

This invention generally relates to improvements in computer systems, and more particularly, to system software for managing a network of heterogeneous client terminals communicating with a server in a consistent manner.

Background of the Invention

Recently, it has become increasingly fashionable to speak of "intelligent," "smart," or "programmable" terminals and systems. Very few mainframe or peripheral manufacturers omit such a device from their standard product line. Although "intelligence," like beauty or art, is in the eye of the beholder, the adjective generally connotes that the device has a degree of autonomy or processing ability which allows it to perform certain tasks without assistance from the mainframe to which it is connected. Many such devices are programmable by virtue of including a microprocessor.

While operational devices are somewhat hazy and non-standard, a device is referred to as a terminal if a user interacts with the device to communicate to a host processor, referred to as a server in a network computing environment. Examples of terminals include keyboard /printer terminals, cathode-ray tube (CRT) terminals, remote-batch terminals, real-time data- acquisition and control terminals, transaction and point-of-sale terminals, and smart terminals.

A terminal is considered to be intelligent if it contains, hard-, firm-, and or software which allows it to perform alphanumeric or graphic message entry, display buffering, verifying, editing and block transmissions, either on host or human command. If the terminal contains a microprocessor which runs a standard program to service the terminal, and not arbitrary, user-loaded programs, the terminal has a fixed function, and is still just an intelligent terminal. Only when the device contains a general purpose computer which is easily accessible to the ordinary user for offering a wide range of programs selectable by a user or by devices attached to the device does the terminal become a network terminal in accordance with a preferred embodiment.

Sun has recently introduced a new language that is designed to provide consistency for network applications, named Java. Java is a general-purpose, concurrent, class-based, object-oriented programming language and support structure, specifically designed to have as few implementation dependencies as possible. Java allows application developers to write a program once and then be able to run it everywhere on a computer network.

The Java language solves many of the client-side problems by: o enabling dynamic class bindings; o providing enhanced portability of applications; and o providing a secure environment in which applications execute.

Java is compiled into bytecodes in an intermediate form instead of machine code (like C, C++, Fortran, etc.). The bytecodes execute on any machine with a Java bytecode interpreter. Thus, Java applications can run on a variety of client machines, and the bytecodes are compact and designed to transmit efficiently over a network which enhances a preferred embodiment with universal clients and server- centric policies.

With Java, developers can create robust User Interface (UI) components. Custom "widgets" (e.g. real-time stock tickers, animated icons, etc.) can be created, and client-side performance is improved. Unlike HTML, Java supports the notion of client-side validation, offloading appropriate processing onto the client for improved performance. Dynamic, real-time applications can be created using the above- mentioned components. Sun's Java language has emerged as an industry-recognized language for "programming the Internet." Sun defines Java as: "a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language. Java supports programming for the Internet in the form of platform-independent Java applets." Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interactive content" to Web documents (e.g. simple animations, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g. Netscape Navigator) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature states that Java is basically "C++, with extensions from Objective C for more dynamic method resolution".

A network terminal in accordance with a preferred embodiment would execute Java applications in stand-alone mode, but have the capability to interact with a server for such functions as retrieving information, database processing, massive computation processing and access to shared devices such as high-speed printers, plotters and magnetic tapes.

The term "distributed computing" refers both to the devices at remote locations and to the logic which has been used to enhance the intelligence of the devices. Such distributed or decentralized computing with remote intelligent terminals and network terminals is a fact of life in today's computer literate society.

There are a number of drawbacks to distributed computing environments which are not found in a centralized computing environment. First, hardware problems: when a user locates a software solution that is optimal for the user's terminal environment, the software often will not execute on the host processor that is universally accessible by others in a company. Moreover, the software will often be incompatible with other user's terminals.

Second, interfacing problems: a nonstandard terminal might require a special-purpose interface and might not be recognized by the host. Even standard interfaces are notorious for crashing the operating system. In any case, "mixed systems" containing multiple vendor hardware are becoming the norm, but lead to the blame for system problems being placed on the other system, and result in difficult debugging and resolving of system problems.

Third, host operating system support for a heterogeneous terminal environment can be a nightmare. To provide support for all of the various protocols, communication rates and processing demands with the peculiarities intrinsic to a motley crew of downstream terminals is a system administration headache. Fourth, local software support: this type of support ranges from minimal (say, a compiler for the particular terminal) to a mail program that is compatible with every different terminal attached to the host server. Some applications can be rebuilt for a particular terminal by simply recompiling the application, but many are only distributed as runtime modules with no support provided for some terminals.

Summary of the Invention The foregoing problems are overcome in a first illustrative embodiment of the invention in a network computing environment in which a plurality of clients are connected to one or more servers. When a client initiates a connection with a server, the server responds to the request for connection by transmitting a message back to the client to determine whether the client is a network terminal or not. The client responds with a message that is received by an application dispatcher at the server which takes one of a pair of actions based on whether the client is a network terminal. If the client terminal is a network terminal, then the application dispatcher spawns a server application in the server which responds to the client application in the client. Going forward, the server application responds to all future requests from the client application. If the client is not a network terminal, then the application dispatcher initiates a client application in the server to service the client terminal application requirements. Requests from the client application on behalf of the client terminal are subsequently serviced by a server application at the server which communicates to the client terminal via the client application at the server.

In addition, the foregoing problems are overcome in an second illustrative embodiment of the invention in a network computing environment in which a plurality of personal automated tellers are connected to one or more servers. When a personal automated teller initiates a connection with a server, the application dispatcher in the server initiates a personal automated teller application in the server to service the personal automated teller application requirements. Requests from the personal automated teller application on behalf of the client terminal are subsequently serviced by a server application at the server which communicates to the personal automated teller via the personal automated teller application at the server. A new communication protocol is also defined for processing personal automated teller transactions.

Brief Description of the Drawings The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings, in which:

Figure 1 is a block schematic diagram of a computer system for example, a personal computer system on which the inventive object oriented information manager operates;

Figure 2 illustrates a client - server network in accordance with a preferred embodiment; Figure 3 illustrates a server architecture in accordance with a preferred embodiment;

Figure 4 illustrates a client - server architecture in accordance with a preferred embodiment;

Figure 5 illustrates a first client request to a server in accordance with a preferred embodiment;

Figure 6 illustrates a client server environment which accesses support services in accordance with a preferred embodiment;

Figure 7 is an architecture diagram of a client - server system in accordance with a preferred embodiment;

Figure 8 is an architecture diagram of a client - server system in accordance with a preferred embodiment;

Figure 9 is an architecture diagram of a client - server system in accordance with a preferred embodiment;

Figure 10 illustrates the message format utilized in accordance with a preferred embodiment;

Figure 11 presents a table showing additional details associated with the device types, commands and data blocks in accordance with a preferred embodiment; Figure 12 presents additional detail on the message format in accordance with a preferred embodiment;

Figure 13 illustrates the display commands and responses in accordance with a preferred embodiment;

Figure 14 presents the status values associated with various operations in accordance with a preferred embodiment;

Figure 15 is a communication flow diagram in accordance with a preferred embodiment;

Figure 16 illustrates the processing associated with payment access today;

Figure 17 illustrates the processing associated with payment access in the future in accordance with a preferred embodiment;

Figure 18 illustrates a Personal-Automated Teller Machine (P- ATM) in accordance with a preferred embodiment;

Figure 19 illustrates P-ATM processing in accordance with a preferred embodiment;

Figure 20 is a block diagram of the P-ATM in accordance with a preferred embodiment;

Figure 21 is a block diagram of the power-up routines in accordance with a preferred embodiment; Figure 22 is a block diagram of the The ICC session state machines in accordance with a preferred embodiment;

Figure 23 is a block diagram of P-ATM usage with an ICC in accordance with a preferred embodiment; and

Figure 24 is a flow diagram of the internal data flow of the P- ATM.

Detailed Description

The invention is preferably practiced in the context of an operating system resident on a computer such as a SUN, IBM, HP, or a Windows NT computer. A representative hardware environment is depicted in Figure 1, which illustrates a typical hardware configuration of a computer 100 in accordance with the subject invention. The computer 100 is controlled by a central processing unit 102 (which may be a conventional microprocessor) and a number of other units, all interconnected via a system bus 108, are provided to accomplish specific tasks. Although a particular computer may only have some of the units illustrated in Figure 1, or may have additional components not shown, most server computers will include at least the units shown.

Specifically, computer 100 shown in Figure 1 includes a random access memory (RAM) 106 for temporary storage of information, a read only memory (ROM) 104 for permanent storage of the computer's configuration and basic operating commands and an input/output (I/O) adapter 110 for connecting peripheral or network devices such as a disk unit 113 and printer 114 to the bus 108, via cables 115 or peripheral bus 112, respectively. A user interface adapter 116 is also provided for connecting input devices, such as a keyboard 120, and other known interface devices including mice, speakers and microphones to the bus 108. Visual output is provided by a display adapter 118 which connects the bus 108 to a display device 122, such as a video monitor. The computer has resident thereon and is controlled and coordinated by operating system software such as the SUN Solaris, Windows NT or JavaOS operating system.

Figure 2 illustrates a client-server network in accordance with a preferred embodiment. A set of consumer devices (client terminals 200) are attached to a server 210 and the server is attached to a legacy host 220 to process applications requiring information at the host 220. The connection could be by means of the Internet, a dialup link, token ring, cellular phone, satellite, TI or X.25 telco link or other communication means.

Server Software

The sever software is written using a combination of Java, C or possibly C++. C or C++ will be used mainly to implement platform dependent code (such as dealing with the comm ports). While a preferred embodiment discloses support for a dialup network and Internet processing utilizing TCP/IP, one of ordinary skill in the art will readily realize that a token ring, SNA or other network, such as those discussed in US Patents (5,530,961; 5,491,796; 5,457,797; 5,442,791; 5,430,863; 5,394,401; 5,291,597; 5,287,537; 5,287,461; 5,201,049; 4,991,089; and 4,588,211) could be readily interchanged as the network.

Architecture A server architecture in accordance with a preferred embodiment supports two types of client terminals.

Network terminals. These are client terminals capable of directly executing the Java applications on the client terminal which are initially stored on a server. The server will simply download this code to the client's network terminal which the client will then execute to provide a particular service. This service may or may not interact with other clients or servers. Network terminals can be connected to a server through a dialup modem link, directly through a local area network, or by other network communication means in accordance with a preferred embodiment.

Non-network terminals. These are client's terminals which are not capable of executing Java applications on the client terminal. When dealing with this class of client the server will execute the application on behalf of the client. In this case the server will only expect necessary input and output operations to be performed by the client terminal. An example of how to connect a plurality of non-network terminals to a host server is described in US Patent 5,287,461, the disclosure of which is hereby incorporated by reference in its entirety. Figure 3 illustrates a server architecture in accordance with a preferred embodiment. A client 300 would initiate a connection with a server 350 by, for example, dialing in to a modem pool which is intercepted by the point-to-point stack software 311 which conforms information received to the TCP layer 312 which obtains a socket 313 for connecting the client 310 to the server 350. The Java net layer 314 further refines the request to conform with the TERMIO and NET layer 315 which passes the request along to the application dispatcher 319. The application dispatcher 319 spawns the appropriate server application selected from the server applications 330. An application such as "Stored value" refers to digital cash on smartcards. A smartcard is a plastic card containing a microprocessor which is capable of making calculations and storing information such as the amount of electronic cash or stored value that is available. Thus, the smartcard can substitute for money if a vendor has the facilities for processing a smartcard.

On a non-network terminal, The non-network terminal initiates a "first connection" by dialing up a modem, for example. The dialup goes through the native OS 316 (Solaris or Windows NT dialup layer) and is connected with the serial communication in the VFI.SERIAL layer 317 which abstracts the serial input/ output functions into a higher level communication layer. The VFI.NET layer 315 takes the abstracted serial layer and maps it into a similar communication as the communication from the network terminal 300. It makes the dialup asynchronous connection appear to the server application as a new socket connection.

Network Terminal - "First Connection" Figure 4 illustrates a client - server architecture in accordance with a preferred embodiment. The architecture is illustrated initially for a network terminal for clarity and then follows with a non-network terminal. Processing commences at 400 when a network terminal requests connection through a layered communication system to a set of server threads 420 which are triggered by a detection of a "ring" 430 to initiate possible client updates and the subsequent client appplication to server application processing. "Ring" refers to a "first connection" in socket processing in accordance with a preferred embodiment.

The network terminal makes its connection through the Point- to-Point-Protocol stack 411 utilizing the TCP layer 412 and the sockets layer 413, which is like an electrical socket, for attaching terminals to communication sockets to facilitate communication through the network. All of this is managed by the Java.net 414 which connects the socket 1111 via the TCP layer 412 and the PPP stack 411. The layer above is the VFI.net and VFI.TERMIO 415 which is responsible for detecting that the connection is made and mapping the connection to an application dispatcher 431 to further process the first connection (ring) request.

The server 450 waits for a "first connection" request much like an interrupt manager. When a "first connection" request arrives, then the application dispatcher has a method that detects a connect request or a LAN "first connection" request that would arrive through the TCP layer as a socket connect. That connection is translated into a logical ring which is equivalent to an event or interrupt. The server 450 responds to the "first connection" with a query initiated by the application dispatcher 431 requesting "who are you" via an enquiry message asking for identification by the client loader thread 421. The network terminal responds with ID information, including the identification of the application that the network terminal requires. If the terminal answers with an identifier indicating that the terminal is a network terminal, then the client loader thread 421 performs any necessary client application updates via a download using a file transfer program such as User Datagram Protocol (UDP) or the File Transfer Protocol (FTP), or any other socket layer protocols that are available for network file transfers to the network terminal 400. UDP and FTP are simple protocols enabling an application to send individual messages to other applications. Delivery is not guaranteed, and messages need not be delivered in the same order as they were sent. These two protocols are typically used by a client making repeated status inquiries of a server where it doesn't matter if a single response doesn't arrive.

Network Terminal - First Client Request to Server

Figure 5 illustrates a first client request to a server in accordance with a preferred embodiment. When a first client request is transmitted from the network terminal 500 with a client application resident thereon 510 to the server 550, the application dispatcher 530 spawns the corresponding server application 520 for servicing the request at the server 550 via the assigned socket 1112. The server application 520 responds to the request and transmits information to the network terminal 500. The application dispatcher 530 has completed its responsibilities for this client 500 and can return to a wait state until the next "first connection" request from a client. The client application request could be as simple as a get current time request or a request for data from a server database.

Network Terminal - Subsequent Client Request to Server

Figure 6 illustrates a network terminal 600 with a downloaded client application 610 which accesses support services in the server 650 through its assigned server application 620 in accordance with a preferred embodiment. The terminal 600 communicates to a server application 620 which accesses host processing capabilities and database services 640 to service requests emanating from the client application 610. The server application 620 handles any events that originate from the client application 610 via the assigned socket 1112. These events could include data requests from a database application, or data transfer to a server. Remote data from another server application could also be accessed by the client. Server application 620 accesses support services directly or via a socket interface 660.

Non-network Terminal - "First Connection"

Figure 7 is an architecture diagram of a client - server system in accordance with a preferred embodiment. A layered communication system 700 is used by a non-network terminal 710 to detect a ring providing an indicia of communication 740 and dispatch an application 730. Dispatching an application 730 also initiates a server thread 720 for servicing the client request. The non-network terminal 710 initiates a "first connection" by dialing up a modem, for example. The dialup goes through the native OS 711 (Solaris or Windows NT dialup layer) and is connected with the serial communication in the VFI. SERIAL layer 712 which abstracts the serial input/ output functions into a higher level communication layer. The VFI.NET layer 715 takes the abstracted serial layer and maps it into a similar communication as the communication from the network terminal. It makes the dialup asynchronous connection appear to the server application as a new socket connection 1111. The communication is an event 740 that triggers actions by the application dispatcher 741 which responds to the "first connection" event by requesting ID information from the client, via an enquiry message, and starting the requested client application 720 at the server 750.

Non-network Terminal - First Client Request to Server Figure 8 is an architecture diagram of a client - server system in accordance with a preferred embodiment. The client application 822 is responsible for managing the non-network terminal 810. The client application 822 writes information, utilizing a server version of VFI.TERMIO 855, to and responds to key presses by the non-network terminal 810 at the server 850. The client application 822 initially makes a request for service from a socket 1112 that is associated with the non-network terminal 810 when the application dispatcher 840 spawns the client application 822.

When the first request 845 is generated by the client application 822 residing on the server 850, at application startup, the first request for service is routed in the server 850 to the application dispacher 840 and spawns the server application 820 which will handle subsequent requests. The server application 820 makes a request for service from a socket 1112 that is associated with the client application 822 which transmits an appropriate command through the VFI.TERMIO 855 to the VFI. SERIAL layer 856 using the operating system communication support 857 to the non-network terminal 810. This processing is identical to the network terminal processing with the exception that all applications reside on the server 850 as opposed to a Java application executing remotely on the network terminal.

One advantage of Java is that it is machine independent and does not care whether a Java application resides on the client or the server. In the case of the non-network terminal, the client application resides in the server and controls the Java incapable terminal.

Non-network Terminal - Subsequent Client Requests to

Server

Figure 9 is an architecture diagram of a client - server system in accordance with a preferred embodiment. A layered communication system 900 is used by a non-network terminal 910 to manage the interconnection of a server application 940 to a client application 920 and facilitate communication between the terminal 910 and server application 940 via a client application 920 resident on the server 950. Figure 9 shows the processing after the first request has been completed and the client application 920 is coupled with the server application 940 via the assigned socket 1112 just as in the network terminal example, except the client application 920 and server application 940 both reside on the server 950.

If a terminal responds with a message that indicates it is a non- network terminal, then the terminal is supported with the command streams described in Figures 10-14. If the terminal is a network terminal, then the application is downloaded via a FTP or other network file transfer procedure.

Figure 10 illustrates the structure of a packet in accordance with a preferred embodiment. Figure 11 shows the format of each field of a communication and describes the contents of the same. For example, the header is two bytes in length and has various values that correspond to different types of transactions. Similarly, the Packet Type, Header CRC, Sequence #, Data Block and CRC- 16 fields are described in the table set forth in Figure 11.

Figure 12 represents a table showing additional details associated with the device types, commands and data parameters. For example, the device type field is one byte long and specifies the selected Input/ Output device. Figure 13 illustrates the display commands in accordance with a preferred embodiment. The display's device type is zero. Figure 14 presents the status values associated with various requested operations in accordance with a preferred embodiment.

Figure 15 is a communication flow diagram in accordance with a preferred embodiment. A terminal 1500 either has firmware or an application 1504 that initiates a connection 1506 with a server 1502 by contacting a dispatcher 1508. The connect initiate 1506 also connects a socket 1111 to handle the connection. The dispatcher 1508 transmits an identification enquiry 1510 which the client terminal replies to with an identification message 1512. In the case of a network terminal, the client loader 1522 performs any necessary client application updates 1520 on the client terminal 1500. In the case of a non-network terminal, the dispatcher starts the client application. The client then sends a request to start the server application 1530 to the server which results in the connection of a socket 1112 and the server application 1550 being started and a confirmation message 1532 being transmitted back to the client application 1540. Then, when the client application 1540 requests data 1542 from the server application 1550, the server application 1550 responds with the application response data 1560.

Application Dispatcher - Control Flow Application Dispatcher startup

Configured modem ports that will take part in transactions are pre-configured. The Application Dispatcher (AD) startup code looks at this configuration stream to determine the number of S threads (serial port listeners) . S classes instantiate a VFI.NET.serversocket object which in turn create a VFI.NET.ModemlO.ModemPort object. The ModemPort object binds to a low level VFI. NET. ModemlO. Port object which utilizes native methods to configure and wait on the communications port.

SO { serversocket SO Socket = new serversocket ("socket 1 111", i);

// Listener object

{ socket SOConnSocket= SOSocket.accept();

/ / Translates to

WaitDevice(CONNECT)

ReadAndValidate (RequestID); return RequestID, SOConnSocket; }

}

Request Processing

As illustrated above, S threads are. transient threads. And even when alive they perform efficient waits (No CPU cycles are consumed). The AD receives the RequestID from each S thread.

Request processing is performed by database lookup. Typically

Requests, are simple text messages with delimiters and are parsed using a StringTokenizer object. StringTokenizer stParseHelp = new StringTokenizer ((String) Request);

field 1 = stParseHelp. nextTokenQ; field2 = .... and so on.

The AD will query a database to determine which applications should be initiated based on the enquiry message utilizing an SQL query of the form: "SELECT <Field ClassPath> from <TableName> where <fl = field 1 >;

is handled by the JDBC layers to return data to the AD. The AD is now ready to run the client thread.

ClientThread = new Thread (field 1, field2... , SOConnSocket);

The field list contains appropriate fields (those required for client application processing) and are passed down to the client thread along with the connected socket object.

Client Threads

Client Threads proxy the actual application. Application output meant for the terminal's devices are routed out using VFI.TERMIO as directives to the client terminal's firmware. The connected socket (which translates to a live dialup connection) is passed down from the AD to the client thread. Client threads are long living - usually transferring data to corresponding servlets that initiate connections to upstream hosts or make database transactions. Despite the fact that client threads can be JDBC aware, servlets handle database transactions. This helps to maintain code constancy when the same client class is downloaded to a Java capable terminal for remote execution.

Terminal I/O is performed through a VFI.TermlO object that in turn instantiates a VFI.TermlO. ServProtocol object. The protocol object implements the actual data transfer with the client terminal. The protocol object requires the socket object passed down from the AD to the client thread.

CO (Appropriate Request fields, SOConnSocket)

{

VFI.TermlO IOObject = new TermlO (SOConnSocket); //IO object instantiation. This cascades into a

/ /ServProtocol Object instantiation.

IOObject. WriteString (Stringlndex) ;

/ /Displays a particular string on the P-ATM. / /If the client needs to retrieve data from upstream hosts

(OmniHost, //VISA etc), or needs data from a database it makes a TCP stream //connection to a servlet.

/ /This is consistent with the behavior of the network terminal which / / would make the same connection over PPP. clienTransObject = new Socket (<Host>, <Well known socket>);

/ / Explained further down under initial client requests //Further processing

/ / Send out host requests clienTransObject.write (HostRequest); clienTransObject.read (HostResponse);

IOObject.WriteString (Stringlndex + n); //Displays status on the P-ATM.

}

Initial Client Request processing

The AD runs a T thread (spawned off during startup) that listens on a well-known socket (e.g. 1112) waiting for initial ClientRequests from a client application. The T thread processes the ClientRequest to determine which servlet class needs loading.

T

{

ClientlnitialRequestListener = new ServerSocket (<wellknown port>);

/ / Wait for initial requests and spawn off server connSocket = ClientlnitialRequestListener. accept(); connSocket.Stream.read (InitialRequest);

Parse (InitialRequest); HostThread HO = new Thread (connSocket, "class name");

}

The T thread is a daemon thread and lives as long as the AD lives. When the client application is downloaded to a Java capable terminal initial requests arrive over the PPP link. Control Flow Client applet

The client threads proxy the actual application for the P-ATM. Application output meant for the terminal's devices are routed out as directives to the P-ATM's firmware. The connected socket (which translates to a live dialup connection) is passed down from the CD to the client thread. Client threads are long living - usually transferring data to corresponding servelets that initiate connections to upstream hosts or make database transactions. Servelets refer to Java code sent to a server for execution. Despite the fact that client threads can be JDBC aware, servelets handle database transactions, which helps to maintain code constancy when the same client class is downloaded to a Java capable terminal for remote execution.

Terminal I/O is performed through a vfi.termio object that in turn instantiates a vfi.termio. ServProtocol object. The protocol object implements the actual data transfer with the P-ATM. The protocol object requires the socket object passed down from the CD to the client thread.

CO (Appropriate Request fields, SOConnSocket)

{ vfi.TermlO IOObject = new TermlO (SOConnSocket);

//IO object

//instantiation. This cascades into a ServProtocol Object instantiation.

IOObject.WriteString (Stringlndex); //Displays a particular string on the P-ATM. //If the client needs to retrieve data from upstream / /or needs data from a database, a TCP stream connection to //a servlet is enabled. / /This is consistent with the behavior of the //Java capable terminal which would //make the same connection over PPP. clienTransObject = new Socket (<Host>, <Well known port>); // Send out host requests clienTransObject. write (HostRequest) ; clienTransObject.read (HostResponse);

IOObject.WriteString (Stringlndex + n); / /Displays status on the P-ATM. }

Host Threads (H) service client requests for upstream and database connectivity. A host thread can make TCP connections with remote hosts, forward financial transactions originating from the client application and route the response.

HO (connSocket)

{ connSocket.Stream.read (ClientRequest); ParseRequest (StringTokenizer);

Socket upstreamSock = new Socket (upstreamHost, Port); / /Transact connSocket. Stream. Write (HostResponse) ; } Transient and Long-living Threads in the Application Dispatcher

In a sockets based abstraction of the Win32 Communication, in accordance with a preferred embodiment, the Personal

Transaction System (PTS) server provides an uniform interface to third party client component and server component applet writers to the async dialup protocol module and the system's TCP/SLIP/PPP stack. This interface comprises a set of Java Classes collectively called VFI.NET.*. It should be noted that this package does not provide pure TCP/UDP/IP specific objects and methods that are already defined and implemented in java.net.*. PTS refers to a complete end-to-end transaction system spanning the consumer located device to the server software. Internet Protocol (IP) refers to the TCL/IP layer 3 protocol responsible for transporting datagrams across an internet/ intranet. Point-to-Point Protocol (PPP) refers to a protocol for data transfer across serial links. PPP supports extensive link configuration capabilities, and allows traffic for several protocols to be multiplexed across the link.

Programmers do not need to explicitly import java.net.*. This is automatically done by a preferred embodiment. Further, this document does not discuss the functionality ofjava.net.* which may be found in the appropriate JDK documentation. It, merely, details a class design that overloads methods specifically necessary to build a Berkley Socket Distribution (BSD) socket like layer between calling applets (servlets) and the machine specific Java serial communications package. BSD refers to the original UNIX software created to specify how programs would use sockets as a means of communicating between applications using Transmission Control Protocol (TCP) /IP. The TCP/IP protocol provides reliable, connection- oriented data transmission between a pair of applications.

Hierarchy

A uniform upper edge interface for the ModemlO classes permits easy replacement of the implementation. The actual modem handling code, for instance, may use the Telephony Application Programmers Interface (TAPI) client calls instead of direct Win32 communication calls. TAPI refers to a Microsoft Windows API which specifies functionality for interfacing the Windows operating system with telephony software and hardware. Multiple libraries that conform to the same interface allow different link level protocol stacks (like MNP3). This helps to ensure the constancy (and hence direct portability) of VFI.ModemlOΛ

Required ModemlO Functionality

1. Open an end-to-end async, duplex dialup connection. The station address (InetAddress as in TCP/IP) is the dial string. Configure upon connection.

2. Listen for an incoming dialup connection. The listen port (analogous to the bound TCP port) is the COM port. In this regard the valid port numbers range from 0 - OxFF (which is the maximum number of COM ports allowed in NT). Configure upon initialization. 3. Obtain Input and Output streams that re-direct from/ to the open connection.

4. Hang-up (close as in TCP/IP) a live connection.

The following classes form a part of VFI. ModemlO.* :

Raw Serial Port Handling public class VFI. ModemlO. Port {

//Contructors public Port (int nPortNum); public Port (int nPortNum, int nBaud, int nParity, int nDataBits, int nStopBits); public Port (int nPortNum, String sCfgStr); public Port (String sPortName); public Port (String sPortName, String sCfgStr);

//Methods public void close(); public int getPortID(); public String getPortName(); public String getCfgStr(); public InputStream getInputStream(); public OutputStream getOutputStream();

}

Modem initialization and methods public class VFI. ModemlO. ModemPort {

//Constructors public ModemPort (int nPortNum); public ModemPort (Port objPort); public ModemPort (String sPortName); public ModemPort (int nPortNum, String slnitString); public ModemPort (Port objPort, String slnitString); public ModemPort (String sPortName, String slnitString);

/ /Methods public Port getPort(); public boolean connect (String sDialString); public void disconnect); public void reset(); public boolean configure (String sCfgStr); public boolean configureDM (String sCfgStr);

}

Programmers must use getPort() to capture a stream and transfer data over the ModemPort. Configure(String) sends out an AT command and returns TRUE if the modem returned OK<cr><lf>. configureDM(String) sends out the same command to the modem when in data mode.

NET - The Sockets wrapper

The package encapsulates two major classes found in java.net.* - Socket and ServerSocket. To present a familiar interface and yet avoid conflicts, the package instantiates its own socket and serversocket objects via constructors that take an extra parameter (that identifies the lower object that needs to be instantiated). This is illustrated after the class definition.

Station address resolution The InetAddress object refers to an unique long value that corresponds to the machines TCP/IP address. The async dialup line may however use multiple COM ports to open a connection with the host. Heuristically, it may seem that fitting the TCP/IP host/ machine address into the native COM support library will permit overloading of InetAddress and hence enhance elegance. This, however, results in extra and avoidable complexity. In this regard, InetAddress will still correspond only to a TCP/IP address. The versions of the java.net. Socket constructor that accept the host name (as a String) will, instead, be overloaded. This value will now refer to a dial String that identifies the remote station address.

Socket initialization and connection public class VFI. NET. socket {

/ / Constructors public socket (String sHost, int nPort, int nProtocolType); /* nProtocolType may take one of two values : PF NET #defined to 1 PF_VFI_PTS_MODEMIO #defined to 2

Passing a value of 0 causes the use of java.net. Socket.*/

//Methods public void close(); public String getStationAddress(); public int getPort(); public InputStream getInputStream(); public OutputStream getOutputStream();

}

public class VFI. NET. serversocket

{ //Constructors public serversocket(int nPort, int nProtocolType);

/* nProtocolType may take one of two values :

PFJNET #defined to 1

PF_VFI_PTS_MODEMIO #defined to 2 Passing a value of 0 causes the use of java.net.ServerSocket.*/

/ /Methods public socket accept(); public void close(); public int getPort(); }

Interface Library to native Win32 Comm. API methods HANDLE OpenDevice (int nDevNum, DCB * pNewDCB); void CloseDevice (HANDLE hDevice); int WriteDevice (HANDLE hDev, int nBytesTo Write, unsigned char * pWriteBuf); int ReadDevice (HANDLE hDev, int nBytesToRead, unsigned char * pReadBuf);

BOOL ConfigureDevice (HANDLE hDev, DCB * pNewDCB);

Figure 16 illustrates the processing associated with payment access today. A consumer 1600 walks into a store with a credit card 1610 and presents it to the store controller 1620 (checkout stand) which dials a number to access a financial network 1630 to connect to a financial host 1640 and verify that the consumer is authorized to make the purchases on the credit card. Conspicuously absent from the processing is any capability to process payments from home or anywhere a store controller is available.

Figure 17 illustrates the processing associated with payment access in the future in accordance with a preferred embodiment. A consumer 1700 utilizes credit cards, smart cards or checks 1710 to access a financial host 1750 to verify purchasing power via network software (internet, financial or cable TV) 1740 at a merchant location 1730 utilizing a store controller, or a home, office or other location utilizing a settop box, P-ATM or cellular phone 1720. This approach gives a consumer many more degrees of freedom then previously available.

Personal Automated Teller Machine (P-ATM) Description

The P-ATM is a low cost Java incapable consumer terminal which interacts with the VeriFone Server. An illustration of the P-ATM is provided in Figure 18. The standard features of the P- ATM are: 16 -character 5x7 LCD

16 -key keypad

1200 - 2400 bps modem or Payport for a PC

2 RJ- 11 phone connectors

Optional micro-Security Access Module (uSAM) containing encryption based algorithm to authenticate the integrity of the messages to/from the Server

• ICC (Integrated Chip Card a.k.a. "smart card") interface . Masked ROM: 32K bytes • Volatile RAM: 8K bytes (pin compatible expansion capability up to 32K bytes)

• Flash: 2K byte (pin compatible expansion capability up to 8K bytes). This memory is for storing system parameters, phone numbers and display prompts.

Because the P-ATM is a consumer device to be used outside of the merchant environment, physical security is not required in the processing of a personal password.

Figure 19 illustrates P-ATM processing in accordance with a preferred embodiment. Processing commences when a smart card 1900 is inserted into a P-ATM 1910. If the P-ATM has the optional SAM security, the card is authenticated via a password or digital signature that is verified at the server 1930. The P- ATM 1910 communicates to the server 1930 via a concentrator 1920 that connects the modem (telephone connection) from the P-ATM 1910 to an X.25 or Internet connection. The Server 1920 communicates to the host 1940 via an X.25 or Internet connection. Security of operations between the smartcard 1900 and the financial host 1940 is achieved utilizing the keys of the card and the software at the financial host 1940. Figure 20 is a block diagram of the P-ATM in accordance with a preferred embodiment. The various blocks are described below with reference to Figure 20.

Display

A display in accordance with a preferred embodiment utilizes a 16-character 5x7 LCD. There is no provision for back-lighting, and the display has its own controller for display refresh. The display supports English and international characters.

The P-ATM shall be able to:

• display specified text strings • display preset prompts from non-volatile memory

• echo data during user input

Keypad

The P-ATM shall use a 16-key keypad. A key press will generate an interrupt which initiates a row/ column key scan. Simultaneous multiple key presses will not be detected.

The keypad shall have the following keys: 0 - 9, *, #, ON, CLEAR, BACKSPACE, HELP, and ENTER. An ON button is provided to power/ reset the P-ATM. The keypad layout is shown below:

The operation of the rightmost keys is as follows:

Clear / No - Clear all data on current input or signal a 'No' response to a question.

Backspace - Delete the last entered character and update display to reflect this.

Help - Signal the server that the user wishes additional help.

Enter / Yes - Accept data or signal a "Yes" response to a question.

Instant feedback should always be provided for user entered data. This means that the P-ATM shall be capable of handling typical data inputs, terminated by the ENTER key, without requiring further commands from the server application after each numeric key press. Also, an acknowledgment of the terminating or control keys is provided.

The input modes of the keypad are: Raw mode (per key press)

Edit mode, terminated by the ENTER or Cancel key local echo numeric key presses secure echo numeric key presses numeric key lockout Chip Card Support

The P-ATM shall only support chips cards adhering to the following requirements:

1. 5 volt cards only.

2. Asynchronous cards which are ISO 7816-3 compliant:

• T=0. Half duplex character transmission protocol.

• T= 1. Half duplex block transmission protocol.

Modem

The P-ATM shall include a 1200 - 2400 bps modem, for the U.S. and international. The modem is not required to support the Fast Connect protocol.

• It is an outgoing modem only, no answering required. • The modem shall be configured for 8 data bits, no parity, and 1 stop bit.

• Supported protocols are: Bell 212A, and Bell 103, V.22 bis, V.22, and V.21.

• The modem shall check the non-volatile memory for modem parameters.

• The countries supported are: United States, Hong Kong, Spain and Sweden.

Non-volatile Memory Table The non-volatile memory contains a table to be used to store the following:

• System Parameters such as Terminal ID, Modem Control Parameters, Telephone Numbers. • Default Prompts, fixed by language. Default prompts in ROM shall be used if it does not exist in the non-volatile memory.

• Factory loaded code for functions such as Balance Inquiry and Network Logons. • Application Prompts, may be stored in the remaining unused area of the Non-volatile Memory Table.

The P-ATM shall be able to store text strings to the nonvolatile memory. Each table entry has a 30 byte maximum.

Volatile Memory Table

A table in volatile memory is provided for server application use. This table, to hold transient data, is initialized to be empty at power up.

Micro Security Access Module (uSAM, Optional)

A uSAM contains an encryption based mechanism to verify the integrity of the messages sent to and from the server. The interface to the uSAM is identical to that of the ICC. See section 5 for more details.

P-ATM Firmware Architecture .

The P-ATM is a single tasking state machine driven terminal. The P-ATM firmware can be broken down to three groups: power-up routines, ICC session state machine, and command/ device drivers. Figure 21 is a block diagram of the power-up routines in accordance with a preferred embodiment. These routines include a Diagnostics, Initialization, System, Factory Setup and Smart Card logic in accordance with a preferred embodiment.

Figure 22 is a block diagram of the The ICC session state machines in accordance with a preferred embodiment. These routines include the Server network connect routine, various communication primitive routines, decryption routine and an encryption routine in accordance with a preferred embodiment.

Figure 23 is a block diagram of P-ATM usage with an ICC in accordance with a preferred embodiment. Processing commences at function block 2300 where an Integrated Chip Card (ICC), in other words a smart card, is inserted. Then at 2310 the Answer To Reset (ATR) is processed. This refers to the response from the ICC to a reset being processed. Next, at 2320, the connection to the server is established, and the authentication of the P-ATM is performed. Then, at function block 2330, the application is selected from the server, at function block 2340, the transaction is processed and upon completion of the transaction, the session with the server is disconnected as shown at function block 2350. Once the server session is disconnected, then the card can be removed as shown at function block 2360.

Communication

The P-ATM communicates with the Server through the internal modem using a messaging protocol. The information exchanged between the P-ATM and the Server shall be in the general format outlined the sections that follow.

General Protocol Overview Protocol Sequencing

The Server software initiates all operations. The P-ATM waits for a Command Packet, performs the requested command(s), and issues a Response Packet indicating the outcome of the command operation(s) . For every Command Packet there is one Response Packet.

Server P-ATM

Command Packet

<r ACK Packet

End Packet -

<r Response

Packet

ACK Packet ^

<r End Packet

Packet Resend

The Command or Response Packet is resent if:

• a NAK packet is received, or

• an ACK packet is not received within a time-out period (implied NAK). The ACK Packet is resent if the End Packet is not received within a timeout period.

The resending of the Command/ Response packet is performed until a retry count is met. After the retries have been exhausted to get an ACK for the Response packet, the P-ATM shall enter the state waiting for a Command packet to re-synchronize with the server. Only the server shall be capable of terminating a session.

Command to Response Time The turnaround time for producing a Response packet after receipt of a Command Packet is command dependent, controlled by the server application. If the Response packet is not sent during this period, the server may deem that communication is lost and terminate the session. Adjustments must be made when waiting for a user input.

Command and Response Packets Figure 24 is a flow diagram of the internal data flow of the P- ATM. As the server receives a command packet from a modem, the uSAM authenticates the command packet (if a uSAM is installed) the command message is processed with requests for information transmitted to the smart card and a completion message is displayed. At the P-ATM, a process response message is received and processed and a sign response message is created if an optional uSAM is installed, and the response is transmitted via a modem to the server. The structure of each packet is:

ACK/ NAK Packet

Header Packet Header Data Block CRC-16

Type/ CRC

Byte Count

Co- nmand or Response Message Packet

where:

Command and Response Message Formats

The Command Messages make up the Command Message chain and are sent from the Server to the P-ATM, categorized by a single character Command identifier.

where:

The commands to the P-ATM comprise: (D) Display Command, (T) Ticker-tape Display Command, (S) Store Command, (Q) Query Command, (W) "Who are you?" Command, (K) Keypad Input Command, (M) Menu Command and (I) ICC Command.

The Command is echoed back in the Response Message, followed by a return status and the requested data, if any.

The notations in the command descriptions are as follows (Any character not enclosed in these is its literal value):

<x> indicates a single byte binary number, shown base 10.

[x] indicates a 2 byte binary number. MSB followed by LSB.

{x} indicates variable length data which consists of a two-byte Data Reference, followed by the actual data, if appropriate. The Data Reference uses the most significant nibble of the MSB as a table identification:

An empty string consists of a single byte whose value is zero. If the data is stored in a table then the first byte of the table entry is its length.

Examples (shown in hex format): [0005]HELLO Indicates a literal string of data. [1005] References the data in Volatile Table[5] .

[2005] References the data in Non-volatile

Table[5].

Display Command Command ID: D Parameters: <χxy>{data}

Description: The display commands is used to display messages on the terminal display. The message may be the text specified in the parameter or an entry in the Table store. The command parameters are generalized for future capabilities, and all displays start from the leftmost column of the single line display.

The P-ATM only has one row on the terminal display, and will ignore all row parameters. The maximum allowable display size is currently 16. Display strings less than the maximum size will be padded with spaces to the right. Display strings larger that the maximum size will be truncated to the maximum allowable display size.

Ticker-tape Display Command Command ID: T

Parameters: <x><y><shiβ rate><pause>{data}

Description: The ticker-tape display command is used to display messages on the terminal display. The message may be the text specified in the parameter or an entry in the Table store. The text appears one character at a time moving from right to left.

Store Command

Command ID: S

Parameters: [n]{dαta}

Description: The S command is used to store a literal data string in the Volatile and Non-volatile Tables, or move data from one table to another.

{data} Source data. Please note that if data references a table entry then this command simply places a copy of the existing data into the specified location.

Query Command Command ID: Q Parameters: [n]

Description: The query command is used to retrieve data from the Table store.

Param Description s

[n] Get the contents of the specified table and index entry, in the form of Reference Data.

Keypad Input Command Command ID: K

Parameters: <x><y><time- out><min><options>[r]{DS}{FS}{PS}

Description: The K command is used to get user data entry from the keypad.

* = Entered character must be * or #

1..9 = Entered character must be between 1 and 9

{PS} Prompt string: data which is displayed until first key is pressed.

The keypad commands are used to get data entry, and affect the display and cursor positioning.

During key input, if the user presses the CLEAR key, the initial display string is redisplayed and all user input is discarded. Pressing the BACKSPACE key discards the last key press and redisplays the corresponding display string entry.

Menu Command

Command ID: M

Parameters: <χ^χy><time-out><count>{C 1}{C2}...{Cn}{PS}

Description: The M command is used to present a menu of choices to the user. The prompt string is optional and will disappear when the user presses any key. The PATM will append one or both of the characters '<' or '>' to each choice to indicate if the user may move right or left (see the keypad layout in section 2.2). For example, assuming the three choices are:

RELOAD, LOTTERY, and STOCK; then each would occupy the full 16 character display and appear as:

I Display Position 1 1234567890123456 1 I RELOAD First display i < LOTTERY Appears if user presses > key I < STOCK Appears if user presses > key again

The selected display choice (choice number) is returned when the user presses the ENTER key.

ICC Command Command ID: I Parameters: C, W, O, P, or X

Description: The I command is used to control and access the ICC (smart card).

Perform a cold reset to the ICC and return ATR data.

W Perform a warm reset to the ICC and return the ATR data.

P[r]<rxlen> {data} Perform the Protocol Type Selection (PTS) exchange.

[r] is the Reference Data for received data. <rxlen> is the length of data to receive.

Required as Reference Data may specify table and offset. data is the PTS data to transmit.

O Power off the ICC.

X[r]<rxlen/NAD>{dαtαI}{dα Data exchange with the ICC. ta2} [r] is the Reference Data for received data.

Status bytes SW1 and SW2 shall always be returned to the server, and will not be stored in the table. <rxlen/NAD> is the length of data to receive, excluding status bytes SW1 and

SW2. datal is the data to transmit to the ICC, starting with the 4-byte [CLA INS PI P2] header. data2 is an optional field, in case the body of the transmit data is contained in a table. From analyzing the ATR, the P-ATM shall determine whether the ICC is compatible with the P-ATM. The P-ATM shall only support ICCs with the following parameter values:

■ Protocol type T=0 or T= 1 only. ■ Clock rate conversion factor Fi = 372.

■ Bit rate adjustment factor Di = 1.

■ Programming voltage VPP = 5V.

■ Maximum programming current factor I = 50.

ICCs that deviate from the above parameters are deemed incompatible with the P-ATM, and shall be rejected.

From the ATR, the P-ATM also determines:

■ protocol type (T=0 or T= 1) ■ extra guardtime

■ EDC method (LRC or CRC) (T= l protocol)

■ Information Field size for the card (IFSC, T= 1 protocol)

■ Character Waiting Time (CWT, T= 1 protocol)

■ Block Waiting Time (BWT, T= 1 protocol)

Data Exchange for T=0 protocol Command: IX[r]<rxlen>{data}

1. The <rxlen> field shall convey the length of bytes to receive from the ICC, excluding the SW1 and SW2 status bytes. Thus for a command only or a command to store data to the

ICC, <rxlen> shall be 0.

2. The first 5 bytes of transmit data shall be the header in the from [CLA INS PI P2 P3]. The P-ATM will transmit the header and await the procedure bytes from the ICC. Data Exchange for T= 1 protocol

Command: IX[r]<NAD>{data}

1. The server shall send only I-block data transfers to the ICC. 2. Thus the data field contains the Information Field data.

3. The P-ATM shall perform data link layer services:

■ assemble the block component using the specified NAD and INF data.

■ handle message chaining. ■ generate and validate parity.

■ handle R-block and S-block messaging.

■ perform error handling protocol.

4. The P-ATM shall inspect the received LEN byte in the prologue field for length of message to receive.

"Who are you?" Command

Command ID: W

Parameters: None

Description: The "Who are you?" command is issued to retrieve identification data from the P-ATM.

The P-ATM shall return the following information: P-ATM serial number Modem country code • LCD country code

Product Version Number Firmware Version Number Display prompt set Answer to Reset from the ICC Security

Security between the smart card and the ultimate host is provided by the smart card's security and the corresponding SAM resident on that host. Additional security measures are available to verify the identity of the sender and the authenticity of the data passing between the P-ATM and the server.

While the invention is described in terms of preferred embodiments in a specific system environment, those skilled in the art will recognize that the invention can be practiced, with modification, in other and different hardware and software environments within the spirit and scope of the appended claims.

Claims

Having thus described our invention, what we claim as new, and desire to secure by Letters Patent is:

1. A distributed computer system including a client terminal and a server which communicate via a network, comprising: (a) the client terminal initiating a connection to the server utilizing the network; (b) the server responding to the connection initiation by transmitting an enquiry message to the client terminal; (c) the client terminal responding to the enquiry message with a message comprising identification information indicative of the client terminal being a network terminal or a non-network terminal and identifying a client application that the client terminal requires; (d) the server receiving and analyzing the identification information to determine if the client terminal is a network terminal or a non-network terminal; and (d l) if the client terminal is a network terminal, then a client loader on the server updates the client application, if necessary, on the client terminal utilizing the network and starts a server application to service future requests from the client terminal; and (d2) if the client terminal is a non-network terminal, then the server initiates the client application and the server application on the server for processing the client application at the server for the client terminal.

2. The distributed computer system as recited in claim 1 , wherein the update of the client application entails a download of the client application to the client terminal.

3. The distributed computer system as recited in claim 1 , in which the client terminal communicates to the server utilizing a dial-up network connection.

4. The distributed computer system as recited in claim 1, wherein the identification information further comprises configuration characteristics of the client terminal.

5. The distributed computer system as recited in claim 1 , wherein the client terminal executes Java code on the client terminal if the client terminal is a network terminal.

6. The distributed computer system as recited in claim 1 , wherein the same client application is executed on the server and the client terminal.

7. The distributed computer system as recited in claim 1, wherein the client terminal receives commands from the client application on the server if the client terminal is a non-network terminal.

8. The distributed computer system as recited in claim 1 , including means for passing a client application request to another server to process the client application request.

9. A method for distributing computing between a server and a client terminal which communicate via a network, comprising the steps of: (a) initiating a connection of the client terminal to the server utilizing the network; (b) responding to the connection initiation at the server by transmitting an enquiry message to the client terminal; (c) responding to the enquiry message at the client terminal with a message comprising identification information indicative of the client terminal being a network terminal or a non-network terminal and identifying a client application that the client terminal requires; (d) receiving and analyzing the identification information at the server to determine if the client terminal is a network terminal or a non-network terminal; and (d l) loading a server application if the client terminal is a network terminal, which starts the client application and services future requests from the client terminal; and (d2) loading a server application on the server, if necessary, which initiates a client application on the server for processing the client application at the server on behalf of the client terminal, if the client terminal is a non-network terminal.

10. The method as recited in claim 9, wherein the update of the client application entails a download of the client application to the client terminal.

1 1. The method as recited in claim 9, including the step of communicating between the client terminal and the server utilizes a dial-up network connection.

12. The method as recited in claim 9, wherein the identification information further comprises configuration characteristics of the client terminal.

13. The method as recited in claim 9, wherein the client terminal executes Java code on the client terminal if the client terminal is a network terminal.

14. The method as recited in claim 9, wherein the same client application is executed on the server and the client terminal.

15. The method as recited in claim 9, wherein the client terminal receives commands from the client application on the server if the client terminal is a non-network terminal.

16. The method as recited in claim 9, including the step of passing a client application request to another server to process the request.

17. A computer program embodied on a computer-readable medium for enabling a distributed computing system, including a client terminal and a server which communicate via a network, comprising: (a) a code segment for initiating a connection of the client terminal to the server utilizing the network; (b) a code segment for responding to the connection initiation at the server by transmitting an enquiry message to the client terminal; (c) a code segment for responding to the enquiry message at the client terminal with a message comprising identification information indicative of the client terminal being a network terminal or a non-network terminal and identifying a client application that the client terminal requires; and (d) a code segment for receiving and analyzing the identification information at the server to determine if the client terminal is a network terminal or a non-network terminal; and (dl) a code segment for loading a server application if the client terminal is a network terminal, which updates the client application and services future requests from the client terminal; and (d2) a code segment for loading a server application, if necessary, on the server which initiates the client application on the server for processing the client application at the server on behalf of the client terminal, if the client terminal is a non-network terminal.

18. The computer program as recited in claim 17, wherein the update of the client application entails a download of the client application to the client terminal.

19. The computer program as recited in claim 17, including a code segment for communicating between the client terminal and the server utilizing a dial-up network connection.

20. The computer program as recited in claim 17, wherein the identification information further comprises configuration characteristics of the client terminal.

21. The computer program as recited in claim 17, wherein the client terminal executes Java code on the client terminal if the client terminal is a network terminal.

22. The computer program as recited in claim 17, wherein the same client application is executed on the server and the client terminal.

23. The computer program as recited in claim 17, wherein the client terminal receives commands from the client application on the server if the client terminal is a non-network terminal.

24. The computer program as recited in claim 17, including a code segment for passing a client application request to another server to process the request.

25. The computer program as recited in claim 17, including a code segment for making a dial up connection appear to the server as a socket connection.

26. A computer system including a personal automated teller, comprising a memory and a keypad, and a server which communicate via a network, comprising: (a) the personal automated teller initiating a connection to the server utilizing the network; and (b) the server initiating a personal automated teller application on the server that processes personal automated teller transactions.

27. The computer system as recited in claim 26, wherein the personal automated teller application includes a display command to display messages on the personal automated teller.

28. The computer system as recited in claim 26, wherein the personal automated teller application includes a ticker-tape display command to display messages on the personal automated teller which include a time period that must elapse before shifting the message one character.

29. The computer system as recited in claim 26, wherein the personal automated teller application includes a store command to store information in a memory of the personal automated teller.

30. The computer system as recited in claim 26, wherein the personal automated teller application includes a query command that retrieves data from the memory of the personal automated teller.

31. The computer system as recited in claim 26, wherein the personal automated teller application includes a keypad input command that retrieves data entered from the keypad of the personal automated teller.

32. The computer system as recited in claim 26, wherein the personal automated teller application includes a menu command used to present a menu of choices on the personal automated teller.

33. The computer system as recited in claim 26, including a command to manage smartcard transactions utilizing the personal automated teller.

34. The computer system as recited in claim 26, including an identification command to retrieve identity information from the personal automated teller.

35. The computer system as recited in claim 26, wherein information transmitted over the network between the personal automated teller and the server comprises a header, a type and a checksum field.

36. A method for supporting a personal automated teller which communicates via a network to a server, comprising the steps of: (a) initiating a connection of the personal automated teller to the server utilizing the network; and (b) responding to the connection initiation at the server by loading a personal automated teller application at the server for servicing the personal automated terminal.

37. The method as recited in claim 36, wherein the personal automated teller application includes support for smartcard processing utilizing the personal automated terminal.

1 38. A computer program embodied on a computer-readable medium

2 for enabling a personal automated teller and a server which

3 communicate via a network, comprising:

4 (a) a personal automated teller code segment that initiates a

5 connection to the server utilizing the network; and

6 (b) a server code segment that initiates a personal automated teller

7 application on the server for processing the personal automated teller

8 application at the server for the personal automated teller.

9 39. The computer program embodied on a computer-readable

10 medium for enabling a personal automated teller and a server which i i communicate via a network as recited in claim 38, including a code

12 segment that displays messages on the personal automated teller.

1 40A. The computer program embodied on a computer-readable

2 medium for enabling a personal automated teller and a server which

3 communicate via a network as recited in claim 38, including a code

4 segment that displays messages on the personal automated teller which

5 include a time period that must elapse before shifting the message one

6 character.

1 40B. The computer program embodied on a computer-readable

2 medium for enabling a personal automated teller and a server which

3 communicate via a network as recited in claim 38, including a code

4 segment that stores information in a memory of the personal automated

5 teller.

1 41. The computer program embodied on a computer-readable

2 medium for enabling a personal automated teller and a server which

3 communicate via a network as recited in claim 38, including a code segment that retrieves data from a memory of the personal automated teller.

42. The computer program embodied on a computer-readable medium for enabling a personal automated teller and a server which communicate via a network as recited in claim 38, including a code segment that retrieves data entered from a keypad of the personal automated teller.

43. The computer program embodied on a computer-readable medium for enabling a personal automated teller and a server which communicate via a network as recited in claim 38, including a code segment that presents a menu of choices on the personal automated teller.

44. The computer program embodied on a computer-readable medium for enabling a personal automated teller and a server which communicate via a network as recited in claim 38, including a code segment that manages a smartcard utilizing the personal automated teller.

45. The computer program embodied on a computer-readable medium for enabling a personal automated teller and a server which communicate via a network as recited in claim 38, including a code segment that retrieves identity information from the personal automated teller.

46. The computer program embodied on a computer- readable medium for enabling a personal automated teller and a server which communicate via a network as recited in claim 38, wherein information transmitted over the network between the personal automated teller and the server comprises a header, a type and a checksum field.