EP1301845A2 - Systeme et procede pour machine transactionnelle automatique - Google Patents

Systeme et procede pour machine transactionnelle automatique

Info

Publication number
EP1301845A2
EP1301845A2 EP01941581A EP01941581A EP1301845A2 EP 1301845 A2 EP1301845 A2 EP 1301845A2 EP 01941581 A EP01941581 A EP 01941581A EP 01941581 A EP01941581 A EP 01941581A EP 1301845 A2 EP1301845 A2 EP 1301845A2
Authority
EP
European Patent Office
Prior art keywords
component
ods
transaction
xfs
transaction function
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP01941581A
Other languages
German (de)
English (en)
Other versions
EP1301845A4 (fr
Inventor
Steven Shepley
Joseph Cwikla
Bryan Reed
James Block
Robert Usner
Jay Paul Drummond
Mark D. Smith
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Diebold Nixdorf Inc
Original Assignee
Diebold Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=22768975&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=EP1301845(A2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Diebold Inc filed Critical Diebold Inc
Publication of EP1301845A2 publication Critical patent/EP1301845A2/fr
Publication of EP1301845A4 publication Critical patent/EP1301845A4/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G07F19/201—Accessories of ATMs

Definitions

  • This invention relates to an automated transaction machine architecture. Specifically this invention relates to a new cross-vendor software and hardware platform architecture for automated transaction machines.
  • Automated transaction machines are known in the prior art. Automated transaction machines are used to electronically carry out transfers representative of value. Automated transaction machines include for example, cash dispensers, ticket dispensers, scrip dispensers, gaming machines, Automated Teller Machines (ATMs) and other self service terminals. For purposes of convenience all such automated transaction machines will be referred to herein as ATMs unless otherwise specifically indicated. ATMs may include various types of transaction function devices.
  • ATMs are operated to carry out transactions.
  • Different types of ATMs include different types of devices.
  • the different types of devices enable the ATM to carry out different types of transactions.
  • some types of ATMs include a depository for accepting deposits while other ATMs do not.
  • Some ATMs have a "touch screen" while others have separate displays and input buttons.
  • ATMs can also be fitted with devices such as cash and coin acceptors, statement printers, check validators, bill acceptors, thumb print readers and other types of devices, while other ATMs do not include such devices.
  • 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 statement printer to each of the ATMs for printing a customer's banking statement.
  • FIG. 1 shows a schematic view of the standard WOSA/XFS architecture.
  • ATM 110 may include a WOSA/XFS Manager 112.
  • the WOSA/XFS Manager 112 includes a standardized interface to enable an ATM terminal application 114 to communicate with ATM transaction function devices 116.
  • Each transaction function device 116 includes a corresponding service provider interface (SP) 118.
  • SPs 118 are supplied by the vendors of the
  • ATM devices 116 are specially designed to accept requests from the WOSA/XFS Manager 112 and pass those requests on to the corresponding device 116.
  • the ATM terminal application 114 will be able to run on any vendor's ATM hardware 120 as long as both the ATM terminal application 114 and the vendor's implementation of the SPs 118 adhere to the
  • J/XFS Java / extensions for Financial Services
  • J/XFS is a Java® based architecture that may be implemented on any hardware/software platform that supports a Java® Virtual Machine (JVM).
  • JVM Java® Virtual Machine
  • a J/XFS enabled ATM 210 may include a J/XFS Kernel.
  • the J/XFS Kernel is similar in functionality to the previously described WOSA/XFS Manager 112, however the J/XFS Kernel runs in a JVM 224.
  • the J/XFS Kernel is operative responsive to commands from an ATM terminal application 214 to have a device service layer 220 control the operation of ATM devices 216.
  • the device service layer 220 includes vendor provided device services 218 that correspond to the vendor's hardware devices 216.
  • the ATM terminal application 214 will theoretically be able to run on any vendor's ATM hardware as long as both the ATM terminal application 214 and the vendor's implementation of the device services 218 adhere to the J/XFS specifications.
  • the WOSA XFS standard provides a number of different methods for having a card reader SP interface with a card reader for returning information read from a card. These methods include a first method of passing individually selected information and a second method of passing all the card information in a single form. Although it would seem that an application could use either method to retrieve card information from any vendor's card reader, in reality one vendor's card reader SP may only support the first method, whereas a second vendor's card reader SP may only support the second method. These types of incompatibilities or differences in interpretation of the WOSA/XFS standard undermine the intended goal of cross-vendor compatibility between ATM applications and ATM hardware.
  • J/XFS architecture is just being developed it shares the similar WOSA/XFS architecture limitation of using device services that are vendor provided. As a result different vendor interpretations of the J/XFS specification have the potential of forcing developers to write modified versions of their ATM terminal applications for each vendor's ATM platform.
  • each of the previously described XFS architectures defines a standard for the lowest common denominator of ATM hardware features.
  • the XFS standards cannot include interfaces to unique features associated with a vendor's particular implementation of a transaction function device.
  • One example of unique features that are not implemented in the XFS interfaces includes access to low level diagnostic testing of individual hardware components of a device. Such control over low level hardware functionality can be very useful when troubleshooting problems with a specific component such as a motor or sensor.
  • the XFS standards have not attempted to implement methods for testing low level vendor specific hardware. Consequently there further exists a need for an XFS enabled ATM that offers low level diagnostic testing of ATM hardware.
  • an ATM that comprises a computer and a plurality of transaction function devices in operative connection with the computer.
  • the ATM further includes at least one XFS layer such as the WOSA/XFS Manager or the J/XFS kernel, hi addition, the ATM includes a device driver layer that includes vendor provided device drivers such as the WOSA/XFS service providers or the J/XFS device services.
  • the device drivers generally correspond to each of the transaction function devices and are responsive to commands from the XFS layer to control the operation of the transaction function devices.
  • the ATM further includes at least one terminal application and an Open Device Services (ODS) layer.
  • ODS layer includes a plurality of ODS components that generally correspond to the device drivers and/or transaction function devices.
  • An ODS component is operative responsive to the terminal application to control at least one transaction function device through communication with the XFS and device driver layers.
  • the ODS component layer is adapted to provide the terminal application with a consistent interface for communicating with vendor provided device drivers which may have inconsistent implementations for interfacing with the particular XFS layer.
  • the ODS layer is operatively programmed to communicate with device drivers from different vendors such that each of the corresponding transaction function devices operate the same.
  • the ODS layer is operative to include ODS components that are exchangeable to correspond to different vendor implementations of a device driver for a particular type of transaction function device. For example if the ATM includes a card reader and a corresponding device driver from vendor A, the ODS layer is operative to include a first
  • the ODS layer is operative to enable the first ODS component to be exchanged with a second ODS component that is compatible with Vendor B's device driver and card reader.
  • Both the first and second ODS components include identical interfaces which are accessed by the terminal application in the same manner to have either vendor's A or Vendor B's card reader perform the same card reader functions.
  • the terminal application is operative to communicate with the ODS layer to have any vendor's hardware perform the same functions.
  • the ODS layer is further operative to communicate with more than one XFS layer.
  • an ATM may include both a WOSA/XFS Manager and a J/XFS Kernel with different sets of devices for each XFS layer.
  • J/XFS is a Java® based architecture that may be implemented on any hardware/software platform that supports a Java® Virtual Machine (JVM). Examples of automated transaction machines that include a Java based architecture are found in U.S. Application Serial No. 09/193,637 which is incorporated herein by reference in its entirety.
  • the terminal application only needs to be programmed to communicate with the ODS layer as previously described.
  • the ODS layer is operative to route the terminal application commands through the correct XFS layer.
  • Those devices that include WOSA/XFS service provider interfaces will have corresponding ODS components that are operative to communicate with the WOSA/XFS Manager.
  • Those devices that include J/XFS device services will have corresponding ODS components that are operative to communicate with the J/XFS Kernel, hi a further alternative embodiment, each ODS component is operative to communicate with either XFS layer depending on ODS configuration parameters which specify which XFS layer each ODS component should use to communicate with devices.
  • the exemplary embodiment further comprises terminal element controls (TECs).
  • TECs are high level programming objects that encapsulate much of the low level functions and structures needed to interact with one or more transaction function devices.
  • TEC objects may be operatively configured in any object package that the terminal application designer prefers. Examples of operative object configurations for TECs include OCXs, Active X objects, COM object, JavaBeans, EJBs or any other object that can be integrated into a terminal application.
  • an interface to a card reader in the previously described XFS architecture includes a complex assortment of methods and structures that must be dealt with just to operate a card reader and to read a card. Integrating this interface into a terminal application can require significant effort.
  • An exemplary card reader TEC object of an embodiment of the invention provides a simplified interface that includes five methods: 1) enable the card reader; 2) read a card; 3) write a card; 4) return a card; and 5) retain a card.
  • Exemplary TEC objects also include configurable parameters or properties such as the amount of time that a card should be presented to a customer before it is retained.
  • the terminal application can be programmed in any language or on any platform that can either directly access the ODS layer or that can incorporate TEC objects.
  • a terminal application can be developed as a stand alone Windows® application, a browser based application, Java® application, or any other type of application that is operative to incorporate TEC Objects.
  • TEC objects of the exemplary embodiment are also operative to combine functions that span multiple devices.
  • a card reader TEC may also interact with related hardware such as a light indicator to draw a customer's attention to the card reader.
  • the exemplary card reader TEC may also interact with a beeping device for signaling the customer to remove their card from the card reader.
  • these simple actions would require low level coding to all three XFS interfaces that correspond to the card reader, sensors/indicators and sound device.
  • the TEC objects are operative to interface with the previously described ODS layer.
  • the TEC objects maybe operatively programmed to access the XFS layer directly.
  • exemplary embodiments are operative to enable pre-existing proprietary terminal applications to run on another vendor's hardware.
  • proprietary terminal control software typically includes a plurality of proprietary drivers for controlling a plurality of different transaction function devices.
  • the proprietary terminal applications are typically updated to include new proprietary drivers for controlling the new or updated hardware.
  • the proprietary terminal application software may be updated to indirectly access ATM hardware through the ODS layer rather than through the proprietary drivers. By accessing the ODS layer, proprietary terminal control software is operative to function on any vendor's hardware that is XFS enabled.
  • the device drivers such as the WOSA/XFS service providers or the J/XFS device services are adapted to include a diagnostic interface.
  • the diagnostic interface provides external applications with access to specific low level features of the hardware that corresponds to the device drivers.
  • a cash dispenser device driver may be adapted to include an interface for manipulating individual motors or sensors in the corresponding cash dispenser transaction function device. Such access is provided to applications independently of the
  • a diagnostic application may be operatively programmed to access the diagnostic interfaces of a plurality of different device drivers. Such an exemplary diagnostic application may use the XFS layer to deactivate one or more devices from XFS communication. Once the devices have been taken off-line with respect to the XFS components, the diagnostic application may enable a programmer or service technician to directly access ATM hardware through the corresponding diagnostic interface for trouble shooting, repair and other maintenance purposes.
  • Figure 1 is a schematic view representative of a WOSA/XFS enabled ATM.
  • Figure 2 is a schematic view representative of a J/XFS enabled ATM.
  • Figure 3 is a schematic view representative of an exemplary XFS enabled ATM.
  • Figure 4 is a schematic view representative of an exemplary terminal application that includes an exemplary card reader TEC to interact with exemplary ODS components.
  • the ATM architecture 20 includes an computer 22 that is in operative connection with a plurality of transaction function devices 42.
  • transaction function devices may include for example such devices as a note dispenser, coin dispenser, card reader, printer, key pad, display device, function keys, depositor, cash acceptor or any other hardware device that may be operatively connected to an ATM.
  • the computer 22 includes a software components including terminal application 24 that is operative to control the operation of the transaction function devices 42.
  • the computer 22 further includes an XFS layer 28 that corresponds to a multi- vendor supported interface for ATM devices such as the WOSA/XFS Manager or the J/XFS Kernel, hi addition, the computer 22 further includes a device driver layer 30 that includes a plurality of device driver components 38 that correspond to the XFS layer. For example if the XFS layer corresponds to the WOSA/XFS Manager, the device driver components 38 correspond to the WOSA/XFS service provider interfaces. If the XFS layer corresponds to the J/XFS Kernel, the device driver components
  • a device driver 38 For each transaction function device 42, a device driver 38 must be installed in the computer that is operative to enable commands passed through the XFS layer 28 to control the operation of the transaction function devices 42.
  • the device drivers 38 are manually installed from a portable physical media such as a disk or CD supplied by the manufacture of the device.
  • the device drivers are operatively downloaded from a data store of device drivers that is in operative connection with the computer.
  • the device drivers are retrieved by the computer 22 from the transaction function devices 42 themselves using a service configuration protocol such as Sun Microsystems JINTTM or Microsoft Universal Plug and PlayTM.
  • Each of the device drivers 38 are operative responsive to the XFS layer 28 to have at least one transaction function device 42 perform a function.
  • a card reader device driver is operative responsive to a read card request from the XFS layer 28 to have its corresponding card reader device physically read information from a card and return the information through the XFS layer.
  • Another device driver such as a note dispenser device driver is operative responsive to a dispense request from the XFS layer 28 to have its corresponding cash dispenser dispense an amount of notes.
  • the terminal application 24 is operative to control transaction function devices 42 through communication with the XFS layer 28.
  • the exemplary embodiment includes an ODS layer 26 operative in the computer
  • the ODS layer 26 is operative responsive to the terminal application 24 to control the functionality of transaction function devices 42 through communication with the XFS and device driver layers 28 and 30.
  • the ODS layer 26 includes a plurality of ODS components 36 that generally correspond to the device drivers 38 and/or the transaction function devices 42.
  • the exemplary embodiment of the present invention may include a card reader ODS component that corresponds to a card reader device driver for a card reader.
  • An exemplary embodiment of the present invention may also include a note dispenser ODS component that corresponds to a note dispenser device driver for a note dispenser.
  • a single ODS component may be used when either of the drivers are installed in the ATM.
  • vendor specific ODS components maybe operatively programmed for each of the vendor specific device drivers.
  • a vendor specific ODS component may then be installed in the ODS layer responsive to whichever vendor specific device driver is installed in the ATM.
  • the vendor specific ODS component is operative to communicate through the XFS layer in a manner that is appropriate for the particular implementation of the vendor specific driver.
  • each vender specific ODS component may communicate with the XFS layer in a different manner, all of the vendor specific ODS components for a particular type of device share a common interface for access by external applications such as the terminal application 24.
  • the ODS layer 26 is thus operative to isolate the inconsistencies in communication between different device drivers, and to present the terminal application 24, or any other application, with a common set of methods, properties and events for communicating with transaction function devices from different vendors.
  • the present exemplary form of the invention encompasses a testing process that is operative to identify unique characteristics and/or inconsistencies in a vendor's implementation of a device driver and to operatively adapt ODS components to include those features that are necessary to properly and consistently communicate with the device driver through the XFS layer.
  • the testing process includes the configuration of the particular vendor's hardware device and corresponding device driver on an XFS enabled test platform.
  • the test platform typically includes a computer system with an XFS layer and an ODS component that corresponds to the particular type of the vendor's device. For example if the particular device being tested is a note dispenser, an ODS component that corresponds to an XFS device driver for a note dispenser is installed in the test platform.
  • the test platform further includes a testing application.
  • the testing application is operative to interface with the ODS component and issue a plurality of commands through the ODS component to control the operation of the vendor's 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 work properly with the ODS component.
  • the testing application when testing a card reader the testing application enables a user to issue a command to the ODS component to have the device read a card.
  • the testing application is further operative to output to the user the results of the operation. If the operation appears to work correctly, the testing application may display the contents of the information read from the card. A user may then verify that the contents are correct. If the operation failed, the user may evaluate the error messages that are generated.
  • the testing application is further operative to report what events have been triggered as a result of the operation. addition to monitoring the testing application, the user may also monitor the actual device to determine if the operation produces the correct function.
  • the testing application may include an operation to dispense a certain amount of cash or number of notes through cor munication with a cash dispenser ODS.
  • the ODS component may be operatively modified to compensate for the idiosyncrasies associated with the vendor's implementation of the device driver.
  • the modified ODS component may then be further tested on the testing platform to either uncover further inconsistencies or to certify that the ODS component works properly.
  • an ODS component Once an ODS component has been certified, it may be installed in any ATM that includes the tested vendor's device, device driver and corresponding XFS layer to enable a terminal application to properly control the device's functionality.
  • the terminal application 24 may be based on any programming architecture that is operative to communicate with the ODS layer 26.
  • the terminal application may be a stand-alone, Windows®-based application.
  • the terminal application may include a browser and a plurality of web page documents.
  • the terminal application may be a Java® application that is operative in a Java Virtual Machine (JVM).
  • JVM Java Virtual Machine
  • the ODS layer may be based on any piOgramming architecture that is operative to communicate with the XFS layer 28. For example if the XFS layer corresponds to a J/XFS Kernel running in a JVM 48 of the computer 22, the ODS components may be constructed as Java Beans that are operative in the JVM. If the XFS layer corresponds to the
  • the ODS components may be constructed as a plurality of Windows® based DLLs. If portions of the XFS layer and/or terminal application are both Windows® based and Java® based, the ODS layer may include components operative in the JVM and components operative as DLLs. In other embodiments, the ODS layer and terminal application may be configured as other types of applets, modules or libraries which are appropriate for the operating system architecture and the XFS layer.
  • the exemplary embodiment of the present invention comprises the integration of transaction element components (TECs) 34 with the terminal application 24.
  • TECs are objects or classes such as ActiveXs or Java Beans that encapsulate the complex operation of one or more transaction function devices 42 into a package of streamlined methods, properties and events.
  • the TEC objects include the necessary functionality to communicate with the ODS layer.
  • an entire terminal application can be constructed from TEC objects.
  • FIG. 4 shows an exemplary terminal application 50.
  • the terminal application includes a card reader TEC 52.
  • the application 50 is operative to invoke methods 54 of the card reader TEC 52 such as enable card reader, read a card, write a card, return a card and retain a card.
  • the application 50 is further operative to set properties 56 of the card reader TEC 52 such as the time out value before a card is returned by the card reader.
  • the application is further operative to monitor one or more events 58 that are triggered through the card reader TEC.
  • the exemplary card reader TEC 52 is operative to communicate with three different hardware devices including a card reader device 60, a lead through indicator device 61 and a beeper device 62.
  • the exemplary card reader TEC 52 interfaces with these devices through communication with three corresponding ODS components including a card reader ODS 63, an indicator ODS 64 and a beeper ODS 65.
  • the card reader ODS 63 Through communication with the card reader ODS 63, the card reader
  • TEC 52 is operative to have the card reader device 60 perform a plurality of functions such as enabling the card reader, reading a card and returning the card to a customer.
  • the card reader ODS communicates with the card reader device through the XFS layer 68 and the card reader driver 67.
  • the exemplary card reader TEC 52 is further operative to automatically activate a lead thru indicator light 61 to draw a " customer's attention to the card reader 60. This is performed by communicating with a sensors and indicators device driver 66 through interaction with the indicators ODS 64.
  • the exemplary card reader when a beeping sound is desired to signal the customer to remove their card, the exemplary card reader
  • TEC 52 interacts with the beeper ODS 65 to have the sensors and indicators driver 66 activate the beeper device 62.
  • the exemplary TECs of the present invention are operative to combine device interaction in a logical manner by communicating with more than one ODS component and corresponding devices in response to various methods of the TEC being invoked.
  • the exemplary embodiment of the present invention encompasses adapting pre-existing and proprietary terminal control software of one vendor to run on another vendor's ATM hardware.
  • Such proprietary terminal control software typically communicates with a plurality of proprietary device drivers directly without accessing a middle layer interface such as the previously described XFS layers. Consequently proprietary terminal control software has previously been limited to running only on a specific vendor's hardware platform. However, the exemplary embodiment of the present invention is further operative to enable such proprietary software to properly control another vendor's transaction function devices when installed on another vendor's ATM platform. This is achieved by adapting the proprietary software to communicate with ODS components rather than proprietary device drivers. Once the proprietary terminal control software has been so adapted, the software is operative to run on another vendor's ATM platform that includes an XFS layer and corresponding XFS compatible device drivers.
  • the exemplary XFS compatible device drivers 38 of an exemplary form of the present invention may further include diagnostic interfaces 40 in addition to their interfaces with the XFS layer 28.
  • the diagnostic interfaces 40 include additional low level hardware control functions that may be accessed by external applications.
  • the low level functions for example may access specific motors, sensors and other components in the corresponding transaction function devices 42.
  • a diagnostic application 44 to access these low level functions of the device drivers 38 directly, individual mechanical and electronic functions specific to the device can be tested, analyzed and possibly corrected.
  • the diagnostic interfaces 40 of the device drivers 38 may include an authentication system which is operative to validate that the application attempting to access the low level functions of the device is authorized to do so.
  • the diagnostic interface 40 is operative to detect that a valid hardware device such as a dongle is in operative connection with the ATM before an external application is granted access to the transaction function device 42 through the diagnostic interface
  • the diagnostic interface 40 is operative to detect whether a valid license key is present.
  • a license key for example may be located on a removable media in operative connection with the ATM such as a floppy disk, CD, magnetic stripe card, smart card, or any other portable medium that the diagnostic interface is operative to access through the machine.
  • the license key may also be associated with the specific application such as the diagnostic application 44 that is operatively programmed to access the diagnostic interfaces of device drivers 38. Communications from the diagnostic application may be required to include a valid license key before the diagnostic interface enables the diagnostic application to access the transaction function device.
  • the diagnostic interfaces 40 may include a secret password or digital certificate which may be used by the diagnostic interface to determine if an application is allowed access to functions of a corresponding transaction function device.
  • a diagnostic interface of a device driver may require communications from a diagnostic application to be digitally signed.
  • the diagnostic interface may then authenticate the digital signature associated with the communication using one or more digital certificates and/or public keys stored in operative connection with the diagnostic interface.
  • the diagnostic interface is operative to enable the diagnostic application to access the transaction function device through the diagnostic interface.
  • the diagnostic application is denied access to the transaction function device by the diagnostic interface.
  • the diagnostic application may be required to send a valid digital certificate to the diagnostic interface prior to being granted access to the transaction function device.
  • the digital certificate may be validated by the diagnostic interface using a trusted public key of a certificate authority that issued the digital certificate.
  • the digital certificate may also be evaluated by the diagnostic interface to determine if it has expired.
  • the exemplary embodiment of the diagnostic interface may be operatively programmed to return a message to the calling application which indicates that the digital certificate is not valid and access to the transaction function device is denied.
  • other software and/or hardware encryption and/or authentication systems may be combined with the diagnostic interfaces of the device drivers to enable the selective validation of users and/or applications attempting to access transaction function devices through communication with the diagnostic interfaces of device drivers
  • the exemplary embodiment of the present invention further comprises a terminal Manager 46.
  • the terminal Manager 46 is a software application that is operative to configure and manage the ATM through interaction with the ODS layer.
  • the ODS layer 26 is operative to enable any application that can access ODS components to be operative on a plurality of different XFS enabled ATM hardware platforms.
  • the exemplary form of the cross-vendor automated transaction machine architecture of the present invention achieves at least one of the above stated objectives, eliminates difficulties encountered in the use of prior devices and systems, solves problems and attains the desirable results described herein.
  • certain terms have been used for brevity, clarity and understanding, however no unnecessary limitations are to be implied therefrom because such terms are used for descriptive purposes and are intended to be broadly construed.
  • the descriptions and illustrations herein are merely examples and the invention is not limited to the exact details shown and described.
  • any feature described as a means for performing a function shall be construed as encompassing any means known to those skilled in the art to be capable of performing the recited function, and shall not be limited to the features and structures shown herein or mere equivalents thereof.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Stored Programmes (AREA)
  • Computer And Data Communications (AREA)

Abstract

La présente invention concerne une machine transactionnelle automatique (20) se distinguant par un logiciel commun à plusieurs vendeurs et une architecture de plate-forme matérielle. La machine comporte un ordinateur (22) et une pluralité d'appareils à fonction transactionnelle (32) fonctionnellement reliés à l'ordinateur. La machine comporte également une pluralité de composants pilotes d'appareil (38) qui correspond généralement à chacun des appareils à fonction transactionnelle. Les pilotes d'appareils fonctionnent en réaction avec les communications provenant d'une couche XFS (28) de façon à commander le fonctionnement des appareils à fonction transactionnelle. La machine comporte également une application terminal (22) et une couche ODS (26). La couche ODS comporte une pluralité de composants ODS (36) qui correspondent généralement aux pilotes d'appareils et/ou aux appareils à fonction transactionnelle. Les composants ODS réagissant à l'application terminal ont pour fonction d'amener les pilotes d'appareils à commander le fonctionnement des appareils à fonction transactionnelle via une communication avec la couche XFS.
EP01941581A 2000-05-25 2001-05-23 Systeme et procede pour machine transactionnelle automatique Ceased EP1301845A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US20704300P 2000-05-25 2000-05-25
US207043P 2000-05-25
PCT/US2001/016775 WO2001090850A2 (fr) 2000-05-25 2001-05-23 Systeme et procede pour machine transactionnelle automatique

Publications (2)

Publication Number Publication Date
EP1301845A2 true EP1301845A2 (fr) 2003-04-16
EP1301845A4 EP1301845A4 (fr) 2009-10-28

Family

ID=22768975

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01941581A Ceased EP1301845A4 (fr) 2000-05-25 2001-05-23 Systeme et procede pour machine transactionnelle automatique

Country Status (10)

Country Link
EP (1) EP1301845A4 (fr)
CN (1) CN1204518C (fr)
AR (1) AR028612A1 (fr)
BR (1) BR0111112A (fr)
CA (1) CA2406257C (fr)
MX (1) MXPA02010682A (fr)
PL (1) PL357552A1 (fr)
RU (1) RU2251730C2 (fr)
WO (1) WO2001090850A2 (fr)
ZA (1) ZA200208343B (fr)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1473631A3 (fr) 2003-05-01 2007-10-10 NCR International, Inc. Objet client à utiliser dans un terminal de libre service
GB0328962D0 (en) * 2003-12-13 2004-01-14 Ncr Int Inc A self-service terminal
CH695124A5 (de) * 2004-12-10 2005-12-15 Wincor Nixdorf Ag Geldautomat und Geldautomatensteuerung.
US7520423B2 (en) * 2005-12-21 2009-04-21 Ncr Corporation Multi-vendor agent for a self-service terminal
FR2899749B1 (fr) * 2006-04-07 2008-07-04 Groupe Ecoles Telecomm Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants.
BRPI1106243B1 (pt) * 2011-09-28 2020-11-24 Diebold, Incorporated COFRE BIPARTIDO PARA USO EM TERMINAL DE AUTOATEN Dl MENTO BANCÁRIO
CN103135966B (zh) * 2011-11-24 2016-08-24 深圳市证通电子股份有限公司 基于xfs标准的sp实现方法及sp架构
CN102622267B (zh) * 2012-03-14 2014-11-12 深圳市紫金支点技术股份有限公司 一种日志采集方法及系统
CN102890844B (zh) * 2012-08-02 2015-08-05 交通银行股份有限公司 一种银行集成化自助设备
RU2672710C2 (ru) * 2017-01-25 2018-11-19 Общество с ограниченной ответственностью "СНС Софт" Система и способ защиты финансовых устройств, использующих стандарт xfs, от несанкционированного доступа
WO2018187993A1 (fr) * 2017-04-12 2018-10-18 深圳怡化电脑股份有限公司 Procédé et système de développement et de débogage de logiciel de service atm, et système de simulation atmp
CN109147230A (zh) * 2018-08-07 2019-01-04 中国建设银行股份有限公司 一种基于wosa的金融自助设备的操作方法及装置
CN112114980B (zh) * 2020-08-31 2024-03-29 深圳市紫金支点技术股份有限公司 支持跨平台业务的中间件实现方法、智能终端、存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999049431A2 (fr) * 1998-03-24 1999-09-30 Korala Associates Limited Procede et dispositif pour la realisation de services transactionnels

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2319100B (en) * 1997-11-15 1998-09-16 Ibm Hardware simulator for a transaction processing system
EP1096448A3 (fr) * 1999-11-01 2004-01-28 Citicorp Development Center, Inc. Méthode et système pour obtenir des services à partir d'un terminal de transactions à libre service

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999049431A2 (fr) * 1998-03-24 1999-09-30 Korala Associates Limited Procede et dispositif pour la realisation de services transactionnels

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"EXTENSIONS FOR FINANCIAL SERVICES (XFS) INTERFACE SPECIFICATION - PART 1: APPLICATION PROGRAMMING INTERFACE (API) - SERVICE PROVIDER INTERFACE (SPI) - PROGRAMMER'S INTERFACE" CEN WORKSHOP AGREEMENT, XX, XX, 1 December 1998 (1998-12-01), pages 1-121, XP001206895 *
See also references of WO0190850A2 *

Also Published As

Publication number Publication date
MXPA02010682A (es) 2003-03-10
CN1430761A (zh) 2003-07-16
CN1204518C (zh) 2005-06-01
ZA200208343B (en) 2003-05-15
BR0111112A (pt) 2003-04-15
CA2406257A1 (fr) 2001-11-29
PL357552A1 (en) 2004-07-26
CA2406257C (fr) 2013-04-09
WO2001090850A2 (fr) 2001-11-29
WO2001090850A3 (fr) 2002-03-21
EP1301845A4 (fr) 2009-10-28
RU2251730C2 (ru) 2005-05-10
AR028612A1 (es) 2003-05-14

Similar Documents

Publication Publication Date Title
US7490762B2 (en) Card activated cash dispensing automated transaction machine system and method
US7891552B2 (en) Cash dispensing automated banking machine diagnostic method
US7721953B1 (en) Cash dispensing automated banking machine diagnostic system
US8245912B2 (en) Automated banking machine that operates responsive to data bearing records
US7367492B2 (en) Cash dispensing automated banking machine diagnostic device
US7661583B2 (en) Cash dispensing automated banking machine diagnostic system and method
US8141773B2 (en) Automated banking machine that operates responsive to data read from data bearing records
US7717331B2 (en) Cash dispensing automated banking machine diagnostic system and method
CA2406257C (fr) Systeme et procede pour machine transactionnelle automatique
US7093750B1 (en) Cash dispensing automated banking machine diagnostic system and method
US7093749B1 (en) Cash dispensing automated banking machine diagnostic system and method

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20021213

AK Designated contracting states

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

RBV Designated contracting states (corrected)

Designated state(s): DE ES FR GB IT

A4 Supplementary search report drawn up and despatched

Effective date: 20090929

17Q First examination report despatched

Effective date: 20100607

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20150325