CN100382071C - Automated Banking Machines and Systems - Google Patents

Abstract

The automated banking machine (12) responds to the HTML documents and TCP/IP messages exchanged with the local computer system (14) through the internal network (16) and responds to foreign servers (20, 22, 24, 26, 28, 96) exchanged messages can be effectively traded. The banking machine includes a computer (34) having an HTML document processing section (76, 80, 82). The HTML document processing part effectively communicates with the local HTTP server (90) in the internal network through the proxy server (88), or with the foreign server in the wide area network. The computer also includes a device application portion (84) that sends messages to operate the device (36) within the automated banking machine.

Description

Automated Banking Machines and Systems

technical field

The present invention relates to automated banking machines. In particular, the present invention relates to equipment and systems for automated banking machines that can be used in wide-area networks. The present invention can provide customers with familiar interfaces from the user's local institution to banking machines operated by other institutions, and provide a relatively simple output for the machine. The ability to choose from.

Background technique

Automated banking machines are well known. One common type of automated banking machine used by customers is an automated teller machine. Automated teller machines allow customers to conduct banking transactions. Common banking transactions that can be performed with an automated teller machine include dispensing cash, deposits, transfer of funds between accounts, bill payments and inquiries about account balances. The types of banking transactions a customer can perform depend on the capabilities of the particular banking machine and the programming of the financial institution operating the machine. Other types of automated banking machines allow transfers or transfers of funds for customers. Other automated banking machine types can print or issue items of value such as: coupons for bonds etc., bills, policies, vouchers, checks, food stamps, money orders, temporary certificates or traveler's checks. For purposes of describing the present invention, an automated banking machine or automated transaction (transaction) machine will possess any device that can conduct a transaction including the transfer of value.

Current ATMs operate within proprietary communication networks. These networks will be interconnected by automated teller machines operated by financial institutions and other organizations. If the foreign (foreign) institution's banking machine is interconnected with networks including the user's institution, the interconnection of these networks often allows the user to utilize a banking machine operated by another institution. However, when a customer operates a machine of a foreign institution, the customer must operate the machine using a customer interface developed by the foreign institution for its banking machine. In addition, customers are limited by the trading options offered by foreign (foreign) institutions.

When customers use a foreign institution's banking machine, they will encounter various difficulties. These problems arose due to the customer's unfamiliarity with the types of machines operated by foreign establishments. Difficulties can often arise because the customer does not know which button to press or which part to actuate to complete the desired transaction. The transaction flow on a foreign institution's machine may be significantly different from the transaction flow on a machine operated by a client's local institution. This is especially problematic when users from other countries are not familiar with the type of banking machine or the interface language provided by the foreign institution. Likewise, information printed on a printer within an automated banking machine is usually limited to a limited number of prescribed formats in a single language.

A foreign institution may also offer transactions of a different type than the client is familiar with at a local institution. For example, a customer's local institution may transfer funds between accounts for the customer through their automated banking machine, enabling the user to hold their funds in a higher interest account until needed. If the foreign organization does not have this ability, it cannot be done when the user operates the foreign machine. This becomes problematic when users cannot perform the transactions they are accustomed to on foreign machines.

Networks operating automated teller machines or other types of automated banking machines typically operate private networks to which access is restricted. This is necessary to prevent fraud or tampering with the network or users' accounts. Private networks are also generally used to transmit credit card messages and other financial transaction messages. Access to these credit card processing systems is also restricted, primarily for security purposes.

Communication over a wide area network enables the transfer of messages between remote locations. The best known wide area network is the Internet (Internet), which can be used to provide communication between computers throughout the world. Because the Internet is not a secure system, it is not widely used for financial transaction messages. Messages intended to be received at a particular computer address may be intercepted at other addresses without detection. This is a source of potential fraud and corruption as messages may be intercepted at locations on Earth other than the intended receiving location.

Many companies have begun to provide methods for relatively secure message transmission over the Internet. Encryption techniques are also used for Internet messages. However, the open nature of the Internet has limited its use for financial messaging, particularly financial messaging related to the operation of automated banking machines.

Messages within the WAN may be transmitted using Transmission Control Protocol/Internet Protocol ("TCP/IP"). In the example of a system presented in US Patent No. 5,706,422, financial information stored in a database is accessed through a private wide area network using TCP/IP packets. Messages transmitted over the network using TCP/IP as described above may include "documents" (also referred to as pages). These documents are generated in Hypertext Markup Language ("HTML"), which refers to a programming language used to generate documents with instructions or identifiers ("tags"). Identifiers are codes that specify the characteristics and/or usage of a document, such as font style, page layout, embedded graphics, and hypertext links (links). HTML documents are processed or read by using a computer program called a "browser". When a document is processed, the identifier tells the browser how to process and control what is seen on the screen and/or heard in the speakers connected to the computer running the browser. HTML documents may be transmitted via the Hypertext Transfer Protocol ("HTTP") over a network communication channel. The term "hypertext" refers to the ability to embed linking instructions into the text of a document that allow communication with other documents accessible on the network.

Therefore, there is a need for an automated banking machine and system that can be applied over a wide area network such as the Internet while providing a high level of security. There also exists a need for an automated banking machine and system that, when operating a machine at a foreign institution, can provide the user with the interface and transaction options that the user is familiar with using a local institution. There is also a need for a machine that can provide users with more transaction options and types of initiatives as well as printed materials.

Contents of the invention

The purpose of the present invention is to provide users with an automated banking machine capable of conducting transactions.

Another object of the present invention is to provide an automated banking machine which is connected to and operated by a wide area network.

It is yet another object of the present invention to provide an automated banking machine and system that will provide users with familiar interfaces and transaction options when using a machine operated by a foreign institution on a machine operated by a foreign institution.

Yet another object of the present invention is to provide an automated banking machine that communicates using HTML documents and TCP/IP messages.

Yet another object of the present invention is to provide an automated banking machine that responds to user input of indicia on a card, through generated HTML documents and TCP/IP messages, thereby allowing the banking machine to interface with the user's local institution.

Another object of the present invention is to provide an automated banking machine and system that can complete transactions over a wide area network while maintaining a high degree of confidentiality (security).

Another object of the present invention is to provide an automated banking machine and system which controls the connection between the banking machine and foreign addresses through a proxy server.

Another object of the present invention is to provide an automated banking machine which can limit the operation of the devices within the machine through a local device server.

Another object of the present invention is to provide an automated banking machine and system which operates through its connection to the Internet.

Another object of the present invention is to provide an automated banking machine which can provide users with more message types including messages targeted at specific users.

Another object of the present invention is to provide an automated banking machine, which can provide customers with various printed materials.

Another object of the present invention is to provide an automated banking machine with the additional option of identifying a user.

Yet another object of the present invention is to provide an automated banking machine that can be used to interface with existing transaction systems while providing multiple machine functions.

Yet another object of the present invention is to provide an automated banking machine with high diagnostic and service capabilities.

Yet another object of the present invention is to provide an automated banking machine which can execute transactions quickly.

Another object of the present invention is to provide an improved system for using automated banking machines.

It is a further object of the present invention to provide improved methods of operation of automated banking machines and systems.

Other objects of the present invention will become clearer through the following best mode for carrying out the present invention and the description in the appended claims.

In a preferred embodiment of the invention, the foregoing objects are achieved by an automated banking machine comprising an output device such as a display screen, and an input device such as a touch screen or a keyboard. The banking machine also includes some equipment for completing banking transactions by the machine, such as a currency dispensing mechanism, a printing mechanism, a card reader/recorder, a depository mechanism and other banking transaction functions performed by the machine.

The banking machine also includes a computer, which is effectively linked with the output device and the input device, and is also effectively linked with the paper dispensing mechanism, the card reader and other actual transaction function equipment in the banking machine. A computer includes an executable software program. The software program includes an HTML document processing part. The HTML document processing part plays the role of transmitting and receiving HTML documents and HTTP messages. The HTML document processing portion is preferably connected to an output device for displaying screens containing hypertext link indicators. The HTML document processing portion is also preferably connected to an input device to allow the customer to make selections and generate a response message through the computer. The HTML document processing portion preferably runs in a JAVA software environment and has the ability to execute instructions written in the JAVA language that are delivered with the HTML document in a script.

The software inside the computer preferably also includes a device application part. The Device Applications section includes software to efficiently control paper dispensers and other devices. In the preferred embodiment of the present invention, the device application portion includes a number of JAVA applets for operating the built-in device.

The computer within the automated banking machine also includes a device interface software portion. The device interface software part manages the messages received from the device application part and causes the built-in device to operate through the appropriate hardware interface. In a preferred embodiment of an automated banking machine, the HTML document processing portion, the device application portion and the device interface software portion each reside in the same computer and communicate at different IP ports.

In one configuration (configuration) of the automated banking machine of the present invention, communication is carried out using TCP/IP messages within an internal network comprising many of the automated banking machines described above. This internal network in turn connects at least one computer operated by the local institution. The local institution is the one operating the banking machine.

The computer at the local institution preferably includes a local HTTP server, a proxy server and a device server. The proxy server communicates with the HTML document processing portion of the software within each banking machine via the internal network. Proxy servers can also be connected to a wide area network, such as the Internet to which foreign servers are connected. The device server can effectively transmit messages between the device application part and the device interface software part of the banking machine. The device server may contain supervisor software for monitoring and selectively restricting the use and operation of the devices within the banking machine. This provides a certain level of confidentiality.

Automated banking machines and systems efficiently connect customers with institutions with their accounts. This could be a local institution operating a banking machine at the customer's location, or a foreign institution connected to a wide area network. When using a banking machine, a customer inputs an address corresponding to, for example, a URL address (Uniform Resource Address) through an address input device. The HTML document processing portion controls the connection of the banking machine to the server corresponding to the address. This is preferably accomplished by indicia representing the address on the user's card through a card reader in the banking machine or through other input devices that identify the user or the institution or entity with which the user has an account.

In response to the address or other input data on the card, the HTML document processing part connects to the user's institution via a proxy server. If the user's home institution address matches the local server, the banking machine operates in response to messages from the local server. However, if the user's input address corresponds to the address of the foreign server, then the proxy server effectively communicates with the foreign server at the client's local institution via the wide area network. If the client connects the machine to a server operated by a foreign institution, the HTML documents delivered from the foreign institution correspond to those normally provided by the foreign institution. Therefore, the customer is familiar with the interface generated by these documents, and can operate the banking machine more conveniently.

The foreign server or the local server runs the banking machine by delivering an HTML document that includes some instructions for operating the equipment inside the banking machine. These instructions are sent by the HTML document processing part to the device application part of the software. The device operates in response to these instructions. Some instructions from the device application to the device within the automated banking machine are transmitted through the device server at the local institution. This helps maintain confidentiality. In addition, proxy servers include blocking software that restricts foreign servers from connecting to banking machines and operating banking machines. This shielding effect is called a "firewall".

Embodiments of the present invention also provide an enhanced user interface and can use the banking machine to provide printing of various materials. The present invention can also use existing transaction networks and automated banking machines to perform enhanced functions.

Description of drawings

Fig. 1 is a schematic diagram of a network configuration, which includes the equipment and system of the automated banking machine of the present invention.

Figure 2 is a schematic diagram of a preferred embodiment of the automated banking machine of the present invention.

Figures 3-24 show schematic diagrams of the automated banking machine, an internal network connecting the local bank's computer system to the banking machine, and a wide area network connecting the local bank's computer system to the foreign bank.

Figures 3 to 18 schematically represent the steps of implementing a transaction on a banking machine with a local bank's computer system.

Figures 19-24 schematically show the various steps of conducting transactions with the foreign bank computer system on the banking machine.

Figure 25 is a schematic diagram of a network configuration that includes another embodiment of the automated banking machine of the present invention.

FIG. 26 shows a schematic diagram of frames within the HTML document processing portion of another embodiment of the automated banking machine shown in FIG. 25. FIG.

Figure 27 is a schematic illustration of the customer interface of the automated banking machine and the function keys and keypad keys included in the interface.

28-30 illustrate exemplary steps for converting function key and keypad key input into keyboard stream and mouse stream input.

Figure 31 schematically shows exemplary steps for printing materials with an automated banking machine.

Detailed ways

Referring now to the drawings and in particular to FIG. 1, numeral 10 schematically indicates a network configuration which includes the apparatus and system of an automated banking machine according to a preferred embodiment of the present invention. Network 10 includes a plurality of automated banking machines 12, which in the preferred embodiment of the invention are automated teller machines. The automated teller machine 12 is connected to the computer system 14 of the local bank. The local bank computer system 14 is a computer system operated by the bank or other institution that has primary responsibility for the automated teller machine 12 . The local bank computer system 14 is connected to the automated teller machine 12 via an internal network 16 . Internal network 16 is preferably a regional or private network that provides communications between computer system 14 and banking machine 12 using Transmission Control Protocol/Internet Protocol ("TCP/IP") formatted messages.

Messages communicated over internal network 16 are preferably TCP/IP messages and Hypertext Markup Language ("HTML") documents. In a preferred embodiment of the present invention, the HTML documents delivered over the intranet 16 include embedded object-oriented programming instructions, preferably in the JAVA( ^R ) format developed by Sun Microsystems. Messages transmitted through the internal network 16 can be transmitted in a confidential or unencrypted manner according to the nature of the system and the security requirements of the local bank.

It should be understood that embodiments of the invention can process documents in other formats that include markup or instructions therein. For example, an "extended" HTML format was recently proposed that can be used in embodiments of the present invention. For the purposes of the present invention, all formats of these languages and their variants that contain documents, and documents containing instructions therein will be referred to as HTML documents. Also, although JAVA(R) is used in the described embodiment, other programming languages may be used. For example, Active-X ^(TM) developed by Microsoft Corporation or other languages may be used in other embodiments. Furthermore, it should be understood that instructions contained within a document are effective to cause the computer to access other documents, records or files at other locations in order to obtain the program and operate on it.

The local bank computer systems 14 may also be connected by a wide area network 18 as shown in FIG. 1 . In some embodiments of the invention, wide area network (WAN) 18 is the Internet. Other wide area networks may be used in other embodiments of the invention. The wide area network is preferably capable of transporting TCP/IP packets between the many computer systems connected to the wide area network. These foreign computer systems are represented schematically by servers 20, 22, 24, 26 and 28 in the figure. It should be understood that servers 20-28 may be operated by or connected to other financial institutions around the world. Servers 20-28 preferably operate by delivering HTML documents and other HTTP messages.

FIG. 2 is a schematic diagram of the automated teller machine 12 used in a preferred embodiment of the present invention. The ATM 12 includes a touch screen 30 . The touch screen 30 comprises a display screen which is used as an output device for communicating with the user of the machine. Since the touch screen 30 is a touch screen, it can also be used as an input device for receiving user input instructions. The touch screen 30 is connected via an interface 32 to a computer 34, preferably housed inside the machine. Other embodiments of the invention may include other output devices such as speakers.

The computer 34 is also connected to a number of transaction processing functions 36 contained within the automated teller machine 12 . Device 36 includes, for example, a card reader/writer mechanism 38 and a keypad 40 . The apparatus 36 also includes a sheet dispensing mechanism 42 for operatively dispensing sheets, which in some preferred embodiments of the invention are currency or banknotes. The device 36 also includes a storage mechanism 44 for receiving deposits in a secure location within the machine. Also included in the device 36 is a receipt printer 46 for providing transaction receipts to the user. Also included in the device 36 is a journal printer 48 that maintains a hard copy (replica) of the transaction information. In other embodiments, other or additional transaction function devices that perform other transaction functions may be used. Still other embodiments have fewer functional devices. It must also be understood that although the described embodiment of the invention is an automated banking machine, the principles of the invention can be applied to many other transaction machines and are not necessarily limited to machines for conducting banking transactions.

Within banking machine 12, each device is operatively connected to an internal control bus 50. The control bus 50 outputs internal messages to specific devices. Each device has a suitable hardware interface which enables the particular device to perform its associated function in response to messages sent to it over control bus 50. The card reader/writer 38 has a hardware interface indicated schematically at 52 in the figure. Hardware interfaces 54, 56, 58, 60 and 62 operatively connect keyboard 40, paper dispensing mechanism 42, storage mechanism 44, receipt printing mechanism 46 and journal entry printing mechanism 48, respectively, to control bus 50.

The computer 34 has a number of executable software programs within it. In the preferred embodiment of the present invention, these software programs include a device interface software portion indicated generally at 64 . The device interface software portion 64 preferably includes a software device interface 66 for intercommunicating electronic messages with the control bus 50 . The device interface software portion 64 preferably also includes a device manager 68 . The device manager preferably efficiently manages the various devices 36 and controls their different states to ensure that they in turn operate properly. The device manager is also preferably practicable to create device objects within software to enable operation of the device via at least one object-oriented program 70 . The device interface software portion 64 also includes the object-oriented programming portion 70, which in a preferred embodiment is an application program written in the Java language. Program 70 works with the device manager to receive object-oriented JAVA messages that cause the device to run, and to pass device run messages to indicate that the device is running and/or to receive input data.

In the illustrated embodiment, the device interface software portion 64 runs on the computer 34 and interconnects with the internal network 16 via an actual TCP/IP 72 connection. The actual connection 72 may be an analog dial-up, serial port and ISDN connection or other suitable connection. In the configuration of the system as shown, the device interface software portion 64 differs from other software implementations in that this portion 64 communicates at the IP address and IP port of the computer 34 or the reporting interface indicated by reference numeral 74 . In other embodiments of the present invention, the device interface software portion 64 may run on a computer using other software than that of the present invention.

It must also be understood that although in one embodiment of the invention the device interface portion 64 is software, in other embodiments of the invention all or some of the instruction steps performed by the software portion 64 may reside in firmware or reside in in the program medium of one or more computers in communication with device 36 . For purposes of this invention, all such formats of executable instructions will be referred to as software.

Other software may also run within computer 34 . Such software includes HTML document processing software including a browser, indicated schematically at 76 in the figure. In the preferred embodiment of the present invention, the HTML document processing software includes a browser provided by Netscape Corporation. However, in other embodiments, other HTML document processing and communication software and browser software can be used, such as Hot JAVA( ^R) from Sun Microsystems or Internet Explorer( ^TM ) software from Microsoft . The browser 76 communicates within the computer 34 at an IP port indicated at 78 .

The browser 76 is effectively linked with the JAVA environment software 80, allowing the computer 34 to run JAVA language programs. JAVA language programs have an advantage that they can be run equally on various hardware platforms without modification. This "write once, run anywhere" capability makes the JAVA environment well suited for the embodiments described herein. However other embodiments may use different types of software programs.

JAVA environment software 80 allows computer 34 to execute instructions written in JAVA scripting language 82 . The instructions written in the JAVA scripting language for execution by the computer are preferably embedded JAVA scripting language commands contained within HTML documents which are received via the browser 76 . The browser 76 is connected with the JAVA environment software 80 that executes the embedded JAVA script language 82 instructions, and this browser 76 plays the role of transmitting and receiving HTML documents and TCP/IP messages through the IP port 78 to the HTML document processing software part.

The computer 34 also has executable software therein, and has a device application portion 84 . Device application portion 84 contains executable instructions related to 36 operation. In a preferred embodiment of the present invention, the application portion of the device includes a number of JAVA applets. In the described embodiment, these applets are also preferred programs, practicable to control and track the state of the device associated with the applets. Some applets are preferentially used to make the browser pass the message. Certain applets manage the security and confidentiality of using the ATM and authenticate the institution using the ATM.

In the manner described by the invention, the JAVA applets are associated with functions such as activating the card reader mechanism, notifying the browser after user card data has been entered, operating the receipt printer mechanism, operating the logging printer mechanism, Keyboard, receiving data input via keyboard, operating paper dispenser mechanism, operating storage mechanism, locating document addresses, timing device functions, verifying digital signatures, handling information encryption, controlling obfuscation of bills (tickets) dispensed from composite paper dispensing mechanism, Calculates the foreign exchange, and ends the transaction and commands the browser to return to the state connected to the local server. Of course, in other embodiments, there are other applets that can be used to control the device and use the data to carry out the various functions required in the machine. Device application portion 84 within computer 34 communicates at IP port 86 .

In the described embodiment of the invention, the device application portion 84 of the software does not pass its messages directly to the device interface software portion 64 . As described later, this will enhance security and confidentiality. However, it should be understood that some embodiments of the present invention may also allow the device application portion 84 to transmit device operation information directly to the device program 70 . This can be done internally using TCP/IP, by routing the information in a conventional manner through queuing methods established within the computer operating system associated with the software associated with the device, or by directly invoking this software.

It will also be understood from the foregoing discussion that some of the applets within the device applications section 84 may also correspond to devices that do not exist in all automated teller machines. For example, an automated teller machine that operates only as a cash dispenser does not contain a storage mechanism like storage mechanism 44 . To accommodate the situation where the user requests a transaction that is not physically possible to perform with the automated teller machine 12, the device interface software portion 64 may go through the process of providing an appropriate response message to the user indicating that the function does not exist.

Alternatively, the device interface software portion may include a function that can be used to check the presence or absence of each type of physical device inside the automated teller machine. Information indicating the presence of a certain device within the automated teller machine may be included as part of the information generated by the automated teller machine. For example, information indicating that the device is operable within an automated teller machine may be included within the portion or portions of the URL that information is controlled by the automated teller machine. Thus, URLs within a server associated with an automated teller machine may be configured to provide only HTML documents corresponding to the types of transactions that the automated teller machine is capable of performing. As a result, the browser can avoid displaying documents involving transaction types that the machine cannot perform. Thus, for example, assuming the machine does not contain a deposit mechanism, the machine can avoid generating a display based on the inclusion of documents pertaining to the deposit transaction.

Alternatively, the machine may include in memory data representative of the features of the built-in functional devices. This may include, for example, data representing the number of devices within the machine and the configuration of said devices, or, alternatively, identifiers such as a machine number sufficient to identify the capabilities of the machine. The device data representing the functional devices in the machine is connected to the server, and the server can efficiently transmit appropriate HTML documents to the devices in the machine. This can be done from data corresponding to machine devices or by a memory storing data representing functional devices within a machine associated with specific identifiers. Documentation selectively sent to the machine's browser by the server will include appropriate measures of the functional devices within the machine. These documents may be static documents or may be documents which are generated during runtime from sub-documents or otherwise provide the appropriate output and instructions to the output devices of the transaction machine.

FIG. 3 shows the automated teller machine 12 in communication with the local bank computer system 14 via the internal network 16 . Computer system 14 includes a proxy server 88 . System 14 also includes a local HTTP server 90 . Computer system 14 also includes a device server 92 . The proxy server, local HTTP server and device server may be contained within a single computer as shown, or may be contained within separate computers in other embodiments. In other embodiments, there may be additional servers.

The local HTTP server 90 is preferably in communication with the data store and is in electronic communication with the computer system 94 in the office. The in-office computer system 94 effectively tracks debits or credits to a customer's account as the customer conducts transactions on the automated banking machine. In addition, the in-office computer system 94 preferably also efficiently tracks transactions for the purposes of completing settlements with other institutions participating in the system whose customers transact at the automated teller machine 12 .

It will be further explained later that the proxy server 88 can effectively communicate with the foreign server, for example, the foreign server 96 through the wide area network 18 in the embodiment. Foreign server 96 is an example of a server operated by an institution or entity other than the institution operating computer system 14 . It must be understood that although the foreign server 96 is operated by a "foreign" institution, that institution is not necessarily located in another country remote from the institution operating the computer system 14 . Rather, it is also possible that the foreign server 96 is located in a foreign country, including in a country where the language spoken is different from the language generally spoken in the country where the automatic teller machine 12 is located.

Referring now to Figures 3-24, the process of conducting a transaction using the automated teller machine 12 will be explained. It must be understood that the transaction flow described below is only an example of the use of equipment and systems, which can be configured and operated in a variety of ways in order to conduct transactions.

As shown schematically in FIG. 3, browser 76 communicates with proxy server 88 over internal network 16 at the initiation of an exemplary transaction. Communications are preferably established and an HTML document intended to attract the customer to the automated teller machine 12 is displayed on the touch screen 30 . This is called "attraction mode". The output generated on the touch screen 30 (and/or via other output devices included in the machine) of these HTML documents processed within the browser may originate from a local HTTP server 90, which may effectively The HTML document is passed to the proxy server 88. The local HTTP server delivers the addressed message to the IP port associated with the browser 76, causing the message to be displayed on the associated ATM machine. However, it must be understood that although in this embodiment, the local server 90 communicates with the automatic teller machine through the proxy server 88, in other systems, the server 90 of the present invention can also communicate directly with the automatic teller machine. communication.

A fundamental advantage of this system is that the local HTTP server 90 can selectively transfer documents to the ATM 12 connected to the internal network 16 . These documents may include messages or materials appropriate to the particular location at which the automated teller machine 12 is located. Some examples of specially edited screens may include bilingual messages in certain areas or information relating to currency exchange at ports of entry. The data or message may contain advertisements for various products or services or other materials aimed at specific machine locations. JAVA applets and JAVA scripting language are loaded from an optional software distribution central unit within the automated teller machine, which can also be used to adapt the automated teller machine by making it accessible to files including those specified for that location environment, and they are not provided in the documentation sent to at least some other machines in the system.

The system of the present invention can be configured to enable selected machines to access HTML documents at different locations such that a particular accessed document includes material desired by a particular machine user. Alternatively, the machine may communicate machine data indicating its identity and/or location to the server. From the machine data associated with the server and the data stored in the data storage, the server can deliver documents including target materials. This can be done by combining subdocuments, or otherwise by generating a document to be delivered to a browser on a particular machine. Furthermore, it must also be understood that although in the illustrated embodiment the HTML document is accessed through an organization's server associated with the machine, the documentation for the attract mode could also be accessed through other servers operated by other organizations. access.

In this exemplary transaction sequence, the touch screen 30 displays a screen including icons in one or more languages telling the user that a transaction can be initiated by touching the screen. An input signal may be generated if the user touches the screen within the icon area. The incoming signal or HTTP message is passed through the browser 76 to the local address of the local HTTP server 90 that is currently communicating with the ATM 12 . Return to the message generated by the local HTTP server as shown by the arrow in Figure 3 from the browser 76 to the internal network 16, from the internal network 16 to the proxy server 88, and then from the proxy server to the HTTP server 90.

Responsive to the local HTTP server 90 receiving a message indicating that the client has touched an icon on the screen, the local server effectively replies to the accessed address and delivers the message to the browser 76 via the proxy server 88 (or directly in other embodiments) . The message preferably includes an HTML document which, when processed by the browser, generates a screen to instruct the customer to insert the card into the card reader mechanism 38. The flow of the HTML document as shown in Figure 4 preferably also includes embedding JAVA scripting language or other instructions, which run in the JAVA environment and deliver the message to the JAVA applet responsible for launching the card reader in the device application section 84 . In a preferred embodiment, the instructions provide an indicator or flag to the applet, which executes in response to receipt of the document instruction. Of course other software and methods may be used in other embodiments.

As shown in Figure 5, the JAVA applet related to the activation of the card reader function is driven along with the embedding of the JAVA scripting language. The JAVA applets within the device applications section 84 communicate with the device server 92 . The device server 92 includes a device server program 98, which in the preferred embodiment of the present invention is a JAVA program that enables JAVA applets to communicate with the device server application (program) 100. The device server 92 preferably also includes a monitoring software application (102) effective for monitoring device operating instructions. The monitoring software minimizes the risk of fraud or misuse as described below.

Returning now to the transaction as an example, in response to receiving a message from the device application part 84 to activate the card reader, the device server 92 can effectively generate a message via the internal network 16 to the device interface software part 64 of the automatic teller machine 12. . The message contains an HTTP record with some instructions for running the card reader, and the message points to the IP port 74 where the device interface software part 64 communicates. In response to receiving the message, the software portion 64 effectively transmits the message or messages on the control bus 50 which activates the card reader 34 .

Continue the transaction example shown in Fig. 6 below, by the customer inputting the card into the card reader 34, the data of the card can be effectively read out, and the device interface software part 64 will send a message to the device server 92 to represent the card Data has been read. This message is sent by the device server to the device application part 84 via the internal network 16 . Then the device application part sends a message requesting card data to the device server. The device server 92 transmits a message to instruct to transmit the card data from the device interface software part 64, and the device interface software part 64 replies with a message sending the card data to the device server through the internal network. The device server, if there is no basis for stopping the transaction, sends an HTTP record containing the card data back to the device application part 84 via the internal network 16.

In a preferred embodiment of the invention, the card entered by the user or customer includes indicia corresponding to the user's associated address within the network. In such an embodiment, the token corresponds to a Uniform Resource Locator ("URL") address that provides the computer with information where user information resides, including user information directories or subdirectories and files or resources containing user information The name. The URL address can be encoded on the customer card. The address can be encoded on the magnetic stripe track and elsewhere within the magnetic stripe data, or by encoding other readable marks on the card. Alternatively, if the customer card is a "smart" card ("smart") containing semiconductor memory thereon, the URL address associated with the customer may be included as part of the data stored on the integrated circuit chip contained on the customer card. Alternatively, the URL may be derived from other data on the card by accessing a database in which address data is associated with other data read from the card. The data necessary for deriving the address for accessing documents related to the customer may also be derived from other input data entered into the input device rather than from the data obtained from the card data, such data including, for example, Biometric data entered via a biometric reading device. Such biometric data includes, for example, data corresponding to one or more fingerprints, data from a customer's appearance, or a combination thereof.

For example, without limitation, data entered by a customer, such as data entered into a card reader via a card, may correspond to an address for accessing an HTTP record, which may be a file that includes information that can be used to authenticate the customer or documentation. This record may include a number corresponding to a PIN (Personal Identification Number). This information may include biometric data corresponding to authorized users of the card. The browser may access the record and use the content of the record (eg, data and/or instructions) to verify that the indicia corresponding to the biometric data within the record correspond to the biometric data of the customer entered into the card. Alternatively, input data representing appearance, voice, other characteristics (or combinations thereof), or other input data may be used to generate one or more addresses corresponding to the user, and use the recorded content at the visited address to verify whether the on-board user is compatible with Corresponds to the user associated with the record. A variety of methods can be used within the scope of the present invention. Information in the records corresponding to a user may also be used to grant permission for the user to operate certain functional devices on board and not to allow the user to operate other devices. For example, a user who is overdrawn may have information in the record that prevents him from actuating the cash dispenser, while a user who is not overdrawn contains information that enables the operation of the cash dispenser. Alternatively, the absence of information in a corresponding record permits operation of the device, while the presence of information selectively restricts operation of the device.

Now back to the exemplary transaction. The programming of the transponder application portion 84 delivers successfully read card data to the JAVA applet, along with notification that the card data has entered. In response, the JAVA applet is run to generate a JAVA script language that configures the browser with a URL address corresponding to the data read from the card. The JAVA applet also preferably effectively opens a record, shown schematically at 104, involving the transaction, including the user's URL address, time and other card data. In a preferred embodiment, this record can be stored in memory as an object data in software. This object is preferably used to accumulate data in conducting transactions. The data stored in the transaction data object preferably includes data entered by the user through the input device as well as data representing operations performed by the transaction function device.

A record or transaction data object provides persistence to allow a client to perform several different transaction steps. The ability to use that data across multiple distinct operations avoids having to export or fetch data from the customer multiple times during the conversation with the customer when multiple transaction steps are involved. The use of transaction data objects allows applets to operate largely independently, obtaining the required data from transaction objects. The method also allows the record or data object to be used to generate an appropriate record at the end of the transaction session. This record can be stored or collected within a program group or sent to selected locations within a local or wide area network.

As shown schematically in FIG. 7 , in response to browser 76 receiving the URL address data, the browser may effectively transmit the message via internal network 16 to proxy server 88 . For the purposes of the embodiment, the URL address associated with the card data is the address of a customer associated with the local bank of the operating system 14 . As a result, the client's URL address will cause a message to be sent from the proxy server 88 to the local HTTP server 90 and access the document corresponding to that address. Alternatively, in other systems, a direct connection to server 90 may be made without the intervention of proxy server 88 . As previously mentioned, the URL address may also contain data that would represent the device operating within the automated teller machine.

After receiving the message, the local HTTP server 90 finds in its relevant memory the data corresponding to the client's URL address data, and delivers the data and an HTML document to the browser at its IP port. This HTML document may include a panel for identifying the particular customer's name and the name of the banking institution or other entity operating the local banking computer system 14 .

In addition, the HTML document preferably contains an embedded JAVA scripting language with a digital signature or a method of obtaining a digital signature associated with the local HTTP server 90 . Script instructions included within the document in some embodiments cause the device application portion to access an HTTP address on a server, which in the described embodiment is server 90 . The HTTP address corresponds to an HTTP record, which contains at least one command and preferably contains a program, such as a JAVA applet or an Active-X file. Instructions are used to run the appropriate transaction function device. The HTTP record preferably contains data representing a signature, such as a digital signature. This digital signature is received in response to the JAVA scripting language 82 and processed within the application portion 84 of the device. The JAVA applet processes the digital signature and verifies it, and if an acceptable signature, allows manipulation of the banking machine. In some embodiments, the applet compares the signature with signature data stored in memory in a predetermined, eg, matching, relationship.

After the applet verifies that the HTTP server 90 or other accessed HTTP record has sent a correct digital signature, the transaction is allowed to proceed. If for some reason a correct digital signature is not sent, the JAVA applet will stop the transaction and cause the banking machine 12 to return to the The state before the transaction started. The use of signed commands can be used to ensure that various transaction function devices operate only in response to appropriate messages. Instructions using a signature are particularly suitable for instructions to operate a banknote dispenser or otherwise to provide a user of the machine with something of value or the like.

Assume in the example that the received digital signature is a correct signature. Under this condition, the message returns to the local server 90 from the browser 76, indicating that the transaction can be carried out. In the exemplary transaction shown in FIG. 8, the HTTP local server 90 then operates to send an HTML document to the browser 76. The HTTP document contains instructions which, when processed, generate a page or screen informing the user to enter their personal information. Identification number or PIN. The HTML document preferably contains embedded JAVA instructions which cause the device application portion 84 to activate the keypad 40 of the automated teller machine so that the machine can receive the PIN number. This message is shown schematically in Figure 8, and the JAVA scripting language 82 signals the JAVA applet responsible for the keyboard, telling it to start the keyboard. In response, the JAVA applet within the device application portion 84 sends the message over the internal network 16 to the device server 92 . The device server 92 returns a message via the internal network to the device interface software portion 64 within the automatic teller machine. The instructions within this message cause the device software to activate the keyboard 40 . The JAVA applet responsible for activating keypad 40 also preferably efficiently updates transaction record 104 to indicate that a PIN was requested.

As shown in FIG. 9, the PIN entered via the keyboard 40 is sent from the device interface software portion 64 to the device server 92 in the form of a message. The device server 92 sends a message back to the responsible JAVA applet within the application part of the device. The JAVA applet then runs a message back through the HTML document processing portion and browser 76 to the HTTP address of the local server 90 . This message includes data representing the PIN entered by the customer. Displaying the customer's PIN on the screen is not desired in some embodiments. In such embodiments, the keypad applet may effectively display on screen, for example, a "*" symbol or other symbol in place of a PIN number. Furthermore, as described later, it may be desirable to avoid transmitting PIN or other data via the browser, in which case the PIN data can be processed as a separate HTTP message or otherwise to reduce the risk of compromise.

The software running in association with the HTTP server 90 then verifies the PIN itself or sends it to the in-office computer system 94 to verify the customer's PIN number and account number and wait for a reply. Alternatively, verification of the customer's PIN can be performed within the automated teller machine through a suitable applet. This can be done where the data on the customer's card, eg account number, can be algorithmically linked to the customer's PIN. The embedded JAVA scripting language in the HTML message may include or point to an address for obtaining data and/or instructions that the applet uses to perform authentication functions, including certain encryption key data. This may include user information within HTML documents or other recorded data accessed in response to user card data. As schematically shown in Figure 9, the transaction data object 104 may also be suitably updated by the applet to indicate the entry of a customer PIN.

In other embodiments, the machine may include a biometric reading device or other input device that receives data from the user. Using such a device, a user may enter data which may be used in place of or in addition to PIN data to verify that the user is an authorized user. This can be done, for example, by comparing the user data entry with information corresponding to the identified user contained in the card within the record or document. This record or document has an HTTP address, and this address is accessed through HTTP server by browser or HTTP client application program according to card data. Alternatively, the input data may be used to generate a document or address of record, accessed by a browser or client, that contains information used to authenticate the user. For example, data about a user may be stored in a data store associated with an HTTP server, and in response to the user data, the HTTP server sends data from a record to authenticate the user.

It must be noted that the page or screen shown asking the customer to enter a PIN is generated by the local HTTP server 90 . This screen is associated with a particular client URL address. This will be the interface of the customer's local bank, so the interface will be familiar to the customer. Alternatively, the customer's address may have access to a personal "home page" primarily of the customer and the institution operating the computer system 14. So it's not only something that users are familiar with, but it's also well suited to their specific trading needs.

Alternatively, documents or records containing user data can be used to generate addresses for other documents. Information may also be used to generate documentation as a particular client in particular circumstances. This method can effectively reduce the trouble of preparing a personal page or document for each customer in advance.

A method of accomplishing the above objectives, which may involve including various types or categories of user information within files or records pertaining to a particular customer. This information includes, for example, gender, people involved, account types, permitted transactions, customer preferences, customer interests, account balances, previous offers or acceptances, and other information. This customer information can be used by a suitable applet among the applets 86 to address and/or develop a suitable file for the browser to access according to the customer's "profile". In addition, the profile applet may take into account the transaction devices that are present in a particular machine, whose information is stored in data storage within the machine or elsewhere in the system, as well as other factors such as the day of the week based on the system clock The number of days, the time of day. In this way, the machine determines the appropriate document to visit or generate for a particular client in a particular context.

Logic used within the profile applet can act on a customer to cause a profile to be created or accessed, including transaction selection based on customer information, information on a regular basis, and other factors. The profile applet can selectively provide transaction options or information based on customer information. For example, a machine operator may selectively provide various incentives, material incentives, rewards, additional transaction options, or advertising messages to the user. Certain types of institutional customers operating the machine may receive screen output with options encouraging the customer and the institution to do more business or other types of business. Likewise, clients who are recognized as clients of foreign institutions may be offered incentives to do business with the institutions operating the machines.

The profile applet can function to cause the computer to access other files on other servers, such as stock quote data, and selectively provide this data to customers. It must be understood that the profile applet can be run to determine an address or generate a document to generate the initial display screen of the transaction sequence. The profile applet can also function to provide information or access or form documents for customers at or between other transaction points to generate intuitive output. This can further be used in systems where the machine operator can sell paid advertisements to third parties and then access HTTP records such as HTML files for third party products or services. These visits may be made on a periodic or other basis, but are effectively made by selecting HTTP records in response to a particular user's profile.

In the transaction used as an example, the flow of the transaction ensuing by the client of the establishment operating the computer network 14 is schematically shown in FIG. 10 . In response to the customer entering the correct PIN, the local HTTP server 90 effectively sends the HTML document to the HTML document processing portion of the software in the computer running the automated teller machine. These messages may include information for generating a screen prompting the customer to select a transaction. For purposes of this embodiment, it is assumed that the customer enters a selected transaction at the touch screen, the selected transaction being the dispensation of cash, which is a typical transaction for automated banking machines.

The client's selection of the input device through the touch screen is returned via the HTML document processing part, and the HTML document processing part transmits an HTTP message to the local HTTP server 90 . The server 90 then responds by sending another HTML document to the banking machine, prompting the customer to select the amount to withdraw cash. Again the customer can enter a selection of his choice on the touch screen which displays the amount of cash requested by the customer. The HTTP message reaches the local server 90 through the HTML document processing part and the browser 76 .

After receiving the amount data from the customer, the local server 90 is preferably in active electronic communication with the in-office computer system 94 to verify that the customer has the amount of money he requested in his account. This is preferably accomplished through a Common Gateway Interface (CGI) 106 which is operatively connected to the local server 90. With regard to this transaction, assume that the computer system 94 in the office indicates that there is this amount in the customer's account, and sends a message to the local server 90 through the CGI 106 to indicate that the transaction can continue.

As shown schematically in Figure 11, the local server 90 then executes the HTML document processing portion that sends the file back within the ATM software. This message will preferably result in a message being displayed on the screen informing the customer that the transaction is in progress. In addition, the returned HTML document preferably contains a JAVA scripting language program with embedded instructions that are executed and communicated to the JAVA applet associated with the operation of the banknote dispensing mechanism 42 .

Documents returned from the local server 90 may include advertising or other information not necessarily customer information, or other information in addition to the customer. The returned document also includes an instruction to cause the machine to access or generate another document. Depending on characteristics associated with the client, machine, presence, and/or other circumstances, these instructions may invoke methods within the profile applet. This allows access to documents that provide the user with promotional information, such as advertisements or other information, while the user waits for the machine to operate. It must be understood that these documents may be accessed anywhere including the Internet. This makes it possible to selectively provide a large amount of data to the client. Operators of automated teller machines and other transaction machines are also permitted to serve advertisements to customers on a broad basis, or targeted to certain classes of customers, or even to individual customers on a partial basis. This could be an advertisement of eg a bank by the operator of the machine or for virtually any type of good or service. These advertisements may also be selectively served based on the particular trading device being manipulated, the amount of funds involved, or other parameters. HTML documents also allow images and sounds to be provided to clients, thus enhancing the effectiveness of promotions.

A message arriving at the JAVA applet within the device application portion 84 of the software initiates operation of the banknote dispenser, resulting in the generation of a message to the device server 92. Messages arriving at the device server 92 for dispensing cash are preferably analyzed by the monitoring software 102 to check and observe whether the messages are appropriate. For example, the monitoring software 102 preferably effectively verifies that the amount of cash requested does not exceed a predetermined amount. There is also an optional check to verify that the amount provided to the customer did not exceed a certain amount in previous periods. This can be done by the device server sending a message to the in-office computer system containing the card data previously received from the customer. This message may pass through server 90 and its associated CGI or other link. Assuming the dispensing order is not blocked by a message from an internal office computer system or monitoring software, the device server 92 sends the dispensing message to the device interface software portion 64 within the automated teller machine. Afterwards, the software part 64 effectively responds to the above-mentioned message and starts the paper distributing mechanism 42, and distributes the cash amount requested by the customer.

Monitoring software 102 preferably performs other functions within the device server. For example, government regulations or good business practice often require limiting the amount and amount of deposits that can be placed in an ATM, which prevents "money laundering" or other suspicious activities. The monitoring software preferably controls the amount of any one-time deposit below a set limit. The monitoring software may further operate in communication with the internal computer system 94 of the local bank office to prevent a series of deposits exceeding a certain limit within a predetermined period of time. The monitoring software can also work with the proxy server to respond to instructions from the foreign server to limit certain transactions that can be made on the banking machine, as will be discussed later.

It must be noted that in a preferred embodiment of the present invention, the applet that effectively communicates the messages that result in the dispensing of cash can work in conjunction with other applets that control the confusion of tickets assigned to customers. Many automated teller machines have the ability to dispense currency notes of two or more denominations. There is a need to control the mix-up of tickets dispensed to customers to suit in-flight applications and to avoid running out of tickets of one denomination before another. The ticket obfuscation applet preferably controls the obfuscation of tickets according to the needs of the institution operating the automated teller machine and according to the capabilities of the automated teller machine as practicable. Alternatively, a JAVA applet for controlling ticket obfuscation may reside in the device program 70 within the device interface software portion 64 .

Those skilled in the art will understand that specific JAVA applets and/or configuration data on the machine can be selectively loaded from the local server 90 at machine startup or at other times. Because applets and configuration data can be selectively transferred to particular machines, those machines are tailored to the money dispensing mechanism and other capabilities of a particular automated teller machine. For example, an automated teller machine may be configured so that certain sets of applets are required to allow the machine to function. One method of loading the above-mentioned data or programs consists in providing address values within the terminal software to indicate where the instructions required by the applet or data are available. If the applet or group of applets does not already exist in the memory of the ATM terminal when the machine is started, the software effectively accesses the system address of the file containing the required records or instructions and enables the machine to install Enter the required records. The browser can be used to access the address, and the software will load the data corresponding to the instruction in the accessed file into the memory in the terminal of the automatic teller machine, so that the terminal has required small applications and data. The above-mentioned document address can be accessed through the local server 90 . Alternatively, the address may be on a separately developed server connected to the internal network 16. In this way, each transaction machine can be loaded with the applets and data containing the opcodes necessary to run the transaction device within the machine. Alternatively, the documentation may be provided via a machine-accessible development server or other server over a wide area network. Documentation can be provided on a development server, providing instructions to machines on how to obtain opcodes to perform a wide variety of functions. The instructions may instruct the machine to obtain the necessary data and codes from addresses accessible via the HTTP server through the built-in HTTP client. The data and codes may be obtained in response to commands within one or several documents. The machine can also require that the applets loaded in this way contain digital signatures or other authentication features to represent the applets with signs, so as to complete the operation of certain devices in the machine.

Alternatively, embodiments of the present invention may obtain the necessary applets and data from a remote data store. The data storage preferably contains data and/or programs that allow the machine to operate as required, or has instructions where the machine can obtain the instructions and data necessary to run the machine. Data can be retrieved from a database server. The transaction machine makes an address query to the database server. This query contains or is accompanied by a signature from the machine that can identify (identify) the machine. This may be specific to the machine such as a machine number and/or include markings representing the type of machine or representing the capabilities of the machine's functional equipment.

The data storage preferably contains records with data or programs sent to the machine. In response to the query to the server, the server retrieves the record from the data store and transmits one or more messages to the HTTP client within the transaction machine in response to the server's record. The message contains configuration data or applets to make the machine operate in the desired manner or may contain instructions on how the machine obtains said programs from a server connected within the system.

In the illustrated embodiment, the configuration server and data store may run on the same computer as the local bank server 90 . In other embodiments, the database server may reside elsewhere within the network to which the machine is connected.

One advantage of machines and systems using the features described above is the flexibility to change the operation of the machine and the customer interface as circumstances change. This can include changes within the transaction function device. Circumstances may change so that certain transactions are restricted or certain transaction items are not available in the machine. For example, a machine may normally accept deposits unless its depository is full. In this case, the machine can change the accessible file to provide information to the user through its output device telling the user that the deposit service is no longer provided. This is accomplished by initially loading applets and data on board, which provide instructions when the above conditions are detected. The machine program is changed by loading new applets and/or data from the HTTP server in response to the prevailing conditions. This can be done in response to queries from a database server that contains or is accompanied by data representative of machine variability or variability. In response, the server delivers applets, data and/or instructions that will operate the machine in the altered mode.

This approach eliminates the situation when using conventional transaction machines where the display on the output device with a static interface provides the customer with a transaction option. Sometimes, after the customer makes a selection, the machine gives instructions that the transaction option selected by the customer cannot be provided. The methods described herein can be used for many trade options and changes to trades. The transaction options from the on-board database server can be easily changed by machine-based or even client-based as previously stated, and according to the needs of the institution running the transaction machine.

Will now continue to discuss the transaction used as an example. After the cash dispenser 42 has distributed the requested amount of cash, the device interface software program 64 sends a distribution operation message back to the JAVA applet responsible for distribution in the device application program 84. application to confirm the assignment operation. As shown in Figure 12, this particular applet can effectively update the transaction record 104 to indicate that the requested amount of currency was dispensed to the customer. The embedded JAVA scripting language instructions effective to cause currency to be dispensed to the customer preferably also include instructions for sending a message back to the local server 90 confirming that the distribution is complete. After receiving the distribution operation message indicating that the cash has been distributed, the JAVA applet configuration HTML document processing part is caused to send a device response message back to the local server. The local server is then programmed to indicate to the computer system inside the office that the customer has received the cash amount allocated to him. The cash amount is debited from the customer's account in records maintained by the office's internal computer system.

During a transaction, the customer is usually asked if he would like a transaction receipt. Inquiries can be made at various stages in the transaction process. In this embodiment, the above information as shown in FIG. 13 is sent to the customer operating the machine after the cash is distributed. The local server 90 effectively sends an HTML document that includes a screen asking the customer if he would like a receipt. In response to receipt of the message sent by the browser 76, the information is displayed as part of a page on the touch screen 30. Alternatively, the document is machine generated. After responding to the information that the customer indicates that he or she does not want a receipt, the message is returned to the local server. It must again be understood that the screens displayed to the customer are preferably those the customer is used to, from those seen at his or her local establishment, and possibly his or her unique local page.

Assuming that the customer wants to receive a transaction receipt, the local server 90 initiates sending a file back to the ATM with embedded JAVA scripting language as shown in FIG. 14 indicating that a transaction receipt is to be printed. These instructions written in the JAVA script language are sent to the device application part 84, and the device application part 84 sends a TCP/IP message to the device server 92 via the internal network. The device server 92 in turn transmits a message with instructions to the device interface software portion 64 within the automatic teller machine. In response to receiving this message, software portion 64 effectively causes printer 46 to print out the customer's transaction receipt. The JAVA applet responsible for starting the printer preferably also efficiently updates the transaction data object or record 104 . As described later, an applet for controlling the printing of receipts can obtain data for printing receipts from a transaction data object.

It must be understood that even if the customer does not want a receipt, it is preferred that a hard copy page of the transaction be printed by the journal printer 48 . This can be done in response to an embedded instruction, which is part of the same document from the local server 90, which causes the customer's transaction receipt to be printed, or part of another document which indicates that the customer has opted out of accepting the transaction receipt. Alternatively, the journaling printer may be activated in response to other applets, such as the applet that causes the dispensing of cash, or another applet chosen by the operator of the automated teller machine. It will be appreciated from the foregoing description that the operation of the preferred embodiment of the automated teller machine has inherent flexibility and programmability to meet the needs of the system operator.

As shown in Figure 15, once the printing of the transaction receipt is complete, the software portion 64 preferentially effectively sends a device operation message to the device server 92 indicating that the required device function was successfully performed. The device server 92 effectively sends a corresponding device operation message to the device application portion 84. In the preferred embodiment, the device operation message is sent to the specific JAVA applet responsible for printing the receipt. The JAVA applet configures the HTML document processing part to generate a message that returns to the local server in the form of a device response message, indicating that the customer receipt has been printed.

After receiving the cash and receipt, the customer is reminded by generating a display screen from the HTML document of the local server 90, asking the customer to indicate whether he wants to carry out another transaction. The above-mentioned visual page or screen reminding the customer in this regard is displayed on the touch screen 30 . As for the transaction as an example, it is assumed that the client does not want to conduct another transaction. In this case, a message is returned to the local server 90 through the HTML document processing part.

As shown schematically in Figure 17, after receiving the message that the customer's transaction ends, the local server 90 effectively sends a "go home" message to the automatic teller machine. The message preferably includes an HTML document for generating a screen display thanking the customer. This message preferably also includes the embedded JAVA scripting language program of calling the JAVA applet, and the JAVA applet finally returns the URL address or other addresses on the local server 90 related to it to the HTML document processing part of the automatic teller machine, The latter provides documentation for outputting so-called "attract mode" messages. It must be remembered that the letters in some embodiments refer to a program written in a scripting language operable to cause a message to be sent from the document processing part to an address on the local server, which would cause the loading of a corresponding HTTP record, where The HTTP record includes instructions consisting of the required applets.

As shown schematically in FIG. 18, the "Back To Home" command applet may effectively configure the browser 76. Configuration via the JAVA Applet After the HTML document processing portion returns to the start, the JAVA applet is configured to transfer information from the transaction record 104 to the local server 90 pertaining to the transaction just completed. Because the exemplary transaction relates to customers of the institution operating computer system 14, all data related to the transaction should have already been recorded in computer system 94 within the office. However, it will be appreciated that the situation is different if the transaction is performed in response to a message from a server operated by a different institution. Thus, all or part of the information from the transaction recorder 104 may be sent to the local server 90 in response to a "return to home" command and transmitted via CGI to the in-office computer system 94. From there, computer systems within the office can identify the information as transcribed and discard it. This may use Remote Mode Invocation (RMI) to forward or transfer the object to the server 90, and then transfer the data to the computer system within the office via messages from the server or via messages or other techniques.

Of course, in other embodiments, transaction information may be stored in the database for extended periods rather than sent back after each transaction. Alternatively, if desired by the operator of the system 14, the automated teller machine 12 of the present invention may contain an applet that practicably delivers the transaction record information to the address rather than a local server.

When a "foreign" user uses the automatic teller machine 12, the operation of the computer system proceeds in the manner shown diagrammatically in Figures 19-24. The foreign user conducting the transaction is not a customer of the institution operating the ATM 12 and computer system 14, the transaction will be run under the control of the local server 90 and will be carried out by the location where the customer enters their card in the manner of the previous embodiment. The card entered by the customer has an indicia corresponding to the URL address instead of the indicia corresponding to the local server 90 . The HTML document processing part effectively configures an addressing message for accessing the URL address corresponding to the mark on the customer's card or other address responding to the above mark. The above-mentioned message is forwarded to the proxy server 88 , which in turn forwards the message to the wide area network 18 . The message is forwarded from the WAN to the foreign server corresponding to the client URL address. As far as this example is concerned, the foreign server corresponds to the server 96 connected to the Internet.

In the preferred embodiment of the present invention, proxy server 88 includes masking software shown at 107 . The masking software is preferably operable to verify addresses to which the message is aligned via the automated teller machine and selectively prevent delivery of the message to particular addresses. Screening software can be used as a "firewall" firewall, which meets the needs of preventing fraud in the system.

As shown in FIG. 20 , the foreign server 96 can practicably return the HTTP message including the HTML document to the automatic teller machine 12 through the wide area network 18 . To minimize the risk of message disruption, this can be done using a secure connector ("SSC"). Of course, other techniques including encrypted message techniques can also be used to minimize the risk of interrupting the message.

As shown schematically in FIG. 20, the document replied from the foreign server 96 preferably contains embedded JAVA scripting language representing or corresponding to a digital signature identifying the foreign server 96. As previously mentioned, this can be achieved by loading an HTTP record containing an applet represented by a logo. The applet in the application section 84 within the automated teller machine preferably operates in the manner described in the previous example to verify the digital signature and send a message indicating that the transaction has been approved. The digital properties used by the foreign facility will be stored in memory within the ATM and eventually recorded in the computer system 94 within the office.

It must be noted that the HTML document from the foreign server 96 produces the visual page or screen of the foreign institution that the foreign client is used to seeing. These pages are consistent with the "home page" of foreign customers, which are especially suitable for the needs of specific customers.

FIG. 21 shows an example where a document accessed through a foreign server 96 arrives at the automatic teller machine 12. As shown in FIG. The file from the foreign server may contain an embedded JAVA scripting language that enables the JAVA applet to work in the manner previously described to run the device 36 within the automated teller machine 12 . As shown in Figure 21, the TCP/IP message arriving at the device is transmitted from the JAVA applet to the device server 92 through the device application part 84, and the instruction is passed from the device server to the device software interface part 64 in the automatic teller machine. Device operation packets take the reverse path. As these messages pass through device server 92, monitoring software 102 monitors the messages to minimize the risk of fraud or abuse.

As shown in FIG. 21, the document from the foreign server 96 may effectively display a screen on the touch screen 30 asking the customer to enter their PIN (Personal Identification Number). The embedded JAVA scripting language instructions include instructions to activate the keypad 40 for accepting the customer's PIN as in the exemplary transaction previously described. As in the previous example, the transaction record 104 containing the shared data object related to the specific transaction can be opened by the application software part of the device. As previously mentioned, measures can be taken to prevent PIN data from passing through the browser, if desired.

Fig. 22 shows that the device operation message and PIN data are returned to the JAVA applet, and then the encrypted connector is used to send the data back to the foreign server 96 through the wide area network 18. From this point of view, the transaction generally proceeds as previously described and accepts the message from the document processing portion of the ATM, except that the foreign server 96 sends the HTTP record containing the HTML document. The foreign server 96 must contain JAVA application software so that the embedded JAVA script language is included in the document, and the embedded JAVA script language is sent to the automatic teller machine to operate the equipment 36 in the machine.

When the foreign server 96 is operating the machine, the monitoring software 102 in the device server 92 effectively monitors the messages in the aforementioned manner. Such monitoring may be used, for example, to prevent improperly dispensed large amounts of money from leaving the machine. Surveillance software may also serve to limit the attachment or capabilities of certain foreign institutions' trading machines. This can be done based on data stored in memory that can limit the devices or activities that are executable at certain addresses according to the document. This can be achieved, for example, by using code insertion that performs transaction object classification to limit possible operations. For example, an operation that allows connection to a foreign server could specify an object with specified limited capabilities for messages received from the foreign server. This could, for example, limit the amount of cash dispensed, prevent bill (check) receiving equipment from operating, limit the dispensing of printed material such as tickets, prevent the operation of a cash dispenser or restrict use of the machine in other specialized ways. The above qualification can be done in terms of addresses or partial document addresses.

If the machine's capabilities are limited to foreign customers, foreign customers can be provided with an intuitive interface from foreign banks based on the transactions the machine can perform and the machine owner allows. As a result, the documents accessed on the foreign bank's server may be a variation of what was provided to the customer on a machine operated by the foreign bank. This could be based on specially developed documentation for operating foreign machines, or it could be a variation of the normal foreign bank interface with visual indications that certain transactions are invalid. In some cases, the interface may indicate that certain transactions are valid but subject to associated service fees.

The automatic teller machine of the described embodiments can enhance security by restricting the addresses that the browser can access. This can be done by maintaining a directory in machine memory. This directory can be maintained in HTTP records (including files) accessible through the local bank's internal network. The machine can periodically access this record and update the memory data. The record itself requires a digital signature corresponding to the signature in the terminal memory before the data is loaded into the terminal memory. This information also contains instructions and information for the automatic teller machine to authenticate the authenticity of the message received by accessing the file on the foreign server. This may include digital signatures which, when transferred using public key or private key cryptography, authenticate the authenticity of the message. The machine checks and determines whether the signature in the record accessed from the foreign server is consistent with the digital signature stored in the address in the memory. Only when the above-mentioned consistency occurs, the transaction device like the cash dispenser is allowed to start. Of course, various methods of authenticating and encrypting messages may be used in various embodiments. A signature or a recorded record as used herein may contain any indicia which is an indication of acceptance, contained in or derived from the record.

It will also be understood from the foregoing description that the foreign server 96 communicates to the user via the touch screen in a language different from the language normally used by customers of the institution operating the computer system 14 . As a result, the HTML document may display requests for currency types or amounts not included in the automated teller machine. To accommodate the above, it is preferable to include within the device application section 84 an applet for processing foreign exchange requests. The foreign exchange applet causes the ATM to send a message back to its local server to provide the customer with an amount nearly equivalent to the foreign currency requested by the customer in the currency available at the ATM. It should also be understood that the applet will effectively call a specific function address within the local server 90 that provides this function. When dispensing, the applet is also effective to indicate to the server 96 that the dispensing amount is slightly different than the amount requested by the customer. Of course in other embodiments other methods may be used. Alternatively, an in-machine applet can generate a visual display representing the local currency equivalent when displaying or processing foreign currency payments. This provides the user with payouts in both currencies on a visual display.

As shown in Figure 23, when foreign customers have completed their transactions through the touch screen 30, the foreign server 96 can effectively send a "return to home" message back to the automatic teller machine. After receiving the above message, it can effectively cause the device application part 84 to run in the aforementioned manner to respond to the embedded JAVA scripting language command, so as to configure the HTML document processing part to cause the browser 76 to re-establish communication with the local server 90 or other specified document address .

As shown in FIG. 24, the applet that processes the "return to home" message within the device application portion 84 preferably effectively reconnects with the local server 90 and sends transaction log information into the recorder 104. The transaction record information is preferably assembled within a data object containing customer name, foreign institution name, digital identifier, amount of information pertaining to dispensation, payment information for transfers or deposits and all other relevant transaction data. The transaction data is used by the applet in executing a transaction step, any portion of which data is required. Upon completion of the on-board customer activity, the applet provides a transaction data message containing at least some of the collected data. The above data is transferred from the server 90 to the computer system 94 inside the local bank office through the common gateway interface (CGI) 106 . This information stored in the office's internal computer system is then used to settle settlements with the foreign bank operating the foreign server 96 . Alternatively, transaction data may be recorded in the terminal's internal memory as well as in hard copy on the logging printer. Transaction data can be stored in batches (batch data) or pass-through (qualified) objects containing many transaction data. Bulk data may be transferred from time to time to addresses stored in the terminal configuration data memory.

One advantage of embodiments of the present invention is that transaction data may be transmitted to addresses within a local area network (LAN) or wide area network such as the Internet. This facilitates a wide variety of transactions and allows directed messaging involving tracking purposes (such as smart cards for electronic tracking) or selection of system addresses to settle different transaction types.

It should be appreciated that embodiments of the automated banking machine and system described herein have the advantage that users can conduct their banking virtually anywhere in the world when the machine is connected to a wide area network (such as the Internet) trade. In addition, no matter how extensive the capabilities of the system, the risk of fraud is minimized because machines can be monitored locally through connections and activity.

Embodiments of the present invention include another feature that facilitates accessing documents within a network to which the machine is connected. This feature is useful for determining whether an HTTP record such as an HTML document or other item can be downloaded at a certain address before a computer attempts to access the record. This avoids transactions that time out, which would otherwise result in no access to the record due to the downtime of the server through which the record is normally accessed. Other embodiments may consider both record length and transfer speed, and determine that the transfer speed of the record is not fast enough, so an alternate record should be transferred.

In one embodiment, this feature can be achieved by using a stand-alone program or applet that observes and checks whether the server that the computer will then access is valid. The applet runs in response to receiving the address or part thereof, and establishes a connection with the address. The applet decides to make a reporting interface connection to the address and loads a small but sufficient number of records or otherwise determines that the server by which the records must be accessed is valid. In response to an applet that verifies the operation of the remote server or otherwise determines that the record can be accessed or loaded, the computer then operates, thereby allowing a browser or similar module software to locate the address at the appropriate time in transactional order. If the applet fails to detect the availability of the remote server, or determines that there are no records present that can be successfully accessed or loaded, steps may be taken to access alternate addresses or abort the transaction. Access to alternate addresses can be obtained from data stored in the terminal memory or by accessing local or remote files containing data from which alternate addresses can be obtained or derived. The alternate address is also checked to make a determination that the record can be accessed before attempting to access the alternate record. This approach avoids delays in conducting transactions.

Another embodiment may use other methods to determine whether a desired HTTP record, such as an HTML document, can be successfully accessed and/or downloaded appropriately before the browser provides a client interface to attempt to access the document. The foregoing embodiments may consider transmission speed or other conditions related to system operation or document content when determining whether a document can be accessed successfully. For example, an applet that tests HTTP records that can be accessed for purposes of determining, or another applet that can be used to determine the delivery rate at which records are delivered to the computer, at which rate data that can be delivered at that delivery rate An alternate record is accessed if the transfer rate is lower than the data representative of the required storage rate compared to the data stored in memory. This could be, for example, an HTML document stored locally. Alternative embodiments may include procedures that take into account HTTP record lengths and transfer rates to determine transfer speeds. The above procedure then determines whether the record can be transferred fast enough to accommodate the parameters established in the memory configuration, and if not, alternate addresses are accessed. The aforementioned alternate recording can likewise be checked for transfer speed prior to transfer.

In deciding to visit a particular location, the program may also take into account other factors which may include, for example, date and time information, or information from, for example, sensors on the ground indicating that other persons are waiting to use the machine. It follows that accessing documents with augmented output can help avoid lengthening transactions, even when records can be loaded at a reasonable rate.

Although the embodiments of the automated banking machine and system described herein are shown to be particularly useful for making particular types of machines connected to local or wide area networks, generic automated banking machines are also suitable for incorporating the capabilities described above. In particular, both the HTML document processing part and the device application part can be included in the automated banking machine along with other traditional software to run. This allows the automated teller machine described above to operate within a traditional private network or as part of a wide area network. Additionally, automated banking machines may be configured to operate their devices either through the device interface software portion of the present invention or through a different software interface when the automated banking machines operate within a conventional network. When the above machine is running under the control of the server in the wide area network, it can be converted to need to transmit the device message through the device server to maintain the security in the system. It can thus be seen that a single ATM can operate in the manner of existing ATMs within a proprietary network as well as within the network configuration of the system of the present invention.

Alternative embodiments of the present invention communicate transaction messages for use within a network of proprietary automated teller machines. This can be done using CGI connected to the HTML document processing portion of the automated teller machine or to an HTTP local server or other server. CGI is connected to the message conversion program and the database, selects the necessary data from the HTML document and the response message, and generates a specified transaction request message suitable for the proprietary transaction network. Likewise, the message conversion program and CGI operations receive function command messages from the proprietary network and convert these messages to generate appropriate HTML documents and/or TCP/IP messages for use by the ATM. Because these proprietary network formats are defined and the data required to generate and interpret the messages is known, direct use of ATMs 12 within conventional proprietary ATM networks is achieved.

A traditional ATM transaction message is defined as a layout message that does not include an HTML document on top of an HTTP message. An example of a conventional message known to be used to operate an ATM is the Diebold 91X message. The above messages generally relate to delivery of request messages from automated teller machines within a defined layout, including customer input data (account/personal identification number (PIN)) and an indication of the type and quantity of the requested transaction. The request message is received by the host computer of an automatic teller machine, and the host computer sends back a response message with a defined layout, which contains an indication of whether the transaction is authorized or not. The ATM then sends another message back to the host computer stating whether the machine can perform the transaction. The packets used in the above-mentioned traditional proprietary network generally occupy a relatively small frequency bandwidth.

A server is provided for connecting the automatic teller machine of the present invention to the above-mentioned one network. The server is operatively connected to a memory comprising a relational database holding message conversion and document creation data. In one configuration, the server is connected to the document processing portion through a network, or may reside on a computer at the automated teller machine. The server generates a browser-accessible document containing transaction device instructions. The server (or a connection server) transmits conventional messages via the host. One server within a LAN (Local Area Network) could provide an interface to several ATMs connected to it, or alternatively, each ATM could have its own server running within it.

The communication capabilities of the ATM 12 within the proprietary network can also enable the operation of the ATM in a manner in which the interface is generated by the user's local organization as described above, but in which the transaction is directly through the message. Approved via a proprietary ATM network. Such use of a private network may achieve confidentiality, while at the same time having the advantage of providing the user with a familiar local banking interface and/or "personal home page" interface.

In the above configuration, the automatic teller machine transaction function device can operate in the traditional way, responding to the traditional automatic teller machine transaction messages in the private network, such as Diebold 91X messages. Client output devices such as screens (and speakers, if present) communicate through a browser connected to a local or wide area network. The browser prompts the user to access the document through the action of the transaction, but the document does not include instructions to cause the device (such as a cash dispenser) to work.

In one configuration, the browser, via the computer, can operate in response to the state of the device within the machine, just as the device operates in response to conventional ATM messages. In this manner, the browser can be positioned to select addresses, including those associated with the customer based on the customer's input data. However, less security is required in accessing documents since documents received through a browser cannot drive transaction function devices. Thus, the customer responds to the familiar unique interface and market transaction information such as circulars or other materials that appear in the transaction sequence, and the customer can still operate the machine.

In other embodiments, the machine may perform some device functions in response to conventional messages, while other functions may be performed in response to instructions within HTML documents, or other HTTP messages. For example, HTML documents may provide data for extensive use by printers or other output devices. Some embodiments may access some documents with instructions, but may ignore certain instructions and actions in response to other documents. System operators can configure the software according to their needs to select the above methods.

Another advantage of the system configuration of a preferred embodiment is that it increases the flexibility of routing ATM related messages. The device manager 68 preferentially generates status messages relating to the status of the device 36 . These status messages usually represent information about conditions that exist on the device. Such messages may indicate a low or depleted supply of printer paper or currency. Other messages may indicate an unhealthy condition. These messages often indicate that the ATM requires maintenance. All of the above message types are interchangeably referred to herein as status or fault messages.

Device interface software portion 64 communicates over internal network 16 using TCP/IP messages. While messages related to the aforementioned transactions are directed to the device server 92, the software portion 64 may comprise a server and be configured to forward fault and status messages to other addresses within an internal network or the Internet. For example, the above-mentioned fault or status messages can be directed to the software application part, which transmits the messages to the service provider. Furthermore, fault messages can be selectively dispatched depending on the nature of the fault indicated. For example, a failure message indicating a need for currency or supply replenishment is directed to an address within the internal network associated with the entity responsible for replenishing the supply. Alternatively, a fault message indicating that another type of service is required may be directed to an address associated with an entity that can provide the desired type of service.

Alternatively, fault messages can be selectively sent to addresses within the internal network 16, which can be done by configuring the device server 92 appropriately. Additionally, software portion 64 or device server 92 may direct fault messages from the automated teller machine to a fault handling system, for example, to a computer-operated event management system "Event Management System" available from Diebold Corporation. ^TM ” software. The software described above is effective in addressing the nature of the fault condition and notifying appropriate personnel to take corrective action.

The automated teller machine 12 also includes a software function to assist in diagnosing problems and providing remedial services. Alternative embodiments of the automated teller machine 12 may include a miniature HTTP server 109 in communication with the device interface software portion 64, as shown in FIG. The server 109 is configured to receive device status messages and generate HTML records containing HTML documents in response to the HTTP records, the HTML documents providing data representative of the device status to a diagnostic device 110 such as a handheld computer terminal. Server 109 includes a CGI interface to the device software so that technicians can access information within the records accessible at the HTTP address associated with the status message and enter test and correction instructions through diagnostic device 110 . HTTP records and/or HTML documents generated by server 109 may preferably contain graphical or audible instructions indicating conditions such as problems, as well as instructions for correcting operational data and repairing.

In other versions of the invention, the functionality of the mini HTTP server 109 may reside within the device server 92 . This is particularly suitable where the functionality of the device server resides on a computer within the automated teller machine. Regardless of where the function resides, maintenance of the automated teller machine is facilitated using the visual and audio components of the HTML documents associated with maintenance and diagnostic messages.

The records delivered by the mini-HTTP server contain instructions corresponding to status or fault conditions. The aforementioned records or documents may be accessed locally or remotely as previously described. Handheld computers used by technicians contain browsers or other software that effectively access HTTP logs, allowing access to local documentation for repair, diagnosis and service. In some cases, a client interface and a browser associated with the client interface may be used to access a small HTTP server, or a separate browser, on-board display and input devices and maintenance mechanisms may be used. Alternatively, fault and status messages can be monitored from the terminal anywhere connected to the network. The Mini HTTP Server Handling Status and Fault Messages can also be configured to send an e-mail or similar message to a selected address whenever a particular status or combination of conditions exists.

Another advantage of the above features is that HTTP messages can also be sent to small HTTP servers in order to correct existing problems. The above messages may include running diagnostic tests and receiving results. It also includes operating equipment to test or attempt to clear blockages and other malfunctions. This can often be done with remote configuration. Of course, when there is a significant risk of unauthorized access to server operating system settings (values) or device messages, appropriate security measures should be taken.

The HTTP records indicating the status of the transaction function device may have different formats depending on the software configuration and the needs of the system operator. In some embodiments, device state information for one or more devices may be represented by tags contained within the data object. Data objects can be transferred to other connected computers to provide status data. The transmission of the data object can be accomplished through, for example, remote method invocation (RMB remote method, invocation). The data in the forwarded data object can then be used to generate the messages and/or outputs desired by the system operator. The above technique may be particularly useful when an operator wants to connect a machine to an existing monitoring system. The tags contained within the data objects can be used to generate outputs or messages representing the state of the equipment. These outputs or messages Can be handled by existing monitoring systems. Plug-ins may also be used to enable communication between existing monitoring systems and transaction machines, which may have different types of status conditions or different types of message formats. This includes machines with different types of trading function equipment and capabilities.

The technique of transferring data objects can also be used for testing or modifying transaction function devices. For example, tags within a data object can be modified by a server returning the object to the machine. The built-in software may cause the transaction function device to operate or change state or programming in response to the modified data object. This could include, for example, clearing a fault indication or causing the device to start up to clear a blockage or perform a test. The results of the above activities can be reflected in a modification flag within the data object, which is then transmitted to the computer within the diagnostic terminal. Of course, the methods described herein are exemplary, and other methods will become more obvious to those skilled in the art based on the description herein.

Fig. 25 shows a schematic diagram of the network configuration of another embodiment of the automated banking machine of the present invention. The embodiment shown in FIG. 25 includes an automated banking machine that is particularly adapted to operate in conjunction with conventional automated banking machine systems (eg, systems that operate using the Diebold 91X ATM message format or other non-HTTP conventional format). Host computer 120 is a conventional ATM host using message communications as described above. The host communicates with an interface server, indicated schematically at 122 . The interface server 122 operates in the manner previously described and is operatively connected to a memory that contains information necessary for converting HTTP messages that are 91X request messages or other conventional messages belonging to transaction requests, which information can be retrieved by the host computer 120. deal with. Similarly, the interface server 122 and the instructions and data stored in the memory can effectively convert the traditional 91X command message or other traditional command message from the host computer 120 into an HTTP message, and the HTTP message can be passed through the automated banking machine. Used to execute commands. Likewise, the interface server 122 is operable to receive HTTP messages corresponding to the automated banking machine's responses to commands and generate 91X response messages or other conventional response messages to the host. For completing these functions, the interface server communicates with the interface client 124. In a preferred embodiment, the interface client is a COMM software plug-in, which runs on the banking machine under the new technology window (Windows ^NI ) operating environment system on the terminal. Interface server 122 also includes a command/status gateway 126 . The command/status gateway effectively receives command and status messages from the software part to process the functional devices in the machine. The device-related messages are used to generate transaction messages and send the transaction messages back to the host 120 . In addition, the command status gateway part also generates status messages representing the status of the device, and these status messages are also transmitted to the host.

Interface server 122, command status gateway portion 126 and interface client 124 may reside in software on the automated banking machine terminal. In this configuration, the terminal appears to the host computer as a conventional machine. Alternatively, interface server 122 and command status gateway portion 126 may reside on separate servers, while interface client portion 124 may reside on a terminal. This allows the interface server 122 to handle many automated banking machines by connecting the machines to the interface server via a network.

Another configuration of the automated banking machine system shown in Figure 25 is particularly suitable for use with existing automated teller machine systems. The machine includes an HTML document processing section 128 including a browser operating in the manner of the previous embodiments. In other words, the HTML document processing part is considered here as a browser for simplicity. The HTML document processing portion operates in conjunction with the network 130 and accesses HTTP records in HTML document format through servers 132, 134 and 136. For purposes of the example, server 132 will be considered a local bank server operating an automated banking machine. The browser portion 128 is allowed to access the local bank's files in order to obtain the contents and instructions of the files, to send output information to customers, and to operate on-board equipment. Servers 134 and 136 characterize other servers to which the automated banking machine may instruct access to download files containing information or instructions. Such files, often from non-local bank servers, will contain information provided to customers, such as advertisements, promotional materials, stock quotes, or other types of information. It should be understood that servers 134 and 136 may be directly connected to network 130 or accessible through other networks and servers. In some embodiments, the above-mentioned server is accessible via the Internet to provide documents to the automated banking machine.

The document processing portion 128 includes a terminal theater software portion 138 . Terminal theater section 138 is illustrated in detail in FIG. 26 . Terminal theater portion 138 includes a background frame 140 and a theater frame 142 . Although the background frame 140 resides within the browser, it is not visible on the screen of the automated banking machine. The theater frame 142 is a visual frame and controls what is displayed to the user.

As schematically shown in FIG. 25 , the HTML document processing section 128 also includes a terminal director section 144 . Directors contained in the Terminal Directors section are instances of applets used to perform specific types of transactions. The terminal director generally corresponds to the operation of the JAVA applet in the foregoing embodiments.

The automated banking machine of another embodiment also includes a transaction service application (TSA), indicated schematically at 146 . The transaction service application enables security, terminal conditioning, terminal authorization and key management services within the automated banking machine. The transaction service application program includes a HTTP message function for communicating with the interface server 122 . The transaction service application may also communicate via a network such as the network 130 described below. The transaction service application also provides a server function that allows the transaction service application to perform the functions of the device server 92 in the previous embodiments.

The automated banking machine of another embodiment also includes a JAVA common device interface, indicated schematically at 148 . In the preferred embodiment the JAVA common device interface is a related instance of an applet which controls and coordinates the operation of the function device 150 of the transaction function machine. Functional devices may comprise devices of the type related to the preceding embodiments or other types of devices which function to perform transaction-related functions. The JAVA public device interface 148 communicates with functional devices via a public device interface schematically indicated by 152 . Common Device Interfaces (CDIs) provide an interface that controls the electromechanical modules contained in the functional devices within the automated banking machine. The schematically shown common device interface is connected to a diagnostic server 154 . The diagnostic server operates in a similar manner to the server 109 of the previous embodiments. Diagnostic server 154 is available for diagnosing the status of equipment within the automated banking machine and correcting problems.

Referring again to FIG. 26 , the frame 140 in the background within the theater portion 138 of the terminal is an integral part of a so-called background applet 156 . Background applet 156 is preferably a thinner component. Instructions called scripts contained within documents are accessed through the browser, and when an action occurs in response to the instructions contained in the accessed documents, the script instructions selectively cause the background applet to notify the terminal control device. The background applet also acts to request access to a new HTML document. The background applet also provides assurance that the aforementioned shared transaction data objects holding transaction data can be utilized.

The theater frame 142 controls the user interface visible to the end user of the automated banking machine. The client HTML, represented schematically at 158 within the theater frame 142, determines signatures associated with events sent to the Navigation Manager 160 by the background applet and provides an interface to the Navigation Manager's utilities. The Steering Manager, indicated schematically at 160 in FIG. The Director Manager class residing in the TSA process effectively loads the Terminal Director 144 into the HTML document processing section. The Navigation Manager also contains a category of applets that reside in the background frame 140 . The Background Applet Class of the Guidance Manager provides a client HTML interface for making requests on the Guidance Manager. Instructions within the HTML document may pass events through the background applet 156 to the navigation manager. The aforementioned events include a request for a privileged transaction. The above-mentioned request may also contain an indication that the customer has completed the transaction, or the document loaded by the browser may contain an indication requesting an instruction to terminate the session. Other events that can be passed through the navigation manager include print events. Other events that may be communicated to the navigation manager by the background applet include an indication of a deleted input or other specified user events.

In response to received events, the navigation manager of the illustrated embodiment corresponds to the browser accessing instructions within the document to perform functions including changing the content of the theater frame 142 . The Director Manager reacts to the above commands and also changes the classification of the active Terminal Director. The Director Manager also caches terminal director categories for later use or loads terminal director categories and HTML documents taken from available server directories. The Steering Manager also makes it possible for specific transactions to utilize shared transaction data objects that hold transaction data. The guide manager also sends the terminal theater event to the background control classification of the current terminal guide, and prepares a screen timeout timer. Of course, in other embodiments, the terminal director may perform other functions.

In operation of an alternative embodiment shown in FIG. 25, the terminal director 144 in the transaction service application 146 allows selective access to documents including the HTML document processing portion 128. The accessed files may include instructions for operating the automated banking machine and functional devices thereon. The transaction service application software 146 can also effectively transmit HTTP messages to the interface server 122, and the interface server 122 is used to generate traditional ATM messages that the host 120 can process. In response to approval from the host computer 120, dispensing of currency and other delivery of items of value can take place, while the interface and other functions are controlled by the browser accessing commands within the document.

In a preferred embodiment, the ATM or other transaction machine communicates with a conventional ATM host (computer) computer by communicating transaction data objects between the computer within the ATM and the interface server. The above transfer is preferably accomplished through the Remote Message Invocation (RMI) feature of software (eg, JAVA). Of course, other programs that use HTTP to transfer data object files are possible.

As mentioned earlier, transaction data objects hold transaction data. The machine obtains data related to the transaction, such as account data from the card, customer PIN number, requested transaction and amount of money and data included in the transaction data.

Once the data required to generate a conventional ATM transaction message is embodied in the transaction data, the data object is transmitted to the interface server. As shown schematically, the interface server may be operatively connected to a database 123 or other item holding conversion data. The converted data is used by server-related software to generate a conventional ATM transaction request message to host 120. Legacy messages can be formatted as a legacy 91X message or other legacy non-HTTP transaction messages.

After processing, the host 120 replies with a traditional reply message. The components of the response message are received at the server, the response transformed data is processed, and the modified transaction data is generated within the data object. Said modified transaction data preferably includes data indicating whether the requested transaction has been approved or rejected, as well as other data. For example, if a transaction is declined, it may contain data indicating the reason for the rejection.

Next, the transaction data object and the modified transaction data are transmitted to the computer operating the automated teller machine via Remote Message Invocation (RMI) or other transfer method. A transaction service application 146 running in software receives the data object and activates a transaction function device sensitive to the modified transaction data. The transaction data within the transaction data object is further modified by the inclusion of information related to the operation of the device. The data transaction object and further modified transaction data are sent back to the interface server 122 after the device has been run. The modified transaction data is then used to generate a message to the ATM host. The message sent to the host contains data corresponding to the modified transaction data. Typically this message is a conventional non-HTTP completion message which indicates whether the transaction function device has successfully executed the transaction.

The format of traditional non-HTTP transaction messages is easily changed in the described embodiments. This can be done by using soft plugins. The soft plug-in can effectively put data into and take data out of the transaction data object. The soft plug-in completes the conversion between transaction data and required traditional non-HTTP messages. Application software plug-ins allow easy use of the automated teller machine shown in the embodiments in connection with various types of conventional transaction networks.

The transaction data in the transaction data object also preferably efficiently enables the computer to operate the browser to access the selected HTML document. This can be done by indicating permission or denial of access to a particular document as part of a transaction and reply message. For example, certain promotional materials that are not given to existing customers of the bank may be given to bank customers rather than to ATM operators. Transaction data indicating why the transaction was declined can be used to access a document that provides an explanation, or may encourage the user to take another action, eg, cash advance on a credit card or apply for a loan.

The system schematically shown in Figure 25 is an embodiment of an automated banking machine system that enables selection of various useful interfaces through the use of an HTML interface while preserving compatibility with and associated with existing banking machine systems. encryption technology. Of course other methods and configurations may be used in other embodiments.

Another advantage of incorporation into the system, shown schematically in Figure 25, is the efficiency with which the illustrated embodiment of the present invention operates software components in existing automated banking machines. It should be understood that the processing of HTML documents in traditional computers needs to be input through a QWERTY type keyboard (a kind of English keyboard), and the corresponding icon position or the feature on other HTML documents, click the mouse and input, so that successfully locate and Use the above document. Traditional automated banking machines generally do not include a mouse or full-digit keyboard. In contrast, traditional automated banking machines generally include an alphanumeric keypad and function keys similar to those used on telephones. Embodiments of the present invention allow operation of a system with a terminal having the above-described interface operating in a manner to the benefit of the present invention.

Figure 27 shows an example of a conventional automated banking machine interface 162. Interface 162 includes an output device including a screen 164 . Screen 164 may be a cathode ray tube (CRT), liquid crystal display (LCD) or other conventional display screen. The screen 164 shown in the example is not a touch screen as in the previous embodiments. A number of function keys 166 are provided near the screen 164 . Also included within interface 162 is a keypad 168 . Keypad 168 includes alphanumeric keys and other special purpose keys such as "CLEAR", "Correction" and "OK". Other keys on the keypad are normally blank but can be used in some cases.

In the operation of a conventional automated banking machine, screen data generated from information stored in the terminal memory generates a prescribed transaction screen graphically displayed on screen 164. These screens are displayed sequentially in response to transaction functions selected by the customer. Conventional screens also generally contain text and graphics representing choices made by the customer. These text and graphic options typically include lines or other indicia extending to the edge of the screen near one of the function keys 166 . Allows the user to select an option by pressing the function key indicated by Select. Likewise, the user is permitted to enter alphanumeric characters containing PIN numbers and quantity information and other instructions by pressing keys within keypad 168 during operation of the automated banking machine.

In one embodiment of the invention, software employed in the automated banking machine accomplishes the translation of standard ATM key inputs into operating system events, such as mouse clicks at desired locations or inputs from a QWERTY-type keyboard. The software components that allow this function to be performed are shown in Figures 28-30. These functions include a keypad applet 170 . In the depicted embodiment, the keypad applet 170 is contained within the terminal director 144 applet. The keypad applet 170 supports a subset of keyboard common device interface (CDI) functionality.

The keypad applet 170 is linked to a key command server that runs as the transaction service application 146 . The server within the transaction service application communicates with a common device interface (schematically indicated at 172) for the keypad and function keys. The key CDI in the preferred embodiment is a JAVA program which is considered a wrapper for the common device interface associated with the function keys and keypads.

The software also includes a keyboard mapper, indicated schematically at 174 . In the preferred embodiment, the keyboard mapper is linked to a database 176 which stores a number of sets of maps. In the preferred embodiment, the keyboard mapper is an extension of the keyboard class of objects for manipulating the keyboard. The keymapper runs to complete storing the keymap set in the database 176. This can be done by reading the information in the automatic teller machine's configuration database to obtain the keymaps running on the particular machine. In operation, the keymap program selects one of the keymaps as the current set. This can be done in response to the keypad applet and based on selectively accessing instructions within the HTTP record. The keymap program may select a keymap in response to instructions within an HTML document loaded via a browser. The keyboard mapper also effectively enables the keypad and function keys to be adapted to the particular set of maps selected. The keyboard mapping program responds to the selected mapping set and can also effectively convert (translate) a keypad input signal or a function key input signal into a corresponding keyboard or mouse input signal, and then transmit the keyboard or mouse input signal A stream of keyboard input or mouse input to the operating system of the computer on which the software runs.

In the preferred embodiment, the sets of maps are each composed of hash tables. Keymap objects are stored as values within a hash table such that each object contains the values and operations necessary to convert any suitable ATM key event into an operating system input event.

It will be appreciated that in the case of function keys near the ATM screen, it may be preferable to provide a mouse input to the mouse input stream corresponding to the particular coordinate location of the mouse input. This is provided by the keymapper using the selected keymap set. Various keymap sets respond to HTML documents displayed on the browser, enabling different function keys to provide different types of input to the computer operating system. In addition, the keyboard mapper causes the press of the select key to generate an input corresponding to a mouse click at the selected x,y coordinate location on the screen. It should be understood that either keypad keys or function keys can be used to generate mouse input. Likewise, function key input can also be converted to keyboard input. However, in some embodiments it is desirable to suppress the mouse pointer on the screen so that the user does not notice the common mouse icon. Such deprecation may, in some embodiments, include reducing the size of the mouse icon so that it is so small that it is not easily seen by a user of the machine.

During some part of the transaction process, it is not necessary for the user to press any keys. In such cases, certain preferred embodiments of the present invention control the deactivation of the keypad keys and/or function keys. Since computer resources are used to poll the input keys, suspending the polling at an appropriate time allows the computer resources to concentrate on other functions. This will increase the speed of other activities. In some embodiments, this may be accomplished by the keypad applet effectively eliminating key devices from a round-robin list.

28-30 contain schematic depictions of examples of keyboard mapper and keypad applet operation. FIG. 29 shows an example of keypad 168 entry. In this embodiment, the keypad applet 170 generally responds to instructions within an HTTP record (eg, an HTML document or other event) allowing the event to be communicated to the transaction service application 146 . In response, a set of images is selected from the database 176 corresponding to the name of the particular image. The keyboard command server further effectively activates the appropriate key for the automated teller machine.

In this embodiment, in response, the customer presses the "OK" key on the keypad, and the CDI generates an appropriate signal to the transaction service application. It can be noted from FIG. 27 that the "OK" key is conventionally referred to as the "J" key of the ATM interface. The device service application passes the signal generated from the client pressing the "J" key to the keyboard mapper 174. In response to receiving the signal, the keyboard mapper 174 operates to resolve the object in the map set corresponding to the map name to convert the function key input signal into a keyboard input signal recognized by the operating system. By calling the selected object from the map, a keyboard input signal is generated and sent to the computer's keyboard stream. This is shown by keyboard flow 178. In the illustrated embodiment, the keyboard stream is an input to the New Technology Windows (Windows NT) operating system. The keypad applet 170 initiates receiving (listening to) device readout input through its corresponding key. The applet 170 is also operative to receive events and display an icon or other graphic corresponding to what the customer has entered.

FIG. 28 shows the operation of the keymapper in a situation where the transaction service application prevents the transfer of customer-entered data to the applet 170 function. This is desirable, for example, where the customer has entered the customer's PIN or other data that is not displayed. In the above case, the transaction service application 146 acts to hold the customer input data and simply sends a signal representing the hold character, in which case a "*" symbol is sent back to the browser. This is done optionally in response to instructions contained within documents accessed by the browser or in response to instructions contained within other HTTP records accessed by the computer, which instructs the user to enter a PIN that matches their PIN or is not sent to the Other browser data. In the example shown in FIG. 28, only the held characters are transferred to the browser through the keymapper. In the case of an accessed HTTP record caller, where a numerical value (for example, the amount of a reversed transaction) is prepared to be sent to the browser and/or displayed on the screen, represented by a signal sent to the browser by the transaction service application The numeric value associated with the key being pressed.

FIG. 30 is another example of the operation of the keyboard mapper, in which case the input corresponds to the function key 166. In this condition, input is made by pressing the function key "A" near the upper right corner of the screen as shown in FIG. The signals generated in response to pressing the function keys are passed to the keyboard mapper which, in response to the data obtained from the data memory 176, outputs mouse input corresponding to a mouse click. Mouse input contains x and y coordinates representing the screen where the mouse click data is provided. The above-mentioned mouse input signal is then passed to the mouse stream input, indicated schematically at 180 .

It can be seen that, enabling an automated banking machine that processes HTML documents to operate using a conventional automated teller machine interface, the mouse input will typically include a coordinate location corresponding to a location on the screen near a particular function key. This is because the icon, line, word or other mark selected by the customer through the key will be preferentially displayed or extended on the screen near the key. This makes the customer aware of which key to press to make a corresponding selection through visual presentation. Many function keys near the screen are available at any one time. The customer can make a selection by pressing a function key at one location and then pressing a function key at another location disposed away from the first location. This will cause the signal sent to the mouse stream to correspond to a mouse click at the coordinates on the screen near the function button pressed by the customer. During a transaction, combinations of functions and keypad keys are operable and can be mapped to various keyboard and mouse inputs as defined by the selected map set. Additionally, developers can develop proprietary image sets that correspond to specific images that can be displayed within an HTML document.

By sending keypad input to a conventional ATM or other automated banking machine in the manner previously described, the keypad input can be converted to conventional keyboard or mouse input, which can be recognized and processed as either a conventional keyboard input stream or a mouse input stream . Likewise, function keys can be translated into mouse input at selected locations and passed into the mouse input stream to be processed by the computer, or function keys can be converted into keyboard input and passed into the keyboard input stream . Another advantage of the terminal configuration is that these function keys can be selectively deactivated (disabled) unless they are needed. This reduces instances of attempts to use the machine improperly by pressing keys on the keyboard. Additionally, the preceding steps can be taken to disable function keys when they are not required to increase transaction processing speed.

Another advantage of embodiments of the present invention resides in the automated banking machine's ability to provide printed material based on instructions within an HTML document. The aforementioned printed items may include tickets, travelers cheques, money orders, bank checks, temporary securities, or other types of materials. The ability of the preferred embodiment to access and process HTML documents allows graphics and other indicia to be printed with selected appearance characteristics and selected decorative patterns of the printed material. This reduces the need to utilize pre-printed formats and also allows a greater variety of print formats to be printed. In addition, some embodiments of the machine are configured to allow only selected portions of transaction information to be printed for record keeping purposes on-board, while at the same time providing versions to customers that include enhanced graphics or other attractive features .

Fig. 31 is a schematic diagram of the system operation in the case of printing various bills using the automatic banking machine built-in printer. The best mode of the present invention uses WIN32 printer service program under Windows NT4.0 operation. In the exemplary transaction shown, director manager class 180 operating within terminal theater portion 138 initiates a print receipt transaction by requesting printer director 182 to print a receipt. In a preferred embodiment, the printer director is a collection of instances related to JAVA Beans (SUN's plan to establish an open API that is fully written in JAVA). JAVA Beans plays the role of realizing printing activities, and in the terminal guide Among the controllers 144 is a director. The printer director contains a separate printing class shown schematically which effectively invokes a printing URL (Uniform Resource Address) procedure. In a preferred embodiment, printing classification involves utilizing a shared transaction data object containing customer-specific information related to the transaction, the customer-specific information containing tags representative of the information to be printed. In the case of an automated banking machine, this may include, for example, indicia representing information which can be read from a customer's card entered into the machine (by a card reader). Such information may include, for example, customer name and account number. Other transaction information may include the type of transaction performed, eg deposit (savings), withdrawal or inquiry and the amount involved in each related transaction.

The transaction service application 146 receives the print request and passes the URL string to the WIN printer object 184 through the print URL procedure. In a preferred embodiment the URL address is the address of an HTTP record such as an HTML document for formatting the material to be printed (receipt in this case). This HTML document contains embedded JAVA scripting language for processing transaction data from transaction data objects. The document's URL address may be on the local machine, or may be retrieved from another server, such as over the network indicated at 186 . Network 186 can be a local area network or a wide area network depending on the configuration of the machine.

The WIN printer object 184 is then located at the address of the document to be accessed. In the preferred embodiment, this is accomplished using the Microsoft Corporation Web Browser (Microft's C Web Browser 2 Active X) control. When an HTML document has been loaded the Active X control automatically starts processing the content of the accessed document. The transaction service application 146 calls the print URL routine of the WIN printer object 184 . This WIN printer object uses the Active X control to print the current HTML document. Printing is handled through the Windows NT ^(R) print input output subsystem (Print Spool) and graphics components.

JAVA CDI receives an event from the print monitoring component 192, indicating the completion of the print input and output subsystem (spool). This indicates that the existing file to be read is valid and sends the file to the Common Device Interface (CDI) 188 of the receipt printer.

Then a print object 190 calls the read data function in the print monitor 192 to determine the location and size of the print data file. The printer object 190 sends the data or the path name of the data file to the printer CDI 188, respectively. The printer CDI 188 then transmits the print data to the printer hardware. This result results in the printing of the data.

Once the receipt is printed, a request is sent from the printer director 182 applet to send the printed receipt. The transfer request is passed through the transaction service application 146 to the printer object 190 . The printer object 190 calls the transfer routine on the printer CDI 188 to cause the receipt to be transferred to the machine user. Operation of the software components allows selective access to the document format and use of instructions contained in the document to include transactional data within the printed document. This allows various types of materials to be printed out. In addition, it is also allowed to provide different types of printed materials for different customers. This is desirable in providing market information, coupons (coupons) or similar indicia on transaction receipts. This approach also simplifies providing print formats in multiple languages by developing HTML documents that provide print formats in different languages. In addition, the program of the present invention can be used to provide marketing quotes to customers by user profile or customer category type and base (address).

While the foregoing printing routines have been discussed in connection with transmitting transaction receipts, similar routines can also be invoked to print customer financial statements as well as print transaction journals within automated banking machines. In addition, by accessing selected documents to control print formatting of said information log records may also be equipped with consolidated (unified) information in a manner that allows for promotional or other types of information provided on customer profiles without printing Save log files on-board.

The printing procedure of the present invention also allows printing of various types of optical indicia, such as bar codes or other types of machine-readable indicia, which can be used to print coupons, checks or similar items. The above codes facilitate the tracking of the use of the above items by the client in evaluating the effectiveness of various marketing sales effects. Additionally, machine-readable indicia may be used to print on some items, for example, on deposit envelopes and/or within transaction journals. Such printing may facilitate machine reading of said items to identify deposit contents.

The printing capability achieved by the program of the present invention also allows printing of selected graphics data. This may include, for example, embedded digital signature material for verifying the authenticity of printed items. This may be particularly useful where, for example, a transaction processor is used to print certificates, travelers checks, lottery tickets or other items of independent value. In addition, full-color printed materials may be produced by a color printer included in the transaction processor.

The computer software for operating the automated banking machine of the present invention and the connected computers can be made of various types of articles to be incorporated into the associated computers. The computer software described above may be contained on one or more articles of manufacture and one or more articles of manufacture (eg, floppy disk or compact disk) loaded into a computer. The software described above may also be contained on some article of manufacture, for example, a hard disk drive, magnetic tape or ready-only storage device. Other articles of manufacture, including data representing instructions for operating the computer, are suitable for carrying out the operation of the transaction processor and system of embodiments of the present invention in the manner described herein.

Exemplary embodiments of the automated banking machine and system are described herein with reference to specific software components and features. Other embodiments of the invention may include other or different software components that provide similar functionality.

Thus, the new automated banking machine and system of the present invention achieves the above objects, eliminates difficulties encountered with prior art devices and systems, solves problems and achieves the desired results described herein.

In the foregoing description, certain terms have been used for brevity, clarity and understanding. They do not, however, have this unnecessarily limiting meaning, since the above terms are used for descriptive purposes and should be interpreted broadly. Furthermore, the descriptions and illustrations herein are by way of example only, and the invention is not limited to the details shown and described.

Any feature in the following claims as a means for performing a function should be construed to include any means for performing the recited function and should not be considered limited to the specific means for performing the preceding description or only its some equivalents.

Having described the features, findings and principles of the present invention, construction, operation, advantages and means of obtaining effective results; new and effective structures, means, elements, arrangements, components, assemblies, systems, devices, operations, procedures, processes and relationships are contained in the appended claims.

Claims (20)

1. An automated banking machine system, characterized in that it comprises: a plurality of different types of transaction function devices, wherein the plurality of different types of transaction function devices includes at least one available transaction function device, and the plurality of different types of transaction function devices are selectively operated to conduct transactions of different types Function; display device; browser means for accessing HTML documents operative to access HTML documents corresponding to the availability of said plurality of different types of transaction function means, from which output is provided through said display means. 2. The system according to claim 1, wherein the browser device accesses the HTML document at an address during operation, and at least a part of the address indicates at least one of the different types of transaction function devices A transaction function device is included in the automated banking machine system. 3. The system according to claim 1, wherein the different types of transaction function devices include a storage mechanism. 4. The system according to claim 1, further comprising a server, the server transmits at least one document to the browser device during operation, wherein the document responds to a specific type of the different types of transaction function devices The availability of the transaction function device is communicated. 5. The system according to claim 4, wherein the available transaction function device includes a paper dispenser that executes a distribution transaction but does not include a storage mechanism that executes a savings transaction, and the server transmits to all The at least one document of the browser device contains references to distribution transactions and does not contain references to savings transactions. 6. The system according to claim 4, wherein the available transaction function device includes a paper dispenser for executing a distribution transaction and a storage mechanism for performing a savings transaction, and the server transmits to the browser when it is working. The at least one file of the server device contains references to both distribution transactions and savings transactions. 7. The system of claim 1, wherein said at least one available transaction function device in said automated banking machine system comprises a sheet dispenser adapted to be selectively selected from The system dispenses paper sheets. 8. The system of claim 1, wherein the different types of transaction function devices in the system include card reader devices, paper dispensers, storage mechanisms and receipt printer devices. 9. An automated banking machine system, characterized in that it comprises: An automated banking machine comprising: multiple types of transaction function devices, each type of transaction function device selectively operative to perform a transaction function, at least one output device selectively operative to provide an output to a user, at least one storage means, comprising data representative of said multi-form transaction function means within the automated banking machine, and browser means for accessing HTML documents; a server operatively connected to said automated banking machine, comprising a plurality of HTML documents deliverable through said server, wherein said automated banking machine operatively transmits data representing said transaction function means to said server, The server is operative to deliver at least one HTML document to said browser device in response to receipt of data representing said transaction function means, and said automated banking machine is operative to process said at least one HTML document in response to said browser device. an HTML document to operate the at least one output device. 10. The system of claim 9, wherein said at least one HTML document contains instructions for operating at least one transaction function device, said automated banking machine operating in response to said at least one HTML document, operating The at least one transaction function device. 11. The system of claim 9, wherein said server is operative to generate said at least one HTML document in response to receiving data representative of said transaction function device. 12. The system of claim 9, wherein said transaction function device in said automated banking machine comprises a paper dispenser adapted to receive from said automated banking machine Paper sheets are selectively distributed. 13. The system according to claim 9, wherein the transaction function device in the automated banking machine includes a card reading device, a sheet dispenser, a storage mechanism and a receipt printing device. 14. A method of operating an automated banking machine comprising the steps of: (a) providing a plurality of HTML documents, each of which is accessible by the server, a first document of said HTML documents containing a first reference to a first transaction made by a first transaction function device; A transaction type, the first transaction function device can be installed in the automated banking machine, the second document in the HTML document contains a second reference to a second transaction performed by the second transaction function device version, the second transaction function device can be installed in the automated banking machine; and (b) accessing the first or the second HTML document with a browser device in the automated banking machine, wherein, when the automated banking machine includes the first transaction function device but does not include the second transaction function device , access the first document in the HTML documents, and access the second document in the HTML documents when the automated banking machine includes the first and the second transaction function devices. 15. The method of claim 14, wherein step (b) comprises accessing a first one of the HTML documents at a first address, or accessing a second one of the HTML documents at a second address. 16. The method according to claim 14, wherein, prior to said step (a), further comprising the step of: (c) transferring device data representative of said transaction function device contained within said automated banking machine from The automated banking machine transmits to the server, wherein the first or second of the HTML documents accessed in step (b) is provided by the server in response to the device data. 17. The method of claim 14, wherein the first transaction function corresponds to a sheet dispenser and the second transaction function corresponds to a storage mechanism. 18. The method of claim 14, wherein the first and second transaction function devices are selected from card reading devices, sheet dispensers, storage mechanisms, and receipt printing devices. 19. A method of operating an automated banking machine comprising the steps of: (a) providing automated banking machines comprising multiple transaction function means, display means and browser means for accessing documents; (b) providing a plurality of documents, each of which is accessible from a server over a network, a first document of said documents comprising a first display reference corresponding to a transaction function device in an automated banking machine The first availability condition of the document, the second document in the document contains a second display reference, the second display reference corresponds to the second availability condition of the transaction function device in the automated banking machine; (c) accessing the first or the second document with said browser device, wherein when the automated banking machine provided in step (a) corresponds to said first availability condition, accessing said document in when the automated banking machine provided in step (a) corresponds to the second usability condition, accessing the second file in the files. (d) outputting an output through said display means, the output corresponding to said document being accessed. 20. The method of claim 19, wherein the automated banking machine provided in step (a) comprises a paper dispenser.

Images