RU2255371C2 - Automated banking machine system and method for improvement thereof - Google Patents

Abstract

FIELD: computer science.

SUBSTANCE: variants of methods include forming of blocks for controlling terminals, which generally match transactions, performed by automated transaction machine. Terminal control blocks control visually formed links between multiple objects of automated transaction machine in workspace. As objects following objects are used: authorization object, concealed control object, object of device for reading from card, client profile object, depositor object, dispensing device object, auxiliary keyboard object, logical object, server object, presenter object, PIN-code input object, printer object, synchronization object and transaction data object. Devices realize operations of methods.

EFFECT: higher reliability.

17 cl, 59 dwg

Description

Technical field

The present invention relates to automated banking machines. More specifically, the present invention relates to a device and system of an automated banking machine that can be used on a global network that provides the user with a familiar interface of his "home" institution in banking machines used by other institutions, and which provide significantly more opportunities for obtaining results ( production standards) using a machine.

State of the art

Automated banking machines are known. A common type of automated banking machine used by customers is an automatic cash register (“AKM”). AKMs enable customers to complete transactions (banking transactions). Common transactions that can be performed using AKM include cash withdrawals, deposits received, transfers between accounts, payment of bills and requests for account balances. The type of transactions that a client can perform is determined by the capabilities of a particular banking machine and the planning of the institution using the machine. Other types of automated banking machines may allow customers to write to any account or transfer funds. Other types of automated banking machines can print or issue securities, such as coupons, tickets, bet forms, vouchers, checks, food stamps, money orders, government bonds or travel checks. For the purpose of this disclosure, an automated banking machine or automated transaction machine should encompass any device that performs transactions involving the transfer of values.

Currently, AKM is used in private communication networks. These networks connect AKMs used by financial institutions and other organizations. Networking often allows a user to use a banking machine used by another institution if the banking machine of another (“foreign”) institution is connected to a network that includes the user's institution. However, when the client uses the machine of another ("foreign") institution, the client must use the machine using the user interface that the other institution installed for his bank machines. In addition, the user is limited by the transaction capabilities provided by another institution.

The client may have difficulty using the machine of another (foreign) institution. Problems may occur because the user is not familiar with the type of machine used by another institution. There may be confusion because the client does not know which buttons or other devices need to be activated in order to complete the desired transactions. The transaction flow for a client in a machine of another institution may differ significantly from the machines used by the user's home institution. It can be especially problematic when the user is a representative of another country and is not familiar with the type of banking machines or the language of the interface provided by another institution. Similarly, documents that are printed by printers in an automated banking machine are usually limited to a limited group of specific formats in one language.

Another institution may also provide different types of transactions than those with which the user is familiar in their "home" institution. For example, a user's home institution may allow funds to be transferred between accounts through their automated banking machines to enable the user to maintain funds in accounts that bring higher interest until they are needed. If another institution does not provide such an opportunity, the user will not be able to do this when working with another machine. The inability of the user on another ("foreign") machine to conduct transactions to which he is accustomed can be a problem.

Networks that use automatic cash registers and other types of automated banking machines typically use private networks, access to which is limited. This is necessary in order to prevent fraud or interference with the network or user accounts. Private networks are also commonly used to send credit card messages and other financial transaction messages. Access to such a credit card processing system is also limited primarily to maintain protection.

WAN communication enables the transfer of messages between remote locations. The most famous global network is the Internet, which can be used to provide communication between computers around the world. The Internet is not used so widely for reporting financial transactions because it is not a secure system. Messages intended to be received at a specific computer address can be intercepted at other addresses without detection. Since messages can be intercepted at locations that are remote from the recipient in the world, it is possible for fraud and corruption.

Companies are starting to provide approaches for more secure messaging over the Internet. Encryption methods are also applied to messages transmitted over the Internet. However, the openness of the Internet has limited its usefulness for financial communications, especially financial communications related to the operation of automated banking machines.

Messages on wide area networks can be transmitted using the Transmission Control Protocol / Internet Protocol ("TCP / IP"). US patent No. 5706422 discloses an example of a system in which financial information stored in databases is accessed through a private global network using TCP / IP messages. Messages transmitted on networks that use TCP / IP may include “documents” (also called “pages”). Such documents are created in a hypertext markup language ("HTML"), which refers to a markup language, which is a type of programming language used to create documents with built-in commands, or "tags." Tags are codes that identify features and / or operations of a document, such as fonts, layout, inserted graphics, and hypertext links. Markup language documents, such as HTML documents, are processed or read using a computer program called a "browser". Tags tell the browser how to process and manage objects that are visible on the screen and / or listened to in speakers connected to a computer running the browser program when processing the document. HTML documents can be transmitted over the network using the Hypertext Transfer Protocol ("HTTP"). The term "hypertext" is a reference to the ability to embed links in the text of a document that allows you to communicate with other documents that can be accessed on the network.

Thus, there is a need for an automated banking machine and system that can be used on a global network such as the Internet, while at the same time providing a high level of protection. There is also a need for an automated banking machine and system that provides the user with a familiar interface and transaction capabilities of their "home" institution when working with machines of another ("foreign") institution. Additionally, there is a need for a machine that can provide users with a large number of transaction options and types of promotional and printed materials.

SUMMARY OF THE INVENTION

An object of the present invention is to provide an automated banking machine in which a user can conduct transactions.

A further object of the present invention is to provide an automated banking machine that can be used by connecting to a global network.

An additional objective of the present invention is the creation of an automated banking machine and system that provide the user with a familiar interface and transaction capabilities of his "home" institution in the machines used by other (foreign) institutions.

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

Another objective of the present invention is the creation of an automated banking machine that allows the connection of the banking machine to the user's home institution through the markup language of documents and TCP / IP messages formed depending on the indication information on the card inserted by the user.

Another objective of the present invention is the creation of an automated banking machine and system that performs transactions over the global network, while maintaining a high level of protection.

The next objective of the present invention is the creation of an automated banking machine and a system that controls the connection of the banking machine to external addresses through a proxy server.

Another objective of the present invention is the creation of an automated banking machine, which restricts the operation of devices in the machine through a local device server.

The next objective of the present invention is the creation of an automated banking machine and system that works by connecting to the Internet.

Another objective of the present invention is the creation of an automated banking machine, which can be used to provide the user with a large number of message types, including messages directed to specific users.

The next objective of the present invention is the creation of an automated banking machine, which is able to provide users with a wide variety of printed documents.

Another objective of the present invention is the creation of an automated banking machine, which provides additional opportunities for the identification of authorized users.

The next objective of the present invention is the creation of an automated banking machine, which can be used when connected to existing transaction transfer systems, while at the same time providing enhanced functionality.

Another objective of the present invention is the creation of an automated banking machine, which provides advanced diagnostic and maintenance capabilities.

A further object of the present invention is to provide an automated banking machine that executes transactions more quickly.

A further object of the present invention is to provide an improved system in which automated banking machines are used.

Another objective of the present invention is the creation of improved working methods for automated banking machines and systems.

Additional objectives of the present invention are apparent from the following description of the best modes of carrying out the invention and the attached claims.

The above problems are solved in an example embodiment of the invention by means of an automated banking machine, which includes output devices, such as a display screen, and data input devices, such as a touch screen and / or keyboard. The banking machine further includes devices such as an automatic paper cash dispenser, a printing mechanism, a card reader / writer, a depository mechanism, and other functional transaction devices that are used by the machine to complete banking transactions.

A banking machine is operatively connected to at least one computer. The computer is operatively connected to output devices and data input devices, as well as to a cash dispenser, a card reader and other physical transaction devices in a bank machine. A computer includes software running in it. The software includes a part for processing documents for processing HTML or other documents. The document processing part sends and receives HTML documents and HTTP messages. The HTML document processing part is preferably operatively connected to output devices to display data including hypertext link pointers. The document processing part is also preferably operatively connected to a data input device that allows the user to select and generate response messages from a computer. The document processing part is preferably operatively connected to the JAVA software environment and has the ability to execute commands in a JAVA script (JAVA script) transmitted with the documents.

The computer software of an example embodiment further preferably includes a device control application part. The application control part of the device includes software that is designed to control a paper money machine and other devices. In an example embodiment of the invention, the device control application part includes a plurality of JAVA application programs (JAVA applets) for operating devices in a machine.

The computer in an example embodiment of an automated banking machine further includes a part of a software interface for communicating with devices. Part of the software interface for communicating with devices is intended to receive messages from the application part of the device control and to force the device to work through appropriate hardware interfaces. In one embodiment of an automated banking machine, a document processing part, a device management application part and a software interface part for communicating with devices each are always on the same computer and are exchanged via different IP ports.

In one example configuration, the automated banking machine according to the invention is exchanged using TCP / IP messages on an intranet (intranet - corporate network), which includes many such machines. The intranet, in turn, is associated with at least one computer that is used by the home institution. A "home" institution is an object that operates with banking machines.

The home institution computer preferably includes a home HTTP server, a proxy server, and a device server. A proxy server communicates through an intranet with a piece of document processing software in each of the banking machines. A proxy server can also be connected to a global network, such as the Internet, to which other servers are connected. The device server is designed to transfer messages between the application part of the device management software and the part of the software interface for communication with devices in banking machines. A device server may include monitor software that monitors and selectively restricts the use and operation of devices in a banking machine. This provides a level of protection.

The automated banking machine and the system of the exemplary embodiment is operable to connect users to an institution where they have their accounts. This can be either a “home” institution that uses a banking machine where the user is present, or another (foreign) institution that is connected to the global network. In order to use the banking machine, the user enters data that corresponds to an address, such as a URL (unified index of an information resource), through an address data input device. Part for processing documents is used to connect the banking machine to the server corresponding to this address. This can be done in the example of an embodiment by a user having indication information representing an address on a card that is read by a card reader in a bank machine or other data entry device identifying a user or institution or entity with which the user has settlements.

The part for processing documents in response to entering the address from the card or other input information is connected through a proxy server to the user's institution. If the "home" address of the user's institution corresponds to the "home" server, the banking machine operates in response to receiving messages from the "home" server. If, however, the user address entered matches the address of another server, the proxy server communicates through a global network with another (foreign) server in the client’s "home" institution. If a client forces the machine to connect a server used by another institution, the documents sent from that other institution correspond to the documents usually issued by that other institution. As a result, the client is familiar with the interface formed in accordance with these documents and is able to use the banking machine more easily.

Another (“foreign”) server or “home” server uses the banking machine, sending documents that include commands that enable devices to work in the banking machine. Commands are transmitted from the document processing part to the application part of the software for controlling a device that uses devices in response to commands. Commands from the application part of device management to devices in an automated banking machine pass through the device server of the "home" institution. This helps maintain protection. In addition, the proxy server may include security software that restricts the connection of other servers that can connect and use the banking machine. This is called a "firewall."

Embodiments of the present invention also provide enhanced user interfaces for printing a wide variety of documents using a banking machine. The invention also allows for enhanced functionality using existing transaction networks and automated transaction machines.

Brief Description of the Drawings

Figure 1 depicts a schematic representation of a network configuration including an example embodiment of an automated banking machine device and system according to the present invention.

2 is a schematic representation of an example embodiment of an automated banking machine according to the present invention.

Figures 3-24 are a schematic representation of an automated banking machine, an intranet connecting a banking machine to a computer system of a home bank, and a global network connecting a computer system of a home bank to another bank.

Figure 3-18 in a schematic form represent the steps of a transaction performed in a banking machine with a computer system of a "home" bank.

Figures 19-24 schematically represent the steps of a transaction performed in a banking machine with a computer system of another bank.

25 is a schematic diagram of a network configuration including an alternative embodiment of an automated banking machine according to the present invention.

FIG. 26 schematically represents a frame view in part of processing an HTML document according to an alternative embodiment of the automated banking machine shown in FIG. 25.

Fig. 27 is a schematic representation of a client interface of an automated banking machine and function keys and keys of an auxiliary keyboard included in the interface.

28-30 schematically represent examples of steps in converting input data using a function key and auxiliary keyboard keys to an input keyboard data stream and mouse data stream.

31 schematically represents an example of steps for printing documents using an automated banking machine.

Fig. 32 shows a screen image representing the combined output from five browsers operating in an automated banking machine.

Fig. 33 shows a screen image representing the output from three browsers operating in an automated banking machine.

Fig. 34 shows a screen image representing output data from nine browsers operating in an automated banking machine.

Fig. 35 shows a screen image representing output data from two browsers operating in an automated banking machine.

36 shows a screen image representing a visual programming environment for creating terminal control units.

Fig. 37 depicts a portion of a visual workspace representing a combination of events with methods and a connection of parameters between AKM objects.

Fig. 38 shows a screen image representing a window for creating, viewing, or changing a connection of an event to a method.

Fig. 39 is a table representing AKM objects and associated visual graphic symbols (icons).

Figures 40-53 schematically represent examples of AKM objects with related methods, events, and properties.

Fig. 54 schematically represents the interaction between a client, a terminal control unit, a database, a host computer, and a plurality of AKM devices.

55 is a schematic view representing an interaction between a client profile object and a plurality of stored data.

56 is a schematic view representing an example of an AKM that enables AKM entities to determine the capabilities of devices and determine the rules for using devices to "neutralize" a failure when the original device becomes inoperative.

Fig. 57 is a schematic view representing an alternative embodiment of an AKM that includes a modified J / XFS core to enable AKM entities to determine device capabilities and determine rules for using fault mitigation devices.

Fig. 58 is a schematic view representing a native embodiment of AKM, which includes an extended level of ASMA ("open device services", ODS) to enable AKM entities to identify device capabilities and determine rules for using the "mitigate" devices .

59 is a schematic view representing an alternative embodiment of an AKM that includes an ASMA layer to provide an interface between a modified J / XFS core and a WOSA / XFS administrator. The best embodiments of the invention.

In the drawings, and specifically in FIG. 1, a network configuration is shown schematically indicated as 10, which includes an automated banking machine device and a system according to an example embodiment of the present invention. Network 10 includes many automated banking machines 12, which in the example system are AKM. The AKM 12 is associated with the computer system of the home bank, schematically indicated 14. The computer system 14 of the home bank is a computer system that is used by a bank or other institution that has primary responsibility for the AKM 12. The computer system 14 of the home bank with AKM 12 through the intranet 16. The intranet 16 is preferably a local or private network that provides communication between the computer system 14 and the banking machines 12 using messages in the format of the control protocol Transmission / Internet Protocol ("TCP / IP").

Messages that are transmitted through intranet 16 in the example embodiment are preferably TCP / IP messages and hypertext markup language ("HTML") documents. In one example embodiment, HTML documents sent via intranet 16 include embedded commands of an object-oriented programming language, preferably in the JAVA® format, which was developed by Sun Microsystems. Messages sent through intranet 16 can be sent in encrypted or unencrypted form, depending on the properties of the system and the security needs of the home bank.

It should be noted that embodiments of the invention may process other forms of documents that include tags or commands. For example, a form of "advanced" HTML ("XML") has recently been developed that can be used in embodiments of the invention. For the purposes of the invention, all such forms of languages and variations that include documents, these documents including commands, should be referred to as documents in a markup language. Similarly, although JAVA® is used in the described embodiment, other programming languages may be used. For example, Active-X ™ developed by Microsoft or other languages may be used in other embodiments. It should also be understood that the commands included in the documents may force the computer to access other documents, records, or files at other addresses in order to obtain a program for performing the operation.

The home banking computer system 14 may also be connected, as shown, to the global network 18. In some embodiments, the global network 18 is the Internet. In other embodiments, other wide area networks may be used. The wide area network preferably exchanges TCP / IP messages between multiple computer systems connected to the wide area network. These other computer systems are schematically represented by servers 20, 22, 24, 26 and 28. It should be understood that servers 20 to 28 can be used or connected to other financial institutions around the world. Servers 20 to 28 preferably exchange markup language documents and other HTTP messages during operation.

Figure 2 depicts a schematic representation of AKM 12 used in one example of an embodiment of the invention. The AKM 12 includes a touch screen 30. The touch screen 30 includes a display screen that serves as an output device for communicating with a user of the machine. The touch screen 30, since it is a touch screen, also serves as a data input device for receiving commands entered by a user. The touch screen 30 is connected via an interface 32 to at least one computer 34, which is preferably housed in a machine. Alternative embodiments of the invention may include other types and / or additional output devices, such as sound speakers.

The computer 34 is also connected to a variety of transaction processing devices 36, which are included in the AKM 12. The devices 36 include, for example, a reader, such as a card reader / writer 38 and keyboard 40. The devices 36 further include a device 42 cash dispensing, which serves to issue leaflets, which in some preferred embodiments of the invention are money or bank notes. Devices 36 also include a depository 44 (storage) for receiving deposits in a safe place in the car. Deposits in embodiments of the invention may include sheets such as bills and checks and / or securities placed in envelopes, such as depository envelopes. A printer 46 for printing checks for providing customers with transaction checks is also present among devices 36. A journal printer 48 (event logging) is also present among devices for storing a hard copy of a record of information related to a transaction. In other embodiments, other or additional transactional functional devices may be used that perform other transaction support functions. Other embodiments may include fewer functional transaction devices. It should also be understood that although the described embodiment of the invention is an automated banking machine, the principles of the invention can be used in many types of transaction machines that do not necessarily perform banking transactions.

Each of the devices is operatively connected to the internal control bus 50 in the banking machine 12. The control bus 50 issues internal messages to specific devices. Each device has a corresponding hardware interface, which enables a particular device to work in such a way as to perform its corresponding function in response to messages transmitted to it via the control bus 50. The card reader / writer 38 has a hardware interface schematically indicated by 52. The hardware interfaces 54, 56, 58, 60 and 62 are respectively for connecting a keyboard 40, a cash dispenser 42, a depository device 44, a receipt printing device 46 and a journal printer 48 to the control bus 50.

Computer 34 has several programs executed therein. In an example embodiment of the invention, these programs include a part of a program interface for communicating with a device, generally indicated at 64. Part 64 of a program interface for communicating with a device preferably includes a program interface 66 with a device that causes a computer to send electronic messages over a bus 50 controls. Part 64 of the program interface for communicating with the device also preferably includes a device control program 68. The device management program is preferably designed to control various devices 36 and control their various states to ensure that they are working properly in sequence. The device management program is also preferably designed to communicate with device software objects to enable devices to operate in response to at least one object-oriented program. Part 64 of the program interface for communicating with the device also includes an object-oriented program part 70, which in one example embodiment is an application task written in the JAVA language. Program 70 works in conjunction with a device management program to receive messages that make devices work, and send device operation messages showing the way the devices work and / or receive input.

Part 64 of the program interface for communicating with the device in the described embodiment runs on computer 34 and communicates via physical TCP / IP connection 72 to intranet 16. The physical connection can be an analog telephone connection (cable), a serial port, or a digital network connection with complex services (CSSC, ISDN) or other suitable connection. In the configuration of the system shown, part 64 of the program interface for communicating with the device is exchanged via the IP address of the computer 34 via an IP port, or a connector designated 74, which is different from other software applications. In other embodiments of the invention, part 64 of the program interface for communicating with the device may operate on a different computer than the one on which other applications are running.

It should also be understood that, although in an example embodiment of the invention, part 64 of the interface for communicating with the device is software, in other embodiments, all or part of the instructions for performing operations performed by software part 64 may be resident in ROM or other recording media connected to one or more computers that are used to communicate with devices 36. For the purposes of the invention, all such forms of executable instructions are called software.

Other software also runs on computer 34. This software includes document processing software that includes a browser schematically indicated at 76. In one example embodiment, the document processing software includes a Netscape Navigator® browser provided by Netscape Communications. However, in other embodiments, other document processing and messaging software and browser programs, such as Hot JAVA® from Sun Microsystems or Internet Explorer (TM) from Microsoft, may be used. Browsers used in embodiments of the invention can be designed to process documents and serve to force the computer to provide output signals that can be used to obtain visible images on the screen, as well as other types of signals or messages. In an example embodiment, the browser 76 is exchanged in the computer 34 through the IP port indicated by 78.

The browser 76 is in operative connection with the software 80 of the JAVA environment, which enables the computer 34 to run programs in the JAVA language. JAVA programs have the advantage that they can work the same on a variety of hardware platforms without modification. This "write once / execute everywhere" capability makes the JAVA environment well suited for the described embodiment of the invention. However, other embodiments may use different types of programs.

The JAVA environment software 80 enables the computer 34 to execute instructions in a JAVA script schematically indicated by 82. The instructions that are executed by the computer in the JAVA script are preferably embedded JAVA script commands that are included in HTML documents received through the browser 76. In this example embodiment, the browser 76 associated with the JAVA environment software 80, which executes instructions in the embedded JAVA script 82, serves as part of the HTM document processing software L, for transmitting and receiving HTML documents and TCP / IP messages over the IP port indicated at 78. In other embodiments, other browsers and / or HTML document processing software may be used.

Computer 34 also has software running on it having a device control application 84. The device control application part 84 contains executable instructions related to the operation of the devices 36. In an example embodiment, the device control application part includes a plurality of JAVA applets. In the described embodiment, the applets are also preferably programs for managing and monitoring the status of the devices with which they are associated. Some applets are also preferably designed to configure the browser for messaging. Some applets control security and authenticate objects that use AKM.

In the described form of the invention, JAVA applets are associated with blocks that implement functions such as enabling the operation of the card reader mechanism, notifying the browser that the data from the user card has been entered, using the printer mechanism to print checks, using the journal mechanism (for logging transactions) printer, allowing the client keyboard to work and receiving data entered through the keyboard, using a cash dispenser, using a depository, "navigating" to the document addresses Mentoring, providing the function of a synchronization device, verifying digital signatures, managing message encryption, managing the consolidation of accounts issued from a variety of cash withdrawal mechanisms, calculating foreign currency amounts and ensuring completion of the transaction and instructing the browser to return to the exchange with the "home" server. Of course, in other embodiments, other applets may be used to control devices and data used to perform various required functions with the machine. The application control part 84 of the device is exchanged in the computer 34 via the IP port indicated at 86.

In the described embodiment of the invention, the application control software application part 84 does not transmit its messages directly to the program interface part 64 for communicating with the devices. As explained below, this is one approach to provide an increased degree of protection. However, it should be understood that embodiments of the invention may provide that the device control application part 84 can directly exchange device operation messages with the device control program 70. This can be done either through the internal use of TCP / IP, by routing messages in the usual way through a queue installed in the operating system of a computer associated with software that communicates with software that serves as an interface with devices, or by directly requesting it software.

It can also be seen from the foregoing description that some applets in the device control application 84 may correspond to devices that are not present in all automatic cash registers. For example, an automatic cash register that operates only as a cash dispenser does not include a depository mechanism similar to depository 44. To adapt to a situation where a user requests a transaction that is physically impossible for AKM 12, part 64 of the communication software interface with the device can be programmed to issue an appropriate response message to indicate the inaccessibility of functions.

Alternatively, a portion of the software interface for communicating with the device may include a function that checks for the presence or absence of each type of physical device within the AKM. Information indicating that the device is presented in the AKM may be included as part of the messages generated by the AKM. For example, information indicating devices that operate on the AKM may be included as part or more of the URLs to which messages are sent through the AKM. Thus, the URL in the server to which the AKM connects can be configured to provide only documents that correspond to the types of transactions that the AKM is capable of performing. As a result, the browser does not display documents that include links to transaction types that the machine is unable to execute. Thus, for example, a machine may not issue an image in response to a document that includes a link to a deposit transaction if the machine does not include a depository.

Alternatively, the machine may include data in a storage device representing functional devices included in the machine. They may include, for example, data representing a plurality of devices in a machine, and configurations of such devices, or, alternatively, a pointer, such as a machine number, sufficient to identify the capabilities of the machine. These devices indicating the functional devices in the machine are transmitted to the server, and the server functions to transmit relevant documents for the devices present in the machine. This can be done on the basis of the data corresponding to the data of the device from the machine, or it may be decided to provide them from a storage device that stores data representing functional devices in the machine associated with a particular pointer. Documents selectively sent by the server to the browser of the machine will include appropriate links to the functional devices presented in the machine. In alternative embodiments, messages from the machine may indicate the type of transaction requested or other information that corresponds to the devices or operational capabilities available in the particular machine in which the transaction is requested by the client. Available documents can be static documents or can be generated at runtime from subdocuments or other data to provide appropriate output and commands to the output devices of the transaction machine.

Figure 3 depicts an AKM 12 connected through an intranet 16 to a computer system 14 "home" bank. Computer system 14 includes a proxy server 88. System 14 further includes an HTTP home server 90. Computer system 14 further includes a device server 92. The proxy server, the home HTTP server and the device server may be included in one computer, as shown, or in other embodiments, may be separate computers. In other embodiments, additional servers may operate.

The "home" HTTP server 90 is preferably associated with the stored data and is in electronic communication with the computer system of the back office, indicated at 94. The computer system 94 of the back office monitors the debiting or crediting of client accounts when they conduct transactions in automated banking machines. In addition, the subsidiary office 94 also preferably monitors transactions in order to make settlements with other institutions that are participants in the system and whose customers conduct transactions in AKM 12.

As described below, the proxy server 88 in the described embodiment is also connected through a wide area network 18 to other servers, such as a server 96 of another ("foreign") institution. The server 96 of another institution is an example of a server used by an institution or organization other than the institution that uses computer system 14. It should be understood that while the server 96 of another institution is indicated as used by a “foreign” institution, this does not necessarily indicate that the institution is located in a different country than that of the institution using the computer system 14. However, it is possible that the server 96 of another institution may be located in a similar other This includes the country in which the language of communication is different from the language that is commonly used in the country where AKM 12 is located.

Conducting transactions using AKM 12 is described with reference to figures 3-24. It should be understood that the following transactions are merely examples of operation of a device and a system, and the device and system can be configured and used in a variety of ways to execute transactions.

At the beginning of the transaction example, as shown schematically in FIG. 3, the browser 76 communicates via the intranet 16 with the proxy server 88. The communication is preferably established in such a way that HTML documents intended to attract customers to the AKM 12 are processed and displayed for display on the touch screen 30. This is called the “attraction mode”. These HTML documents that are processed in the browser to obtain output in the form of screen images for display on the touch screen 30 (and / or output through other output devices included in the machine) can be issued from the "home" HTTP server 90, which functions to transfer HTML documents to a proxy server. The home HTTP server sends messages addressed to the IP port associated with browser 76 to cause them to be displayed on the appropriate AKM machine. It should be understood that while this example describes a “home” server 90 communicating with the AKM via the proxy server 88, the server 90 in other systems covered by the invention can communicate directly with the AKM.

The main advantage of this system is that the "home" HTTP server 90 can send documents selectively to the AKM 12 associated with the intranet 16. These documents can include messages or material "tied" to the specific location where the AKM 12 is located Examples of specific “tied” on-screen images may include bilingual messages in some locations or information regarding currency exchange at various ports of call. Material or messages may include advertising various goods or services or other materials that are specifically targeted to specific machine locations. JAVA applets and a JAVA script are downloaded from a central location that allows software to be distributed selectively to many AKMs, which can also be used to adapt AKMs to their environment, forcing them to access documents that include material that may be useful at that location and which is not provided in documents sent to at least some other machines in the system.

The systems of the present invention can be configured to have HTML documents selected at various addresses so that specific documents accessed include material intended for users of a particular machine. Alternatively, the machine may transmit machine data to the server indicating its identity and / or location. Based on the machine data and the data stored in the data storage device on the connected server, the server can send documents including targeted material. This can be done by combining subdocuments, or otherwise, generating documents that should be sent to the browser of a particular machine. In addition, it should be clear that while in the shown embodiment, HTML documents are accessed through the server of the institution associated with the machine, the documents used for the attract mode can be accessed from other servers used by other organizations.

The touch screen 30 in this example transaction sequence displays a screen image that includes a graphic symbol (icon) that indicates one or more languages, that in order to start a transaction, the user must touch the screen. If the user touches the screen in the graphic symbol area, an input signal is generated. An input signal or an HTTP message is transmitted through the browser 76 to the "home" address of the "home" HTTP server 90 with which AKM 12 is currently connected. The message transmitted back to the home HTTP server is shown in FIG. 3 by arrows directed from the browser 76 to the intranet 16, from the intranet 16 to the proxy server 88, and from the proxy server to the HTTP server 90.

In response to the receipt by the home server 90 of an HTTP message indicating that the client has touched the graphic character on the screen, the home server senses the address it is accessing to send the message through the proxy server 88 (or, in other embodiments, directly ) to the browser 76. This message preferably includes an HTML document which, after being processed by the browser, forms an image on the screen instructing the client to insert his card into the card reader 38. The HTML document flow, which is presented graphically in FIG. 4, preferably also includes an embedded JAVA script or other commands that work in a JAVA environment to send a message to the JAVA applet responsible for ensuring the operation of the card reader in the application part 84 device control. In one example embodiment, the instructions give a pointer or tag to an applet that executes commands in response to receiving a document. Of course, in other embodiments, other software and approaches may be used.

As shown schematically in FIG. 5, in response to an embedded JAVA script that activates a JAVA applet associated with issuing a permit for the operation of a card reader, the JAVA applet in the device management application 84 communicates with the device server 92. The device server 92 includes a device server program 98, which in the example embodiment is a JAVA program that enables exchange with JAVA applets and the device server application 100. The device server 92 preferably also includes a monitor application 102 that is designed to control device operation commands. Monitor software minimizes the risk of fraud or abuse through the method explained below.

Returning to the typical transaction shown in FIG. 5, in response to receiving a card reader permission message from the device management application 84, the device server 92 generates a message transmitted via the intranet 16 to the program interface part 64 for communication with the device in AKM 12. This message, which contains an HTTP record that includes instructions for the operation of the card reader, is sent to the IP port, indicated by 74, through which st 64 software interface for communication with the device. In response to receiving this message, the program part 64 performs the action of transmitting the message or messages on the control bus 50, which allows the mechanism 34 of the card reader to function.

Continuing the transaction example, as shown in FIG. 6, inserting the card with the client into the card reader 34 causes the card data to be read and a part of the program interface 64 is sent to communicate with the device to the device server 92, indicating that the data from the card has been read. This message is transmitted by the device server via the intranet 16 to the device management application 84. The device management application part then sends a message to the device server requesting card data. The server 92 of the devices transmits a message with commands to send data from the card from part 64 of the program interface for communication with the device, which responds by means of a message with the sent card data via the intranet to the device server. The device server, if there is no reason to stop the transaction, sends the HTTP record, which includes the card data, back through the intranet 16 to the device management application 84.

In one example embodiment, a card inserted by a user or client includes indication information that corresponds to an address associated with a user on the network. In such an embodiment, the indication information corresponds to the address of a unified index of an information resource ("URL"), which provides information about the computer where the user information resides, as well as a directory or subdirectory including user information, and the name of a document or resource that includes user information. The URL can be encoded on the customer’s card. The address can be encoded on track 3 of the magnetic strip, at other locations within the magnetic strip data, or by encoding other readable information on the card. Alternatively, if the customer card is an intelligent card (“smart card”) that includes a semiconductor storage device located on it, the URL address associated with the client may be included as part of the stored data on the integrated circuit on the client card.

Alternatively, the URL may be obtained from other data on the card by accessing a database in which the address information is interconnected with other data read from the card. For example, traditional magnetic stripe encoded cards include, as part of the encoded account, information identifying instruction information that indicates the institution or facility with which the customer account is associated. For example, when using debit cards, these cards include a “Bank Identification Number” (BIN). Examples of embodiments of the invention may include, while maintaining an operational connection to a computer, a data storage device that includes data corresponding to a BIN number or other object data identifying associated network address data. The machine may allow the use of a network address for the customer’s “home” institution in response to identification data. The machine can use the allowed address information from the data on the card, access the server used by the object with which the user has a connection associated with the account. As explained to the user later, this feature can be used to provide the client with HTML documents or other documents of the type that provide the interface display and transaction flows from their familiar “home” institution or facility, even though the machine they are using is not controlled by this object.

As can be seen from the following description, an object having a banking machine can be completely independent of the object with which customers make payments. Nevertheless, the client is provided with interface output that reports that the machine is such a machine that is used "by its" particular bank or object with which it has interconnections related to settlements. The customer may be invoiced for a transaction fee for the convenience of using a bank machine. In exemplary embodiments, at least a portion of this payment will be shared between the customer’s institution and the facility using the banking machine that provides this opportunity.

The data necessary to obtain an address for accessing documents related to the client can also be obtained from entered data from readers or other data input devices other than or used in addition to card data, including, for example, biometric data entered by the client through a biometric reader. Such biometric data may include, for example, data corresponding to one or more fingerprints, data from a user’s image, for example, a face or iris, user voice input, including recorded voice or spoken passwords, or combinations thereof.

For example, and without limitation, data entered by a client, for example, by inserting a card into a card reader, may correspond or otherwise be used to determine an address for accessing an HTTP record, which may be a file or document that includes information that may include used to authenticate the user. This record may include data corresponding to a PIN number (personal identification number, PIN). The information may include biometric data corresponding to an authorized card user. The browser can access the record and use the contents of the record, such as data and / or commands, to verify that the indication information corresponding to the biometric data in the record matches the biometric data of the user entering the card. Alternatively, input data representing appearance, voice, other features (or combinations thereof) or other input data may be used to form one or more addresses that correspond to the user, and the contents of the entry in the address being accessed are used to verify that the user of the machine corresponds to the user associated with the record. Numerous approaches within the scope of the invention may be used. The information in the record corresponding to the user can be used in the same way to provide authority to some functional devices of the machine to serve the user, while other powers do not provide such authority. For example, a user who exceeds the credit limit may have information in the record that is being accessed that interferes with the operation of the cash dispenser, while users who do not exceed the credit limit may have information (in the record) which allows such an operation. Alternatively, the lack of information in the corresponding record may allow operations, while the inclusion of information selectively limits the operation of the devices.

Alternatively or in addition, in embodiments of the invention, information that is used to determine the identity of the client and / or his accounts may be suitable for use by a computer connected to the machine to generate documents, such as XML documents. Such documents can be used to generate output from the machine provided to the client. Such documents may alternatively or additionally include information corresponding to one or more network addresses. Such network addresses can be used to access documents relevant to a particular client or his transaction.

Returning to the transaction example, the data from the card from the successfully read card is sent in response to program actions from the device control application 84 to the JAVA applet associated with the notification that the card data has been entered. In response, the JAVA applet generates a JAVA script that configures the browser with a URL address corresponding to the data read from the card. The JAVA applet also preferably opens a record, schematically indicated 104, for a transaction that includes a user network address, time, and other data from the card. This entry in the example embodiment can be stored in the storage device as data in the form of an object in software. This object is preferably used to accumulate data when a transaction takes place. The data stored in the transaction data object preferably includes data inputted by the user input device, as well as data representing actions performed by the transaction-enabling devices.

A transaction data record or object provides consistency through the fact that there may be several different steps of a transaction being performed by a client. The ability to use and share data in many different actions eliminates the need to form them or receive them from the client more than once during a user session, which includes many stages of transactions. Using the transaction data object enables applets to work largely independently, obtaining the necessary data from the transaction object (data). The transaction data object may be processed or accessed from various documents. Its content can also be processed and used to fill out forms presented in HTML documents. A record or data object may also be used to make a corresponding record at the end of a transaction session. This record can be saved, combined into a data packet or sent to selected addresses in a local or global network.

In alternative forms of the invention, a customer card or other product presented by a customer to a banking machine may include additional personal data regarding the customer. Such personal data may include demographic and / or preferably marketing data related to the customer. This personal data may also be read by a card reader and stored in a transaction data object or other suitable storage. Such data can be used by the system to carry out targeted marketing presentations and / or provide other information specifically for a particular client. The inclusion of personal data in the client’s card enables the client to exercise more control over his personal data than that which is available to the machine and third parties who make marketing presentations to the client. This approach can be used as an alternative or as an addition to systems using a central archive of personal information about the client. An approach that allows the client to control what information about him is made available to others may be more acceptable to customers in terms of confidentiality.

As shown schematically in FIG. 7, in a transaction example, in response to the browser 76 receiving the network address data, the browser sends the message through the intranet 16 to the proxy server 88. For the purpose of illustrating this example, the network address associated with the data on the card is the client address associated with a home bank that uses system 14. As a result, the client’s address will force a message from the proxy server 88 to the HTTP home server 90 and contact the address corresponding to it. Alternatively, in other systems, a connection can be made directly to the server 90 without affecting the proxy server 88. As described above, the network address may also include portions indicating data representing devices that operate on the AKM.

In the example of the transaction, in response to the receipt of the message, the "home" HTTP server 90 finds the data corresponding to the client's address data (or other data) in its associated storage device and transmits one or more HTML documents to the browser via its IP port. These HTML documents may include an image identifying a particular customer by name, as well as the name of a banking institution or other facility that uses the home banking computer system 14.

In addition, the HTML document preferably includes an embedded JAVA script that has a digital signature or means for obtaining a digital signature associated with the "home" HTTP server 90. The script command included in the document, in some embodiments, causes a portion of the application device to access the HTTP address on the server, which is server 90 in the described embodiment. The HTTP address corresponds to an HTTP record that includes at least one command and preferably includes a program such as a JAVA applet or Active-X file. The command is used to operate the corresponding device that ensures the functioning of the transaction. The HTTP record preferably includes data representing a signature, such as a digital signature. This digital signature is received in response to the JAVA script 82 and is processed in the device control application 84. The JAVA applet processes the digital signature to confirm its authenticity, and if the signature can be acceptable, it allows the banking machine to work. In some embodiments, the applet may compare the signature with the signature data stored in the memory for predetermined relationships, such as a match. Of course, other approaches to verifying the credentials of servers, documents or commands for the operation of machines or specific devices in them can be used in embodiments of the invention.

After the applet has verified that the correct digital signature or other authorization data has been sent from the HTTP server 90 or other related HTTP record that has been accessed, transactions will be allowed to continue. If for some reason the correct digital signature has not been sent, the JAVA applet will stop the transaction and return the banking machine 12 back to the state that existed before the transaction began, connecting the AKM to the address associated with the attraction mode in the “home” server 90. Using signed commands can be used to ensure that various devices that support the operation of transactions only work in response to relevant messages. The use of signed commands may be especially suitable for teams that start a sheet issuing machine or otherwise transfer securities to a machine user.

For example, suppose the resulting digital signature is the “correct” signature, in which case the message is returned from the browser 76 to the “home” server 90, indicating that the transaction may continue. As shown in FIG. 8, in this transaction example, the home HTTP server 90 then functions to transmit at least one HTML document to browser 76. This document includes commands that, after processing, form a visible page or a screen image that instructs the customer to enter his personal identification number, or PIN. This HTML document preferably includes embedded JAVA commands or other commands that work to force the device control application 84 to enable the operation of the keyboard 40 in the AKM, so that the machine can receive a PIN number. Such a message is shown schematically in FIG. 8, in which a JAVA script 82 transmits signals to a JAVA applet responsible for operating a keyboard that is requested permission to use the keyboard. In response, the JAVA applet in the device management application 84 sends a message through the intranet 16 to the device server 92. The server 92 devices sends a message through the intranet to part 64 of the software interface for communication with the device in the AKM. The commands in this message force the device software to enable the operation of the keyboard 40. The JAVA applet responsible for granting the use of the keyboard also preferably serves to update the transaction record 104 to indicate that a PIN code was requested.

As shown in FIG. 9, the PIN code entered via the keypad 40 is transmitted in a message from the program interface part 64 for communication with the device to the device server 92. Device server 92 returns a message to the responsible JAVA applet in the device management application. The JAVA applet then sends the message back through the HTML document processing part and the browser 76 to the HTTP address of the "home" server 90. This message includes data representing the PIN code entered by the client. In some embodiments, it is undesirable to display the client PIN on the screen. In such embodiments, the keyboard applet may function to display a default character, such as the “*” character or another character, instead of the PIN numbers. As further described below, it may be desirable to avoid passing the PIN code or other data through the browser when the PIN data can be processed as a separate HTTP message or in another way to reduce the risk of detection.

The software, working in conjunction with the HTTP server 90, then operates to either verify the PIN directly or verify the client PIN number and account number, sending it to the auxiliary office 94 and waiting for a response. Alternatively, verification of the client PIN can be performed in the AKM using the appropriate applet. This can be implemented in situations where the data on the client’s card, such as the account number or parts thereof, can be interconnected with the client’s PIN code by means of an algorithm. The embedded JAVA script in HTML messages may include or point to an address to receive data and / or commands that the applet can use to perform this validation function, including some encoding key data. These may include user information in an HTML document or other recording data that is accessed in response to data from a user card. The BIN number read from the customer’s card can alternatively be used as an indicator for implementing the approach that should be used when checking PIN data. As shown schematically in FIG. 9, the transaction data object 104 is also a suitably modified applet to indicate a client PIN entry.

In alternative embodiments, a machine may include a biometric device reader or other data input device, such as a reader, for receiving data from a user. The user can enter data through such a device, which can be used instead of, or in addition to, the PIN code data to verify that the user is an authorized user. This can be done, for example, by comparing the data entered by the user with the information corresponding to the authorized user of the card included in the record or document that has an HTTP address and accessed by the browser or HTTP client application through the HTTP server in response to the card data. Alternatively, the input information can be used to generate an address for documents or records that are accessed by the browser or client, and the records or documents contain information that is used to verify the identity of the user. For example, user data may be stored in a data warehouse connected to an HTTP server, which forwards data from a record in response to user data, the data being used to verify the identity of the user.

It should be noted that the page or screen image that asks the client to enter their PIN code is shown generated from the "home" server 90 HTTP. They are preferably a screen image that is associated with a specific URL associated with the client. This should be the client’s home bank interface and should be familiar to the client. Alternatively, the client’s address may indicate what may be essentially a client’s personal “home page” with an institution that uses computer system 14. As such, it is not only something that the user is familiar with, but is ideally suited to the specific needs of the user for the transaction.

Alternatively, the document (s) or report (s) that (e) contains (at) the client’s data can (be) used (s) to form the address for other documents. The information may also be used by a computer to dynamically generate a document for a particular client in specific circumstances. This approach can be useful to reduce the effort involved in developing a pre-personalized visual page or document for each client.

Approaches to accomplish such a task may include the inclusion of various types or categories of user information in the document (s) or record (s) that belong to a particular client. These may include information such as gender, related people, types of accounts, permitted transactions, customer preferences, customer interests, account balances, whether previous offers were rejected or accepted, and other information. This client information can be used by the corresponding applet from applets 86 to address and / or generate a corresponding document for the browser to access based on the client’s “profile”. In addition, the profile applet may take into account the transaction devices presented in a particular machine, information about which is stored in a data storage device in a machine or elsewhere in the system, as well as other factors such as day of the week and time of day, based on system clock. Thus, the machine determines the appropriate document for circulation or formation for a particular client in specific circumstances. As described above, some personal data can be obtained from the information encoded on the customer’s card.

The logic used in the profile applet can generate documents or access them for the client, which includes the possibility of transactions based on client information, terminal information and other factors. A profile applet may offer transaction capabilities or sample information based on customer information. For example, a machine operator may offer incentives, bonuses, additional transaction options, or advertising information selectively for customers. Some types of institution customers using the machine may receive screens with output data that encourage them to do more trading or various types of trading with the institution. Similarly, clients who are identified as clients of other institutions can be provided with incentives to do business with an institution using the machine.

A profile applet can force a computer to access other documents on other servers, such as stock market data, and selectively provide them to customers. It should be understood that the profile applet may work to determine an address or generate documents for generating initial screen images of a transaction sequence. A profile applet can also work to provide information or call or generate documents that generate visual output to the client at other points in the transaction or between transactions. It can also be used in systems in which the machine operator is able to sell paid advertising time to third parties, and then refer to HTTP records, such as HTML files, corresponding to files of those third parties' products or services. Such access can be done on a periodic or other basis, but can be done efficiently by selecting an HTTP record to make a request in response to a specific client's profile. As described below, advertising documents can be accessed from ad servers connected to the network. Promotional materials can be sent to customers from the machine at various points in time during transactions, for example between steps managed in accordance with documents, from the server used by the client’s institution. Promotional materials may be displayed when devices are provided that support the operation of transactions, such as a device for issuing sheet documents. The operator of the machine and / or system with which the machine is connected may also require payment from advertisers for the presentation of promotional materials.

Continuing the flow of transactions from the moment shown in Fig. 9, for this example of a transaction carried out by a client of an institution that uses computer network 14, is shown schematically in Fig. 10. The "home" HTTP server 90, in response to the client entering the correct PIN code, sends HTML documents to part of the HTML document processing software on the computer that uses AKM. These messages may include information and commands used to generate screen images that request the client to select a transaction. For the purposes of this example, it is assumed that the customer enters selection data from the touch screen 30 that corresponds to a cash dispense, which is a normal transaction of an automated banking machine.

The selection of the client via the touch screen input device is transmitted back through the HTML document processing part, which transmits an HTTP message to the "home" HTTP server 90. Server 90 then responds by sending another HTML document to the banking machine, which asks the client to select the amount. Again, the customer can enter the selected value on the touch screen, which indicates the amount of cash required by the customer. This HTTP message goes through the HTML document processing part and the browser 76 to the home server 90.

In response to receiving amount information from the client, the home server 90 preferably electronically contacts the back office 94 to verify that the client has the requested amount in his account. This can be done through the Common Gateway Interface (OSG, CGI) 106, which is operatively connected to the "home" server 90. In order to complete this transaction, suppose that the back office 94 indicates that the money is available on the client’s account and sends a message through the OSI 106 to the home server 90, indicating that it may continue.

As shown schematically in FIG. 11, the home server 90 then sends the document back to the HTML document processing part in the AKM software. This message, after being processed by the browser, will preferably cause a screen to display information that notifies the client that the transaction is being processed. In addition, the returned HTML document preferably includes a JAVA script that includes embedded commands executed and exchanged with a JAVA applet associated with the sheet document issuing mechanism 42.

The document returned from the "home" server 90 may include advertising or other information instead of or in addition to the client message. The returned document may also include a command that forces the machine to access or generate another document. These commands can cause the implementation of the methods in the profile applet, which depend on the properties associated with the client, machine, current time and / or other circumstances. This allows you to access documents that provide promotional messages, such as advertising or other information to the client, while the client expects the result of the machine to issue sheet documents or another device for the operation of transactions in the machine. It should be understood that these documents can be accessed from servers located elsewhere and connected to the system, including servers connected to the Internet. This makes it possible to selectively provide customers with a wide range of materials. It also enables AKI and other transaction machine operators to advertise to customers from a wide audience, or targeted to categories of customers, or even targeted to individual customers on a single principle. This can be an advertisement for a machine operator, such as a bank, or an advertisement related to virtually any type of product or service. Advertising may also be selectively presented based on a particular operational transaction device, amount of funds involved, or other parameters. Documents may also allow the presentation of video images and sound to the client, which may increase the effectiveness of the promotion. The appeal to advertising documents can be traced and payments made to the client’s institution, the system operator and / or the owner of the machine, an object related to advertising materials submitted to customers.

In the example embodiment, the message to the JAVA applet in the application part 84 of the device management software used to enable the operation of the machine for issuing money leads to the formation of a message on the server 92 of the devices. The message to the device server 92 to dispense cash is preferably analyzed by the monitor software 102 to determine if the message is appropriate. For example, monitor software 102 preferably ensures that the amount of cash requested does not exceed a predetermined amount. It may also optionally verify that the quantity provided to this customer within a predetermined period does not exceed a certain amount. This can be done by the device server sending a message to the back office, which includes data from the card or other data that has been previously received from or which is allowed to be used for this client. This message may pass through server 90 and its associated OSH, or other connection. Assuming that the issuing command is not prevented according to a message from the back office or monitor software, the device server 92 sends a money issuing message to part 64 of the program interface for communicating with the device in the AKM. The software part 64 in response to the message to use the mechanism 42 of the issuance of money carries out the issuance of cash requested by the client.

The monitor software 102 preferably performs additional functions in the device server. For example, government regulations or good business practice may require limits on the size and amount of deposits that can be made at AKM. It may be desirable to prevent money laundering or other suspicious activities. The monitor software preferably works in such a way as to limit the amount of any individual deposit below a set limit. It can also communicate with the back office system 94 of the home bank to prevent a number of deposits from being made over a predetermined time from exceeding a certain limit. Monitor software can also work in conjunction with a proxy server to restrict some transactions that can be performed on the banking machine in response to commands from other servers, as described below.

It should be noted that in this example embodiment of the invention, the JAVA applet that forwards the message causing the issuance of cash works in conjunction with another applet that controls the consolidation of accounts held by the client. Many automatic cash registers are capable of issuing banknotes of two or more denominations of foreign currency. It is advisable to manage the consolidation of accounts available to the client in order to satisfy his needs, which is available in the machine, and to avoid exhaustion of accounts of one value compared to another. The account pooling applet preferably manages the account pooling in accordance with the requirements of the institution using the AKM machine, as well as in accordance with the capabilities of the AKM machine. Alternatively, a JAVA applet for managing account consolidation may reside in the device management program 70 in part 64 of the program interface for communicating with the device.

As is apparent to those skilled in the art, specific JAVA applets and / or configuration data in the machine can be selectively downloaded from the “home” server 90 at machine startup or at other times. Because applets and configuration data can be selectively provided to specific machines, these machines can be tailored specifically to distribute a specific currency and other AKM capabilities. For example, AKM can be configured so that some applets or groups of applets must be present to enable the machine to work. One approach to downloading such data or programs is to provide address values in the terminal software, to indicate where the necessary commands can be received to receive applets or data. If applets or groups of applets at startup are not already present in the memory of the AKM terminal, the software addresses the system to obtain documents that contain the required records or commands that will force the machine to load the required records. A browser can be used for addressing, and the software downloads the data corresponding to the commands from the documents that have been accessed to the storage device in the AKM terminal so that the terminal has the required applets and data. Such document addresses can be accessed through the home server 90.

Alternatively, the addresses may reside on a separate “enhancement” server associated with intranet 16. Thus, each transaction machine is capable of loading applets and data, which includes the working code necessary to use the operating devices in the machine. Alternatively, documents may be provided through an “enhancement” server or another server that is accessible to the machine through the wide area network. Documents can be submitted to the "enhancement" server to provide the machine with commands on how to acquire working code to perform a variety of functions. Teams can force the machine to acquire the necessary data and code at the addresses available on the machine using HTTP servers by the HTTP client. Data and code can be obtained in response to commands in one or more documents. The machine may also request that the applets loaded in this way be signed applets, including digital signatures or other authentication features to enable operations on some devices in the machines.

Alternatively, embodiments of the invention may receive the necessary applets and data from a remote data storage device. The data storage device preferably includes data and / or programs that enable the machine to work as needed, or store instructions where the machine can receive the necessary instructions and data for operation. Data can be accessed from the database server. The transaction machine addresses the request to the database server. The request includes or is accompanied by indication information from a machine that identifies the machine. This may be information about a particular machine, such as a machine number and / or may include indication information representing the type or capabilities of the functional devices of the machine.

The data storage device preferably includes records that have data or programs to be transmitted to the machine. In response to a request to the server, the server searches for records in the data storage device and, in response, issues one or more messages to the HTTP client in the transaction machine. The message (s) include (s) the configuration data or applets that enable the machine to work as required, or may include commands that indicate how the machine should receive such programs from servers connected to the system.

In the example shown, the configuration server and the data warehouse can operate on the same computer as the home bank server 90. In other embodiments, the database server may reside at a different location on the networks with which the machine is operatively connected.

The advantage of machines and systems that use such features is the flexibility to change the operating mode and client interface of the machine in response to changing conditions. Such a change may include a change in the device to ensure the functioning of the device. Conditions may change so that some transactions are limited or inaccessible. For example, a machine can usually accept deposits, but its depository is full. In this situation, the machine may modify the documents that it addresses to present messages to users through its output devices so that the possibility of a deposit is no longer offered. This can be done using applets and data originally loaded into the machine, which provide for the issuance of commands when such a case occurs. Alternatively, the programming of the machine can be changed by downloading new applets and / or data from the HTTP server, in response to its current state. This can be done in response to a request to the database server, which includes or is accompanied by data representing the changed states or capabilities of the machine. In response, the server sends the applet (s), data and / or commands that should be used by the machine in an altered mode.

This approach eliminates the situation typical of conventional transaction machines, where the static representation of the interface image on the output devices offers the possibility of transactions to the client. Sometimes, after the client has made a choice, an indication is displayed that the selected transaction option is not available. The approach described here can be used in conjunction with numerous transaction options and transaction types. Transaction capabilities can be easily changed from the database server on a machine-by-machine basis, or even on a client-by-client basis, as described above, based on the requirements of an object using a transaction machine.

Discussion of an example of a transaction is continued below from the moment schematically represented in FIG. 11. In response to the issuance of the required amount of cash by the machine 42 for dispensing cash, the program interface 64 for communicating with the device preferably sends a message about the dispensing operation confirming the dispensing operation back to the JAVA applet responsible for issuing the device control application 84. As shown in FIG. 12, a particular applet modifies a transaction record 104 to indicate a cash out to a customer in a specific amount. The embedded JAVA script commands that triggered the cash dispensing operation to the client also preferably include the commands necessary to send a confirmation message back to the "home" server 90 that the dispensation is complete. Receiving a message about the issuing operation indicating that cash was issued forces the JAVA applet to configure the part for processing HTML documents in order to send the device’s response message back to the “home” server. The “home” server then preferably operates in accordance with its software to indicate to the subsidiary office 94 that the client has received a certain amount of issued cash. This amount is deducted from the customer’s account in the records maintained by the back office system.

Usually during a transaction, it is common practice to ask the client if he wants to have a receipt for the transaction. This can be done at various points in time during the flow of transactions. In the present example, after the cash has been dispensed, a message is sent to the client using the machine, as shown in FIG. 13. The "home" server 90 sends an HTML document which, after being processed by the browser, forms a screen image asking the client if he would like to receive a receipt. This message is displayed as part of the page on the touch screen 30 in response to receiving the message through the browser 76. Alternatively, a document may be generated by a machine. In response to the client indicating that he either wants or does not want a receipt, the message is returned to the "home" server. Again, it should be understood that the screen images displayed to the client are preferably those that the client is used to in his or her "home" institution, and may be part of his or her unique home page.

Assuming that the client wishes to receive a transaction receipt, the “home” server 90 in the example embodiment operates as shown in FIG. 14 to send a document with an embedded JAVA script indicating that a transaction receipt should be printed back to the AKM . These commands in the JAVA script are transmitted to the device control application 84, which sends a TCP / IP message via the intranet to the device server 92. The server 92 devices, in turn, transmits a message with commands to part 64 of the software interface for communication with the device in the AKM. In response to the receipt of the message, the software portion 64 causes the printer 46 to print a client transaction receipt. The JAVA applet responsible for providing the printer also preferably modifies the object or transaction data record 104. As described below, the applet that controls the printing of the transaction receipt can receive the data used in the printing of the transaction receipt from the transaction data object.

It should be understood that, even if the client does not wish to have a receipt, it may be desirable to print the transaction record in hard copy using a journal (for logging) printer 48. This can be done in response to inserted commands that are part of the same document , from the "home" server 90, which obliges you to print the transaction receipt for the client, or may be part of a separate document that indicates that the client rejected the possibility of receiving a receipt for the transaction. Alternatively, the journal printer may be powered in response to other applets, such as an applet that allows cash dispensing, or in another manner selected by the AKM operator. Alternatively or in addition, an electronic record of transaction information may be stored in a data storage device. Such information can later be retrieved remotely from the machine, (upon request) from other system addresses. As is apparent from the foregoing description, the operation of the example embodiment of the AKM is inherently flexible and programmable to satisfy the needs of the system operator.

As shown in FIG. 15, upon completion of the printing of the transaction receipt, the program portion 64 preferably sends a device operation message to the device server 92, which indicates that the requested device function has been completed successfully. The server 92 of the devices sends a corresponding message about the operation of the device of the application part 84 of the device control and, in the example of the embodiment, to the specific JAVA applet responsible for printing the receipt of the transaction. The JAVA applet, in turn, configures the part for processing HTML documents to form a message back to the "home" server in the form of a device response message to indicate that a transaction receipt for the client has been printed.

After receiving the cash and the receipt of the client’s transaction, they are then asked to indicate if he wants to conduct another transaction by means of a screen display formed from an HTML document from the “home” server 90. A visual page or screen requesting the client to do this is displayed on the touch screen 30. For the purpose of the example, suppose the client does not want to perform another transaction, and the message is returned via the HTML document processing part back to the "home" server 90.

As shown schematically in FIG. 17, in response to receiving a message that the client is serviced, the home server 90 sends a Home Return message to the AKM. This message preferably includes an HTML document which, after being processed by the browser, forms an image on the screen expressing gratitude to the client. This message also preferably includes an embedded JAVA script that calls the JAVA applet, which ultimately returns the part for processing HTML documents in AKM back to the connection state with the URL on the "home" server 90 or another network address that provides documents used to display messages for the so-called "attraction mode". It must be remembered that the script or commands included in the documents used in some embodiments may cause the message from the document processing part to be forwarded to the address on the "home" server, which causes the corresponding HTTP record to be loaded, including commands containing the required applet .

As shown schematically in FIG. 18, the return home command applet configures the browser 76. After the HTML document processing part is configured by the JAVA applet to return home, the JAVA applet can be configured to direct " home server 90 information from transaction record 104 regarding a transaction that has just been completed. Since an example transaction was carried out with a client of an institution that uses computer system 14, all data regarding this transaction should already be recorded in the back office 94. However, it should be understood that this will not occur if the transaction was carried out in response to messages from the server used by another agency. Also, this may not be the case for some types of transactions, such as some credit card transactions, where authorization is provided during transactions, and in later transactions, details are sent for settlement purposes. Thus, all or part of the information from the transaction record 104 can be sent in response to the “return home” command to the “home” server 90 and through the OSH to the back office system 94, where it can be identified as double information and rejected. This can be done using a remote calling method (the RMI protocol is a remote calling method in JAVA) to transmit or direct an object to server 90 and then transmit data via messages from the server to the back office or via messages or other means.

Of course, in other embodiments, transaction information may be stored in the database for extended periods of time instead of being returned after each transaction. Alternatively, the AKM 12 of the present invention may include applets that send transaction record information to addresses other than the home server address, if required by the system operator 14. The computer can be configured using the appropriate applet or other commands to direct saved transaction record data at selected network addresses in the system. Such recording data may be sent in encrypted form adopted in a particular system. Such recording data may be forwarded through a document processing part of the banking machine. In alternative embodiments, such data may be routed through a separate server component used in a computer connected to an automated banking machine. By accessing this record data, a machine operator or other authorized authority can retrieve transaction data records. Such data can also be used to extract data that is used to determine the number and types of transactions carried out in a machine, involving other institutions and / or charging transaction fees associated with them. Such information may also include information regarding promotional materials provided to customers. Such information can be processed and used as the basis for sharing transaction fees or receiving payment from advertising materials.

The operation of an example computer system when the "other" ("foreign") user uses the AKM 12, is graphically presented with reference to Figs. 19 - 24. A transaction with another user who is not a client of the institution that uses the AKM 12 and the computer system 14, will be managed by the “home” server 90 and will start in the same manner as in the previous example from the point in time when the client inserted his card. The client inserts a card having indication information corresponding to a network address that does not correspond to the "home" server 90. The HTML document processing part configures a message addressed to access at a URL that matches the indication information on the client card or other address in response such information is indicated. For example, a network address may be based on a BIN number encoded on a customer card. The BIN number can be interconnected with an entry in the table of a financial institution (TFU) or a similar link to determine the network address data and / or other parameters. This message is sent to the proxy server 88, which in turn transmits the message to the global network 18. From the global network, the message is transmitted to another server corresponding to the client URL. For the purpose of an example, another server corresponds to server 96, which is connected to the Internet.

In an example embodiment, the proxy server 88 includes security software, indicated at 107 in the drawing. Security software preferably checks the addresses to which the AKM sends messages and selectively prevents messages from being sent to specific addresses. It serves as a "firewall" and is desirable in order to prevent fraud in the system.

As shown in FIG. 20, another (“foreign”) server 96 preferably serves to send HTTP messages, including HTML documents, to the AKM 12 back over the global network 18. This can be done using the technology of a protective sonnet connection (SSS) , SSC) so as to minimize the risk of message interception. Of course, other methods may also be used, including message encryption methods to minimize the risk of message interception.

As shown schematically in FIG. 20, a response document from another server 96 preferably includes an embedded JAVA script representing or corresponding to a digital signature that identifies another server 96. This can be accomplished by downloading an HTTP record including a signed applet, as described above. The applet in application part 84 of the AKM preferably verifies the digital signature in the manner described in the previous example, and sends a message indicating that the transaction is authorized (authorized). The digital identity of another institution will be stored in the storage device in the AKM, for example, in the data of the transaction record, and ultimately registered in the auxiliary office 94.

It should be noted that HTML documents from another server 96 include commands so that after processing by the browser, visual pages or screen images of another institution that the other client is used to seeing are displayed. These pages may correspond to another user's "home page" that are specifically tailored to the needs of a particular user.

21 schematically depicts an example of a document that is accessed through another ("foreign") server 96 and sent to AKM 12. A document from another server may include an embedded JAVA script that enables JAVA applets to be executed in the manner described above for the use of device 36 in AKM. As shown in FIG. 21, TCP / IP messages to devices from JAVA applets are transmitted from the device control application 84 to the device server 92, and commands from there are transmitted to the program interface part 64 for communication with the device in the AKM. Messages about the operation of the device are transmitted in the opposite direction. When these messages are transmitted through the device server 92, the monitor software 102 monitors them to minimize the risk of fraud or abuse.

As shown in FIG. 21, documents from another (“foreign”) server 96 may output, via the touch screen 30, a request for the client to enter his PIN code. The commands of the embedded JAVA script, as in the typical transaction described above, may include commands that enable the keyboard 40 to accept the client PIN. As in the previous example, a transaction record 104, which includes an object of shared data about this transaction, can be opened by the application software part of the device. As described above, if necessary, conditions can be defined to prevent the transfer of PIN code data through the browser.

Fig. 22 indicates the return of a device operation message and PIN code data to a JAVA applet, which in turn transmits data back to another server 96 via wide area network 18 using a secure socket connection. From this moment, transaction processing continues in the usual way, as described above, except that the other server 96 sends HTTP records that include HTML documents and receives messages from the AKM part for processing documents. Another server 96 includes JAVA application software needed to include the embedded JAVA script in documents that are sent to the AKM to use devices 36 in the machine.

Since the other ("foreign") server 96 uses the machine, the monitor software 102 in the device server 92 monitors the messages in the manner described above. Such control may, for example, prevent the dispensing of an excessively large amount of money from the machine. Supervisory software may also limit some other institutions to only a subset of the machine’s devices for transactions or opportunities. This is carried out on the basis of data stored in a storage device that sets restrictions on the use of devices or actions that can be performed on the basis of documents at certain addresses. This can be achieved, for example, by using additional codes that implement the class of transaction objects that restrict the actions performed. For example, actions that allow connection to another server may process objects that provide the specified limited capabilities for messages received from another server. They can, for example, limit the amount of money given out, prevent the check receiving device from working, restrict the issuance of printed documents such as tickets, prevent the cash dispenser from working, or limit the use of the machine in other appropriate ways. This can be done based on the addresses or parts of addresses for documents.

If the capabilities of the machine provided to another ("foreign") client are limited, the other client may be provided with a visual interface from another bank based on transactions that the machine can execute and which the owner of the machine will allow. As a result, documents accessed in the server of another bank may differ from those that would be provided to the client in the machine used by another bank. This can be done on the basis of documents specially designed for the operation of other machines, or it can be a variant of the usual interface of another bank with visual signs that some transactions are not available. In some cases, the interface may indicate that some transactions are available for an appropriate service charge.

The AKM of the described embodiment can tighten security by limiting the addresses to which the browser can access. This can be done by maintaining the list in the storage device of the machine. This list may be maintained in the HTTP record (s) (including documents) accessible through the intranet of the home bank. The machine can access the recording periodically and modify the data of the storage device. This record may itself require a digital signature corresponding to the signature in the terminal storage device before the data is loaded into the terminal storage device. This information may also include commands and information for the AKM to verify that the messages it receives by accessing documents on another ("foreign") server are genuine. It may include digital signatures that, when transmitted using a public key or encryption methods with a private encryption key, verify whether the messages are genuine. The machine checks to make sure that the signature in the records that are being accessed from another server matches the digital signature for this address stored in the storage device, and allows transaction devices, such as a cash dispenser, only when such a match is present. Of course, in various embodiments, different approaches to verifying and encrypting messages can be used. The signatures or signed records used herein encompass any indication information that is included or retrieved from a record that indicates that it is authorized.

As can be seen from the previous disclosure of the invention, another server 96 can communicate with the user by displaying information through a touch screen in a language that differs from the institution commonly used by clients using computer system 14. As a result, HTML documents may display requests for issuing a currency of this type or in an amount not included in the AKM. To adapt to this situation, the applet may be included in the device control application 84 to deal with requests for a different currency. An applet associated with a request for a different currency causes AKM to send a message back to its "home" server in order to calculate the closest value that AKM can provide to the client in an available currency, corresponding to how much the client requested. As you can see, this applet calls the address of a specific functional device in the "home" server 90, which is able to provide this function. When dispensing is completed, the applet also tells server 96 that the dispensed quantity is slightly different from the amount requested by the client. Of course, in other embodiments, other approaches may be used. Alternatively, an applet in the machine may generate visual images that indicate equivalents in local currency when a quantity of foreign currency is displayed or processed. An embodiment may include a representation of both sums in a visual image presented to a user. Alternatively, additional browsers operating in a bank machine, as described below, may generate visual images that provide the user with information, such as exchange rates, or other information suitable for a client transaction.

As shown in FIG. 23, when another client completed his transaction, which is indicated by the touch screen 30, another server 96 serves to send a “home” message back to the AKM. This message is received in the manner described above to force the device control application 84 to respond to embedded JAVA script commands in order to configure the HTML document processing part to force the browser 76 to reconnect to the home server 90, or The other designated address of the document.

As shown in FIG. 24, the applet in the application control part 84 of the device that processes the “return home” message is preferably reconnected to the “home” server 90, and also sends the transaction record information to the record 104. This transaction record information, which, in the example of an embodiment, is packaged in a data object, includes the name of the client, the name of another ("foreign") institution, a digital identifier, information on the amount of the amount being issued, transferred or deposited, and all other relevant current transaction information. Transaction information is used by applets to complete transaction steps that require any piece of data. Upon completion of the client’s actions in the machine, the applet provides a transaction data message that includes at least a portion of the data collected. This data is transmitted from the server 90 through the OSH 106 to the auxiliary office 94 of the "home" bank. This information is stored in a back office for later use for settlement with another ("foreign") bank using another server 96. Alternatively or in addition, transaction information can be recorded in a terminal in a storage device such as an electronic journal, as well as in hard copy on a magazine printer. Transaction information can be stored for loading in a data packet or by transmitting to objects including data from many transactions. Objects can be thrown by processing from a remote server, for example, by a remote invocation method. The packet data may be transmitted from time to time and to addresses that may be stored in a storage device in terminal configuration data.

An advantage of embodiments of the invention is that transaction information can be routed to addresses on a local area network or on a global network such as the Internet. This facilitates a wide variety of transactions and makes it possible to send messages related to usage tracking (for example, for smart cards such as an electronic wallet) or for settlements of various types of transactions to a selected system address.

As can be seen, the described embodiment of the automated banking machine and system according to the present invention provides the advantage that if the machine is connected to a global network such as the Internet, customers will be able to execute their banking transactions virtually anywhere in the world. Further, despite the wide capabilities of the system, due to the fact that the machine can be controlled locally and in terms of connection and activity, the risk of fraud is minimized.

Embodiments of the invention may include an additional feature to facilitate access to documents on the network with which the machine is associated. This feature allows you to determine if an HTTP record, such as an HTML document or other element, is available at the download address before the computer tries to access the record. This avoids the time spent on transactions that could otherwise occur as a result of the inability to access the record due to the server through which the record is usually accessed. Other embodiments may consider both the recording size and the transmission rate and decide that the transmission rate for a given recording is not large enough for an alternative recording to be transmitted.

In one embodiment, this feature is achieved by using a separate program or applet that finds out if the server is working, which the computer will subsequently access. The applet receives in response the address or part of it with which the connection will be made. The applet makes a socket connection with the address and downloads a small but sufficient number of records, or functions differently to decide that the server through which the record must be accessed is active. In response to the results of the operation of an applet that checks the operation of a remote server, or another way of determining that conditions indicate that records can be accessed or downloaded, the computer enables the browser or similar software component to “navigate” to the address at the appropriate time in the transaction sequence . If the applet is not able to detect that the remote server is operational, or determines the non-obviousness that the record can be successfully accessed or downloaded, steps can be taken to access alternative addresses to generate other output data, or to terminate the transaction. Alternative access addresses can be based on data stored in a terminal storage device, or can be obtained by accessing documents either locally or remotely, which include data from which alternative addresses can be obtained or generated. Alternative addresses are likewise checked to conclude that records can be accessed before attempts are made to access alternative records. This approach avoids transaction delays.

Alternative embodiments may take other approaches to determine whether the required HTTP records, such as HTML documents, can be successfully accessed and / or adequately downloaded before the browser providing the client with the interface tries to access the document. Such embodiments may consider the transmission rate or other conditions regarding the operation of the system or the contents of the document in order to determine whether the document can be successfully accessed. For example, an applet that checks whether an HTTP record or another applet can be accessed can determine the transfer rate at which the record can be transferred to a computer. The baud rate at which data can be transmitted can be compared with the data stored in the storage device, and if the baud rate is less than the data value representing the stored desired baud rate, an alternative recording is accessed. This could be, for example, an HTML document saved or generated locally in a machine. Other embodiments may include programs that consider the HTTP record size and transmission rates when determining the transmission rate. Such programs then determine whether the record can be transferred fast enough to satisfy the parameters set in the configuration in the storage device, and if not, refer to alternative addresses. Such alternative records can likewise be checked for transmission speed before transmission directly.

Programs may also consider other factors when deciding to go to a specific address, such factors may include, for example, information about the day and time, or information from sensors, such as sensors on the floor, or from a video surveillance system that indicates what other people expect use of the machine. Thus, access to documents that have great output capabilities and which may tend to extend the duration of a transaction can be avoided even when records can be loaded at an adequate speed.

In alternative embodiments of the invention, multiple browsers in the (ax) AKM computer may be used to process instructions in documents. Some browsers can process commands and cannot provide output of data that can be perceived by users of the machine. Such browsers can be used to issue commands used to operate devices that support transactions. For example, a browser that does not generate data that may be visible on the display can process documents that generate output data that forces the printer to issue printed documents.

Other embodiments may use a variety of browsers that provide output that may be perceived by customers using the machine. For example, many browsers, each of which is capable of providing visual (and / or audio) data, can be used in the corresponding servers in the machine at the same time to process documents and to provide simultaneous output to the user. Such browsers can also process commands for running devices that support transactions. This may provide the machine with the ability to conduct simultaneous types of transactions.

In an example embodiment, AKM has five (5) operational visible browsers. Each of these browsers is capable of providing visual output to the AKM screen. 32 depicts an example of a screen image 196 in which each of the browsers generates visual output. The output 198 of the main browser is shown centered on the screen. The output data 198 of the main browser on top of adjacent output data 200 of the upper browser 200 and the output data 202 of the lower browser. The output of the main browser is horizontally adjacent to the left of the output of the browser 204 and to the right of the output of the browser 206. Each of these browsers is capable of processing documents and exchanging to network addresses in the manner described above. Some or all browsers may also send commands to control transactional devices in a machine. Alternatively, some browsers can be used primarily to provide output to the client, and cannot be configured to use commands in the documents being accessed in order to use some devices in the machine.

In the example embodiment, all five (5) browsers are used, although they may not all provide visual output. Initially, only the output of the main browser 198 is made visible. Other browsers are made visible using the “presentation” method, which identifies the size of the browser output. This is done in response to display and size commands included in documents, such as HTML documents. Such commands are preferably included in documents accessed by the main browser, but may be in documents accessed by other browsers. In an example embodiment, the size of the browser is determined by a separate measure of thickness. In the case of the “upper” and “lower” browsers, the thickness refers to the vertical measurement from the adjacent upper or lower edge of the image, respectively. In the case of “left” and “right” browsers, the thickness is the horizontal thickness from the corresponding adjacent edge of the image. In an example embodiment, the output of the main browser is repositioned automatically to fill the remaining visible space on the screen that is not occupied by the output of other browsers. In this embodiment, the upper and lower browsers, when activated, occupy the entire width of the screen, while the left and right browsers occupy the space between the upper and lower browser output, if visible. In alternative embodiments, other approaches may be used.

The use of multiple visible browsers provides the ability to output multiple simultaneous visual output based on various documents available at various network addresses. It also allows for improved application tasks that provide sequences of documents that allow the creation of output data generated from documents that are visible at various selected points in time in a transaction sequence. Such opportunities can be especially useful when presenting advertising or related materials to clients during a transaction. Such features may also be useful for displaying messages in a variety of languages for machine operation. Such opportunities may also be useful when presenting exchange rate information in transactions involving a cardholder from another country or when conducting currency exchange transactions. The output from multiple browsers could also be useful in displaying to the client documents generated for the client, or documents that include information to the client on a specific issue, such as the current status of specific stocks or investment opportunities.

33-35 depict examples of screen images generated in an example embodiment when some various browsers are used to generate visual output on a screen. 33 depicts a screen 208 in which the output of the left browser 204 and the output of the upper browser 200 are visible along with the output of the main browser. FIG. 34 shows a screen 210 in which the output of the upper browser 200 and the output of the lower browser 202 are visible with the output of the main browser 198. Fig. 35 depicts a screen 212, on which the output of the right browser 206 and the output of the main browser 198 are visible. It should be understood that many varieties of screen images are possible, and that such screen images may include configurations in which the output of the main browser is not visible.

As you can see, the work of many browsers in the machine allows the execution of simultaneous transactions. For example, a user can be provided with the opportunity to purchase goods or receive services through documents processed by one of the browsers, while a bank transaction is being processed. Such a browser can work, being in conjunction with other components or a machine, as described above, allow operation and receive input data through various devices that ensure the functioning of transactions. Such input may include accepting input or rejecting offers to buy goods or services. A transaction data object can also be invoked by applications using other browsers to make such offers. This allows you to send account information related to the user, which were previously received in connection with the implementation of a banking transaction. It also enables the client to conveniently choose a payment method using the account currently involved in the transaction. Each browser can also create its own transaction or record data object for use with the purpose of performing mutual settlements, as well as for storing data on what happened during the transaction.

While an example of an embodiment of the invention has been described for the case of using multiple browsers to display information during a banking transaction and allowing multiple transactions to be performed simultaneously, it should be understood that the use of multiple browsers providing visible and invisible output can be used for multiple and various purposes that are within the scope of the present invention.

While the described embodiment of an automated banking machine and system according to the present invention is illustrated with reference to a specific type of such machine, which is specifically designed to provide connectivity to local or global networks, conventional automated banking machines can also be adapted to include such opportunities. More specifically, the document processing part and the device control application part can be included in conjunction with other conventional software that runs on one or more computers while in operational connection with an automated banking machine. This makes it possible for such AKMs to work either on a regular local network or as part of a global network. In addition, automated banking machines can be configured to use their devices using a part of the software interface for communicating with the device according to the invention or through another software interface when operating in a conventional network. Such machines can be switched to request messages about devices that need to be passed through the device server when working under the control of the server within the global network in order to maintain security within the system. Thus, a single AKM can operate in private networks in the same way as current AKMs, as well as in the network configuration of the system according to the invention.

Alternative embodiments of the invention are used to exchange transaction messages used in a private AKM network. This can be accomplished using an interface, such as an OSH, in conjunction with either the AKM document processing part or the "home" HTTP server or another server. OSI is operatively connected to a message conversion program and a database in order to select the necessary data from documents and response messages and generate specific transaction request messages corresponding to a private transaction network. Similarly, the message conversion program and OSI work in such a way as to receive command messages from the local network and convert them and generate the appropriate documents and / or TCP / IP messages for use by the AKM. Since these formats of the local network are defined, and the data necessary for generating and interpreting messages are known, the use of AKM 12 directly in a regular private network of AKM is achieved.

Regular AKM transaction messages are messages of a specific format that do not include documents such as markup language documents or HTTP messages. An example of known common messages used for AKM operation are Diebold messages. 91X, NCR PAS messages, and IBM 473X messages. Such messages usually include the transmission of request messages from the AKM in a specific format, which includes input data about the client (account / PIN) and an indication of the type and requested transaction. The request message is received using the host computer AKM, which sends back a response message in a specific format, which includes a sign whether the transaction is authorized. The AKM then returns another message to the host computer indicating whether the machine is able to complete the transaction. Messages used in such conventional private networks typically occupy a relatively small bandwidth.

When connecting the AKM according to the invention to such a network, a server is provided. The server is in operational communication with a storage device that contains a relational database or other data storage that converts the message and the document creation data. In one configuration, the server is connected to the document processing part via the network or may reside on the AKM computer. The server generates documents that are accessed by the browser and which include the transaction device commands. The server (or the connected server) exchanges regular messages with the host computer. A single server can provide an interface for several AKMs connected to it in a LAN, or alternatively, each AKM can have its own server running on it.

The ability of the AKM 12 to exchange on the local network also allows AKM operations to be performed in the manner in which the interface is configured by the user's home institution in a previously described way, but in which the transactions are authorized by messages sent through the AKM private network. This allows you to protect the use of the local network while providing the client with the benefits of the familiar interface of the "home" bank and / or the interface of the "personal home page".

In such a configuration, AKM transaction support devices can be used in a conventional manner in response to conventional AKM transaction messages, such as Diebold 91X messages, NCR PAS messages, or IBM 473X messages on the local network. Output devices, such as a display (and speakers, if provided), transmit output to the client in response to documents processed by a browser connected to a local or global network. The browser refers to documents to request a client using a transaction operation, but the documents do not include commands that allow devices, such as a cash dispenser, to work with a missing permission from the local network.

In one configuration, a browser can be used by a computer in response to the state of devices in the machine, since devices are used in response to normal AKM messages. In this way, the browser can navigate to selected addresses, including addresses that are associated with the client, based on the input information about the client. However, since documents accepted by the browser independently will not use devices that support transactions, there is less need for security measures when accessing documents. As a result, the customer can still use the machine in response to providing a familiar and unique interface, and marketing information, such as advertising or other material, can be presented in a sequence of transactions using the methods described above.

In other embodiments, machines may perform some device functions based on regular messages, while others may be executed in response to commands in HTML documents or other HTTP messages. For example, HTML documents may provide essential data for use by printers or other output devices. Some embodiments may access documents with commands, but may ignore some and act in response to others. The approach can be chosen by the system operator by configuring the software based on their requirements.

It should be understood that embodiments of the invention may also include generating appropriate documents that are processed by document processing software. Such documents can be dynamically generated in response to information sent using messages from the AKM, which include commands and data indicating information related to the client or transaction. This makes it possible to exchange messages with and from AKM with a much more limited number of network addresses. The dynamic generation of various documents, such as XML documents, can be performed by one or more computers based on data stored in one or more data storage devices. A plurality of documents corresponding to a plurality of objects may be generated from a single server. Such documents can be adapted to the possibilities of transactions or promotional information issued by each such object. Documents may include graphic images, graphic symbols, hints, trademarks and other visual features and / or embedded commands corresponding to invisible output as appropriate for the corresponding object. Thus, documents corresponding to many banks, service providers, advertisers and other objects can be generated by one or more computers and sent through one or more servers as a corresponding response to information in AKM message forms and information stored in one or more storage data devices operatively connected to computers.

An additional advantage of the system configuration of an example embodiment is that it increases the flexibility for AKM messaging. The device management program 68 preferably generates status messages related to the status of the devices 36. These status messages can typically represent status information that occurs in devices. Such messages may indicate that the paper stock for printers or the currency stock is low or depleted. Other messages may indicate that the devices are not functioning properly. Often, these messages indicate that the AKM requires service. All such types of messages are called interchangeably, or error messages, or status messages.

Part 64 of the program interface for communicating with the device in the example embodiment, exchanges through the intranet 16 using TCP / IP messages. While the messages associated with the transaction examples described above are routed to the device server 92, the software part 64 may include a server and be configured to address error and status messages to other addresses on the intranet or the Internet. For example, such error or status messages may be routed to an application that sends messages to a service provider. Further, error messages may be selectively sent based on the nature of the error indicated. For example, error messages indicating the need to replenish currency or stocks of paper can be sent to the intranet address associated with the facility that is responsible for replenishing stocks. Alternatively, error messages that indicate the need for other types of services may be routed to an address associated with an entity that can provide the type of service required.

Alternatively, selective address allocation of error messages on intranet 16 can be performed by appropriately configuring device server 92. In addition, either the software portion 64 or the device server 92 may send error messages from the AKM to an error handling system, such as a computer using the Event Management System ™ software, available from Diebold, Incorporated. This software allows you to determine the nature of the error condition and notify the appropriate personnel of the corrective actions that must be taken. Examples of approaches to error handling systems are described in US Pat. No. 5,984,178, the disclosure of which is incorporated herein by reference.

AKM 12 may further include software to help diagnose problems and provide repair services. As graphically represented in FIG. 2, alternative embodiments of AKM 12 may include an HTTP mini-server 109, which is in communication with part 64 of the program interface for communicating with the device. Server 109 is configured to receive device status messages and, in response, make HTTP records including documents that provide device status data to a diagnostic device 110, such as a handheld computer terminal. Server 109 includes an OSH to implement an interface with the device software so that technicians can access information in records available at HTTP addresses regarding status messages and enter test and corrective commands through diagnostic device 110. HTTP records and / or documents generated by server 109 may preferably include graphic and / or audio commands indicating states such as problematic, as well as data for corrective actions and restoring commands Nia.

In alternative embodiments of the invention, the functions of the HTTP mini-server 109 may permanently belong to the device server 92. It may be especially suitable when the device server functions belong to the computer in the AKM. Regardless of who performs the function, the use of visual and audio components of the output data generated during processing of documents related to maintenance and diagnostic messages facilitates maintenance of the AKM.

Records or documents routed through the HTTP mini-server may include commands that correspond to error states or states. Such records or documents may be accessed locally, as described above, or may be accessed remotely. Technicians using a handheld computer, which includes a browser or other software to access HTTP records, can locally access documents for maintenance, diagnosis, and maintenance. In some situations, the client interface and the browser associated with it can be used to access the HTTP mini-server, or a separate browser, display and data input device on the machine can be used and intended for use with the purpose of performing maintenance operations. Alternatively, error and status messages can be monitored from terminals at any locations that are connected to the network. The HTTP mini server processing error and status messages can also be configured to send e-mail or another message to a selected network address or group of addresses whenever a particular state or group of conditions occurs.

An additional useful aspect of the exemplary embodiment is that HTTP messages can also be sent to the HTTP mini-server to try to fix the problems. Such messages may include commands that cause diagnostic tests to be run and messages to be sent indicating the results. They may also include messages that cause devices to test or try to clear jams (paper) and other malfunctions. This can often be done from remote locations. Of course, when there is a significant risk of unauthorized access to a server that processes error or status messages, appropriate security measures should be taken, for example, of the type described above.

HTTP records that indicate the status of transactional devices can take various forms 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 indication information contained in a data object. A data object may be transferred to other related computers to provide status data. The transfer of a data object can be accomplished, for example, by a remote call method (RMI). The data in the transmitted data object can then be used to generate the message and / or output required by the system operator. This method can be especially useful when the operator wants to connect a machine with an existing control system, and the indication information included in the data object can be used to generate output data or messages indicating the status of the device that can be processed by the existing system. Additional modules can also be used to achieve communication between existing control systems and transaction machines that have different types of condition conditions or different types of message formats. In this case, we consider machines that have various types of devices that support transactions, and features.

Can also be used a method of transmitting a data object to conduct a test or modify devices that support transactions. For example, the indication information in the data object may be changed by the service node and the object transmitted back to the machine. The software in the machine can cause the transaction-enabled devices to activate or change states or software in response to a modified data object. Such cases may include, for example, clearing a symptom of error or forcing the device to free from a jam (paper) or conduct a test. The results of such work can be reflected in the variable information of the indication in the data object, which can then be transferred to the computer in the diagnostic terminal. Of course, the approaches described here are examples, and from the above description, other approaches are obvious to those skilled in the art.

25 is a schematic diagram of a network configuration for an alternative embodiment of an automated banking machine according to the present invention. The embodiment shown in FIG. 25 includes an automated banking machine specifically adapted to work in conjunction with conventional automated banking machine systems, such as systems that operate using Diebold 91X AKM message formats or other conventional non-HTTP formats. The host computer 120 in this example embodiment is a conventional host computer AKM that exchanges using such messages. The host computer communicates with the interface server, schematically indicated at 122. The interface server 122 operates as described above and is in operational communication with a storage device that includes information necessary for converting the HTTP messages that belong to the transaction request into a message request 91X or another regular message that can be processed by the host computer 120. Similarly, the interface server 122 and the commands and data stored in the storage device serve ie to convert a conventional 91X command message or other conventional command message from the host computer 120 in the HTTP messages that can be used by the automated banking machine to execute the command. Similarly, the interface server 122 is used to receive HTTP messages that correspond to the response of the automated banking machine to commands, and generates a response message 91X or another conventional response message to the host computer.

In performing these functions, the interface server communicates with the interface client 124, which in the preferred embodiment is an additional COMM module that operates in the terminal of a banking machine running the Windows NT® operating environment. Interface server 122 also includes a command / status gateway 126. The command / status gateway is used to receive commands and status messages from parts of the software that control functional devices in the machine. Messages regarding devices are used in generating transaction messages for sending back to the host computer 120. In addition, a part of the command / status gateway also generates status messages indicating the status of devices that can also be transmitted to the host computer.

The functions of the interface server 122, part 126 of the command / status gateway and interface client 124 may belong to the software in the terminal of the automated banking machine. In this configuration, the terminal appears to the host computer as a normal machine. Alternatively, the functions of the interface server 122 and the command status gateway portion 126 may reside on a separate server, while the interface client portion 124 may belong to a terminal. This enables the interface server 122 to control a variety of automated banking machines by connecting the machines to the interface server via a network.

The alternative automated banking machine system configuration shown in FIG. 25 is particularly suited for use in conjunction with an existing AKM system. The machine includes a computer with a document processing part 128, which includes one or more visible or invisible browsers that operate in the manner described above for embodiments. The part for processing documents for simplicity is also called a browser. The document processing part operates in conjunction with a network 130 to access HTTP records in the form of documents through servers 132, 134 and 136. For the purpose of illustrating this example, server 132 will be considered a home bank server that uses an automated banking machine. Part 128 of the browser allows you to access the documents in its "home" bank in order to obtain content and commands in order to issue information to customers, as well as working devices in the machine. Servers 134 and 136 are representatives of other servers for which the automated banking machine may receive a command to download documents that include information or commands. Often, such documents from the servers of a "homeless" bank include information that should be presented to customers, such as advertising, promotional material, stock quotes or other types of information. It should be understood that servers 134 and 136 can be directly connected to network 130, or they can be accessed through other networks and servers. In some embodiments, such servers can be accessed via the Internet to transfer documents to an automated banking machine.

The document processing portion 128 in this example embodiment includes a terminal software demo portion schematically indicated at 138. The terminal demo portion 138 is schematically shown in more detail in FIG. 26. The demo portion 138 of the terminal includes a latent frame 140 and a demo frame 142. The latent frame 140, although constantly resident in the browser, is not visible on the screen of an automated banking machine. The sample frame 142 is a visible frame and controls what is shown to the client.

As shown schematically in FIG. 25, the HTML document processing part also includes a terminal control unit part 144. A portion of the terminal control unit includes control units, which are respective examples of applets that are used to perform specific types of transactions. Terminal control units typically correspond to the operations of JAVA applets in the above embodiment.

The automated banking machine in the example of an alternative embodiment further includes an application for servicing transactions (PZOT), schematically indicated by 146. The applied task of servicing transactions provides security, terminal status, terminal authorization information and key management services in an automated banking machine. The transaction service application task includes a function for exchanging HTTP messages with the interface server 122. The transaction service application can also be exchanged over a network, such as a network 130, in the manner described below. The transaction service application also provides a server function that enables the transaction service application to perform the functions of the device server 92 in the previously described embodiment.

The automated banking machine according to an alternative embodiment further includes common JAVA device interfaces schematically indicated at 148. The general JAVA device interfaces in the example embodiment are respective examples of applets that control and coordinate the operation of functional devices 150 of machines that execute transaction functions. Functional devices may include devices of the types described for the previous embodiment, or devices of other types that perform a function related to a transaction. The common interfaces of the device 148 in the JAVA language communicate with the functional devices through the interfaces of the common device, schematically represented by the position 152. The general interfaces of the device (OIU, CDI) provide an interface that controls the electromechanical modules in the functional devices included in the automated banking machine. The general interfaces of the device are shown schematically connected to the diagnostic server 154. The diagnostic server operates in a manner similar to the method of the server 109 of the above embodiment. The diagnostic server 154 is useful in diagnosing a condition and resolving problems associated with devices of an automated banking machine.

The hidden frame 140 (FIG. 26) in the terminal demo 138 is a component called the hidden applet 156. The hidden applet 156 is preferably a relatively “thin” (limited) component. Commands, referred to as scripts included in documents accessed by the browser, selectively cause the hidden applet to notify the terminal control unit when an action should take place in response to commands included in the document being accessed. A hidden applet is also needed for the request in order to access a new document. The hidden applet also provides access to the shared transaction data object described above, which stores transaction information.

The demo frame 142 controls the user interface that is visible to the user of the terminal of the automated banking machine. The HTML client, schematically represented at 158 in demo frame 142, defines identification information of an indication associated with events sent to the administrator of the control unit via a hidden applet and provides an interface for publicly accessible procedures of the administrator of the control unit. The administrator of the control unit, which is schematically indicated by the position 160 in FIG. 26, has a class (data structure) that resides in the transaction service application (PZT) application 146, as shown. The administrator class of the control unit, which is constantly in the process of PZOT, serves to load the 144 control units of the terminal into the part for processing documents. The control unit administrator also includes a hidden applet class that resides in the hidden frame 140. The control unit administrator’s hidden applet class provides an interface for client HTML to make requests to the control unit administrator. Commands in documents can transmit events through a hidden applet 156 to the administrator of the control unit. Such events include a transaction authorization request. Such requests may also include indications that the client has completed the transaction or that the document downloaded by the browser includes commands that require the end of the session. Other events that can be transmitted through the administrator of the control unit include print events. Other events in this example embodiment that can be transmitted through a hidden applet to the administrator of the control unit include a sign that the recording has been canceled, or other specific user events.

In response to events, the administrator of the control unit for the shown embodiment responds to commands in documents that are accessed by the browser to perform functions that include changing the contents of the demo frame 142. The administrator of the control unit in response to such commands also changes the class of the active block terminal management. The control unit administrator also caches the terminal control unit class for later use or downloads the terminal control unit classes and documents from the list of available servers, the control unit administrator also provides access to the shared transaction data object that stores transaction information for a specific transaction. The administrator of the control unit also sends the events of the demo terminal to the hidden control class of the control unit of the current terminal and provides a timeout timer. Of course, in other embodiments, the terminal control unit may perform other functions.

During operation in the alternative embodiment shown in FIG. 25, terminal control units 144 in transaction service application 146 allow selective access to documents with document processing part 128. Documents that are accessed may include teams that are used to operate an automated banking machine and functional devices in it. The application transaction service 146 also serves to exchange HTTP messages that are transmitted to the interface server 122 and are used to generate ordinary AKM messages that can be processed by the host computer 120. Cash withdrawals and other “value” transfers are performed in response to permission from the host computer 120, while interface and other functions are controlled by commands in documents that are accessed through a browser.

In an exemplary embodiment, an AKM or other transaction machine communicates with a conventional AKM host computer, passing a transaction data object between the computer in the AKM and the interface server. This transfer is preferably performed by a remote call method (RMI) element of software such as JAVA. Of course, other methods may be used to transfer the data object file using HTTP.

As described above, a transaction data object stores transaction information and possibly other data suitable for a client or transaction. The machine requests data suitable for the transaction, such as account information read from the card, customer PIN number, the requested transaction (s) and amount (s), and includes this data in the transaction information.

As soon as the data necessary for generating a standard transaction message from AKM is presented in the transaction information, the data object is passed to the interface server. The interface server is in operative connection with a database 123 or other element storing conversion data, as shown schematically. These conversions are used by the server-related software to generate a normal transaction request message AKM to the host computer 120. The regular message can be formatted as a normal message 91X or in the format of another non-HTTP type of a normal transaction message.

After processing, the host computer 120 responds with a normal response message. The components of the response message are received at the server and processed in response to the conversion data to generate modified transaction data in the data object. These modified transaction data preferably includes data indicating whether the requested transaction is authorized or rejected, as well as other data. For example, if a transaction is rejected, it may include data that indicates the reasons for the rejection.

The transaction data object with the modified transaction data is then transmitted to the computer using the AKM using RMI or another transmission method. The application transaction service task 146, available in the software, receives the data object, and uses the devices that support the operation of transactions in response to the modified transaction data. The transaction data object has transaction data further modified by including information regarding the operation of the devices. After the devices begin to work, the transaction data object with further modified transaction data is transferred back to the interface server 122. The modified transaction data is then used to form a message to the AKM host computer. The message to the host computer includes data corresponding to the modified transaction data. Typically, this message is a regular non-HTTP completion message indicating whether the transaction was successfully completed by the transaction processing devices.

The non-HTTP format of conventional transaction messages can be easily changed in the described embodiment. This can be achieved with additional blocks. Additional blocks are used to place data in the transaction data object and extract data from it. Additional blocks convert between transaction data and the required regular non-HTTP messages. The use of additional blocks makes it easier to use the AKM of the described embodiment in conjunction with various types of conventional transaction networks.

The transaction data in the transaction data object also preferably serves to force a computer using a browser or multiple browsers to access the selected documents. This can be done to indicate that the transaction is authorized or rejected, and also to refer to certain documents in response to message components. For example, customers of banks other than the one that uses AKM can be provided with some assistance not provided to existing customers of the bank. Transaction data indicating why the transaction was declined can be used to refer to documents that provide an explanation, or may encourage the client to choose another action, such as taking a cash advance on a credit card or requesting a loan.

The system shown schematically in FIG. 25 is an example of an automated banking machine system that provides a wide variety of interface features available using the HTML interface, while maintaining compatibility with existing banking machine systems and associated security methods. Of course, other approaches may use alternative embodiments and configurations.

An additional advantage inherent in the system schematically represented in FIG. 25 is the ability to use the software components of the described embodiment of the present invention in existing automated banking machines. As you can see, processing HTML or other types of documents in conventional computers requires entering data using a keyboard, such as a keyboard with the QWERTY key layout, as well as by clicking on the positions corresponding to graphic symbols (icons) or other features in documents, to successfully manage and use such documents. Conventional automated banking machines usually do not include a mouse or a full-featured keyboard. Instead, conventional automated banking machines typically include an alphanumeric keypad similar to those used in telephones, as well as function keys. Embodiments of the present invention allow systems to operate with terminals that have such interfaces in a manner that can take advantage of the invention.

27 depicts an example interface 162 of a conventional automated banking machine. The interface 162 includes an output device that includes a screen 164. The screen 164 may be a cathode ray tube, a liquid crystal display, or other conventional display screen. In an embodiment, the screen 164 shown is not a touch screen, as in the embodiment described above. Many function keys 166 are located at positions adjacent to the screen 164. The keypad 168 is also included in the interface 162. The keypad 168 includes alphanumeric keys, as well as some other specialized keys, such as cancel, fix, and Confirm (OK). The other keys on the keypad are usually unused, but in some cases can be used.

During operation of a conventional automated banking machine, screen image data that is generated from information stored in a terminal storage device forms certain transaction-related images that are presented graphically on screen 164. Screen images appear sequentially in response to a transaction execution function selected by the client. Conventional on-screen images also typically include text or a graphic representing choices that can be made by the client. These text or graphic capabilities typically include lines or other indication information that are directed toward the edges of the screen adjacent to one of the function keys 166. The user is allowed to make a selection by pressing the function key that is indicated by the selection option. Similarly, when working with an automated banking machine, the user is allowed to enter alphanumeric characters that contain the PIN code number, as well as numerical quantitative information and other commands by pressing the keys on the auxiliary keyboard 168.

In an example embodiment of the present invention, software used in an automated banking machine is used to convert input using standard AKM keys to operating system events, such as a mouse click at a desired position or keyboard input, such as QWERTY. Software components that allow this function to be performed are shown in FIGS. 28-30. These functional modules include the keyboard applet 170. The auxiliary keyboard applet 170 in the described embodiment is included in the applets in terminal control units 144. The auxiliary keyboard applet 170 supports a subset of the functionality of the general keyboard device interface (OIU) of the keyboard.

The auxiliary keyboard applet 170 coordinates the operation with the keyboard command server, which operates in the transaction service application 146. The server in the transaction service application communicates with the general device interface for the auxiliary keyboard and function keys, schematically indicated at 172. The OIU of the keys in the preferred embodiment is a JAVA program, which is called a shell for the general device interface associated with the function keys and auxiliary keyboard.

The software further includes a keyboard display unit program schematically indicated 174. A keyboard display unit in an example embodiment is connected to a database 176 that stores a plurality of display sets. In an example embodiment, the keyboard display unit is an extension of the class of keyboard objects used to operate the keyboard. The keyboard display unit serves to store the key mapping sets (keyboard layout) in the database 176. This is done by reading the information in the configuration database for the AKM to obtain key mappings that are used in a particular machine. During operation, the keyboard display unit selects one (set) of key mappings as the current set. This is done in response to the auxiliary keyboard applet and based on the commands in the HTTP entries that are selectively accessed. The keyboard display unit may select the display of keys in response to commands in documents processed by the browser. The keyboard display unit also serves to enable the operation of the auxiliary keyboard and function keys corresponding to the particular selected key display options. The keyboard display unit also serves to convert an input signal from an auxiliary keyboard or an input signal from a function key into a corresponding input signal from a keyboard or mouse in response to a selected set of display keys, which is then sent to a keyboard input stream or a mouse input stream the operating system of the computer in which the software runs.

In an example embodiment, each (set) of key mapping consists of hash tables. Key mapping objects are stored as values in hash tables so that each object includes the values and actions needed to convert any corresponding AKM key press event into an operating system input event.

As can be seen for the case of function keys adjacent to the AKM screen, it may be desirable to provide input from the mouse into the input stream from the mouse, which corresponds to a specific location in the coordinate system for inputting data by mouse. This is provided by the keyboard display unit using the selected set of key mappings. Different sets of key mappings enable different function keys to provide various types of input to the computer operating system in response to a document processed by the browser to generate output data displayed to the user. In addition, the keyboard display unit forces, upon pressing the selected key, to form input data corresponding to a mouse click in the selected position with x, y coordinates on the screen. It should be understood that either the keys of the auxiliary keyboard or the function keys can be used to form the input data of the mouse. Similarly, input of a function key can be converted to input from a keyboard. In some embodiments, however, it will be desirable to turn off the mouse indicator on the screen so that the user does not see a normal graphic mouse symbol. Such a shutdown may include, in some embodiments, reducing the size of the mouse graphic so that it is so small that it cannot be easily seen by the user of the machine.

During the execution of parts of some transactions, the user may not need to press any keys. In such situations, some preferred embodiments of the invention disable keypad keys and / or function keys. Since computer resources are used to poll such keys in order to detect input, the termination of such a survey during appropriate time intervals makes it possible to redistribute computer resources to perform other functions. This increases the speed at which other actions can be performed. This, in some embodiments, may be performed by an auxiliary keyboard applet that serves to remove devices with keys from the survey list.

28-30 include schematic descriptions of examples of operation of an applet of a keyboard display unit and an auxiliary keyboard. Fig. 29 depicts an example of input from a sub keyboard 168. In this example, the sub keyboard applet 170 typically, in response to commands in an HTTP record, such as an HTML document, or other events, transmits and enables the transmission of an event to a transaction service application 146. In response, the key mapping set is selected from the database 176 corresponding to the specific name of the key mapping set. The keyboard command server further issues AKM permission to use the appropriate keys.

In this example, in response to the client pressing the OK button on the auxiliary keyboard, the OIU generates a corresponding signal to the transaction service application. As can be seen from FIG. 27, the “OK” key is named by agreement as the “J” key of the AKM interface. The transaction service application task transmits a signal generated when the client presses the "J" key on the keyboard display unit 174. In response to receiving the signal, the keyboard display unit allows the use of an object in the set of key mappings corresponding to the name of the key mapping set, which converts the input signal of the function key into a keyboard input signal that is recognized by the operating system. By calling the selected object from a set of key mappings, a keyboard input signal is generated and sent to the computer keyboard data stream. This is represented by stream 178 of the keyboard. In the embodiment shown, the keyboard data stream is an input stream to the Windows NT® operating system. The keypad applet 170 senses the inputted data with its corresponding keyboard data receiver. Applet 170 also perceives the event and can display a graphic symbol or other graphic symbol corresponding to the fact that the client enters data.

FIG. 28 depicts the operation of a keyboard display unit in situations where a transaction service application is used to prevent the data entered by the client from being transmitted to the applet 170. This may be necessary, for example, in situations where the data entered by the client is the client’s PIN or other data that should not be displayed. In these circumstances, the transaction service application 146 saves the data input by the client and sends only a signal representing the commit symbol, in this case the “*” character, back to the browser. This is done selectively in response to commands contained in documents that are accessed by the browser, or in other HTTP records that are accessed by a computer that indicates that the data entered by the client matches its PIN code or other data that should not be sent to the browser . In the example shown in FIG. 28, only the latch symbol is transmitted through the keyboard display unit to the browser. In cases where the HTTP record being accessed calls methods in which numerical values should be sent to the browser and / or displayed on the screen (such as the number of deleted transactions), the signal sent by the transaction service application to the browser indicates a numerical value, associated with the pressed key.

Fig. 30 depicts the following example of the operation of the keyboard display unit when the input data corresponds to the function key 166. In this case, the data entry is caused by pressing the function key "A", which is shown next to the upper right corner of the screen, as shown in Fig. 27 . The signal generated in response to pressing the function key is transmitted to the keyboard display unit, which, in response to receiving data from the data storage 176, outputs mouse input data corresponding to a mouse click. The data entered by the mouse includes data representing on the screen the x and y coordinates of the location where the mouse is to be clicked. This mouse data input signal is transmitted to the input data stream from the mouse, schematically represented by 180.

As you can see, in order to allow the automated banking machine that processes documents to work using the standard AKM interface, the data entered with the mouse will usually include the coordinates of the position that correspond to the location on the screen adjacent to the specific function key. This is due to the fact that the graphic symbol, line, text or other indication information that the client selects by pressing the key will preferably appear or unfold in the place of the screen adjacent to the key. Thus, the client knows, by visual presentation, which key to press in order to make the appropriate choice. Many function keys adjacent to the screen can be activated at any time. The client can make a selection by pressing a function key in one position, and then using a function key in another position, remote from the first position. This will lead to sending signals to the data stream from the mouse corresponding to mouse clicks at positions with coordinates on the screen adjacent to the function keys pressed by the client. During transactions, various combinations of function keys and auxiliary keyboard keys can be activated and displayed on the input data of various keyboards and input from the mouse, as determined by the selected key mapping sets. In addition, developers can develop special sets of key mappings that correspond to specific graphics in documents that are displayed.

In the previous method, the input data of the auxiliary keyboard of a conventional AKM or the auxiliary keyboard of another automated banking machine can be converted into input data of a conventional keyboard or mouse, which can be identified and processed in a normal data input from the keyboard or data input from the mouse to the computer. Similarly, function keys can be converted to mouse input at selected positions and sent to a mouse input stream for processing by a computer, or can be converted to keyboard input and directed to a keyboard input stream. Another advantage of the described terminal configuration is that the keys can be selectively locked, except when necessary. This can reduce the number of attempts to access the machine improperly due to pressing a key on the keyboard. Further, as in the steps described above, it can also be decided to turn off the keys when they are not necessary in order to increase the speed of transaction processing.

An additional advantage of embodiments of the present invention is the ability of an automated banking machine to issue printed documents based on commands in HTML or other types of documents. Such printable items may include tickets, travel checks, money orders, bank checks, government bonds or other types of documents. Possible embodiments allow the circulation and processing of documents, the printing of graphic images and other indication information, which can form printed documents having selected features of appearance and selected decorative patterns. This can reduce the need to use pre-printed forms and also allows the printing of a wider variety of printable formats. Additionally, the configuration of some embodiments of the machine allows the printing of only selected parts of transaction information in order to save records in the machine, while at the same time providing options, including extended graphics or other attractive features, to customers.

Fig is a schematic representation of the system when printing forms using a printer in an automated transaction machine. An example form according to the invention uses the services of a WIN32 printer that is running Windows NT® 4.0. In the shown transaction example, the control unit manager class 180 operating in the demo part 138 of the terminal initializes the transaction by requesting the printer control unit 182 to print the receipt. The printer control unit in the example of the embodiment is a combination of cases of the corresponding JAVA sets (bin objects) that serve to perform printing operations, and is one of the control units among the 144 terminal control units. The printer control unit includes a print class (data structure), which is shown schematically separately, for invoking the print URL method. The printer class in an example embodiment includes access to a shared transaction data object that includes information about a specific client related to a transaction, which includes indication information representing information to be printed. In the case of an automated banking machine, it may include, for example, indication information representing information that is read from a customer card inserted in the machine and read by a card reader. It may include, for example, customer name and account number. Other transaction information may include the types of transactions conducted, such as a deposit, withdrawal, or request, as well as the amount included in each relevant transaction.

The transaction service application 146 receives a print request and passes the URL string to the WIN printer object 184 using the URL printing method. The URL address in the example embodiment is the address of the HTTP record, such as an HTML document, which should be used to format the document to be printed if received. This HTML document contains an embedded JAVA script that processes transaction information from a transaction data object. The URL of the document may be located on a locally located machine, or it may be found on another server, for example, through a network schematically indicated at 186. Network 186 may be a local network or a global network, depending on the configuration of the machine.

The WIN printer object 184 is then routed to the address of the document to be accessed. In one preferred embodiment, this is implemented using Microsoft's Web-Browser2 ActiveX control. When an HTML document has been loaded, ActiveX control automatically begins to process the contents of the document that has been accessed. The transaction service application 146 calls the print URL method of the WIN printer object 184. The WIN printer object uses ActiveX control to print the current HTML document. This printing process is handled by the Windows NT® paging and graphics buffer components that enable printing.

The JAVA OIU receives events from the print control component 192, which indicates completion of printing with information paging. This indicates that the file is now available for reading and forwarding to the general device interface (OIU) 188 of the printer for printing receipts.

Then, the printer object 190 calls the read data function of the print control component 192 to determine the position and size of the print data file. The print object 190 sends the data or the path name of the data file to the printer OIU 188. The printer OIU 188 then transfers the print data to the printer hardware. This prints the received data.

Once the received data is printed, the applet from the printer control unit 182 issues a request to direct the printed received data. A direction request is transmitted through an application 146 transaction service to the object 190 of the printer. The object 190 of the printer calls the method of sending to the printer 188 OIU to send the received data to the user of the machine. The operation of software components enables selective access to document formats, as well as the use of commands contained in documents, to include transaction information in printed documents. This allows you to create documents of various types. In addition, this allows printing of various types of documents for various clients. This may be desirable when providing marketing information, coupons or similar information indicating when receiving transactions. This approach also simplifies the provision of printed formatted documents in various languages by designing HTML documents that provide printed forms in various languages. As can be seen, numerous types of document forms can be set, including commands that insert values and / or process some data in the transaction data object to form printed forms. In addition, the methods of the present invention can be used to provide marketing information to customers through profiles or types of customer categories, as well as part of such information.

Although the above printing method is described in conjunction with the direction of the received transaction data, similar methods can be invoked to print account statements for customers, as well as to print a transaction log in an automated banking machine. Further, referring to the selected documents governing the printing format of the information, the journal entries can be provided with the combined information in a way that allows the journal paper to be stored in the machine without printing related or other types of information that is provided for client documents.

The printing method of the example form according to the present invention also allows the printing of various types of optical pointing information, such as a bar code or other types of machine-readable pointing information, which can be used to print coupons, checks or the like. Such coding can facilitate tracking the use of such products by customers to evaluate the effectiveness of various marketing efforts. In addition, machine-readable instruction information can be used to print on products, such as deposit envelopes and / or in transaction logs. Such printing can facilitate the reading of such products by the machine in order to check the content of deposits.

The printing capabilities achieved by the methods of the present invention also allow the printing of selected graphic materials. They may include, for example, materials that include embedded digital signatures that can be used to authenticate printed documents. This can be especially useful, for example, in situations where a transaction machine is used to print bonds, travel checks, bet forms or other documents of independent value. In addition, fully-printed documents can be generated by connecting a color printer in a transaction machine.

The principles associated with printing forms from an automated banking machine are also applicable to the development of other electronic forms and forms in hard copy. As described above, in embodiments of the invention, transaction information may be sent to the home bank as an HTML document or other HTTP message. Such documents may include instructions that, after processing by the browser, retrieve or manipulate the data, so that they can be further processed and / or stored in various formats. Such processing may include, for example, converting the data in the document to a non-HTTP format such as Diebold. 91X, NCR PAS, or IBM 473X format.

In some circumstances, customers of an automated banking machine may be presented with promotional offers or offers to buy goods or services. These offers may come from seller’s institutions not affiliated with the institution in which the customer has an account. Such proposals, which must be accepted, may require the customer to provide the seller with information. Such information typically may include data accumulated in a transaction data object or transaction record. For example, a seller of goods or services will often need a customer name and account number information to pay for goods or services. As described above, the transaction data object may also store personal data regarding the customer that is stored on the customer card or other product, and read by a reader in the machine. In exemplary embodiments, sellers of such goods or services may have available applications on the server. These applications may include documents that have instructions for inserting values and / or processing information in a transaction data object to provide information that a seller needs to complete a transaction. This can be done by “navigating” one of the visible or invisible browsers in the banking machine to the network address where the seller’s document (s) is available in response to the client entering commands that they wish to accept the offer or conduct such a transaction.

In examples of embodiments, the seller’s form may be visible on a display and printed by a customer on an automated banking machine. If there is a need for additional information from the client or for the client to make a choice, the seller’s application program composed of HTML, another document markup language, or other documents can reveal such information through the client’s interface of the banking machine. The seller’s application may also have restrictions confirmed by the client relating to the goods or services offered. The print capabilities of an example embodiment also allow the customer to provide a printed version of a computer-generated form or contract that reflects information regarding a transaction and terms associated with it. Additionally, any special conditions, such as a printed notice that the client has the right to cancel the transaction at a specific time and the steps that the client can take to cancel it, can be provided in the format of a printed hard copy.

In alternative embodiments, offers or transactions provided through an automated banking machine by sellers of goods or services may use the same or at least some of the documents containing the application program that is used to conduct the transaction by electronic means when the client is not uses an automated banking machine. For example, similar documents of the form type may have data in them recorded using the user's home computer when a transaction is conducted far from an automated banking machine. When a transaction is conducted in a banking machine, the information in the transaction data object or other transaction record is used to provide the necessary data.

This opportunity provides sellers with the opportunity to develop application programs that can be used over the Internet for home PCs (personal computers), as well as for customers who use automated banking machines. These capabilities additionally provide an opportunity for merchants and banking institutions to develop application programs, such as home banking applications, procurement applications, and billing applications that can be used from both home PCs and automated banking machines. Since automated banking machines have access to data that is stored in the back office, a database, personal data stored on a card or accessible from another data storage device, the system according to the invention can be configured so that additional information can be included in the data object Transactions without the need for the customer to enter data into the bank machine. This allows you to process transactions in a banking machine more quickly than might be possible on a client’s “home” PC. Further, the use of a banking machine for conducting transactions enables the client to conduct transactions using the protection associated with the banking machine system.

The use of automated banking machines for transactions that could be carried out through a “home” PC has the advantage that it includes the ability to provide customers with forms for obtaining a hard copy documenting transactions. Using a banking machine can also provide customers with a greater degree of confidentiality that transactions have been recorded, as the bank can also maintain information that documents the transaction even if the transaction is between a client and a third party. Banking machines can also provide forms of receipts (receipts) that are intentionally made more difficult to counterfeit or that have the ability to verify authenticity. The use of image recording systems in conjunction with banking machines can also be used to verify that the transaction was conducted by an authorized person. Such features also enable the institution that has a customer account to offer rewards such as premiums, extended warranties, or prizes for conducting transactions involving the institution. Numerous advantages can also be achieved in the framework of the present invention.

Terminal control blocks, as described above, are software components that are collections of objects, such as JAVA applets or JAVA sets (bin objects). JAVA sets are JAVA classes that belong to the specification of JAVA sets (bin objects). These objects apply to sequential AKM transactions. In an example embodiment, there is typically one terminal control unit per transaction. For example, two conventional terminal control units - a withdrawal control unit and a deposit control unit, which serve to control the functionality of AKM for withdrawing and making a deposit. Other terminal control units are responsible for other types of transactions, such as transferring money between accounts and executing a request for the available balance of the current account.

An example embodiment of the present invention includes methods for creating terminal control units in a visual programming environment by linking a plurality of visual graphic symbols that represent examples of respective JAVA sets. Although an example embodiment uses JAVA sets, the present invention encompasses any type of objects or classes that are applicable to group programming logic, events, properties, and methods. Other examples include C ++ classes, CORBA objects, ActiveX objects, and COMM objects. Previous examples of these objects include a hidden applet 156 and an auxiliary keyboard applet 170.

The present invention includes many of these specialized applets, classes, or objects that are intended to encompass certain functionalities for automated transaction machines, such as AKMs, and other types of self-service terminals. These objects are named AKM objects below and are intended to be basic building blocks for creating terminal control blocks. For example, some AKM objects are used to control various AKM devices, such as card readers, bearers, cash dispensers, printers, and keypads. Other AKM objects are used to manage transactional functionalities, such as authorization and client profile management. Additionally, other AKM objects are used to control the processing of the PIN code and transaction data.

In an example embodiment, the demonstration control units are created by visually configuring variants of these AKM objects. 36 schematically represents a visual programming environment 220 that enables a programmer to visually create a terminal control unit 225. In an example embodiment, the visual programming environment is achieved using IBM's Visual Age for JAVA®. However, the present invention encompasses any visual programming environment that allows a user to visually associate a group of individual AKM objects, process the AKM objects, determine the characteristics of objects, and define relationships between objects.

The visual programming environment 220 includes a palette 222 (toolbar) including graphic symbols that are visual representations of these AKM objects. The programmer is usually allowed to create a terminal control unit 225 by selecting the necessary individual AKM objects and placing them in the visual workspace 224. Placing the AKM objects in the workspace 224 serves to subject the object to processing. Machined AKM objects are represented in the workspace with marked graphic symbols, such as 230 and 232 AKM objects. The developer is also allowed to bind the AKM objects together to create links or routes that the programming logic of the terminal control unit 225 will track. These routes are represented by a solid line 238 between the AKM facilities.

Once the AKM object is placed in the workspace, it can be specified how it interacts with other AKM objects. This is accomplished by changing one or more properties of the AKM object and by creating visually marked routes or links between the AKM objects.

For example, an AKM object 232 represents a certain type of an AKM object called a hidden control unit, which uses the services of an administrator of a control unit to manage properties such as a browser URL. In this described terminal control unit 225, the AKM object 232 has been marked as a “service menu” 231 since it has been configured to have an HTML page opened by the browser for servicing the AKM.

AKM objects typically include one or more events. The events of such AKM objects are signals or messages that indicate that something has happened. For example, when a bank card is inserted in the card reader device, an event on the card reader will be triggered in the AKM object to monitor and control the card reader.

AKM objects also include methods. AKM object methods are actions or functions that an AKM object can perform. For example, an AKM object for a card reader will include a discard method that serves to cause the card reader to discard a bank card.

Fig. 39 depicts a table of examples of types of AKM objects 256 and their associated graphic symbols (icons) 258. These AKM objects include an authorization object 260, a hidden control object 262, a card reader device 264, a client profile object 266, a depositor object 268 , issuing device object 270, auxiliary keyboard object 272, logical object 274, SC object 276, bearer object 278, PIN code input object 280, printer object 282, synchronization object 284, and transaction data object 286.

An example authorization object 260 includes functionalities for managing communication with an authorization agent, such as a main banking system. In an example embodiment, such communication includes authorization requests, transaction commit, and transaction cancellation. The authorization object interacts with an additional authorization module to send and receive status messages from the authorization host computer.

An example of a hidden control object 262 includes functionality for using the services of an administrator of a control unit to manage browser URL properties, load control units, and receive events from a browser. The hidden control object contains the functionality of the hidden applet 156 described above. Each terminal control unit requires at least one hidden control object 262 that provides a communication link between the administrator of the control unit and the terminal control unit. For example, a hidden control object “navigates” the method used to change the displayed HTML page. In addition, demonstration events that are related to data input, such as a button click in an HTML page, are triggered from the hidden control object 262.

An example of an object 264 of a card reader is one of a variety of AKM objects for controlling an AKM device. In this case, the card reader object 264 includes functionality for controlling the card reader device.

An example of a customer profile object 266 includes functionality for collecting and retrieving customer information. The profile object may include a sign of whether the user of the machine is the client who is to conduct the banking transaction, or the maintenance personnel of the machine who is authorized to carry out one or more types of servicing actions. The profile object may also include the functionality of the profile applet described above. The client profile object 266 preferably interacts with one or more removable client profiles to retrieve and modify client profile information stored in a variety of different locations, such as a local data storage device, external data storage device, application server, or any other location that serves to storing information regarding the AKM user.

Examples of the depositor object 268, the issuing device object 270, and the auxiliary keyboard object 272 include functionalities for controlling the depositor device, the issuing device, and the auxiliary keyboard device, respectively. The sub keyboard object 272 includes the functionality of the sub keyboard applet 170 described above.

An example of a logical object 274 is a special AKM object that does not monitor or control external AKM devices, but rather controls the flow of logical data between AKM objects. Logical object 274 includes functionality for determining truth values when comparing two operands and calls various methods of one or more AKM objects depending on the result of the comparison.

An example of a command status object 276 (SC, OCS) includes functionality for controlling the processing of commands of the host computer and responses to commands of the host computer. The object 276 SK interacts with the server SK and additional blocks of the command / status for communication with the host computer.

An example of a bearer entity 278 includes functionality for controlling a bearer device, such as a device for presenting issued sheet documents. An example of a PIN input object 280 interacts with a PIN input event server to control a PIN input mode. An example of a printer object 282 includes functionality for controlling a printing device.

An example of a synchronization object 284 includes functionality for synchronizing multiple processing methods. The synchronization object 284 also provides a timer for one or more processing methods. For example, in a terminal control unit for withdrawing cash, the synchronization object can be used to control the synchronous cash dispensing and prepare the receipt.

An example of a transaction data object 286, as described above, includes functionality for archiving transaction data that can be shared between terminal control units, a browser, and an authorization agent. Examples of data managed by the transaction data object 286 include a chargeable amount, an account number, and an account type. When the request method of the authorization object 260 is called, a copy of the transaction data from the transaction data object 286 can be transferred to the host computer to authorize (issue permission) the transaction.

These described AKM objects are used in an example embodiment of the present invention. However, the present invention also implements other types of AKM objects that form the functionality of the AKM terminal. Other types of AKM objects can control devices, such as a fingerprint reader, an iris scanner, an intelligent card reader, a sound system, a printer for printing on savings / checkbooks, a receipt scanner, a printer for printing bank statements, a printer for printing a ticket printer, a coupon printer, a phone card encoder, or any other type of device that can be quickly connected to AKM. In addition, other AKM objects are used to interact with databases, servers, and other types of computing systems for extracting and sending data to and from the AKM terminal.

On Fig presents a portion of the visual workspace 224, which includes an example of a route or communication 238. An example of communication 238 corresponds to the connection from the event to the method between two objects 230 and 232 of the AKM. An example visual programming environment uses an event-to-method connection between AKM objects to control AKM functionality and transaction flow. A transaction flow is transferred from one AKM object to another, linking the event of one AKM object with the method of another AKM object. The visual programming environment in the example embodiment includes visual relationships to indicate the direction of program flow. For example, a square 248 at one end of junction 238 indicates the original AKM entity. Arrow — A pointer 250 at the opposite end of connection 238 indicates the target of the AKM. When an event occurs in the source object AKM 230, the program stream is transmitted to the method of the target object 232 AKM. Of course, in other embodiments, other types of visual indications of communication between objects may be used.

For this example, terminal control unit 225, the AKM entity 230 is a logical entity 274, designated "isService", which is configured to trigger either a true event or a false event if the user has or does not have permission to serve the AKM. AKM object 232 is a hidden control object 262, which, as described above, is labeled “Service Menu” and includes a navigation method that serves to open the HTML page of the service menu in the browser.

Fig. 38 is a window 246 in a visual programming environment for creating, editing, and changing a connection of an event to a method. Here, window 246 displays parameters for connecting event 238 to a method that determines that when source event 243 occurs at source object 242, target method 245 will be called to target object 244.

As shown in Fig. 36, not all groups of AKM objects are interconnected. For example, groups 252 and 254 of AKM objects are not related. This reflects the properties of terminal control blocks, which should be event-driven. Each of these groups is represented by a specific terminal control function block or subroutine that is triggered by an AKM event or called in the AKM object method.

AKM object methods often require parameters. In an example embodiment of the present invention, these parameters may be provided with parameters of an AKM object or other AKM objects, visually creating parameter or communication connections.

37 includes an example of a visual connection 236 parameter. The visual connection of the parameter serves to return a value for the method argument. The visual connection 236 of the parameter includes a solid circle at one end, which serves as a visual key that the client type in the object 226 produces a parameter. The opposite end of the visual parameter connection 236 is connected to the event connection 240 with the method. The arrow 241 associated with connecting the event to the method is a visual key that indicates that the isService logical entity 230 includes a method that is the target, and connecting the event to the method and connecting the parameter.

For this example of a terminal control unit, the AKM object 228 is a PIN entry object that includes a PIN entry event. The event connection 240 with the method has been configured so that when a PIN input event occurs, the comparison method of the logical object 230 isService is called. Connection 236 parameter indicates that the comparison method is called with the argument entered by the object 226 of the client profile of the client type. The comparison method of the logical object 230 isService is configured so that if the value of the client type data in the client profile object 226 is equal to the value represented by the client of the attendant type, a true event will occur. Accordingly, if the service type does not represent the value of the client type, a false event will be raised. Triggering a true event, which is determined by connecting event 238 to the method, calls the navigation method of the service menu hidden control object 231. The triggering of a false event, as defined in the event connection 250 with the method, calls the navigation method of the service menu hidden control object 234.

Fig. 54 schematically represents a programming architecture of a terminal control unit that contains AKM objects. As described above, the terminal control unit 290 is an applet that contains a plurality of AKM objects 292 for determining the transaction sequence of the AKM. Each AKM device 298, such as a card reader or printer, has a corresponding AKM object that serves to monitor and control the operation of each AKM device 298.

Administrator 291 of the control unit serves to load and unload terminal control units 290 and helps provide a programming route from HTML pages 246 to terminal control units 290.

For communication with external host computers 304, additional interface browser modules provide an interface between the AKM objects 292 in the terminal control unit 290 and the external host computer 304. In an example embodiment, these additional modules support Diebold 91X format messages, including configuration, transaction, state, and messages like commands.

Examples of such additional modules include SC (Team Status, OCS) optional module 302 and optional authorization module 300. As described above, the ACM SK object 276 interacts with the additional SK module to provide “serviced” and “out of service” events that originate from the host computer 304. The additional SK module 302 also provides methods for sending the state of a command and user events to the host computer 304 .

An additional authorization module 300 also serves to communicate with a host computer 304, which serves as an authorization agent. The authorization object 300 interacts with an additional authorization module 260 to manage transaction messages, including permission, commit (transactions), and return requests from the authorization agent host computer 304.

As described above, the optional client profile module 306 serves to retrieve user profile information from a local or remote database 308. This information can be used to individualize the AKM terminal for each client 294 that uses the AKM terminal. The client profile object 266 interacts with the add-on client profile module 306 to retrieve and modify client information in the database 308.

As soon as the terminal control unit is created in the workspace 224, the visual programming environment saves the terminal control unit as an applet, JAVA class, or other object. Such applets are quickly saved as programming language commands that respond to AKM objects and communications visually created in the workspace 224. For example, the terminal control unit can be saved as one or more source files. Also, the terminal control unit can be compiled and saved in a form that is suitable for use with an automated transaction machine according to the present invention, such as applets, EJBs, COMM objects, CORBA objects, dynamic link libraries, or any other type of software container. The visually created terminal control unit can then be integrated with other terminal control units to control the functionality of the AKM terminal according to the present invention. In an example embodiment, terminal control units may reside in an accessible memory device such as a hard disk or random access memory (RAM) of a local computer or a remote network computer. In an example embodiment, terminal control units may be retrieved by AKM from a local or remote file system. Also, terminal control units can be retrieved from a local or remote database or Web server. In other exemplary embodiments, terminal control units may be integrated into an application server.

During a typical client session, the AKM terminal will use at least three control units: a control unit, a transaction management unit, and a termination control unit. The control unit is usually responsible for entering the card, entering the PIN code and selecting the transaction. The transaction management unit is responsible for authorizing and managing the device during the selected transaction. The completion control unit is usually responsible for completing the transaction, including returning the card to the client.

The visual programming environment used in the example embodiment of the present invention enables the user to create new terminal control units or configure existing terminal control units to meet the requirements of a particular banking institution and the needs of customers using the AKM terminal. The visual programming environment provides a flexible and intuitive programming environment that allows the developer to visually connect many specialized AKM objects together to create an interactive AKM application.

Figures 40-53 schematically represent properties, events, and methods associated with AKM objects in an example embodiment. Many of these AKM objects produce synchronous events. When methods or functions of AKM objects are called to perform an action, the AKM object waits for the completion of the action, then triggers an event that indicates the result of the operation. In the example embodiment, there are four events related to the operation that are common to most AKM objects. As shown in FIG. 41 with respect to authorization object 260, these operation events 348 comprise a successful operation event 340, a failed operation event 342, an unavailable operation event 344, and an unsupported operation event 346. An unavailable operation event 344 indicates that the device is temporarily unavailable because, for example, it has been put into maintenance mode. An unsupported operation event 346 indicates that the device is not supported on the AKM.

An example authorization object 260 also includes many specialized events and methods. Examples of permission object methods include an authorization method 320, a transmission method 322, and a postback method 324. When these methods are called, the authorization object 360 interacts with an additional authorization module to exchange messages with the authorization host computer to either allow, or transmit, or send back the transaction.

An additional authorization module converts authorization methods into messages that correspond to the selected host computer protocol, such as 91x messages. For example, terminal control units that serve to execute a withdrawal transaction will typically include an authorization entity 260. Before cash will be issued to the client, the authorization request is sent to the authorization host computer, calling the authorization object authorization method 320.

The example authorization object also includes many events, such as stolen card event 326, invalid account event 328, invalid quantity event 330, invalid PIN code event 332 and additional tax event 334. These events are triggered in response to receiving a status code from the authorization host computer.

This example embodiment of an authorization object 260 also includes the ability to expand a core set of events through a user state event 336. An additional authorization module may be configured to trigger a user status event when the status message from the authorization host computer includes a unique status code. This code is placed in the user state field of the transaction object. When a user state event is triggered, the terminal control authorization object can be configured to call a logical object method that compares the value in the user state field with a known set of possible user codes.

FIG. 41 represents a method and events for a hidden control object 262 for an example embodiment. As described above, the hidden control object 262 interacts with the administrator 291 of the control unit to set the URL in the browser, download a new terminal control unit and establish a new document database for the browser. In an example embodiment, the hidden control object 262 includes methods such as a navigation method 350, a navigation control block method 352, and a main blank document method 354.

Navigation method 350 serves to set a new URL in the browser. URLs are passed as a parameter to the navigation method. The URL may be an absolute address that includes the full specification of the URL starting with "http: \\", or the URL may be a relative address that begins with "\" and is relative to the fixed or current page of the HTML document. The navigation control block method 352 serves to download a new terminal control block in addition to setting a new URL.

Both, and the navigation method 350 and the method 352 of the navigation control unit, include a timeout argument that determines the number of seconds before the timeout is turned on, and the timeout page is displayed to the user. A timer is a means to prevent the AKM terminal from freezing indefinitely on the page, and should force the client to stop making choices. The navigation timer parameter can be set to zero for those cases when an event or timer for another AKM object is guaranteed to be called regardless of the user.

The hidden control object 262 includes events such as an authorization request event 356, a PIN request cancellation event 358, a print request event 360, a non-press event 362, a session end event 364, an additional tax acceptance event 366, an additional tax rejection event 368, transaction completion event 370, user events 372, 374, 376, and yes click event 378. These events are raised by the administrator of the control unit in response to the user's use of the current HTML page. In a browser, for example, a button on an HTML page can be configured to trigger one of these hidden control events in response to the button being pressed.

The hidden control object 262 also includes a plurality of events that are triggered only in response to the administrator of the control unit directly. These events include a loaded control unit event 380, a navigation block failure event 382, a failed control event 384, and a screen timeout event 386. The event 380 of the loaded control unit is triggered when the terminal control unit is loaded. Navigation block operation failed event 382 is triggered when HTML or a script in a browser called the control unit administrator to move to a new URL and change terminal control units, and one of these actions failed. Similarly, a bad control event 384 is triggered when the HTML or script called the control unit administrator to move to the new URL and the move failed. The screen timeout event 386 is triggered after the indicated number of seconds has elapsed without any user action.

Fig. 42 schematically represents methods and events for an example embodiment of an object 264 of a card reader. The card reader object enables the developer to create transaction control units that use and manage the AKM card reader. The card reader object 264 includes methods such as a resolution method 390, a shutdown method 392, a dispense method 394, and a hold method 396. Enable and disable methods 390 and 392 enable use and disable the card reader, respectively. Issuing method 394 serves to pop a card to be issued back to a customer. The hold method 396 serves to hold the card internally and is usually used in situations where the card must be held, in such cases, for example, when the card has expired, it is marked as captured, or when the customer leaves the AKM, does not take the card back.

The card reader device 264 includes the following asynchronous events: card input event 398, card read event 400, card hold event 402, card acceptance event 404, and card request event 406. Each of these events is triggered in response to the action described in the event name. For example, when a card is read, a card read event 400 will be triggered. The card reader object 264 also includes the same set of operation synchronization events 408 as the operation events 348 described for the authorization object 260, when the card allows data to be read from the card and put into the server of the card reader, where data can be transferred to the host computer or used to work with the client profile.

FIG. 43 schematically represents an example embodiment of a client profile object 266. The client profile object 266 reads and writes information unique to a particular client. Customer profile object 266 includes many properties, such as customer type 419, actual quick payment account 420, actual fast payment amount 421, preferred quick payment account 422, preferred quick payment amount 423, quick payment selection property 424, preferred language 425, the last 426 withdrawal account, the last withdrawn amount 427 and the constancy property 428.

These properties can be used as parameters for other methods of the AKM object. In addition, read and write methods can be invoked by HTML pages to obtain or set these properties. Property 419 of the client type is differentiated between different classes of clients, such as staff or client. A valid quick payment account 420 and a real quick payment amount 421 identifies the withdrawal amount from the bank account, which is shown to the customer in HTML for a quick cash transaction. Preferred quick payment account 422 and preferred quick payment account 423 identify the withdrawn amount from the bank account that has been selected by the client from the preference page to use for quick cash transactions. The selected fast payment property 424 determines whether the withdrawal transaction is fast or not. A typical cash-out control unit may use this property to determine whether to set quick payment selection values. The language preference property 425 identifies the preferred language of the client. Property 426 of the last withdrawal account and property 427 of the last withdrawn amount identify the last account and the amount used by the client during the withdrawal transaction. The persistence property 428 identifies the client profile set (bin object) element as persistent. Any value set in a permanent object causes the value to be written to a database or other data archive. Values set to a non-persistent element of the client object are lost at the end of the client session.

The terminal control unit can be operatively programmed to display an HTML page in the browser, which includes information and choices for performing a transaction in response to client profile properties. As described above, choices for servicing the AKM can be presented to a user, such as a “maintenance staff,” while a user, such as a “client,” would only be presented with options for performing a transaction with the AKM. Also, various levels of transaction functions may be related to the type of client. For example, customers who have a bank account with a financial institution that has an AKM may be assigned a type of customer that grants permission to the customer to perform advanced transactions, such as paying an invoice and printing checks. However, customers of other banks may be assigned a type of customer that only allows them to access simple transactions, such as cash withdrawals.

The client profile object can also be used to modify client profile information in data in response to user interaction with the AKM. Such user interaction may result in modification of the user's preferred language, actual quick payment properties, preferred quick payment properties, selected quick payment properties and last withdrawal properties. For example, using the client profile object to save the properties of the last withdrawal of money every time a cash withdrawal takes place, the terminal control unit serves to present an HTML document to the user with the possibility of withdrawing the same amount of money the next time the user accesses AKM.

Client profile values are retrieved and modified from the stored data in response to user or client identification information, such as an account number or other unique value associated with the user. Such an account number is usually read from a card by a card reader device. However, in alternative embodiments, the implementation of the AKM may enable the user to enter an identification value using a data input device, such as an auxiliary keyboard, a biometric device, or any other device that serves to obtain information that identifies the user of the AKM.

In addition, the client profile object can be used to retrieve and store other types of information in a data storage device. Such information may include customer-related marketing information that can be used by the terminal control unit to display targeted AKM advertisements, for example, through a browser. Client profile values can also be used by the terminal control unit to form user-defined transaction options or other selectable options for interaction with AKM. Such information can be obtained from various sources, as described above. Some of this information may also be provided by the user. This can be done in person or through an automatic data acquisition device. Alternatively, such information may also be provided by a user from a remote terminal, such as a personal computer, through an interactive connection. Examples of such data collection approaches are described in US patent No. 6023288, the disclosure of which is incorporated herein by reference.

The client profile object 266 includes the following methods: read or receive methods 410, write or set methods 412, persistence property setting methods 414, client session reset methods 416, and operation events 418. Read methods 410 and write methods 412 are used to extract and modify client profile information. The persistence setting method 414 forces the client profile server to write to disk all the permanent profile properties accumulated during the client session in the data archives. The AKM terminal uses the method 414 for setting the constancy property to efficiently accumulate all records so as not to slow down the client transaction. A typical terminal control unit should have a card reception event associated with the method of setting the constancy property, so that the modification of data archives occurs immediately after a client session.

The client session reset method 416 resets all configuration properties to an uninitialized (zero) state. This method is usually called between client sessions to reset the values accumulated for the previous client. For example, a card entry event may be associated with a client session reset method 416 such that the client profile data is set to zero for each new session.

55 schematically represents an architecture for using a client profile object 266 to enter specific client information using an AKM terminal. HTML pages 614 may include scripts that are commands for receiving and setting specific client information through a client profile object 266. The client profile object 266 is isolated by the client profile server 600 and therefore has no software requirements to identify a data archive for the profile data. This architecture simplifies the task of individualizing the AKM terminal for each client. An institution can integrate its database logic into the AKM terminal by implementing a simple client profile server.

Client profile properties are read from a data archive, such as local database 608, remote database 610, magnetic or smart cards 612, or any other type of data storage device. One or more registered classes 602, 604 and 606 of additional modules are configured to control the reading and writing of profile data for a particular data storage device. In an example embodiment, there are two types of classes for the optional profile module. The first FITProfile add-on module, which controls the client type and other properties, is used internally by the AKM terminal. The second is an additional user preference module that manages user preferences, such as those shown in FIG. 43 for language and quick payment transaction. These preferences are usually read and written to the local database. In alternative embodiments of the client profile architecture, another add-on module may be implemented to connect to any type of data storage device that contains useful information related to the client.

The developer of the terminal control units may include a variant of the client profile object 266, which serves to interact with other data storage devices through these new additional modules.

An example embodiment of a depositor object 268 is shown schematically in FIG. The depositor object 268 allows the developer of the terminal control unit to use and manage the device of the depositor in AKM. The depositor object includes a permission method 430, a prohibition method 432, and an envelope holder door unlock method 436. These methods are used to permit and prohibit the depositor and unlock the door of the envelope holder, respectively. The depositor object 268 also includes a print data setting method 434 that determines transaction information to be printed on the deposited envelope.

In addition to the synchronous operation events 444, the depositor object 268 includes the following asynchronous events: deposit completion event 438, media insertion event 440, and envelope holder door unlock completion event 442. Each of these events is included in response to an action that is described by the name of the event.

Fig. 45 schematically represents an example embodiment of an object 270 of a dispensing device. The issuing device object 270 provides an interface with the issuing device and includes an issuing method 450 and a storage method 452. The issuing method takes one or more of the following parameters: quantity, family, and type. The quantity parameter is usually the transaction amount that has been confirmed for the agent to issue a permit. This value is obtained from transaction data object 286. The family and type parameters are descriptions of the kind of media to be issued. The save method is used to locate a carrier, such as accounts, that must be selected and transferred to the bearer or other escrow device. In addition, the object of the issuing device includes events 454 operations.

An example embodiment of an auxiliary keyboard object 272 is shown in FIG. The keypad object includes a display resolution method 460 that takes an argument to determine which key or keys are allowed to be pressed, and to map the input using the keys to the input with a mouse click. Disable disable method 462 selectively disables key presses. The keypad object 272 also includes operation events 464.

47 schematically represents an example of a logical entity 274. A logical entity serves to perform logical comparisons of data elements. The terminal control unit uses the results of the comparison to change the flow of transactions. A logical entity is typically used to compare a known value or range of values with the current value contained somewhere in a transaction data object 286 or client profile object 266. Logical entity 274 includes a logical comparison method that takes two parameters that are comparison objects. Depending on the result of the comparison, the logical object includes either the truth event 472 or the false comparison event 474.

48 schematically represents an example of an object 276 SK. This object interacts through the SK server with an additional command / state module and, ultimately, the host computer. The SC object 276 includes the following methods: a user event sending method 480, a command state sending method 482, a service setting method 484, and a service exit method 486. The user event sending method 480 sends an event to an additional command / status module. The command / status add-on module can then use this information in combination with any subsequent return send or commit to form the appropriate message for the authorization host computer. The user event dispatch method 480 is typically used when a client cancels a transaction or is unable to take out the issued cash. This method can then be used to tell the host that the transaction was canceled, cash was saved, or the timeout was exceeded.

The maintenance method 484 and the exit method 486 enable the host computer to transfer the terminal to or from the service. In addition, the object 276 SK includes the following events: event 488 enter service, event 490 exit service, event 492 autonomous control SK and event 494 operational management SK.

Additional command / status modules trigger an event 488 to enter service and event 490 to exit service after receiving commands from the host computer to enter service and exit service. The terminal control unit is typically configured to respond to these events by enabling or disabling a device, such as a card reader or keypad. Additional command / state modules trigger the SK operational control event 494 and the SK autonomous control event 492 when the exchange is started and stopped by the host computer.

An example of an embodiment of a PIN entry object 280 is shown in FIG. The PIN code input object 280 is used to set the state of the PIN mode property in the server of the PIN code input event. The method 500 for starting to enter a PIN code is used to transition to the "in PIN mode" state. In response to the inclusion of "in PIN mode", the PIN server determines the correct number of repeated PIN code entries allowed to the client, and then enters the safe mode for processing input data from the auxiliary keyboard.

When the client enters an acceptable PIN code or when the client presses the cancel button, the server of the PIN input event sets the property "in PIN mode" to false. The PIN code cancellation method 501 also serves to disable the "in PIN mode" property and is usually called by the terminal control unit when a time-out event associated with the screen occurs.

The PIN input object 280 includes events, such as a PIN input event 502, a PIN input cancellation event 504, a PIN input rejection event 506, and an operation event 508. The PIN input event 502 is triggered when the PIN input event server decides that the PIN is either valid (local verification) or the PIN can be approved later by the authorization host. The PIN input cancellation event 504 is triggered in response to a client clicking a cancel button in the AKM terminal. The PIN input rejection event 506 is triggered when a local PIN code check is used and the client exceeds the maximum number of attempts to enter the PIN code.

An example embodiment of a bearer entity 278 is shown in FIG. 50. The bearer device object 278 provides an interface image to the bearer device and includes a dispensing method 510, a pre-issuing method 512, and a storing method 514. As the names of the methods suggest, the dispensing method 510 delivers the medium to the client, the preservation method 514 saves the media that is not taken by the client, and the pre-dispensing method 512 performs the steps that are preliminary to issuing by moving the medium inside directly to the output slot of the bearer device so that the medium was prepared to become accessible to the client.

Bearer entity 278 includes an asynchronous media take event 516 and synchronous operation events 518. A media take event is triggered when a client takes media from a bearer device.

51 schematically represents the methods and events of an example of an object 282 of a printer. The printer object 282 provides an interface to the printer for printing receipts and includes the following methods: buffer adding method 520, dispensing method 522, printing method 524, buffer printing method 526, file printing method 528, print URL method 530, and save method 532 . These printing methods provide many methods for printing information on receipts. For example, buffer add method 520 is used to add characters to the buffer of a printing device. Next, the buffer printing method 526 is called to force the printer device to print the contents of the buffer. The print method 524, the file print method 528, and the print URL method 530 are used to print the contents of a specified line, file or HTML page, respectively.

In addition to operation events 518, an example of a print object 282 includes an asynchronous form taking event 534. This event is triggered when a client takes a printed form from a printing device.

An example of an embodiment of synchronization object 284 is shown in FIG. The synchronization object provides synchronization between tasks. For example, the developer of the terminal control unit may want to issue cash and print the receipt of receipt at the same time. However, the developer may want to wait for both tasks to complete before continuing. This is accomplished by connecting the events of the operation of the cash dispensing object 270 and the printer object 282 with the methods in the synchronization object. In this case, the events of the operation of the object 270 of the cash dispenser and the object 282 of the printer are associated with the method 542 sync0 and method 544 sync1, respectively. The synchronization object 284 serves to trigger one or more of the fifteen exit events, depending on when and how the synchronization methods are called. Both method 542 sync0 and method 544 sync1 take arguments representing the parameters of an event that is successful, which failed, which is not available, or which is not supported.

Synchronization object 284 also includes two synchronization timers that are started by trigger method 540. These synchronization timers count the elapsed time in seconds specified in the timeout property sync0 550 and the timeout property 552 sync1. If the synchronization timer expires, the synchronization timer enables the corresponding synchronization method with the parameter that the event has failed. If the synchronization method is called before the corresponding synchronization timer expires, the synchronization timer is reset.

An example of a synchronization object 284 includes a “how to expect” property that defines a combination of synchronization methods that the synchronization object expects to occur. Examples include those where the synchronization object 284 is waiting for a call to the sync0 method, waiting for a call to the sync1 method, waiting for method calls to both sync0 and sync1, and waiting for a call to either sync0 or sync1.

In the example embodiment, there are 16 synchronization result properties 548 that control how the calls of synchronization methods 542 and 544 are logically connected to generate exit events. Each of the 16 synchronization properties corresponds to one of 16 output events 546. The developer can combine these exit events with the methods of various other AKM objects, depending on the required flow of transaction logic. Output events 546 are triggered in response to the corresponding properties 548 of the synchronization result. For example, a developer may set the synchronization result result01 property to a value that represents the presence of a successful parameter used in method calls and sync0 and sync1. If both sync0 and sync1 methods are called with successful parameters, then the synchronization object will raise the exit1 event. If one or both of the sync0 and sync1 methods are called with a failure parameter, then the exit1 event will not be raised.

In an exemplary embodiment, the properties of the result can be set to a plurality of different values representing sync1 and sycn0 called with various combinations of parameters. Thus, multiple exit events can be configured that are called with various combinations of successful or unsuccessful calls to the sync0 and sync1 methods.

Fig. 53 schematically represents an example embodiment of a transaction data object 286. Transaction object 286 provides a container for specific transaction data, such as specific customer account information. Other AKM objects may access or set values in the transaction data object 286 by establishing a connection with or from transaction property values of the transaction data object. Transaction data object 286 is typically used by authorization object 260. For example, a variant of transaction data object 286 is provided as a parameter to authorization method 320 from authorization object 260.

An example of a transaction data object 286 includes two account objects to support transactions that require more than one account, such as transfer transactions. One of these account objects is used to store the data of the source account. The second of these account objects is used to store destination account data. In an example embodiment, these account objects are called from object 562 "from account" and from object 564 "to account", respectively. Each of these account objects stores information regarding the account, such as the account number, the established financial identifier (ID) and the address, name and address of the card holder, available balance of the current account, account type, last modification date, and any other information that is useful to identify the account.

In an example embodiment, which is used to communicate with the host computer via messages in 91X format, the interface 91x uses the transaction data object 286 when processing authorization requests. Interface 91x receives properties when generating a request to the host computer and sets properties when processing the response to the host computer. In an example embodiment, the transaction data object also includes common transaction properties 560 that are accessed using the 91x interface. Examples of these properties include the human language of the account holder, type of account, type of current transaction, error status message, transaction status and user codes, status severity, amount of available current account balance, bank ID and whether there is an additional tax.

The objects described here, as well as the methods and events associated with them, are given as examples. Other embodiments of the invention may include other or different objects to achieve the desired properties of the invention.

Many AKMs include devices that support transactions, with the ability to perform similar functions. For example, AKM may include both a printer for printing bank statements and a printer for printing receipts. A printer for printing bank statements is usually used to print a listed list of financial transactions over a period of time. A receipt printer is commonly used to print a record of the most recent transactions. Both devices serve for the formation and delivery of printed materials to the client. When one of the devices does not work, the AKM may prohibit one or more transaction actions that correspond to the device. For example, if the printer runs out of paper for printing bank statements, AKM may detect a problem and deactivate the printing of bank statements to customers. If paper is jammed in the receipt printer, the AKM can deactivate the entire AKM until the receipt printer is restored. Unfortunately, in any of these cases, customers will be annoyed by these problems, and the owner of AKM may lose the revenue associated with transaction fees.

An alternative example of an embodiment of the present invention is to reduce the number of cases that an AKM exits from service due to inoperative devices, taking advantage of the “overlapping” functionality between similar transaction processing devices in the AKM. For example, if the printer for printing receipts has jammed the paper or it runs out of paper, an example of an AKM embodiment is quickly programmed to use the printer to print bank statements in order to generate and issue both bank statements and customer checks. Thus, the printer for printing receipts can be used as a device for “neutralizing” printer malfunctions for printing statements of accounts, and the printer for printing statements in bills can be used as a device for “neutralizing” printer malfunctions for printing receipts. Although the printer for printing bank statements and the printer for printing receipts can use different document sizes, the AKM, which serves as an example, is operatively programmed to use different formats for printing information depending on the characteristics of the printer.

Other devices with overlapping functionality can be used in the same way. For example, AKM may include a cash dispenser and a coin storage and distribution module. If the cash dispenser does not work after completing ten dollars payment, the module for storing and issuing coins can be used to issue dollar coins until these ten dollars payment are replenished.

Fig. 56 is a schematic diagram of a programming architecture that serves to achieve these "neutralize" malfunctions as an example. Here, the AKM 700 includes a terminal control unit 710 consisting of a plurality of AKM objects 712, such as those described above. In an example embodiment, the AKM objects 712 correspond to JAVA sets (bin objects); however, in alternative examples of embodiments, other types of objects and classes may be used that correspond to the hardware and platform of the AKM application software, including Active X and COMM objects.

In addition to the methods of the AKM objects described above, each AKM object further includes a plurality of methods or functions related to the capabilities of the main devices 724 and 726. These methods include the presence method 714, the rule use method 716, and the select type method 718. The selection type method 718 serves to determine which type of device the AKM object is associated with. For example, the printer object is used for exchange with both printer 724 for printing receipts and printer 726 for printing bank statements. A selection type method 718 may be used to determine that a particular embodiment of the print AKM object corresponds to a receipt printer.

Presence method 714 determines if the desired device type is present in the AKM. This method enables the terminal application to independently configure for various types of transactions. For example, if presence method 714 returns a negative value for the printer to print bank statements, terminal functionality that corresponds to printing bank statements may be hidden from the client. Thus, examples of AKM objects serve to determine the capabilities of AKM objects and determine the configuration of AKM operation in response to certain capabilities.

In alternative embodiments of the present invention, methods may be used that include parameters for various types of features of the desired device or service. For example, a presence method or other capability method of a printer object may transmit a parameter that corresponds to color printing. If color ink is present, the printer object may be configured to print multicolor indication information. These example methods allow for a single universal type of AKM object, such as a printer object, to support many specialized devices, such as a receipt printer, a printer for printing invoices, thermal printers for printing receipts, a color printer, or any other printing device.

The rule use method 716 defines a set of rules for determining which device the AKM will use initially and which device will be used when the current or default device is inactive. An example embodiment of the present invention includes a data store 720 that serves to store a plurality of such rule sets 721 for each of the devices in the AKM. For example, a data store may include a default set of rules for a card reader object that determines that if there is only one card reader device, the card reader object will be automatically associated with it. If there is more than one printer device, a set of rules can be created and used by the printer object that determines that the printer for printing receipts is the default printer for printing receipts, and the printer for printing bank statements is the printer to cases when the printer device for printing receipts is not available.

In an example embodiment, a set of rules and associated devices 724 may be created and stored in the data store 720 using a configuration program 722 operably associated with the data store 720. Such a configuration program 722 also serves to store information which devices are currently installed in the AKM. The configuration program further serves to store in the data warehouse 720 certain features that are associated with each device. The results of the presence methods 714 can be determined by querying the data store 720 for the corresponding device type and / or device attribute.

In an alternative embodiment, when individual devices include self-configuration features such as Sun Microsystems JINI® and Microsoft Universal Plug and Play®, individual devices 724 themselves can serve to swap their features and / or corresponding service access modules in storage 720 data.

An example AKM 700 further includes a device interface layer 728. An example of a device interface level 728 may include multiple ODS (Open Device Services - “open” services for working with devices, ASMA). In addition, a device interface layer 728 may consist of one or more device API levels (application programming interface), such as a J / XFS kernel (Java / eXtensions for Financial Services) or WOSA / XFS administrator (Windows Open Services Architecture / extensions for Financial Services - an open architecture for accessing Windows-based services / extension for financial services). These components and device interface layers 728 serve to provide an interface between AKM objects 712 and associated hardware devices 724 and 726.

In one example embodiment of the present invention, the ASMA components and / or the XFS components (extension for financial services) are operatively programmed to provide an interface between AKM entities 712 and data storage 720 to determine which devices and device attributes are present in the AKM. The device interface level 728 further serves to process the rules in the data warehouse 720 to determine the default devices and the sequence of devices to "neutralize" the malfunction. In response to the information associated with the rules, existing devices and device capabilities stored in the data store 720, the device interface layer 728 serves to ensure that each AKM object 712 is associated with a device 724, which includes the corresponding capabilities required by the AKM object .

Fig. 57 depicts an example embodiment of AKM 740, which includes an interface layer of a device comprising an extended J / XFS core 742. The 742 J / XFS kernel includes a device type administrator 744. A device type manager 744 serves to exchange with a plurality of AKM objects 746 and create corresponding variants of objects 750 of the device control units in response to the rule sets selected by the AKM object. Rule sets are retrieved from data storage 748 in operational communication with the device type administrator. The device control units 750 serve to control the operation of the AKM devices 754 by exchanging with service devices 756 (i.e., device drivers) according to the J / XFS specification. Device control units 750 typically correspond to service devices. Messages between the device type manager 744 and the device control units 750 are queued by the command issuing servers 752 to the devices, which typically correspond to the device control units 750.

A device type manager 744 sends messages to the desired server 752 to issue commands to devices in response to rule sets in the data store 748. The device type manager 744 is also responsible for the set of rules for switching to the next appropriate server 752 to issue commands to the devices if the state of one of the current devices 754 becomes inoperative.

Fig. 58 depicts another example embodiment of the present invention. AKM objects 770 serve to control the operation of devices 772 by exchanging components 774 with the OSDM. The OSD components 774 are designed to ignore the differences between vendors ’conflicting implementations of service driver interfaces (i.e. device drivers) to use a consistent and uniform interface. In this described example of an embodiment of an ASMA, components 774 control the operation of devices 772 through exchange with WOSA / XFS level 776. Level 776 WOSA / XFS, in turn, communicates with devices 772 through the vendor-supplied interfaces of 778 service providers. In this described example of an embodiment of an ASMA, level 773 is expanded to include the above-described functionality of the device interface layer. Thus, examples of ASMA components 774 serve to communicate with data storage 779 to provide capability information to AKM facilities 770. The SALS components 774 also serve to process rule sets to determine which service provider interfaces and devices should be used initially and which should be used as a “mitigation” device when the default devices become inoperative.

59 shows another example embodiment of the present invention. Here, the device control unit 760 of the J / XFS level 761 serves to control the operation of the devices 762 by exchanging with the OSUR components 764. As described above, the OSMS components 764 control the operation of the devices 762 by exchanging with the WOSA / XFS administrator 766. The WOSA / XFS administrator communicates with 762 devices through the vendor-supplied interfaces of 778 service providers. For OURS components that consist of (software) components in C, C ++, COMM or other non-JAVA languages, this example embodiment includes placing a JNI (JAVA Native interface) wrapper around the OURS of 764 components to form J / XFS compatible modules 765 device maintenance. The device service modules 765 provide an interface for a JAVA-based J / XFS layer to communicate with the ASMA 764 components and a window-based administrator for the 766 WOSA / XFS.

The software used in the operation of the automated transaction machines of the present invention and associated computers can be downloaded from various types of objects to the corresponding computers. Such software may be included or downloaded from one or more objects, such as floppy disks or CDs. Such software can also be written to objects such as hard drives, magnetic tapes, or read-only memory devices. Other products, which include data representing instructions for working computers in the described manner, are suitable for operating transaction machines and systems in accordance with embodiments of the present invention.

Examples of embodiments of automated banking machines and systems have been described 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 according to the present invention solves the aforementioned stated problems, eliminates the difficulties encountered when using known devices and systems, solves problems and achieves the required results described above.

In the foregoing description, certain terms have been used for brevity, clarity, and understanding. However, no unnecessary restrictions should be implied as a result of their use, since such terms are for description purposes only and are intended to be broadly interpreted. In addition, descriptions and illustrations are given as examples, and the invention is not limited to the details shown and described.

In the following claims, any feature described as means for performing a function should be construed as encompassing any means known to those skilled in the art so that it can perform the specified function and will not be considered limited to the specific means shown in the foregoing description or their simple equivalents.

The features, disclosures and principles of the invention are described, the way in which it is created and used, and the advantages and useful results achieved; new and useful structures, devices, elements, structures, parts, combinations, systems, equipment, operations, procedures, processes and ratios are set forth in the appended claims.

Claims (119)

1. A method of providing output that uniquely corresponds to the object in which the user has an account for the user using an automated banking machine, comprising the steps of: a) determine, through the operation of the automated banking machine, data corresponding to the (economic) facility in which the client using the machine has an account, while the automated banking machine includes an automatic cash dispenser, b) access using the automated banking machine to the network address of the server that is associated with the object, in response to the definition of data, c) receive by means of an automated banking machine from the server at least one document in the markup language of documents, d) issue through the output device of the automated banking machine, at least one output data that uniquely corresponds to the object in which the client has an account, in response to a document in the markup language of documents received from the server. 2. The method according to claim 1, in which step (a) includes reading the indication information by the reading device in operative communication with the banking machine. 3. The method according to claim 2, in which step (a) includes reading information on the card using a card reader that is connected to an automated banking machine. 4. The method according to claim 3, in which step (d) includes issuing at least one visual output signal corresponding to the object through an output device. 5. The method according to claim 4, in which step (d) includes processing said at least one document through a browser running on a computer in operational communication with an automated banking machine. 6. The method according to claim 5, in which at step (b), at least one network address is determined in response to information indications read from the card in step (a). 7. The method according to claim 6, further comprising the step of: (e) issuing cash using an automated cash machine for dispensing cash. 8. A method for delivering documents corresponding to the object in which the user has an account to the user using an automated banking machine, comprising the steps of: a) reading card information from a card provided by a customer to an automated banking machine, the card indicating information including data (economic ) the object corresponding to the object in which the client has an account, b) retrieve the network address data by the banking machine in response to the object data and the data stored in data box, c) perform browser operations in the banking machine in response to extracting the network address data for accessing at least one network address in the network at which the network address being accessed corresponds to the address of the server adapted for delivering documents corresponding to the object in which the customer has an account. 9. The method of claim 8, in which the banking machine includes an output device and further comprises the steps of processing at least one document corresponding to an object in which the client has an account delivered from the server and issuing at least one output via an output device in response to at least one document. 10. The method according to claim 9, in which the output device includes a display and in which, at the output stage, the output includes visual output. 11. The method of claim 8, in which the automated banking machine includes at least one device for the operation of transactions, in which at least the first one of the documents includes at least one team, which serves to initiate the operation of the device for the operation of transactions, and further comprises the step of processing the first document using a browser and the operation of the device for the operation of transactions in response to at least one command in the first document. 12. The method of claim 8, further comprising the steps of: d) provide a plurality of servers, one for each of a plurality of objects in which a plurality of users of an automated banking machine have accounts, each server being in operational communication with a network and having a corresponding network address, each server being adapted to supply at least one document corresponding to the object with which it is associated, repeating steps (a) to (c) for each card submitted by the client to the automated banking machine, whereby each client card serves to force the browser to connect to the server, which includes at least one document corresponding to the object, in which customer has his own account. 13. The method according to item 12, in which the automated banking machine includes a display that is in operational communication with the browser, and in which documents include commands for creating at least one screen image that is uniquely associated with the corresponding object, and in which, in step (c), the browser, in response to commands in the documents, causes the display to form at least one screen image uniquely associated with the object in which the client has his own account. 14. The method of claim 8, in which the automated banking machine is used by an additional object, and further comprising stages: d) issuing a commission to the client’s account for a transaction using an automated banking machine used by an additional facility, e) the separation between the object and the additional object of at least part of the transaction fee. 15. The method of claim 8, further comprising the step of: d) accessing, using a browser, a plurality of documents from a server associated with the object in which the client has an account, e) accessing using a browser running in an automated banking machine, to at least one advertising document from an additional server used by the advertising object, f) the advertising document is processed using a browser to deliver advertising content through an output device that is in operational communication with the automation banked machine. 16. The method according to clause 15, in which the automated banking machine is used by an additional object, and further comprising the step of: g) paying for the additional object by the advertising object, whereby the additional object using the automated banking machine is compensated for the advertising object presenting the advertising content on the banking machine . 17. The method of claim 15, wherein step (e) is performed during step (d). 18. The method according to clause 15, in which at step (d), at least one document is accessed using the first browser running in a banking machine, and in which at step (e), at least one document are accessed using a second browser running in a banking machine. 19. An apparatus for delivering documents corresponding to one of a plurality of financial institutions to an automated banking machine containing a plurality of institution’s servers, each institution’s server being connected to one of a plurality of financial institutions, in which each institution’s server has at least one unique network the address and in which each server of the institution serves to supply at least one document associated with the respective institution, a network in operational communication with each m from the set of servers of the institution, at least one automated banking machine, in which the banking machine includes a computer having a browser running on it, a card reader and an output device in operative connection with a computer in which the automated banking machine performs operations in response to reading from the card information on the card with a card reader, which causes the browser to connect through the network to the network address of the institution’s server, with relevant information on the card. 20. The device according to claim 19, in which the browser serves to process at least one document from the institution’s server and issue output in response to the document through the output device on the bank machine. 21. The device according to claim 19, in which the browser serves to process at least one document from the server of the institution, in which the banking machine includes at least one device for the operation of transactions and in which the document includes, at least one command to enable the operation of the transaction functioning device, in which the transaction operation device is allowed to perform operations in response to the processing of the document by the browser. 22. The device according to item 21, in which the device for the operation of transactions includes an automatic machine for issuing sheet documents, in which the document includes at least one machine command for issuing sheet documents and in which an automatic machine for issuing sheet documents allow issuing at least one sheet document in response to processing by the browser of the document. 23. The device according to claim 19, in which the information indicating the card includes the BIN number (bank identification number), in which the automated banking machine serves to resolve the network address in response to receiving the BIN number. 24. The device according to claim 19, further comprising at least one ad server in operative communication with a network in which the ad server has at least one unique network address in which the ad server serves to provide at least one advertising document and in which the computer is programmed to force the browser to access the advertising document from the advertising server, in which the computer serves to output the advertising content through the output device in response to the advertising document. 25. The device according to paragraph 24, in which the automated banking machine includes at least one device for the operation of transactions in operative communication with a computer, in which the computer serves to force the browser to process at least , one document from the server of the institution, in which the document from the server of the institution includes commands of the device in which the computer is adapted to enable the device for the functioning of transactions to work in a response to device commands, and the computer is adapted to force advertising content to be output through the output device during operation of the transaction functioning device. 26. The device according A.25, in which the device for the operation of the transaction includes a device for issuing banknotes and in which advertising content is displayed during operation of the device for issuing banknotes. 27. The device according to paragraph 24, in which the computer includes a first browser and a second browser running on it, and the computer uses the first browser to access the server of the institution, and the second browser to access the ad server. 28. A transaction processing device for users using an automated banking machine with a transaction functioning device, comprising an automated banking machine, wherein the automated banking machine includes a computer, at least one device for performing transaction functioning in operative communication with a computer, a plurality of browsers operating in a computer in which the computer serves to force the device to perform functions ation transactions operate in response to commands from the at least one document is treated, at least one of the browsers. 29. The device according to p. 28, in which the automated banking machine further comprises at least one output device that is in operational communication with the computer, and documents processed by at least two browsers generate output data issued simultaneously through output device. 30. The device according to clause 29, in which the output device includes a display and in which each of these two browsers displays data on separate parts of the display. 31. The device according to p, in which the device for the operation of transactions is used in response to documents processed by many browsers. 32. The device according to p. 28, in which the automated banking machine includes a card reader that is in operational communication with the computer, and the computer serves to include card data read by the card reader into the transaction data object, and commands in documents processed by multiple browsers serve to access card data from a transaction data object. 33. The device according to p. 28, further comprising a network in which the computer of the automated banking machine is in operational communication with the network, a plurality of servers in operational communication with the network, in which the first server serves to deliver the first documents, and the second the server serves to supply second documents, the first browser running in the banking machine serves to process the first documents from the first server, and the second browser running in the banking machine serves to You can process second documents from the second server. 34. The device according to p. 33, in which the automated banking machine includes a display device in operative communication with a computer, in which at least one of the first and second browsers is used to display the output data through the display device . 35. The device according to p. 33, in which at least one of the browsers is used to generate an invisible output, in which the invisible output serves to force the computer to control the operation of at least one support device functioning of transactions in a banking machine. 36. The device according to clause 34, in which at least one of the first documents includes at least one image command and the computer is used in order to provide additional visible output in response to the display command to the second browser through the display device. 37. The device according to clause 36, in which at least one of the first documents includes at least one command to set the size and the computer operates in response to the command to set the size to set the size of the additional visible output. 38. The device according to p, in which at least one document includes an HTML document. 39. A method of delivering output data and executing transactions with an automated banking machine, which includes a plurality of browsers, comprising the steps of: providing the operation of a plurality of browsers in a computer in operative communication with an automated banking machine; the response to at least one document processed by at least one of the browsers provides output through at least one output triple in conjunction with an automated banking machine in response to documents processed by at least two of the browsers. 40. The method according to § 39, in which the automated banking machine includes a display device and in step (c) the output from at least two browsers are output through the display device. 41. The method according to § 39, in which at least one document includes a display command and before step (c) further comprises the step of reading the display command using a browser, and in step (c) the output in response to the second the browser is sent in response to reading a display command. 42. The method according to § 39, in which at least one document includes a size command, and further comprising the step of reading a size command using a browser, in which, in step (c), the output is in response to a second browser form by having a size in response to a size command. 43. The method of claim 40, wherein in step (c), the size of at least one output from the browser is determined in response to other output. 44. The method according to § 39, in which, in step (b), a device for executing transactions is used in response to documents processed by multiple browsers. 45. The method according to § 39, in which the automated banking machine includes a display device and in step (a), at least five browsers are used in the machine, in step (c) the output data corresponding to the documents processed by each of these five browsers are issued through a display device. 46. The method according to § 39, in which at the stage of issuance, at least one output is sent through at least one output device, in response to at least one HTML document processed at least one of the browsers. 47. A method of programming commands in a visual manner, which is used to instruct AKM to perform a financial transaction, comprising the steps of: a) forcing the first computer to issue the first graphic symbol (icon) and second graphic symbol to the visual workspace provided by the display device of the first computer moreover, the first graphic symbol corresponds to the first AKM object, and the second graphic symbol corresponds to the second AKM object, b) force the first computer to create at least one the connection between the first and second AKM objects, visually representing at least one connection between the first and second graphic symbols in the workspace, c) force the first computer to create program commands that represent the at least one connection created in step b ) d) carry out, using the second AKM computer, a financial transaction that must be executed in response to the program commands created in step c), and this financial transaction includes the operation of at least one AKM transaction functioning device. 48. The method according to clause 47, in which the second AKM object is associated with at least one AKM transaction functioning device. 49. The method of claim 48, wherein said at least one transaction functioning device includes a cash dispenser, the second AKM object being connected to said cash dispenser, wherein, in step (d), the machine for cash dispensing, performs cash dispensing. 50. The method of claim 47, wherein in step (b), creating a link includes providing a visible line between the first and second graphic symbols. 51. The method according to clause 47, in which, in step (b), the created connection corresponds to connecting a program event of the first AKM object with the program functions of the second AKM object, wherein the program event of the first AKM object is triggered in response to the operation of the second computer, while executing the program function through a second computer, it executes at least a portion of the financial transaction. 52. The method of claim 51, wherein step (b) includes providing a visual presentation of the connection that visually indicates, by the display device of the first computer, which of the first and second graphic symbols is associated with a program event and which of the first and second graphic symbols associated with a software function. 53. The method according to § 51, in which step (d) comprises the steps of: e) initiating a program event of a first AKM object through an operation of a second computer, and f) in response to step e) and at least one communication represented in program instructions , cause the execution of the program function of the second object of the AKM through the operation of the second computer. 54. The method of claim 53, wherein, in step (f), the program function of the second AKM entity forces said at least one transaction operation device to work. 55. The method according to item 54, in which the device for the operation of transactions includes the device of the machine for issuing cash. 56. The method according to item 55, in which the second object AKM corresponds to the object AKM issuance and at step (f) the work includes the issuance of the amount of cash using the device of the machine for issuing cash. 57. The method according to item 54, in which the device for ensuring the functioning of transactions includes a card reader. 58. The method according to paragraph 53, further comprising, before performing step (c), the steps of: g) force the first computer to issue a third graphic symbol to the workspace in which the third graphic symbol corresponds to the third AKM object, h) force the first computer to create at least one second connection between the second AKM object and the third AKM object by visual representation of at least one the second relationship between the second and third graphic characters in the workspace. 59. The method according to § 58, in which the third AKM object includes at least one value, in which, in step (h), the second created connection corresponds to connecting the value with a program function, in which, in step (f), the program function the second AKM object forces the AKM to execute at least a portion of the financial transaction in response to the value. 60. The method according to § 59, in which the third AKM object corresponds to the transaction data AKM object, in which the transaction data AKM object stores a plurality of transaction data values that correspond to a financial transaction running in the AKM, wherein, in step (f), the software the function of the second AKM object forces the AKM to execute at least a portion of the financial transaction in response to at least one of the values of the transaction data. 61. The method of claim 60, wherein the transaction data values include an account number associated with a financial transaction. 62. The method of claim 61, wherein the second AKM object corresponds to the authorization AKM object, in which, in step (f), the program function of the authorization AKM object forces the second computer to send an authorization message to the host computer system, in which the authorization message includes a data value permissions that correspond to at least one of the values of the transaction data. 63. The method according to § 59, in which the third AKM object corresponds to the client profile AKM object, in which the client profile AKM object stores a plurality of client profile data values that correspond to the AKM user, and in step (f), the program function of the client profile AKM object forces AKM perform at least part of a financial transaction in response to at least one of the values of the client profile data. 64. The method according to item 63, in which the client profile AKM object extracts the values of the client profile data from the data storage device, which is in operative connection with the AKM. 65. The method according to § 59, in which the second AKM object is a logical AKM object, in which, in step (f), the program function forces the second computer to perform a logical comparison between at least two parameter values, in which one of the two values the parameter corresponds to the value of the third AKM object, in which the method further comprises i) initiating a program event of the AKM logical object by the operation of the second computer, and when the result of the logical comparison is true, the ruetsya software true event of the second ATM object, and if the comparison result is false, false software initiated event second ATM object. 66. The method of claim 59, wherein the second AKM object corresponds to the printer AKM object and, in step (f), the software function of the printer AKM object causes the AKM printer device to print indication information in response to the value of the third AKM object. 67. The method according to p, in which the information information includes the value of the third object of the AKM. 68. The method according to § 59, in which the second AKM object corresponds to the state and command AKM object, in which, in step (f), the program function of the state and command AKM object forces the second computer to send a message to the host computer system, in which the message includes value of the third AKM object. 69. The method of claim 53, further comprising, prior to step (f), step: g) causing the first computer to create second program instructions that represent communications visually represented in the second workspace, in which the second AKM object corresponds to the first hidden control AKM object, and in step (f), the program function of the first covert control AKM object forces the second computer to attempt to load the second program instructions. 70. The method according to p, in which the second workspace includes a second hidden control AKM object and the method further comprises: h) initiating a software event of loading the second hidden control AKM object by the control unit by the operation of the second computer. 71. The method according to item 70, in which, in step (f), the program function of the first hidden control AKM object further forces the second computer to try to load the web page into the browser. 72. The method of claim 71, wherein if the second computer either cannot load the second program instructions or cannot load the web page, the step further comprises: i) initiating a program event of a failure of the navigation control unit of the first hidden control AKM by the operation of the second a computer. 73. The method according to item 70, in which the second hidden control AKM object includes a timeout value, in which after the second computer successfully loads the second program instructions, and a period of time that is longer than the timeout value expires, additionally contains the step: i) initiate a program event for the expiration of the latency of the screen image of the second object AKM hidden control through the operation of the second computer. 74. The method according to item 53, in which the first object AKM corresponds to the object AKM hidden control, in which at step (e) the program event of the object AKM hidden control is initiated by the browser using a second computer. 75. The method of claim 74, further comprising, prior to step (e), step: (g) initiating a program event of loading an HTML web page into a browser by an operation of a second computer, in which, at step (e), a program event of a hidden control object AKM is triggered in response to HTML program event. 76. The method of claim 75, wherein the HTML program event is generated by a second computer in response to a user clicking a button on a web page. 77. The method according to item 53, in which the second AKM object corresponds to the hidden control AKM object, in which, in step (f), the program function of the hidden control AKM object forces the second computer to load web pages into a browser running on the second computer. 78. The method of claim 58, wherein in step (h), the second created connection corresponds to connecting a program event of a third AKM object to a second program function of a second AKM object. 79. The method of claim 78, further comprising, prior to step (c), the steps of: i) causing the first computer to issue a fourth graphic symbol in the workspace in which the fourth graphic symbol corresponds to the fourth AKM object, and j) forcing the first computer to create a third connection between the second AKM object and the fourth AKM object, visually representing the third connection between the second and fourth graphic symbols in the workspace, and in which the third created connection corresponds to the connection of the program event of the second object KM with a software function of the fourth ATM object. 80. The method according to p, in which the second AKM object corresponds to the synchronization AKM object, in which the second AKM object includes at least one synchronization timer and at least one synchronization timeout property, in which the method further contains the stage: k) start the timer of the AKM synchronization object in response to the first communication and step e). 81. The method of claim 80, further comprising the steps of: l) initiating, by the operation of the second computer, the program event of the third AKM object in the period of time before the synchronization timer reaches the timeout value, m) causing the execution of the second program function of the object by the operation of the second computer; The synchronization AKM in response to the second connection and step 1), n) initiate a program event of the second AKM object through the operation of the second computer, and the event of the second AKM object corresponds to one of many of the events of synchronization events, o) cause the execution of the program function of the fourth AKM object through the operation of the second computer in response to the third connection and step n). 82. The method of claim 80, further comprising the steps of: l) reaching a timeout value by the synchronization timer before the program event of the third AKM object is triggered, m) initiating the program event of the synchronization AKM object by the operation of the second computer, the program event of the AKM object synchronization corresponds to one of the many software synchronization events, n) cause the execution of the program function of the fourth AKM object through the operation of the second computer in response to the third s and step m). 83. The method of claim 82, wherein in step (n), the program function of the fourth AKM entity causes the operation to be performed by at least one device to enable transactions to function. 84. The method according to p, in which at least one device for the operation of transactions includes the device of the machine for issuing cash, the first, third and fourth objects of the AKM correspond to the object of the AKM of the machine for issuing cash, and a software event the first AKM object is triggered by the issuing of the amount of cash by the cash dispenser device, the program event of the third AKM object is triggered by the user taking the amount of cash from the machine and dispensing of cash, wherein in step n) the software function of the fourth ATM object causes automatic device for securing cash dispensers previously issued amounts of cash automatic device for dispensing cash. 85. A computer-readable recording medium containing instructions that implement the steps of the method listed in clause 47. 86. A method of displaying on a automated banking machine a web page that is generated using a user profile, comprising the steps of: a) read customer identification information with a reader in operational communication with an automated banking machine, b) access at least one client profile value from at least one data store in response to client identification information, c) form at least one web page in response to at least , one client profile value, and d) display at least one web page in the machine through the operation of the browser. 87. The method of claim 86, further comprising the steps of: e) receiving input from an operator of the automated banking machine, and f) modifying at least one client profile value in the data warehouse in response to the entered data. 88. The method of claim 87, wherein the data warehouse includes a remote database. 89. The method according to p, in which the data warehouse includes a smart card. 90. The method of claim 87, wherein in step (a), the reader includes a card reader and client identification information is read from the card. 91. The method according to p, in which the value of the client profile represents the preferred natural language of the client, in which the web page is formed in a language that corresponds to the value in which the entered data represents an excellent value for the preferred natural language of the client. 92. The method according to p, in which the value of the client profile represents the amount of quick payment, in which the web page includes a selectable option, which corresponds to the issuance by the automated banking machine of the amount of cash equal to the amount of quick payment, in which step (f) includes modification of the amount of quick payment. 93. A computer-readable recording medium containing instructions that implement the steps of the method of claim 86. 94. A method of performing transactions with an automated banking machine using the user profile that is accessed, comprising the steps of: a) reading the account number from the card with a card reader of the automated banking machine, b) accessing the set of client profile values that correspond to the number accounts, c) display web pages in a browser using an automated banking machine, in which the web page includes many selectable options for performing a trans computer automated banking machine, in which at least one of the selected options is carried out in response to at least one of the profile values of the client that is being contacted, d) receive input data that correspond to the selected option using the device data entry, e) carry out transactions by the automated banking machine in response to the selected options. 95. The method according to clause 94, further comprising the step of: f) modifying at least one of the client profile values that were accessed in the data store in response to the selected option. 96. The method according to p. 95, in which the client profile values include the last withdrawn amount representing the previously withdrawn amount of cash, in which one of the selected choices corresponds to the issuance of cash amount equal to the last withdrawn amount, in which step (e) includes dispensing the selected amount of cash with a cash dispenser device, and in which step (f) includes changing the last withdrawn amount to a value that corresponds to the selected amount of cash. 97. A computer-readable recording medium containing instructions that implement the steps of the method listed in clause 94. 98. A method of displaying on a automated banking machine a web page that is downloaded using a client profile, comprising the steps of: a) receiving at least one client identification value by an automated banking machine, b) accessing a client profile from a data warehouse in which the client profile corresponds to the client identification value, in which the client profile includes the client type value, c) display the web page in the browser of the automated banking machine, in which the web page is loaded they get stung in response to the value of the client type. 99. The method according to p, in which, when the type of client corresponds to the maintenance personnel of automated banking machines, the web page includes a variety of options selected by maintenance personnel for servicing an automated banking machine. 100. The method of claim 99, wherein when the client type corresponds to the client, the web page includes a plurality of selectable transaction options for performing transactions by an automated banking machine. 101. The method of claim 100, further comprising the steps of: d) receiving input data that correspond to one of the transaction options selected, e) issuing the amount of cash with a cash dispenser device in response to data input. 102. The method of claim 98, wherein the web page includes a plurality of selectable transaction options for performing transactions by an automated banking machine, and wherein the method further comprises the step of: d) receiving input data that corresponds to one of the select transaction options, and e ) modify client profile data in response to data entry. 103. The method according to p, in which, when the type of client corresponds to the first type of client, the web page includes a first option to perform the first transaction by an automated banking machine, in which, when the type of client corresponds to the second type of client, the web page does not include the first option. 104. The method according to p, in which the first transaction corresponds to the payment of the bill. 105. A computer-readable recording medium containing instructions that implement the steps of the method listed in clause 98. 106. A method of displaying an advertisement on an automated banking machine on a web page that is selected using a client profile, comprising the steps of: a) accepting a client identity value associated with a client using AKM, b) accessing a client profile in response to a client identity value , c) select targeted advertising in response to the client profile, and d) display the web page in the AKM browser, in which the web page includes targeted advertising. 107. The method of claim 106, further comprising, prior to performing step (c), step: e) determining whether the client is a client associated with a financial institution, in which, if it is determined that the client is not a client of a financial institution, targeted advertising includes self promotion for a financial institution. 108. The method according to p, in which targeted advertising includes at least one selectable option, in which the method further comprises the steps of: (e) receiving input from a client that corresponds to the selected option, and (f) modify customer profile in response to the entered data. 109. A computer-readable recording medium containing instructions that implement the steps of the method listed in paragraph 106. 110. A method for selecting and using one of a plurality of transaction functioning devices for executing a transaction from an automated banking machine, comprising the steps of: a) storing a plurality of rules for an automated banking machine, in which the rules correspond to at least one sequence for using a plurality of functional devices transactions that are in operational communication with an automated banking machine, and each of the functional devices osu estvleniya transactions capable of performing substantially equivalent to the first transaction function, b) selecting a first transaction of the functional unit in response to the first rule, c) perform a first function of performing the first transaction function device of the transaction. 111. The method of claim 110, further comprising the steps of: d) determining that the first functional transaction processing device is not available, e) selecting the second functional transaction processing device in response to the first rule, f) performing the first transaction processing function by the second functional transaction processing device . 112. The method according to p. 111, in which both the first and second functional transaction processing devices include printer devices, in which the first transaction processing function includes printing checks. 113. The method according to p. 111, in which the first functional transaction processing device corresponds to a printer for printing checks and the second functional transaction processing device corresponds to a printer for printing account statements. 114. The method of claim 110, further comprising, before performing step (b), step: d) a first rule is selected in response to an event that serves to force the machine to perform the first transaction execution function. 115. The method of claim 110, further comprising the step of: d) a plurality of opportunity values are stored, which are features of the functional transaction devices, in which, in step (b), the first functional transaction device is further selected in response to the opportunity values. 116. The method of claim 110, further comprising the step of: d) determining at least one capability of the first functional transaction device, and in which, in step (c), the first functional transaction processing device is further selected in response to said capability. 117. The method of claim 110, further comprising the step of: d) determining at least one first opportunity of the functional transaction devices, in which, in step (b), the first functional transaction device is further selected in response to the first opportunity, e) determining that the functional transaction processing device is not available to perform the first transaction processing function, f) determining at least one second capability of the transaction processing functional devices, g) selecting a second transactional functional unit is provided in response to the first rule and said second opportunity, and h) perform the first transactional function as a second transactional functional unit. 118. The method according to p. 117, in which the first possibility corresponds to the printing of information indications in the form of a multicolor image, in which the second opportunity corresponds to the printing information indications, at least in one color. 119. A computer-readable recording medium containing instructions that implement the steps of the method listed in paragraph 110. Priority according to claims 1-46 - 07/20/1999. Priority according to claims 47-119 - 08.19.1999.

Images