Registers – Systems controlled by data bearing records – Credit or identification card systems
Reexamination Certificate
2001-08-06
2003-02-18
Le, Thien M. (Department: 2876)
Registers
Systems controlled by data bearing records
Credit or identification card systems
C235S379000, C235S381000, C235S382000, C235S383000, C705S041000, C705S043000, C705S044000
Reexamination Certificate
active
06520410
ABSTRACT:
TECHNICAL FIELD
This invention relates to automated banking machines. Specifically this invention relates to an automated banking machine apparatus and system that is operative to independently and simultaneously provide user interfaces at both a consumer and a service display or other multiple user displays.
BACKGROUND ART
Automated banking machines are well known. A common type of automated banking machine used by consumers is an automated teller machine (“ATM”). ATMs enable customers to carry out banking transactions. Common banking transactions that may be carried out with ATMs include the dispensing of cash, the receipt of deposits, the transfer of funds between accounts, the payment of bills and account balance inquiries. The types of banking transactions a customer can carry out are determined by capabilities of the particular banking machine and the programming of the institution operating the machine. Other types of automated banking machines may allow customers to charge against accounts, to transfer funds and/or to cash checks or redeem other types of items. Other types of automated banking machines may print or dispense items of value such as coupons, tickets, wagering slips, vouchers, checks, phone cards, smart cards, food stamps, money orders, scrip or traveler's checks. For purposes of this disclosure a reference to an automated banking machine or an automated transaction machine shall encompass any device which carries out transactions including transfers of value.
ATMs have been developed which include both a front consumer user station and a rear service or maintenance user station. Each user station includes corresponding front and rear display devices and input devices. The front consumer user station typically includes a front consumer display that is publicly viewable and accessible. The front consumer display is generally associated with input devices such as a keypad and function keys which enable a consumer to perform transactions with the ATM. The rear maintenance user station is typically orientated in a position or location that is only accessible to individuals who maintain or service the ATM. Because the rear user station is generally used for maintenance purposes, it typically includes a rear maintenance display with access to the operating system and maintenance software. The rear maintenance display is typically associated with one or more computer input devices such as a fill keyboard and a mouse device.
In systems with dual displays, the maintenance display (alternatively referred to herein as a rear display) is controlled by the operating system and provides access to a computer shell, window, or other standardized interface to the operating system of the ATM. The consumer display (alternatively referred to herein as a front display) is typically a “slave” device that is controlled by a terminal software program using proprietary drivers. If the terminal software program terminates, the proprietary drivers are no longer available to output new consumer screens to the front display device. Consequently, the front display typically goes blank or shows a frozen screen, while the rear display may remain active and responsive to inputs from the associated keyboard and/or mouse.
Because the front screen is a “slave” device that is dependent on proprietary drivers for output, a servicer cannot use the front screen to run and interact with conventionally written programs. Only programs that are operatively programmed to access the hardware specific proprietary drivers of the display will have the ability to output a user interface on the front display. Such a design requires a more complex terminal software program with operative low level hardware dependent programming. In addition, if a different display hardware is implemented for the ATM, the terminal control software must be rewritten to interface with the new proprietary drivers that correspond to the new display hardware.
Consequently there exists a need for an ATM with terminal control software that is less complex to develop. There further exists a need for an ATM with terminal control software that can output user interfaces on two or more displays without being tied to specific proprietary display drivers.
The consumer displays of ATMs typically do not have associated input devices such as full keyboards and pointing devices. Any program that can be accessed through the front display must be operatively programmed to accept inputs from more limited input devices, such as keypads, touch screens, and function keys. To enable programs to be accessible from both the front and rear displays, separate front and rear interface programs may be created for dual display ATMs. Each of the front and rear interface programs are written to accept inputs from the specific types of input devices associated with the respective front and rear displays. For example a mouse device has the ability to easily move to and click a specific user interface element placed anywhere on a user interface window. This functionality enables ATM terminal software programmers to use a complex assortment of user interface elements such as scroll bars, buttons, list boxes, hypertext links, text boxes, tab controls, tree views and option buttons. Although such user interfaces are easily manipulated with a mouse at the rear display of an ATM, such user interfaces are very difficult to work with at the front display due to the more limited nature of available input devices such as function keys and keypad buttons.
Thus when a maintenance software program is required to be accessed from the front consumer display of the ATM, a separate front user interface program must be developed which is less complex and more easily accessed by input devices typically found in association with the front consumer display. Developing different user interface programs responsive to different input devices can consume a significant amount of programming effort. Consequently, there exists a need for an ATM programing architecture that reduces the need to develop separate user interface programs for both the consumer and servicer displays of an ATM.
ATM applications have been developed using a plurality of different operating systems such as Microsoft® Windows® NT and IBM® OS/2®. In addition for each targeted operating system more than one type of application development tool or version of the tools may be used. For example with a Microsoft(& Windows® NT operating system different C++ compilers from Microsoft®, IBM and other tool providers may be used to build ATM applications.
Unfortunately, when developing ATM applications different sets of source code must be written and maintained for each targeted operating system platform and software development tool. Although much of the source code is the same or similar for each targeted platform, incompatibilities between the operating systems platform and the foundation classes of the development tools typically require different sets of source code to be written. Maintaining completely separate sets of source code for each targeted platform decreases the productivity of ATM software developers. Consequently there exists a need for a method for developing ATM applications for different platforms and for different development tools that decrease the amount of duplicate code that must be written and tested.
When multiple developers are working to maintain ATM applications targeted for different platforms, each development workstation must include at least one installation of a development tool that is capable of compiling and building the ATM application. Although it may be desirable to install more than one development tool on a development workstation, in many cases the incompatibilities between different compilers and their configuration on a workstation makes it impractical to do so. Consequently there exists a need for a system of developing platform specific applications which enables a developer of ATM applications to more easily compile an application with different compilers from t
Miller Gregory R.
Putman Harold V.
Diebold Incorporated
Jocke Ralph E.
Le Thien M.
Le U Chau
Parmelee Christopher L.
LandOfFree
Method of developing platform specific applications for an... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method of developing platform specific applications for an..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of developing platform specific applications for an... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3143195