Method and structure for determining transaction system hardware and software configurations

A method and structure are provided for automating the collection of information from a customer and providing a specification of a transaction system to fullfil the customer's needs and desires. An ordering step is used in order to obtain information via a convenient user interface to determine the customer's intended use of the machine and the performance desired. As a result of this ordering process, the system hardware configuration is determined automatically. During the implementation process, the system is used to assemble a package of software, to run the hardware thus configured and implement the chosen user functions. If desired, this information is stored for later use in the event the user wishes to modify the configuration of his system, or to order additional system configurations different than that of the initial system.

CROSS-REFERENCE TO RELATED APPLICATIONS 
The following co-pending applications are related to this application, and 
are hereby incorporated by reference: 
______________________________________ 
Filing 
USSN Date Title 
______________________________________ 
07/639,584 
1/9/91 Novel Transaction 
Now Abandoned 
System Architecture 
07/639,583 
1/9/91 Transaction System 
Now Abandoned 
Including Novel 
Memory Architecture & 
Management 
07/639,572 
1/9/91 Transaction System 
Now Abandoned 
Including Novel 
Program Structure 
07/639,838 
1/9/91 Emulator for Use with 
Now Abandoned 
a Transaction System 
______________________________________ 
BACKGROUND OF THE INVENTION 
This invention pertains to transaction systems, such as point of sale 
terminals, inventory control systems, and the like. More particularly, 
this invention pertains to a method and structure for determining the 
specific hardware and software configuration needed to meet an end users' 
needs and desires. 
DESCRIPTION OF THE PRIOR ART 
Transaction systems are well known in the prior art and consist to a large 
extent of sales systems such as electronic cash registers and associated 
peripherals. Typical prior art systems include an electronic cash register 
of pre-determined hardware configuration running specific application 
software. For example, in a supermarket an electronic cash register is 
utilized in conjunction with a bar code scanner, a change machine, a 
produce scale, and the like. The electronic cash register is typically a 
general purpose electronic cash register including ports for connecting 
the peripheral devices. The application software is stored in the 
electronic cash register in order to meet the needs of the particular 
retail or professional environment. In some environments, such as a 
medical office or certain billing departments, a computer system is used 
in lieu of an electronic cash register. However, as with prior art 
electronic cash register systems the computer system is configured with 
application software and hardware to perform the desired functions of the 
particular environment. 
In order to configure the system and software for a particular use, prior 
art systems leave few choices. In many situations, the electronic cash 
register provided no opportunities for being tailored to the specific 
environment of the end-user. In those instances in which the electronic 
cash register could be tailored, tailoring the electronic cash register 
for a specific need was accomplished by a salesperson or the like who 
selected from the few options available based upon his experience with end 
user needs. 
The situation with respect to application software is no better in the 
prior art. Although there is generally greater diversity in application 
software than hardware in the prior art, much of it is custom tailored by 
the particular end user for use in their applications. Thus, for example, 
a supermarket chain would often prepare, or have prepared, application 
software intended for their specific use. While a number of features might 
be common among various supermarket chains, or end users in general, it 
was up to the end user to determine which applications were needed for 
their particular purposes, and how best to implement those application 
softwares. 
Accordingly, it is seen that in the prior art relatively few choices of 
hardware configuration and application software configurations are 
available on a standardized basis. From the relatively small selection of 
standardized application software, a selection is made in a non-standard 
manner by a sales or marketing person which hopefully best meets the end 
users' needs. 
SUMMARY OF THE INVENTION 
In accordance with the teachings of this invention, a method and structure 
are provided for automating the collection of information from a customer 
and providing a specification of a transaction system to fullfil the 
customer's needs and desires. In one embodiment of this invention, an 
ordering step is used in order to obtain information via a convenient user 
interface to determine the customer's intended use of the machine and the 
performance desired. As a result of this ordering process, the system 
hardware configuration is determined automatically. During the 
implementation process, the configuration system of this invention is used 
to assemble a package of software, which may include both programs and 
data files, to run the hardware thus configured and implement the chosen 
user functions. 
If desired, this information is stored for later use in the event the user 
wishes to modify the configuration of his system, or to order additional 
system configurations different than that of the initial system.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS 
Transaction system end users (i.e. customers of transaction system vendors) 
understand their environments and can describe their needs in looking for 
solutions to their problems. Customers (and vendor marketing personnel) 
need help, however, in selecting the appropriate choice of hardware and 
software options provided by a modern transaction system. 
In accordance with the teachings of this invention, a method and structure 
are provided for automating the collection of information from a customer 
and providing a specification of a transaction system that will fulfill 
the customer's needs. Information on a customer's system is retained for 
maintaining and updating the customer's system at a later date, as 
customer needs change. 
The use of the configuration system of the present invention may be 
described as follows, with reference to FIG. 1 which depicts one 
embodiment of a configuration system constructed in accordance with the 
teachings of this invention. 
1. Ordering process: The configuration system of this invention is used to 
insure functional completeness of the user's system and specify the 
hardware configuration to implement those functions. System specification 
includes the user's choices for the user interface (e.g. keyboard 
definition) and the order and presentation of functions to be performed by 
the transaction system (e.g. scroll through a menu, select function by 
pressing a single key). 
2. Implementation process: The configuration system is used to assemble a 
package of software (programs and data files) to run the hardware and 
implement the chosen user functions. 
3. Maintenance: The information produced by the configuration system is 
available for various maintenance activities and the configuration system 
itself is used for updating the user's system. 
ORDERING PROCESS 
In the ordering phase, input from the user will typically be in response to 
questions and consist generally of yes/no choices and some numbers or 
ranges of numbers. This information is easily provided as it is the 
customer who is most familiar with his business and his specific needs. 
The customer supplied information is used to specify the functions which 
the user has indicated his customized system needs to perform. From these 
functions the configuration system derives the system description. 
The user functions include, for example, some or all of those given in 
Appendix A. The choices are presented to the user in a form most 
appropriate for the user which may, if desired, differ from the 
organization of the material in Table 1. The ordering phase of the 
configuration system preferably takes into account defaults (functions a 
user will get automatically in various circumstances, unless specifically 
renounced), probable contingencies ("if you have chosen A, then you might 
want B"), and the user viewpoint in general. If desired, the form of 
presentation can be made dependent on the type of business and activity 
which will be served by the transaction system being configured. 
In one embodiment, program queries and user input of data is through a 
user-friendly interface of menus and windows. The interface works off of 
one or more templates that allow for easy alteration of the interface for 
different markets and to respond to feedback from sales personnel and 
customers in order to make the ordering process as simple and responsive 
as possible. This is described in greater detail later under the heading 
"Setting up and Modifying the Configuration System." 
The configuration system performs two operations with respect to the input 
data: determining the completeness of the data and determining the 
system(s) that will meet the requirements of the data. The configuration 
system first decides whether the information given is complete. If not, it 
calls for the information needed. This functionality is closely integrated 
with the user interface and has a "shell" form allowing for the easy 
alteration of the input requirements and the decision rules. 
Various reports are capable of being provided following the ordering 
process. For example, a hardware report comprises a hardware component 
list, including the required amounts of memory. If desired, this hardware 
report can also include product pricing based upon the hardware 
configuration required. If desired, one or more reports pertaining to the 
desired functions and the software modules required is also provided; in 
one embodiment pricing of the software required is also provided. If 
desired, the system automatically generates purchase orders, and provides 
shipping information as well. 
One or more data files are created during the ordering process in response 
to the customer supplied information. Such one or more data files are then 
provided to the implementation process, which is now described. 
IMPLEMENTATION PROCESS 
Step 1: Based upon the configuration and functionality defined in the 
ordering process, additional information is obtained, for example in a 
similar manner as information is obtained during the ordering process, to 
obtain specific information needed to implement the desired functionality. 
For example, once the functionality is defined in the ordering process, 
this step obtains information defining the specific location of keys on a 
keyboard, which keys are required by the desired functionality. A user's 
specific data is also obtained, such as the sales tax table, price look up 
files, department definitions, gasoline storage pump configurations, which 
are needed as defined during the ordering process. 
Step 2: The software component package, consisting of application programs 
and specific data files, is generated based upon the determined 
configuration. The package is presented for installation in an appropriate 
mode, such as via modem, diskette, JEDIA card, or as a file on the 
salesperson's or customer's computer, such as a personal computer. In one 
embodiment, an operational state table (OST) is generated in order to tie 
together the application software selected for this configuration and the 
user defined keys. For example, a master state table (MST) is used which 
includes a large number of possible combinations of states and key 
entries, from which are selected those state transitions required to form 
the OST for the specific configuration being developed. 
MAINTENANCE 
If desired, the "raw" information input by the customer and/or the 
information generated by the configuration system is saved for future use 
in the event the customer determines that his needs or desires have 
changed. In this manner, only changes need be input to the configuration 
system, rather than a complete set of data, thereby making the task of 
modifying the configured system quite simple, fast, and inexpensive as 
well as less prone to error. Furthermore, this allows a customer to 
explore various alternative systems based upon slightly changed 
functionality such that, for example, new comparisons can be made. 
SETTING UP AND MODIFYING THE CONFIGURATION SYSTEM 
An ASCII file is used as a template to determine the content and flow of 
the process by which the configuration is defined. This file is easily 
constructed and altered with a simple text editor. In one embodiment of 
this invention, a template editor is included which is invoked via the 
Edit selection on the main menu. If desired, separate templates are used 
for different types of users in order to make the configuration process as 
simple as possible for each user. Thus, for example, one template is used 
to configure supermarket transaction systems, another template is used to 
configure gasoline station transaction systems, etc. 
1. Template Control of Input 
The template lists the data required for a given running of the 
configuration system. It supplies a list of the data required, its type 
and format, and the text of the prompt to obtain the data. When the data 
is a selection among alternatives, the template supplies the text 
describing the alternatives that appear in the window. The I/O shell takes 
the template data and uses it to ask the right questions. 
In one embodiment, there are six types of data elements ("facts"). 
1. Integer 
2. String 
3. Boolean (e.g. yes/no or true/false) 
4. Attribute--e.g. select one choice from a list of choices 
5. Multivariable--e.g. select a plurality of choices 
6. Real 
The list of required input data fulfills the function of determining if all 
the data has been received. In one embodiment, the list of required input 
data is cycled through and each question must be answered. Where 
appropriate, the template includes certain default input data values. 
2. Template Specification of Decision Rules 
The template contains the rules relating the input elements. The template 
is divided into three sections. The first section is called the Facts, the 
second section is called the Rules, which defines the relationship(s) 
between the facts, and the third section is called the Reports which 
specifies the output data and output format. 
The criteria used for the selection of a system configuration is based upon 
a combination of the rules and the facts specific to that user. 
3. The Use of Different Templates 
Different templates are appropriate for different users. Different 
templates can adapt the use of the configuration system of this invention 
to different natural languages. Different levels of generality for 
templates are, if desired, employed. For example, a high level of 
generality might cover one kind of store for different companies, a more 
specific level might be for different stores for the same company. If 
desired, templates can be configured for use for different types of end 
users, e.g. a given template is used which is specifically tailored for a 
supermarket application, another template is used which is specifically 
tailored for a department store situation, and another set of template is 
used which is specifically tailored to apply to the data gathering with 
respect to a professional office environment. In one embodiment, a record 
of a customer profile includes a record of the template with which it was 
collected. 
In one embodiment of this invention, the configuration system includes 
programs written in C and compiled using a Microsoft C compiler to run on 
a DOS based personal computer, such as an IBM AT or equivalent. One such 
embodiment includes the following modules: 
Modules 
3.1 The I/O Interface 
3.2 The Shell 
3.3 File Maintenance 
3.3.1 Keyboard Program 
3.3.2 State Table 
3.3.3 Miscellaneous Site Files 
3.4 Report Generators 
3.5 Communications Media 
USER INTERFACE 
FIGS. 2 through 5 depict the user interface screen for the edit, user data, 
reports, and select screens, respectively, in accordance with one 
embodiment of this invention. In each of these screens, the user interface 
presents six windows as follows: 
1 MENU: 1st level of user choice. 
2 OPTIONS: 2nd level of user choice. 
3 DIALOG: 3rd level of user choice. 
4 FILES: This window indicates the current template file in use and the 
current active user file. 
5 MESSAGE: This is a message window where the shell puts messages 
conforming to whatever processing is currently being carried out. Error 
messages also appear in this window. 
6 DATE & TIME: Presents the date and time 
1 MENU. The Menu window presents the four choices: 
EDIT (FIG. 2) is used to edit the choices presented to the user 
USERDATA (FIG. 3) used to enter user data and run DOS programs 
REPORTS (FIG. 4) is used to generate reports based on the user data 
SELECT (FIG. 5) can be used, if desired, to select a different template or 
user file. Alternatively, this selection is achieved via the Load option 
of the Userdata menu. 
Highlighting is moved among the choices by the use of the left and right 
cursor arrows. The highlighted choice is activated by pressing the TAB 
key. When a selection is activated, the OPTIONS window presents the 
options appropriate to the menu selection. 
The EDIT Function 
This function is used to edit the choices presented to the user. The 
following options are available: 
FILES--Used to select an existing template file. 
OPEN--Provides same function as FILES. 
NEW--Used to create a new template file; prompts for a file name. 
SAVE--Saves the currently selected file; prompts for a filename if n file 
name was specified earlier. 
EXIT--Saves the currently selected file and returns to Main Menu. 
QUIT--Returns to the Main Menu without saving changes. 
The USERDATA Function 
This function is used to enter user data and run DOS programs. Four options 
are currently available: 
LOAD--Loads a selected template file. The loading of the template file 
forms a base upon which questions can be asked and the required 
information queried and stored. The user is also prompted to select an 
existing user file that contains previously saved information. 
RUN--Starts the User session and evaluates the Rules. 
DOSPROG--Used to select and execute those DOS programs that are defined in 
the template file. 
SAVE--Used to save new and updated information. 
The REPORTS Function 
This function is used to generate reports based on the user data entered. 
Two options are available: 
BUILD--Used to build the Reports specified in the template file. 
PRINT--Sends the reports built using the above option to the printer. 
The SELECT Function 
This function is used to select available files. The current options are: 
RULEFIL--Initially LOAD prompts for a Rulefile, however, if the user wants 
to load a different template file after a session, this option can be used 
to select another file. 
USERFIL--Same as RULEFIL, except for User files. 
FILES Window 
The FILES window displays the name of the current activated file. 
DIALOG Window--The DIALOG window displays the questions/choices used to 
identify the system that will best satisfy the needs outlined by the user. 
A sample of these questions/choices is listed in Appendix B according to 
file type (Fact, Rule, Report). 
MESSAGE Window--The MESSAGE window displays error messages or other user 
instructions. 
OPTIONS Window--The OPTIONS window lists the options available for each 
MENU function (refer to FIGS. 2 through 5). To select an option, use the 
up/down cursor arrows. When the desired option is highlighted, activate it 
using the ENTER key. 
TABLE 1 
Applications and Functions 
(Classified by Session and Service Type) 
1. Sales Sessions 
1.1 The Sales Application 
1.1.1 Entering sales manually, with designation of department, e.g. 
taxable, nontaxable, deli, bakery 
1.1.2 Entering sales automatically using all relevant information from the 
item file (item file: the information on an item recorded within the 
system) 
1.1.2.1 Scanning the UPC or EAN of an item 
1.1.2.2 Recording sales of fast moving, promotional, or non-coded products 
by use of predefined buttons (item definition keys, IDKs) on the keyboard 
1.1.2.3 Identifying products by a numeric entry, other than the above 
1.1.3 Modifying the effects of other entries by special keys 
1.1.3.1 Modifying the effect of UPC, EAN, IDK and numeric entry keys by a 
series of keys to take account of sizes or quantities: small, medium, 
large, single, 6-pack, case, etc. 
1.1.3.2 Using a multiplier key for the sale of more than one of an item 
1.1.3.3 Calculating the split price on multiple unit priced items, mix and 
match or specially priced combinations: 3 for $1, coffee & danish 
1.1.3.4 Overriding the price of an item at the time of sale 
1.1.4 Calculating taxes automatically to the extent possible 
1.1.4.1 Calculating the sales tax in accordance with the various state and 
local requirements, using multiple tables as necessary 
1.1.4.2 Adding in any appropriate excise taxes or value added tax as 
required by law 
1.1.4.3 Overriding the tax or the tax amount for tax exempt organizations 
1.1.5 Modifying transactions 
1.1.5.1 Incorporating a discount into the sales transaction for a single 
sales item or for an entire receipt 
1.1.5.2 Voiding for a single sales item or for an entire receipt 
1.1.5.3 Including a high amount lockout (HALO) and a low amount lockout 
(LALO), with the facility for override 
1.1.6 Handling various tender media: cash, checks, charge, debit, credit, 
manufacturers coupons, store coupons, food stamps, cash card, etc. 
1.1.6.1 Separate accounting for different media 
1.1.6.2 Automatic handling of special rules for different media such as 
laws governing the use of food stamps 
1.1.7 Printing sales receipts with options for modes: full receipt, 
abbreviated receipt and no receipt 
1.1.8 Opening the cash drawer by use of a NOSALE key 
1.1.9 Interfacing with various models of [Bscales and proper handling of 
tare (the weight added by packaging) 
1.1.10 Accounting for returned merchandise and refunds 
1.1.11 Handling different or special forms of sales (Session Subtypes) 
1.1.11.1 Lottery Sessions: Handling the selling of lottery tickets and the 
redemption of lottery winners, as defined by the state commission 
1.1.11.1.1 Handling up to 12 scratch lottery books 
1.1.11.1.2 Handling lotto 
1.1.11.2 Gasoline sessions: see item 2 below 
1.1.11.3 Customer Sessions: to be dealt with in later phases of Gemstone 
1.2 The Time Clock Application 
1.2.1 Recording employee clock in/out data 
1.2.2 Presenting clock information to store management for verification and 
approval prior to payroll processing Note: this is an example of a 
functionality that reside in different sessions (clerk or administrative) 
for different users 
1.3 The Inventory Application 
1.3.1 Handling deliveries of merchandise by vendors, to include the cost of 
goods received and the increased retail accountability 
1.3.2 Recording and accounting for merchandise that is: 
1.3.2.1 Not appropriate for sale or use in the store or facility (bad 
merchandise: damaged, spoiled or any other condition which might prohibit 
if from being sold) 
1.3.2.2 Used in upkeep of store/facility and thereby removed from the 
retail stock 
1.3.2.3 Transferred out of the facility to an affiliated facility 
1.3.2.4 Transferred in from an affiliated facility 
1.3.2.5 Returned to vendor 
1.3.2.6 Used as ingredients for retail items 
1.4 The Accounting Application 
1.4.1 Accounting for various tender media and coupons 
1.4.2 Accounting for loans from safes or cash controllers 
1.4.3 Accounting for tender transfers: 
1.4.3.1 Removed from the cash drawer and secured in a safe or cash 
controller (drops) 
1.4.3.2 Removed from the cash drawer or facility to be deposited in the 
bank 
1.4.3.3 Brought into the facility from the bank 
1.4.4 Accounting for the payment of vendor invoices from the financial 
resources in the facility (paid outs) 
1.4.5 Accounting for miscellaneous income 
1.4.5.1 U.S. Postage Stamps, game machines, etc. 
1.4.5.2 Deposits and deposit returns for soft drink bottles and other 
containers 
1.4.5.3 Rentals such as video tapes and electronic equipment 
1.5 Closing Applications 
1.5.1 Terminal Close 
1.5.2 Shift Close 
1.5.3 Day Close 
2. Gasoline Session (a subtype of the Clerk Session) 
2.1 Controlling the gasoline dispensers from the terminal 
2.1.1 Controlling the pumps either via the PAM (pump access module) 
provided by the manufacturer or directly via the current loop. 
2.1.2 Determining problems at terminal or in-store computer that are 
currently handled in the console incorporated in the system 
2.1.3 Shutting down dispensers in emergency situations at the terminal 
2.2 Providing direct cash accounting control over gasoline sales and 
dispensing, at the terminal upon which the sale was initiated 
2.3 Providing for payment: 
2.3.1 Made by prepayment or postpayment with same information available on 
both for customer receipt 
2.3.2 Made by specific dollar amount or for unlimited dispensing. 
2.4 Providing for multiple delayed sales (gas queuing) 
2.5 Providing for sales initiated on one console and concluded on another 
2.6 Recording on the customer receipt, the pertinent data involving the 
sale of gasoline, including: 
2.6.1 dollar amount of the sale, 
2.6.2 the gallons sold, 
2.6.3 the grade of gasoline 
2.7 Provide for deliveries and other inventory adjustments of the gasoline 
inventory 
2.8 Allowing attachment of any pump to any gasoline storage tank and, 
hence, to any grade of gasoline for: 
2.8.1 up to eight grades of gasoline 
2.8.2 up to eight gasoline storage tank 
2.8.3 up to 32 pumps as a normal configuration in a gasoline retail store 
2.9 Interfacing with any of the various gasoline tank monitors and making 
that information available for reporting 
2.10 Requiring minimal hardware modification to interface with pumps of 
various manufacturers such as user replacement of a single component. 
Suggested manufacturers of dispensers include: Gilbarco, Tolkeim, 
Dresser-Wayne, Bennett and Southwest Pump 
3. Administration Sessions 
3.1 Reporting and Displaying Application 
3.1.1 Accounting totals for the current period (since the last time the 
totals were cleared) 
3.1.1.1 Providing the option to clear after printing 
3.1.1.2 Providing the capability to adjust the period accounting summaries 
for "over-rings" and errors by a "Post Void" function 
3.1.2 Displaying various types of system data 
Note: the display functionality is one that may be divided up in different 
ways and appear in different session types according to what is to be 
displayed and the customer's preferences. 
3.2 Site 
3.2.1 Modifying the store and terminal numbers 
3.2.2 Modifying the date and the time maintained by the system 
3.2.3 Modifying the tax computation tables used for the calculation of the 
sales tax 
3.2.4 Modifying the information about a product, such as UPC, source, 
description, price, food stamp eligibility and tax indicator 
3.3 Maintaining and enhancing applications 
3.3.1 The accounting summaries is maintained by operator, by terminal, or 
by system. 
3.3.2 The means of recording sales, deliveries, bad merchandise, refunds, 
in-store use, transfers in and out, returns to vendors, and any other 
means of inventory adjustment. 
4. Internal Services 
4.1 Database services 
4.1.1 Maintaining an accounting of all activities for reporting through the 
administrative sessions 
4.1.2 Handling the on-line updates of all accumulator files for accounting 
purposes 
4.1.3 Providing data for reporting and for upload tasks 
4.1.4 Providing integrity of updates at the field level 
4.2 Communication services. Communication services are integral to 
automation efforts and are available at various levels, from the terminals 
to in-store personal computers to the host mainframes. 
4.1.1 Causing minimal interference with normal activities 
4.1.2 Establishing connection with PNC330 for remote communication to 
financial services via telephone line 
4.1.3 Passing information to a higher level utilizing a "state of the art" 
communications discipline 
4.1.4 Interrogate internal LAN/files to determine availability of 
additional functionality for purpose of migrating to full system 
capability 
4.1.5 The operational mode of the system, terminals and the in-store 
computer (including the sequence of entry and/or the information captured 
at the store) are modifiable from the host computer 
4.3 Diagnostic services 
4.3.1 Analyzing and reporting problems relating to system components 
(self-diagnosis) 
5. Security Services 
5.1 Local Application Security 
5.1.1 Authorizing by password, the applications authorized by a given 
password are set in an administrative session 
5.1.2 Cash drawer accountability 
5.2 Remote Access Security 
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. 
All publications and patent applications mentioned in this specification 
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. 
##SPC1##