Transaction processing systems

Abstract

A banking, retail or other transaction network can comprise a number of terminals, for example an ATM, where each terminal comprises a plurality of peripheral devices such as a user interface, card reader, receipt printer and cash dispenser. The applications software for the peripheral devices can be held in a central server located externally of the terminal and linked to the terminal through a communications link. The link can extend to the individual peripheral devices so that they are direct clients of the server. Additionally the individual peripheral devices can be connected to each other over the link to enable them to communicate directly with each other on a peer-to-peer basis. Each peripheral can have an independent control application. In use, the independent control applications may communicate with each other so that a peripheral operates in response to a signal generated by another peripheral. A peripheral for use in such a terminal, and a network of such terminals are also described. A mainframe or server computer accessing a banking or other information database (e.g., a legacy host) can be connected to the central server through an information signal connection.

Claims

What is claimed is:

1. A banking or retail transaction network comprising a server and one or more transaction terminals, each of the transaction terminals containing a plurality of peripheral devices adapted to function as constituents of the transaction terminal operating through the server in the transaction network, wherein the server is arranged to store applications and driver software for the peripheral devices and communication links are provided from the server to the peripheral devices so that the server and the peripheral devices can communicate independently of the transaction terminal to enable the applications and driver software to be downloaded directly from the server to the peripheral devices.

2. A network according to claim 1 in which the peripheral devices include their own embedded processors to which the communication links are able to download software from the server.

3. A network according to claim 2 in which the devices each include hardware control elements controlling the hardware of the device and the processor embedded in a device operates the hardware control elements in a manner determined by the software downloaded to the processor through the communications link.

4. A network according to claim 1 in which the communication links also enable the peripheral devices of a terminal to communicate with each other.

5. A network according to claim 1 in which the peripheral devices are selected from the following peripheral devices, namely: a user interface, a card reader, a receipt printer, a cash dispenser, and a bar code scanner.

6. A network according to claim 5 in which one of the peripheral devices is a card reader capable of reading from and writing to smart cards.

7. A network according to claim 5 in which one of the peripheral devices is a user interface comprising a keyboard and a display unit.

8. A network according to claim 1 in which the communication links are dedicated links.

9. A banking transaction network according to claim 1 in which the communication links comprise a modem and information signal transfer media enabling transfer of signals from the modem through a telephone network to a server.

10. A banking transaction network according to claim 1 in there is provided a banking information database and a communications link between the banking information database and the central server.

11. A banking transaction terminal including a plurality of peripheral devices adapted to function as constituents of the banking transaction terminal in which communication links are provided from individual devices to link said devices directly to an external server, wherein the external server and the peripheral devices can communicate independently of the banking transaction terminal.

12. A terminal according to claim 11 in which internal communication links are also provided between the peripheral devices to enable such devices to communicate directly with each other.

13. A terminal according to claim 11 in which the peripheral devices are selected from the following peripheral devices, namely: a user interface, a card reader, a receipt printer, a cash dispenser, and a bar code scanner.

14. A terminal according to claim 13 in which the user interface comprises a keyboard and a display unit.

15. A terminal according to claim 11 in which the communication links are dedicated links.

16. A terminal according to claim 11 in which the communication links comprise a modem and information signal transfer media enabling transfer of signals from the modem through a telephone network to a server.

17. A banking transaction network comprising a plurality of banking transaction terminals according to claim 11 together with a central server to which each of the communication links from the individual peripheral devices of the terminals are connected.

18. A banking transaction network comprising a plurality of banking transaction terminals, each of the banking transaction terminals including a plurality of peripheral devices adapted to function as constituents of the banking transaction terminal in the banking transaction network, a central server, and communication links from the terminals to the server characterized in that the links extend from each individual peripheral device in a terminal directly to the server so that the central server and the peripheral devices can communicate independently of the banking transaction terminal.

19. A network according to claim 18 in which there is provided a banking information database and a communications link between the banking information database and the central server.

20. A transaction network comprising a server and at least one terminal, each terminal containing a plurality of peripheral devices adapted to function as constituents of the transaction terminal operating through the server in the transaction network, the network being characterized in that the server is arranged to store software for the peripheral devices, and communication links are provided from the server to each peripheral device, whereby each peripheral devices is operable to download software directly from the server independently of the terminal.

21. A transaction network according to claim 20, where each peripheral devices is operable to configure itself using the downloaded software.

22. A transaction network according to claim 20, where the software stored on the server includes applications software and peripheral driver software.

23. A transaction network according to claim 20, where each peripheral device includes an embedded processor that operates with the communication links to download software from the server.

24. A transaction network according to claim 23, where each peripheral device includes hardware control elements controlling the hardware of the peripheral device, and the embedded processor operates the hardware control elements in a manner determined by the downloaded software.

25. A transaction network according to claim 20, where each peripheral device has a non-volatile memory for storing boot-up information, whereby, on powering the peripheral device, the contents of the non-volatile memory may be used for initializing the peripheral device.

26. A transaction network according to claim 20, where the peripheral devices communicate with the server using the TCP/IP protocol.

27. A transaction network according to claim 20, where the communication links also enable the peripheral device of a terminal to communicate with each other.

28. A transaction network according to claim 20, where the peripheral devices are selected from the following peripherals, namely: a user interface, a card reader, a receipt printer, a cash dispenser, and a bar code scanner.

29. A transaction network according to claim 20, where an information database is in communication with the server.

30. A transaction network according to claim 20, where the communication links include a router for concentrating information from the peripheral devices and transmitting that information across a single connection.

31. A transaction terminal including a plurality of peripheral devices adapted to function as constituents of the transaction terminal, each of the peripheral devices having communication hardware for use in connecting to a server, whereby, in use, each peripheral device is operable independently of the transaction terminal to access the server and to download software directly therefrom.

32. A transaction terminal according to claim 31, where the peripheral communication hardware is an Ethernet adapter.

33. A transaction network system comprising a server and at least one terminal, each terminal containing a plurality of peripheral devices adapted to function as constituents of the terminal operating through the server in the transaction network system, where the server stores a plurality of independent software modules, where at least one software module is associated with each peripheral device, and where communication links are provided from the server to each peripheral device so that the server and the peripheral devices can communicate independently of the terminal, whereby each peripheral device is operable to download one or more of the independent software modules directly from the server and to configure itself using the one or more downloaded software modules.

34. A transaction processing terminal including a plurality of modular elements that intercommunicate through a connected sub-network using IP protocols and that adapted to function as constituents of the transaction processing terminal operating through a remote server in a transaction network, and a router that concentrates communications between the modular elements and the remote server through a single IP protocol connection to the server, wherein the remote server and the modular elements can communicate independently of the transaction processing terminal to enable applications and driver software stored on the remote server to be downloaded directly from the remote server to the modular elements.

35. A peripheral device adapted to function as a constituent for a transaction processing terminal, the peripheral device including a dedicated processor, read/write memory, an I/O port, and a communication link to a remote server, wherein the peripheral device is configured for installation of software by download from the remote server independently of the transaction processing terminal using a Dynamic Host Control Protocol service when the peripheral device is initialized.

36. A peripheral device adapted to function as a constituent for a transaction processing terminal, the peripheral device including a dedicated processor, read/write memory, an I/O port, and a communication link to a remote server, wherein the peripheral device is configured for re-booting of the peripheral device initiated through the remote server independently of the transaction processing terminal over a connected network using a remotely executing Dynamic Host Control Protocol service.

37. A transaction processing terminal comprising a plurality of networked peripheral devices adapted to function as constituents of the transaction processing terminal operating through a remote server in a transaction network, each of the peripheral devices having its own data processor controlling operations of the device through execution of software applets downloaded to the device over the network from the remote server independent of the transaction processing terminal.

38. A transaction processing terminal comprising a plurality of networked peripheral devices adapted to function as constituents of the transaction processing terminal operating through a remote server in a transaction network, each of the peripheral devices having its own data processor controlling operations of the device through execution of software applets downloaded to the device over the network from the remote server independent of the transaction processing terminal via Web browser functioning incorporated within the device.

39. A transaction processing terminal comprising a plurality of networked peripheral devices adapted to function as constituents of the transaction processing terminal operating through a remote server in a transaction network, each of the peripheral devices having its own data processor controlling operations of the device through execution of interpreted software applets downloaded to the device over the network from the remote server independent of the transaction processing terminal and interpreted via virtual machine functioning incorporated within the device.

40. A transaction processing terminal comprising a plurality of networked peripheral devices adapted to function as constituents of the transaction processing terminal operating through a remote server in a transaction network, each of the peripheral devices having its own data processor controlling operations of the device through execution of compiled software byte code downloaded to the device over the network from the remote server independent of the transaction processing terminal and compiled via compiler functioning incorporated within the device.

41. A transaction processing terminal comprising a plurality of networked peripheral devices adapted to function as constituents of the transaction processing terminal operating through a remote server in a transaction network, each of the peripheral devices having its own data processor that directly executes byte code downloaded to the device over the network from the remote server independent of the transaction processing terminal to control operations of the device.

42. A banking or retail transaction terminal comprising a plurality of peripheral devices adapted to function as constituents of the transaction terminal operating through a remote server in a transaction network, each of the peripheral devices having control applications associated therewith, communication links for enabling the control applications to have individual access to an external server independent of the transaction terminal, and a central processor for providing processing power for the peripheral devices.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to transaction processing systems, such as banking or retail transaction systems, and in particular, to associated transaction processing terminals and networks.

2. Description of Related Art

Transaction processing networks, such as banking and retail transaction networks, may commonly comprise one or more transaction terminals connected to a server. Typical transaction terminals may comprise automated teller machines (ATMs), retail point-of-sale (POS) terminals, general self-service terminals (SSTs), and transaction kiosks. Each terminal generally has a central processor, typically PC based, which controls the operation of the terminal, application flow and user interface presentation. Application software and files used by the application are typically stored on a hard disk or other mass storage device within the terminal. The terminal generally is connected to a server through a connection, which may be a high order communications link or a modem and telephone based link into the network. The server may access an information database (e.g., a "legacy host") to assist in processing a transaction.

Numbers of other terminals, which may be of the same or of a different kind, may be connected in the transaction network. Simple client-server transactions may be conducted between a terminal and the host in order to obtain specific customer information used in the processing of a customer's transaction. In the case of an ATM the transaction may typically be a cash withdrawal or a balance request. In the case of a retail POS terminal a typical transaction may be a sale that makes use of price lookup.

A transaction terminal generally includes peripheral devices that are often very specific to the function of the terminal. Typical peripheral devices included in an ATM are a card reader, a cash dispenser, a receipt printer and a user interface (e.g., an encrypting keyboard and a display). Typical peripheral devices included in a POS terminal are a card reader, a bar code scanner, a receipt printer and a user interface (e.g., keyboard and display). Such peripheral devices are not all normally found on a general-purpose computer and must be incorporated both physically and electrically and be provided with appropriate control software. The serial and parallel ports associated with the central processor of a personal computer ("PC") can be used to supply control signals to the peripheral devices. Alternatively, a proprietary communications system can be employed; for example, the communications system known as Serial Distributed Control ("SDC") is used in ATMs manufactured by NCR Corporation. In either case, peripheral devices generally require some form of localized or embedded processing capability to conduct communications with the central processor and to implement its commands upon the device.

The above approach has a number of failings. The desired main task of a central processor is to present information, graphics and animation to the user. However, the processor has also been required to conduct control operations and possibly maintenance operations on the peripheral devices connected to it. Therefore either a larger processor may be required to obtain a given level of user interface performance or this performance may be adversely affected by the control operations of the processor on the peripheral devices.

Additionally, a terminal's peripheral devices have been configured to act as simple command processing systems, with all application control being conducted from the central processor. Peripheral processing capability was therefore not always well used, particularly hen invoked in a start-stop manner.

Furthermore, when it was desired to change the control logic for a peripheral device this often could only be done by changing the ROM (read-only memory) parts on the device or else by loading new driver software through the central processor over the communications channel within the terminal. All applications software, peripheral device drivers and user interface files have commonly been held in a mass storage device within the terminal. Collectively the installed software many times comprised a large monolithic system, in effect a central program used to control the various aspects of the terminal operation, from the user interface presented to the control of the peripheral devices. The installed software further generally included the necessary application business logic and error handling routines. In order to upgrade the software associated with any individual function or module it was thus often necessary to install a new suite of program files onto the terminal's mass storage device and to otherwise disrupt the terminal's operation for software maintenance. Particularly in the case of ATMs where security is a significant factor this could be an arduous task requiring secure disc build operations at each individual terminal.

While this type of software upgrade approach may be feasible, although cumbersome, for driver software in current use, it may not be practical for transaction terminals in the future, which may be required function in a much more dynamic manner, e.g., by dynamically changing their capabilities at transaction run time and not just at the start of day. Examples of this may arise in connection with the need to operate with so-called "smart" cards of various kinds.

Smart cards generally have built-in electronic processing and data storage facilities. Card readers for such cards may need to be able to both read from and write to different kinds of smart cards and to the underlying applications contained within those cards, and may thus be called upon to dynamically change their capabilities or manner of operation at run time. Smart card readers may thus be required to use different drivers or control logic dependent on the actual smart card that is inserted. There may also be a requirement to dynamically download new applications software for transfer from the terminal to various types of inserted smart cards. However, installing and maintaining various smart card reader drivers, control logic implementations and smart card applications may well put further strains on systems maintenance.

Printers may require the dynamic download of different graphics drivers to support various different graphics formats. Also, dispensers may not be limited to dispensing cash only but may be required to dispense other media such that alternative or additional control software may be called for at run time.

While application development tools are becoming available that may allow the developer to consider peripheral modules as functional components, maintenance issues will remain if application business logic and error handling facilities for these components are made to reside within a single central application program.

SUMMARY OF THE INVENTION

It is an object of the invention to provide transaction terminals or networks in which one or more of the above stated objectives are met, or problems are overcome or mitigated.

General objectives of the invention are met by providing modules or peripheral devices adapted to function as constituents of a transaction terminal operating through a server in a transaction network, characterized in that the devices or modules (or associated processes) and server can independently communicate. Communications with the server may be direct or through a controller such as a router acting as a firewall to block unwanted communications with other devices. This structure, for example, may variously allow each module's operating or application software and required data files to be independently introduced or updated via the server at start up, selected maintenance intervals or dynamically at the time of transaction. Conveniently, the software may be in the form of downloaded byte code or applets, such as JAVA.RTM. program code, executable using Web browser, virtual machine or compiler functioning incorporated within the module. The need for local hard disc storage can thus be eliminated and modules can be independently serviced without significant disruption of the operations of the terminal or other modules. Further, a module's software and data files can be isolated to the module's immediate or selected requirements, allowing for associated files and file updates to be better targeted to specific functions and thus more limited in size. Another advantage of the module to server communications structure is that it allows a module's state and operational history to be directly monitored through the server with minimal disruption to operations of other terminal elements.

General objectives of the invention are alternatively or further met by providing modules or peripheral devices adapted to function as constituents of a transaction terminal, characterized in that the devices or modules (or associated processes) communicate with each other, e.g., via peer to peer communications, by device specific addressing or by broadcast messaging. Conveniently, a module may operate as a state machine, executing its own event driven application programming. Modules may communicate their respective states to other modules and execute operations based upon a module's state and events within one or more other modules. This type of architecture allows use of relatively low cost local or embedded processors within various modules, mitigating requirements for a higher cost PC based processor used for centralized processing within a transaction terminal.

According to the invention a banking, retail or other transaction network can comprise a server and one or more terminals each containing a plurality of peripheral devices where the server is arranged to store applications and driver or other operational software for the peripheral devices and communication links can be provided from the server to individual peripheral devices to enable such software to be downloaded directly from the server to the devices.

The peripheral devices can each include their own, preferably embedded, processors to which the communication links are able to download software from the server.

In carrying out the invention the a terminal's peripheral devices may each include a hardware controller to control the hardware of the device, and a local processor in the device operates the hardware controller in a manner determined by software downloaded to the processor through the communications link.

In a preferred embodiment communication links enable the peripheral devices of a terminal to communicate with each other.

The peripheral devices for a transaction terminal may be selected, for example, from the following peripheral devices, namely: a user interface, a card reader, a receipt printer, a bar code scanner and a cash dispenser. The user interface may comprise a keyboard and a display unit. The card reader peripheral is preferably capable of reading from and writing to smart cards.

The peripheral device communication links may be dedicated links. Alternatively they may comprise a modem and information signal transfer capability for enabling transfer of signals from the modem through a telephone network to a server.

In embodiments of the invention there may be provided a banking, retail, or other information database and a communications link between the information database and a central server.

According to the invention a banking or other transaction terminal can include a plurality of peripheral devices where communication links are provided from individual peripheral devices to link said devices for independent communications with an external server. A banking, retail or other transaction network may accordingly comprise a plurality of transaction terminals each including a plurality of peripheral devices, a central server, and communication links from the terminals to the server, where the communication links connect peripheral devices in a terminal for communications with the server.

Alternatively, communication links may extend to the server from multiple peripheral device control applications executing on a central processor in the terminal, where each such control application supports and is associated with a different peripheral device. In one embodiment a transaction terminal may include a central processor providing processing capabilities for a plurality of peripheral devices each of which may have its own independent control process or application running on the central processor. The control processes or applications may be so constructed that they can communicate directly with each other, or directly with an external server on a connected network.

Thus, a transaction terminal may comprise multiple peripheral devices, and the different peripheral devices or their associated operational processes may have individual access to or by a central server in the network. The network may further include an information database (legacy host) with a communications link between the database and the server to assist a transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the invention may be more fully understood reference will now be made to the accompanying drawings in which:

FIG. 1 is a block diagrammatic representation of one peripheral device and its place in a transaction network embodying the invention,

FIG. 2 is a block diagrammatic representation of a banking or retail transaction network embodying the invention and showing one terminal,

FIG. 3 is a flow chart of card reader control software for detecting different types of card,

FIG. 4A is a block diagrammatic representation of a transaction network embodying the invention and showing one terminal,

FIG. 4B illustrates a software architectural view of the embodiment of FIG. 4A,

FIG. 5 is a flow chart of a typical sequence of events at an ATM terminal embodying the invention,

FIG. 6 is a diagram illustrating a conventional ATM network and the software control of peripherals within an ATM,

FIG. 7 is a diagram illustrating the software control of peripherals within an ATM in accordance with one embodiment of the present invention,

FIG. 8 is a block diagrammatic representation of an ATM network in accordance with an embodiment of the invention,

FIGS. 9A, B and C are tables illustrating a feature of the embodiment of FIG. 8,

FIG. 10 is a flow chart of a typical sequence of events in an ATM terminal as shown in FIG. 8,

FIG. 11 is a block diagrammatic representation of an ATM network in accordance with an alternative embodiment of the invention,

FIG. 12 is a table illustrating a feature of the embodiment of FIG. 11,

FIG. 13 is a block diagram of a conventional ATM-based transaction network,

FIG. 14 is a block diagram of a transaction network according to one embodiment of the invention,

FIG. 15 is a block diagram of a transaction network according to another embodiment of the invention, showing a router connecting four peripherals in a terminal to a server,

FIG. 16 is a block diagram showing one of the peripherals of FIG. 15 in greater detail,

FIG. 17 is a flow chart relating to one of the peripherals of FIG. 15,

FIG. 18 is a block diagram of three types of Java programming environments,

FIG. 19 is a functional block diagram of the picoJava processor core,

FIG. 20 is a functional block diagram of the microJava 701 processor core,

FIG. 21 is a functional block diagram of the microJava 501 processor core,

FIG. 22 is a block diagram of an exemplary use of a Java processing core implementation for control of a networked peripheral device or module, according to one possible embodiment of the invention,

FIG. 23 is a functional block diagram of an exemplary ATM terminal made up of networked peripheral devices or modules, according to one possible embodiment of the invention,

FIG. 24 is a functional block diagram of an exemplary POS terminal made up of networked peripheral devices or modules, according to one possible embodiment of the invention,

FIG. 25 is a functional block diagram of the Java Engine 1 Java processing board, designed for Thin Client or networked computer applications,

FIG. 26 is a functional block diagram of an exemplary use of the Java Engine 1 board shown in FIG. 25, for constructing a Thin Client POS terminal or kiosk,

FIG. 27 is a functional block diagram of an exemplary ATM terminal made up of networked peripheral devices or modules, and using a network communications router, according to one possible embodiment of the invention,

FIG. 28 is a functional block diagram of an exemplary ATM terminal made up of networked peripheral devices or modules, and using a dual port user interface, according to one possible embodiment of the invention,

FIG. 29 is a functional block diagram of an exemplary ATM terminal made up of networked peripheral devices or modules, and using a modem port user interface, according to one possible embodiment of the invention,

FIG. 30 is a functional block diagram of an exemplary ATM terminal using a Thin Client networked computing model architecture,

FIG. 31 is a functional block diagram of an exemplary ATM terminal using an Ultra Thin Client networked computing model architecture, according to one possible embodiment of the invention,

FIG. 32 is a functional block diagram of exemplary application and control software associated with a networked peripheral device or module for use in an Ultra Thin Client Team application architecture, according to one possible embodiment of the invention,

FIG. 33 is a software file directory listing of messaging files for networked peripheral devices or modules used in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 34 is a listing of elements of messages exchanged by networked peripheral device or module processes used in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 35 is a simplified block diagram of the internal registry use by networked peripheral devices or modules in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 36 is a functional block diagram of an exemplary ATM terminal made up of networked peripheral devices or modules, and using a network communications router, according to one possible embodiment of the invention,

FIG. 37 is a functional block diagram illustrating an exemplary identification number assignment scheme for messaging with networked peripheral devices or modules in an Ultra Thin Client Team application architecture for ATM terminals, according to one possible embodiment of the invention,

FIG. 38 is a simplified block diagram of a linked-list type internal registry use by networked peripheral devices or modules in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 39 is a simplified block diagram of the functional relation messaging program elements for networked peripheral devices or modules in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 40 is a simplified block diagram illustrating types of events reacted to by event-driven networked peripheral devices or modules in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 41 is a flow diagram for the application flows for an exemplary standard ATM transaction by networked peripheral devices or modules in a prototype Ultra Thin Client Team application, according to one possible embodiment of the invention,

FIG. 42 is a software file directory listing of software application files for networked peripheral devices or modules used in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 43 is a flow diagram for a time out sequence used by a card reader networked peripheral device or module in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 44 is a software file directory listing of miscellaneous files for networked peripheral devices or modules used in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 45 is a screenshot of a display window associated with the functioning of a card reader networked peripheral device or module in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 46 is a screenshot of a display window associated with the functioning of a cash dispenser networked peripheral device or module in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 47 is a screenshot of a display window associated with the functioning of a receipt printer networked peripheral device or module in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 48 is a screenshot of a display window associated with the error dialog functioning of a card reader networked peripheral device or module in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 49 is a screenshot of a display window associated with the error dialog functioning of a receipt printer networked peripheral device or module in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 50 is a screenshot of a display window associated with the error dialog functioning of a cash dispenser networked peripheral device or module in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 51 is a simplified block diagram of the functional relation between a cash dispenser networked peripheral device or module and a legacy host through a TopEnd type interface in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 52 is a software file directory listing of software used to control a card reader networked peripheral device or module used in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 53 is a is a simplified block diagram of possible interface relations for controlling a card reader networked peripheral device or module in a Thin Client Team application architecture for an ATM terminal, according to one possible embodiment of the invention,

FIG. 54 s a screenshot of a display window associated with the operation and testing of a card reader networked peripheral device or module in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 55 is a screenshot of a display window associated with the user control of Java communications for testing of a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIGS. 56A, B and C are listings and descriptions of Java program files used for operation and control of networked peripheral devices or modules in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention,

FIG. 57 is a listing and description of C++ program files used for operation and control of card reader networked peripheral device or module in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention, and

FIG. 58 is a listing and description responses to messages by a card reader networked peripheral device or module in a prototype Ultra Thin Client Team application architecture for a simulated ATM terminal, according to one possible embodiment of the invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

EXAMPLE 1

Referring now to FIG. 1 there is shown therein a block diagram of a typical peripheral device 1 used in a network embodying the invention. Device 1 is connected over a Local Area Network (LAN) 2 to a central server 3. A legacy host 4 is also connected to server 3 via a Wide Area Network (WAN) 5. Device 1 contains a processor 6, which can be a low cost embedded processor, to which is connected a communications system 7. Communications system 7 together with LAN 2 form a communications link between device 1 and server 3. Also contained within device 1 there is hardware control electronics 8 for controlling the module hardware 9 of device 1. A number of different peripheral devices such as device 1 and each having different functions can be grouped together in a transaction terminal.

Processor 6 is able to communicate through communications system 7 and LAN 2 with server 3 and with any associated devices connected to LAN 2. Processor 6 uses communications system 7, LAN 2 and server 3 in order to load applications and drivers for hardware control electronics 8 as required. Processor 6 applies the loaded driver software to hardware control electronics 8 to control module hardware 9. Dependent upon the application loaded from server 3 to device 1, it is possible for the software to access legacy host 4 over LAN 2, server 3 and WAN 5 as required.

Referring now to FIG. 2 there is shown therein a block diagram of an ATM 11 having a plurality of peripheral devices each of which is an example of a typical peripheral device 1 described with reference to FIG. 1. In the example illustrated ATM 11 has various peripheral devices each of which fulfill a different function. As shown, there can be a user interface 12, a card reader 13, a receipt printer 14 and a cash dispenser 15 making up the ATM 11. User interface 12 can comprise a keyboard and a display unit, for example. A typical ATM keyboard will have a numeric keypad and a small number of additional keys, which may be labeled "ENTER", "CANCEL" and so on.

A server 16 is positioned at a suitable location externally of ATM 11. ATM 11 is shown connected to server 16 by a communication link 17, which can be of any known type. For example link 17 may be part of a local area network (LAN), a wide area network (WAN) or else a dial up connection. Link 17 may be a high bandwidth network connection to allow for efficient and rapid download of software and may use the TCP/IP transfer protocol, although for single off-site terminals lower speed dial-up modems can be used. Other banking transaction terminals, in addition to ATM 11 may be linked to server 16 through other communication links similar to link 17.

A preferred feature of communication link 17 is that each peripheral device or module in ATM 11 has independent access to server 16 through link 17 and is thus an individual client to server 16. Server 16 can be connected to legacy host 18 (which can include a banking, retail or other information database) through a further information signal communication link 19. Server 16 may also contain the application software used by the modules in ATM 11. The same applications software can also be used by corresponding modules in other terminals of the network which are linked to server 16.

The modules in ATM 11 may access link 17 using standard networking protocols such as TCP/IP in order to connect both to server 16 and to the other modules. Each module may contain an embedded processor and appropriate hardware control electronics in order to be able to manipulate the hardware that constitutes the module. This can be done either by embedding the silicon description of the processor within module specific control chips or through the use of a generic embedded processor, which uses general-purpose input/output software to access module specific control chips as peripheral devices. Within such embodiments of the invention the individual module applications may run directly on the embedded processor.

In addition to link 17 providing a direct connection from each module to server 16, link 17 may also enable communication to take place among the individual modules of ATM 11 themselves. Thus, for example, information as to the operational state of any of the modules can be communicated to other modules.

In operation and with the applications software being held in server 16, the modules of ATM 11 can require only a very simple boot code to be present in ROM or PROM or in Flash RAM in the modules themselves to allow them to boot up, initiate a network session with server 16 and download the current version of the applications software to each module. The downloading operation may use standard protocols such as BOOTP or TFTP. Software upgrades can be easily achieved by upgrading the software held on server 16 and restarting the modules either directly at ATM 11 or via server 16. This allows for the remote administration of an entire transaction network.

The banking transaction network described above may be operated according to a number of application architectures.

In one architecture a master/slave relationship can exist between user interface 12 and each of the other peripheral devices. Application flow can be conducted by the user interface module with the other peripheral modules being commanded to carry out specific tasks as required. Commands can be issued over the communications links using standard network sockets, remote method invocation or remote procedure calls.

In an alternative preferred architecture a peer to peer relationship can exist between all of the modules of ATM 11. The occurrence of significant events can be broadcast to ensure synchronization of individual applications operating within each module.

The ability of peripheral modules within a transaction network to dynamically load required software components provides for an efficient and easily controllable mechanism for supporting the required functionality. For example for card reader 13 to be able to recognize different types of smart card as well as magnetic stripe cards, card reader 13 needs to be a multiple type card reader. To this end different software drivers can be available and accessible to support the different types of electrical interfaces, data streams and communications protocols for each type of card. In addition, various mechanical and electrical considerations would generally be addressed to accommodate interfacing with the various card types.

The flow chart of FIG. 3 illustrates a basic application flow for recognizing two types of smart card with the processing of a magnetic stripe card as the default. A default program can be loaded initially to wait for a card to be inserted. On detection that an attempt is being made to insert a card into card reader 13, the program can provide for the opening of shutters and for the energizing of drive motors as required and then identify the type of card that has been inserted in accordance with the flow chart illustrated in FIG. 3. Unlike card readers that need to have all the necessary routines available all the time, either locally in ROM or else downloaded at the start of the day, a terminal embodying this example of the invention may initially download only the default program, and when the presence of a Type 1 or Type 2 card (as indicated in the flow chart of FIG. 3) is detected, the relevant program for the detected card can be downloaded.

While the flow chart of FIG. 3 shows only two types of card, the disclosed architecture can readily be programmed to detect any other number of cards. If it is desired to support another type of card, a default program may need to be increased in size by only a small amount sufficient to support the extra decision block and type identification. Support for particular card and transaction types can be readily updated, added or deleted, incrementally as desired. Associated software changes can be made at the start of day, at some other maintenance time or interval, or dynamically as needed at the time of a transaction. This contrasts with terminals and associated card readers that may need to have their operational programming replaced or increased by the total size of the routines required to process an extra type of card or application embedded in the card. Similar programming considerations may apply to other modules such as printers and media dispensers.

In the case of printers, technologies such as the World Wide Web can bring large amounts of graphic imagery to self service and point of sale terminals so that printers at such terminals may require the ability to print out hard copy of such imagery. Printer 14 can be programmed to load Web pages directly over communication link 17 from server 16 as well as loading the appropriate printer driver software to support the graphics, fonts and other imagery in the downloaded Web pages. Such software can be resident in server 16 and be loaded to the printer only as and when required. As these drivers consist of code and data it is possible to load individual graphic imagery, along with its own printer driver software, in order to customize receipts, statements and the like either as part of a branding exercise or as a customization exercise for a user. These graphic images can be purely transitory, so as to take up memory space in the printer module only for the duration of their task.

The traditional cash dispenser may be replaced by more of a general multi-media dispenser, with the media to be dispensed ranging from paper in the form of currency notes, airline and other tickets and books of stamps and on to plastic media such as ski passes. Accordingly there is a requirement to support different media types at the dispenser which require different timing and control parameters for the different stacks of media material held by the dispenser. With the disclosed architecture, appropriate software can be readily downloaded from server 16 through link 17 at run time without the need to store every alternative driver program at the dispenser.

With each peripheral module having a direct connection through communication link 17 to server 16, it can communicate directly and independently with the server 16 not only to download software but also to obtain data specific to a current transaction while it takes place. For example a request may be made for information specific to the user and appropriate to conduct the current transaction. Thus dispenser 15 may require the users current balance in order to determine if the user had sufficient funds to cover a requested cash withdrawal. User interface 12 may also require account balance and bank statement information in order to present these to the user.

With each peripheral device or module in ATM 11 individually connected to server 16, the network can be capable of downloading software from server 16 whenever it is required, for example on startup or on resetting. Furthermore the latest version of a particular software application can be instantly made available to all terminals in a network by loading it into server 16 without the need for physical access to any of the terminals. In addition terminal specific software can be made available at the server. Such terminal specific software may comprise marketing messages for display at a terminal.

By having a direct connection from the peripheral devices to the server it is possible to allow the peripheral software applications to take a more active role in the overall operational flow. This allows the user interface processor to concentrate on its primary task of providing user interface display graphics, animation or video facilities. The processing power required to operate individual peripheral devices can then be selected to optimize the cost/performance ratio.

It is desirable to monitor the operation of the modules and for this purpose various logs and hardware tallies can be provided for. An embedded processor at a module can be programmed to generate such logs and tallies and report the results. Access points can be provided over a network to allow for diagnostic operations including the downloading of monitoring information. The reports can be in HTML form thus allowing a standard Web browser to access the information.

EXAMPLE 2

Referring to FIG. 4A there is shown therein a block diagram of a transaction network comprising an ATM 21 connected through a network connection 27 to a server 26. A transaction database (or legacy host) 28 is also connected to server 26 via a communications link 29. ATM 21 has a number of peripheral devices. These are a card reader 23, a receipt printer 24, and a cash dispenser 25. These devices are connected through suitable parallel or serial ports to a central processor 30 provided in ATM 21. ATM 21 also includes a keyboard 22 and a user display 31. A communications link 27 is provided from ATM 21 to server 26. Link 27 is typically a high order communications link to allow for efficient transfer of data from server 26 to ATM 21 although lower speed dial-up modems could be used if desired. When ATM 21 is turned on all application software is loaded from the mass storage device (not shown) associated with the central processor 30. Once operational the individual module applications running on central processor 30 use client-server techniques to communicate with server 26 to obtain customer specific transactional information from legacy host 28.

An architectural view of the embodiment of FIG. 4A is illustrated in FIG. 4B in which like parts of FIG. 4A are similarly numbered. The application modules of card reader 23, receipt printer 24 and cash dispenser 25, e.g., considered as software modules, may control the operation of the associated peripheral modules through corresponding device drivers 32. Similarly, the user interface application module 34 may use a graphics display driver 33 to present appropriate information to the user. This application module may also use a keyboard (not shown) to gather user input.

The individual application modules that operate within various hardware embodiments of the invention such as those shown in FIGS. 2 and 4A may be programmed to operate as a team, with each application module being considered as a team member or peer. Each application module may run its own error handling, control and business logic based upon predetermined rules of operation. The applications may be event driven with internal events, for example user input or hardware activity, driving the state of each application module. As the state of an application module changes it may broadcast appropriate messages to all the other members of the team. These event-based messages may be used to synchronize the different application modules to a common application state. As the state of any application module changes, due for example to hardware events, user input or time-out conditions, so an event message may be broadcast to allow the other members of the team to act accordingly.

Initial "HELLO" messages may be used to introduce each member of the current team configuration. This introductory process may allow each team member to build a registry of the other application modules that are present and how to communicate with them. This team building process may also allow a user interface 12 to determine what peripheral devices are available and therefore what user services can be offered.

An application module that is closing down can send a "GOODBYE" message to indicate that it is no longer available. Peripheral modules can become non-functional. This can happen as a result of hardware failure (for example if a card is jammed in card reader 13) and an application module that has gone fatal may send a "GOODBYE" as it withdraws from the team. Alternatively if a peripheral module is physically removed, or is otherwise unable to signal with a "GOODBYE" message, then the first application module that attempts to send a message to the now missing application module may detect that it is missing and send a "GOODBYE" message on its behalf. When the peripheral module is reconnected, or becomes operational, its application module may broadcast a "HELLO" message to allow the other application modules to adapt accordingly.

Various transaction terminal embodiments described herein may thus operate as an event driven system. Messages may be broadcast from application modules within which an event has occurred to other application modules within the terminal. These other application modules may, or may not, be concerned with that event. For an ATM 11 and its user interface 12, card reader 13 and cash dispenser 15 a typical transaction sequence is illustrated in FIG. 5.

Referring now to FIG. 5, the first column shows an illustrative sequence of events and their associated event messages. The second, third and fourth columns show exemplary operations of user interface 12, card reader 13 and cash dispenser 14 following generation of each event message listed in the first column. In the second column, which shows a manner of operation of user interface 12, the statements within quotation marks are examples of the text displayed on a screen to the user.

In the event of insertion of a card by a new user into card reader 13 a message "CARD_INSERTED" may be broadcast by card reader 13. The effect of that message may be to cause user interface 12 to display the text "Please enter PIN". When the user has entered a PIN number a `Validate User PIN` operation can take place. This might involve the use of links 17 and 19 to communicate with legacy host 18. If the entered PIN number is found to be valid for the particular card that has been inserted into card reader 13 then user interface 12 can be informed accordingly whereupon it may generate a "USER_VALID" event message. This may cause display of a cash selection request. The customer user may then enter a specific amount that may cause the broadcast of another event message, e.g., "CASH_REQUEST".

The "CASH_REQUEST" message may cause operation of cash dispenser 15 to count out the requested amount while at the same time user interface 12 may cause the text "Your cash is being counted" to be displayed on the screen. When cash dispenser 15 has completed its task it may generate a "CASH_STAGED" message which can be used by card reader 13 to present the inserted card partly out of the card entry slot to enable it to be removed by the user. Card reader 13 may then broadcast the event message "CARD_PRESENTED" which in turn may cause user interface 12 to display the text "Please take card".

When card reader 13 detects that the card has been taken it can generate a "CARD_TAKEN" message. This message, on receipt by cash dispenser 15 may cause the device to present cash that it has counted out. When that operation is done cash dispenser 15 may generate a "CASH_PRESENTED" message to cause user interface 12 to display "Please take cash". On dispenser 15 detecting that the cash has been taken it may broadcast a "CASH_TAKEN" message to reset all the modules to their initial condition ready for another user.

From the above description it is apparent that the messages listed in the first column of FIG. 5 can be used to drive individual application modules and thus the operation as a whole in the manner illustrated. Since the messages are broadcast they are available to all of the application modules. However in many cases only one application module or only some of the application modules may make use of certain messages. For example card reader 13 may need to know the amount of any cash withdrawal figure entered by the user so that it can update the card appropriately should that cash withdrawal be validated by server 16 and dispensed by cash dispenser 15.

Not shown in FIG. 5 are the various communications that may take place between individual modules and server 16 and legacy Host 18. Where each application module has an independent connection through communication link 17 to server 16 it can communicate directly and independently with it. For example a request may be made for information specific to the user and appropriate to conduct the current transaction. Thus dispenser 15 may require the users current balance in order to determine if the user had sufficient funds to cover a requested cash withdrawal. User interface 12 may require account balance and bank statement information in order to present these to the user.

By having a direct connection from the peripheral devices to the server it is possible to allow the peripheral application modules to take a more active role in the overall operational flow and to conduct appropriate sections of the transaction business logic along with their own error handling. This allows the user interface application 12 to concentrate on its primary task of providing user interface display graphics, animation and video facilities. Within the hardware embodiment of the invention illustrated in FIG. 2 the processing power required to operate individual peripheral devices can then be selected to optimize the cost/performance ratio.

EXAMPLE 3

FIG. 6 shows an ATM 30 connected to a legacy host 32 via a server 34, the ATM 30 having a card reader 36, a receipt printer 38, a cash dispenser 40, and a user interface 42 (including an encrypting keyboard and a display). These devices are generally with appropriate control software, and also require some form of embedded or local processing capability to conduct communications with the central processor and to implement commands received therefrom.

All applications software, peripheral device drivers and user interface files are commonly held in a mass storage device in the ATM 30. Typically these applications are large, monolithic systems with a central program 44 being used to control all aspects of the operation of the ATM 30. This central program 44 runs on a central processor and, for example, determines what graphics are presented to the customer on the display, retrieves encrypted PIN information from the card reader and passes it to the encrypting keyboard for validation, and checks that the person's account has sufficient funds if a cash withdrawal is requested.

This central program 44 also includes the necessary business logic (which integrates and manages the different functions of the terminal) and error handling routines (which minimize the possibility of the terminal having to go out of service due to a malfunction). Therefore, design of this central program 44 is very complex and time consuming. In addition, updating device drivers or applications software associated with a peripheral device is complicated because of the size of the central program 44.

Referring to FIG. 7, there is shown a diagram illustrating the software control of peripherals according to one embodiment of the present invention, wherein like numerals in FIG. 7 refer to like features in FIG. 6. In FIG. 7, an ATM 46 includes four peripherals 36,38,40,42 each having an associated control application 50,52,54,56. For example, a card reader 36 has an associated card reader control application 50. Each of the control applications is connected to the server 34 via a communications controller 58 which is responsive to each of the control applications 50,52,54,56 for facilitating communication with the server 34. Each control application (e.g. 50) controls its associated peripheral (e.g. 36) using dedicated device drivers (not shown) for that peripheral.

Referring to FIG. 8 there is shown therein a block diagram of a self service network 100 in the form of an ATM transaction network comprising an ATM 102 connected to a server 34 via a high order communications link 104 which is part of a wide area network. The link 104 provides efficient transfer of data from server 34 to ATM 102. A transaction database (or legacy host) 32 is also connected to server 34 via a conventional communications link 106.

ATM 102 houses a plurality of peripherals including a card reader 116, a receipt printer 118, a cash dispenser 120, an encrypting keyboard 128 and a display 130 (the keyboard 128 and display 130 together form a user interface). A typical ATM keyboard will have a numeric keypad and a small number of additional keys, which may be labeled "ENTER", "CANCEL" and so on. These peripherals 116,118,120,128,130 are connected by an RS-232 link 136 to a central processor 138 housed in ATM 102.

ATM 102 also has a mass storage device 140 in the form of a hard disk. This hard disk 140 stores at least one device driver and at least one control application (50,52,54,56 in FIG. 7) for each of the peripherals 116,118,120,128,130. A TCP/IP protocol is used for communication within ATM 102.

When power is applied to ATM 102, the central processor 138 is initialized, which involves the device drivers and the control applications being loaded into the central processor 138 from the mass storage device 140. Each control application is an independent process running on processor 138. Once the device drivers and control applications have been loaded into the central processor 138, the control applications implement a team-building process to form a team of peripherals, as will be described below.

As part of the team-building process, the control application for each peripheral creates a functional group registry that is stored as a linked-list. A completed functional group registry 150 for the card reader control application is illustrated in FIG. 9A. This registry 150 has an entry for each peripheral that may be part of the team, including the card reader peripheral. Each entry has three fields: a peripheral identification field 152, a peripheral IP address field 154, and a port address field 156.

The peripheral IP address field 154 is the address of the processor on which the control application associated with that peripheral is running. Thus, in the FIG. 10 embodiment the peripheral IP address field 154 for each peripheral is the same, being the address of the processor 138 that runs all of the control applications. However, in embodiments where each peripheral runs its associated control application on its own processor then the address field 154 will contain the address of the peripheral processor, i.e. the address field 154 of each peripheral will be different.

The port address field 156 at which each peripheral receives signals is predetermined, having been written into the control application associated with that peripheral.

Initially, the registry 150 for the card reader control application will appear as shown in FIG. 9B because the control application leaves all entries in the peripheral identification field 152 blank except the identification of its associated peripheral.

Even though a peripheral receives power, it may not be available for use and therefore may not be available to join the team. For example, a peripheral may have been shut down because of a malfunction, or because it needs replenished with paper (in the case of a receipt printer) or currency (in the case of a cash dispenser). Therefore, the card reader control application performs a test of the card reader to ensure that the card reader is functioning correctly. If the card reader is functioning correctly then the control application indicates its availability to join the team by broadcasting a start-up signal (a "HELLO" message) to other control applications.

A broadcast message on a TCP/IP network uses a special reserved IP address (255.255.255.255). Every node (every device having an IP address) connected to that TCP/IP network receives the broadcast message.

The "HELLO" message includes an identifier for the peripheral being initialized and an address at which the peripheral receives signals. For example, the card reader control application would transmit the identifier "card reader", the processor address "178.132.152.212"(from processor IP address field 154), and the port address "6040"(from the port address field 156). The TCP stack within processor 138 would recognize that the IP address "178.132.152.212" relates only to itself and so would not transmit the broadcast over the physical layer. The control applications (running on processor 138) relating to the other peripherals would receive this "HELLO" message and if available to join the team would update their registries 150 accordingly.

If a cash dispenser control application transmitted a "HELLO" message with the identifier "cash dispenser", the IP address "178.132.152.212", and the port address "6010"then the card reader control application would update its registry 150 to include this information, as shown in FIG. 9C. Thus, each peripheral control application maintains a registry of the identity and address of all other active peripherals in the team.

Once the team-building process is complete, the individual control applications (50,52,54,56 in FIG. 7) running on central processor 138 use client-server techniques to communicate with server 34 to obtain customer specific transactional information from legacy host 32.

The team building process also allows display 130 to determine what peripherals are available and therefore what services should be displayed for offering to a user.

It will be appreciated that although all of the control applications are executed by the central processor 138 during operation of the ATM 102, each of the control applications (e.g. 50, see FIG. 7) is independent of the other control applications (52,54,56, see FIG. 7).

In the event of a malfunction during operation (for example if a card becomes jammed in card reader 116, or if paper jams in the receipt printer 118), a peripheral can withdraw from the team. This is effected by the control application for that peripheral sending a shut-down signal (a "GOODBYE" message) to indicate that it is no longer available. The "GOODBYE" message includes the identity of the peripheral that is withdrawing. Each control application in the team updates its registry 150 by removing reference to the withdrawn peripheral from the registry 150, thereby removing the peripheral from the team.

If a peripheral is physically removed, or if power to a peripheral fails then the first application module that attempts to send a message to the now missing peripheral will detect that it is missing and send a "GOODBYE" message on its behalf. In this case the "GOODBYE" message includes the identity of the missing peripheral rather than the identity of the peripheral sending the "GOODBYE" message. The control applications for the other (remaining) peripherals update their registries in response to this "GOODBYE" message.

When the peripheral is reconnected its associated control application will broadcast a "HELLO" message to allow the other control applications to update their registries 150. Once the team-building process is complete, any newly joining peripheral will require information about the current members of the team. Therefore, when a "HELLO" message is received after the team-building process has been completed, each active control application (i.e. the control application for each active peripheral) retransmits a "HELLO" message to allow the newly joining peripheral to create an accurate registry 150 for the team.

The individual control applications are arranged to operate as a team, with each application module being considered as a team member or peer. Having a common application flow for all control applications ensures uniformity in the way that each control application interfaces with other control applications and with any other devices in the ATM 102.

The control applications are event driven. Internal events (for example, user input or hardware activity) drive the state of each control application. As the state of a control application changes it transmits appropriate messages to all the other members of the team (i.e. all other active control applications). These event-based messages are used to enable other control applications to set themselves to an appropriate state.

As the state of any control application changes an event message is broadcast to allow the other members of the team to act appropriately. The state of a control application may change as a result of, for example, a hardware event, a user input, or a time-out condition.

The transaction terminal described herein operates as an event driven system. Messages are transmitted from the control application for a peripheral within which an event has occurred to other control applications within the ATM 102. These other control applications may, or may not, be concerned with that event. A typical transaction sequence is illustrated in FIG. 10 for ATM 102.

Referring now to FIG. 10 the first column 160 shows a sequence of events and their associated event messages. The second 162, third 164 and fourth columns 166 show operations of display 130, card reader 116 and cash dispenser 120 following generation of each event message listed in the first column 160. In the second column 162, which shows the operation of display 130, the statements within quotation marks are examples of the text displayed to a user.

Where ATM 102 is operating with a team of peripherals comprising: card reader 116, receipt printer 118, cash dispenser 120, keyboard 128, and display 130; in the event of insertion of a card by a new user into card reader 116 a message "CARD-INSERTED" is transmitted by the card reader control application to the other peripherals in the team.

The effect of that message is to cause display 130 to display the text "Please enter PIN". When the user has entered a PIN number a `Validate User PIN operation takes place. This might involve the use of link 104 to communicate with legacy host 32 via server 34. If the entered PIN number is found to be valid for the particular card that has been inserted into card reader 116 then display 130 is informed accordingly whereupon its control application generates a "USER-VALID" event message. This causes display of a cash selection request. The user then enters a specific amount that causes the transmission of the next event message, namely "CASH-REQUEST".

The "CASH-REQUEST" message causes operation of cash dispenser 120 to count out the requested amount while at the same time display 130 causes the text "Your cash is being counted" to be displayed on the screen. When cash dispenser 120 has completed its task, its associated control application generates and transmits a "CASH--STAGED" message. On receiving the "CASH-STAGED" message, card reader 116 presents the inserted card partly out of a card entry slot in ATM 102 to enable the card to be removed by the user. The control application associated with the card reader 116 then transmits the event message "CARD-PRESENTED" which in turn causes display 130 to display the text "Please take card".

When card reader 116 detects that the card has been taken its associated control application generates and transmits a "CARD-TAKEN" message. On receipt of this "CARD-TAKEN" message, the cash dispenser 120 presents the cash that it counted out. When the cash has been presented, the control application associated with the cash dispenser 120 generates and transmits a "CASH--PRESENTED" message to cause display 130 to display "Please take cash". On dispenser 120 detecting that the cash has been removed its associated control application transmits a "CASH--TAKEN" message to all of the control applications associated with the modules in the team. On receipt of the "CASH--TAKEN" message, each control application associated with a peripheral in the team resets its respective peripheral to its initial condition ready for another user.

From the above description it is apparent that the messages listed in the first column 160 of FIG. 10 are used to drive individual application peripherals, and thus the operation as a whole, in the manner illustrated.

Although the messages are transmitted to all of the peripherals, in many cases only one peripheral or only some of the peripherals will make use of the messages. For example card reader 116 may need to know the amount of any cash withdrawal figure entered by the user so that it can update the card appropriately should that cash withdrawal be validated by server 34 and dispensed by cash dispenser 120.

Not shown in FIG. 10 are the various communications that take place between individual peripherals and server 34 and legacy host 32.

An alternative hardware architecture capable of providing an embodiment of the invention is shown in FIG. 11, which illustrates an ATM transaction network 200 comprising an ATM 202 having a plurality of intelligent peripherals including a card reader 216, a receipt printer 218, a cash dispenser 220, and a user interface 222. User interface 222 includes both a keyboard and a display unit.

The fundamental difference between the peripherals of FIGS. 8 and 11, for example card reader 116 and card reader 216, is that the peripherals in FIG. 11 are configured so that they operate individually and independently of any central processor, each peripheral being operable: to communicate directly with the server 34; to download software therefrom; and to run the downloaded software directly on its own processor. Whereas, in contradistinction, the peripherals of FIG. 8 are controlled from a central processor 138 which: communicates directly with the server 34; downloads software from the hard disk 140; and runs the downloaded software to control the peripherals.

However, in both embodiments (FIG. 8 and FIG. 11), the control applications for the peripherals, whether running on a central processor (FIG. 8) or in the individual peripherals (FIG. 11), communicate with each other and operate in response to signals generated by each other.

In FIG. 11, each peripheral 216,218,220,222 has an embedded processor, associated volatile memory (for example, 32 Mbytes), non-volatile memory for booting-up the peripheral, and a TCP/IP network connection. ATM 202 is connected to server 34 by a communication link 204, which is part of a wide area network (WAN); where the WAN connects a plurality of ATMs to the server 34. Link 204 is a high bandwidth network connection to allow for efficient and rapid download of software and uses the TCP/IP transfer protocol.

A feature of communication link 204 is that each peripheral 216,218,220,222 in ATM 202 is directly and independently connected to server 34 through link 204 and is thus an individual client to server 34. This is required for this embodiment because each peripheral must be able to download software independently of the other peripherals. In the same way as the FIG. 8 embodiment, server 34 is connected to legacy host 32 (which can be a basic banking information database) through communications link 106.

The control applications software used by peripherals in ATM 202 is stored in server 34. The same applications software can also be used by corresponding peripherals in other terminals of the network 200 that are linked to server 34. Thus, one advantage of this arrangement is that control applications software can be updated at the server 34 and all associated peripherals will download the updated software, thereby centralizing software upgrades.

In addition to link 204 providing a direct connection from each peripheral 216,218,220,222 to server 34, link 204 also enables communication to take place between the individual peripherals 216,218,220,222 of ATM 202. Thus information as to the operational state of any of the peripherals 216,218,220,222 can be transmitted to all of the other peripherals 216,218,220,222.

When a peripheral (e.g. 216) is first powered-up, it uses non-volatile memory to boot-up and then transmits a message to the server 34. On receiving this message, the server uploads software to the peripheral to enable the peripheral to initialize and begin the team-building process.

Although the hardware architecture of FIG. 11 is different to that of FIG. 8, the team-building process and subsequent operation, as described with reference to FIGS. 9 and 10, are the same for the two embodiments. FIG. 12 shows a typical functional group registry 150' for the embodiment of FIG. 11, where each peripheral in the terminal has a different IP address because the processor in each peripheral runs its associated control application.

During operation, a request may be made by a peripheral to the server 34 for information specific to the user and appropriate to conduct the current transaction. For example, the cash dispenser 220 will require the user's current balance to determine if the user has sufficient funds to cover a requested cash withdrawal. User interface 222 may require account balance and bank statement information to display these to the user.

By having a direct connection from the peripherals to the server 34 it is possible to avoid using a central processor and a mass storage device.

It will be appreciated that the function of the communications controller 58 illustrated in FIG. 9 may be incorporated into the central processor 138 (FIG. 8 embodiment) or may be incorporated into each peripheral 216,218,220,222 (FIG. 11 embodiment), or may be a separate network router that routes data from each peripheral 216,218,220,222 (FIG. 11 embodiment) to the server 34.

The individual control applications that operate within either hardware embodiment of the invention (FIG. 8 or FIG. 11) are arranged to operate as a team, with each application module being considered as a team member or peer.

Various modifications may be made to the above described embodiments within the scope of the present invention, for example, the communications link 104 may be any convenient link and may be part of a local area network or it may be a dedicated link having a dial-up modem connection. In other embodiments, such as for a single off-site terminal, the communication link 204 may be a low speed dial-up modem. In other embodiments, a communications mechanism other than an RS-232 link 136 may be used, for example, a USB (universal serial bus), Firewire, or Ethernet link may be used.

In embodiments where a retail point of sale (POS) terminal is used in a network, the legacy host may be a retail information database. In other embodiments, the addresses at which other peripherals may receive signals may be written into the control application for each peripheral so that each control application knows the address of its associated peripheral and all possible addresses of other peripherals. In other embodiments, a different communications protocol may be used, for example, an RS-232 based protocol may be used instead of TCP/IP.

EXAMPLE 4

Transaction networks comprise one or more transaction terminals connected to a server. A typical transaction terminal may be automated teller machine (ATM), a retail point-of-sale (POS) terminal, a self-service terminal (SST), or a transaction kiosk. ("SST" is a generalized term that would include transaction kiosks, POS terminals and ATMs.) FIG. 13 shows part of a conventional ATM network 310 in which an information database 312 (termed a legacy host) is connected to a server 314 by a communication cable 316. The server 314 is also connected to a terminal 318 having a central processor 320, typically PC-based, which controls the application flow (the order in which events may occur) and the associated user interface presentation for the terminal 318. The application files used by the application software are commonly stored on a hard disk 321 or other mass storage device within the terminal 318.

The network 310 is shown having one terminal 318, however, a plurality of other terminals, which may be of the same or of a different kind, may also be connected to the server 314. Simple client-server transactions are conducted between terminal 318 and the host 312 for obtaining specific customer information used in the processing of a customer's transaction. In the case of an ATM the transaction may typically be a cash withdrawal or a balance request. In the case of a retail POS terminal a typical transaction is a price lookup.

Terminal 318 includes peripheral devices 322 (referred to hereinafter as "peripherals") that are often very specific to the function of the terminal 18. Typical peripherals included in an ATM are a card reader, a cash dispenser, a receipt printer and an encrypting keyboard. These devices are generally provided with appropriate control software and require some form of embedded or local processing capability to conduct communications with the central processor 320 and to implement commands received therefrom.

Referring to FIG. 14, there is shown therein a transaction network 330 including a legacy host 312, a server 334 and an ATM 350. The server 334 is very similar to server 314, the main difference being that server 334 stores software modules (such as applications software and operating system software) for use by peripherals within the ATM 350. The ATM 350 has three peripherals 352, each having communications hardware 354. The communications hardware 354 in each peripheral 352 is directly connected to a communication port 333 in the server 334 by a separate communication medium 355 in the form of a data cable. The hardware 354, medium 355, and port 333 together form a communication link, so that each peripheral 352 has a separate communication link. However, having separate cables 355 connecting the server 334 to the peripherals 352 may be undesirable because of the proliferation of cables that would result from increasing the number of peripherals.

FIG. 15 is a block diagram of an ATM transaction network 360 in accordance with another embodiment of the invention. ATM network 360 includes an ATM 362 that contains four peripherals 364: a card reader 364a, a receipt printer 364b, a cash dispenser 364c, and a user interface 364d.

Each peripheral 364 has a network interface 366 (in the form of an Ethernet adapter, see FIG. 16) which is physically connected to a multiport router 368 by a network cable 370. The router 368 receives data on each of the cables 370 (from the peripherals 364) and concentrates this data onto a single cable 372 for transmission to the communication port 333 in the server 334. The communication port 333, Ethernet adapters 366, router 368, network cables 370, and cable 372 together form a sub-network 371 to which the peripherals 364 and the server 334 are connected. The sub-network 371 implements the TCP/IP protocol and allows open standard connection between each peripheral 364 and the server 334, and also between different peripherals (e.g. 364a and 364b).

Sub-network 371 thereby provides a communication link between a peripheral 364 and the server 334. Thus, there is a communication link for each peripheral 364, whereby each peripheral 64 is able to download software directly from the server 334.

Although the peripherals 364 are connected to the server 334 via the router 368, each peripheral 364 has independent access to the server 334 and is operable to download software modules directly therefrom (i.e. software modules are not first downloaded to an intermediate location and then copied to the peripherals 64 from the intermediate location). The router 368 does not store any software modules being downloaded, it merely facilitates downloading by managing the communication between the server 334 and the peripheral 364 which is downloading the software. It will be appreciated that the flow of information is two-way, a peripheral 364 being operable to transmit information to the server 334. It will also be appreciated that the ATM 362 has no mass storage device for permanently storing the downloaded software: all downloaded software is stored in memory. In this embodiment volatile memory is used; however, in an alternative embodiment non-volatile memory could cache downloaded software for immediate access on power-on with software updates being applied via the download process described.

Each type of peripheral (e.g. a card reader 364a) needs a different software module (or modules) to other types of peripherals (e.g. a receipt printer 364b); however, all peripherals of one type (e.g. all card readers 364a) need the same set of software modules. Therefore the server 334 stores a set of software modules for each type of peripheral (e.g. 364a) in the network 360; where a set of software modules may contain one or more software modules.

FIG. 16 shows a block diagram of one of the peripherals 364 of FIG. 3. The peripheral 364 has an Ethernet adapter 366 (which is the peripheral communication hardware) having a unique MAC address. The Ethernet adapter 366 implements the TCP/IP protocol, and is in electronic communication with an embedded processor 374. Processor 374 executes JAVA.RTM. code, and communicates with peripheral-specific control electronics 376 which controls the hardware 378 in the peripheral 364. For a card reader peripheral 364a, the hardware 378 includes the card transport mechanism and the magnetic stripe reader. The processor 374 also has associated volatile memory 380 in the form of DRAM and nonvolatile memory 382 in the form of FLASH EPROM.

When a peripheral 364 is first powered-up, it requires an IP (Internet protocol) address. IP addresses are supplied by the server 334 which implements an ARP (address resolution protocol) and DHCP (dynamic host control protocol) service for allocating an IP address to each peripheral 364 which is connected to the sub-network 371. DHCP is a standard protocol that provides a way of dynamically allocating IP addresses to processors in a network. A range of IP addresses is assigned to the DHCP and each processor is configured to request an IP address from the DHCP server. The request and grant process uses a lease concept with a controllable time period for the lease.

When a peripheral 364 is first powered-up, its processor 374 uses FLASH EPROM 382 to boot-up and broadcast a message requesting an IP address. The broadcast message contains the peripheral's MAC address and a special "broadcast address", which is "255.255.255.255". This broadcast address is a standard feature of the BOOTP protocol; it means, transmit to every device on the subnetwork 371 that a peripheral with enclosed MAC address requires an IP address. The server 334 receives this broadcast message; allocates an available IP address; and sends a grant message to the peripheral that requested the IP address (using the peripheral's MAC address), where the grant message contains the peripheral's IP address and the server's IP address.

The newly powered up peripheral 364 receives this grant message and now knows its IP address and the server's IP address. Using this information the peripheral 364 can access the server 334 and download an operating system using a simple protocol such as TFTP (Trivial File Transfer Protocol). Once the peripheral has downloaded an operating system (in this embodiment JAVA.RTM. OS) it can store this operating system in the FLASH EPROM 382. This has the advantage that when the peripheral 364 is powered-up again it can load the operating system directly from the EPROM 382; however, the peripheral 364 will still need to obtain an IP address from the server 334 using BOOTP.

When the peripheral 364 has received its IP address and its operating system, it can then use the TCP/IP protocol to download its applications software module from the server 334 to the volatile memory 380.

One advantage of using router 368 is that the router 368 can auto-detect how much bandwidth the Ethernet adapter 366 within each peripheral 364 requires (for example, whether it requires 10 Mbytes per second or 100 Mbytes per second). Most of the peripherals, for example, card reader 364a, receipt printer 364b, and cash dispenser 364c only receive large amounts of information (software) when they are downloading software modules; at other times they only send or receive small amounts of information; thus, these peripherals 364a,b,c can operate on a low bandwidth channel (10 Mbytes per second). However, the user interface peripheral 364d frequently downloads large amounts of information to update the display; so peripheral 364d operates using a high bandwidth channel (e.g., 100 Mbytes per second).

Another advantage of using a router 368 is that the router 368 may ensure that any messages that are sent by one peripheral (e.g. 364a) within the ATM 362 to another peripheral (e.g. 364b) within the same. ATM 362 are not transmitted to the server 334 or to any other terminal in the network 360. This reduces the amount of traffic on the network 360 without adversely affecting communication between peripherals 364.

When a peripheral 364 has downloaded all necessary software modules from the server 334 then it is ready for use by the terminal 362. The terminal 362 may use one of a number of possible application architectures. For example, in one architecture a master/slave relationship exists, where the user interface peripheral 364d is the master and the other peripherals 364a,b,c are the slaves. The user interface 364d controls the application flow and instructs the other peripherals 364a,b,c to carry out specific tasks (e.g. the card reader may be instructed to read a card, the receipt printer may be instructed to print a receipt) as required. The user interface 364d issues commands over the sub-network 371 using TCP/IP.

In an alternative architecture a peer to peer relationship exists between the peripherals 364a,b,c,d so that the peripherals 364 send message objects to each other to inform one another when significant application events occur. The peripherals 364 thereby operate in response to one another.

One advantage of the invention is that software upgrades are easily achieved by upgrading the software held on server 334 and restarting the peripherals 364 either directly at ATM 362 or via server 334. This allows for the remote administration of the entire transaction network 360 (which may include a large number of ATMs).

The ability of peripherals 364 within an ATM 362 to dynamically load required software modules provides for an efficient and easily controllable mechanism for supporting the required functionality. For example, if card reader 364a is to recognize different types of smart card and standard magnetic stripe cards then card reader 364a requires different software drivers depending on which type of card is inserted into the card reader 364a. These software drivers must be available and accessible to support the different types of electrical interfaces, data streams and communications protocols for each type of card.

By allowing the card reader 364a to download software modules from the server 334 as and when required the card reader 364 can load software modules during operation. Thus, if a user inserts a smart card, and the card reader 364a is currently configured for a magnetic stripe card (i.e. the card reader 364a has downloaded software driver modules for a magnetic stripe card), then the card reader 364a on detecting that the inserted card is a certain type of smart card will download the relevant software module for use in processing that type of smart card, as will be described with reference to FIG. 17.

The flow chart of FIG. 17 illustrates the steps implemented by a card detection software module for recognizing two types of smart card. On powering-up, the card reader 364a will download this card detection software module and also a card driver software module, which by default is the software module for a magnetic stripe card. The ATM 360 then waits for a card to be inserted.

On detecting that a card is being inserted into card reader 364a the card detection software module provides for the required electromechanical operation to receive the card (e.g. the opening of shutters and the energizing of drive motors as required) and then identifies the type of card that has been inserted in accordance with the flow chart of FIG. 17.

Conventional ATMs that can read more than one type of card require all of the necessary software driver modules for the types of card that can be read to be available at all times during operation of the ATM. This is implemented by the ATM storing all of the required software driver modules locally. However, in ATM 362 it is only necessary to store the card detection software module because the required software driver module can be downloaded when it is needed.

The card detection software module recognizes only two types of smart card; however, if it is desired to support additional types of card then, the card detection software module only needs to be increased in size by a small amount sufficient to support the extra decision block and card type identification. Conversely, a traditional card reader would need to have its program increased by the total size of the routines required to process the extra type of card or application embedded in the card. Similar considerations apply to other modules such as the receipt printer 364b and the cash dispenser 364c.

Referring to FIG. 17, the card detection software module awaits insertion of a card (step 402). Once a card has been inserted, the software detects the card and determines if the card is a type one smart card (step 404). If the card is a type one smart card then the processor 374 (see FIG. 16) downloads a type one software driver module (step 406) from the server 334. When the type one software has been successfully downloaded the ATM 362 (see FIG. 16) processes the transaction.

If the card is not a type one smart card then the software determines if the card is a type two smart card (step 408). If the card is a type two smart card then the processor 74 (see FIG. 16) downloads a type-two software driver module (step 410). When the type two software has been successfully downloaded the ATM 62 (see FIG. 16) processes the transaction.

If the card is neither a type one nor a type two smart card then the software module assumes that the card is a magnetic stripe card and uses (step 412) the magnetic stripe card driver software module (which in this embodiment is downloaded as the default driver). The ATM 62 (see FIG. 16) then processes the transaction.

In the embodiment of FIG. 15, the server 334 may provide Internet or Intranet access, thereby allowing the receipt printer 364b to load Web pages from the server 334, in addition to loading the appropriate printer driver software modules needed to support the graphics, fonts and other imagery in the downloaded Web pages. Such software modules may be resident in server 334 and loaded to the printer 64b only as and when required. These software modules consist of code and data, so it is possible to load individual graphic imagery, along with its own printer driver software, for customizing receipts, statements and the like. It may be desirable to customize receipts and/or statements to promote a certain product or brand, or for tailoring the receipt to the user. These graphic images are transitory: taking up memory space in the printer module 364b only for the duration of their task (e.g., until they have been used by the computer).

Since each peripheral 364 has an independent connection to server 334 through a communication link, the peripheral 364 can communicate directly and independently with the server 334 not only to download software modules therefrom, but also to obtain data specific to a current transaction while the transaction is taking place. For example a request may be made for information specific to the user and appropriate to conduct the current transaction. Thus, cash dispenser 364c may require the user's current balance for determining if the user has sufficient funds to cover a requested cash withdrawal. User interface 364d may require account balance and bank statement information for presenting to the user.

Since each peripheral in ATM 362 is individually connected to server 334 the latest version of a particular software module can be made available to all ATMs in the network 360 by loading the new version of the software module into the server 334. This does not require physical access to any of the terminals in the network 60. In addition, terminal-specific software modules can be made available at the server 334. Such terminal-specific software modules may comprise marketing messages for display at the ATM 362.

By having a direct connection from the peripherals 364 to the server 334 it is possible to allow the peripheral software applications to take a more active role in the overall operational flow of the ATM 362. This allows the user interface processor to concentrate on its primary task of providing user interface display graphics, animation and video facilities. The processing power required to operate individual peripherals 364 can then be selected to optimize the cost/performance ratio.

It is desirable to monitor the operation of the peripherals 364 and for this purpose various logs and hardware tallies can be provided for. The embedded processor 374 (see FIG. 16) in a peripheral 64 can be arranged to generate such logs and tallies for use with an embedded web server for reporting the results. Access points can be provided over the network 60 to allow for diagnostic operations including the downloading of monitoring information. The reports can be in HTML form thus allowing a standard Web browser to access the information.

Various modifications may be made to the above-described embodiments. For example, in other embodiments, an ATM may be used as a general multi-media dispenser, where the media to be dispensed ranges from paper (in the form of currency notes, tickets, and books of stamps) to plastics media (such as ski passes). This requires the ability to dispense media types having different dispensing characteristics (such as timing and control parameters). Appropriate software modules can be readily downloaded by a media dispenser from a server at run time without the need to store every possible driver software module in the terminal housing the dispenser. In other embodiments, a different network protocol (such as an RS-232 based protocol) and different boot-up protocols may be used. In other embodiments, different network architecture to that shown for sub-network 371 may be used, for example the router function may be implemented by one of the peripherals such as the user interface. The processor 374 may not include a JAVA.RTM. virtual machine but may execute native machine code.

EXAMPLE 5

Client/Server concepts are introduced, with some of the potential shortcomings of existing Thick Client technology such as local storage, configuration and excessive processor performance being illustrated.

The use of this technology within existing ATM's is considered, with centralized WinTel systems and under used SDC processors being illustrated. The concept of the Thin Client as a stateless, application processor that loads all of its applications and data from the network is described. With no local storage these devices are lower in cost than their Thick Client cousins and can be administered more easily from the network. The Informa software product which is intended to be Thin Client based is discussed. While this product is currently still PC Core based, it will use Java applications to allow for dynamic download and reconfiguration. The Ultra Thin Client concept is offered as an extension of Thin Client, whereby individual peripheral modules of an ATM or POS terminal can be implemented as Thin Clients, giving dynamic reconfiguration and more efficient dispersion of processing power.

A driving factor of this example of the invention is the emergence of processors that can execute Java byte codes directly in silicon. Existing techniques for running Java applications either involve large processors running the Java Virtual machine that interprets the byte codes or the use of Just In Time compilers. The first approach has poor performance while the latter requires increased amounts of memory, an important issue in embedded applications. By executing the Java byte codes directly in silicon, performance can be regained without requiring excessive amounts of memory. The core silicon (picoJava) can be included in embedded Java processors.

The use of such processors in creating an Ultra Thin Client architecture is described. The Intel 8051 series processors and proprietary SDC used in ATM peripheral module control can be replaced by Java processors and industry standard TCP/IP networking to produce networked modules that could be connected together in combination with a Network Computer style user interface in order to provide a fully operational self-service terminal. The use of the same architecture within a Point of Sale terminal is illustrated to indicate the potential for retail transaction systems.

Various potential implementations of UTC are illustrated including the use of picoJava core silicon within a networked dispenser controller that could provide an industry standard module for use within transaction processing terminals of various vendors. Peripheral modules such as card readers and receipt printers could use discrete Java processors while various levels of user interface modules could be used dependent upon the level of display performance required for the application being provided.

In terms of software architectures, UTC can use standard Thin Client and Java techniques to load the Java OS and application code from the network. Traditional application architectures such as Master/Slave can be supported within UTC through techniques such as Remote Method Invocation, although this can reduce the effect of having disparate processing elements that are capable of running their own sections of the application as is presently preferred. Mechanisms for accessing legacy data and for supporting State of Health functioning through embedded servers and mobile intelligent agents can be incorporated.

Thin Client technology is a new form of computing architecture that is evolving within many Enterprise Information Systems as a replacement for existing Thick Client approaches. Thin Client uses fast networks and powerful servers to support Network Computers that are stateless, application processing systems permanently connected to the network. Proponents of the Thin Client and NC concepts claim that considerable improvements in the total cost of ownership of client end point terminals can be achieved within the enterprise information system context. These cost reductions occur through lower hardware costs plus savings in administration costs through the centralizing of applications and data.

Thick Client Architectures

Commercial transaction terminals such as ATMs have generally used a Thick Client architecture, whereby all of the application and driver software is stored locally to the terminal and is loaded to memory at start of day. Transient data used in transaction processing is obtained over dial up, high order communications or network connections to the legacy host.

Thick Client PCs are typically based upon the WinTel architecture (Windows Software such as Windows NT on Intel processors such as Pentium processors).

The Thick Client ATM's central processor is responsible for all application control, peripheral control, external communications, graphics and state of Health monitoring and reporting with a large, generalized processor being used to conduct all of these tasks. This solution is not the optimum for any of the tasks and requires a powerful enough processor to conduct them all through brute force. This requires a relatively large and costly processor.

This ATM architecture requires that a large central application control the user interface facilities of the terminal as well as controlling the disparate peripherals employed. Within Thick Client ATMs these, e.g., SDC based, peripherals generally already have processors of their own which are used for little more than hardware control and simple command processing.

The Thick Client models' use of terminal resident applications raises other issues. The local storage of all operating system software, device drivers, applications and data adds a unit cost for local storage media whether hard/flex disks or CD-ROM drives. There are also additional administration costs associated with upgrading applications that are becoming more significant as financial institutions see the benefits in having dynamic content on their ATMs as their primary interface to the consumer.

In its defense, however, the Thick Client architecture is well suited to traditional bank networks that use transactional based messaging to legacy hosts over the ATM Switch.

Thin Client Architectures

An alternative Thin Client model architecture has been introduced based upon the premise that all applications and their data are stored within the network and that client end points will load only those application and data segments necessary for the task at hand. The emerging Java networked computing environment is ideally suited for this. Its object oriented model splits applications into individual object classes that can be loaded over the network from a central server as they are required.

Thin Client or Network Computers (NCs) require no local storage capabilities thus reducing their initial cost. As all applications are stored at centralized locations and loaded to the Client on demand administration costs are reduced. The ability to provide upgrades and to introduce more dynamic content is also improved through this networked approach.

Thin Client technology has been implemented, for example for Informa based point of sale terminals. With peripherals including an LCD display, touch screen and card reader, this type of counter top system is intended to provide customer information and store loyalty card checking facilities. POS product versions may also have, e.g., receipt printer, cash drawer and bar code scanner capabilities. Informa may use a PC core as it's central processor running a Java VM (Virtual Machine) to allow Java based applications to be loaded from a retail branch network. Peripheral modules such as card readers and bar code scanners may be connected to the platform using serial or USB connections

While such systems are still based upon a single central processor, it operates in a Thin Client mode with all applications being loaded over the retail store network from central servers. This approach assumes that an in-branch networked environment or Intranet exists, using Internet (e.g., TCP/IP) protocols.

The Thin Client architecture still requires a centralized application to present the user interface and control the peripherals. However, through the use of a Java VM, applications can be dynamically downloaded from the network. This allows for easier upgrades and allows the functionality of these terminals to be configured from a central location. In this way the administrator can turn a point of sale terminal into a Customer Information Terminal simply by issuing a new application.

Ultra Thin Client Architectures

In accordance with this invention, an Ultra Thin Client approach applies Thin Client concepts to the individual components and peripheral modules of a transaction terminal, such as an ATM, SST or POS terminal, with individual peripheral modules loading and running their own applications (e.g., Java applications) from the network. This concept is being made more attractive through the introduction of embedded Java processors. These allow the direct execution of Java applications in silicon rather through Virtual Machines and would load their application code from the network as with any other Network Computer. This approach reaps all the benefits of Thin Clients in terms of such things as software administration while the emerging Java processors allow for the application of the optimal processing power for the module concerned. The potential for these Java processors is considered first followed by the hardware and software architectures for the Ultra Thin Client model.

Java Processors

While Java is still a very young language there are various indications such as its use within Informa platforms and published white papers that there is a great deal of potential for Java not only as a programming language but also as an operating environment, based on the availability of embedded or other low cost Java specific processors.

While Java can be run on any processor and operating system through the use of an appropriate Virtual Machine, the Java byte codes are still only being interpreted causing a performance penalty against compiled, native code. By using processors that are specially designed to execute the Java byte codes directly, performance can be regained.

In accordance with the invention, the proposed Ultra Thin Client architecture would preferably use Java processors within each of the peripheral modules of a terminal. Rather than running Java applications on a Virtual Machine implemented on some general-purpose processor, the Java byte codes could be executed directly on the Java processor running the module.

Java in Silicon

Java byte codes can either be run through an interpreter (see FIG. 18, Case 1), which considerably slows down execution, or a Just In Time (JIT) compiler can be used, speeding up execution but expanding the code size by a factor of three or more (see FIG. 18, Case 2 ). The JIT approach is problematic in the memory-restricted environment involved in embedded applications, while interpreted code performance is poor.

An alternative approach is to execute the Java byte codes directly in silicon or through microcode and software traps. A Java CPU (processor) provides an environment in which to run Java with equivalent performance to native code without requiring excessive amounts of memory (see FIG. 18, Case 3 ). The Java CPU would run the Java OS (operating system), which presently requires about 512 KB ROM/128 KB RAM for memory and includes elements such as the class loader, byte code verifier, thread manager, constant pool resolution and garbage collector. Application byte codes are loaded by the Java OS and executed directly on the Java CPU.

Java Byte Codes are generally 8 bit opcodes with 0 or more operands. On average 1.8 bytes are required per instruction (a typical RISC processor requires 4 bytes per instruction). The Java CPU hard codes 85% of the opcodes with 14% being microcoded or implemented through state machines. The remaining 1% are trapped to software and emulated. Six new opcodes provide for hardware access.

PicoJava Cores

The basic core silicon for Java processors is known as "picoJava." This silicon description can be licensed from Sun Microsystems for use in various designs and it is presently used as the basis for embedded Java and other Java processors.

FIG. 19 illustrates the picoJava Core. The amounts of instruction and data cache provided in a design can be configured as can the inclusion of a floating-point data path. This allows for flexibility in terms of performance, silicon area used, cost, etc., allowing the optimum price/performance to be achieved for each embedded application.

PicoJava as a silicon description can be integrated with appropriate hardware control elements in order to provide a customized, embedded processor.

MicroJava Processor Series

The first level of true Java processor is code-named "microjava" and this combines picoJava with the other components necessary to provide a functional processor. Different performance and configuration levels will allow the systems designer to choose the optimal configuration for each application, ranging from corporate network computers (NCs) through consumer set top boxes to embedded industrial control applications.

MicroJava 700 Series Processors

The microJava 700 series processors, a block diagram for which is shown in FIG. 20, are intended for use in the corporate NC market. Through an industry standard PCI bus these processors can be connected to standard Ethernet chips, peripheral I/O and graphics adapters in order to provide a complete Network Computer.

MicroJava 701 Specifications:

200 MHz picoJava Core.

16K Data Cache.

8K Instruction Cache.

Floating Point Unit (from SparcII).

Power Management.

8 Interrupts.

32 bit/33 MHz PCI Bus.

SDRAM/EDO/DRAM Controllers.

Flash ROM Controller.

MicroJava 500 Series Processors

The microJava 500 series processors a block diagram for which is shown in FIG. 21, are intended for use in the consumer NC market and for set top boxes and DVD systems. While still based on the picojava core, the 500 series aims to integrate as much of the display and peripheral I/0 as possible into the silicon in order to provide high performance parts that can be made very cheaply due to the high volumes associated with the consumer market. The 500 series is targeted at modem technology rather than Ethernet and supports both TV and SVGA displays, again placing this device in the consumer market.

MicroJava 501 Specifications:

66/125 MHz picoJava core.

4K/2K Data/Instruction Cache.

Limited FPU.

PCI Bus.

SDRAM, Flash ROM.

Keyboard, Mouse, Serial Port.

High Speed Serial Port, Parallel Port.

SVGA (RGB) PAL/NTSC.

2D Graphics, CLUT/RAMDAC.

MicroJava 300 Series Java Processors

The microJava 300 series processors are intended for use within the industrial control market. These processors may closely integrate picojava core processing with Ethernet communications in order to provide for easily networked control processors. Such processors may be used in instrumentation and embedded control functions that do not require user interface display capabilities. This class of Java processor would be ideal for transaction terminal modules such as card readers and receipt printers.

ATM Terminal Modules

The peripheral modules that make up commercial Self Service Terminals such as card readers, dispensers, receipt printers etc., have used Intel 8051 series microprocessors. These are somewhat under used at present, being used for simple hardware control and command processing. An SDC communications structure upon which a number of these modules are based was developed some 10 years ago when no appropriate standards existed and this proprietary mechanism has precluded the ready use of these modules in other systems.

By embedding Java processors, either as off the shelf components (microjava 300 Series) or by using the picojava core to build module specific embedded processors, as for chip sets used in the dispenser module, it would be ideal for implementing an ATM as a series of networked modules. These Ultra Thin Client modules could be based upon industry standard TCP/IP network protocols allowing for dynamic download of Java based applications. As industry standards could be used rather than the proprietary SDC, there would be a greater potential for sharing of common modules within products of various manufacturers.

Ultra Thin Client Hardware Architectures

In accordance with the invention, the Ultra Thin Client architecture as applied within Self Service Terminals reduces the Thin Client concept to the level of the individual peripheral modules of the terminal such as the card reader or user interface. Appropriate Java based cores can conveniently operate each module as a networked component, with these components being networked together in order to create the larger terminal system.

This networked peripheral architecture allows for a highly configurable terminal architecture that allows various modules to be combined together to form simple information and point of sale terminals, through limited and full function ATMs to self service checkout terminals.

Networked Modules

In order to implement the Ultra Thin Client architecture within transaction terminals, individual terminal modules could be implemented so as to run Java applications over a TCP/IP network. FIG. 22 illustrates how a networked peripheral device or module could be constructed by combining a Java Processing core with module specific control electronics and physical hardware.

Existing RS-232 and SDC implementations of peripheral modules could be modified by retaining the modules physical hardware and control electronics and replacing the RS-232/SDC command processors with Java Cores and TCP/IP network communications.

Each module could thus operate as a Thin Client, loading its application software from the central network as necessary. Splitting up the functions of a given system into its constituent modules in this way allows the modules to operate over open standards such as TCP/IP.

Networked Peripheral Architecture

In order to construct an SST or POS Point of Sale terminal from these networked modules, it is possible to connect together a set of peripherals appropriate to the functions required.

FIG. 23 illustrates how an ATM can be created by connecting user interface, card reader, receipt printer and dispenser modules together. Mechanically the modules may remain as they are currently with a TCP/IP sub-net being created within the terminal to allow for an open standard connection between all of the modules. A router within the terminal can concentrate the individual network lines into a single TCP/IP connection to the branch network.

This Ultra Thin Client architecture can be easily used across different environments, allowing common modules and components being sourced in higher volumes and at a reduced cost. Using the user interface, card reader and receipt printer from an ATM system combined, e.g., with a bar code scanner module, the same ATM system modules and control software with similar applications could provide a POS terminal, as illustrated in FIG. 24. The retail store network can provide the necessary environment for the download of software and for connecting to stock and pricing information.

Networked Peripheral Implementations

There are a number of ways in which individual Ultra Thin Client, networked peripherals might be implemented dependent upon the capabilities and level of performance required.

Cash Dispenser Modules

Current implementations of the dispenser have used the proprietary SDC communication protocol using, for example, a Dance/Disco chip set that integrates Intel 8051 series core silicon with custom dispenser control electronics. These chips provide for highly integrated SDC peripheral functioning. Simpler and less proprietary RS-232 based dispenser controllers are also being developed, e.g., with appropriate drivers being written for operating systems such as Windows NT and OS/2.

Proprietary or high cost chip-sets and supporting SDC communications systems can be replaced by integrating a picoJava core with the dispenser control electronics and network electronics for an Ultra Thin Client architecture using Java Bean interface classes. This would provide a networked connection that could be integrated with NC technology for use in ATMs, teller stations and other kiosk and POS applications. A Java processor chip set for the cash dispenser would accordingly allow an industry standard networked dispenser module to be created.

Non-Display Modules

Modules such as card readers and receipt printers do not generally require display processing capabilities, just embedded Java processing. Proprietary SDC based controller cards have been used to operate such devices within current platforms.

Similar networked, Java controller cards can be used as direct replacements for such SDC controllers. These could use embedded Java processors, e.g., from the microjava 300 Series, which will preferably integrate Java processing and Ethernet connectivity. The selection of the appropriate microJava processor would allow the price/performance of each module to be tuned dependent upon the module's processing requirements.

User Interface Modules

The user interface is generally an every unit item and generally a dominant part of any transaction terminal application, no matter what application architecture is used.

Some form of user interface is a common component for all self-service and POS terminals, although different terminal types often require different display and keyboard configurations. In traditional systems, the user interface is driven directly from the central processor of the terminal; however, within the Ultra Thin Client environment, the user interface can be seen as just another one of the modules that go to make up the terminal. This has the advantage that the user interface module can be relieved of the responsibilities for state of health management (as individual modules can be made to take that on for themselves). A modular approach allows various levels of display performance to be created that can better align the price, performance and functionality required for each terminal.

Self Service Terminals

In terms of self-service terminals where the need is for a medium to large display device, either based upon a CRT or an LCD, a VGA/SVGA capable user interface module can be required. For simpler display capabilities such as text or limited graphics on monochrome displays lower performance Java processors can be suitable, as only a small amount of processing power would be required for display purposes. For more complex graphical applications with color graphics and animation, the set top box or higher level NC processors may be appropriate to provide sufficient performance for these extended display capabilities.

Video Kiosks

Where video enabled applications were to be provided, either to support video conferencing or as video playback for advertising purposes a PC based approach with a Java Virtual Machine would allow appropriate video processing cards to be added in order to provide an appropriate solution. Alternative platforms, similar to Sun Microsystems' Java Engine 1, may incorporate MPEG video capabilities with high levels of Java performance for use in multimedia kiosk applications.

Point of Sale Terminals

POS terminals that provide SST level display (e.g., by way of self-service, interactive terminals). Such systems may require equivalent processing capabilities to those of SSTs and can readily be implemented using the Ultra Thin Client architecture approach.

Cash Registers/Operator Interfaces

Where non VGA displays are required, such as character/graphic LCD panels used in operat