RU2183862C2 - Device having automatic apparatus and method for making financial operations - Google Patents

Abstract

FIELD: financial engineering. SUBSTANCE: method involves making financial operations by responding to hypertext denoting language documents and Internet data transmission management protocol. Bank device has computer having node for processing hypertext denoting language documents that makes communication through a representative server to the own server of ППГT hypertext in internal network or to foreign servers in global area network The computer also has special purpose hardware node for carrying out interconnection with a node for processing hypertext-denoting language documents and dispatching messages for starting devices in the automatic bank apparatus. The devices have mechanism for giving out sheets that gives out cash money and other devices for carrying out financial operations. EFFECT: enhanced effectiveness and reliability in carrying out financial operations. 22 cl, 31 dwg

Description

 The invention relates to automatic banking machines. Specifically, this invention relates to an automatic banking apparatus device and system that can be used in a wide coverage network that provides the user with an interface known to him that connects his own institution to third-party banking apparatuses, and which provides a larger number of operational options for the apparatus outputs.

 Automatic banking machines (ATMs) are well known. A common type of automatic banking machine used by customers is ATMs (BMs). BMs provide customers with the opportunity to conduct banking financial transactions. Common banking financial transactions that can be performed using BM include the issuance of cash (banknote sheets), making deposits, transferring funds between accounts, paying bills and requests for funds on the account. The type of banking financial transactions performed by a client is determined by the capabilities of a particular banking machine and programming in the institution that works with this device. Other types of automated banking machines may provide customers with the opportunity to make accruals to accounts or transfer money. Other types of automated banking machines can print or issue securities such as coupons, tickets, bets, checks, checks, food coupons, payment orders, temporary receipts or traveller's checks. In the context of this description, an automatic banking machine or an automatic financial transaction apparatus includes any device that carries out financial transactions, including the transfer of amounts.

 Currently, BMs operate in private communication networks. These networks connect BM working in financial institutions and other legal entities. This interconnection of networks often allows the user to use a bank machine operating in another institution if the bank device of a third-party institution is connected to a network that includes the institution of this user. But if the client works with the device of a third-party institution, he must work with the machine using the user interface created by this third-party institution for his bank devices. In addition, the client is limited to the range of operations provided by this third-party institution.

 When using the device of a third-party institution, the client may encounter some difficulties. Difficulties may arise because the user is not familiar with the type of machine with which the third-party institution works. Errors can occur because the user does not know which buttons or other mechanisms need to be activated in order to carry out the necessary operations. The procedure for performing financial transactions for a given client in the device of a third-party institution may differ significantly from the devices that operate in the user's own institution. This circumstance can become a problem when the user is in another country and is not familiar with the type of banking machine or with the interface language established by this third-party institution. Similarly, documents that are printed by printers of an automatic banking machine are generally limited to a limited group of specific formats in one language.

 A third-party institution may also provide various types of operations that are known to the user in his own institution. For example, the user's own institution can transfer funds between accounts using their automatic banking machines to enable the user to keep funds on accounts with a higher percentage for the necessary periods of time. If the third-party institution does not provide such an opportunity, the user will not be able to do this when working with a third-party device. The inability of a user working with a third-party device to carry out the operations to which he is used can lead to problems.

 Networks working with BM and other types of automated banking machines usually operate in private networks, access to which is limited. This is necessary to prevent fraud or illegal attempts to penetrate the network or into user accounts. Private networks are also commonly used to send credit card messages and other financial transaction messages. Access to these credit card processing systems is also limited mainly for security reasons.

 Communication between wide area networks makes it possible to transfer messages between locations that are remote from each other. The most widely known wide-area network is the Internet, which can be used to provide communication between computers around the world. The Internet is not widely used for reporting financial transactions because it is not a secure network. Messages intended to be received at a specific computer address can be intercepted quietly at other addresses. Since messages can be intercepted at locations that are far from the destination country, there is a potential for fraud.

 Some companies are starting to provide technical solutions for more secure messaging over the Internet. For Internet communications, encryption methods are also used. But the openness of the Internet has limited its usefulness for financial communications, in particular 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 PDAP / PI (TCP / IP). US Pat. No. 5,706,422 provides an example of a system in which financial information stored in databases is accessed through a private, wide-area network using PDPM / PI messages. Messages transmitted in networks that use the PDPD / PI can contain “documents” (so-called “pages”). These documents are written in the YOGT Hypertext Designation Language (HTML), which is a designation of the type of programming language used to compose documents that contain commands or "shortcuts". Labels are codes that define characteristics and / or operations of a document, such as fonts, layout, embedded graphics, or hypertext links. AOGT documents are processed and read using a computer program called a "browser" - an accelerated file viewing program. The shortcuts “tell” the browser how to process and manage what is visible on the screen and / or heard in the speakers connected to the computer that controls the browser when processing the document. AOGT documents can be transmitted over the network using the Hypertext Transfer Protocol (GPT) (HTTP). The term "hypertext" is a designation of the ability to embed links in the text of a document, which provide the ability to communicate with other documents that can be accessed on the network during processing.

 Therefore, there is a need to provide an automatic banking apparatus and system that can be used on a wide coverage network, such as the Internet, and at the same time provide a high level of security. There is also a need to provide an automatic banking apparatus and systems that provide the user with a familiar interface and an assortment of financial transactions of his own institution when working with third-party apparatuses. There is also a need to provide an apparatus that can provide a wider range of financial transactions and types of advertising and print material for users.

 The object of this invention is to provide an automatic banking machine, with which the user can carry out financial transactions.

 Another object of this invention is to provide an automatic banking machine, which can be operated by connecting to a wide network.

 Another object of this invention is to provide an automatic banking apparatus and systems that provide the user with a familiar interface and an assortment of financial transactions of his own institution on devices with which third-party institutions work.

 Another object of this invention is to provide an automatic banking machine that communicates using AOGT documents and PUPD / PI messages.

 Another object of this invention is to provide an automatic banking machine, which enables the banking machine to be connected to the user's own institution through YAGT documents and PUPD / PI messages created in response to signs on a card entered by the user.

 Another object of this invention is to provide an automatic banking apparatus and systems that carry out financial transactions over a wide coverage network, while ensuring a high level of security.

 Another object of this invention is to provide an automatic banking machine and systems that control the connection of the banking machine to third-party addresses through a representative server.

 Another object of this invention is to provide an automatic banking machine that restricts the operation of devices in the device using a local device server.

 Another object of this invention is to provide an automatic banking machine and systems that operate through an Internet connection.

 Another object of this invention is to provide an automatic banking machine that can be used to provide the user with a larger number of message types, including messages intended for specific users.

 Another object of this invention is to provide an automatic banking machine, which has the ability to provide users with a wide range of printed documents.

 Another object of this invention is to provide an automatic banking machine, which provides additional capabilities for identifying permitted users.

 Another object of this invention is to provide an automatic banking machine, which can be used in conjunction with existing systems for financial transactions, while providing increased functionality.

 Another object of this invention is to provide an automatic banking machine, which provides increased diagnostic and maintenance capabilities.

 Another object of this invention is to provide an automatic banking machine that carries out financial transactions at high speed.

 Another object of this invention is to provide improved systems that use automatic banking machines.

 Another object of the present invention is to provide improved methods of operation of automatic banking devices and systems.

 Other objects of the present invention will be apparent from the following description of best practices for carrying out the invention and from the appended claims.

 The above objects are carried out in a preferred embodiment of the present invention by means of an automatic banking apparatus that includes an output device, such as a display screen, and an input device, such as a touch screen or keyboard. The banking apparatus also includes devices such as a mechanism for issuing bills, a printing mechanism, a card reader / writer, a mechanism for receiving deposits and other devices that perform physical functions of financial transactions and which are used by the device to carry out financial transactions.

 The bank machine also contains a computer.

 The computer is operatively connected to the output devices and input devices located in the device, and also to the issuing mechanism, a card reader, and other physical devices that perform the function of financial transactions. The computer contains the software running in it. Computer programs contain a node for processing YAGT documents. The YAGT document processing unit sends and receives YAGT documents and messages of the OGTT. The AOGT document processing unit is preferably connected to an output device for displaying screen images containing hypertext communication indicators. The AOGT document processing unit is also preferably connected to an input device that enables the user to select and generate response messages from a computer. The YAGT document processing unit preferably operates in connection with the JAVA software tools and can execute commands in the JAVA text driver transmitted with the YAGT documents.

 The computer software means also preferably comprise a specialized hardware unit. A specialized hardware node contains software tools that control the mechanism for issuing sheets and other devices. In a preferred form of the present invention, a specialized hardware unit contains many specialized JAVA programs for operating devices in the apparatus.

 The computer of the automatic banking apparatus also contains a software interface node with devices. The software node of the interface with devices receives messages from a specialized hardware node and determines the operation of devices using appropriate hardware interfaces. In one preferred form of an automatic banking machine, a YOGT document processing unit, a specialized hardware unit, and a software interface unit with devices — all of them — are located in the same computer and communicate with each other on different PI ports.

 The automatic banking machine of the present invention in one of the configurations communicates using the message PUPD / PI in the internal network (Intranet), which contains a set of such devices. The internal network, in turn, is connected to at least one computer with which its own institution works. Own institution is an organization that works with banking machines.

 The computer of the third-party institution preferably contains its own server PGT, the server representative (authoritative server) and the server device. The representative server communicates via an internal network with a software node that processes the AOGT documents with each of the bank devices. The representative server is also configured to connect to a wide coverage network, such as the Internet, to which third-party servers are connected. The device server sends messages between the specialized hardware node and the software node of the device interface of bank devices. The device server may contain monitoring software that controls and selectively restricts the use and operation of devices in a bank machine. This provides some level of security.

 The automatic banking machine and system connect the user to the institution in which his accounts are located. This institution can be either its own institution that works with the banking machine and in which the user is located, or a third-party institution that is connected to a wide network. To work with a bank device, the user makes entries that correspond to a certain address, for example, the address of the EUP, using the address input device. The YAGT document processing unit connects the bank device to the server that corresponds to this address. This is preferably done by the user, on the card of which the reader in the bank machine reads characters representing the address, or it is carried out by an input device that identifies the user, or institution, or organization in which the user has accounts.

 The YAGT document processing unit responds to the address on the card or to other input data in order to connect to the user's institution through a representative server. If the address of the user's own institution corresponds to its own server, then the bank device will respond to messages from its own server. If the user address entered matches the address of the third-party server, then the representative server communicates over a wide network with a third-party server in the client’s own institution. If the client connects the device to the server with which the third-party institution works, then the AOGT documents sent from the third-party institution correspond to the documents that this third-party institution usually sends. As a result of this, the client will be aware of this interface produced by these documents, and it will be easier for him to work with this banking machine.

 A third-party server or its own server works with the bank device by sending YAGT documents that contain commands for operating the devices in the bank device. The commands are transferred from the document processing unit of the AOGT to a specialized hardware unit of software tools, which, in response to these commands, puts the devices into operation. Commands from a specialized hardware node to devices in an automatic banking machine are sent through the device server of their own institution. This helps maintain security. In addition, the representative server contains a “sorting” software tool that restricts third-party servers that can connect to and work with the bank device. This is called a "firewall."

 The implementation of the present invention also provides an increased number of user interfaces, and provide printing of a wide range of documents by a bank machine. This invention also provides enhanced functionality when using existing financial transaction networks and automated banking machines.

 Figure 1 is a schematic diagram of a network configuration containing an automatic banking machine and the system of the present invention.

 FIG. 2 is a schematic representation of a preferred embodiment of an automatic banking apparatus of the present invention.

 Figure 3 - 24 is a schematic illustration of an automatic banking machine, an internal network connecting the banking machine to the computer system of your own bank, and a wide network connecting the computer system of your own bank to a third-party bank.

 FIG. 3 - 18 is a schematic representation of the stages of a financial transaction performed by a bank machine using a computer system of its own bank.

 FIG. 19 - 24 is a schematic illustration of the stages of a financial transaction performed by a bank machine using a third-party bank computer system.

 FIG. 25 is a schematic diagram of a network configuration comprising an alternative embodiment of an automatic banking apparatus of the present invention.

 FIG. 26 is a schematic illustration of frames in the AOGT document processing unit of an alternative embodiment of the automatic banking apparatus of FIG. 25.

 Fig. 27 is a schematic illustration of a user interface of an automatic banking machine, and function keys and keys of an auxiliary keyboard included in an interface.

 FIG. 28 to 30 show a schematic illustration of examples of steps for converting inputs from function keys and keys of a secondary keyboard to inputs of a stream from a keyboard and a stream from a mouse.

 FIG. 31 is a schematic illustration of examples of steps for printing documents by an automatic banking machine.

 1, reference numeral 10 illustrates a network configuration that includes an automated banking machine and a system of one preferred embodiment of the present invention. The network 10 comprises a plurality of automatic banking machines 12, which in the preferred embodiment of the present invention are BM. BM 12 are connected to the computer system of their own bank 14. The computer system of their own bank 14 is a computer system that a bank or other institution operates with BM 12. The computer system of own bank 14 is connected to BM 12 through the internal network 16. Internal network 16 is preferably a local or private network that provides communication between the computer system 14 and the banking devices 12 using messages in the format of the Transmission Control Protocol / Inte protocol No (PUPD / PI).

 Messages that are transmitted over the internal network 16 are preferably PUPD / PI messages and AOGT documents. In one preferred embodiment of the present invention, the AOGT documents sent over the internal network 16 comprise embedded object-oriented programming commands, preferably in the JAVA format developed by Sun Microsystems. Messages sent through the internal network 16 can be sent in encrypted or unencrypted form, depending on the nature of the system and the security needs of your own bank.

 It should be borne in mind that implementations of the present invention may process other types of documents that contain labels or commands. For example, a form of "expanded" AOGT has recently been proposed that can be used in embodiments of the present invention. For the purposes of this invention, all forms of language and variants containing documents with commands are called YAGT documents.

 Although JAVA is used in the described embodiment, other programming languages can also be used. For example, you can use Microsoft Corporation. Active-X language, or in other implementations you can use other languages. You also need to keep in mind that the commands contained in the documents can determine the computer’s access to other documents, records or files at other addresses in order to receive a particular program to perform some operation.

 The home bank computer system 14 is also connected to the wide coverage network 18. In some implementations of the present invention, the wide coverage network 18 is the Internet. In other implementations of the present invention, other wide-area networks may be used. The wide area network preferably sends PDM / UI messages between multiple computer systems connected to the wide area network. These third-party computer systems are schematically represented by servers 20, 22, 24, 26, and 28. It must be borne in mind that other financial institutions around the world can work with servers 20 - 28, and these servers can connect to them. The servers 20 - 28 preferably work in the form of sending documents AOGT and other messages PGT.

 FIG. 2 is a schematic view of a BM 12 used in connection with one preferred embodiment of the present invention. BM 12 includes a touch screen 30. The touch screen 30 comprises 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 an input device for receiving input commands from a user. The touch screen 30 is connected via an interface 32 to a computer 34, which is preferably placed in the machine. Alternative implementations of the present invention may include other output devices, such as speakers.

 The computer 34 is also connected to a set of financial transaction function devices 36, which are also located in the BM 12. The devices 36 include, for example, a card reader / writer 38 and a keyboard 40. The devices 36 also include a sheet issuing mechanism 42 that provides sheets that in some preferred embodiments, may be currency or banknotes. Devices 36 also include storage 44 for receiving contributions to a secure location in the machine. The receipt printer 46, which issues receipts of a financial transaction to customers, is also among the devices 36. The magazine printer 48 is also among the devices and keeps, on paper, records of information about financial transactions. In other implementations, other or additional devices may use financial transaction functions that perform other financial transaction functions. Other implementations may include fewer financial transaction function devices. You also need to keep in mind that despite the fact that the described implementation of the present invention is an ATM, the principles of the invention can also be applied in many types of financial transaction apparatuses, which do not have to perform banking operations.

 Each of the devices is operatively connected to the internal control bus 50 in the bank apparatus 12. The control bus 50 outputs internal messages to certain devices. Each device has a corresponding hardware interface, which enables a particular device to perform its corresponding function when responding to messages that are transmitted to it via the control bus 50. The card reader / writer 38 has a hardware interface, shown schematically under designation 52. Hardware interfaces 54, 56 , 58, 60, and 62, respectively, connect a keyboard 40, a sheet delivery mechanism 42, a depository storage mechanism 44, a receipt printer mechanism 46, and a journal printer mechanism 48 with 50 th management.

 Computer 34 has several programs executed therein. In a preferred embodiment of the present invention, these programs comprise a program interface unit with devices 64. A program interface unit with devices 64 preferably comprises a program interface with devices 66 that communicates electronically with a control bus 50. The program interface unit with devices 64 preferably comprises a device control program 68 The device management program preferably manages different devices 36 and manages their various states for especheniya their proper operation in sequence. The device control program also preferably creates device objects in the software means to ensure the operation of the devices according to at least one object-oriented program 70. The device program interface node also comprises an object-oriented program node 70, which in one preferred embodiment is specialized and compiled in the JAVA language. Program 70 works in conjunction with the device management program and receives object-oriented JAVA messages that condition devices to transmit device operation messages indicating how the devices work and / or receive input data.

 The program interface node with devices 64 in the described embodiment acts through a computer 34 and communicates via a physical connection of the PDP / PI 72 to the internal network 16. The physical connection can be an analog code call, a serial port, a digital network connection with complex services, or another appropriate connection . In the illustrated system configuration, the program interface node with the devices 64 communicates at the PI address of the computer 34 and at the PI port or socket 74, which differs from other software application systems. In other implementations of the present invention, a software interface node with devices 64 may operate on another computer that is not software applications of the present invention.

 It should also be borne in mind that although in a preferred embodiment of the present invention, the interface unit with devices 64 is a software tool, in other implementations of the present invention all command steps, or parts thereof, performed by program unit 64 may be in hardware or in other media programs in connection with one computer, or with several that communicate with devices 36. For the purposes of this invention, all of these kinds of executable instructions are called software.

 Other software also operates on computer 34. It contains an AOGT document processing program, including a browser, shown schematically under 76. In a preferred embodiment of the present invention, AOGT document processing software comprises a browser developed by Netscape. But in other implementations, other AOGT document processing and communication software may be used, and browser-based software such as Sun Microsoft's Hot JAVA or Internet Explorer developed by Microsoft. Browser 76 communicates in computer 34 at the PI port indicated by 78.

 The browser 76 is operatively connected to the JAVA 80 software, which allows the computer 34 to work with JAVA language programs. JAVA language programs have the advantage that they work the same without modifications on different hardware. This "write once / work everywhere" ability makes the JAVA software well suited for the described embodiment of the present invention. But other implementations may use other types of software programs.

 The JAVA 80 software allows the computer 34 to execute commands in the JAVA text driver, shown schematically under the designation 82. The commands executed by the computer in the JAVA text driver are preferably built-in JAVA text driver commands included in the AOGT documents that are received through the browser 76. Browser 76 in conjunction with the JAVA 80 software, which executes commands in the built-in text driver JAVA 82, serves as a software node for processing YOGT documents for sending and receiving documents AOGT and messages ПУПД / ПИ through port ПИ 78.

 The computer 34 also has software running therein having a specialized hardware unit 84. The specialized hardware unit 84 contains executable instructions related to the operation of devices 36. In a preferred embodiment of the present invention, the specialized hardware unit consists of a plurality of specialized JAVA programs. In the described embodiment, the specialized programs are also preferably programs that control the status of their devices and which monitor this status. Certain specialized programs also preferably configure the browser for messaging. Certain specialized programs are responsible for security and identify BM users.

 In the described embodiment of the present invention, specialized JAVA programs are associated with functions such as activating a card reader, notifying the browser about entering user card data, controlling the operation of the receipt printer, the journal printer mechanism, activating the user keyboard and receiving data through the keyboard, storage management, moving to document addresses, device timing functions, digital signature verification, message encryption management eny, assortment management of banknotes issued from the sheet dispensing mechanisms of different types, the calculation of the exchange rate, and the completion of financial transactions and the issuance of the command to return to the browser due to its own server. Of course, in other implementations, other specialized programs may be used to control devices and use data to perform various necessary functions by the apparatus. Specialized hardware node 84 establishes a message with the computer 34 in the port PI 86.

 In the described embodiment of the present invention, specialized software hardware node 84 does not send its messages directly to the software node of the interface with devices 64. In accordance with the following description, this increases security. But it should be noted that the implementation of this invention may provide for the direct transmission of messages controlling the operation of devices from a specialized hardware node 84 directly to the program of the device 70. This can be done either using the PDP / PI by sending messages in the usual manner through a queue installed in the computer operating system which with this software that interfaces between devices, or through a direct call to this software cross section.

 From the above explanation it follows that certain specialized programs in the specialized hardware node 84 may correspond to devices that are not available in all ATMs. For example, an ATM, which works only as a cash withdrawal mechanism, does not contain a vault mechanism similar to vault 44. To account for the situation when a user requests a financial transaction that is physically impossible with BM 12, the program interface node with devices 64 can be programmed to providing an appropriate response message that will indicate that this function is missing.

 Or a software interface node with devices may contain a function that checks the presence or absence of each type of physical device in the BM. Information indicating the presence of devices in the BM can be part of the messages generated by the BM. For example, information indicating that the devices operating in the BM can be included as part of or several parts of the ESMA addresses to which messages are sent by the ATM. Thus, the ESMA in the server with which the BM is connected can be configured to provide only AOGT documents that correspond to the types of financial transactions performed by the ATM. As a result of this, the browser avoids displaying documents that contain links to types of financial transactions that the ATM cannot perform. For example, an ATM can avoid displaying a response to a document that contains a link to a financial transaction of a deposit if the ATM does not have a vault.

 Or, the ATM may contain in the storage device data characterizing the functional devices available in the ATM. This data, for example, can characterize the set of devices in the ATM and the configuration of these devices, or a designation such as an ATM number may be sufficient to identify the capabilities of the ATM. These devices indicating the functional devices in the ATM are reported to the server, and the server delivers the corresponding AOGT documents for the devices available in the ATM. This can be done on the basis of data corresponding to the data of devices issued by the ATM, or it can be done using a storage device that contains data describing the functional devices in the ATM, which has a specific designation. Documents selectively delivered by the server to the ATM browser will contain relevant links to the functional devices available in the ATM. These documents can be static or be formed during the run of the program from sub-documents, or in another way, in order to provide appropriate output signals and commands to the output devices of the apparatus for performing financial transactions.

 FIG. 3 shows BM 12 in communication through an internal network 16 with a computer system 14 of its own bank. The computer system 14 contains a representative server 88. The system 14 also contains a proprietary PMT server 90. The computer system 14 also comprises a device server 92. A representative server, a proprietary PMT server, and a device server may, in accordance with the image, reside on the same computer, or in other implementations, in different computers. In other implementations, additional servers may operate.

 The PPGT 90 own server is preferably in communication with the data storage device and establishes an electronic message with the auxiliary office computer system, shown schematically under the designation 94. The auxiliary office computer system 94 monitors the debiting or crediting of customer accounts when they carry out financial transactions in automated banking machines . In addition, the auxiliary office system 94 also preferably monitors financial transactions in order to make settlements with other institutions that participate in the system and whose clients carry out banking operations in BM 12.

 In accordance with the following explanation, the representative server 88 also operates in the described embodiment to establish communication, through a wide-area network 18, with third-party servers, such as a third-party server 96. A third-party server 96 is an example of a server that an institution or organization is working with, which are not an institution that works with a computer system 14. It should be noted that although the third-party server 96 is indicated as the server with which the "third-party" institution works, this does not necessarily mean that it is a country in which the institution is located is not the country where the institution operating the computer system 14 is located. But it is possible that the third-party server 96 may be located in another country, including a country where they speak a different language, not the same as that used in the country of residence BM 12.

 The implementation of financial transactions using BM 12 is further explained with reference to Fig.3-24. It should be noted that the financial flows described below are only examples of the operation of the device and system, and the device and system can be configured and operated to carry out financial transactions in many different ways.

 At the beginning of the exemplary financial transaction, schematically depicted in FIG. 3, the browser 76 establishes communication through the internal network 16 with the representative server 88. This communication is preferably established in such a way that the AOGT documents are displayed on the touch screen 30 in order to attract the attention of clients to the BM 12. This is called the “attraction mode”. These AOGT documents, which are processed in a browser to generate output signals in the form of screen images on the touch screen 30 (and / or output signals using other output devices located in the device), can come from the own ППГТ 90 server, which delivers the AOGT documents to the representative server . Own AOGT server sends messages addressed to the PI port related to browser 76 in order to display them on the corresponding BM. It should be noted that although in this example, the native server 90 is described as communicating with the ATMs through the representative server 88, the server 90 may, in other systems included in this invention, communicate directly with the ATMs.

 The main advantage of this system is that the AOGT server 90 can deliver documents selectively to ATMs 12 connected to the internal network 16. These documents may contain messages or material compiled specifically for the location of BM 12. Examples of specially designed screens Images may include bilingual messages in specific areas or exchange rate information at various points of entry. Material or messages may include advertising of various products or services, or other material specifically designed for a specific location of the ATM. Specialized JAVA programs and the JAVA text driver are downloaded from a central point that provides selective distribution of software in ATMs, which can also be used to make BM appropriate for the conditions of its specific location. For this, this ATM provides access to documents that contain material, intended for use at a given location and which is not provided in documents supplied by at least some other devices in this system.

 The systems of this invention can be configured so that the selected devices have access to the AOGT documents at different addresses, as a result of which certain documents that are accessed will contain material specifically intended for users of a particular device. Or the ATM can provide machine data indicating to the server its identity and / or location. Based on machine data and data stored in a data storage device connected to the server, the server delivers documents, including specially designed material. This can be done by selecting sub-documents, or in another way, to generate documents that will be delivered to the browser of a specific ATM. It should also be noted that despite the fact that, in the described implementation, access to the NOGT documents is carried out through the server of the institution related to this ATM, the documents used for the attraction mode can be accessed from other servers that other institutions work with.

The touch screen 30 of this exemplary sequence of financial transactions, displays a screen image that contains a separate image indicating, in one or more languages, that the user must touch to start a financial transaction
to the screen. If the user touches the screen in the area of this single image, an input signal is generated. The input signal or message ППГТ is transmitted through the browser 76 to the own address of its own server ППГТ 90, with which BM 12 is currently connected. The message generated back to the CCPT own server is represented by arrows directed from the browser 76 to the internal network 16, from the internal network 16 to the representative server 88, and from the representative server to the CCP server 90 in FIG. 3.

 In response to the receipt by the PPGT own server of 90 messages indicating that the client has touched the indicated image on the screen, the own server responds to the selected address and as a result sends the message through the representative server 88 (in other implementations - directly) to the browser 76. This message preferably contains an AOGT document, which is then processed by a browser and as a result a screen image is generated that instructs the user to insert his card into the card reader 38. Stream to 4, preferably also contains a built-in JAVA text driver or other commands that run the JAVA software to send a message to a specialized JAVA program, which is responsible for activating the card reader mechanism in a specialized hardware node 84 In one preferred embodiment, the commands provide a specialized program with a pointer or shortcut, and this program is executed in response to receiving doc commands ENTOV. Of course, in other implementations, other software and other methods may be used.

 In accordance with the image in FIG. 5, in response to the built-in JAVA text driver, which drives the specialized JAVA program related to the function of activating the card reader, the specialized JAVA program in the specialized hardware node 84 establishes a message with the device server 92. The server device 92 includes a device server program 98, which in a preferred embodiment is a JAVA program that provides communication with specialized JAVA programs and Okay device server system 100. The server device 92 also preferably comprises an application system monitoring software 102, which controls the operation command device. Supervisory software minimizes the risk of fraud or abuse, as explained below.

 Returning to an example of a financial transaction: in response to receiving a message to activate the card reading mechanism from a specialized hardware node 84, the device server 92 generates a message using the internal network 16 to the software node of the interface with devices 64 BM 12. This message contains a PPT record containing commands for the operation of the card reader, is sent to the port PI 74, where the communication device interface of the device interface. In response to receiving the message, the program unit 64 sends the message or messages to the control bus 50, which drives the card reader 34.

 In continuation of the financial transaction in accordance with the image in FIG. 6: the input of the card by the client into the card reader 34 causes the card data to be read and the program node of the device interface 64 sends the message to the device server 92, which indicates that the card data has been read. This message is transmitted through the device server through the internal network 16 to the specialized hardware node 84. The specialized hardware node then sends a message to the device server requesting card data. The device server 92 transmits a message with commands to deliver card data from the software node of the device interface 64, which responds to this by sending a message with card data over the internal network to the device server. The device server - if there is no reason to terminate this financial transaction - transfers the PPGT record containing the card data back through the internal network 16 to the specialized hardware node 84.

 In one preferred embodiment of the present invention, when a card is inserted by a user or a customer, characters are entered that correspond to the address associated with that user on the network. In this embodiment, the characters correspond to the address of a uniform resource discovery device (URL), which provides information about the computer in which the user information is located, and also a directory or subdirectory that contains user information and the name of the document or resource that contains user information . The EUP address can be encoded on the user's card. The address can be encoded on track 3 of the magnetic strip, in other places among the magnetic strip data, or by encoding other readable characters on the card. Or, if the user’s card is “intelligent”, which contains a semiconductor memory device, then the ESOP of this client can be included as part of the stored data on the chip of the integrated circuit on the user’s card. Or, the EUPM can be derived from other data on the card by accessing a database in which these addresses are correlated with other data read from the card. The data necessary to derive an address for accessing client documents can also be derived from inputs to input devices that are not card data or supplement card data, including, for example, biometric data that is entered by a client through a biometric reader. This biometric data may contain, for example, data corresponding to one or more fingerprints, data on the user's appearance, or a combination of both.

 For example, and not limited to this, the data entered by the client, such as by inserting the card into the card reader, can correspond to the address for accessing the CCPT record, which can be a file or a document containing information that can be used to verify the identity of the user. This record contains data corresponding to a personal identification number. The information may contain biometric data corresponding to the legitimate user of the card. The browser can access the record and use the contents of this record, such as data and / or commands, to verify that the characters of the biometric data of the record correspond to the biometric data of the user entering the card. Either input data characterizing the appearance, voice, other features (or combinations thereof), or other input data can be used to generate one or more addresses that correspond to the given user, and the contents of the record in the selected address can be used to verify that at the device, the user corresponds to the user of this record. Within the scope of the present invention, many methods can be used for this purpose. Record information corresponding to a given user can be used in a similar way to allow certain functional devices in the device to act for a given user, and to prevent other devices from doing so. For example, for a user who has exceeded the balance of the account, the record may contain information that will not allow him to activate the mechanism for issuing cash, while for users who have not exceeded the balance of the account, there may be information that allows this operation. Or the lack of information in the corresponding record may allow the action of the devices, and the introduction of some information will selectively limit the effect of the devices.

 Returning to the example of a financial transaction: the card data from a successfully read card is delivered in response to the programming of the hardware node of the devices 84 into a specialized JAVA program, which makes a notification that the card data is entered. In response, the specialized JAVA program generates a JAVA text driver that configures the browser with the EUP address corresponding to the data read from the card. The specialized JAVA program also preferably opens a record 104 on financial transactions, which contains the EUP address of the user, time and other card data. This recording, in a preferred embodiment, can be stored in a storage device as data in a software object. This object is preferably used to accumulate data during the financial transaction. The data stored in the financial transaction data object preferably contains data entered through user input devices, as well as data describing the operations performed by the financial transaction function devices.

 A record or object of financial transaction data provides the established order of the possible several different steps performed by the user. Due to the ability to use and share data in a number of different operations, you can avoid the need to display them or receive them from the user more than once during the work with one user, when a certain number of stages of a financial transaction are carried out. Using the financial transaction data object makes it possible to run specialized programs mainly autonomously, while obtaining the necessary data from the financial transaction object. This method also provides the ability to use a record or data object to generate the corresponding record at the end of the financial transaction process. This record can be memorized in a storage device, transferred to a series of records, or delivered to selected addresses on a local network or a wide network. According to the schematic representation in FIG. 7: the browser 76, in response to receiving the EUP address data, transmits a message over the internal network 16 to the representative server 88. For the purposes of this example, the EPP address related to the card data is the address of the user of his own bank, which works with system 14. As a result, the client’s ESMA address will determine the direction of the message from the representative server 88 to the PPGT 90’s own server and will determine access to the corresponding document in its address. Or in other systems, communication can be directly established with the server 90 without the participation of the representative server 88. In accordance with the foregoing, the ESMA address may also contain data characterizing the devices operating in the BM.

 In response to receiving the message, the PPGT own server 90 also finds the data corresponding to the user’s EUP address data in its corresponding storage device and delivers it to the browser in its PI port with the AOGT document. This AOGT document may contain a screen image confirming by the name of this client, and also by the name of a banking institution or other organization that works with its own banking computer system 14.

 In addition, the AOGT document preferably contains a built-in JAVA text driver, which has a digital signature, or a means for obtaining a digital signature related to its own PGTT server 90. Thanks to the text driver command included in the document in some implementations, a specialized hardware node accesses the PGTT address on the server, which in the described embodiment is the server 90. The CCP address corresponds to the CCP record that contains at least one command and preferably contains a program, such as a specialized JAVA program or an Active-X file. This command is used to activate the corresponding device functions of the financial transaction. The CCPT record preferably contains signature characterizing data, such as a digital signature. This digital signature is received when responding to the JAVA 82 text driver and processed in the specialized hardware node 84. The specialized JAVA program processes the digital signature in order to identify it, and if this signature is acceptable, it allows the banking machine to work. In some implementations, a specialized program may compare the signature with the signature data stored in the storage device for a given relationship, for example, correspondence.

 After a specialized program certifies that the PPGT server 90 or another selected PPGT record sent an appropriate digital signature, the financial transaction receives permission to continue. If, for one reason or another, the proper digital signature is not sent, then the specialized JAVA program will stop this financial transaction and return the bank device 12 back to the state that preceded the start of the financial transaction by connecting the BM with the address of the attraction mode in its own server 90. Using signed commands you can apply in order to make sure that various devices functions of financial transactions are valid only when responding to proper messages. The use of signed commands may be especially appropriate for teams that control the operation of the sheet issuing mechanism or otherwise provide values to the user of the machine.

 In this example, it is assumed that the received digital signature is the proper signature, in which case the message is returned from the browser 76 to its own server 90, thereby indicating that the financial transaction can be continued. In accordance with the image in FIG. 8, in this exemplary financial transaction, the private PAGT server 90 then sends the NOGT document to the browser 76, which contains commands that, after processing, form a page or screen image instructing the user to enter their personal identification number (LIN). This AOGT document preferably contains built-in JAVA commands that condition the activation of a BM 40 keyboard using a specialized hardware unit 84 so that the ATM can receive LIN. This message is schematically depicted in FIG. 8 with a JAVA 82 text driver that signals the specialized JAVA program responsible for the keyboard that it has received a request to bring the keyboard into operation. In response to this, the specialized JAVA program in the specialized hardware node 84 sends the message to the device server 92 through the internal network 16. The device server 92 sends the message back through the internal network to the software node of the device interface 64 in the BM. The commands in this message cause the keyboard 40 to be activated via device software. The specialized JAVA program responsible for driving the keyboard also preferably adjusts the entry 104 to indicate that a LIN has been requested.

 In accordance with the image in FIG. 9, the LIN entered through the keyboard 40 is transmitted in a message from the device interface program unit 64 to the device server 92. The device server 92 returns a message to the specialized JAVA program responsible for this specialized unit. The specialized JAVA program then sends the message back through the document processing node of the AOGT and the browser 76 to the address of the local server 90 of its own server. This message contains the data characterizing the LIN entered by the client. In some implementations, it is not necessary to display the client LIN on the screen. In these implementations, a specialized keyboard program may display default characters, such as the “*” character, or another character instead of LIN numbers. Further, in accordance with the following explanation, it may be desirable to avoid the transmission of LIN or other data through a browser, in which case the LIN data can be processed as a separate message TAG, or in another way to reduce the risk of disclosure.

 The software that works in connection with the PPGT 90 server then either certifies the LIN itself or certifies the LIN and the customer account number by sending them to the auxiliary office system 94, and waits for a response. Or, LIN client testing can be performed in the BM using the appropriate specialized program. This can be done in situations where the data on the customer’s card, such as account number, can be correlated with the customer LIN using the algorithm. The built-in text driver in AOGT messages can contain or indicate an address for receiving data and / or commands that a specialized program uses to perform this verification function, including certain data of the encryption key. They may include user information in the NOGT document or in other recording data that was accessed while reacting to the user's card data. According to the image in FIG. 9: the financial transaction data object 104 is also appropriately adjusted using a specialized program to indicate input of the customer LIN.

 In alternative implementations, the apparatus may comprise a biometric reader or other input device for receiving data from a user. The user can enter data through this device, which can be used instead, or in addition to the LIN data, to make sure that the user is an authorized user. This can be done, for example, by comparing the input of user data with the information corresponding to the allowed user of the card contained in the record or in the document that has the address of the CCP and which is accessed by the browser or client application system of the CCP using the CCP server in response to the card data. Or the entered data can be used to generate addresses for documents or records that are accessed by the browser or client and which contain information that is used to verify the identity of the user. For example, user data can be stored in a storage device associated with the CCP server, which delivers data from the record in response to user data that is used to verify the identity of the user.

 It should be noted that the page or screen image that asks the user to enter their LIN is depicted being generated from the PPGT 90's own server. This is preferably a screen image that refers to a specific user address of the EUP. This will be the interface of the client’s own bank, which will be known to the client. Or the user’s address can access what is essentially a personal “personal page” of the client in an institution that works with computer system 14. This will not only be what the user knows, but also what is ideally tailored for certain financial transaction needs.

 Either document (s) or record (s) containing customer data can be used to generate the addresses of other documents. This information can also be used to generate a document for a specific client in specific circumstances. This method can be used to reduce the amount of work required in advance to develop a personal visual page or document for each client.

 Methods for accomplishing this may apply various types and categories of user information in the document (s) or record (s) relating to a particular client. This information may contain information such as gender, relatives, types of accounts, permitted financial transactions, user benefits, user interest, account balances, previous offers - rejected and accepted, and other information. This client information can be used by the corresponding specialized program among the specialized programs 86 for addressing and / or developing an appropriate document for the browser in order to access based on the "characteristics" of the client. In addition, a specialized characteristic program may also take into account financial transaction devices present in a particular device, information stored in a storage device in a device or anywhere in the system, and also other factors, such as the day of the week and time of day based on the system clock generator. Thus, the device determines the appropriate document for access to it or for the formation of a document for a particular client in certain circumstances.

 The logic used in the specialized characterization program can lead to the creation of documents or access to documents for the client; it also includes a range of transactions based on user information, terminal information and other factors. A specialized characterization program may offer options for financial transactions or information that is selectively based on customer information. For example, the ATM operator may offer, selectively, incentives, allowances, additional transaction options or advertising information for customers. Certain types of clients of the institution that works with this ATM can receive screen images with options that encourage them to expand commercial operations or perform other types of commercial operations with this institution. Also, customers who are identified as customers of third-party institutions may be provided incentives for conducting commercial transactions with the institution working with this ATM.

 A specialized characterization program may cause a computer to access other documents in other servers, such as stock exchange data, and selectively provide them to customers. It should be noted that a specialized characterization program can also determine the address or generate documents for creating the initial screen images of the sequence of financial transactions. A specialized characterization program may also provide information, or access documents or generate documents to generate visual conclusions for a client at other points of a financial transaction or between financial transactions. It can also be used in systems in which the ATM operator can sell paid advertising for third parties, and then access the CCP records, such as AOGT files, for the products or services of these third parties. Such access can be done on a periodic or other basis, but it can be done efficiently by choosing the AOGT record for access while reacting to the characteristics of a particular client.

 The continuation of the financial transaction flow for this exemplary financial transaction carried out by a client of an institution that works with computer network 14 is shown schematically in FIG. 10. Own server 90 ПГГТ acts when responding to the client entering the correct LIN and at the same time sends documents AOGT to the node processing documents AOGT in a computer that controls the operation of BM. These messages may contain information used to form screen images that prompt the client to choose one or another financial transaction. For the purposes of this example, it is assumed that the customer enters a selection on the touch screen 30 that corresponds to cash dispensing, which is a normal financial transaction of BM.

 The choice of the client using the touch screen input device is communicated back through the YAGT document processing unit, which reports the TGP message to its TGP 90 server. Server 90 then responds by sending another YAGT document to the bank machine, in which the client is prompted to indicate the amount. The customer can again enter the selection on the touch screen indicating the amount of cash requested by the customer. This message ППГТ passes through the node processing documents YOGT and browser 76 to its own server 90.

 In response to receiving data about the amount from the client, its own server 90 is preferably communicated electronically with an auxiliary office system 94 to make sure that the client has this requested amount in his account. This is preferably done using the OSH 106 Common Gateway Interface, which is operatively connected to its own server 90. For the purposes of this financial transaction, it is assumed that the auxiliary office system 94 indicates that there is money in the account of this client and sends a message through OSI 106 to its own server 90 indicating that it can continue to work.

 In accordance with the schematic representation in FIG. 11, the own server 90 then sends the document back to the AOGT document processing unit in the BM software. Preferably, as a result of this message, information appears on the screen informing the client that the financial transaction is being processed. In addition, the returned AOGT document preferably contains a JAVA text driver containing built-in commands that are executed and then communicated to a specialized JAVA program, which relates to the operation of the sheet issuing mechanism 42.

 The document 90 returned from its own server may, in addition to the message for the client, or instead of it, contain advertising material or other information. The returned document may also contain a command for the ATM to access another document, or generate another document. These teams can use such methods in a specialized characterization program, which depend on the properties of the client, ATM, current time and / or other circumstances. This makes it possible to access the documents that are provided to the client while he is waiting for the completion of the ATM, advertising information or other information. It should be noted that access to these documents can be done anywhere, including access via the Internet. This makes it possible to selectively present a wide range of materials to customers. It also gives the opportunity to operators of BM and other devices for financial transactions to present advertising material to customers in general, or even specifically for certain categories of customers on a specific basis. This material can be an advertisement for an ATM operator, such as a bank, or an advertisement for almost any type of product or service. Advertising material may also be presented selectively on the basis of a specific device currently operating for financial transactions, based on a given amount of cash, or based on other parameters. AOGT documents also allow the client to present video and audio material that can enhance the effectiveness of advertising.

 The message about activating the sheet issuing mechanism sent to the specialized JAVA program in the specialized software hardware node 84 results in the formation of a message for the device server 92. The message for the device issuing 92 about the cash dispensing is preferably analyzed by the monitoring software 102 to verify that it meets the relevant requirements . For example, the monitoring software 102 preferably checks the amount of cash requested to exceed a predetermined amount. Alternatively, it can check the excess of the amount provided to this client during the past period. This can be done by sending a message to the auxiliary office system, which contains the card data previously received from this client. This message may pass through server 90 and its OSI, or through another connection. If the command for issuing cash is not canceled by a message from the auxiliary office system or monitoring software, the device server 92 sends a message about the issue to the software part of the device interface 64 in the BM. The software node 64 then, in response to a message about activating the mechanism for issuing bank notes 42, issues the amount of cash requested by the client.

 The monitoring software 102 preferably performs additional functions in the device server. For example, government regulations or good faith business practices may require limits on the size and amount of contributions that can be made to BM. This may be appropriate to prevent money laundering or other suspicious activities. Supervisory software preferably limits the amount of any one contribution below a specified limit. It also, in connection with the auxiliary office system of its own bank 94, prohibits the implementation of several deposits within a specified time, which exceed a certain limit. Monitoring software can also work in connection with a representative server to limit certain financial transactions that can be performed at an ATM when responding to commands from third-party servers, in accordance with the description below.

 It should be noted that in a preferred embodiment of the present invention, the specialized JAVA program, which sends a cash withdrawal message, works in connection with yet another specialized program that controls the set of bank notes issued to customers. Many ATMs can issue banknotes of two or more advantages. It is advisable to control the set of banknotes issued to customers so that the necessary merits are available in the ATM, and that the banknotes of one denomination do not end earlier than the other. It is preferable that the specialized program of the assortment of the advantages of bank notes control the assortment in accordance with the needs of the institution working with BM, and in accordance with the capabilities of BM. Or a specialized JAVA program that controls the assortment of bank notes can be in the device program 70 in the program node of the interface with devices 64.

 A person skilled in the art will understand that specific specialized JAVA programs and / or configuration data in an ATM can be selectively downloaded from its own server 90 when starting up the ATM, or at other times. Since specialized programs and configuration data can be selectively delivered to specific ATMs, ATMs can be prepared specifically for specific banknote issuance capabilities or other characteristics. For example, BM can be configured in such a way that certain specialized programs or their groups must be present so that the ATM can be activated. One of the methods for loading this data or programs is to provide address values in the terminal software in order to indicate where you can get the necessary commands for acquiring specialized programs or data. If specialized programs or their groups are no longer in the memory of this BM at startup, then the software makes access to the system addresses for documents that contain the necessary records or commands that load the necessary records into the ATM. You can use a browser to access the addresses, and then the software downloads the data corresponding to the commands of the documents that have been accessed to the storage device in the BM terminal, as a result of which the terminal will have the necessary specialized programs and data. Access to these document addresses can be done through your own server 90. Or the addresses can be in a separate development server connected to the internal network 16. Thus, each device performing financial operations can download specialized programs and data that contain the operational codes that it needs to be brought into operation of devices for making financial transactions in the apparatus. Either documents can be provided through a development server, or another server that can have access to the machine through a wide network. Documents can be provided in the development server to provide the apparatus with instructions for obtaining the operating code for a wide variety of functions. Commands can be sent to the device to obtain the necessary data and code from the addresses that can be accessed through the GPTT servers by the PPGT client in the device. Data and code can be obtained by responding to commands in one or several documents. The device may also require that specialized programs downloaded in this way be signed, including digital signatures or other authentication attributes, in order to power certain devices on the devices.

 Embodiments of the present invention can obtain the necessary specialized programs and data from a remote data storage device. The data storage device preferably contains data and / or programs that provide the apparatus with the ability to perform the desired operation or receive a command on where the apparatus can receive the necessary commands and data for operation. Data can be accessed from the database server. The financial transaction apparatus sends a request to the database server. This request may contain characters from the device that identify this device, or be accompanied by these signs. This may be a specific device, such as a device number, and / or may contain characters describing the type or functionality of the devices of this device.

 The data storage device preferably comprises records that have data or programs to be transmitted to the apparatus. When responding to a request to the server, the server selects the records from the data storage device and, responding to this data, delivers one or more messages to the client of the PPGT in the apparatus for performing financial transactions. This message (s) contains configuration data or specialized programs that cause the device to operate, or they may contain commands that tell the device how to receive these programs from servers connected to the system.

 In the described example, the configuration server and the data storage device may operate in the same computer, such as a server of its own bank 90. In other implementations, the database server may be located in a different location on the networks to which this unit is connected.

 The advantage of devices and systems that use these features is the flexibility to change the operation and the client interface of the device to meet changing conditions. They may include a change in the function of the financial transaction. Conditions may change so that some financial transactions are limited or absent. For example, the device can accept deposits in the usual manner, but at the same time its storage will be full. In this situation, the device can change the documents that it accesses to present messages to users through its output devices, as a result of which the ability to make deposits will no longer be offered. This can be done using specialized programs and data downloaded initially to the machine and providing commands when such a situation is detected. Either the programming of the device can be - in response to its subsequent status - be modified by downloading new specialized programs and / or data from the PGT server. This can be done when responding to a request to a database server that contains data that characterizes the changed conditions or characteristics of the device, or is accompanied by these data. In response to this, the server delivers a specialized program (s), data and / or commands that power the device in a modified mode.

 This approach eliminates the situation that occurs when working with ordinary financial transaction devices, when the static representation of the interface on output devices offers the client some version of the financial transaction. Sometimes, after the client has made a choice, an indication is given that the selected option of a financial transaction is missing. The technical solution described here can be applied to many sets of financial transactions and their options. The sets of financial transactions can be conveniently changed from the database server in the machine on a machine basis, or even by the client itself on a “client basis” in accordance with the above explanation, based on the needs of the organization working with this financial transaction machine.

 The following is a description of an exemplary financial transaction. When responding to a cash dispensing mechanism 42 issuing the requested amount of cash, the device interface program unit 64 preferably sends a dispensing operation message that confirms issuance for a specialized JAVA program that is responsible for issuing in a specialized hardware program 84. In accordance with the image in FIG. 12 a certain specialized program adjusts the record of the financial transaction 104 - indicates the delivery of cash to the client in a certain amount. The built-in JAVA text driver commands for issuing cash to the client also preferably contain instructions for sending confirmation of the completion of the message back to its own server 90. Receiving a message on the issuing operation indicating the fact of cash dispensing determines the configuration of the YAGT document processing unit for the specialized JAVA program for direct the device’s response message back to its own server. The own server then, in accordance with its program, indicates to the auxiliary office system 94 that the client has received the amount of the issued cash. This amount is deducted from the customer’s account in the records maintained by the auxiliary office system.

 Typically, during the conduct of a financial transaction, the client is asked if he wants to receive a receipt on the completion of this financial transaction. This can be done at different times during the financial transaction. In this example, after issuing cash to the client working with the ATM, send the message shown in Fig.13. Own server 90 sends an AOGT document that contains a screen image in which the client is asked if he wants to receive a receipt. This message is displayed as part of the page on the touch screen 30 in response to receiving a message on the browser 76. Or this document can be formed by an ATM. In response to the client indicating that he wants or does not want to receive a receipt, the message is returned to his own server. It should be noted that the screen images displayed for the client are preferably images that the client is used to in his own institution, or are part of his own special page.

 Based on the fact that the client wants to receive a receipt, his own server 90, in accordance with image 14, sends the document back to the BM with the built-in JAVA text driver indicating the need to print the receipt of the financial transaction. These commands in the JAVA text driver are communicated to a specialized hardware node 84, which sends the PDP / PI message through the internal network to the device server 92. The device server 92 in turn sends a message with the commands to the device interface software node in the BM. In response to the receipt of this message, the program portion 64 causes the printer 46 to print a client receipt of the financial transaction. The JAVA specialized program responsible for driving the printer adjusts the financial transaction data object or record 104. In accordance with the following explanation, the specialized program that controls the printing of the receipt can receive the data used for printing the receipt from the financial transaction data object.

 It should be noted that even if the client does not want to receive a receipt, it is still desirable to print the record of the financial transaction on paper using the journal printer 48. This can be done in response to the built-in commands that are part of the same document from your own server 90, which determines the printing of the receipt of the financial transaction for the client, or may be part of a separate document that indicates that the client rejected the offer to receive a receipt for a financial transaction. Or the journal printer can be powered up in response to other specialized programs, such as a specialized program, which determines the issuance of cash, or otherwise selected by the BM operator. From the above description it follows that the work of the preferred implementation of BM inherent flexibility and programmability in order to meet the needs of the system operator.

 As shown in FIG. 15, upon printing of the receipt of the financial transaction, the program portion 64 preferably sends a device activation message to the device server 92, which indicates that the requested device function has been completed successfully. The server device 92 sends the appropriate message drive the device in a specialized hardware node 84, and in a preferred embodiment, in a specific specialized program JAVA, responsible for printing a receipt. The specialized JAVA program, in turn, configures the AOGT document processing unit to form a message back to its own server as a device response message to indicate that the receipt for the client has been printed.

 Upon receipt of cash and a receipt, the client is then given a screen prompt generated by the AOGT document from their own server 90, in which they are asked to indicate whether the client wants to perform another operation. A visual page or screen image informing the client about this is displayed on the touch screen 30. For the purposes of this example, it is assumed that the client does not want to perform another financial transaction, and the message about this is returned via the AOGT document processing unit back to its own server 90 .

As shown in FIG. 17, in response to receiving a message that the service of this client has been completed, its own server 90 sends a “home” message to the BM. This message preferably contains an AOGT document that forms a screen image thanking the customer. This message also preferably contains a built-in JAVA text driver, which calls the specialized JAVA program that returns the BMN BMD document processing node back to the connection with the EUP address in its own server 90, or with another address that provides documents used to display messages for the so-called . "attraction mode." Necessary
note that the text driver in some implementations may send a message from the document processing unit to an address in its own server that downloads the corresponding PPGT record, including commands containing the necessary specialized program.

 As shown schematically in FIG. 18, the specialized program of the home command configures the browser 76. After the specialized program has configured the AOGT document processing unit to return home, the specialized JAVA program can be configured to deliver information from the financial record to its own server 90 operations 104 on a financial transaction that has just been completed. Since the approximate financial transaction was made with a client of the institution that works with computer system 14, all data on this financial transaction should already be recorded in the auxiliary office system 94. But it should be noted that this will not happen if the financial transaction was completed in response to Messages from a server that another institution is working with. Therefore, all or part of it, information from the record of financial transaction 104 can be delivered in response to the “home” command to its own server 90 and through the OSH to the auxiliary office system 94, where it can be identified as safety information and deleted. This can be done using the remote call method (RMI-RMI) to transfer or deliver the object to the server 90 and then, by transmitting the data via messages from the server, to the auxiliary office system, or via messages, or using other methods.

 Of course, in other embodiments, information about a financial transaction may be stored in the database for extended periods, and not returned after each financial transaction. Or BM 12 of the present invention may contain specialized programs for delivering information on recording financial transactions not to its own server, but to other addresses, if necessary, to the system operator 14.

 The action of the computer system when the BM 12 is used by a “third-party” user is graphically depicted in FIGS. 19-24. A financial transaction with a third-party user who is not a client of the institution working with BM 12 and computer system 14 is carried out under the control of its own server 90 and occurs in the manner of the previous example until the moment the client inserts his card. The client inserts a card with characters corresponding to the EUP address, which does not correspond to its own server 90. The UOGT document processing unit configures a message addressed to access the EUP address, which corresponds to the characters on the client card, or to another address that responds to these signs. This message is delivered to the representative server 88, which in turn sends the message to the wide-area network 18. From the wide-area network, the message arrives at a third-party server corresponding to the EUPU client address. For the purposes of this example, the third-party server corresponds to server 96, which is connected to the Internet.

 In a preferred embodiment of the present invention, the representative server 88 comprises “rejection” software 107. The rejection software preferably checks the addresses to which messages are sent using the BM and selectively cancels sending messages to specific addresses. This serves as a "firewall", and is desirable in order to prevent fraud in the system.

 As shown in FIG. 20, the third-party server 96 preferably reports the CCPT messages, including the BAG documents, to the BM 12 back through the wide-area network 18. This can be done using a secure socket connection (CST) to minimize the risk of message interception. Of course, other methods, including message encryption methods, can be used to minimize the risk of message interception.

 As shown schematically in FIG. 20, the response document from the third-party server 96 preferably contains a digital signature that identifies the third-party server 96. This can be done by downloading the CCPT record containing the signed custom program as described above. The specialized program in the specialized node 84 in the BM preferably checks the digital signature in accordance with the method described above, and sends a message indicating that the financial transaction is allowed. The digital identity of the third-party institution is stored in the storage device BM and recorded in the auxiliary office network 94.

 It should be noted that the AOGT documents from the third-party server 96 form visual pages or screen images of the third-party institution, which the third-party client is used to seeing. These pages may correspond to a “third party user’s own page” that specifically matches the needs of a particular user.

 FIG. 21 shows a document accessed through a third-party server 96 for BM 12. A document from a third-party server may contain a built-in JAVA text driver that allows specialized JAVA programs to operate in accordance with the above procedure to power devices 36 in the BM. In accordance with FIG. 21, the PDPD / PI messages for devices from specialized JAVA programs pass from the specialized hardware node 84 to the device server 92, and the commands from it go to the software node of the device interface 64 in the BM. Device actuation messages have a return path. When these messages pass through the device server 92, monitoring software 102 monitors them to minimize the risk of fraud or abuse.

 In accordance with Fig. 21, documents from a third-party server 96 may display on the touch screen 30 a request to the client to enter his LIN. The built-in commands of the JAVA text driver, as in the previous example, contain commands that allow the keyboard 40 to accept the client LIN. As in the previous example, the record of a financial transaction 104, which contains a shared data object for this financial transaction, is opened by a specialized hardware software node. In accordance with the above, you can optionally exclude the passage of LIN data through the browser.

 FIG. 22 shows the return of the drive actuation message and the LIN data to a specialized JAVA program, which in turn transfers the data back to the third-party server 96 via the wide-area network 18 using a secure socket connection. From now on, the financial transaction takes place in general in accordance with the example set out above - with the exception that the third-party server 96 sends the HRTT records containing YAGT documents and receives messages from the document processing unit in the BM. The third-party server 96 contains specialized JAVA software necessary to include the embedded JAVA text driver in the documents that are sent to the BM to power the device 36 in the device.

 When a third-party server 96 is operating in the apparatus, the monitoring software 102 in the device server 92 monitors the messages in accordance with the above description. This control, for example, prevents the dispensing of disproportionately large amounts of cash from an ATM. Supervisory software may also limit certain third-party agencies to a subset of the devices or characteristics of financially operating devices. This is done on the basis of data stored in a storage device that limits devices or actions that can be performed on documents at specific addresses. This can be accomplished, for example, with the help of code barriers that perform a certain class of objects of financial transactions and restrict feasible operations. For example, operations that connect to a third-party server can trigger objects that provide certain limited capabilities for messages received from a third-party server. This may, for example, limit the amount of cash issued, cancel the operation of the check receipt device, limit the issuance of printed documents, such as tickets, cancel the operation of the cash withdrawal mechanism, or limit the use of the device by other appropriate means. This can be done based on the addresses or parts of addresses for documents.

 If the capabilities of the device for a third-party client are limited, then a third-party client can be provided with a visual interface from a third-party bank on the basis of financial transactions that this device can perform and which the owner of the device can allow. As a result of this, documents accessed on the server of a third-party bank may be a variant of documents that would be provided to the client on the machine with which the third-party bank works. This can be done on the basis of documents specially prepared for working with third-party devices, or it could be a variant of the usual interface of a third-party bank with visual indications that certain financial transactions are missing. In some cases, the interface may indicate that some financial transactions can be made subject to an appropriate service charge.

 The BM of the described implementation can increase security by limiting the addresses that the browser can access. This can be done by maintaining a list in the device’s storage device. This list can be kept in the records (s) of the CCP (including documents), which are accessed through the internal network of your own bank. This unit can access the recording periodically and adjust the data of the storage device. This record itself may 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 contain commands and information for BM to verify the authenticity of received messages by accessing documents in a third-party server. They may contain digital signatures, which are then forwarded using public key or private key encryption methods to verify the authenticity of the messages. The device checks to make sure that the signature in the records accessed from a third-party server matches the digital signature for this address stored in the storage device; and the apparatus permits the operation of financial transaction devices, such as a cash dispensing mechanism, only if there is such a match. Of course, in different implementations, other methods may be used to verify and encrypt messages. In this invention, signatures or signed records include any characters that are contained in the record, or which are derived from the record, and which indicate their permissibility.

 From the above description, it also follows that the third-party server 96 can communicate with the user through a touch screen in a language that differs from the language commonly used by clients of the institution that works with the computer system 14. As a result, AOGT documents may display requests to issue the currency of that or other type, or in the amount that is not contained in the BM. To meet this situation, the specialized hardware unit 84 preferably includes some specialized program that processes requests regarding foreign currency. The specialized foreign currency program determines the sending via the BM message back to its own server in order to calculate the closest amount that can be provided to the client in the existing currency in the BM to fulfill his request. It should be noted that this specialized program calls the address of a specific function in its own server 90, which can provide this function. After issuance, a specialized program indicates to the server 96 that the amount issued is somewhat different from the amount requested by the client. Of course, in other implementations you can use other technical solutions. Or, a specialized program in the device can generate visual displays that show equivalents in local currency during the display or processing of amounts in foreign currency. Also for the user in visual displays can be shown both amounts.

 As shown in FIG. 23, when the third-party client completed its financial transactions via the touch screen 30, the third-party server 96 sends the message “home” back to the BM. As a result of receiving this message, in accordance with the above description, the specialized hardware node 84, in response to the built-in commands of the JAVA text driver, configures the AOGT document processing node so that the browser 76 re-establishes communication with its own server 90 or with another assigned document address.

 In accordance with FIG. 24, the specialized program in the specialized hardware node 84, which processes the home message, preferably reconnects its own server 90 and also sends the financial transaction record information to the record 104. This financial transaction record information, which is preferably packaged in a data object, contains the name of the client, name of the third-party institution, digital identifier, information on the amounts issued, transferred or invested, and all other relevant data on financial transactions. Data on financial transactions is used by specialized programs when performing stages of a financial transaction, which require some part of the data. Upon completion of the client’s actions in the device, a specialized program provides a financial transaction data message that contains at least a portion of the data collected. This data is reported from the server 90 through OSH 106 to the auxiliary office system of its own bank 94. This information is stored in the auxiliary office system for subsequent use in order to make settlements with a third-party bank that works with a third-party server 96. Either, or in addition, data about financial transactions can be recorded in the storage device in the terminal, and also on paper using a journal printer. Data on a financial transaction can be remembered to download as a package, or by transferring objects containing data on many financial transactions. The packet data can be reported at such a time and at such addresses that can be stored in the storage device in the configuration data of the terminal.

 An advantage of the embodiments of the present invention is that financial transaction data can be delivered to addresses on a local network or a wide-area network such as the Internet. This facilitates a wide variety of financial transactions and makes it possible to send messages related to the following use (smart cards such as an electronic wallet), or to calculate various types of financial transactions at a selected address of the system.

 It should be noted that the described invention of an automatic banking apparatus and system according to this invention provides the advantage that when the apparatus is connected to a wide network such as the Internet, customers can carry out their banking operations almost around the world. Also, despite the wide capabilities of the system, since the device can be controlled on the spot both in terms of connection and in terms of actions, the risk of fraud is minimized.

 The implementation of the present invention may also contain a feature that facilitates access to documents on the network to which the device is connected. This feature determines whether a PPGT record is available, such as an ATF document or another document, at any download address, before the computer will access this record. Due to this, downtimes that could otherwise occur as a result of the inability to access this record due to the fact that the server through which this record is usually accessed can be avoided. Other implementations may take into account both the recording size and the transfer speed, and determine that the transfer speed for a given record is not fast enough, and therefore an alternative recording needs to be forwarded.

 In one embodiment, this characteristic is provided using a separate program or a specialized program that checks whether the server that the computer will access is working. This specialized program operates upon receipt of the address, or part of it, to which the connection will be made. A specialized program makes a nested connection to the address and downloads a small but sufficient amount of recording, or acts in another way to determine that the server through which access to the recording is to be made is not turned off. In response to a specialized program verifying the fact of a remote server, or otherwise determining the conditions for access and download, the computer then does a certain job, as a result of which the browser or similar software accesses this address at the appropriate time in the sequence of the financial transaction. If a specialized program cannot detect the fact that the remote server is working, or determines that it is not possible to successfully contact or download this record, then measures can be taken to gain access to an alternative address or to terminate the financial transaction. Access to alternative addresses can be based on data stored in the terminal memory, or can be obtained by accessing documents either locally or remotely with the inclusion of data from which alternative addresses can be obtained or displayed. Alternative addresses are likewise checked to determine that records can be accessed before alternative records are accessed. This technical solution eliminates delays in the implementation of financial transactions.

 Alternative embodiments may use other technical solutions to determine whether it is possible to successfully access the required HRT records, such as AOGT documents, and / or to determine the possibility of a corresponding download before the browser providing the client interface tries to access the document. Some implementations may consider when determining whether a document can be successfully accessed, the transfer speed or other conditions relating to the operation of the system or to the contents of the document. For example, a specialized program that determines the ability to access the recordings of a CCP, or another specialized program, can determine the transfer speed with which the recording can be sent to a computer. The speed at which data can be transferred can be compared with the data stored in the storage device, and if this speed is lower than the speed of the data characterizing the desired stored speed, then access to an alternative recording. This can be, for example, a document of a nuclear weapon, which is stored locally in the apparatus. Other implementations may include programs that take into account the size of the HRTT record and the forwarding rate when determining the forwarding rate. These programs then determine whether it is possible to forward the given record quickly enough in accordance with the parameters set in the configuration in the storage device, and if this is not possible, then access is made to alternative addresses. These alternative entries can likewise be checked for forwarding speed before being forwarded.

 Programs can also consider other factors when deciding on access to a specific address; these factors may include, for example, the day and time of information, or information from sensors, for example from sensors in the field, which indicate that other clients are waiting in line to use the machine. Thus, you can avoid access to documents that have significant output volumes and which can extend the financial transaction time for an undesirable time, even when the records can be downloaded at the appropriate speed.

 Although the described embodiments of the automatic banking apparatus and systems of the present invention are given with respect to a particular type of apparatus that is specifically designed to be connected to local or wide area networks, conventional automatic banking machines can also be adapted to include this characteristic. In particular, the YAGT document processing unit and specialized hardware units can be introduced into other conventional software that runs in an automatic banking machine. This makes it possible for these BMs to work either on a regular private network or as part of a wide network. In addition, automatic banking devices can be configured to operate their devices through the software node of the device interface of the present invention, through another software interface when operating on a conventional network. These devices, when operating under the control of a server in a wide network, can switch according to the messages of devices that must pass through the device server in order to maintain the security of the system. Thus, one BM can work in private networks like regular BMs, and also in the network configuration of the system of the present invention.

 Alternative embodiments of the present invention transmit financial transaction messages used in a private BM network. This can be done using the OSH in connection with either the document processing unit YaOGT BM, or with its own PPGT server or with another server. OSI operates in connection with the message conversion program and the database for collecting the necessary data from the AOGT documents and response messages, and for generating certain financial transaction request messages that are relevant for this private financial transactions network. In a similar way, the message and OSI conversion program receives function command messages from the private network and converts them, and generates corresponding AOGT documents and / or PUPD / PI messages for use by the ATM. Since these formats of the private network are defined and the data necessary for the formation and interpretation of messages are known, the use of BM 12 directly in the private network of the BM is ensured.

 The usual messages on financial transactions of BM are messages of a certain format that do not contain YAGT documents in the messages of the BCP. An example of the usual messages used for BM operation are Diebold 91X messages. These messages usually provide for the transmission of a request message from BM in a specific format, including customer input (account / LIN) and an indication of the type and amount of the requested financial transaction. The request message is received by the main computer BM, which sends back a response message with a specific format, which contains an indication of the permissibility of this financial transaction. Then BM returns one more message to the main computer, which indicates whether the device was able to carry out a financial transaction. Messages used in these conventional private networks typically occupy a relatively small bandwidth.

 When connecting the BM of the present invention to such a network, a server is provided. The server is connected to the storage device, which contains the corresponding database, in which the document conversion data and the document creation data are stored. In one configuration, the server is connected to the document processing node via the network, or the server can be located in the BM computer. The server generates documents that are accessed by the browser and which contain commands from financial transaction devices. The server (or the connected server) exchanges regular messages with the host computer. One server can provide an interface for several BMs connected to it on a local network, or each BMI can have its own server working in it.

 The ability of BM 12 to communicate with a private network also allows the BM to work in the order in which the interface is formed by the user's own institution as described above, but in which financial transactions are allowed in messages sent through the private BM network. This ensures the security of the use of the private network and provides the client with the benefits of the familiar interface of their own bank and / or the interface of the "personal own page".

 In this configuration of the BM device, the financial transaction functions may work in the usual way when responding to regular BM messages about financial transactions, such as Diebold 91X in a private network. Client output devices, such as a screen image (and speakers, if any) are communicated through a browser connected to a local or wide area network. The browser accesses documents to give prompts during a financial transaction, but the documents do not contain commands that trigger the device, such as a cash dispensing mechanism.

 In one configuration, the browser can work from the computer in response to the status of devices in the device, because devices work in response to regular BM messages. Thus, the browser can go to the selected addresses, including addresses that relate to the client based on the entered client data. But since the documents received by the browser do not activate the financial transaction functions of the device, there is less need for security measures when accessing documents. As a result of this, the client can work with the device in response to a familiar and special interface; and also marketing information, such as advertising, or other material, may be presented during the course of a financial transaction.

 In other embodiments, apparatuses may perform some functions of devices based on ordinary messages, while other functions may be performed in response to commands in the AOGT documents or other messages of the CCP. For example, AOGT documents can provide significant data for use in printers or other output devices. Some implementations may access documents using commands, but may also not respond to some and respond to others. This method can be chosen by the system operator by configuring the software based on its needs.

 Another advantage of the system configuration of one preferred implementation is that it has increased the flexibility for exchanging messages related to BM. The device manager 68 preferably generates status messages about the status of the devices 36. These status messages can usually represent information about the states that are present in the devices. These messages may indicate that stocks for printers or stocks of banknotes are exhausted or unacceptably small. Other messages may indicate that the devices are not functioning properly. Often, these messages indicate that the BM needs maintenance. All of these message types are referred to here as status messages or fault messages.

 The software interface node with the devices 64 establishes communication through the internal network 16 using messages PDP / PI. Although the financial transaction messages described above are routed to the device server 92, the program node 64 may comprise a server and may be configured to address status messages and fault messages to other addresses on the internal network or the Internet. For example, these fault messages or status messages can be sent to a software application system that delivers messages to a service provider. Also, error messages can be selectively sent based on the nature of the indicated failure. For example, fault messages indicating the need to replenish cash or paper may be routed to an internal network address related to who is responsible for replenishing these stocks. Or fault messages that indicate the need for other types of service can be sent to an address related to who can provide the required type of service.

 Or, by properly configuring the device server 92, you can selectively dispatch the error messages to addresses on the internal network 16. In addition, either the software node 64 or the device server 92 can send the error messages from the BM to the troubleshooting system, such as software " Troubleshoot system "Diebold, Inc." This software recognizes the nature of the malfunction and notifies appropriate personnel of the need to take appropriate action.

 BM 12 may also comprise a software function for diagnosing problems and providing troubleshooting services. In accordance with the graphical representation in FIG. 2, alternative implementations of BM 12 may comprise a mini-server of the HRPT 109, which communicates with a software node of the device interface 64. The server 109 is configured to receive status messages from devices and to generate HRTT records that include responses to them AOGT documents that provide data characterizing the status of a device for a diagnostic device 110, such as a portable computer terminal. Server 109 contains an error code for the interface with the device software, as a result of which the technician can access the information in the records accessed in the addresses of the CCP related to status messages, input verification and troubleshooting commands through the diagnostic device 110. CCP records and / or AOGT documents generated by the server 109 may preferably contain graphic and audio commands indicating states such as problems that occur and also data on troubleshooting steps nost and repair teams.

 In alternative embodiments of the present invention, the functions of the mini-server PGT 109 may be located in the device server 92. This, in particular, may be appropriate in cases where the function of the server server is located in the computer in the BM. Regardless of the location of the function, the use of visual and audio components of AOGT documents related to maintenance and diagnostic messages facilitates maintenance of BM.

 These records, delivered through the CCP mini-server, contain commands that correspond to status or failed states. These records or documents may be accessed locally, as described above, or remotely. A technician using a laptop computer with a browser, or other software to access the PMT records, can access documents locally for maintenance, diagnostics, and maintenance purposes. In some situations, the client interface or a browser related to it can be used to access the mini-server of the CCP, or to a separate browser, display or input device in the device, which are intended for servicing operations. Either error messages or status messages can be monitored from terminals located elsewhere and connected to the network. Status messages and fault messages for working with the CPS mini-server can also be configured to send an e-mail message or send a similar message to the selected address whenever there is a specific state or group of states.

 Another advantage of this feature is that the messages of the CCP can also be sent to the mini-server of the CCP to solve problems. These messages may include a run of diagnostic tests and obtaining results. They may also contain methods for checking and fixing freezes and other malfunctions. This can often be done from remote locations. Of course, in cases where there is a significant risk of unauthorized access to messages of silence about working with the server or to device messages, then appropriate security measures must be taken.

 Records ППГТ, which indicate the status of the devices functions of the financial transactions, may take different forms depending on the configuration of the software and the needs of the system operator. In some implementations, device status information for one or more devices may be represented by characters contained in a data object. The data object can be sent to other connected computers to provide status data. Forwarding a data object can be accomplished, for example, by a remote call method. Then, the data in the transferred data object can be used to form the message and / or output data needed by the system operator. This method may be especially appropriate when the operator wants to connect the device to an existing monitoring system, and the characters contained in the data object can be used to generate output data or messages indicating the status of devices that can be processed by the existing system. You can also use plug-in connections to establish communication between existing control systems and financial transaction apparatuses (apparatuses) that have different types of status states or different types of message formats. This includes devices that have different types of devices and characteristics of the function of performing financial transactions.

 The method of sending a data object can also be used to test or modify devices for the function of performing financial transactions. For example, characters in a data object can be modified during maintenance, and the object can be sent back to the machine. The software in the device can instruct the devices of the financial transaction function to start working or change conditions or programming in response to a modified data object. For example, this may include the removal of an indication of a malfunction, or the actuation of a device in order to eliminate a hang or test. The results of these actions can be reflected in the modified characters in the data object, which can then be sent to the computer in the diagnostic terminal. Of course, the technical solutions described here are examples, and other technical solutions will be apparent to those skilled in the art from the description set forth herein.

 In FIG. 25 is a schematic diagram of a network configuration for an alternative embodiment of an automatic banking machine of the present invention. The implementation of Fig.25 contains an automatic banking machine, specifically designed to work in conjunction with conventional systems of automatic banking machines, such as systems that operate using message formats Diebold 91X ATM or other conventional formats that are not PGT. The host computer 120 is a conventional host BM that communicates using these messages. The main computer communicates with the interface server, schematically depicted at 122. The interface server 122 operates as described above and is operatively connected to a storage device that contains the information necessary for converting the messages of the CCP related to this request for a financial transaction to a request message 91X, or another regular message that the main computer 120 can process. Similarly, the interface server 122, and the commands and data stored in the memory the other device, the regular command message 91X or another ordinary command message from the main computer 120 is converted into the CCP messages that the automatic banking machine can use to execute this command. Similarly, the interface server 122 receives the CCP messages that correspond to the response of the automatic banking machine to the commands, and generates a response message 91X, or another ordinary response message for the main computer. In performing these functions, the interface server communicates via a client interface 124, which in a preferred embodiment is a COMM connector and operates in a terminal banking machine in the Windows NT operating environment. The interface server 122 also includes a command / status gateway 126. The command / status gateway receives command and status messages from software nodes that operate with functional devices in the apparatus. Messages related to devices are used to generate messages about financial transactions that are sent back to the host computer 120. In addition, the command / status gateway node also generates status messages indicating the status of devices that can be reported to the host computer.

 The interface server 122, the command / status gateway node 126, and the client interface 124 may reside in the software of the terminal automatic banking machine. In this configuration, the terminal device from the point of view of the main computer is a conventional device. Or, the interface server 122 and the command / status gateway node 126 may reside in a separate server, while the client interface node 124 may reside in a terminal device. This allows the interface server 122 to process a number of automatic banking devices by connecting the devices to the interface server via a network.

 An alternative system configuration of the automatic banking apparatus of FIG. 25 is specifically designed for use in connection with an existing BM system. The apparatus contains a document processing unit YOGT 128, which contains a browser that operates in accordance with the above-described implementations. The AOGT document processing unit is also called a browser for simplicity. The YAGT document processing unit works in connection with the network 130 to access the TGVT records in the form of YAGT documents through the servers 132, 134 and 136. For the purpose of this example, the server 132 will be considered as a server of its own bank that works with this automatic banking machine. The browser node 128 accesses documents of its own bank in order to obtain content and commands for displaying information for customers and also for actuating devices in this unit. Servers 134 and 136 characterize other servers that the automated banking machine may instruct to access in order to download documents that contain information or commands. Often these documents from servers of third-party banks contain information that needs to be presented to customers in the form of advertising material, such as stock quotes, or other types of information. It should be noted that servers 134 and 136 can be directly connected to network 130, or they can be accessed through other networks and servers. In some implementations, access to these servers may be via the Internet in order to provide documents for an automated banking machine.

 The document processing unit 128 comprises a terminal “theater” software node 138. The terminal theater node 138 is depicted in more detail in FIG. 26. The terminal theater unit 138 contains a behind-the-scenes frame 140, a theater frame 142. The behind-the-scenes frame 140, although located in a browser, is not visible on the screen of the automatic banking machine. Theater frame 142 is the visible frame and controls what is displayed to the client.

 In accordance with the schematic representation in FIG. 25, the AOGT document processing unit also contains a terminal director node 144. The terminal director node contains directors that are relevant examples of specialized programs used to perform certain types of financial transactions. Terminal directors usually correspond to the work of specialized JAVA programs of the implementation described above.

 The automated banking apparatus of alternative implementation also contains an application system of financial operations services 146. The applied system of financial services provides security, indicates the status of the terminal, permissibility of the terminal, and provides basic management services in this automatic banking apparatus. The financial transaction services application system includes a function for sending CPS messages using the interface server 122. The financial transaction services application system can also establish a message over a network, such as a network 130, in accordance with the explanation below. The financial services application system also provides a server function that allows the financial services application system to act as a device server 92 in the above implementation.

 The automated banking apparatus of an alternative embodiment also contains common interfaces of JAVA devices 148. The common interfaces of JAVA devices in the preferred embodiment are relevant examples of specialized programs that control and coordinate the operation of functional devices 150 of apparatuses that perform the functions of financial transactions. Functional devices may comprise devices of the types described in connection with the foregoing implementation, or types of devices that perform a function related to a given financial transaction. Generic device interfaces JAVA 148 communicates with functional devices via generic device interfaces 152. Generic device interfaces provide an interface that controls electromechanical modules in functional devices contained in an automated banking machine. The common interfaces are schematically depicted in connection with the diagnostic server 154. The diagnostic server acts similarly to the server 109 of the above implementation. Diagnostic server 154 is used in diagnostic status and when correcting problems that arise in devices in an automatic banking machine.

As shown in FIG. 26, the backstage frame 140 in the terminal theater unit 138 is a component called the backstage special program 156. The backstage special program 156 is preferably a relatively thin film element. Commands called a text driver contained in documents accessed by the server selectively give
a command to a specialized program behind the scenes to notify the terminal director of the time of the financial transaction in response to the commands contained in the document to which access was made. The behind-the-scenes specialized program also makes a request that you need to access the new AOGT document. The behind-the-scenes specialized program also provides access to the financial transaction data shared object mentioned above, which contains financial transaction data.

 Theatrical frame 143 controls the user interface in the form in which the user sees the automatic banking machine. The client’s AOGT, schematically depicted under the designation 152 in theatrical frame 142, identifies identifying characters related to events sent to the director’s management program through a behind-the-scenes specialized program and provides an interface with publicly accessible methods of the director’s management program. The director’s management program 160 in FIG. 26 has a class that is located in the financial transaction services application system (FFSA) 146. The director’s management program class in the PFSA process loads terminal directors 144 into the AOGT document processing unit. The director’s management program also contains a backstage specialized program class, which is located in the backstage frame 140. The director’s backstage specialized program class provides an interface for client AOGT to implement requests in the director’s management program. Teams in YAGT documents can transmit events through the specialized behind-the-scenes program 156 to the director’s management program. These events contain a request to authorize a financial transaction. These requests may also indicate that the client has completed the financial transaction, or that the document downloaded by the browser contains commands requesting the end of the session. Other events that can be transmitted through the director’s management program include event printing. Other events that can be transmitted through a behind-the-scenes specialized program for the director’s management program contain an indication that the entered data has been canceled, or other specific user events.

 In response to the reception of events, the director’s control program of the depicted implementation is triggered by commands in documents accessed by the browser by performing functions that contain a change in the content of the theater frame 142. The director’s control program generated by these commands also changes the director’s active end class. The director’s management program also caches the director’s end classes for future use, or downloads the director’s end classes and AOGT documents from the list of available servers. The director’s management program also provides access to a shared financial transaction data object that contains financial transaction data for a specific financial transaction. The director’s control program also directs theatrical theater events to the backstage class of the current terminal director and provides a blocking time relay when the screen image timeout is exceeded. Of course, in other implementations, the terminal director may perform other functions.

 In the alternative embodiment of FIG. 25, terminal directors 144 in the financial services application system 146 selectively access documents using the AOGT document processing unit 128. Documents that are accessed may contain commands that are used to work with automatic banking apparatus and its functional devices. The financial services application system 146 also reports the messages of the PSTT, which are transmitted to the interface server 122 and used to generate conventional BM messages that can be processed by the main computer 120. Cash withdrawals and other cost transfers are carried out in response to permission from the main computer 120, while the interface and other functions are controlled by commands in documents accessed by a browser. In one preferred embodiment, the BM, or other financial transaction apparatus, establishes communication with the conventional main computer of the BM by transmitting a financial transaction data object between the computer in the BM and the interface server. This transfer is preferably accomplished by characterizing a method for remotely invoking a message in software tools such as JAVA. Of course, for transfer, you can use the data object file using the CCP.

 In accordance with the above, the financial transaction data object contains financial transaction data. The device receives data related to a financial transaction, such as account data from a card, customer LIN, the requested financial transaction (s) and amount (s), and stores this data in the data on financial transactions.

 After presenting the data - in the financial transaction data - required to generate a regular message about the financial transaction of BM, the data object is sent to the interface server. The interface server operates in connection with a database 123 or other object containing conversion data in accordance with a schematic diagram. These transformations are used by the server software to generate a regular message about the financial transaction request BM, which is sent to the main computer 120. A regular message can be formatted as a regular message 91X, or another regular message about a financial transaction not in the PPGT format.

 After processing, the host computer 120 responds with a normal response message. The components of the response message are received on the server and processed in response to the conversion data to generate the modified financial transaction data in the data object. This modified financial transaction data preferably contains data indicating whether the requested financial transaction is authorized or canceled, and also other data. For example, if a given financial transaction is rejected, then they may contain data that indicate the reason for such a rejection.

 The financial transaction data object with the modified financial transaction data is then sent to the computer with which the BM works using the method of remotely invoking a message, or using another method of forwarding. The financial services application system 146, operating in software, receives a data object and activates the financial transaction functions device in response to modified financial transaction data. The financial transaction data object further modifies the financial transaction data by including in them information regarding the operation of the devices. After the devices are activated, the financial transaction data object with the data on financial transactions that underwent subsequent modification is transferred back to the interface server 122. The modified financial transaction data is then used to generate a message for the BM main computer. The message in the main computer contains data corresponding to the modified data on financial transactions. Typically, this message is a regular completion message, not in the CGT format, indicating whether the financial transaction was completed successfully by the financial transaction function devices.

 The format of the usual messages about financial transactions, not in the format of the CCP, can be conveniently changed in the described implementation. This can be done using removable programs. Removable programs insert data into the financial transaction data object, and extract this data from it. Plug-in programs provide conversion between financial transaction data and the necessary regular messages not in the PST format. The use of removable programs provides a more convenient use of BM described implementation in connection with variable types of conventional networks for financial transactions.

 The financial transaction data in the financial transaction data object preferably operates so that the computer drives the browser in order to access the selected AOGT documents. This can be done to indicate that the financial transaction is authorized or canceled, and also to access specific documents that respond to message components. For example, customers of banks that are not a bank working with BM may receive some advertising materials that they do not represent for customers of this bank. Data on financial transactions indicating the reason for the cancellation of this financial transaction can be used to access documents that provide an explanation, or can stimulate the client to perform another transaction, such as receiving an advance in cash by credit card, or to request a loan.

 The system shown schematically in FIG. 25 is an example of an automatic banking machine system that provides a wide range of interface options available when using the AOGT interface, while maintaining compatibility with existing banking machine systems and related security methods. Of course, in other implementations, alternative technical solutions and configurations may be used.

 Another advantage available in the system schematically depicted in FIG. 25 is the ability to work with software components of the described embodiment of the present invention in existing automatic banking machines. It should be noted that the processing of AOGT documents in conventional computers requires data input using a keyboard with the location of QWERTY type characters and also clicks in places corresponding to images or other characteristics of AOGT documents in order to successfully find and use these documents. Conventional automatic banking machines, as a rule, do not have a mouse or a full keyboard. Conventional automatic banking machines, as a rule, have an alphanumeric auxiliary keypad similar to telephone ones, and also function keys. Implementations of the present invention enable the system to operate with terminals that condition the operation of these interfaces in a manner that provides the benefits of the present invention.

 FIG. 27 depicts an example of a conventional automatic banking machine that has an interface 162. The interface 162 includes an output device comprising a screen 164. The screen 164 may be a CRT, a liquid crystal display, or another conventional display screen. In the depicted embodiment, the screen 164 is not a touch screen as in the previous described embodiment. The set of function keys 166 is located near the screen 164. The keypad 168 is also included in the interface 162. The keypad 168 contains alphanumeric keys, as well as some specialized keys, such as cancel, correct, and " right "(ok). Other keys on the keypad are usually empty, but in some cases can be used.

 During operation of a conventional automatic banking machine, screen data, which is formed from information stored in the terminal memory, forms certain screen images of financial transactions, which are presented graphically on screen 164. Screen images appear in sequence when responding to a financial transaction function selected by a client. Conventional on-screen images also typically contain text or graphics representing options that a client can select. These textual or graphical options usually contain lines or other characters that extend to the edges of the screen image near one of the function keys 166. The user can select options by pressing the function key that is indicated by this selectable option. Similarly, as with the automatic banking machine, the user can enter alphanumeric characters that contain the LIN, as well as digital information about the amount and other commands, by pressing the keys on the auxiliary keyboard 168.

 In one embodiment of the present invention, the automatic banking machine software converts standard BM key inputs to operating system events, such as a mouse click in the right place or QWERTY type keyboard input. The software components that perform this function are depicted in FIGS. 28-30. These functions comprise a specialized program of the auxiliary keyboard 170. The specialized program of the keyboard 170 in the described embodiment is contained among the specialized programs of the terminal directors 144. The specialized keyboard 170 provides a subset of the functionality of the keyboard common device interface.

 A specialized keyboard program 170 coordinates the keyboard command server that operates in the financial transaction services application system 146. The server in the financial transaction services application system communicates with a common device interface for the auxiliary keyboard and function keys 172. The keyboard general device interface in the preferred embodiment is JAVA , which is called the "collapse" for the general device interface related to the function keys and to the auxiliary no keyboard.

 The software also includes a keyboard mapper 174. A keyboard mapper in a preferred embodiment is associated with a database 176 that stores a plurality of mappings. In a preferred embodiment, the keyboard mapping program is a continuation of the keyboard class of objects used to operate the keyboard. The keyboard mapping program remembers a plurality of keyboard mappings in the database 176. This is accomplished by reading information in the configuration database for the BM to obtain keyboard mappings operating in a particular apparatus. In operation, the keyboard display program selects one of the keyboard images as the current option. This is done in response to a specialized auxiliary keyboard program and is based on the commands in the GPTT entries that are selectively accessed. The keyboard mapper can select keyboard mappings when responding to AOGT documents downloaded through a browser. The keyboard display program also activates the keypad and function keys corresponding to the particular selected keyboard display configuration. The keyboard display program also acts in response to the selected keyboard display configuration to convert the input of the auxiliary keyboard or input of the function key to the corresponding input of the keyboard or mouse, which is then delivered to the keyboard input stream or mouse input stream of the operating system of the computer in which this software.

 In a preferred embodiment, each keyboard display consists of randomized tables. Keyboard display objects are stored as values in randomized tables, as a result of which each object contains the values and operations necessary to convert any corresponding BM key events to an input event of the operating system.

 It should be noted that in the case of function keys near the screen image in the BM, it may be desirable to provide input from the mouse into the input stream of the mouse, which corresponds to a specific coordinate location of the mouse input. This is achieved using a keyboard mapping program using a selected set of keyboard mappings. Different sets of keyboard mappings drive different function keys to provide different types of inputs to a computer operating system that responds to an AOGT document displayed in a browser. Further, as a result of the keyboard mapping program, pressing the selected key generates an input corresponding to a mouse click at the selected x position, at the coordinate on the screen image. It should be noted that to form mouse inputs, you can use either the keys of the auxiliary keyboard or function keys. Similarly, function key inputs can be converted to keyboard inputs. In some implementations, however, it will be desirable to turn off the mouse indicator on the screen image, as a result of which the user will not see a normal mouse image. In some implementations, this shutdown may include reducing the size of the mouse image, which is so small that it can not be immediately seen by the user of the device.

 During some stages of a financial transaction, the user may not need to press any keys. In these situations, some preferred embodiments of the invention turn off the keys of the keypad and / or function keys. Since computer resources are used to poll these keys for inputs, the termination of this survey within appropriate time periods causes the computer resources to switch to other functions. This will increase the speed at which other actions can be performed. This can be done in some implementations by means of a specialized auxiliary keyboard program that removes keyboard devices from the questionnaire.

 28-30 schematically depict examples of the operation of the keyboard display program and the specialized auxiliary keyboard program. Fig. 29 depicts an example of input into the auxiliary keyboard 168. In this example, the specialized program of the auxiliary keyboard 170, mainly when responding to commands in the HRTT record, such as AOGT documents or other events, transmits and drives events in the financial transaction services application system 146. In response to this display, the keyboards are selected from the database 176 corresponding to the particular display name. The keyboard command server also activates the corresponding BM keys.

 In this example, in response to the client pressing the OK button on the secondary keyboard, the common device interface generates a corresponding signal to the financial services application system. From the image of Fig. 27, it follows that the "OK" key corresponds to the "J" key of the BM interface. The financial services application system transmits a signal generated by pressing the "J" key by the client to the keyboard mapping program 174. When responding to the reception of this signal, the keyboard mapping program resolves the object in a set of mappings corresponding to the display name, which converts the input signal of the function key to the keyboard input signal that is recognized by the operating system. By calling the selected object from the set of images, the input keyboard signal is generated and delivered to the keyboard stream of the computer. This is represented by keyboard stream 178. In the depicted implementation, the keyboard stream is input to the Windows NT operating system. A specialized keypad 170 program detects input using its key detection program. Specialized program 170 also receives the event and can display an image or other graphic corresponding to the input made by the client.

 Fig. 28 depicts the operation of a keyboard mapping program in situations where the financial transaction services application system prevents the transfer of data entered by the client to the specialized program 170. This may be desirable, for example, in situations where the input made by the client is the client LIN or other data which do not need to be displayed. In these circumstances, the financial services application system 146 remembers the data entered by the client and sends back to the browser only the signal that represents the memorization symbol, in this example, the symbol "*". This is done selectively when responding to commands contained in documents that were accessed by the browser, or in other records of the CCP, accessed by a computer, indicating that the client input corresponds to its LIN, or other data that should not be sent to browser. In the example of FIG. 28, only a remember sign is transmitted to the browser through the keyboard mapping program. In situations where the CCPT record that has been accessed causes methods in which the digital values must be sent to the browser and / or displayed on the screen (such as the sum of the financial withdrawal transaction), a signal sent by the financial transaction services application system , indicates a numerical value related to the pressed key.

 FIG. 30 is another example of the operation of a keyboard display program: in this case, the input corresponds to the function key 166. In this case, the input is made by pressing the function key "A", which is shown near the upper right corner of the screen image in Fig.27. The signal generated by responding to the press of this function key is sent to the keyboard mapping program, which, when responding to data received from the data storage device 176, outputs mouse input corresponding to a mouse click. Input from the mouse contains data characterizing the x and y coordinates on the screen image on which you want to click the mouse. The input from the mouse is sent to the input stream from the mouse 180.

 It should be noted that for the introduction of an automatic banking machine that processes AOGT documents so that it works using the standard BM interface, mouse input usually contains coordinate locations that correspond to the location on the screen image near a certain function key. This is because the image, line, text or other characters selected by the client by pressing the key will preferably appear or continue on the screen image near the key. Thus, using the visual representation, the client becomes aware of which key to press in order to make the appropriate choice. A number of function keys near the screen image can work at any one time. The client can make a selection by pressing a function key in one location, and then a function key in another location outside the first location. As a result of this, the signals will be sent to the stream from the mouse in accordance with the clicks on the coordinates of the screen image near the function keys pressed by the client. During financial transactions, various combinations of the function key and the auxiliary keyboard key can act and be displayed in various keyboard and mouse inputs in accordance with the definition made by the selected sets of displays. In addition, developers can develop special sets of mappings that correspond to a specific displayed graphic in the TSP documents.

 In this way, the inputs of the auxiliary keyboard into the auxiliary keyboard of a conventional BM or other automatic banking machines can be converted into conventional keyboard or mouse inputs that can be identified and processed in a conventional keyboard input stream or input stream from the mouse to the computer. Similarly, function keys can be converted to mouse inputs at selected locations and delivered to the input stream from a mouse for processing by a computer, or they can be converted to keyboard inputs and delivered to an input keyboard stream. Another advantage of the described configuration of the terminal is that the keys can be selectively turned off at a time when they are not needed. Thus, it is possible to reduce the number of cases of attempts of unauthorized access to the device by pressing the keys on the keyboard. Also, as mentioned earlier, you can turn off the keys when they are not needed to increase the speed of processing financial transactions.

 Another advantage of the embodiments of the present invention is the ability of an automatic banking machine to provide printed documents based on commands in the AOGT documents. These printed documents can be tickets, traveller's checks, money orders, bank checks, temporary types of payment instruments and other types of documents. The ability of the preferred implementations to access and process YAGT documents allows you to print graphic materials or other characters that can form printed documents having selected external characteristics and selected decorative design. This can reduce the need for pre-printed forms and also allows you to print a more diverse range of pre-printed forms. Moreover, the configuration of some implementations of the device allows you to print only selected parts of information about financial transactions in order to keep records in the device, and at the same time provide options, including improved graphics or other characteristics that are attractive to customers.

 FIG. 31 depicts a schematic representation of the system when printing forms using a printer in an automatic banking machine. A preferred embodiment of the invention uses a WIN 32 printer, which operates under Windows NT 4.4. In the exemplary financial transaction, the director's control program class 180, which operates in the terminal theater node 138, initiates the printing of the financial transaction receipt by sending a request to the printer director 182 to print the receipt. The printer director, in one preferred embodiment, is a collection of examples of relevant JAVA commands that perform printing operations, and is one of the directors among terminal directors 144. The printer director contains a printing class that is shown diagrammatically separately and that invokes the EPM printing method. The printer class in a preferred embodiment includes access to a shared financial transaction data object that contains specific client information about financial transactions, including characters that characterize information to be printed. In the case of an automatic banking machine, this can be an example of characters that characterize information that is read from input into the machine from a customer’s card and read by a card reader. For example, this could be a customer name and account number. Other information on financial transactions may contain the types of financial transactions performed, such as a deposit, withdrawal from an account or a request for the amount of the balance, and also the amount involved in each relevant transaction.

 The financial services application system 146 receives a print request and sends the EPM sequence to the WIN 184 printer using the EPM printing method. The address of the ESMA in one preferred embodiment is the address of the CCPT record, such as a BAG document, which will be used to format the document to be printed, in this case the receipt. This AOGT document contains an embedded JAVA text driver that processes financial transaction data from a financial transaction data object. The address of the EUPM of the document can be located in the local device, or it can be obtained by sampling from another server, for example, via network 186. Network 186 can be a local network or a wide-area network depending on the configuration of the device.

 The WIN 184 printer then searches for the address of the document to be accessed. This is done in a preferred embodiment using the Microsoft Web Browser2 ActiveX control program. After loading the AOGT document, the ActiveX method automatically starts processing the contents of the document that has been accessed. The financial services application system 146 invokes a method for printing the EPPF of the WIN 184. The WIN printer uses the ActiveX control program to print the current AOGT document. This printing process is handled by the printing paging program and Windows NT graphics components.

 The common JAVA device interface receives an event from the print control component 192, which indicates the completion of the swap for printing. This indicates that the file is now ready to be read and sent to the general interface of the receipt printer devices 188.

 Then, the printer object 190 calls the data reading function in the print manager 192 to determine the location and size of the print data file. The printer object 190 directs the data or the path name of the data file to the common interface of the printer devices 188. The common printer device interface 188 then transfers the print data to the printer equipment. As a result, the document is printed.

 After printing the receipt, a specialized program from the director of the printer 182 gives a request for delivery of the printed receipt. The delivery request is sent through the financial services application system 146 to the printer object 190. The printer object 190 calls the delivery method in the common interface of the printer devices 188 to deliver a receipt to the user of the device. The action of the software components makes it possible to selectively access document formats and also selectively use the commands contained in documents to include financial transaction data in printed documents. This makes it possible to generate documents of various types. It also makes it possible to provide printing of different types of documents for different clients. This may be desirable when providing marketing information, coupons, or similar marks on financial transaction receipts. This solution also simplifies the provision of printed formats in different languages through the development of AOGT documents that provide printed forms in different languages. In addition, the methods of this invention can be used to provide marketing to customers for certain characteristics or types of customer categories, and also on a single basis.

 Although the printing method described above is characterized in connection with the delivery of receipts of financial transactions, similar methods can be used to print balances for customers and also to print a journal of financial transactions in an automatic banking machine. By accessing selected documents that control the print format, journal information records can be provided with consolidated information in such a way as to save “journal” paper in the machine by canceling the printing of advertising information and other types of information that are provided on customer documents.

 The printing method of the present invention also allows the printing of various types of optical characters, such as a barcode, or other machine readable characters that can be used to print coupons, checks, or similar documents. This coding can help track the use of these documents by customers in order to evaluate the effectiveness of various marketing activities. In addition, machine readable signs can be used to print them on documents such as deposit envelopes and / or financial transaction logs. This printing may facilitate reading of these documents by a machine for checking the contents of contributions.

 The printing characteristics provided by the methods of the present invention also enable the printing of selected graphic materials. This may include sample materials, which include embedded digital signatures that can be used to verify the authenticity of printed documents. This can be especially useful, for example, in situations where the machine is used to print temporary cash, travelers checks, coupons about bets or other documents of independent value. In addition, full-color printed documents can be generated by providing a color printer in the financial operations apparatus.

 The computer software used in the operation of the automated banking machines of the present invention and in connected computers can be downloaded from various types of devices to the respective computers. This computer software may be contained in, and downloaded from, one or more devices, such as floppy disks or CDs. This software may also be contained in devices such as hard drives, tapes, and ROM devices. Other devices that contain data describing instructions for driving computers as described herein are suitable for use with financial apparatuses and systems in accordance with embodiments of the present invention.

 Cited as examples of embodiments of automatic banking machines and systems described herein are given with reference to specific components and characteristics of the software. Other implementations of the present invention may contain other, or different from those described, software components that provide similar functionality.

 Thus, the new automatic banking apparatus and the system of the present invention provide the above objectives, eliminate the difficulties encountered when using devices and systems of the prior art, solve problems, achieve the desired results described here.

 In the foregoing description, certain terms are used for brevity, clarity, and explanation. But from these terms, any unnecessary restrictions should not follow, since these terms are used for illustrative purposes and are subject to wide interpretation. The description and explanations set forth herein are given as examples, and the invention is not limited to the details described here.

 In the following claims, any indicated feature described as a means of performing a function should be construed as including any means capable of performing the specified function, and is not considered limited to the specific tool mentioned in the above description, or only its equivalents.

 After describing the characteristics, discoveries and principles of the present invention, the method of its construction and operation, the benefits provided and the achieved useful results, new and useful structures, devices, elements, layouts, details, combinations, systems, equipment, operations, methods, processes and relationships are described in the attached claims.

Claims (22)

 1. Automatic banking apparatus, including a computer connected to a storage device and to an input device for receiving user input and a sheet issuing mechanism, characterized in that the computer is designed to access at least one address of the hypertext transfer protocol ( НТТР) to the commands of the device for making financial transactions, and the software executed in the computer contains the first object for controlling the input device, intended for bringing into action an input device, and a second object for controlling the sheet issuing mechanism, designed to actuate the sheet issuing mechanism in response to said commands, the software also comprising a financial transaction data object associated with the first software object and the second software object , while the data object of the financial transaction is designed to store user input received by the said device yes, and data sheet dispensing mechanism for dispensing sheets in memory.  2. The device according to p. 1, characterized in that the software contains a browser, and the computer is designed to access the address of HTTP via a browser.  3. The device according to claim 2, characterized in that at least one command of the financial transaction device is contained in a document in hypertext markup language (HTML) transmitted over the network to an automatic banking device.  4. The apparatus according to claim 1, characterized in that the input device comprises a card reader, and the data object of the financial transaction contains card data read by the card reader.  5. The apparatus according to claim 1, characterized in that the software includes a third object designed to access data in the specified data object of the financial transaction.  6. The device according to claim 5, characterized in that the device contains a printer, and the third software object is designed to control the printer and activate it to print data corresponding to the data stored in the data object of financial transactions.  7. The device according to claim 1, characterized in that the device contains at least one Hypertext Transfer Protocol (HTTP) server, the HTTP address corresponding to a server intended for accessing through it to a plurality of financial transaction device commands, the computer being designed to access the first commands of the financial transaction device at the first HTTP address and to the second commands of the financial transaction device at the second HTTP address, the first program object is both sintering is designed to control the input device in response to the first commands of the financial transaction device, and the second object is intended to control the mechanism for issuing sheets in response to the second commands of the financial transaction device.  8. The apparatus according to claim 7, characterized in that the software also comprises a browser, the computer being designed to access the first and second commands through a browser.  9. The apparatus of claim 1, wherein the apparatus comprises an auxiliary office processing system associated with a computer, the software of which is designed to transfer at least a portion of the data stored in the financial transaction data object to the auxiliary office processing system.  10. The apparatus according to claim 1, characterized in that the instructions of the financial transaction device include an application in the Java language.  11. The method of operation of the automatic banking apparatus, which consists in activating the first device for making financial transactions when responding to the first commands to activate the first device for making financial transactions, while access to the commands is carried out by the computer in the device at the first address of the Hypertext Transfer Protocol (HTTP) , the formation of the first financial transaction data using the first financial transaction device and storing said first data in volume data of the financial transaction in the storage device associated with the computer.  12. The method according to p. 11, characterized in that the first financial transaction device is a sheet issuing mechanism, and the first data characterizes the issuance of at least one sheet by a sheet issuing mechanism.  13. The method according to p. 11, characterized in that the second device for performing financial transactions in the said apparatus is actuated in response to commands to activate the specified second device, accessed by a computer at the second address of HTTP, form the second financial performance data operations using the second financial transaction device and store the second data in the financial transaction data object in the storage device.  14. The method according to p. 13, characterized in that the first financial transaction device contains a card reader, and the second financial transaction device contains a keyboard, the first data containing card data read from the card, and the second data containing data characterizing the input from the keyboard.  15. The method according to p. 11, characterized in that they access the data contained in the data object of the financial transaction using software running on the computer, and control the second device for performing financial transactions using the computer when responding to the data object of the transaction financial transactions and the data of the specified object.  16. The method according to p. 15, characterized in that the second financial transaction device includes a printer that is designed to print characters that correspond to the data in the financial transaction data object.  17. The method according to p. 11, characterized in that the computer contains a browser, while the computer accesses the first HTTP address using a browser.  18. The method of operation of an automatic banking machine, which consists in accepting user identifying data by an automatic banking machine, storing the mentioned data corresponding to the identifying data in the data object of the financial transaction of the computer software of the device, conducting the first financial transaction in response to the user data entered to the said device, and when conducting the first financial transaction, access to the data in the object is yes GOVERNMENTAL fulfillment software transaction.  19. The method according to p. 18, characterized in that during the first financial transaction, the first financial transaction device is activated and the data corresponding to the operation of the first financial transaction device is stored in the data object of the software financial transaction.  20. The method according to p. 18, characterized in that the second financial transaction is carried out in response to the user data entered, and during the second financial transaction, access is made to the data in the data object of the financial transaction of the software.  21. The method according to p. 18, characterized in that they provide a report on the first financial transaction made by the user and send the data of the financial transaction data object from the computer to the server.  22. The method according to p. 18, characterized in that they form a printed record corresponding to the first financial transaction made using the apparatus, while accessing the data in the data object of the financial transaction and form characters in the printed record, respectively, at least in part data stored in the data object of the financial transaction.

Images