WO1992012479A1

WO1992012479A1 - Novel transaction system structure

Info

Publication number: WO1992012479A1
Application number: PCT/US1992/000141
Authority: WO
Inventors: Gordon Paul Eckley, Jr.
Original assignee: Verifone, Inc.
Priority date: 1991-01-09
Filing date: 1992-01-09
Publication date: 1992-07-23
Also published as: AU1190092A

Abstract

A transaction system (100) in which various software modules are layered on the core hardware (101). Operating system software (102) transforms hardware including a microprocessor to function as a general purpose computer having capabilities defined by the hardware and operating system software. Application software, communication software (104), shared libraries (107), and the like are invoked to cause the system to operate as a transaction terminal having specific characteristics to function in its intended transaction system environment. A system manager (106) allows the transaction terminal to communicate to a remote computer (150) or development system allowing diagnostics to be performed remotely on the transaction terminal and files to be updated on the transaction terminal. Information is stored in memory in the transaction terminal in the form of one or modules which includes offset information which allows the module to be stored in any desired location within transaction system memory.

Description

NOVEL TRANSACTION SYSTEM STRUCTURE

CROSS-REFERENCE TO RELATED APPLICATIONS The following co-pending applications are related to this application, and are hereby incorporated by reference:

Attorney

Docket

Title Number

Novel Transaction VERI-125 System Architecture

Transaction System VERI-126 Including Novel Memory Architecture & Management

640,279 1/9/91 Method and Structure VERI-129 for Determining Transaction System Hardware & Software Configurations

639,838 1/9/91 Emulator for Use with VERI-144 a Transaction System

Field of the Invention

This invention pertains to transaction terminals, and more particularly to a transaction terminal which includes layered approach such that the core of the system contains the most basic functions, and outer layers include more sophisticated functions which are capable of being modified or replaced as needed.

Background

Transaction automation systems of one sort or another are well known in the prior art. Electronic cash registers of varying degrees of sophistication have become rather commonplace in recent years. While the degree of sophistication of such devices varies, each essentially operates as a computer system performing specific tasks associated with the processing of the desired transactions.

Certain of these prior art ECRs include a microprocessor-based computer system including a factory programmable memory device, typically a mask programmable or one-time programmable (OTP) read-only memory (ROM) , which stores sufficient program information to cause the microprocessor to operate in order to control the ECR such that it performs the desired transaction processing function.

In such prior art systems, the factory provided ROM must necessarily define all the functions which the ECR must perform. While this may not seem to pose a problem for simple electronic cash registers, any changes in the function of the cash register will require a physical change of the ROM, which requires technical capabilities beyond that of a cash register operator, and likely beyond that which is available in a given business establishment. Furthermore, there is also a time delay associated with the factory providing the new ROMs, and their installation. In addition, there is the cost associated with the new ROM and its delivery and installation. U.S. Patents 4,688,173 and 4,811,219 both pertain to an electronic cash register including a ROM and one or more additional memories. The additional memories include addresses which are identical to addresses used by the ROM. A technique is used in order to memory map the additional memories onto the address space which serves to address both the ROM and the additional memories. In this manner, a microprocessor capable of addressing a given amount of memory space has access to a larger amount of memory due to the ability of the memory to be bank-switched as needed.

The additional memories are capable of storing modified programs such that the ECR utilizes these modified programs, rather than their unmodified counterparts contained within the ROM. While the '173 and '219 patents describe a structure which allows memory bank switching and is capable of utilizing modified programs, they have the disadvantage of being quite rigid in their hardware requirements, in that once the hardware is designed, changes in memory size necessitate significant hardware changes. Furthermore, program sizes are constrained by the size of memory banks.

SUMMARY OF THE INVENTION In accordance with the teachings of this invention, a novel transaction system is provided in which various software modules are layered on the core hardware. In accordance with the teachings of this invention, operating system software is utilized to transform hardware including a microprocessor to function as a general purpose computer having capabilities defined by the hardware and operating system software. Once this general purpose computer has been implemented, application software, communication software, shared libraries, and the like are invoked in order to cause the general purpose computer established by the hardware and operating system software to operate as a transaction terminal having specific characteristics to function in its intended transaction system environment. In one embodiment of this invention, a system manager is included which allows the transaction terminal to communicate to a remote computer or development system allowing diagnostics to be performed remotely on the transaction terminal and files to be updated on the transaction terminal. In one embodiment of this invention, information is stored in memory in the transaction terminal in the form of one or modules which includes offset information which allows the module to be stored in any desired location within transaction system memory. Each module includes start¬ up code, which allows selected tasks pertaining to that module to be performed upon initialization. One or more of such modules are library modules, whose start-up codes include the ability to create, alter and/or append to, one or more vector files which allow invocation of functions contained within the libraries regardless of the precise location within memory in which libraries are stored. This feature allows libraries to be added over time to the transaction system, with the vector files being continually updated in order to properly point to the location associated with each current function stored within the library modules.

DESCRIPTION OF THE DRAWINGS

Figure 1 is a diagram depicting one embodiment of the transactions terminal constructed in accordance with the teachings of this invention, in communication with a development system;

Figure 2 is a diagram depicting the organization of memory modules and vector files in accordance with one embodiment of this invention;

Figure 3 is a diagram depicting memory utilization in accordance with one embodiment of this invention; and

Figure 4 is a flow chart depicting start-up operation in accordance with one embodiment of this invention.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

Figure 1 is a diagram depicting one embodiment of a transaction system constructed in accordance with the teachings of this invention. Of interest. Figure 1 depicts not only transaction system 100, but also development system 150. Development system 150 comprises a general purpose computer, such as a personal computer (PC) which is used to develop various types of software for use in transaction system 100. This software includes operating system software, application software, as well as data files, and the like. By allowing system development to take place on a general purpose computer, various sophisticated tools which are generally available or which later become available are used to develop the software in a convenient fashion, which software is then provided to transaction system 100. This may occur, for example, by programming memory devices such as read only memories or programmable read only memories based upon the development performed utilizing development system 150, with the memory devices then being inserted into transaction system 100. This is convenient when transaction system 100 is being initially manufactured or is being refurbished at the factory. It is also possible to replace memory devices in the field, although this is less convenient and would preferably be performed only with a major change, or the cumulative effect when a number of changes is made. Alternatively, software and/or data is replaced or appended within transaction system 100 utilizing a memory device which is more easily replaceable in the field, such as a ROM cartridge or a JEIDA memory card. In accordance with the teachings of this invention, software programs, modifications to existing software programs, and new and modified data is capable of being provided to transaction system 100 remotely, via communications link 112. Communications link 112 may comprise, for example, a local area network enabling a central computer within a large department store, for example, or a central computer tied to a number of retail outlets, to provide software and data to two or more transaction systems 100 connected to local area network 112. Alternatively, communications link 112 is a point-to-point communications link, for example, used for connecting an individual transaction terminal 100 to a remote computer, such as development system 150. If desired, development system 150 is used to develop software and data which is then transported to a host computer (not shown), via communications link 112 to transaction terminal 100. Development system 150 typically comprises a PC with communications software 152 for communicating with terminal 100, and debug tool 151 for use in evaluating the operation of transaction system 100, including detecting and correcting any possible errors in the operation of transaction system 100. The operation of debug tool 151 allows development system 150 access to the internal operation of transaction system 100 as transaction system 100 is operating in its intended mode of operation, or in a captured mode, whereby transaction system 100 is effectively disabled pending debug and analysis.

In the first debug mode of operation, which in many instances is preferred, development system 150 is capable of monitoring or tracing every action (or a selected subset thereof) taken during the operation of transaction system 100 in its normal course of business. Any anomalies in the operation of transaction system 100 is easily detected and either corrected at that time, or provided to a technician in order to evaluate what is causing the problem such that a solution can be developed and provided to transaction system 100.

The second debug mode of operation is the "capture" mode, in which the development system 150 tests transaction system 100 while effectively disabling transaction system 100. This may be desirable, for example, for very extensive tests or, more likely, if transaction system 100 has failed so badly that it is effectively out of service anyway. Transaction system 100 includes a "layered" approach, as depicted in Figure 1. At the heart of transaction system 100 is its hardware 100, which includes, for example, a microprocessor (such as a Motorola 68302) serving as a CPU of transaction system 100, memory devices, power supply, and the like.

Transaction system 100 also includes operating system ("OPSys") software 102, which serves to control the operation of hardware 101 such that hardware 101 functions as a general purpose computer whose level of sophistication is dictated by the sophistication of hardware 101. OpSys 102 typically comprises a multitasking operating system with shared libraries. Additional software and data are used in conjunction with OPSys 102 to configure the general purpose computer provided by hardware 101 and OPSys 102 into a transaction terminal having the desired capabilities for the desired transaction system. For example, specific applications software, application data, and the like, are included with hardware 101 and OPSys 102 to provide a transaction system which is uniquely tailored for use in a department store, a gas station, a restaurant, a utility company, an accounts receivable department, a medical office, and the like. By providing different combinations of applications software and the like in addition to hardware 101 and OPSys 102, transaction system 100 is thus configured for its specific intended purpose. For example, hardware drivers 103 and software drivers are used for interfacing transaction terminal 100 with various peripheral devices such as printer 109, display 110, keyboard 111, and the like. As shown in Figure 1, these peripheral devices are connected to transaction terminal 100 via a single bus 108 which is shared among these peripherals. If desired, one or more peripherals can be connected to transaction terminal 100 via point-to-point connections, or a plurality of busses can be used in order to minimize bus contention. Other types of peripherals include, for example, UPC scanners, magnetic stripe readers, scales, change machines, keyboards, displays, printers, disk drives, and the like. Of interest, drivers 103 can be selected so that drivers are included only for the specific peripherals utilized with a given transaction system 100, thereby minimizing memory requirements within transaction 100.

In the example of Figure 1, transaction system 100 also includes communications driver 104 which serves to link transaction system 100 to the outside world via, for example, telephone and/or direct connection.

Transaction system 100 also includes peripheral bus driver 105 which serves as a tightly captured peripheral synchronous serial interface with error detection and correction. In one embodiment of this invention, this peripheral bus is that bus described in the above- mentioned co-pending U.S. patent application entitled "Novel Transaction System Architecture". Transaction system 100 includes system manager software 106 which serves as the interface between transaction system 100 and development system 150.

Library 107 typically comprises a plurality of software programs which provide services for application tasks. Figure 2 depicts libraries 107 of Fig. 1 in greater detail. In this embodiment, libraries 107 include only a single copy of each portion of the software (a "function"), such as a subroutine, or data file, which is to be used by a number of application software modules. Thus, in this embodiment, transaction system 100 includes shared libraries in that each software module which requires a particular software function will access the single copy of that software function contained in libraries 107 for execution and return to the calling module. This conserves memory space. In one embodiment of this invention, each task 201-1 through 201-N accesses one or more functions via vector file 202. Vector file 202 includes a pointer indicating the address location of the actual function within function library 203. Thus, a particular task, 201-1 through 201-N, can access one or more functions without knowing its precise location with function library 203. This allows the organization of function library 203 to be changed as desired with a corresponding change in vector file 202, rather than requiring a change in a plurality of tasks, 201-1 through 201-N, in order to indicate the new location of the particular function within function library 203. This has a number of advantages. First, sharing libraries minimizes the memory space required to store libraries 107. Secondly, additional functions can be added to a system simply by storing an additional functions within function library 203 and including an entry in vector file 202 to indicate the location of that function newly added. Furthermore, functions can be modified or upgraded even when such modification or upgrade will require an increase in the memory space required for that function. Thus, for example. Figure 3 depicts the organization of function library 203a including functions fl through f4, and the organization of function library 203b after function f2 has been upgraded which requires additional memory space for its storage. In addition to reallocating memory 203b such that the space initially holding function f2 is not used and previously available and unused memory space is allocated to modified function f2, the pointer to function f2 stored within vector file 202 is updated to indicate the new starting location within memory 203 for function f2.

In accordance with one embodiment of this invention, address space within library memory space 203 is defragmented, for example, such that the unused space between functions fl and f3 of memory function library 203b of Figure 3 is eliminated. This allows the maximization of the amount of contiguous available (i.e., unused) memory space in function library 203. This allows additional software or software modifications to be added to function library 203 quickly and without the need to hunt for a suitable amount of available space. This also allows the use of contiguous unused memory to be used for other purposes, for example, as one or more scratch pad data storage areas, and/or one or more storage area for cumulative data gathering, such as statistics which are accumulated each operating shift of the transaction terminal. In one embodiment of this invention, functions can themselves be stored in fragmented form within memory, utilizing appropriate jumps in order to carry out the entire function. This may be helpful, for example, when it is desired to download software during a busy transaction period, without the need for defragmentation. In one embodiment of this invention, defragmentation occurs when the transaction system is otherwise not very busy, for example during a slow shift, when a store is closed, or when the transaction system is not being operated.

As shown in Figure 2, each module 203 includes header information, relocation data information, and start-up code information. Header information describes the memory size requirement of the library module and provides descriptors to key data sections within the module. Header information also includes date/time stamp information pertaining to the creation of the module. Relocation information describes relocation data, if any, for the module. This relocation information describes, for example, address offset information for various pieces contained within the module, with respect to the top of the module. This relocation information is updated upon defragmentation, as the module is moved to a different location within memory. Start-up code information includes module start-up program code which serves to, for example, initialize all data sections and set up CPU registers for execution of the module. These data sections serve to properly reflect the memory address based on the module's current position in memory, so that the module can execute.

As shown in Figure 2, a general module also includes code, and various types of data. For modules which serve as library modules, each portion of code and/or data is considered as a "function", which is then pointed to utilizing the vector file which is created upon running each library module. In one embodiment of this invention, when application software is prepared using development system 150, functions are called within the code via an appropriate means, such as naming conventions, such that the code executed by transaction terminal 100 is able to access the function by finding the appropriate pointer within the vector file.

Figure 4 is a flow chart depicting one embodiment of the operation of a transaction system constructed in accordance with the teachings of this invention. Upon initialization, such as in response to a power on reset, diagnostics are performed. These diagnostics serve to, for example, determine system configuration and basic functionality of the system. Operating system software is then loaded in order to cause the hardware to operate as a general purpose computer system having capabilities determined by the hardware and the operating system software. Modules which serve as libraries are located, for example, by use of a naming convention which easily identifies each module as a library or other types of modules. Each library includes its own start-up code which is then run. Each libraries' start-up code serves to initialize data sections and create one or more vectors memories which serve as pointers to library functions. In one embodiment of this invention, library start-up code is run in chronological order so that the oldest library is used first in order to create the vector files. This allows the final vector files, which have been created and modified after running all library start-up code in chronological order, to properly reflect the most current state of the various functions contained within the various library modules. Next, as shown in Figure 4, communications ability is established, utilizing communications software 104, and bus driver 105 in combination with peripheral drivers 103. As shown in Figure 4, applications programs are run, allowing the transaction system to function in an intended manner. In one embodiment of this invention, the system manager is established during the diagnostics portion of the start-up operation, thereby allowing communication and/or debugging to occur with development system 150 even if fairly low level errors in the system occur. In this embodiment, so long as the basic hardware and software operations pertaining to the system manager are functional, communication and debugging can take place with development system 150. In an alternative embodiment of this invention, system mode software 106 is initialized at a later point in the start-up sequence, for example during the initialization of the operating software, during the establishment of communication capabilities, or during initialization of the application programs.

All publications and patent applications are herein incorporated by reference to the same extent as if each individual publication or patent application was specifically and individually indicated to be incorporated by reference.

The invention now being fully described, it will be apparent to one of ordinary skill in the art that many changes and modifications can be made thereto without departing from the spirit or scope of the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A transaction system comprising: a CPU; memory for storing a plurality of modules, each module comprising: header information; relocation information; start-up code; and software.

2. A transaction system as in claim 1 wherein said relocation information comprises information pertaining to offset values between the start of said module and various locations within said software.

3. A transaction system as in claim 2 wherein said start-up code serves to adjust memory location information within said module based upon the starting address of said module as stored in said memory.

4. A transaction system as in claim 3 including means for revising said memory location information when the location of said module within memory is changed.

5. A transaction system as in claim 4 wherein one or more of said modules comprise libraries containing functions, said functions being contained within said system only once and being shared among all software.

6. A transaction system as in claim 5 wherein said library modules each comprise start-up code which serves to create, amend, or append to, one or more vector files which store pointers to the address locations within said memory of each of said functions.

7. A transaction system as in claim 6 wherein each of said library modules includes a date/time stamp pertaining to its creation.

8. A transaction system as in claim 7 wherein one of said modules includes operating system code, which serves to locate all of said library modules and invoke the start-up code of each of said library modules.

9. A transaction system as in claim 8 wherein each of said library module start-up codes are invoked in chronological order based upon said date/time stamps.

10. A transaction system as in claim 1 which further comprises means for defragmenting information stored in said memory.

11. A transaction system as in claim 10 which further comprises means for storing additional modules in said memory.

12. A transaction system as in claim 1 which further comprises hardware diagnostics performed upon power-up or upon request by software.

13. A transaction system as in claim 1 which further comprises software diagnostics performed upon power-up or upon request by software.

14. A transaction system as in claim 1 which further comprises means for communicating with a plurality of peripheral devices.

15. A transaction system as in claim 1 which further comprises means for communicating with a remote computer.

16. A transaction system as in claim 15 wherein said remote computer comprises a debug tool.

17. A transaction system as in claim 16 wherein said debug tool allows said remote computer to remotely debug the operation of said transaction terminal.

18. A transaction system as in claim 1 which further comprises means for determining the configuration of said transaction system upon power-up.