CN1989530A - Cash dispensing automated banking machine diagostic system and method - Google Patents

Abstract

An automated banking machine (10) includes a cash dispenser (54). Servicing the machine is facilitated through use of a portable diagnostic article (98) which enables the controller to access diagnostic data stored in memory and which provides data indicative of the significance of the diagnostic data. A portable article of computer readable and writable media (314) is also operative to cause the computer to gather data concerning the banking machine and record it on the media through a drive (312). The data gathered is then analyzed by a separate analysis computer (324).

Description

Cash dispensing automated banking machine diagnostic system and method

technical field

The present invention relates to automated banking machines. More particularly, the present invention relates to automated banking machine devices, systems and methods that provide improved reliability and maintainability.

Background technique

Automated banking machines are well known. A common type of automated banking machine used by consumers is an automated teller machine ("ATM"). ATMs enable consumers to perform banking transactions. Examples of banking transactions commonly accomplished using an ATM may include cash dispensing, deposits, transfers between accounts, bill payments, check cashing, cash receipts, purchase of money orders, purchase of stamps, purchase of tickets, purchase of phone cards, and account balance inquiries. The types of banking transactions that a user can complete at an ATM depend on the specific banking machine, the system to which the machine is connected, and the programming of the machine by the entity responsible for its operation.

Other types of automated banking machines can operate in other types of environments. For example, certain types of automated banking machines may be used in customer maintenance environments. For example, certain types of automated banking machines may be used to count currency or other items received from or to be given to customers. Other types of automated banking machines are used to authenticate items of access, value, or privileges offered to customers, such as tickets, vouchers, checks, or other financial instruments. Other examples of automated banking machines may include machines operable to provide goods or services to authorized users in an attended or self-service environment. For the purposes of this disclosure, automated banking machines shall be considered to include all machines operable to effect transactions including transfer of value.

ATMs may include various types of transaction function devices. These devices are operable to perform transactions. Different types of ATMs include different types of devices. These different types of devices enable the ATM to perform different types of transactions. For example, some types of ATMs include depositors to accept deposits, while other ATMs do not include such a device. Some ATMs have "touch screens" while others have separate displays and enter buttons. ATMs may also be equipped with devices such as cash and coin acceptors, statement printers, check validators, bill acceptors, fingerprint readers and other types of devices that other ATMs do not include.

Many financial institutions wish to add new functionality to their existing ATMs. For example, a bank with ATMs for dispensing cash may wish to add a list printer for each ATM that prints the user's bank list. Typically, such new functionality requires additional software modifications to the ATM in addition to new hardware. Unfortunately, because many financial institutions purchase ATM hardware from more than one manufacturer, the process of updating ATM software is often complicated. Thus, in order to add new software for performing new functions, such as printing bank statements, different application programs must be written or modified for each vendor's specific ATM platform. Compounding this complexity, vendor-specific ATM platforms can similarly incorporate transaction function devices from a variety of other sources, so there can also be significant differences in the drivers of vendor-specific transaction function devices within a vendor-specific ATM platform . Migrating applications to multiple ATM platforms significantly reduces the productivity of ATM software developers. Therefore, there is a need for a framework that enables developers to write ATM applications that can be used with minimal modification on multiple proprietary ATM platforms with multiple proprietary transaction function devices.

To achieve this goal, industry standards can make ATM hardware and software compatible across vendors. An example of such a standard is WOSA/XFS (Window OpenService Architecture/eXtensions for Financial Services), which was developed by the CEN/ISSS XFS Standards Committee. Figure 26 shows a schematic diagram of an exemplary WOSA/XFS structure. An exemplary WOSA/XFS enabled ATM 1110 may include a WOSA/XFS manager 1112. WOSA/XFS Manager 1112 includes a standard interface for enabling ATM terminal application 1114 to communicate with ATM transaction function 1116 . Each transaction function 1116 includes a corresponding maintenance provider interface component 1118 . The maintenance provider 1118 is provided by the supplier of the ATM device 1116 and is specifically designed to receive requests from the WOSA/XFS manager 1112 and pass these requests on to the corresponding device 1116 . Theoretically, the ATM terminal software application 1114 can run on any vendor's ATM hardware 120 as long as the ATM terminal application 1116 and the vendor's maintenance implementation vendor 1118 comply with the WOSA/XFS specification.

Another example of an emerging industry standard for ATM hardware/software architecture is J/XFS (Java/eXtensions for Financial Services). Unlike WOSA/XFS, which is specially designed for the Microsoft Windows ^(R) platform, J/XFS is a Java-based architecture that can be implemented on any hardware/software platform that supports Java ^(R) Virtual Machine (JVM). As shown in Figure 27, an exemplary J/XFS enabled ATM 1210 may include a J/XFS Kernel. The J/XFS Kernel is similar in function to the previously described WOSA/XFS manager 1112 . However, J/XFS Kernel runs in JVM 1224. The J/XFS Kernel is operable to respond to instructions from the ATM terminal software application 1214 to enable the device maintenance layer 1220 to control the operation of the ATM device 1216 . As with previously described maintenance providers 1118 , device maintenance layer 1220 includes vendor-supplied device maintenance 1218 corresponding to vendor hardware devices 1216 .

In general, the previously described XFS architecture defines the lowest common denominator criteria for ATM hardware characteristics. Unfortunately, by only including these features common to all ATM hardware devices, the XFS standard cannot include an interface to unique features associated with a particular implementation of a vendor's transaction function device. One example of a unique feature not implemented in the XFS interface includes access to low-level diagnostic tests of various hardware components of the device. This control over the underlying hardware functionality can be very important when troubleshooting specialized components such as motors or sensors. Unfortunately, the XFS standard has not attempted to implement a method for testing the underlying vendor-specific hardware since each vendor may mechanically and/or electronically construct a particular type of device completely different from the other.

There is a need to keep automated banking machines operational at all reasonable times as possible. If a machine experiences a breakdown, it is advantageous to have the machine returned for maintenance as soon as possible. The inability to perform low-level diagnostic tests, and wide variations in the methodology and performance of vendor-developed transaction function device diagnostic test methods can cause significant delays in diagnosing and resolving these failures. Thus, there is a need for low-level diagnostic tools and testing methods for ATM hardware that can be used in single-vendor or cross-vendor XFS-enabled terminals. Improvements are also needed in the operation, reliability, maintenance and repair of automated banking machines. In addition, there is a need to analyze ATM problems and the ability to predict problems before they occur.

Contents of the invention

An object of an exemplary embodiment of the present invention is to provide an automated banking machine.

Another object of an exemplary embodiment of the present invention is to provide an automated banking machine which provides for improved maintenance.

Another object of exemplary embodiments of the present invention is to provide an automated banking machine capable of controlling the temperature of machine components to extend service life.

Another object of an exemplary embodiment of the present invention is to provide an automated banking machine that provides reliable lighting of the transaction area while facilitating maintenance of the machine.

Another object of exemplary embodiments of the present invention is to provide an automated banking machine which facilitates the detection of attempted fraudulent actions on the machine

Another object of exemplary embodiments of the present invention is to provide a structure comprising a standardized low-level interface for hardware devices manufactured by multiple vendors.

Another object of exemplary embodiments of the present invention is to provide an automated banking machine with improved diagnostic capabilities.

Another object of exemplary embodiments of the present invention is to provide an automated banking machine capable of reducing the risk of unauthorized access to the device and operation of the banking machine.

Another object of exemplary embodiments of the present invention is to provide a system and method for analyzing characteristics of an automated banking machine.

Other objects of the exemplary embodiments will become apparent in the following detailed description and claims.

The above objectives are achieved in some exemplary embodiments by an automated banking machine being an ATM. An ATM includes a plurality of transaction function devices. In an exemplary embodiment, the transaction function means includes input and output means, which are part of the user interface. In an exemplary embodiment, the transaction function means also includes means for performing various types of banking functions, such as money dispenser means (also referred to herein as cash dispensers), and deposit accepting means. Exemplary embodiments of the ATM also include at least one computer, generally referred to herein as a processor or controller, and operable to cause transaction functions within the machine to operate.

In some exemplary embodiments, the controller may include a module interface framework that provides a unified interface between the ATM application and a plurality of modules, typically including transaction function devices. The exemplary module interface framework includes a device server that operates as a device scheduler and manager. The device server may be accessed by a terminal application, an XFS maintenance provider package (SP), and/or a diagnostic application through at least one module interface application programming interface ("API"). The device server is operable to selectively direct the operation of the transaction function device by using a module interface component corresponding to the transaction function device. The use of a modular interface framework enables the use of a consistent set of commands by one or more applications to control multiple vendor-specific transaction function devices that can be incorporated into any stand-alone ATM.

In some embodiments, a cross-vendor ATM terminal application needs to be used, in which case an XFS layer can be used between the ATM terminal application and the module interface framework or in parallel with the module interface framework, which uses the Maintenance provider for each transaction function device.

In some embodiments, an improved diagnostic system may be provided to authorized maintainers of machines. Improved diagnostic systems may include security features to reduce the threat of unauthorized persons using a machine's maintenance and diagnostic capabilities for unauthorized purposes.

In an exemplary embodiment, an authorized maintainer is provided with a portable diagnostic item bearing computer readable instructions, such as a CD, DVD, smart card, portable storage device, compact flash, portable hard drive, portable computing device, or any other operatively A portable device that provides diagnostic information to the ATM. When the machine is to be serviced by an authorized maintainer, the portable diagnostic item is placed into operative engagement with the diagnostic item reading device. The reading means may include, for example, a CD drive located within the box portion of the ATM housing. This exemplary method may reduce the risk that persons not authorized to use the cabinet area will be able to use the diagnostic item reading device. However, in other embodiments, other methods may be used.

In an exemplary embodiment, the diagnostic item provides one or more passwords to the controller of the machine. These codes can then be processed by operation of the controller to determine if the diagnostic item is authorized. In some embodiments, the maintainer may also be required to enter identification information through one or more input devices on the ATM. Such identifying information may also be used to determine whether a diagnostic item is authorized. Additionally, in some exemplary embodiments, the code in the diagnostic article may be date, location, and/or device sensitive so that it can only be used at specific times and/or for specific durations, on specific machines, or only for machines Some devices of the can use diagnostic items with codes. Of course, these security procedures are exemplary only, and in other embodiments other or additional approaches may be used.

In some embodiments, the ATM controller sensitive to identification of the diagnostic item is operable to enable the machine to output protected diagnostic data stored in one or more data stores within the machine. This may include, for example, information about the performance of the device, information about sensed or recent failures, data about statistical operating trends of various transaction function devices, and/or other information to prevent future failures. In an exemplary embodiment, this diagnostic data is stored in the machine's data storage in a protected manner to prevent unauthorized access to the machine. However, when the machine is combined with an authorized diagnostic item, these data, or information based on these data, can be passed through an output device on the machine (such as a screen), and/or other devices (such as a portable terminal or mobile phone carried by the maintainer) And the output.

In some exemplary embodiments, in response to confirmation of the diagnostic item, the ATM controller is operable to enable the machine to switch to the diagnostic application. Diagnostic applications may include, for example, graphical representations of systems, modules, and block states by displaying system, or graphical representations of selected modules or blocks. Additionally, the diagnostics application may include icons that identify portions of the system, module, or chunk where more information is available, or where diagnostic tests or other options are available. In some embodiments of the diagnostic application, the options available to the maintainer may include the ability to instruct the transaction function device to selectively perform one or more underlying actions (such as turning on lights, motors). In some embodiments, the availability of such information may be displayed by other output means, such as textually or audibly or audibly. In some embodiments, such information, tests, or other options may be accessed or enabled by touching or clicking on an associated icon or textual description. In some embodiments, the available information includes suggested recovery actions ranked by likelihood. Such a diagnostic application may also switch from a graphical diagnostic and testing mode to a non-graphical diagnostic and testing mode in response to maintainer input.

In some exemplary embodiments, the diagnostic item also includes maintenance data for diagnosing and/or correcting problems that have or may have occurred with the machine. In some embodiments, maintenance data may be included in or used in conjunction with electronic maintenance manual data describing various characteristics of the machine, as well as instructions for corrective action and predictive maintenance. In some embodiments, maintaining data may include at least one diagnostic test operable to enable a controller within the machine to perform one or more transaction function devices. In some embodiments, the maintenance data is also operable to cause the controller to output suggested remedial actions or to recommend further testing based on one or more results of the diagnostic tests. In some embodiments, the diagnostic application is operative to display relevant maintenance manual data in a browser window in response to selection of a restoration action by a maintainer. In another exemplary embodiment, a maintainer may be enabled to receive output that facilitates maintenance and maintenance of the machine by viewing maintenance manual data or other information included in or on a diagnostic item.

In some exemplary embodiments, the diagnostic application is made available to various maintainers through the use of a diagnostic toolkit. A diagnostic toolkit can provide generic functionality through the use of sample codes, templates, and upper-level objects in a programming environment such as Microsoft.NET and/or Suns Microsystems JAVA( ^R ). The use of such toolkits enables companies to create diagnostic applications in various languages for various transactional functional devices.

In some exemplary embodiments, a diagnostic item may include maintenance or other data in encrypted form. Various types of standard and non-standard encryption can be used in various embodiments. The controller is operable to decrypt such encrypted data to facilitate output of the data from the ATM. Also in some exemplary embodiments, the diagnostic article may include browser software thereon. Such browser software can be loaded from the diagnostic item to the machine's controller and used to interpret maintenance data from the diagnostic item. In some embodiments, the browser software is operable to interpret embedded indications of non-public and/or non-standard properties that may be included within the maintenance data. This can facilitate providing maintenance data on diagnostic items while preventing access by unauthorized users. In some exemplary embodiments, the diagnostic article may also include features that prevent browser software and/or maintenance data from being persistently loaded onto another computer and/or are operable to cause the diagnostic article to be removed while in operable engagement with the computer. , to enable these items to be deleted from the computer's memory.

In some exemplary embodiments, a computer device separate from the ATM may utilize the diagnostic item. For example, devices such as notebook computers, PCs, PDAs or mobile phones may be included. In such exemplary embodiments, such devices may use maintenance items to provide access to maintenance data thereon, such as electronic maintenance manuals. Provisions for security may be set in a previously discussed manner or otherwise to ensure that diagnostic items are not used by unauthorized users. Additionally, in an exemplary embodiment, when the maintenance item is installed in connection with a computer device other than the ATM, an indication from the maintenance item (which may be used to interact with the ATM's controller and transaction function device) may be rendered inoperable .

In some exemplary embodiments, a machine may be used to output data associated with the machine for performing various types of analysis. These analyzes may include, for example, identifying errors in setting structural parameters of a machine, identifying malfunctions in the operation of a transaction function, and/or predicting future needs to maintain one or more transaction functions in a machine. These analyzes can be performed by one or more computers within the machine or by separate computers. In an exemplary embodiment, a removable computer-readable medium includes instructions operable to cause at least one computer of the machine to collect data and write indicia corresponding to the data on the removable computer-readable medium. In an exemplary embodiment, the machine includes a read/write device, such as a CD read/write drive. In response to the removable medium including instructions to be entered into the drive by an authorized maintainer, the instructions are operable to cause at least one computer in the machine to create one or more processing threads. The processing thread is also operable to create one or more temporary files in the one or more memories. The processing thread is operable to gather data about configuration characteristics, device operation, or other characteristics associated with the machine and include them in a temporary file in at least one data store of the machine.

In an exemplary embodiment, the instructions are further operable to cause at least one computer to generate an output indication that data is to be collected via an output device of the machine, such as on a screen viewable by a machine maintainer. Whenever data is collected, the exemplary embodiments are operable to cause at least one computer of the machine to protect the data, such as by password protection and/or encryption, and to write a tag corresponding to the collected data into the available on removable media. Thereafter, the directive operatively closes the temporary file and terminates the processing thread.

In an exemplary embodiment, the removable media may then be moved to a separate analysis computer. The analysis computer can recover data from the signatures and then analyze errors in the process of configuring parameters, failures in device operation, and/or analyze and predict future maintenance needs of one or more transaction function devices in the machine. In response to this information, appropriate corrective actions may be taken, such as correcting configuration settings, repairing devices to correct faults, and/or performing maintenance actions to avoid potential functionality that may arise based on predictive analysis.

It should be understood that the above-mentioned objects and examples are only exemplary, and the embodiments of the present invention need not meet all or any of the above-mentioned objects, and need not include all or any of the above-mentioned exemplary characteristics. Within the scope of the claims, a person skilled in the art may relate to other aspects and embodiments based on the teaching given here.

Description of drawings

Figure 1 is an exterior isometric view of an exemplary embodiment of an automated banking machine as an ATM.

FIG. 2 is a front plan view of the ATM shown in FIG. 1. FIG.

Figure 3 is a transparent side view diagrammatically showing some internal features of the ATM.

FIG. 4 is a schematic diagram showing the software structure of the exemplary embodiment.

Figure 5 is a front view showing the fascia portion moved to enter the first portion of the upper housing of the machine.

6 is a partially transparent side view showing air flowing through the air cooling openings of the machine.

Figure 7 is an isometric view showing a baffle structure used in an exemplary embodiment.

Figure 8 is an isometric view showing the pallet portion in an operable position adjacent to the bulkhead.

Figure 9 is a transparent rear isometric view showing a blower, air opening and air moving duct within the housing of the exemplary embodiment.

Figure 10 is an isometric view of the components of the ATM shown in Figure 1 with the upper housing portion removed, and which shows the lighting system for the transaction area supported on the chest portion of the housing every aspect.

Figure 11 is a schematic side view of the housing diagrammatically showing the lighting system for the transaction area and partly in section showing movement of the upper pallet portion to provide access for maintenance.

12 and 13 show schematic diagrams of exemplary embodiments of logic that may be used to maintain a machine using diagnostic items.

FIG. 14 is a schematic diagram of the lighting and anti-spoofing sensing arrangement of a card reader slot of an exemplary embodiment.

Figure 15 is a schematic side view of an unauthorized card reading device operably connected to the housing of the anti-spoofing sensor.

Figure 16 is a schematic diagram of an exemplary embodiment for detecting the presence of an unauthorized card reading device proximate to a card reader during operation of an ATM.

Figure 17 is a schematic diagram representing the software architecture of an exemplary embodiment.

Figure 18 is a schematic diagram representing the software architecture of an exemplary embodiment.

Figure 19 shows a typical system status screen for the Diagnostics application.

Figure 20 shows a typical module status screen for a diagnostics application including information icons.

Figure 21 shows a typical system status screen of a diagnostics application including problem icons.

Figure 22 shows a typical module status screen of a diagnostics application including an unknown problem icon and suggested recovery actions.

Figure 23 shows a typical diagnostic application text screen.

Figure 24 shows a typical item that can be displayed in a browser.

FIG. 25 is a schematic diagram representing the software architecture of an exemplary implementation of the diagnostic toolkit.

Figure 26 is a schematic diagram representing an exemplary WOSA/XFS enabled ATM.

Figure 27 is a schematic diagram representing an exemplary J/XFS enabled ATM.

Figure 28 is a schematic diagram representing an exemplary embodiment of an XFS enabled ATM.

Figure 29 is a schematic diagram illustrating an exemplary embodiment of a terminal application including an exemplary reader TEC interacting with exemplary ODS components.

Figure 30 is a schematic diagram representing an exemplary embodiment of a diagnostic application.

Figures 31 and 32 illustrate exemplary embodiments of output by the ATM's display device produced by the diagnostic application.

Figure 33 shows an exemplary embodiment of an ATM including a security manager application.

Figure 34 is a schematic diagram representing an ATM system with data associated with automated banking machines collected and analyzed by a maintainer therein.

35 is a schematic diagram of an exemplary logic flow executed by an automated banking machine in response to a removable diagnostic item operable to cause the machine to collect data and store indicia corresponding to the data on the item.

36 is a schematic diagram of an exemplary logic flow executed by an analysis computer in the process of analyzing data collected in an automated banking machine.

Detailed ways

Referring now to the drawings, and in particular to FIG. 1 , there is shown an exemplary embodiment of an automated banking machine generally indicated at 10 . In the exemplary embodiment, automated banking machine 10 is a drive up ATM (drive up ATM), however, the features described and claimed herein are not limited to this type of ATM. The exemplary ATM includes a housing 12 . The housing 12 includes an upper housing region 14 and a secure box portion 16 in a lower portion of the housing. Access to the box portion 16 is controlled by a box door 18 which, when not locked by authorized personnel in the manner described later, can provide access to the interior of the box area.

The exemplary ATM 10 also includes a first tray portion 20 and a second tray portion 22. As will be described later, each tank section is movably mounted relative to an enclosure which, in the exemplary embodiment, facilitates maintenance.

The ATM includes a user interface generally indicated at 24 . An exemplary user interface includes an input device such as a card reader 26 (shown in FIG. 3 ) operatively connected to a card reader slot 28 (extending in the second tray portion). Other input devices of the exemplary user interface 24 include function keys 30 and a keyboard 32 . The exemplary ATM 10 also includes a camera 34, which may be used as an input device for biometric characteristics and the like. The exemplary user interface 24 also includes an output device such as a display 36 . The display 36 is viewable by an operator of the machine when the machine is operatively connected to the opening 38 in the second pallet portion 22 . Additionally, output devices in the exemplary user interface include a speaker 40 . The headphone jack 42 also serves as an output device. The headphone jack 42 may be connected to headphones provided by a visually impaired user to provide voice guidance to the user during operation of the machine. The exemplary machine also includes a receipt printer 44 (receipt printer) (see FIG. 3 ), which is operable to provide a user of the machine with a receipt for transactions performed. The user is provided with a transaction receipt through a receipt delivery slot 46 extending through the second pallet portion. Exemplary receipt printers that may be used in some embodiments are shown in US Patent No. 5,729,379 and US Patent No. 5,850,075, the entire contents of which are hereby incorporated by reference. It should be appreciated that these input and output devices of user interface 24 are exemplary and that in other embodiments other or different input and output devices may be used.

In the exemplary embodiment, the second tray portion 22 has a deposit envelope delivery opening 48 therein. An opening 48 may be provided from a deposit envelope to provide a deposit envelope to a user who may deposit money at the machine. The first pallet portion 20 also includes a pallet lock 50 . A pallet lock 50 is operatively connected to the first pallet portion 20 and restricts access to the first portion of the upper housing area behind the pallet by authorized personnel. In the exemplary embodiment, pallet lock 50 comprises a keyed type lock. However, in other embodiments, other types of locking mechanisms may be used. These other types of locking mechanisms may include, for example, other types of mechanical and electronic locks that open in response to items, inputs, signals, conditions, actions, or combinations or more thereof.

The exemplary ATM 10 also includes a delivery area 52 . The delivery area 52 is connected to a money dispenser device 54 located in the bin portion 16 and shown diagrammatically in FIG. 3 . The delivery area 52 is the transaction area on the machine where currency notes are delivered to the user. In the exemplary embodiment, the delivery area 52 is located in and extends in a recessed pocket 56 in the machine housing.

The ATM 10 also includes a deposit acceptance area 58 (deposit acceptance area). The deposit acceptance area 58 is an area through which deposit envelopes such as to be deposited by the user can be placed in the machine. The deposit acceptance area 58 is operatively connected to a deposit accepting device located in the drawer portion 16 of the ATM. Exemplary types of deposit accepting devices are shown in US Patent No. 4,884,769 and US Patent No. 4,597,330, the entire contents of which are hereby incorporated by reference.

In the exemplary embodiment, deposit acceptance area 58 serves as the transaction area of the machine and is placed in recessed area 60 . It should be appreciated that while the exemplary embodiment of the ATM 10 includes envelope deposit accepting devices and currency note dispenser devices, other or different types of transaction function devices may be included in the automated banking machines and devices encompassed by the present invention. For example, these devices may include: check (check) and/or money order (money order) accepting means, cash accepting means, bill (ticket) accepting means, banknote (stamp) accepting means, card dispensing means, money order dispensing means and Other types of devices operable to perform transaction functions.

In the exemplary embodiment shown in FIG. 1, the ATM 10 includes a number of lighting devices for illuminating the transaction area, some of which will be discussed in detail later. The first tray portion 20 includes an illumination panel 62 for illuminating the opening 48 of the deposit envelope. The second pallet portion 22 includes an illuminated panel 64 for illuminating the area of the receipt delivery slot 46 and the card reader slot 28 . Additionally, the illuminated housing 66 , discussed in detail later, defines the card reader slot 28 . Also, in the exemplary embodiment, an illumination window 68 is located in the recessed region 56 of the delivery area 52 . Illuminated window 70 is located in recessed area 60 of deposit acceptance area 58 . It is to be understood that these structures and characteristics are exemplary, and that in other embodiments other structures and characteristics may be used.

As shown diagrammatically in FIG. 3, ATM 10 includes one or more internal computers. These internal computers include one or more processors. These processors can be operably connected with one or more data stores. In some exemplary embodiments, processors may be located on several devices within the ATM to individually control their operations. Examples such as multi-stage processor systems are shown in US Patent No. 6,264,101 and US Patent No. 6,131,809, the entire contents of which are hereby incorporated by reference.

For the sake of brevity, an exemplary embodiment will be described with a single controller that controls the operation of the devices within the machine. It should be understood, however, that such references should be construed to include multiple controllers and multiprocessor systems that may be adapted to control the operation of a particular machine. In FIG. 3 , the controller is indicated diagrammatically at 72 . Also, as illustrated, a controller 72 is operatively connected to one or more data stores 78 . In an exemplary embodiment, such data storage 78 is operable to store program instructions, values and other information for operation of the machine. Although diagrammatically shows the controller 72 in the upper housing region 14 of the ATM 10, it should be understood that in alternative embodiments the controller may be located within various portions of the automated banking machine.

In order to execute a transaction, the exemplary ATM 10 communicates with a remote computer. The remote computer is operable to exchange messages with the machine and to authorize and record the various transactions that occur. In FIG. 3, the communication of the machine with the bank 78 over the network 76 is shown, and the bank has at least one computer operable to exchange messages with the ATMs over the network 76. For example, the bank 78 may receive one or more messages requesting authorization to enable the user to withdraw $200 from their account. A remote computer at the bank 78 operates to determine whether such withdrawal is authorized and returns one or more messages to the machine over the network 76 authorizing the transaction. After the ATM executes the transaction, the ATM typically sends one or more messages over the network 76 to the bank 78 indicating that the transaction was successfully performed. Of course, these messages are only exemplary.

It should be appreciated that, in some embodiments, the ATM may communicate with other entities over various networks. For example, the ATM will communicate with a computer operated by a maintenance provider 80, as shown diagrammatically in FIG. Such communications may occur over network 76 . These maintenance providers may be entities to be notified of status conditions or malfunctions of the ATM, or entities to be notified of corrective actions. An example of a system for doing this is disclosed in US Patent No. 5,984,178, the entire contents of which are incorporated herein by reference. Other third parties who may receive notifications from an exemplary ATM include entities responsible for delivering money to the machine to ensure that the money supply is not depleted. Other entities may be responsible for removing deposit items from the machine. Alternative entities that may be informed of actions on the machine may include entities holding transaction data about the customer that provide messages corresponding to the transaction messages to be presented to the customer. Various types of messages are provided by the machine to remote systems and entities, depending on the capabilities of the machine in various embodiments and the type of transaction to be performed.

FIG. 4 diagrammatically shows an exemplary software architecture operable in controller 72 of machine 10 . Exemplary software architectures include operating systems such as Microsoft(R) Windows, IBM OS/S(R) or Linux. The exemplary software architecture also includes an ATM application 82 . Exemplary applications 82 include instructions for the operation of automated banking machines, and may include, for example, the Agilis ^™ 91x application, available from Diebold, which incorporates software applications for operating ATMs and which may additionally are applications from different vendors. Another example of a software application that may be used in some embodiments is disclosed in US Patent No. 6,289,320, the entire contents of which are incorporated herein by reference.

In the exemplary embodiment, a middleware software layer, illustrated at 84 , runs in controller 72 . In the exemplary embodiment, middleware software layer 84 is used to compensate for differences between various types of automated banking machines and transaction function devices used therein. The use of the middleware software layer 84 enables the same software application to be used more rapidly on various types of ATM hardware. In an exemplary embodiment, middleware software layer 84 may be Involve ^(R ) software available from Nexus Software, a wholly owned subsidiary of the assignee of the present invention.

The exemplary software architecture also includes a diagnostics layer 86 . The diagnostic layer 86 operates as described later to be able to use and perform various diagnostic functions of the devices within the ATM. In the exemplary embodiment, diagnostic layer 86 operates with a browser, shown diagrammatically at 88 .

The exemplary software architecture may also include an XFS layer, diagrammatically indicated at 90, which will be described in more detail below. The XFS layer 90 represents a standard interface to software layers above the XFS layer that facilitates the development of software for use in conjunction with different types of ATM hardware. Of course, this software architecture is exemplary and in other embodiments other architectures may be used.

An example of XFS that may support cross-vendor architectures in an exemplary embodiment includes the Agilis ^™ 91x application commercially available from Diebold Incorporated. FIG. 28 shows a schematic diagram representing an exemplary embodiment of a cross-vendor ATM architecture 1020 . Here, the ATM architecture 1020 includes a computer 1022 operatively connected to a plurality of transaction function devices 1042 . These transaction function devices may include, for example, devices such as ticket dispensers, coin dispensers, card readers, printers, keyboards, display devices, function keys, depositors, cash acceptors, or other operable ground connection to the hardware device of the ATM.

The computer 1022 may include software components including a terminal application 1024 for controlling the operation of the transaction function 1042 . The computer 1022 may also include an XFS layer 1028 corresponding to an interface to an ATM device that supports multi-vendor, such as a WOSA/XFS manager or a J/XFS kernel. Current releases of the XFS layer include XFS 3.0. Exemplary embodiments of components described herein that communicate with the XFS layer may be compatible with the XFS 3.0 standard or any other earlier or later XFS standard that is developed.

Additionally, the computer 1022 may also include a device driver layer 1030 that includes a plurality of device driver components 1038 that interface with the XFS layer. For example, if the XFS layer corresponds to a WOSA/XFS manager, then the device driver component 1038 corresponds to a WOSA/XFS maintenance provider interface. If the XFS layer corresponds to the J/XFS kernel, then the device driver component 1038 corresponds to the J/XFS device maintenance. In an exemplary embodiment of a terminal application that includes a J/XFS kernel, Sun Microsystems' Java ^(R) may be used. An example of an automated transaction machine including a Java-based terminal application is disclosed in US Application No. 09/193,637, the entire contents of which are incorporated herein by reference. As used herein, the device driver corresponding to the WOSA/XFS maintenance provider interface or J/XFS device maintenance is referred to as maintenance provider component 1038 or SP component.

For each transaction function device 1042, an SP 1038 must be installed into the computer operable to enable commands through the XFS layer 1028 to control the operation of the transaction function device 1042. In one exemplary embodiment, SP 1038 is installed manually from portable physical media, such as a diskette or CD, provided by the device manufacturer. In another exemplary embodiment, the SP is operatively downloaded from a data storage device of the SP operatively connected to the computer. In yet another exemplary embodiment, the SP is obtained by the computer 1022 from the transaction function device 1042 itself using a maintenance configuration such as Sun Microsystems JINI ^™ , Microsoft Universal Plug and Play ^™ , or other plug-and-play architecture protocol.

Each SP 1038 is operatively responsive to the XFS layer 1028 to enable at least one transaction function device 1042 to perform a function. For example, the card reader SP is operable to respond to a card read request from the XFS layer 1028 such that its corresponding card reader device physically reads information from the card and returns the information through the XFS layer. Another SP, such as a ticket distributor SP, is operable to cause its corresponding ticket distributor to distribute a certain amount of tickets in response to a distribution request from the XFS layer 1028 .

In this illustrated exemplary embodiment, terminal application 1024 is operable to control transaction function 1042 through communication with XFS layer 1028 . However, in addition to having the terminal application 1024 in direct communication with the XFS layer, the exemplary embodiment also includes an ODS layer 1026 running in the computer 1022 between the terminal application 1024 and the XFS layer 1028 . An example of an ODS layer may include the previously described Involve ^(R) software.

In this illustrated exemplary embodiment, ODS layer 1026 is operatively responsive to terminal application 1024 to control the functionality of transaction function device 1042 through communication with XFS layer and device driver layers 1028 and 1030 . ODS layer 1026 includes a number of ODS components 1036 that generally correspond to SP 1038 and/or transaction function 1042 . For example. Exemplary embodiments may include a card reader ODS component corresponding to a card reader SP for a card reader. Exemplary embodiments may further include a ticket dispenser ODS component corresponding to the ticket dispenser SP for the ticket dispenser.

While SPs from two or more vendors generally communicate with the XFS layer in a consistent manner, a single ODS component can be used when any one driver is installed into the ATM. However, if the vendor-specific SPs implement communication with the XFS layer differently, the vendor-specific ODS components may be operatively programmed for each vendor-specific SP. Then, vendor-specific ODS components can be installed into the ODS layer in response to any vendor SPs installed into the ATM. Vendor-specific ODS components are operable to communicate through the XFS layer in a manner appropriate to the particular implementation of the vendor-specific driver.

While each vendor-specific ODS component may communicate with the XFS layer in a different manner, all vendor-specific ODS components for a particular type of device share a common interface to access external applications such as terminal applications 1024 . Thus, the ODS layer 1026 is operable to isolate inconsistencies in communications between different SPs and present the terminal application 1024 or any other application.

The illustrated exemplary embodiments include a testing process operable to identify unique features and/or inconsistencies in a vendor's SP implementation, and operable to adapt ODS components to include proper and consistent integration with the SP via the XFS layer. Those characteristics necessary for communication.

Typically, the test process includes the configuration of vendor-specific hardware devices and corresponding SPs on an XFS-enabled test platform. A test platform typically includes a computer system with an XFS layer and ODS components corresponding to a particular type of vendor device. For example, if the particular device to be tested is a ticket dispenser, then the ODS component corresponding to the SP for the cash dispenser is installed into the test platform.

The test platform also includes test applications. The test application operably interfaces with the ODS component and then issues a number of commands through the ODS component to control the operation of the supplier device. A user may monitor and/or interact with the device and the test application to determine which functions of the device may or may not function properly with the ODS components.

For example, when testing a card reader, the test application enables the user to issue commands to the ODS component to cause the device to read the card. The test application is also operable to output the results of the run to the user. If the operation appears to be working properly, the test application can display the contents of the information read from the card. Users can then verify that the content is correct. If the operation fails, the user can evaluate the resulting error message. Additionally, if an operation triggers an unexpected event through the XFS layer, the test application is also operable to report what event has been triggered as a result of the operation.

In addition to monitoring the test application, the user can also monitor the actual device to determine whether operation is producing correct functionality. For example, if the device corresponds to a note dispenser, the test application may include an operation of dispensing an amount of cash or an amount of notes through communication with the cash dispenser ODS. For example, by monitoring a cash dispenser, a user can determine if the correct amount of cash is being dispensed. After functional issues between cash ODS components and devices have been identified, the ODS components can be operatively modified to compensate for characteristics associated with the vendor's SP implementation. Modified ODS components can also be tested on a test bench to uncover further inconsistencies or to verify that the ODS components are working properly. Once the ODS component has been verified, it can be installed in the ATM, which includes the tested vendor's device, SP and corresponding XFS layer, so that the end application properly controls the device's functionality.

In an exemplary embodiment, terminal application 1024 may be based on any programming framework operable to communicate with ODS layer 1026 . In an exemplary embodiment, the terminal application may be a Microsoft Windows-based application, including one or more Windows-based executable programs. In an exemplary embodiment, a Windows-based application may include multiple .Net components and applications. In an alternative exemplary embodiment, the terminal application comprises a browser-based application having a user interface comprising a web page. Such web pages may include static web pages and/or dynamically generated web pages using, for example, Active Server Pages, .NET, PHP, and CGI. Additionally, a web page can include HTML, DHTML, XML, Java Script, Active X, .NET components, Java programs, or any other markup language, component, or script. In another exemplary embodiment, the terminal application may be a Java application operable in a Java Virtual Machine (JVM).

In an exemplary embodiment, the ODS layer may be based on any programming framework operable to communicate with the XFS layer 28 . For example, if the XFS layer corresponds to the J/XFS kernel running in the JVM 48 of the computer 22, the ODS components can be built as Java Beans operable in the JVM. If the XFS layer corresponds to the WOSA/XFS manager, the ODS components can be built as multiple Windows-based DLLs and/or .Net components. If the XFS layer and/or parts of the terminal application are both Windows-based and Java-based, the ODS layer may include components operable in the JVM and components operating as DLLs. In other embodiments, the ODS layer and the terminal application program can be configured as other types of programs, modules or libraries, which are suitable for the operating system architecture and the XFS layer.

To increase the productivity of programmers developing terminal applications, the illustrated exemplary embodiment may include the integration of Transaction Component Component (TEC) 1034 with terminal applications 1024 . A TEC is an object or class, such as an ActiveX, .NET object, or Java Bean, that encapsulates the complex operation of one or more transaction function devices 1042 into a package of improved methods, properties, and events. The TEC object includes the functions necessary to communicate with the ODS layer. In an exemplary embodiment, an entire terminal application can be built from TEC objects. While ODS components 1036 may generally have a one-to-one relationship with corresponding SP 1038 and/or transaction function devices 1042, TEC objects combine logical groups of functions for different devices, resulting in TEC objects generally having a one-to-many relationship with ODS components .

FIG. 29 shows an exemplary terminal application 1050. The terminal application includes the card reader TEC1052. The application 1050 is operable to call methods 1054 of the card reader TEC 1052, such as enable card reader, read card, write card, return card, and reserve card. The application 1050 is also operable to set attributes 1056 of the card reader TEC 1052, such as a timeout value before the card reader returns a card. Additionally, the application is also operable to monitor one or more events 1058 triggered by the reader TEC.

The exemplary card reader TEC 1052 is in operable communication with three distinct hardware devices, including a card reader device 1060 , a lead through indicator device 1061 , and a call device 1062 . The exemplary card reader TEC 1052 interfaces with these devices through communication with corresponding ODS components, including the card reader ODS 1063 , indicator ODS 1064 , and pager ODS 1065 .

Through communication with the card reader ODS 1063, the card reader TEC 1052 is operable to cause the card reader device 1060 to perform functions such as activating the card reader, reading the card and returning the card to the customer. The card reader ODS communicates with the card reader device through the XFS layer 1068 and the card reader driver 1067 . The example card reader TEC 1052 is also operable to automatically activate the lead indicator light 1061 to draw the user's attention to the card reader 1060 when the card reader is activated. This is performed by communicating with the sensor and indicator SP1066 via interaction with the indicator ODS1064. Additionally, the example card reader TEC 1052 interacts with the pager ODS 1065 to cause the sensor and indicator driver 1066 to activate the pager device 1062 when the call sound needs to signal the consumer to remove their card. Exemplary embodiments of the TEC are operable to logically combine the interaction of devices by communicating with one or more ODS components and corresponding devices in response to the various methods of the TEC to be referenced.

In addition to making it possible to produce cross-vendor compatible terminal applications (including TEC objects, or operable to directly interact with the ODS layer), the exemplary embodiments include: changing a vendor's pre-existing and proprietary terminal control software to operate another vendor's ATM hardware. Such proprietary terminal control software typically communicates directly with multiple proprietary device drivers without using the XFS layer previously described. As a result, proprietary endpoint control software has previously been restricted to run only on hardware platforms from specified vendors. However, exemplary embodiments are also operable such that such proprietary software, when installed on another vendor's ATM platform, is operable to properly control another vendor's transaction function device. This is accomplished by adapting proprietary software to communicate with ODS components rather than changing proprietary device drivers. Once the proprietary terminal control software has been so changed, the software is operative to run on another vendor's ATM platform including the XFS layer and corresponding SP.

As shown in FIG. 28 , in addition to interfacing with the XFS layer 1028 , the SP 1038 of an exemplary embodiment may also include or be associated with a diagnostic interface 1040 . Diagnostic interface 1040 may include additional low-level hardware control functions that can be accessed by external applications using function calls rather than using the XFS layer. For example, underlying functions may access specific motors, sensors, and other components in the corresponding transaction function device 1042 terminal. By using the diagnostic application 1044 to directly access these underlying functions of the SP 1038, the various mechanical and electrical functions specific to the device can be tested, analyzed and possibly corrected.

For example, the cash dispenser SP may be modified to include interfaces for operating various motors or sensors in the corresponding cash dispenser transaction function. Such access to applications is provided independently of the XFS layer. In an exemplary embodiment, a diagnostic application may be operatively designed to access a plurality of different SP's diagnostic interfaces. Another exemplary embodiment of the diagnostic application may also be adapted to use the XFS layer to stop one or more devices from communicating with XFS. Once the device has been run off-line with respect to the XFS components, the diagnostic application may enable a maintenance technician to directly access the ATM hardware through a corresponding diagnostic interface for troubleshooting, repair and other maintenance purposes.

In another exemplary embodiment, the diagnostic interface 1040 of the SP 1038 may include an authentication system operable to verify that an application attempting to access the underlying functionality of the device is authorized to do so. In an exemplary embodiment of the authentication system, diagnostic interface 1040 is operable to detect an operative connection of a valid hardware device, such as a dongle, to the ATM before an external application is authorized to access transaction function device 1042 through diagnostic interface 1040 .

In an alternative exemplary embodiment of the authentication system, the diagnostic interface 1040 is operable to detect whether a valid license code is presented. For example, this license code may be located on a removable medium operatively connected to the ATM, such as a floppy disk, CD, magnetic stripe card, smart card, or any other portable medium operatively accessible by the machine through the diagnostic interface. The license code may also be associated with a specific application, such as diagnostic application 1044 designed to access the SP 1038's diagnostic interface. Communications with the diagnostic application may require the inclusion of a valid permission code before the diagnostic interface enables the diagnostic application to access the transaction function device.

In another exemplary embodiment of the authentication system, the diagnostic interface 1040 may include an encrypted password or digital certificate, which may be used by the diagnostic interface to determine whether the application is allowed to access the functionality of the corresponding transaction function device. For example, the SP's diagnostic interface may require communications with the diagnostic application to be digitally signed. The diagnostic interface may then use one or more digital certificates and/or public keys that have been stored in operative connection with the diagnostic interface to authenticate the digital signature associated with the communication. The diagnostic interface is operable to cause the diagnostic application to access the transaction function device through the diagnostic interface when the digital signature is valid. The diagnostic application is denied access to the transaction function means by the diagnostic interface when the digital signature is determined to be invalid.

In another exemplary embodiment, the diagnostic application may require that a valid digital certificate be sent to the diagnostic interface before being granted access to the transaction function device. Digital certificates can be validated through a diagnostic interface using the trusted public key of the certification authority that issued the digital certificate. It is also possible to evaluate whether a digital certificate has expired through the diagnostic interface. When the digital certificate has expired or is invalid, an exemplary embodiment of the diagnostic interface is operatively designed to return a message to the calling application indicating that the digital certificate is invalid and access to the transaction function device is denied. In another exemplary embodiment, other software and/or hardware encryption and/or authentication systems may be combined with the SP's diagnostic interface to select users and/or users attempting to access transaction function devices through communication with the SP's diagnostic interface or application availability.

The illustrated exemplary embodiment may also include a terminal manager 1046 . Terminal Manager 1046 is a software application operable to configure and manage the ATM through interaction with the ODS layer.

Another exemplary embodiment of an ATM 1500 including an XFS layer 1502 is shown in FIG. 30 . Here, the XFS layer may include an application program interface part 1504 and a hardware interface part 1506 . The ATM may include one or more terminal applications 1508, such as user interface applications that provide selectable options through input and output devices, which enable a user to perform transaction functions using the ATM. User interface applications can use the previously described TEC components. In addition, ATM may include the ODS layer 1509 previously described. As used herein, the one or more terminal applications, user interface applications 1508, TEC components, and/or ODS layer 1509 may be referred to as the application layer 1510 of the ATM. The application program layer 1510 of ATM communicates with the application program interface part 1504 of the XFS layer through changes.

Additionally, as described above, the ATM may include a device driver layer 1511, which may include XFS compliant device drivers such as WOSA/XFS maintenance provider 1513 or J/XFS device maintenance, as described previously. In an exemplary embodiment, the SP may include an interface compatible with XFS3.0 or other standards, which may be operable to control the operation of the hardware device in response to the communication of the XFS layer from the hardware interface part of the XFS layer.

Additionally, in this illustrated exemplary embodiment, the device driver layer 1511 may include a unified base release (UBR) component 1515 . Such UBR components may provide an additional layer of abstraction between the SP and the hardware device 1518 . One or more SPs may be programmed to control hardware devices by communicating with UBR components rather than directly communicating with one or more hardware devices. Thus, communication between the SP and the hardware device can be achieved through the UBR component. In an exemplary embodiment, there may be a one-to-one correspondence between each UBR component and a hardware device. It should be appreciated, however, that in alternative exemplary embodiments, a UBR component may provide an interface to more than one hardware device. Also, in an exemplary embodiment, the UBR component may include the previously described diagnostic interface 1040 (FIG. 28), which provides access to the low-level operation of motors, sensors, and other components of the hardware device independent of the XFS layer.

As used herein, the device driver layer 1511 and hardware devices 1518 may be referred to as the hardware layer 1512 of the ATM. The hardware layer 1512 of ATM is changed to communicate with the hardware interface part 1506 of the XFS layer. In an exemplary embodiment, the application program layer 1510 communicates with the XFS layer by calling the application program interface portion 1504 of the XFS layer. In response to communications received by application program interface portion 1504, XFS layer communicates with hardware layer 1512 through hardware interface portion 1506 to cause hardware device 1518 to perform one or more functions.

FIG. 17 diagrammatically shows another exemplary embodiment of a software architecture that may be used in the ATM2110. Here, the exemplary software architecture also includes at least one terminal application 2100 that communicates with the ATM's devices 2310-2313 including transaction function devices through a device layer 2109 including a module interface layer or framework 2108. In an exemplary embodiment, terminal applications 2100 may include a proprietary terminal control software application for ATMs. However, as shown in FIG. 18, in other exemplary embodiments, the terminal application may correspond to an XFS-enabled terminal application or application layer 2102 that communicates with the transaction function device through the XFS layer 2104, and the aforementioned elements of SP 2106. . In this illustrated exemplary embodiment, the device driver layer 2109 includes a module interface layer or framework 2108, and other associated device driver components 2230, 2240, 2242, 2260, 2262 associated with the ATM hardware devices 2310-2313. For the exemplary embodiment including XFS layer 2104 (FIG. 18), the device driver layer also includes SP 2106.

In this illustrated exemplary embodiment, a module interface layer or framework 2108 like the previously described UBR 1515 in FIG. . For non-XFS-enabled terminal applications 2100 (FIG. 17), module interface framework 2108 is similarly operable to provide an additional layer of abstraction between proprietary terminal control software applications and hardware devices 2310-2313.

In an exemplary embodiment, the module interface framework 2108 may be comprised of a number of software components running in the controller 72 or other computers in the ATM. An exemplary module interface framework may include a device server application or process running in the ATM's computer (referred to herein as the device scheduler and manager 2170). Terminal application 2100 and/or maintenance provisioning components may be modified to communicate with device scheduler and manager 2170 through module interface API 2120 . In an exemplary embodiment, the module interface API may correspond to one or more DLLs or other libraries that include standard functionality for communicating with the device scheduler and manager 2170 .

For one or more of the ATM hardware devices 2310-2313, the module interface framework 2108 may include corresponding module interface device components 2181-2184, such as DLLs or other device-specific libraries. The module interface device component may be operable to provide device-specific communications between the device scheduler and manager 2170 and the underlying vendor-specific device drivers 2230, 2240, 2242, 2260, 2262 associated with the ATM hardware devices 2310-2313.

For ATM hardware devices compatible with the plug-and-play architecture on the operating system of ATM, the device scheduler and manager 2170 can also be used to receive information about the ATM hardware device 2313 directly from the plug-and-play manager 2280 of the operating system. hardware event notifications.

The illustrated exemplary embodiment may also include a diagnostic application 2140 that communicates with the ATM hardware device through the same module interface framework as the terminal application 2100 and/or SP 2106 .

As with the diagnostic application 1044 described above with respect to FIG. 28, the diagnostic application 2140 is operable to perform various diagnostic functions with the hardware devices 2310-2313 running in the ATM. In an exemplary embodiment, diagnostic application 2140 operates in conjunction with module interface framework 2108 to allow low-level operation and diagnostic testing of transaction function devices, and may work in conjunction with individual diagnostic objects, as described in more detail below. discussion.

As in the case of terminal application 2100 and/or SP 2106, diagnostic application 2140 uses module interface API 2120 to access the module interface framework. The module interface API includes a standard set of functions that provide low-level and high-level control over transaction function devices. Here, the underlying functionality of the module interface API may correspond to the diagnostic interface 1040 previously discussed with respect to FIG. 28 .

Terminal applications 2100 , SPs, and/or diagnostic applications access one or more functions of the module interface API to communicate desired actions or actions to module interface dispatcher and manager 2170 . In response to this communication, the module interface scheduler and manager is operable to selectively invoke module interface components 2181-2184 associated with hardware devices 2310-2313, which may be required to perform the requested action. The module interface assemblies 2181-2184 are operable to communicate through the ATM's USB port 2300, serial interface 2290, or other hardware through one or more DLLS (DLL) 2230, 2240, 2242, 2260, 2262 associated with the transaction function device mouth to guide the actions of the corresponding hardware devices 2310-2313.

Since the module interface API 2120 uses a standard set of functions, terminal applications 2100, SP 2106, and/or diagnostic applications can be written to control the actions of the hardware devices 2310-2313, regardless of which specific model is ultimately incorporated into the ATM or Is it beneficial for each type of transaction function device. Similarly, if the transaction function device later needs to be transferred out of a different transaction function device, then as long as the new device is operable to perform the same functions as the old device, the terminal application 2100, SP 2106, and/or diagnostic application may No modifications are required. In the exemplary embodiment, module interface API 2120 provides a wide range of functional control over transaction function devices.

In addition to providing upper-level control functions that enable transaction function devices to perform complete transaction functions, the module interface API 2120 also provides low-level control functions. These low-level control functions can include, for example, outputting audible tones, turning on motors, disabling keypads, or other low-level operations that can be used by diagnostic applications to accurately diagnose the cause of an overlying operation.

With respect to the interface presented to the device scheduler and manager 2170, the module interface components 2181-2184 may be similarly uniformly standardized. The use of standardized interfaces facilitates the creation of an extensible device scheduler and manager 2170 that can manage multiple hardware devices 2310-2313 without requiring reprogramming every time a new hardware device 2310-2313 is added.

When a new transaction function device is added, new module interface components 2181-2184 may be added to the module interface framework to enable the device scheduler and manager to communicate with the new vendor provided device driver DLL or library (associated with the new device )Communication. On the other hand, if the vendor-supplied device drivers are compatible with the module interface components already incorporated in the module interface framework, then the new module interface components may not be required to properly operate the new transaction function devices.

The illustrated exemplary embodiment of the module interface framework 2108 may use a callback function 2130 associated with the terminal application 2100 , the SP 2106 , and/or the diagnostic application 2140 . When a transaction function device delays performing an action (ie, an asynchronous event), the upper layer application can be designed to periodically poll the status of the device to determine whether an action or event has occurred. An example of an asynchronous event is when cash is presented to the customer for a fixed period, at the expiration of the fixed period, if the cash is not taken by the customer, the cash is withdrawn. A common way to determine if cash has been withdrawn is to repeatedly poll during the presentation cycle. To eliminate the inefficiencies associated with periodically polling a device, an exemplary embodiment of a terminal application, SP, or diagnostic application may provide a callback function for the device scheduler and manager to be called when the deletion of a hardware device has completed. transfer.

For example, the SP can register callback functions associated with cash withdrawals with the device scheduler and manager by using the module interface API. When cash is later withdrawn, the slave dispatch manager sends a notification to the callback function, removing the need to poll the status through the SP to determine if cash is still being provided to the customer. Similar to the callback functionality of terminal applications, maintenance providers, or diagnostic applications, can register with the device scheduler and manager for notification of events initiated by transaction function devices. Such events may correspond to unsolicited status messages. For example, when a card reader device detects an inserted card, the device may generate an unsolicited status message that is deleted by the device scheduler and manager and communicates with the terminal application, SP, or diagnostic application using a registered callback function, to receive such messages.

Using the module interface API 2120, the terminal application, SP and/or diagnostic application registers expected unsolicited events with the device scheduler and manager 2170 during initialization. Likewise, events are registered to the device scheduler and manager when the terminal application, SP and/or diagnostic application relinquish control of the hardware device 2310-2313 used to execute an asynchronous event. When the device dispatcher and manager 2170 subsequently experiences a registration event, through interaction with the module interface device components 2181-2184, the device dispatcher and manager 2170 delivers notification of the event to the correct callback function.

As shown diagrammatically in FIG. 4 , the controller 72 is operatively connected to at least one communication bus 92 . In some exemplary embodiments, communication bus 92 may be a Universal Serial Bus (USB) or other standard or non-standard type of bus architecture. The communication bus 92 is shown diagrammatically in operative connection with a transaction function device 94 . Transaction function means 94 includes means for performing transactions in the ATM. These may include, for example, currency dispenser device 54, card reader 26, receipt printer 44, keypad 32, and many other devices that operate within the machine and are controlled by controller 72 to perform transactions. In the exemplary embodiment, one of the transaction function devices 94 operatively connected to the controller is a diagnostic item reading device 96 , discussed in detail later, which is operative to read the Indicates the diagnostic item. As explained later, in the exemplary embodiment, diagnostic item 98 includes a CD that can be read by reader 96 , and computer device 100 that is generally not associated with the operation of ATM 10 .

In the exemplary embodiment of the ATM 10 , a first fascia portion 20 and a second fascia portion 22 are independently movably mounted to the ATM housing 12 . This is done using hinges attached to the pallet portion 20 . The opening of the pallet lock 50 on the first pallet part 20 enables the first pallet part 20 to be moved to the open position as shown in FIG. 5 . In the open position of the first tray portion 20 , authorized users are enabled to access the first portion 102 in the upper housing region 14 . In the exemplary embodiment, a case lock input device 104 is positioned within the first portion 102 . In this embodiment, the case lock input device 104 includes: a manual combination lock dial; an electronic lock dial; or other suitable input device through which a number or other unlocking input or item may be provided. In this exemplary embodiment, entering the correct number moves the cabinet door 18 to the open position by rotating the door about hinge 106 . In the exemplary embodiment, once the correct number is entered, the cabinet door 18 is opened by operating a locking lever 108 operatively connected to a boltwork. Latches not expressly shown may be of the conventional or non-conventional type and are used to hold the cabinet door 18 in a locked position until the correct number is entered. Whenever the correct number is entered, the locking lever moves the latch so that the cabinet door 18 can be opened. The latch also keeps the door 18 locked after activities in the box portion 16 have been performed and the door 18 is returned to the closed position. Of course, in other embodiments, other types of mechanical or electronic locking mechanisms may be used. In the exemplary embodiment, case lock input 104 is supportably connected to a generally horizontally extending dividing wall 110 that separates case portion 16 from upper housing region 14 . Of course, this housing configuration is exemplary, and in other embodiments, other approaches may be used.

Authorized maintainers who need access to items, components or devices in the bin portion 16 of the ATM can do so by unlocking the pallet lock 50 and then moving the first pallet portion 20 so that the first portion of the upper housing area 14 102 becomes accessible. Thereafter, if the cabinet door 18 is properly unlocked, an authorized servicer may access and manipulate the cabinet lock input device 104 to receive one or more inputs. The bin door 18 may then be moved relative to the housing or about its hinge 106 to enable a maintainer to access items, devices or components within the bin portion 16 . These actions may include, for example, adding or removing cash, removing deposit items such as envelopes or checks, or servicing mechanisms or electrical devices used to enable the machine to accept deposit items or dispense cash. When maintenance actions within the box portion 16 are completed, the box door 18 may be closed and the locking bar 108 moved to ensure that the latch keeps the box door 18 in the closed position. Of course, this structure and maintenance method is exemplary, and in other embodiments, other methods may be used.

In an exemplary embodiment, the second pallet portion 22 is also movable relative to the machine's housing. In an exemplary embodiment, the second pallet portion 22 is movable in a supporting connection with a rollout tray 112 shown diagrammatically in FIG. 3 . The assembly of the user interface on which the tray is operably supported and the second pallet portion 22 are rotated out. Swinging out the tray 112 causes the second pallet portion 22 to move outwardly relative to the ATM housing, thereby exposing the components and transaction function devices supported on the tray, and providing a pair within the upper housing region 14 and located on the second pallet portion 22. A second part 114 of visits follows. Thus, it should be appreciated that when the second pallet portion 22 is moved outwardly, the components on the spin-out tray 112 are located outside the machine housing to facilitate maintenance, adjustment and/or replacement of these components. When the second pallet portion 22 is placed outwardly and away from the housing, the remaining other components within the machine housing, like the spin-out tray 112 , are extended to become available in the second portion 114 of the upper housing region 14 .

In the exemplary embodiment, the swing-out disc 112 is operably connected to a releasable locking device. The locking means is generally operable to retain the disc in the retracted position such that the second pallet portion 22 remains in an operable position adjacent the upper housing region 14 as shown in FIGS. 1 , 2 and 3 . The releasable locking means may comprise one or more forms of locking type means. In an exemplary embodiment, the releasable locking mechanism may be released by manipulating a detent 116 , which is accessible in the first portion 102 of the upper housing region 14 by an authorized user. Thus, an authorized maintainer of the machine can move the second pallet portion 22 outwardly for maintenance through the first access portion 102 in the manner previously described. Then, by actuating the brake 116 , the second pallet portion 22 can be moved outwardly as shown in partial section in FIG. These components include, for example, printers or card readers. After such maintenance, the second pallet portion 22 can be moved towards the housing to close the second portion 114 of the upper housing region 14 . In the exemplary embodiment, such movement enables the spin-out disc 112 to be locked and held in the retracted position without further manipulation of the brake 116 . However, in other embodiments, other types of locking devices may be used to secure the swing-out disk 112 in the retracted position. It should be appreciated that this approach is exemplary and in other embodiments other approaches may be used.

As best shown in FIG. 10 , where components supported in upper housing region 14 are not shown, delivery region 52 and deposit acceptance region 58 are in supportive connection with door 18 . Likewise, when the door 18 is opened, the delivery area 52 and the deposit acceptance area 58 will move relative to the housing of the machine. The exemplary embodiment shown facilitates maintenance of the machine by providing illumination of the transaction area by a lighting source, which is arranged in supporting connection with the spin-out tray 112 . As best shown in FIG. 6 , these illumination sources 118 are movable with the spin-out tray 112 and illuminate the operative position of the second pallet portion 22 and cabinet door 18 generally in a downward direction. The illumination source is generally aligned with apertures 120 and 122 that extend through the top of cover 124 generally surrounding the recessed area. As shown in FIG. 10 , hole 120 is generally aligned vertically with window 68 , while hole 122 is generally aligned with window 70 . In an exemplary embodiment, apertures 120 and 122 each have a translucent or transparent aperture cover disposed therein to minimize the risk of dust or other contaminants entering the interior of cover 124 .

As can be appreciated from FIGS. 6 and 11 , the illumination source 118 is generally positioned in aligned relationship with the apertures 120 and 122 when the cabinet door 18 is closed and the second pallet portion 22 is moved to the operative position. Thus, the illumination of the lighting device is operable to transmit light through the respective apertures 120, 122 and illuminate the transaction area in the corresponding recessed area.

During operation of the exemplary embodiment, controller 72 executes programmed instructions to initiate illumination of each transaction area at the appropriate time during execution of the transaction. For example, in an exemplary embodiment, if a user performs a cash pickup transaction, the controller 72 may begin illuminating the delivery area 52 when cash is delivered therein and is to be picked up by the user. Such lighting draws the user's attention to the need to withdraw their cash and indicates to the user that the cash is ready to be withdrawn. In the exemplary embodiment, the controller 72 is programmed so that when the user withdraws their cash, the machine moves to the next step of the transaction. The controller 72 is operable to cease lighting the delivery area 52 after sensing that cash has been removed.

Also, in the exemplary embodiment, the controller 72 may cause the machine to operate to begin illuminating the deposit acceptance area 58 if the user of the machine indicates that they wish to perform a deposit transaction. The user's attention is drawn to where they must insert the deposit envelope in order for it to be accepted into the machine. In an exemplary embodiment, the controller 72 may also illuminate the illuminated panel 62 to illuminate the deposit envelope providing opening 48 so that the user also notices where a deposit envelope may be provided. In an exemplary embodiment, controller 72 is operable to cease lighting through window 70 and/or lighting panel 62 after indicating that a deposit envelope has been sensed within the machine.

In alternative embodiments, other methods may be employed. This may include, for example, drawing the consumer's attention to a particular transaction area by changing the nature of the lighting in the recessed area that draws the user's attention. For example, this can be accomplished by changing the intensity of the light, flashing it, changing the color of the light, or taking other actions that can draw the user's attention to the appropriate transaction area. Alternatively or in addition, visually impaired users may be provided with sound emitters, vibrations, protruding pins, or other indicators to indicate to them the appropriate transaction area for the user's attention. Of course, these methods are exemplary, and in other embodiments, other methods may be used.

It will be appreciated that the exemplary embodiments enable the use of one or more lighting devices that are relatively movable relative to the area to be illuminated without additional movement of wiring harnesses or other releasable connectors. Additionally, the exemplary location of the lighting device 118 extending on the underside of the spin-out tray 112 facilitates changing the lighting device 118 by extending the swing-out tray 112 in the manner previously discussed and as shown in FIG. 11 . Of course, it should be understood that the principles described are applicable to various types of banking machine structures and arrangements which may be encompassed by the claims presented herein.

As previously discussed, the exemplary embodiment of the ATM 10 is also operable to draw the user's attention to the card reader slot 28 at the appropriate moment. The ATM 10 also includes features to minimize the threat of unauthorized interception of card data by someone who wants to install an unauthorized card reading device on the machine. As shown in FIG. 14 , the exemplary card slot 28 extends through a card slot housing 66 that generally extends in surrounding relationship with the card slot 28 . It should be appreciated that while the housing 66 generally delimits the entire card slot 28, in other embodiments it may be applied by limiting only one or more sides of the card slot 28 as it may be suitable for detecting unauthorized card reading devices. principles described here. Additionally, it should be appreciated that while the exemplary embodiment is described in connection with a card reader that receives a card into a machine, the principles can be applied to various types of card readers that do not receive a card into a machine, such as In the case of a reader, the user extracts the card through a slot, inserts the card, and manually removes the card from the slot, or other card reading mechanism.

In the exemplary embodiment, housing 66 includes a plurality of radiation emitting devices 126 . In an exemplary embodiment, radiation emitting device 126 emits visible radiation that may be perceived by a user of the machine. However, in other embodiments, the radiation emitting device 126 may include a device that emits invisible radiation, such as infrared radiation, but such a device can still be used to sense the presence of an unauthorized card reading device proximate to the card slot 28 . In an exemplary embodiment, controller 72 is operable to illuminate radiation emitting device 126 at appropriate times during the transaction sequence. This may include, for example, moments during a transaction when the user is prompted to enter their card into the machine or alternatively when the user is prompted to remove their card from the card slot 28 . In various embodiments, controller 72 may be programmed to provide reliable illumination of radiation emitting device 126 or to vary the brightness of the device as appropriate to draw user attention to card slot 28 .

In the exemplary embodiment, one or more radiation sensing devices 128 are included in the card slot housing 66 . The radiation sensing device 128 is arranged to detect changes in radiation reflected from the radiation emitting device 126 . The radiation sensing device 128 is operatively connected to the controller 72 . Controller 72 is operable to compare one or more values corresponding to the magnitude of reflected radiation sensed by one or more radiation sensing devices 128 with one or more stored values to determine whether the result of the comparison is A possibly unauthorized card reader is installed on the pallet of the machine. In some embodiments, controller 72 may be operable to implement fuzzy logic programming for determining whether the nature of the change in reflected radiation is that an unauthorized device has been installed and appropriate personnel should be notified.

FIG. 15 shows a side view of the housing 66 . Unauthorized card reading device 130 is shown coupled externally to housing 66 . The unauthorized card reader device 130 includes a slot 132 generally aligned with the card reader slot 28 . The device 130 also includes a sensor, shown diagrammatically at 134, operable to sense a reversal of the encoded magnetic flux representing data on the magnetic strip of the credit or debit card. It should be appreciated that an arrangement of the type shown in FIG. 15 enables the sensor 134 to read card data when properly aligned adjacent the card's magnetic stripe as the card is fed into or out of the card reader slot 28 . This unauthorized reading device 130 can be connected via RF or by unobtrusive wiring to other devices capable of intercepting card data. In some cases, criminals may also attempt to observe the user's PIN number corresponding to the entry of card data in order to gain access to the user's account.

It can be appreciated from FIG. 15 that the installation of the unauthorized card reading device 130 changes the amount of radiation from the emitting device 126 and reflected to the sensor 128 . Depending on the characteristics and construction of the device, the amount of reflected radiation can be increased or decreased. However, detectable changes often occur in the magnitude of the induced radiation between the current transaction and previous transactions (which were performed before the unauthorized card reading device 130 was installed).

Figure 16 shows a simplified logic flow diagram executed by the controller for detecting the installation of an unauthorized card reading device. It should be understood that this transaction logic is part of the overall operation of the machine executing the transaction. In this exemplary logic flow diagram, the machine operates in a normal manner to perform a card reading transaction and additionally performs the steps presented as part of this logic whenever a card is read. Beginning with step 136, a controller in the machine is operable to sense the card in a reader within the machine (step 138). Typically, in these cases, the controller will operate the radiation emitting device 126 when the user inserts their card and draws the card into the machine. In this exemplary embodiment, the controller continuously operates the radiation emitting device and senses one or more radiation energy levels sensed by one or more sensors 128 . This is done in step 140 .

In step 142, the controller is next operable to compare the signal corresponding to the sensed radiation energy level with one or more values. This comparison can be done in a number of ways, and in some embodiments, fuzzy logic can be used to avoid false indications due to acceptable conditions (such as the user placing his finger close to the card slot 28 during a portion of the transaction). . For example, in the case of a user's finger, a computer can determine whether an unauthorized reading device is installed based on the nature, magnitude and change in sensed radiation during a transaction, along with appropriately programmed weights. Of course, various approaches can be used within the scope of the concepts discussed here. However, based on the one or more comparisons in step 142, the controller is operable to determine in step 144 whether the difference between the sensed value from step 140 and the stored value is a difference that exceeds one or more thresholds (implying that Unauthorized card reader installed).

If the comparison does not indicate that the result exceeds the threshold, then the ATM transaction function operates normally as shown in step 146 . Additionally, in an exemplary embodiment, the controller is operable to adjust the stored value as a function of more recent readings. This can be used to properly compensate for dust on the pallet or loss of brightness of the emitter or other factors. This is indicated in step 148 . As shown in step 150, the controller operates the ATM to perform the transaction steps in the usual manner.

If in step 144 the difference between the sensed and stored values exceeds a threshold, this is an indication that an unauthorized reading device has been installed since the last transaction. In an exemplary embodiment, the controller is operable to display a warning screen to the user as shown in step 152 when this occurs. This warning screen operatively advises the user that an unauthorized object has been placed near the card reader slot. For example, this can alert the user that a problem is occurring. Optionally, if the user inadvertently places some object harmlessly near the card reader slot, the user can retrieve it. Additionally or alternatively, other logical steps may also be performed, such as prompting the user to indicate whether they can see radiation emitting devices being illuminated near the card slot and prompting the user to provide input indicating whether these items can be seen. Additionally or alternatively, an illumination device within housing 66 may be operable to cause the emitting device to output words or other symbols that the user may indicate they can or cannot see as output from the machine, based on input provided. tips. This may enable the machine to determine if an unauthorized reading device has been installed or if the sensed condition is due to other factors. It can also make the user aware of the presence of the reading device and remove it. Of course, various approaches can be taken depending on the programming of the machine.

If an unauthorized reading device has been detected, the controller in the exemplary embodiment also performs step 154 where a status message is sent to an appropriate maintenance provider or other entity indicating the suspected problem. In step 156, the controller is also operative to record data representing a particular transaction in which theft of the card holder's card data is suspected to have occurred. Additionally or alternatively, a message may be sent to a bank or other institution alerting them to activity on the user's card account for the purpose of detecting if unauthorized use has occurred. Additionally or alternatively, some embodiments may include a card reader to alter, add or write data to the user's card in the event of suspected theft. These change data can be tracked or used to ensure that only cards with modified data are available thereafter. Additionally or alternatively, in some embodiments, modification cards may be moved in lateral relation, moved irregularly, or otherwise handled to reduce the threat of interception of modification data when the card is output from the machine. Of course, these approaches are examples of the many approaches that can be taken.

In an exemplary embodiment, the ATM is operable to perform transactions even if it is suspected that an unauthorized card reading device has been installed. This is indicated in step 158 . However, in other embodiments, other approaches may be taken, such as refusing to execute the transaction. Other steps can be taken, such as capturing the user's card and advising the user to issue a new card. This approach can be used to minimize the threat of card data being used to perform unauthorized transactions when the card is indicated to be invalid. Of course, other approaches can be taken depending on the programming of the machine and the needs of the system operator.

The exemplary embodiment of the ATM 10 is a machine generally configured for outdoor use and operation. In this way, it can withstand temperature extremes. However, components of an ATM, such as controls, cash dispensers, displays and other items, can be temperature sensitive and if the temperature inside the machine enclosure becomes too hot or too cold, they can begin to malfunction.

In the exemplary embodiment, display 36 comprises a highly illuminated flat-panel display. Some types of such displays generate considerable heat which, if not dissipated properly, can cause high temperatures and damage components of the machine. In an exemplary embodiment, the threat of such damage is reduced by providing airflow cooling through the machine enclosure, and particularly by providing airflow inside the enclosure in an area proximate to the display 36 .

As shown in FIG. 6 , the exemplary embodiment of the ATM 10 includes air cooling openings 160 . In the exemplary embodiment, an air cooling opening 160 extends between a top wall 162 of the second pallet portion 22 and a baffle structure 164 fixedly connected to the housing of the machine. As described in further detail below, the baffle structure 164 is operable to enable cooling airflow through the housing around the rear and sides of the display 36 and out of the housing through the opening 160 . However, the exemplary baffle structure 164 is operable to minimize the threat of moisture, such as liquid water, droplets, snow, condensation, or other contaminants, penetrating the interior region of the housing. In addition, the exemplary baffle structure 164 is used to direct contaminants to the enclosure of the enclosure to avoid accumulation on the baffle.

An exemplary baffle structure 164 is shown in more detail in FIG. 7 . The exemplary baffle structure 164 includes a vertically extending wall portion 166 extending upwardly adjacent the machine housing. As shown in FIG. 7, in the exemplary baffle structure 164, a vertically extending wall portion 166 extends above a substantially planar top surface 168 of the housing. The example baffle 164 also includes an arcuate surface 170 . The arcuate surface 170 extends substantially forward of the wall portion 166 . In the operative position of the swing-out disc 112 shown in FIG. 6 , the arcuate surface 170 overlies the display 36 in a substantially overlay-like manner.

In the exemplary embodiment, arcuate surface 170 has edges 172 at the front and side periphery. The edge 172 is operable to capture moisture and other contaminants that may collect on the baffle structure 164 and direct it towards an area of the baffle structure 164 proximate to the wall portion 166 . Also shown in FIG. 7 , arcuate surface 170 is generally curved at an angle to direct moisture toward the surface of wall portion 166 .

Positioned adjacent the face wall portion 166 is a moisture collection trough 174 . Moisture collection trough 174 is operable to capture moisture and other contaminants migrating towards wall 166 and direct them to the sides of the arcuate surface and exterior of the enclosure in a manner discussed later. In the exemplary embodiment of baffle structure 164 , there are a plurality of fin portions 176 extending generally outwardly from arcuate surface 170 . Fin portion 176 is generally positioned forwardly away from wall portion 166 in order to avoid interfering substances flowing through moisture collection channel 174 . It will be appreciated that fin portion 176 is operable to direct airflow across baffle structure 164 and minimize potential lateral flow of moisture across arcuate surface 170 except in the area of moisture collection groove 174 .

As shown in FIG. 8 , the air cooling opening 160 generally extends between the top wall 162 of the second pallet portion 22 and the front of the vertically extending wall portion 166 when the second pallet portion 122 is moved to the operative position. This extended opening provides sufficient area for the airflow required to maintain the interior of the enclosure within the desired temperature range. Additionally, the configuration of the tray portion 22 and baffle structure 164 in the operative position is such that the moisture collection channel 174 directs moisture and contaminants collected therein to the exterior of the ATM enclosure through the bottom region 178 of the air cooling opening 160 . This minimizes the chance of water and other contaminants collecting inside the machine. It should be appreciated that the second pallet portion 22 and the baffle structure 164 are symmetrical, and thus, the exemplary configuration allows contaminants to exit the housing of the machine on the sides of the first and second pallet portions 20 , 22 .

As shown in FIG. 9 , the exemplary embodiment facilitates airflow through the machine for cooling by providing air openings 180 at the rear of the box portion 16 . It will be appreciated that the air opening 180 is suitably protected so as to prevent ingress therethrough into the box portion of the housing 16 . The air opening 16 is operably connected to one or more blowers 182 through suitable filters or other means. Blower 182 is operable to provide forced air flow through the housing. In addition, in the exemplary embodiment of the present invention, the heating and cooling device can also be arranged near the blower, so as to facilitate maintaining an appropriate temperature inside the housing. Such devices may include, for example, heat pumps, Peltier devices, and other devices suitable for cooling, heating, or conditioning gas flow through the enclosure. Appropriate sensors and other controls may be operated within the enclosure to maintain components within the enclosure within appropriate temperature and/or humidity ranges.

In the exemplary embodiment, a tube 184 is disposed between tank portion 16 and upper housing region 14 . Duct 184 allows air to flow between tank portion 16 and upper housing region 14 to facilitate cooling or heating of components in these two parts of the housing. It should be appreciated that in order for the display to maintain the proper temperature regime, air must pass through the air opening 180 and into the upper housing region 14 through the tube 184 . The negative pressure created by the blower and upper housing region 14 causes gas to flow through upper housing region 14 and through air cooling openings 160 . In this case, air at the rear and sides of the display 36 is directed through the baffle structure 164 and out at the opening 160 . Optionally, where appropriate, the blower can be operated to reverse the air flow, in which case the heat generated by the display 36 can be captured within the machine to supplement the heating capacity of the heater within the machine to prevent the components from becoming too cold . It should be appreciated that in some embodiments, the controller of the machine or other controller may be operable to control the direction and rate of the blower and heating and cooling devices in order to maintain the interior of the enclosure at a suitable temperature range. In an exemplary embodiment, the structure of the display, the baffle structure, and the second plate portion facilitate cooling (and heating) of the display and other components while minimizing the risk of introducing contaminants into the machine.

It should be appreciated from the previous discussion that the baffle structure 164 is generally mounted in a fixed relationship with the housing. Thus, the extension of the swing-out tray 112 enables the display 36 and other components supported on the tray 112 to extend outside of the housing and away from the bezel structure 164 to facilitate maintenance. Once such maintenance has been performed, the swing-out tray 112 and second pallet portion 22 can be retracted so that the monitor 36 can again be moved in relation to the bezel structure 164 under the bezel structure 164 to be positioned between the monitor 64 and the air. The intermediate relationship between cooling openings 160 extends to provide protection. Of course, it should be understood that these structures are exemplary and that in other embodiments other approaches may be used.

In the exemplary embodiment, the ATM 10 provides enhanced diagnostic capabilities as well as the ability for maintainers to more easily perform remedial and preventive maintenance on the machine. In the exemplary embodiment, this is accomplished by programming the controller and/or alternately distributing controllers and processors associated with the transaction function devices to sense and capture diagnostic data regarding the operation of the various transaction function devices . In an exemplary embodiment, this diagnostic data includes more than one indication of a deactivation fault. In some embodiments, and for some transaction function devices, data may, for example, include examples of: velocity, intensity, deflection, vacuum, force, friction, pressure, sound, vibration, wear, cycle, power loss, standard Changes, restore actions, or other parameters that may be significant for monitoring the state of the machine and transaction function devices contained therein. The nature of diagnostic data that may be included may depend on the particular transaction function device and its capabilities, as well as the programming of the controller within the machine.

In an exemplary embodiment, the controller is operable to process data representing the status of various transaction function devices and store such information in one or more data stores. In some embodiments, data may be stored in a protected form. In an exemplary embodiment, the information is protected in such a way that persons who are not authorized and do not have the appropriate diagnostic items cannot gain access to the data. In some cases, the types used to protect data may include encryption, storing such data in memory devices that delete the data in the event of tampering, or other forms of protecting such data from unauthorized persons.

In an exemplary embodiment, authorized maintainers are able to use the diagnostic data and facilitate repair and preventative maintenance on the machine by issuing diagnostic items, such as diagnostic item 98 previously mentioned in connection with FIG. 4 . In an exemplary embodiment, the diagnostic article is a computer readable medium, such as a CD, that is operatively engaged with a diagnostic article reading device 96, such as a CD drive. Of course, it should be appreciated that in other embodiments the diagnostic article may have other forms and may comprise, for example, a portable terminal, such as a PDA or mobile phone, or may be a portable storage device, such as a plug-in USB memory module or smart card.

In an exemplary embodiment, having a diagnostic item operatively connected to the controller enables a maintainer to gain access to the diagnostic data, as well as obtain information from the item that provides an indication of the validity of the diagnostic data being received. In an exemplary embodiment, the diagnostic item includes maintenance guide data, which can be output by an output device of an ATM or other terminal, and the maintenance provider can use the maintenance guide data in a manner similar to maintenance instructions, or other information, which can be used to Perform maintenance operations on the ATM. Additionally, in an exemplary embodiment, the diagnostic article includes diagnostic instructions operable to interpret the results of diagnostic tests or operations that may be performed by operation of the controller.

In an exemplary embodiment, the diagnostic article includes instructions usable by and interactable with a controller of the machine. This enables the maintainer to use the diagnostic data, as well as the maintenance data from the diagnostic items, to provide output flags through the output device that may advise the maintainer to perform certain diagnostic tests. The controller is then operable to cause a user to provide input corresponding to these diagnostic tests through one or more input devices of the machine. These diagnostic instructions included in the diagnostic item's maintenance data cause the controller to interact with the transaction function and produce one or more results. In response to these results, a controller in the machine is operable to output an indicia representing the results to the maintainer. Additionally in response to these results and the maintenance data on the diagnostic items, the controller is operable to cause other diagnostic tests and maintenance or remedial actions corresponding to the threats) flags can be output. In an exemplary embodiment, the maintenance data included in the diagnostic item can be used to guide the maintainer's maintenance activities and interact with the controller, and provide maintainer interaction at the machine to obtain test results and enable status can be diagnosed. Additionally, when operatively connected to the controller, exemplary embodiments of the maintenance article enable indicia, which may include textual, audible, or graphical information, to be output to facilitate maintenance actions at the machine by a maintainer.

In an exemplary embodiment of an item being maintained, the item provides the controller with one or more security codes, commands, results or other things, all referred to herein simply as security codes. These security codes are analyzed by operation of the controller to determine if the diagnostic item is authorized. In some embodiments, the controller is operable to request user input of information that is used to determine whether the item is authorized. Such entered user information may include, for example, an entry code or biometric entry entered into an input device on the machine. Additionally or alternatively, the security code derived from the diagnostic item may be a designated time, machine, or device. For example, designated diagnostic items may have security codes that indicate that the diagnostic item is only operable during certain time periods or before or after specified dates. A controller in the ATM is operable to perform a calendar function providing the current date. The ATM controller may use the security code from the diagnostic item to generate one or more values that are compared to verification data generated in response to the time or date data to generate a comparison. The controller then causes diagnostic data or valid data to be entered for performing an action based on the result of the comparison indicating that the diagnostic item and/or the user is authorized.

In some embodiments, maintenance data included in the diagnostic article may be encrypted. Such encryption may include various standard or non-standard techniques to reduce the threat of unauthorized users being able to use the maintained data. In an exemplary embodiment, the controller of the ATM is operable to decipher the maintenance data so that it can be utilized in performing diagnostic actions and the indicia corresponding thereto can be passed to an output device on the machine or to a terminal at a separate terminal. The output device is output.

Additionally, in some exemplary embodiments, the diagnostic article may include browser software. Such browser software may be loaded into a controller in the ATM and operative therein to provide output tokens as a result of processing maintenance data through a browser. In some embodiments, such browsers may be programmed to interpret instructions embedded in maintenance data that do not conform to published standards and/or are not generally public. These embedded instructions may be processed by the browser to output indicia usable during maintenance of the machine and to cause the controller to interact with transaction functions within the machine to perform maintenance actions. The use of such non-standard browser software also enhances the security associated with diagnostic items and machines.

Additionally, in some embodiments, the diagnostic item and/or the data stored in the ATM may include instructions to prevent continued execution of the browser software and/or data from memory after the diagnostic item is operatively disconnected from the controller. Retention of maintenance data for diagnostic items. These instructions may be used to minimize the threat of maintenance data from the diagnostic item, browser software, or other instructions contained therein continuing to run in the machine after an authorized maintainer has disconnected the diagnostic item from operative connection to the controller.

Additionally, in some embodiments, the diagnostic article may be configured for use with computer devices other than automated banking machines. For example, where the diagnostic item includes maintenance guide data, an authorized user can utilize the diagnostic item to obtain electronic maintenance guide files from a computing device such as a notebook computer, PDA, or mobile phone. In this case, the diagnostic instructions included in the diagnostic item that would otherwise interact with the machine controller and/or transaction function devices included in the ATM will not run in other types of computing devices. However, in these exemplary embodiments, it is understood that use of the maintenance instruction data included on the diagnostic item is prevented until it is determined that the security code corresponds to the time data entered by the user or indicates authorization for use of the maintenance instruction data. is appropriate in the process.

It should be appreciated that these methods and techniques are exemplary, and that in other embodiments other methods, techniques and capabilities may be used.

12 and 13 show exemplary diagrammatic logic flow diagrams associated with verifying an authorization feature of a diagnostic item, such as a CD, in an ATM. It should be noted that in the exemplary embodiment, a diagnostic item reading device, such as the exemplary CD reader 96, is typically located within the housing of the ATM and may be within a secure box to be accessible only to authorized maintenance personnel. This also helps ensure that only those personnel with normal access to the inside of the enclosure can perform maintenance actions, including having access to valuable files, sensitive customer data, or other information.

As shown in FIG. 12, once the maintainer has used the diagnostic item reading device, the controller may operate in step 186 to prompt the maintainer to provide input to enter the output flag of the diagnostic mode through the output means of the ATM. If, in step 188, the input to enter the diagnostic mode is set, then in step 190 the controller is operable to check whether a diagnostic item threat is present. If no threat is present in the diagnostic item reading device, the controller is operable to provide, via the output device, an indicia indicating the absence of any threat to the maintainer. This process occurs at step 192 when the controller returns logic to prompt step 186 .

If it is determined in step 190 that a diagnostic item is present, the controller is operable to cause data to be read from the item in step 194 . In an exemplary embodiment, the diagnostic article provides a security code that is also encrypted, and the controller is operable to decrypt the data into a usable form in step 196 . In step 196, the controller is operable to compare data corresponding to the at least one security code with authentication data used to determine whether the diagnostic item is valid. This is done in step 198. As previously discussed, verification data in various embodiments may be derived from information stored in memory within the machine, dated data, user-supplied input, or generally operable to reliably verify that the diagnostic item is authorized and is being used in its Other data used within the permitted scope. If in step 198 it is determined that the diagnostic item is not valid, then an indicia is output to the user via an output device of the machine to clearly indicate that the diagnostic item is not valid. This is done at step 200 and the logic returns to the prompt step.

If, in step 198, it is determined that the disc is valid, the exemplary embodiment causes the controller to operate according to its programming to provide an output indicium prompting the user to enter ID data. This is done at step 202 . Then, at step 204, the user provides at least one input to at least one input device on the ATM. Next, the controller is operable to perform a verification step 206 to determine whether the ID entered by the user is valid. In various embodiments, whether a user ID is valid may be determined based on security code data, date data, stored data, or a combination or relationship thereof operable to determine that use is restricted to authorized users. If the input from the user is determined not to be valid, when the controller returns to the logic flow, the controller is operable, as shown in step 208, to output a flag indicating that it is not valid to the output device.

If it is determined in step 206 that the user ID data entry is valid, the controller is operable to read the diagnostic item. As previously discussed, in some embodiments this may include loading browser software from the diagnostic item into memory operatively connected to the controller. Alternatively or additionally, this may also include decrypting encrypted maintenance data or instructions from the diagnostic item. In an exemplary embodiment, these actions may be performed and the controller operative to display a menu in response to the maintenance data included on the diagnostic item. This is done in step 210 .

In an exemplary embodiment of the diagnostic article, without the diagnostic article being used in the ATM, a controller in the ATM or a processor of a computer device is operable to perform a test step to determine whether the diagnostic article is operatively connected to the ATM. connect. As shown in step 210 in FIG. 13 . In an exemplary embodiment, diagnostic items include causing diagnostic data stored in the ATM to be used and utilized along with administrative maintenance actions. The logic flow diagram is derived at least in part from the instructions on the diagnostic article. If these diagnostic data and transaction functions are not present in the computing device because the computing device is not an ATM, the logic flow can be changed to accommodate use in a non-ATM computing device. That being the case, for purposes of performing the logic flow description, it is assumed that the determination in step 210 properly represents that the diagnostic item is operably connected to the ATM in the described circumstances. In turn, this causes the controller in the ATM to operate in response to the diagnostic item to provide diagnostic data where applicable, and to provide output indicia on the output device of the ATM corresponding to menu options and selections available for performing actions at the ATM .

The maintainer then makes the appropriate selections as shown in step 212, which selections correspond to menu options and selection outputs generated in response to operation of the controller. For example, this may include an option indicating that the maintainer would like to determine the nature of any anomalies that currently exist or have existed during operation of the transaction function devices in the ATM. Of course, other options may also be provided to the maintainer depending on the programming of the controller and the instructions on the diagnostic items.

In response to a user indicating that they would like to receive information about a fault or anomaly in the operation of the ATM, the controller is operable to output a flag corresponding to such information through an output device on the machine, and the advice can be executed at the ATM to determine A diagnostic test for the cause or type of malfunction or anomaly. This is indicated in step 214 . In response to this output, the maintainer provides input representing the actions the maintainer would like to take. This input may be provided through one or more input devices on the ATM. These input devices may be included in the designated maintainer interface, but in some embodiments, the input devices of the ATM normally used by the customer are used for this purpose.

Input from the maintainer in step 216 typically causes the controller to interact with one or more transaction function devices to perform diagnostic tests and receive test results. This is represented by step 218 . In response to the results of the diagnostic test and/or the maintenance data, the controller is operable to provide an output flag to the maintainer. This output flag can include information about the test result or can indicate that further testing should be performed. This is represented by step 220 . These further steps can be performed as appropriate for diagnosing a particular state of interest in the machine. In an exemplary embodiment, these further steps may include receiving instructions from a maintainer. In response to the instructions, the controller interacts with transaction function devices in the machine and maintenance data from diagnostic items to direct diagnostic actions. These actions are diagrammatically shown by a series of steps indicated at 222 .

The detected, corrected or addressed fault or other condition is to be detected, corrected or addressed by the controller operating in response to the maintenance data and the diagnostic data. This is indicated in step 224 . In an exemplary embodiment, once this process is complete, the maintainer can perform additional diagnostic actions by interacting with the machine. However, in this exemplary sequence of steps, it is considered that the maintainer has completed its action and returned the machine to service. In doing so, the maintainer provides appropriate input to the machine and removes diagnostic items operatively connected to the controller. This is indicated in step 226 . This action operatively takes the ATM out of diagnostic mode and prevents other use of the diagnostic data within the machine. Such action will also generally stop the running of any specified browser software associated with the maintenance item and diagnostic programs that only operate when the maintenance item is connected to the machine. Thereafter, the controller operates to return control of the ATM machine to the application program. This is indicated in step 228 .

It should be appreciated that the exemplary embodiments provide maintenance data, such as diagnostic instructions or other diagnostic actions described in a maintenance guide or other instructions or data, to interface with a controller of a machine. In an exemplary embodiment, this not only enables the maintainer to receive indicia corresponding to what the maintainer should do to perform a particular test, but also provides instructions to the controller based on the maintenance data so that the controller can perform the test. In addition, where appropriate, the results of the test can be used to guide the maintainer on appropriate remedial measures or different tests on maintenance data, so as to complete maintenance actions as quickly as possible. These capabilities, especially when combined with available diagnostic data stored in the machine about transaction function devices, allow for more accurate and quicker determination and correction of problems so that the machine can be returned to service.

As previously mentioned, in an exemplary embodiment, the diagnostic article may also operate as an electronic maintenance guide within a computer device rather than within the ATM.

As shown in Figures 12 and 13, use of the maintenance data included on the maintenance item may be limited in a manner similar to that employed when the maintenance item is used in conjunction with an ATM. This is done through appropriate programming and interaction with non-ATM computer devices. However, as shown in step 210 , when it is determined that the maintenance item is not operating within the ATM, the maintenance item only operates in the display mode as shown in step 230 . In the display mode, maintenance data is presented to the user in a manner similar to an electronic maintenance manual. Thus, the user is able to selectively browse information reviews, textual material and graphics associated therewith. However, when the diagnostic item is only operating in display mode, the diagnostic instructions that would otherwise cause the ATM's controller to interact with the transaction function device are not operable to perform functions not within the ATM computer device. It should be appreciated, however, that the ability to use the exemplary diagnostic item in conjunction with another type of computing device may in some cases be advantageous for maintenance. In some embodiments, the controller may be programmed to obtain diagnostic capabilities to remote computer devices over a network. In some cases, such capabilities may be provided when the diagnostic item is installed or run on a remote computer device. This may avoid the need in some embodiments for a maintainer to go to the machine to physically connect the diagnostic item to an item reading device such as a reader. Additionally, diagnostic actions can be performed remotely to facilitate identification of any events and minimize machine downtime.

It should be appreciated that while in some embodiments the diagnostic article is described as a CD or other read-only device, in other embodiments the diagnostic article may be another type of device. For example, this may include a portable terminal such as a notebook computer, PDA, mobile phone, or other suitable item that may be authenticated and may provide maintenance data and instructions to facilitate the performance of diagnostic actions.

In some alternative embodiments, diagnostic items may be used in systems capable of remote communication with the ATM. For example, a diagnostic item may be used in conjunction with a remote computer (operably connected to the ATM over a network). In some instances, operation and logic may be similar to that previously described, except instead of a diagnostic item near the ATM, it communicates with the ATM controller over the network. In some embodiments, information passing through the network may be encrypted to provide enhanced security.

For example, in some embodiments, the controller may be programmed to reside on a computer remote from the ATM as a diagnostic item on a CD, hard drive, or other computer readable medium. The remote computer includes output and input means for providing outputs and inputs similar to those previously described in diagnosing conditions at the ATM. In this way, the remote maintainer can diagnose and possibly change, adjust or correct the state of the ATM. In some embodiments, maintenance guideline data and diagnostic data may also be used by a remote service provider along with maintenance actions. One or more security codes or other means for obtaining diagnostic data and other values or functions may come from diagnostic items and/or input to the remote computer by the user, or may be from the user and/or input of other values from the remote computing device. Function. In some embodiments, the ability to perform administrative maintenance actions locally or remotely may be provided to facilitate maintenance of the ATM. Additionally, in some optional embodiments, the remote maintainer may work alongside the local maintainer on machine diagnostics. In some embodiments, a local maintainer may be associated with a remote maintainer. In other embodiments, the remote maintainer and the local maintainer may be associated with different entities.

For example, in some cases, the owner or operator of an ATM may choose to perform maintenance and repairs on its own ATM, or have a maintenance company not related to the ATM manufacturer perform such maintenance. This can be performed as a cost saving measure by machine owners or operators who may be able to solve simple problems directly through their own maintenance organization or through other maintainers.

However, whenever a more complex problem is encountered, the ATM owner, operator or maintainer may need the assistance of more sophisticated diagnostic capabilities. In these cases, assistance from other maintenance operations, such as the ATM manufacturer or other entity capable of remotely providing more complex or proprietary diagnostic and/or maintenance capabilities, may be required. In some embodiments, this may be accomplished through the use of a communication interface between the ATM and a remote maintenance system capable of providing diagnostic or maintenance capabilities. In some embodiments, the communication that can be achieved between the individual at the ATM and the remote maintenance system can be achieved through other communication means, such as a mobile phone or a laptop computer with a wireless modem.

In an exemplary embodiment, remote diagnostic and testing capabilities for the ATM enable on-line communication with a remote system to test the ATM and diagnose possible problems in a manner similar to that previously described. In some embodiments, communication with an individual at the machine may enable the individual at the machine to make repairs or take other remedial action. In some embodiments, this may be facilitated through the use of output devices, such as graphical displays of machine components and remedial procedures, and/or simulated human voice commands output through output devices on the ATM. These outputs can be used to guide individuals at the machine to perform detection and/or take remedial action. In some embodiments, the ATM manufacturer's maintenance center can provide personnel assistance along with testing and remedial actions. In other embodiments, testing and remediation guidance capabilities may be provided automatically from the manufacturer's maintenance system. In other embodiments, assistance may include a combination of human assistance and automated cross-sections to provide diagnostic and remedial guidance.

In some embodiments, the maintainer may charge for the use of remote diagnostic and remedial maintenance capabilities. For example, these fees may be paid periodically, per machine, per use, online time, type or kind of resource used, or otherwise. In cases where individuals or entities using the system are paid based on their usage, charges are to be regulated accordingly. For example, this may include identifying the machine and/or the entity represented by the person requesting maintenance from the maintenance facility himself. Such communication may be through the operation of a controller in the ATM, passing messages through one or more networks. In some embodiments, information stored in the memory of the ATM may be used and used as the basis for access charges. In some embodiments, an individual at the machine may provide identifying input to facilitate access charges. In some embodiments, these charges may include providing a financial or credit card or other account number to which the remote maintenance entity's charges may be accessed. In some embodiments, the charge information may be entered through manual entry at the ATM, such as through a keypad at the machine. In some embodiments, the charging information can be entered by using the maintainer's card through the operation of a card reader at the ATM. In some embodiments, these capabilities may obviate the need for ATM owners or on-site maintenance entities to establish any relationship with the manufacturer or other remote maintenance company prior to requesting maintenance. Additionally, this configuration may provide greater assurance of payment to the remote maintenance entity. Of course, these methods are exemplary, and in other embodiments, other methods may be used.

In other exemplary embodiments, data associated with a machine may be collected through the use of a computer-readable medium placed in operative connection with one or more computers operating within the machine. In an exemplary embodiment, this computer readable medium may be used to collect machine-associated data represented by indicia recorded on the medium. The computer readable medium can then be operatively connected to the analysis computer. Next, the analysis computer is operable to analyze the data to determine errors, failures, changes, status, counts, frequencies, or other information that can be used to identify problems or predict possible conditions and indicate the need for future maintenance of the automated banking machine .

FIG. 34 schematically shows an automated banking machine 302 . At least one computer 304 is included in the ATM 302 . Computer 304 includes one or more processors, and the processors are operably connected with one or more data stores, represented diagrammatically at 306 . Computer 304 is also operatively connected to at least one visual output device, represented diagrammatically by screen 308 .

ATM 302 also includes a plurality of transaction function devices 310 operably connected to computer 304 . Transaction function 310 may be of the type previously described, which operates during the execution of transactions at the ATM. For example, these transaction function devices may include card readers, cash dispensers, printers, input devices (such as keypads, function keys, or touch screen displays), biometric card readers, check imagers, cash dispensers, or other types of device. It is of course to be understood that the devices mentioned are only examples of the many devices that may be used. The exemplary ATM also includes a read/write device 312, which in the exemplary embodiment includes a CD read/write drive. CD read/write device 312 is operable to read and write indicia on removable computer media, such as the CD shown schematically 314 . However, it should be appreciated that CD read/write device 312 is exemplary and in other embodiments other devices for reading and writing computer readable information may be used. For example, these devices may include USB drives, hard drives, smart cards, magnetic disk drives, tape drives, or other items that can perform read and/or write functions. It should also be appreciated that in some embodiments separate devices may be used to perform the read and write functions.

The exemplary ATM 302 also includes a communication device 316 . The communication means is operable to cause the ATM to communicate over one or more networks 318 . The network 318 of the exemplary embodiment enables the ATM 302 to communicate with a financial transaction computer illustrated at 320. In the exemplary embodiment, communication between ATM 302 and financial transaction computer 320 enables the ATM to execute transactions. The exemplary embodiment also enables ATM 302 to communicate over network 318 with computers associated with one or more maintainers, illustrated at 322 . In some embodiments, communication with the maintainer computer may cause the ATM to indicate a particular condition that exists at the ATM, such as a malfunction or the need to replenish cash or other consumable items. In some embodiments, this communication with the maintainer computer 322 may cause the appropriate maintainer to be dispatched to fix the problem. Also shown diagrammatically in FIG. 34 is an isolated computer system 324 . Computer 324 may be used as an analysis computer for analyzing data associated with the ATM in a manner discussed later to detect errors, malfunctions, or other indications of problems associated with the ATM.

In this exemplary embodiment, ATM 302 is used to associate various types of data stored therein with its state and/or operation. Such data may be stored in one or more files in data store 306 . Optionally, data may be stored in each of the data stores in the plurality of transaction function devices 310 , represented diagrammatically by 326 . The stored data is determined by programming of the computer 304 and/or processor included in the transaction function device. In an exemplary embodiment, such data may include program settings associated with configuration characteristics of the machine. These may include, for example, settings programmed within the machine with respect to communications, operation, or other parameters (which may be set in layers by software, hardware, or both) to enable the operation of the machine. Data stored in one or more data stores of ATM 302 may also include data regarding the device and/or its operating characteristics during operation of the one or more devices. For example, this may include data representative of device performance or operating parameters of the type previously discussed during prior operation of a plurality of machines. Optionally, such data may be associated with the most recently started operation. These device-associated data may also typically include fault data. For example, such failure data may include instances where a transaction function device attempts to perform a function, fails to do so, and then successfully completes the function after one or more attempts. Such fault data optionally also includes, for example, situations where a given device experiences a blockage, which can then be cleared by performing a recovery procedure. Such data may optionally include data corresponding to a partial loss of device capability. Of course, it should be understood that these failure examples are merely exemplary.

Embodiments may also store data in the data store for predicting future needs of devices in the maintenance machine. As discussed previously, information such as speed, pressure, vacuum, cycle time, wear rate, period, power loss, changes in calibration data, and other information may be sensed and stored for monitoring the ATM's operating parameters. Such data may also be used to predict possible future failures or other conditions that would require maintenance on the ATM or devices therein at some future time. In an exemplary embodiment, the developer of the ATM may determine specific types of data for such analysis and may enable the data to be captured and stored in one or more data stores during machine operation. Of course, it should be understood that these methods are exemplary and in other embodiments other methods may be used.

For example, examples of parameters stored and calculated for a money dispenser in an automated banking machine may include: the total number of papers dispensed from the start of machine service, and the total number of notes transferred from the start of machine service that were picked up by the device and not dispensed . Values may also include the total number of notes rejected, transferred, and/or recalled in a set of transactions (eg, the last 500 transactions performed by the machine). Other parameters may include the average time it takes the cash dispenser to perform a given function during a set of transactions, eg, the dispense function over the last 500 transactions. Another parameter may include the average time for a set of transactions that the device takes to present a stack of notes that has been assembled within the ATM. For example, it is also possible to perform this process on a set of transactions comprising the last 500 transactions. Other values that may be monitored in this exemplary embodiment include the number of missed and repeated picks in a set (eg, the last 50 transactions). Other values may include the number of instances in a set of transactions where two tickets are dispensed back-to-back by the pickup device when only one ticket is requested. For example, this process can be tracked for the last 50 transactions. In an exemplary embodiment, other values include values associated with sensors in the device. For example, this may include power loss for the sensor's radiation or other transmitters for generating a calibration output signal at the sensor's associated receiver. This process can be done for multiple radiation or other types of sensors within the device. Of course, exemplary values representing conditions that may arise within the exemplary types of cash dispensers may be used, and in other embodiments and for other device types, other parameters representing potential problems or conditions that may arise may be used. .

Of course, it should be understood that each type of transaction function device within a machine typically has a different type of parameter that is measured, calculated and/or stored to provide a state that can be determined and/or predicted. Information required for future maintenance. The maintainer can then go to the machine and perform the appropriate maintenance actions.

In an exemplary embodiment, the maintainer is provided with the ability to operate the computer in the machine to collect data associated with the operation of the machine and analyze it to determine errors or malfunctions and/or perform predictive analysis to determine future needs Perform maintenance on ATMs. Instructions are included on a removable computer readable medium such as CD 314 . The instructions are operable to cause the computer 304 to execute the example logic shown in FIG. 35 . Insertion of the computer readable medium in CD read/write drive 312 is operable to cause instructions on the CD to be automatically executed by the computer. This is represented by step 328 in FIG. 35 . The instructions are operable to cause the computer to generate output via the screen 308 . In an exemplary embodiment, the output is operable to indicate that a maintainer, having inputted the computer readable medium, is gathering data from the machine. In an exemplary embodiment, the output is operable to represent an elapsed time in the process of collecting the data. In some embodiments, this may take the form of an output representing the percentage of the data collection process that has been completed at any given moment in time. In alternative embodiments, more detailed information may be output to indicate the type of data being collected, the specific device involved, and/or other information that may be used to indicate to the maintainer what is happening in the process. Such output may include graphical elements, textual elements, or both. The generation of this process window is represented by step 330 in FIG. 35 .

Execution of the instructions on the medium is also operable to generate at least one thread of processing in the computer 304 . This is represented by step 332 in FIG. 35 . The processing thread is operable to cause the computer 304 to perform data collection, provide screen output, and perform other steps as described. At least one thread 332 is operable to cause the computer to create at least one temporary file in data storage 306 . This is represented by step 334 in FIG. 35 . In an exemplary embodiment, temporary files are used to store data gathered by the computer in response to instructions.

As the computer executes one or more processing threads in response to instructions, data is collected and included in one or more temporary files. This is represented by step 336 in FIG. 35 . As previously mentioned, in an exemplary embodiment the data collected may include settings or other data related to configuration parameters, information about malfunctions, problems occurring in the operation of the device, values of calibration parameters, number of instances of events, A time value associated with an event, and/or other operational characteristic of the device may be included during the execution of a plurality of previous operations of the machine. In an alternative embodiment, the instructions are operable to use the machines' dedicated transaction function devices to test their functionality and current operating characteristics, and to generate data in response to their operation. Thus, for example, the instructions may be operable to cause the computer to attempt to operate a number of different transaction functions in the machine, and to gather current data in response to its attempted operations. It should be appreciated that in some embodiments not all of these types of data are collected and that additional or different types of data may be collected.

In an exemplary embodiment, the collected data is secured by at least one computer operating in response to instructions included on a removable computer medium. This is represented by step 338 in FIG. 35 . In exemplary embodiments, this may include computers applying password protection to data. Alternatively and/or additionally, the computer is operable to apply encryption to the data. Additionally, as discussed herein, security schemes may be applied through the operation of the computer, including digital signatures, digital certificates, or other forms of security.

In an exemplary embodiment, computer 304 is also operable to store indicia corresponding to the data on a computer-readable medium. This is done by a computer controlling the operation of the CD read-write device. This is represented by step 340 in FIG. 35 . In an exemplary embodiment, the computer is operable to enable indicia corresponding to the data to be written to a CD from which original instructions for gathering the data can be obtained. As discussed previously, tags can indicate a protected form of collected data.

In operation of the exemplary embodiment, the computer is operable to close the temporary file in the data storage in response to instructions loaded from the removable computer readable medium. This is represented by step 342 in FIG. 35 . The instructions are also operable to cause drive 312 to eject the CD when a mark has been recorded on the CD. This is indicated in step 344 . The instructions are then operable to cause the computer 304 to terminate one or more processing threads for causing the data to be collected. This is represented by step 346 . It should be appreciated that the logical processes represented in Figure 35 are merely examples of logical processes that may be used and the order in which they are performed.

In an exemplary embodiment, an indicia corresponding to data associated with the automated banking machine is written to a removable computer medium, such as a CD. The information may then be analyzed by an analysis computer such as computer 324 diagrammatically shown in FIG. 34 . In an exemplary embodiment, the analysis computer is programmed to perform analysis of the data represented by the indicia recorded on the CD. In an exemplary embodiment, this analysis includes analyzing data for errors in configuration characteristics of the machine. For example, this may include errors associated with inconsistent settings in a machine leading to erroneous or improper operation. It can also include error analysis. For example, this may include situations where the device must repeat operation or recover from a failure to perform a transaction. Alternatively or additionally, the analysis computer may be operable to examine data associated with operating parameters and, based on programmed analysis of these parameters for a particular device, predict: possible future need for maintenance of one or more devices, required The type of maintenance, and the length of time before such maintenance is required. Of course, these types of analyzes are only examples of those that can be performed.

Figure 36 diagrammatically represents the logical steps associated with data analysis by the analysis computer. First, the removable computer readable medium is imported into a reading device, such as a CD drive, operably connected to the analysis computer. This is represented by logical step 348 . Additionally, in an exemplary embodiment, the tokens representing the collected data may be password protected. This password may be determined by instructions included on the medium, eg, known only to the provider of the ATM machine or other analysis software. In order to recover the data, in the exemplary embodiment, the correct password must be entered into the analysis computer. This is represented by logical step 350 in FIG. 36 .

In response to entry of the correct code, the analysis computer is operable to read the indicia and retrieve data collected from the banking machine. This is indicated in step 352 . The analysis computer is then operable to analyze the data according to its programming. In an exemplary embodiment, this analysis includes analyzing configuration data for determining whether settings at the machine are incorrect or inappropriate. Additionally, in an exemplary embodiment, fault data is analyzed to determine that a condition may exist at the machine, wherein the condition indicates a problem that requires correction. Such analysis is represented diagrammatically in logical step 354 .

Additionally, in an exemplary embodiment, the analysis computer includes programming including predictable analysis rules. The predictive analysis rules are operable to analyze data associated with parameters and/or operating characteristics of one or more transaction function devices. These operational characteristics are analyzed to determine characteristics associated with operation and to predict future needs to perform maintenance actions associated with one or more transaction function devices. This is represented by step 356 in FIG. 36 .

Operation of the analysis computer is operable to generate and output one or more results. In an exemplary embodiment, such results indicate a problem, incompatibility, malfunction or error with a configuration setting. The analytics computer may also provide predictive analytics and one or more outputs indicative of the need to perform further maintenance actions related to the banking machine. The determination of these results is represented in step 358 .

In an exemplary embodiment, the analysis computer is operatively connected to one or more output devices. In exemplary embodiments, these output devices may include screen output, printers, modems, automated voice output systems, computers providing network interface output or email output, or other types of devices. In an exemplary embodiment, the program of the analysis computer is operable to enable output via one or more output devices corresponding to the results. This is indicated in step 360 . In some exemplary embodiments, the results may be in the form of a detailed report including remedial actions to be taken at the machine. Generally, in an exemplary embodiment, this information can be used to perform processing to correct any immediate problems. Alternatively or additionally, an output providing a prediction of maintenance actions that will need to be performed at the machine in the future reflects a developing problem when determined by predictive analysis rules that can also be repaired at the same time. This has the benefit of avoiding machine failures which may occur sporadically. Likewise, it may enable the identification of developing or active conditions that may cause other failures to occur or lead to premature failure of spare parts. Alternatively or additionally, in some embodiments, the results of the analysis may include recommended changes to configurable settings of the machine or the generation of other data or software that may be loaded into the machine to provide remedial changes thereto. For example, this can include changes to configurable settings in order to fix problems. Of course, these methods are exemplary.

For example, in some embodiments, the output from the analysis computer may indicate that a particular sensor in the machine is displaying a power signature indicating that replacement may be required within a few weeks. Optionally, these analyzes may show that a particular motor is displaying speed and/or power consumption characteristics suggestive of reaching the latter part of its useful life. Alternatively, the analysis computer may show that the selection of a particular selection mechanism in the past has not been very reliable and that within a few months selection elements will need to be replaced. Alternatively, the data may indicate that lighting (such as a backlight for a display screen) or other components in the machine are experiencing changes in power consumption, indicating that a failure will occur within a relatively short period of time. These types of information, when analyzed by the computer output, can be used to inform the maintainer what exactly should be done to prevent the machine from malfunctioning the next time it is at the machine. Additionally, in the exemplary embodiment, the analysis computer is operable according to its programming to determine not only remedial measures, but also parts or other materials needed to perform the required maintenance. For example, this information can be used to compile the required items that the maintainer will need when making the next maintenance call for the machine for which the data has been analyzed. For example, this may be done by collecting and analyzing data including information corresponding to the model and type of components in the ATM, which may enable the selection of precise maintenance parts. The analytical computer can then be run according to its program and stored data to identify these components. Such information may also be used in some embodiments to ensure that maintainers have local inventory suitable to perform necessary maintenance actions as appropriate based on pre-analyses. Of course, these methods are exemplary and in other embodiments other methods may be used.

It should be appreciated that in alternative embodiments, instructions for at least one computer of the machine may be provided from a remote computer, such as computer 322 shown in FIG. 34, rather than from removable computer media. These instructions may be loaded into an automated banking machine in order to collect one or more types of data from the machine. In these embodiments, the data may be loaded to a medium at the machine. Optionally, these data may be transmitted to one or more computers, such as computer 322, over one or more networks. Thus, the delivery of computer-executable instructions and the collection of data can be performed remotely electronically. Additionally, in some embodiments, wireless methods may be employed, such as laptops, PDAs, mobile phones, or other types of devices used to collect data. In some exemplary embodiments, the analysis computer may be located relatively far from the automated banking machine. In other embodiments, rather than being relatively close to the machine, the analysis computer may be operably run remotely, such as on a maintenance technician's laptop or PDA. Depending on the particular ATM and the system it operates on and the needs of the system and the type of analysis to be performed, a variety of methods can be used.

In other exemplary embodiments, the remote maintenance entity may provide the ability to upgrade ATM-resident software. This can be performed by the ATM owner or operator or local maintainer upon request. Optionally, this may be performed periodically by the remote maintainer as part of a subscription service or other action.

The software programs resident at the ATM are subject to occasional changes. These changes may be in the nature of upgrades, bug fixes, new security features, support for new functions or devices, or enhanced functionality. In some cases, such software changes may be significant enough that the operator of the ATM or the network it uses can test and certify that the change is suitable for use. In other cases, the change may not be significant enough to warrant validation.

The ATM used in the exemplary embodiment may utilize suitable communication means operatively connected to the ATM controller for communicating with the remote maintainer system. For example, such communication means may include a modem, network card, or other means for communicating with the maintainer system over an appropriate network. In some exemplary embodiments, the controller may store computer-executable instructions, such as agent software, in its associated data store for enabling information generation and communication between the ATM and the maintainer system. The ATM controller may also be operatively connected with hardware or software adapted to provide encryption, SSL, and/or other techniques for ensuring secure communications with remote systems. It should be appreciated that various methods may be used depending on the nature of the system, the network over which it communicates, and the nature of transferring data or other items between the remote maintenance system and the ATM.

In the event of a problem in the ATM, the controller may be operable, responsive to appropriate authorization data, to send one or more messages to the remote maintainer system representing the software item and the revision level of the software currently residing in the ATM. A remote server operated by the remote maintenance provider receiving this information can be programmed to compare or analyze the software item with the most recent software for a particular type of ATM and/or ATM network or operator, or to analyze such software for failure. The remote system may alternatively or additionally check to determine whether the indicated copy of the software is licensed for use at the particular ATM. This may be done based on received data stored in ATM memory identifying the particular machine. Once correctness is determined, corrections, enhancements or other desired changes and/or one or more items of software at the ATM may be provided which may cause the server to download the changes or one or more complete software items to the ATM's controller. The controller is operative to store the downloaded software in local memory.

In some embodiments, this may be performed automatically through the operation of the ATM controller and remote server. In other embodiments, it may be performed in response to input provided by personnel at the remote maintainer facility, at the ATM, or both. In some embodiments, as a prerequisite to downloading the fix or software, the maintainer is required to provide billing data or make payment to the remote maintainer for providing this software or maintenance. Alternatively or additionally, the remote maintainer may require agreement regarding contract term agreement and/or registration receipt or other data prior to electronic delivery of software or amendments. In some embodiments, this may be accomplished through communication between the remote server and the ATM controller. Such communication may cause the ATM to output the license expiration date, which is then "clicked to agree" or other legal terms that may be accepted by the maintainer at the ATM via one or more input devices. Additionally, the server may cause the ATM to output a prompt for input of information by the maintainer, such as license registration data or other information required by the operator of the remote server, as a condition of providing software changes. Alternatively or additionally, the remote maintainer may operate to send information to the computer instead of to the ATM controller to obtain agreement on deadlines, entered data or other data or information. For example, this can be done where the owner or operator who is not located at the ATM personally has to agree to legal payment terms, provide data, approve or communicate with the remote maintenance provider. Of course, these methods are exemplary.

In some embodiments, the remote maintainer may alternatively or additionally operate to load diagnostic software onto the ATM and/or activate diagnostic capabilities of an otherwise unusable ATM. Such diagnostic software or capabilities may be removed or stopped at the end of a particular maintenance session, may be stopped after a period of time, or may operate continuously. Appropriate communications with remote servers may also be exchanged to provide appropriate authorization and payment for these capabilities.

In other exemplary embodiments, a remote maintainer may provide software management maintenance to the owner or operator of the ATM. For example, such maintenance may include: automatically loading ATM's software corrections, updates, or upgrades to software residing on a particular ATM. For example, this can be done automatically through secure communication between the ATM controller and a remote server. This can be done on a schedule by the remote maintenance provider in response to paying the maintenance provider for the ATM owner/operator of the order. Alternatively, for one or more ATMs, this may be done on a per request basis by an authorized maintainer or an unauthorized maintainer present at the machine and providing input. Of course, these methods are examples of many that can be used.

As previously discussed with reference to Figures 17, 18 and 28, an exemplary embodiment of the ATM may include a diagnostic application 2140, 1044 operable to access the underlying functionality of the ATM hardware device. These low-level functions can include subcomponents that apply motor sensors or other hardware devices. With such fine-level control over the inner workings of an ATM hardware device, it is possible to determine the source or cause of a malfunction in the upper layers of the device.

In an exemplary embodiment, the diagnostic application 2140, 1044 may include textual, audible, or graphical information to facilitate maintenance activities at the machine by maintainers of various skills and maintenance styles. Use of the diagnostic application 2140 , 1044 may be initiated by operatively connecting a diagnostic item, such as the diagnostic item 98 previously mentioned in connection with FIG. 4 , with the controller 72 . Any of the various security measures discussed previously, such as biometric identification, date and time restrictions, encryption, or physical barriers, can be used to ensure that only authorized maintainers have access to the diagnostic application. The logical flow diagrams shown in Figures 12 and 13, or other series of logical steps designed to limit access to authorized maintainers, may be implemented.

In an exemplary embodiment, a graphical indicia of status or other information may be output via the ATM's output device once the diagnostic application is launched. Exemplary screens bearing indicia of the ATM's system and module status are shown in FIGS. 19,20. As shown in FIG. 19, the graphical representation of the ATM 2500 may include a plurality of icons 2510 for representing modules or components of the ATM 2500 related to which additional information or testing options may be available.

In an exemplary embodiment, a tick denoted by reference numeral 2510 may represent a satisfied state. An "X" shown by reference numeral 2520 in FIG. 22 may indicate a malfunction or error of unknown origin. A lowercase "I," denoted by reference numeral 2530 in FIG. 22, may indicate a module or component that may provide additional information. Such information may be diagnostic data gathered during ATM operation, such as information about stall failures, or operational data such as speed, strength, deflection, vacuum, force, friction, pressure, wear or is a significant parameter). The exclamation point shown in FIG. 21, indicated by reference numeral 1220, may indicate a problem with known solutions, such as an insufficient supply of envelopes. It should be noted that these icons are exemplary in nature due to the nature of the state each icon implies. Other or different icons or other indicia may be used to represent or imply actions, states, or other information useful to the maintainer.

In addition to graphical status representations, diagnostic application 2140 may be operable to output textual, audible, or other indicia representing the same or similar information. In the exemplary illustration in FIG. 19 , textual state description 2550 is displayed next to graphical state representation 2500 . In FIG. 23, a textual embodiment of a portion of a diagnostics application 2140 is shown that may be displayed without graphical accompaniment. In other embodiments, the ATM output device, such as a printer, via the ATM speaker, or via other suitable equipment, such as via a separate maintenance device, such as a PDA, laptop computer, operatively connected to the ATM to be serviced, may be , or other personal electronic devices) to output information.

Diagnostic application 2140 may be operable to display various graphical representations, suggest solutions to problems, perform tests, or provide additional information in response to maintainer input. The maintainer's input may include actions such as clicking or touching icons, entering text commands, pressing buttons, or transmitting instructions from a separate local or remote maintenance device. In the exemplary embodiment shown in FIG. 19, in response to the maintainer clicking on the advanced function allocator icon 2560, or the adjacent advanced function allocator text line 2565, as shown in FIG. The representation is displayed on the ATM output device. This module representation 2580 may include a number of icons 2510, 2520, 2530 or other indicia of modules or components of the advanced function assigner module for additional information, tests, or other actions available. The diagnostic application 2140 may also be operable, in response to maintainer input, to switch to an entirely different diagnostic program, or to abandon the diagnostic application entirely. In an exemplary embodiment, this may be accomplished by clicking or touching one or more graphical tabs 2590 as shown in FIG. 20 .

In the exemplary embodiment shown in FIG. 22, the diagnostic application 2140 may be operable to output the indicia of the various diagnostic options to the maintainer. For example, the output may include a faulty component of an exemplary module represented using icon 2520, or other indicia. This output may also include other indicia of status, questions, or options, such as textual representation 2600 of component status shown below graphical representation 2560 in FIG. 22 . The diagnostic application 2140, 1044 may be operable to provide recommended restoration actions in response to maintainer input. In the exemplary embodiment shown, in response to clicking on unknown problem icon 2520 , the diagnostic application enables output to be displayed including number of recommended recovery actions 2610 . In this exemplary embodiment, the output is displayed below the textual representation 2600 of the component state. In this exemplary embodiment, the recommended recovery actions are ranked based on the most likely causes of failures or errors, visualized by percentage 2620 in FIG. 22 .

The diagnostic application may be operable, responsive to input by the maintainer, to output to the maintainer one or more articles related to the maintenance data on the diagnostic item. In the exemplary embodiment shown in FIG. 24 , in response to the maintainer clicking the recommended restoration action, the diagnostic application enables the ATM to output a maintenance guide article when replacing lead indicators and exit sensors. In the exemplary embodiment shown in FIG. 24, articles are displayed on a screen in an ATM. In other embodiments, the articles may be displayed on other terminal output devices, or on other electronic devices operably connected locally or remotely to the ATM.

Since diagnostic items may be updated periodically, or available in multiple languages or for multiple ATMs in conjunction with the same diagnostic application 2140, diagnostic item 98 may include an index or cross-reference (which will be embedded in the diagnostic application 2140 relative The permanent reference is linked to the appropriate section of the maintenance data included in the current version of the diagnostic item 98). Diagnostic application 2140 may be used with multiple versions of a diagnostic item, or with multiple versions of the same diagnostic item 98, by updating the index or cross-reference table.

Other exemplary features of the diagnostic application 2140 may allow a maintainer to selectively operate various components of a module or assembly, or to perform selected tests. In the exemplary embodiment shown in FIG. 20, when displaying the module status page, the diagnostic application also displays textual descriptions 2630 of the various commands and tests the maintainer wants to perform. Diagnostics application 2140 is operable to execute various commands or tests in response to maintainer input (such as clicking a command line), and may also be operable to output additional Information (such as component state). Based on the output information, the maintainer can also take steps to resolve any identified problems.

In an exemplary embodiment, the diagnostic application may provide a wide range of scripts for problem diagnosis that may assist a maintainer in diagnosing a problem by performing a series of steps. Exemplary scripting options can direct a maintainer to perform a series of tasks, including high-level operations such as printing a receipt, and low-level operations such as turning on the motor that drives the receipt printer. Alternatively, the maintainer may choose to independently select and execute actions that the maintainer's knowledge and experience indicate may be the source of the problem. In such a self-guided use of the diagnostic application, the maintainer can use the low-level and high-level controls of the transaction function device to facilitate testing the general function of the transaction function device, or the interaction between two or more transaction function devices The role, and the detailed function of each component of the transaction function device.

In an exemplary embodiment, the diagnostic application 2140 may also be operable, in response to a change in system, module, or component status, to prompt the maintainer to document a solution to the problem. This information may be stored as part of the diagnostic data described above. The example diagnostic application 2140 may also be operable to communicate such diagnostic data to the diagnostic article 98 for transmission to the diagnostic data collection application. Such diagnostic data may be compiled and analyzed periodically, the weights of suggested recovery actions modified to reflect actual maintenance experience, and the modified weights communicated back to the diagnostic application via new versions of diagnostic items 98 or other devices. In other embodiments, diagnostic data indicative of proper recovery action may be automatically recorded based on data from the transaction function device along with changes in component status, or may be diagnosed through a device other than item 98, such as through an online connection (e.g., via a modem, website, wireless, or wired transmission) to transmit diagnostic data to a diagnostic data collection application.

In some exemplary embodiments, any of the diagnostic enhancements described above may be more readily available to a wide variety of maintainers through the use of diagnostic tools. The architecture of this tool 2700 is diagrammatically shown in FIG. 25 . Diagrammatically shown is a diagnostic base application 2710 including terminal-level features and the overall architecture of device diagnostics. In simple form, an exemplary architecture such as that discussed in connection with FIGS. 19-23 may include tabbed pages containing various diagnostic options, including graphical and textual , or icon or text usage for suggested recovery actions; and links to individual or combined maintenance guides.

In an exemplary embodiment, diagnostic base application 2710 may interact with diagnostic support framework 2730 to summarize diagnostics, and diagnostics may also interact with data stores 2740, 2750 to support translation of device-specific diagnostic configurations into Global diagnostic configuration used by vendor-specific diagnostic applications. Diagnostic base application 2710 can also interact with internationalization support framework 2760 to provide support for diagnostic internationalization, which can also interact with data stores 2770, 2775 to support conversion of device or country specific string tables into A string that can be used by the target audience.

The example diagnostic tool can also interact with the support framework for diagnostic equipment 2730 and internationalization 2760 in creating the example user interface component 2780 and device diagnostics for a diagnostic application targeted to a particular maintainer audience. The user interface component 2780 of the diagnostic tool can also interact with a commonly configured support framework for the recovery actions database 2790 to operably connect to the device-specific recovery actions database 2800 .

As shown, diagnostic configuration and internationalization support can be provided through remote, or network interaction 2720, while recovery database support can be provided more directly. It should be noted that these interactions are exemplary in nature and other connections are suitable.

Additionally, as shown in Figure 25, to increase the usability of synthetic diagnostic tools to the broad population of maintainers, the device and architecture module interfaces 2810, 2820 may be packaged in a more general architecture or technology 2830, 2840, such as Microsoft's . Net technology.

The use of this tool enables companies to easily create diagnostic applications in various languages for various transactional functional devices with a homogenous operation, architecture, and look and feel. This expands the range of machines that can be serviced by individual maintainers through virtually seamless transitions from one diagnostic application to another.

As previously discussed, an exemplary embodiment of an ATM with an XFS layer may include a diagnostic application 2140, 1044 operable to control internal components of the transaction function device of the ATM without communicating with the hardware device through the XFS layer.

In alternative exemplary embodiments, the previously described diagnostic application 2140, 1044 or a different diagnostic application running in the ATM can be used by a technician to diagnose possible Issues associated with terminal applications in the application layer above.

For example, as shown in FIG. 30 , an exemplary embodiment of an ATM may include a diagnostic application 1516 that may be operable to determine whether a problem in the ATM is caused by components in the application layer 1510 of the ATM or by components in the hardware layer 1512 of the ATM. caused by hardware or software components. Determination can be made by hardware means controlled by each XFS layer that executes a number of predetermined operations or functions. The diagnostic application may be operable to form a determination of whether the application layer 1510 or the hardware layer 1512 is responsible for a problem arising in the operation of the ATM based on whether the operation was successful or not.

For example, an exemplary embodiment of an ATM may include a cash dispenser, a deposit mechanism, and/or a card reader. Each of these hardware devices may be associated with a vendor-supplied SP. This depicted exemplary embodiment of diagnostic application 1516 may be in operable communication with XFS layer 1502 to run each hardware device 1518 through a predetermined set of operations. For example, through direct calls to the XFS layer, the diagnostic application 1516 may attempt to cause a cash dispenser to dispense a certain amount of cash and to withdraw a certain amount of cash. If the operation of the cash dispenser is unsuccessful, the diagnostic application may be operable to determine that the problem with the ATM corresponds to a hardware layer 1512 of the ATM, such as SP 1513, UBR component 1515, module interface framework 1517, or hardware device 1518. If after running each device through a predetermined set of functions, all operations are successful, the diagnostic application may be operable to determine that the problem with the ATM corresponds to an application layer of the ATM, such as an end application written to interface with the XFS layer programs, user interface applications, TEC components and/or ODS components.

In an exemplary embodiment, the diagnostic application may also prompt a technician to perform a function using the ATM. For example, when testing the functionality of a card reader, diagnostic application 1516 may prompt a technician to insert a card. In addition, the diagnostic application can also prompt the technician to confirm whether the function of the ATM is being performed correctly. For example, when testing a receipt printer, the diagnostic application may include predetermined operations that cause the receipt printer to print a receipt. After printing the receipt, the diagnostic application may prompt the technician to confirm that the receipt was properly generated and distributed to the technician through input from the ATM's input device. The diagnostic application can also output information about the expected output of the function via the display device, such as what information should be printed on the receipt. The diagnostic application may then cause the technician to enter a response indicating whether the printed receipt corresponds to what should be printed on the receipt.

In an exemplary embodiment, the diagnostic application may cause the ATM to output via an output device a message or other communication indicating which of the ATM's application layer or hardware layer is most likely responsible for a problem or error with the ATM. For example, Figures 31 and 32 illustrate the output 1540, 1542 produced by the diagnostic application shown through the display device 1544 of the ATM. As shown in FIG. 31, if all predetermined functions are successfully completed, the diagnostic application may cause the ATM to output an up arrow 1548 or other indicia through the display device to represent one or more components responsible for the components in the application layer of the ATM. A supplier can take care of ATM problems. If one or more predetermined functions performed by the diagnostic application are not successfully completed, the diagnostic application may cause the ATM to output a down arrow 1550 or other indicia through the display device to indicate the location of the software and/or hardware components responsible for the hardware layer. One or more providers can be responsible for ATM issues).

In other exemplary embodiments, the diagnostic application may also be responsive to the type of error detected in determining whether to output an up arrow or a down arrow. For example, if the ATM has previously generated an error message corresponding to an operational problem with the cash dispenser mechanism, the diagnostic application may respond to the generated error message and may limit testing of the ATM to maintenance associated with cash dispensing provider and hardware device. In an exemplary embodiment, if a diagnostic application detects a problem with a software and/or hardware component of the hardware layer of the ATM that appears to be unrelated to the component that caused the error message, the diagnostic application can still provide the technician with information about all Information about detected problems. However, the diagnostic application can also provide output indicating that the detected problem is not related to the error message, thus, the supplier responsible for the component in the application layer can still be responsible for fixing the component associated with the error message.

FIG. 32 shows an exemplary embodiment in which the ATM 1600 includes a security management application 1602. As previously described, components of the device driver layer 1604 are operable to control the operation of the hardware device 1608 in response to the XFS layer 1606 . In this described exemplary embodiment, components of device driver layer 1604 may also control the operation of hardware device 1608 in response to security manager application 1602 . Exemplary embodiments of the security manager may be operable to selectively start or stop various components of the device driver layer, such as the SP 1610 , the UBR component 1612 and/or the module interface framework 1613 . Each of SP 1610, UBR component 1612, and/or module interface framework is adapted to communicate with security manager 1602 to determine whether they proceed in response to information received from the XFS layer, diagnostic applications, or other applications Control over hardware devices. For example, if an SP or UBR component associated with a cash dispenser device receives information from the XFS layer to cause a cash dispenser of an ATM to dispense cash, the The relevant SP or UBR is operable to obtain authorization from the security manager.

In an exemplary embodiment, the security manager may authorize exactly each individual SP or UBR component. Thus, each SP or UBR must receive authorization to continue performing the function before causing the corresponding hardware device of the ATM to perform the function. In another exemplary embodiment, each SP and/or UBR may continue to control the hardware device unless they receive information from the security manager 1602 not to continue to control the hardware device. Thus, each SP and/or UBR may be operable to control the hardware device when the security manager is not installed on the ATM or is not enabled. However, when the security manager is installed and enabled, the same SP and/or UBR component may be operable to stop accessing the XFS layer when information from the security manager indicates that the SP or UBR component stops controlling the hardware device in response to the XFS layer. response. In this alternative exemplary embodiment, the SP and/or UBR components can be used in an XFS enabled ATM without requiring a security manager to be installed on the ATM. When the security manager is installed on the ATM, the SP or UBR component can then start responding to the security manager before operating the hardware device.

In an exemplary embodiment of an ATM that includes an XFS layer 1502 and a module interface framework 1613, the framework's device servers (i.e., the device scheduler and manager) may be operable in response to communications with the security manager 1602 to selectively Control transaction devices, such as cash dispensers. In these described exemplary embodiments, communications between security manager 1602 and device driver layer 1604 may be encrypted and/or digitally signed or cryptographically authorized to prevent rogue applications from impersonating the security manager.

In an exemplary embodiment, components of the application layer 1614 , such as the previously described TEC or ODS components 1616 , 1618 , may also be operable to communicate with the security manager 1602 prior to communicating with the XFS layer 1606 . The security manager may be operable to enable the boot device driver layer to continue to control the hardware device in response to information received from the TEC, ODS, or other application layer components. For example, the cash dispensing TEC or ODS component may first send information to the security manager before the cash dispensing TEC or ODS component transmits cash dispenser commands to the XFS layer. This information may enable the security manager to enable elements of the device driver layer associated with cash dispensing (i.e., module interface framework, SP or UBR) to control cash dispensing in response to XFS layer communications originating from the cash dispensing TEC or ODS components device.

In another exemplary embodiment, the security manager may perform other consistency checks on the XFS information received by the device driver layer. For example, the security manager may verify that the requested amount of cash to be dispensed by the XFS layer in communication with the cash dispenser SP corresponds to the amount of cash to be dispensed by the application layer components directed by the security manager.

In this described exemplary embodiment, communications between components of security manager 1602 and application layer 1614 may be encrypted and/or digitally signed or cryptographically authenticated to prevent fraudulent applications from impersonating components such as TEC or ODS Application layer components. In this described exemplary embodiment, the hardware device may only be operable to respond to information through the XFS layer when the security manager has verified that XFS communications are being sent from authorized application layer components. Thus, if a fraudulent application wants a hardware device, such as a cash dispenser, to be operable by communicating with the XFS layer, the security manager is operable to prevent the device driver layer from operating the hardware device.

In this described exemplary embodiment, the security manager can also break communication with the XFS layer. For example, when two or more applications attempt to communicate with the same hardware device through the XFS layer, the example security manager may be operable to selectively control the order and timing of the communications. For example, components of the XFS layer may be operable to wait for authorization from the security manager before sending information to the XFS layer. When the security manager receives multiple authorization requests for the same hardware device and/or function information of the hardware device, the XFS layer can send a message through the XFS layer to start authorizing the first one of the application layer components. When the security manager receives confirmation from the device driver that the first XFS message has been received and/or completed, the security manager can then authorize the second application layer component to send the message to the hardware device through the XFS layer.

The order of information from the application layer components to the XFS layer may be based on the order in which the security manager receives requests from the application layer components. In other exemplary embodiments, the order may be based on other criteria. For example, in an exemplary embodiment, a security manager may cause application layer components to exclusively control or lock down functional communications with specific hardware devices and/or hardware devices. Such a lock can be maintained until the application layer component sends a message to the security manager to release the lock. During locking, the security manager may only authorize the application layer component that created the lock to issue messages via the XFS layer for locking the hardware device and/or the functionality of the hardware device.

In this described exemplary embodiment, each of the application layer components, device driver layer components, and security manager may have associated digital certificates, public keys, private keys, or other Encrypted information for communication between. Communications between each application layer component and the security manager, or between each device driver component and the security manager, can be digitally signed using a key associated with the sending component. Exemplary embodiments of the security manager may be operable to verify the digital signature using a public key associated with the application layer or device driver layer component sending the information. Additionally, to prevent possible man-in-the-middle attacks, exemplary embodiments of the application layer component, device driver layer component, and security manager may be operable to implement a handshake protocol that communicates encrypted encryption between the security manager and the application layer or device driver. Information used to establish a secure communication channel or session between components. Examples of methods of authorizing communications between software and/or hardware components of an ATM (which may be used in this described exemplary embodiment) include U.S. Patent Application No. 10/620,966, filed July 15, 2003, and U.S. Patent Application No. 4, 2002. The authorization method disclosed in US patent application Ser. No. 10/126,728, filed on 19 March, the entire contents of which are hereby incorporated by reference.

In a further exemplary embodiment, the application layer components may also be operable to authorize each other prior to responding to other components of the application layer. For example, the ODS layer component may authorize communications from the TEC component or other application layer components before communicating with the XFS layer in response to received information. In this described exemplary embodiment, the application layer may be operable to solely authorize communications received from other application layer components. In an alternative exemplary embodiment, the application layer component may be operable to use a security manager to authorize communications. In this described exemplary embodiment, the security manager may be operable to authorize communications on behalf of the application layer components before the application layer components act on the communications. Additionally, in an alternative exemplary embodiment, all communications between application layer objects may pass through the security manager. The security manager may then be operable to authorize each communication before forwarding the information to its intended receiving application layer component.

Computer software instructions for operating automated banking machines, such as ATMs, and connected computers may be loaded into the respective computers from a computer readable medium or articles of various types. Such computer software may be included on and loaded from one or more items such as a magnetic disk, CD, or DVD. Such software may also be included on an item such as a hard drive, tape, memory device, USB drive, or portable computing device. Other articles including data representing instructions for operating the computer in the manner described herein are also suitable for use in effecting the operation of the automated banking machine and system according to the exemplary embodiments.

Exemplary embodiments of the automated trading machines and systems described herein have been described with reference to specific software components and features. Other embodiments of the invention may include other or different software components that provide similar functionality.

Thus, the features and characteristics of the previously described embodiments achieve the intended purpose, obviate difficulties, solve problems and achieve one or more of the foregoing objectives encountered in the use of previous devices and systems.

Some of the terms previously described are used for brevity, clarity and understanding, however, since these terms are used for description only and are intended to be broadly construed, no unnecessary limitations can be implied from the present invention. In addition, the descriptions and illustrations herein are examples only, and the present invention is not limited to what is shown and described herein.

In the following claims, any feature described as a means for performing a function should be understood to include any means suitable for performing that function, and is not intended to be limited to the particular apparatus shown in the preceding description or its mere equivalent of .

Having described the characteristic of the present invention, inventive point and principle, construction and the mode of operating the present invention, and the advantage and beneficial effect obtained; Propose new and useful structure, device, element, configuration in the appended claims , parts, combinations, systems, equipment, operations, methods, processes, and relationships.

Claims (91)

1. A method comprising: (a) operably connecting the removable computer-readable medium to a medium reading and writing device in an automated banking machine that includes a cash dispenser and at least one computer; (b) operating said at least one computer in response to instructions included on said medium to gather data associated with said automated banking machine; (c) A mark corresponding to the data is written on the medium by the operation of the read/write means. 2. The method of claim 1, further comprising: (d) after (c), operatively disconnecting said medium from said read-write device; (e) following (d), operatively connecting said medium to an analysis computer separate from said automated banking machine; (f) analyzing at least a portion of said data by operating said analysis computer. 3. The method of claim 1, wherein in (b), the collected data includes data associated with a configurable characteristic of the automated banking machine. 4. The method of claim 1, wherein in (b), the collected data includes data associated with at least one transaction function device in the automated banking machine. 5. The method of claim 4, wherein in (b), the data associated with the at least one transaction function device includes data corresponding to at least one operational characteristic of the at least one device. 6. The method of claim 5, wherein in (b), the data corresponding to the at least one operational characteristic relates to a plurality of previous operations of the at least one device. 7. The method of claim 4, wherein in (b), the data is associated with the cash dispenser. 8. The method of claim 7, wherein, in (b), the data is stored in a device-inherent data storage to which the cash dispenser is supportively connected, and from the device-inherent data storage The data collected in the. 9. The method of claim 1, wherein the automated banking machine includes at least one visual output device, and the method further comprises: (d) providing at least one output representative of the data collection via the at least one visual output device during at least a portion of (b). 10. The method of claim 9, wherein in (d), the at least one output represents the process of gathering the data in (b). 11. The method of claim 1, further comprising: (d) protecting data by operating said at least one computer, wherein said marking written in (c) includes the protected data. 12. The method of claim 11, wherein (d) includes encrypting data, and wherein (c) includes writing a marker corresponding to the encrypted data. 13. The method of claim 11, wherein (d) includes cryptographically protecting the data, and wherein (c) includes writing a flag corresponding to the cryptographically protected data. 14. The method according to claim 1, wherein the medium read-write device comprises a drive, and the method further comprises: (d) After (c), ejecting the computer readable medium from the drive. 15. The method of claim 14 , wherein (d) includes: operating the at least one computer in response to instructions included on the medium to cause the drive to remove the medium from the drive pops up. 16. The method of claim 1, wherein (b) comprises: using the at least one computer to create at least one temporary file, wherein at least a portion of the collected data is stored in the temporary file middle. 17. The method of claim 16, further comprising: (d) After (c), deleting the at least one temporary file. 18. The method of claim 17, wherein in (d), the at least one temporary file is deleted in response to instructions included on the medium. 19. The method of claim 1 , wherein (b) comprises: during said operations of said computer, spawning at least one processing thread, wherein said at least one computer is responsive to processing by said at least one The computer executes the thread to collect data. 20. The method of claim 19, further comprising: (d) terminating the at least one processing thread after (c). 21. The method of claim 20, wherein in (d), the terminating of the processing thread is performed in response to the instruction included on the medium. 22. The method of claim 2, wherein (f) includes analyzing at least a portion of the data to identify errors in settings of configurable features of the automated banking machine. 23. The method of claim 2, wherein (f) includes analyzing at least a portion of the data to identify a malfunction of at least one device in the automated banking machine. 24. The method of claim 2, wherein (f) includes analyzing at least a portion of the data to predict at least one future need for maintenance of the automated banking machine. 25. The method of claim 2, further comprising: (g) providing at least one output corresponding to at least one result of said analysis performed in (f) via at least one output device operatively connected to said analysis computer. 26. The method of claim 25, further comprising: (h) executing at least one maintenance procedure on the automated banking machine in response to the at least one output provided in (g). 27. The method of claim 2, wherein (b) comprises: in response to the instructions on the medium, creating a processing thread in the at least one computer, and by operation of the at least one computer to create at least one temporary file, and wherein, in (b), the collected data includes data associated with configurable features of the automated banking machine and operations of the at least one transaction function device associated data, and wherein said collected data is stored in said at least one temporary file; and wherein (f) includes: analyzing at least a portion of said data to identify errors in a configurable feature of said automated banking machine, and analyzing at least a portion of said data to identify errors in the operation of said automated banking machine failure, and analyzing at least a portion of said data to predict at least one future need for maintenance of said automated banking machine; and further include: (g) providing at least one visual output through at least one visual output device of said automated banking machine during at least a portion of (b) to indicate collection of data; (h) protecting data by operation of said at least one computer, wherein the marking written in (c) includes the protected data; (i) wherein said read-write device comprises a drive, and after (c) and before (d), said at least one computer is operated in response to said instructions contained on said medium such that said the media is ejected from said drive; (j) deleting said at least one temporary file by operating said at least one computer in response to instructions included on said medium; (k) terminating said at least one processing thread in response to instructions included on said medium; (l) after (f), providing at least one output corresponding to at least one result of said analysis in (f) via at least one output device operatively connected to said analysis computer; (m) implementing at least one maintenance procedure on said automated banking machine in response to said at least one output provided in (l). 28. A method comprising: (a) operatively coupling a computer-readable medium having indicia corresponding to data associated with said automated banking machine including a cash dispenser, to an analysis computer separate from the automated banking machine; (b) analyzing at least a portion of the data by operating the analysis computer to determine at least one status associated with the automated banking machine. 29. The method of claim 28, further comprising: (c) providing at least one output via at least one output device operatively connected to said analysis computer, wherein said at least one output corresponds to at least one state determined in (b). 30. The method of claim 29, further comprising: (d) implementing at least one maintenance action on said automated banking machine in response to said at least one output in (c). 31. The method of claim 29, wherein in (b), said analyzing includes analyzing at least a portion of said data to identify errors in setting a configurable feature of said automated banking machine. 32. The method of claim 29, wherein in (b), said analyzing includes analyzing at least a portion of said data to identify a malfunction of a device in said automated banking machine. 33. The method of claim 29, wherein in (b), said analyzing includes analyzing at least a portion of said data to predict at least one future need for maintenance of said automated banking machine. 34. The method of claim 29, wherein in (a), the medium comprises a portable medium, and wherein the analysis computer is located remotely from the automated banking machine. 35. The method according to claim 34, before (a), further comprising: (d) operatively connecting said computer readable medium to a read/write device in said automated banking machine; (e) operating at least one computer in said automated banking machine to collect said data associated with said automated banking machine; (f) writing the mark corresponding to the data collected in (e) to the medium by operating the reading and writing means. 36. The method of claim 35, wherein in (e), the at least one computer in the automated banking machine collects the data in response to instructions included on the medium. 37. The method of claim 36, wherein in (e), the data collected includes data associated with operation of the cash dispenser. 38. A device comprising: An automated banking machine comprising: a plurality of transaction function devices, at least one of which includes a cash dispenser; at least one computer operatively connected to a plurality of said transaction function devices; and said at least one at least one data storage device operatively connected to each computer; Wherein said at least one data store includes data associated with said automated banking machine, wherein said data includes at least one selected from the group consisting of: at least one configurable setting of said automated banking machine; at least one operational characteristic of at least one of said transaction function devices during execution of a plurality of operations; and predictive maintenance of at least one future required data of said at least one transaction function device; Wherein said at least one computer is operable to cause said data to be collected and to output an indicia corresponding to said data in a machine readable form from said automated banking machine. 39. The device of claim 38, further comprising: A computer media writing device operatively connected to said at least one computer, wherein said at least one computer is operable to record said mark by operating said media writing device. 40. The apparatus of claim 39, further comprising: A removable computer medium operably releasably engageable with said medium writing means, wherein said at least one computer is operable to cause said indicia to be recorded on said removable computer readable medium. 41. The device of claim 38, further comprising: a read-write device operably connected to said at least one computer, and a removable computer-readable medium operatively connected to said read-write device, and wherein said removable medium includes computer-executable instructions, and Wherein said at least one computer is operable to collect said data in response to executing said instructions. 42. The apparatus of claim 41, wherein the instructions are operable to cause the at least one computer to record the indicia on the removable medium. 43. The apparatus of claim 42, wherein the instructions are operable to cause at least one temporary file to be created in the at least one data store, and to cause the collected data to be stored in the at least one temporary file. 44. The apparatus of claim 43, wherein the instructions are further operable to cause the at least one computer to cause the at least one temporary file to be deleted after the flag is output. 45. The apparatus of claim 44, wherein the instructions are operable to cause at least one processing thread to be created in the at least one computer, and wherein the at least one processing thread is operable to cause the at least A temporary file is created. 46. The apparatus of claim 45, wherein the instructions are operable to cause the at least one computer to delete the temporary file and terminate the at least one processing thread. 47. The apparatus of claim 46, wherein the automated banking machine further comprises a visual output device, and wherein the instructions are operable to cause the visual output device to provide at least one output indicative of gathering the data. 48. The apparatus of claim 47, wherein the at least one output is indicative of a process of gathering the data. 49. The apparatus of claim 47, wherein the instructions are operable to cause the at least one computer to protect the data, wherein the indicia corresponds to the protected data. 50. The device of claim 49, wherein the indicia comprises cryptographically protected data. 51. The device of claim 49, wherein the token comprises encrypted data. 52. The apparatus of claim 49, wherein the read-write device includes a drive, and wherein the instructions are operable to cause the at least one computer to cause the removable computer-readable medium to read from the drive pops up. 53. The apparatus of claim 52, further comprising an analysis computer separate from said at least one computer in said automated banking machine, wherein said analysis computer is operatively connected to at least one analysis medium reading device , and wherein the analysis computer is operable to cause the analysis medium reading device to read the indicia on the removable computer readable medium and analyze the data corresponding to the indicia. 54. The apparatus of claim 53, further comprising at least one analysis output device operatively connected to said analysis computer, wherein said analysis computer is operable to generate at least one result by analyzing said data, And wherein the analysis computer is operable to cause a result indicia corresponding to the at least one result to be output via the analysis output device. 55. The apparatus of claim 53, wherein the analyzing computer is operable to generate at least one result corresponding to an error in setting a configurable feature of the automated banking machine. 56. The apparatus of claim 53, wherein the analysis computer is operable to generate at least one result corresponding to a failure during operation of at least one transaction function device. 57. The apparatus of claim 53, wherein the analysis computer is operable to generate at least one result predicting a future need for maintenance of the automated banking machine. 58. The apparatus of claim 38, wherein said data predicts a future need to maintain at least one transaction function device in said automated banking machine, and further comprises a at least one analytical computer, wherein said at least one analytical computer is operable in response to said indicia to produce at least one result predicting the future need for maintenance of at least one transaction function device in said automated banking machine, and by said The at least one analysis output device is used to output a result flag corresponding to the at least one result. 59. The apparatus of claim 38, wherein said data represents a configurable feature in said automated banking machine, and further comprising at least one analysis computer operatively connected to at least one analysis output device, wherein: said at least one analysis computer is operative in response to said indicia to generate at least one result corresponding to at least one error in a setting of a configurable feature of said automated banking machine, and to output via said at least one analysis output device A result flag corresponding to the at least one result. 60. The apparatus of claim 38, wherein said data is representative of an operational characteristic of at least one of said transaction function means, and further comprising at least one analysis computer operatively connected to at least one analysis output means, wherein: Said at least one analysis computer is operative in response to said indicia to produce at least one result corresponding to a failure in at least one of said transaction function means, and output by said at least one analysis output means corresponding to said at least one A result flag for a result. 61. The apparatus of claim 60, wherein said at least one transaction function device includes said cash dispenser, and wherein said at least one result indicates a malfunction with respect to said cash dispenser. 62. The apparatus of claim 61 , wherein the data representative of operational characteristics is stored in a data store supported in connection with the cash dispenser. 63. The apparatus of claim 40, further comprising at least one analytical computer separate from said at least one computer in said automated banking machine, wherein said analytical computer is operable with at least one analytical media reading device connected, and wherein the analysis computer is operable to cause the analysis medium reading device to read the indicia on the removable computer readable medium and analyze the data corresponding to the indicia to At least one selected from the group consisting of: at least one error in setting at least one configurable feature of the automated banking machine, at least one failure of at least one transaction function device, and future maintenance of at least one transaction function device At least one forecast is required. 64. The apparatus of claim 41 , further comprising a visual output device on said automated banking machine and operatively connected to said at least one computer, and wherein, in response to said instruction, said at least one A computer is operable to cause said visual output device to provide an output indicating that said data was collected, and to cause said indicia to be recorded on said removable medium by operation of said read/write device. 65. A method comprising: (a) operating at least one processor in a cash-dispensing automated banking machine to gather data about operating parameters associated with a plurality of transaction function devices in said banking machine, at least one transaction function device including a cash dispenser; (b) operating at least one computer remote from said banking machine to provide at least one output comprising a prediction of at least one future maintenance action to be performed on said banking machine. 66. The method of claim 65, wherein (a) includes collecting data corresponding to an average velocity associated with at least one transaction function device. 67. The method of claim 66, wherein (a) includes collecting data corresponding to power loss associated with at least one transaction function device. 68. The method of claim 67, wherein (a) includes collecting data corresponding to a plurality of cycles performed by at least one transaction function device. 69. The method of claim 68, wherein (a) includes collecting data corresponding to a plurality of currency instruments transferred by a transaction function of the banking machine. 70. The method of claim 69, wherein (a) includes collecting data corresponding to a plurality of double bills picked up by a money dispenser of the banking machine. 71. The method of claim 70, wherein (a) includes collecting data corresponding to at least one calibration value associated with a calibration sensor. 72. The method of claim 71, wherein (a) includes collecting data from a plurality of data stores, each data store associated with a respective one of the plurality of transaction function devices. 73. The method of claim 72, further comprising: (c) Before (b), writing a mark corresponding to said data collected in (a) on a removable medium by operating a writing means in said banking machine. 74. The method of claim 73, further comprising: (d) prior to (a), operatively connecting the removable medium to a read-write device in the banking machine, wherein the removable medium includes a plurality of instructions, and wherein in (a) the data is collected in response to the instruction, and wherein in (c) the mark is written to the removable medium by operating the read/write device. 75. The method of claim 74, further comprising: after (d) and before (b), operably connecting said removable medium to said at least one computer remote from said automated banking machine, Wherein, in (b), at least one output is generated in response to said marking on said removable medium. 76. The method of claim 72, further comprising: (d) in (b), transmitting said data collected in (a) to said at least one computer. 77. The method of claim 76, wherein in (d), the data is transmitted over an online connection. 78. The method of claim 76, wherein in (d), the data is transferred via a portable medium moved between the banking machine and the at least one computer. 79. The method of claim 76, wherein in (b), the at least one computer generates at least one output predicting a future need to replace at least one sensor in the banking machine. 80. The method of claim 79, wherein in (b), the at least one computer provides at least one output predicting a future need to replace at least one electric motor in the banking machine. 81. The method of claim 80, further comprising: The at least one computer is operated to provide at least one output indicative of at least one portion required to perform the at least one repair action. 82. The method of claim 81 , further comprising: prior to (a), providing at least one input to the banking machine, wherein data is collected in (a) in response to the at least one input. 83. The method of claim 82, wherein in (b), the at least one output comprises at least one of an automated speech output, a web interface output, and an email output. 84. The method of claim 65, wherein in (b), said at least one repair action comprises replacing at least one sensor in said banking machine. 85. The method of claim 65, wherein in (b), said at least one repair action comprises replacing said at least one electric motor in said banking machine. 86. The method of claim 85, further comprising: Operating said at least one computer to provide at least one output corresponding to a portion for performing said at least one repair action predicted in (b). 87. The method of claim 65, further comprising: sending the data collected in (a) on the portable medium to at least one computer operated in (b). 88. The method of claim 65, further comprising: The data collected in (a) is sent to the at least one computer operating in (b) via online communication. 89. The method of claim 65, wherein in (a), the data collected corresponds to the speed of at least one device in the banking machine. 90. The method of claim 65, wherein in (a), the data collected corresponds to power consumption of at least one device in the banking machine. 91. The method of claim 65, wherein in (b), the at least one output comprises at least one of a printout, an automated voice output, a web interface output, and an email output.

Images