Note: Descriptions are shown in the official language in which they were submitted.
2080807
EXPENSE MANAGEMENT SYSTEM
This is a divisional o~ P~plication ~o. 2,036,172 filed on F~bruary 12, 1991.
FIELD OF THE INVENTION
This invention relates in general to expense
management systems, and more particularly to a system for
controlling user access to a device, such as a
photocopier, PABX, facsimile machine, etc.
BACKGROUND OF THE INVENTION
Present day corporate and professional
organizations, such as law offices, are known to
experience charge recovery problems due to misuse of the
various "office expense" charge codes available to
employees when using the photocopiers, facsimile
machines, PABX systems, etc. In particular, usage of
such devices which should be charged to a particular
client or department are often charged to the "office"
file codes because the user could not remember the proper
client file code at the time, or because the file code
had not been assigned by the accounting department yet,
or simply out of convenience. Whatever the cause,
thousands of dollars are lost every month due to such
misuse.
In addition, file codes are often incorrectly
entered such that device usage charges accrue to
incorrectly listed clients or matters.0
one approach to overcoming these problems involves
the use of a terminal controller connected to the device
(e.g. photocopier) which monitors the recovery
performance of each user and prints this information in
the form of a report. The data is not stored within the
system after printing, nor is it accessed or interrogated
as a basis for making decisions regarding a user's
request for device usage. The printed analysis of this
prior art approach was utilized to persuade user's that
2080807
they should make a greater effort to locate the
appropriate file code. As a further option according to
this prior art approach, the user was given the
opportunity to charge a particular job to a limited
length description which could be corrected later.
One problem with such prior art terminal controllers
was that single purpose function keys were employed to
allow a user to trigger a particular function (i.e.
"end", "next account", "extend time out". etc.) while a
"linear layout" alphabetic keypad was used to minimize
the dimensions of the terminal. However, because there
is typically limited space at most device stations (e.g.
photocopiers) and such space is usually required as a
working surface, it is desirable that the size of the
terminal be kept to manageable dimensions, limiting the
number of keys and size of the keyboard.
A further disadvantage of the prior art linear
layout alphabetic keyboard is that the layout effectively
eliminates any text interplay between the terminal and
the user. This can impact on the number of options
available through the terminal for persuading a user to
maximize charge recovery usage of the device.
One prior art approach to minimizing the number of
keys required on the terminal, was to assign a dual
purpose to the single purpose function keys, in which
second assigned purpose is only accessible at a
predetermined point in the job usage process. This
process is referred to in the prior art as "stacking".
Often, the second purpose or function of the stacked key
is not labelled, and such prior art systems do not prompt
to remind the user of the option that the function key
represents at that particular moment in time (i.e. there
is no instruction to the user by way of a screen
display). Thus, the practice of "stacking" functions on
3 2080807
keys is limited in the prior art to specific
applications. The user must remember when and how to
access these second functions, which has been found to be
inconvenient.
An alternate design of terminal allows for most
functions to be performed by combining one basic function
key with another alpha or numeric key in order to trigger
the function (mnemonics are often employed; "# plus E"
for extend time out, etc.). Although this approach saved
space, the users have found that it is difficult to
remember and confusing to employ a long list of options
based on mnemonics multiple keystroke codes.
SUMMARY OF THE INVENTION
According to the present invention, a system is
provided for controlling user access to a device to
address the charge recovery problem discussed above. The
system maintains a list of valid file codes on a system
wide basis (i.e. across a plurality of terminals
connected to respective devices) where such list contains
both the client name and the matter "Re:" line
description in addition to the file code itself (prior
art systems offer the ability to store a valid list of
file codes but no accompanying text).
The system also displays the client name and/or the
"Re:" line matter description to the user on the screen
of the particular terminal being used. The system
recognizes a non-recoverable (i.e. non-billable) file
code and performs an analysis of historic information on
a user-by-user basis in order to determine each users
recovery performance, wherein the analysis is based on
data received from all terminals of the system.
The system stores the result of the above discussed
2080807
analysis and refers to it for the purpose of making a
decision regarding a users request for usage of a device.
In addition, the system may be programmed to store
predetermined recovery performance standards on a system
wide basis (i.e. for all terminals and for all users).
Alternatively, the system may be programmed to establish
alternate sets of recovery performance standards for
individual users or classes of users (for example, a
class of users can be interpreted as a department).
This system recognizes a user's request for device
usage which violates that users performance standards and
intercedes or interferes with usage of the device is such
circumstances by applying various "user sanctions"
designed to increase the users awareness of the expenses
that they are charging to the office (and therefore their
sense of responsibility), request that the user consider
charging a client for the device usage, remind the user
of the options available for charging a client instead of
the office, slowing the users access to the device in the
event that the user persists in charging excessive
amounts to the "office" account, gathering information
regarding what the user is charging to the "office"
account, or denying access to the "office" account.
In addition, the system may be programmed to control
the type and quantity of user sanctions which may be
applied to a specific user or class of users once the
user has exceeded his or her recovery performance
standard.
The system can be programmed to allow the user to
search for a client file by client name and matter
keyword searches of the file code database and to view
all of the entries in a "matched" list that is generated
by the search procedure by selecting "next" or "previous"
keys of a control terminal in accordance with the
2080807
.
preferred embodiment of the invention, and viewing the
client name and/or matter description on a screen of the
control terminal.
The system also allows the user to charge usage of
the device to a manually entered description otup to
thirty characters in length and to assign a maximum
number of such description per unit time to a user or
class of users.
The system of the preferred embodiment of the
invention is programmable to edit the manually enterred
descriptions to reflect the appropriate file codes, which
can be provided by users after the fact.
The system of the invention may be programmed to
recalculate the user recovery performance analysis to
take into account any manually entered descriptions which
were subsequently charged to a valie client file code.
Where the device to be used is centrally located and
administered by a clerk (e.g. copy center photocopier),
the system of the invention can also be control access to
the device by means of a clerk access password, and by
having the clerk search for the p~o~er requesting user's
idenfication code by way of an alpha user search
capability, This allows copy jobs performed in the
center to be tracked to the appropriate user, thus
preserving the integrity of the user recovery analysis.
The system can be programmed to deted instances
where a user has used the manually entered description
opinion to charge "office" expenese~, thereby
circumventing the user sanctions.
The system is capable of removing the privilege of
2080807
charging jobs to a manually entered description in
instances where a user has shown a tendency to use this
option to circumvent the user sanctions. The system also
informs the user of the privilege suspension and the
reason of the suspension by means of the controller
terminal screen display.
In addition, the system generates an auditory signal
to indicate to the user that he or she has exceeded
acceptable recovery performance standards.
By displaying the client name and/or "Re" line of
the matter description to the user once they have logged
on under a file code, the system of the present invention
ensures that users do not charge the wrong client. The
system may also be programmed to employ an optional
"confirm account" screen and to inhibit enablement of the
device until after the user has reviewed the client
and/or "Re:" line, and confirmed his or her choice.
The system may also be programmed to restrict a
certain user or class of users from accessing a certain
account or class of accounts.
The terminal controller of the present invention
employs a unique keyboard and screen layout which
accommodates the implementation of a large list of use
options, an intuitive user interface, a QWERTY layout
keyboard (for text entry), and a terminal size which does
not violate accepted industry norms.
The keyboard design of the preferred embodiment
employs four function keys to trigger a vast number of
user functions. These keys are located directly below
the screen of the terminal, and the bottom line of the
screen is devoted to labelling the functions of the keys
at each stage of the device job and according to each
- 7 20B0807
users identity and usage patterns. In other words, the
function keys take on differency functions depending on
the user, their position in the job, and that users usage
patterns.
The screen of the controller terminal is also angle
adjustable by the user to faciliate the juxtaposition of
the keys next to their respect labels regardless of the
users height.
Various aspects of the invention are as follows:
A system for assisting user access to a plurality of
account codes for the purpose of billing or cost
accounting for usage of one or more devices, comprising:
a) means for storing said plurality of account
codes and associated account names;
b) means located at said one or more devices and
coupled to said means for storing, for displaying said
plurality of account codes and associated account names
to said user;
c) means located at said one or more devices and
coupled to said means for storing and said means for
displaying, for searching said plurality of associated
account names prior to said user access for any one of
said account names associated with said account codes to
be used for charge allocation of said usage of said one
or more devices, wherein said means for searching further
comprises means for receiving a user entered string of
characters representing a position independent portion of
a predetermined account name to be searched, means for
comparing said string of characters to successive ones of
said plurality of associated account names, means for
creating a list of predetermined ones of said account
codes in which said string of characters appears in said
associated account names, and means for said user to
select a predetermined one of said account codes from
8 2080807
said list for charge allocation of said usage of said one
or more devices.
A method for assisting user access to a plurality of
account codes for the purpose of billing or cost
accounting for the usage of at least one device,
comprising the steps of:
storing the plurality of account codes and
associated account names;
displaying at the at least one device a message
prompting the user to charge the usage of the at least
one device to any one of the account codes;
displaying at the at least one device at least
selective ones of the plurality of account codes and
associated account names to the user; and
searching the plurality of associated account names
for any one of the account names associated with the
account codes to be used for charge allocation of the
usage of the at least one device.
A system for assisting user access to a plurality of
account codes for the purpose of billing or cost
accounting for the usage of at least one device,
comprising:
a storage device to store the plurality of account
codes and associated account names; and
a computing device coupled to the storage device and
having an output device to indicate to the user at the at
least one device (i) a message prompting the user to
charge the usage of the at least one device to any one of
the account codes; and (ii) the plurality of account
codes and associated account names, said computing device
further includes a program element to search the
plurality of associated account names for any one of the
account names associated with the account codes to be
used for charge allocation of the usage of the at least
one device.
8a 2080807
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block connection diagram of an expense
management system according to the preferred
embodiment of the invention.
FIG. 2 is a block electrical diagram of a device
controller terminal in accordance with the
system of the preferred embodiment.
FIG. 3 is a m~ch~nical drawing of the device
controller terminal of FIG. 2.
FIG. 4 is an electrical diagram of a communications
network forming part of the system according to
the preferred embodiment.
0 FIG. 5 is a block diagram of the elements comprising a
central computing device forming part of the
system according to the preferred embodiment.
FIG. 6 is a flowchart of a first program for
2080807
controlling operation of device controller
terminal.
FIG. 7 is a tree diagram representing the menu
structure of a second program which provides
facilities for setting and changing registers
and data in memory.
FIG. 8 is a flowchart of a third interrupt signal
processing program according to the preferred
embodiment.
10 FIG. 9 is a flowchart of a fourth program for
receiving and transmitting signals present on
the communications network of FIG. 4.
FIG. 10 is a flowchart of a fifth program to accept an
account code and process user options in
selecting an account code.
FIG. 11 is a flowchart of a sixth program which
performs an account class usage analysis and
stores the results.
FIG. 12 is a flowchart of a sevnth program which
performs the operations required to implement a
"LAST ACCOUNT" feature of the system according
to the invention.
FIG. 13 is a flowchart of an eighth program which
administrates usage of an "OVERRIDE" class of
accounts according to the system of the present
invention.
FIG. 14 is a flowchart of a ninth program to perform
search operations on an accounts table of the
system according to the invention.0 FIG. 15 is a flowchart of a tenth program that
validates a selected account code, and routes
program control to an appropriate point
depending upon the results of the validation
operation, according to the invention.5 FIG. 16 is a flowchart of an eleventh program that
provide various warnings and sanctions when a
user has exceeded the allowable usage limit of
20808~7
the non-billable class of accounts.
FIG. 17 is a flowchart of a twelth program which
performs operations which are required to
precede the beginning of usage of a device
under control of the system of the invention.
FIG. 18 is a flowchart of a thirteenth program which
enables the device, monitors the usage of the
device, and disables the device when the user
is finished.0 FIG. 19 is a flowchart of a fourteenth regularly
executed program according to the preferred
embodiment.
DESCRIPTION OF THE PREFERRED EMBODIMENT5
With reference to FIG.1, an expense management
system is shown comprising a central computing device (1)
connected via a communications network (2) to a plurality
of device controller terminals (3). The central
computing device (1) is also connected to a host
accounting system (not shown) in which client account
files are stored. A plurality of devices (4) (such as
photocopiers, facsimile machines, PABXs, etc.) are
connected to respective controller terminals (3) via
respective cables (6).
Although the principles of the present invention may
be applied to photocopiers, facsimile machines, PABXs or
other devices for which disbursement control is desired,
the preferred embodiment described herein relates to
photocopier control.
The cabling arrangement (6) typically varies among
different models and manufacturers of photocopier, and is
normally connected to an external device harness provided
by the manufacturer of the photocopier (4). Each of the
central computing device (1), controller terminals (3)
2080807
11
and photocopiers (4) receive AC power from a 120VAC 60Hz
power source (5), in a well known manner.
According to the invention in its broadest aspect,
the photocopier controller terminals (3) control usage of
the photocopiers (4) and monitor and store the details of
such usage.
The purpose of the central computing device (1) is
to collect the usage information from each controller
terminal (3), to analyze the usage information from all
controller terminals (3), to provide the controller
terminals (3) with user, account, and configuration
information, and to provide the administrator or owner of
the system a wide variety of means of using the
information that has been accumulated.
In the description of the preferred embodiment
below, references to detailed elements of the central
computing device (1), communications network (2) and
photocopier controller terminal (3) will incorporate
prefixes (1- ), (2- ) and (3- ), respectively.
Referring now to FIG. 2, an electrical block diagram
is shown of controller terminal (3), according to the
preferred embodiment. Electrically, the controller
terminal (3) comprises a power supply (3-1, 3-5), a
microprocessor (3-17), static RAM storage (3-9, 3-32)
with battery back-up (3-6, 3-7, 3-34, 3-12), a ROM
program storage (3-30), a keyboard (3-24) for user input,
a backlit LCD display (3-26), a real time clock (3-8), a
serial RS-422 interface (3-13, 3-14, 3-15), and circuitry
(3-3) to allow control and monitoring of a photocopier
(4).
The power adapter (3-1) connects to a 120 VAC 60Hz
source and provides 9 VDC to the voltage regulator
2080807
circuit (3-5). The voltage regulator circuit (3-5) uses
conventional linear power supply design that is well
understood to provide 5 VDC with a maximum current of
500mA. The regulated output of the voltage regulator
circuit is delivered through conductors to all devices
comprising the controller terminal (3) which require
electrical power. There are two circuits (3-34, 3-12)
that are used to monitor the power for the purpose of
protecting the contents of memory devices (3-9, 3-32) and
the real time clock (3-8) from corruption during power
loss or brownout, and to provide an interrupt signal (3-
33) in such a situation. Each of these power monitor
circuits (3-34, 3-12) have 3V batteries (3-6, 3-7) which
the power monitors use to provide voltage to the static
RAM (3-9, 3-32) and clock (3-8) to ensure data and
timekeeping integrity during a power loss situation
(blackout, brownout or surge, during service, or
transportation).
According to a successful prototype of the
invention, microprocessor (3-17) is a NEC V20 16-bit
internal CPU with an 8-bit external data bus, 1 MByte RAM
addressing, and 64 KByte I/0 space addressing. The data,
address, and control lines are collectively labelled as
(3-16). The block labelled (3-17) also includes the
support logic, memory and I/0 address decoding, and
buffering devices to provide the interface to the devices
to which the signals (3-16) are delivered. The design of
the support logic and buffering system is conventional
and is therefore not described in detail here. The
microprocessor block (3-17) has an interrupt request
signal (3-18) from the serial interface circuit (3-13).
The serial interface circuit (3-13) comprises an
asynchronous serial interface chip (82C50), an RS-422
driver chip, and an RS-422 receiver chip. The serial
interface circuit connects to the network (2) through
2080807
-
13
four conductors. The two receive conductors (3-14) are
connected to the differential inputs of the RS-422
receiver. The two transmit conductors (3-15) are
connected to the differential outputs of the RS-422
driver. The RS-422 driver is further controlled by the
transmit enable signal (3-21) from the serial interface
chip (3-13). This signal controls the RS-422 driver to
enable transmission or put the driver in a high impedance
state. The TTL logic level signals from the transmit and
receive chips are connected to the serial out and serial
in of the asynchronous serial interface chip.
Further, the serial interface circuit (3-13) has a
built-in interrupt signal handler which is conventionally
used for RS-232 and modem handshaking signals. In the
preferred embodiment of the invention however, the built-
in interrupt signal handler of the serial interface
circuit (3-13) is used to handle all interrupt signals
within the controller terminal (3). The sources of
interrupts are; copy pulse interrupt (3-19), serial
transmitter empty (internally generated), serial byte
received (internally generated), and power fail interrupt
(3-33). Upon detection of any of these signals, the
circuit (3-13) will generate an interrupt request signal
(3-18) to the microprocessor block (3-17). The interrupt
signal (3-18) will remain active until the microprocessor
services the interrupt.
The serial interface circuit (3-13) provides two
additional signals. One signal is used as a logical
photocopier enable signal (3-20) which goes to the
photocopier interface circuit (3-3). The second output
signal is connected to an audible alarm (3-35).
The keyboard scan latch (3-22), the keyboard sense
buffer (3-23), and the keyboard switch matrix (3-24) are
the electrical elements that comprise the user input
208~807
.
14
system. The keyboard scan latch is an 8-bit register
whose contents are controlled by the microprocessor (3-
17) through the bus and control signals (3-16). The
keyboard sense buffer (3-23) is an 8-bit addressable
buffer which can be read by the microprocessor (3-17)
through the bus and control signals (3-16). The keyboard
switch matrix (3-24) is of conventional design having 8
column drive lines connected to the keyboard scan latch
(3-22), forty-three closure keyswitches across the
matrix, and eight row sense lines connected through
signal diodes to the keyboard sense buffer (3-23). This
electrical design allows for software testing of each
keyswitch for an open or closed condition.
The controller terminal 3 contains an LCD display
(3-26) that is controlled through 8-data lines and 2
control lines which are provided by the parallel
interface chip (82C55) (3-25). The LCD display is a
backlit 4 lines by 40 character device, with built in
controller. The built-in controller allows simple
command based control of the display. Further, there is
an electrical circuit which allows the microprocessor to
control the power to the blacklight device (3-29) of the
LCD display. One bit of the parallel interface chip (3-
25) is connected to a transistor (3-27) which acts as a
switch for supplying power to the voltage inverter (3-
28). This voltage inverter (3-28) converts 5 VDC to
approx. 90 VAC. It is this 90 VAC that actually makes
the EL backlighting panel (3-29) of the LCD display
illuminate.
The photocopier interface circuit (3-3) is connected
to the controller terminal main enclosure (3-2) through
the copier interface cable (3-4). The copier interface
cable (3-4) carries the photocopier pulse (3-19) and
photocopier enable (3-20) signals through conductors.
The photocopier interface circuit (3-3) is further
2080807
connected to a external device harness of a photocopier
(4) by cabling arrangement (6). This cabling arrangement
(6) carries signals in the form indigenous to the
particular brand/model of the photocopier.
The copier interface (3-3) provides connections for
creating the following types of photocopier enable
signals; 1) contact closure (closed circuit between two
conductors), 2) contact open (open circuit between two
conductors), 3) positive logic signal (+-5 VCD signal
across two conductors), 4) negative logic signal (0 VDC
signal across two conductors). The exact form of signal
generated is dependent on the cabling arrangement and the
logical level of the signal (3-20).
The photocopier pulse detection section of the
copier interface circuit (3-3) provides a low pass RC
pulse shaper, current limiting resistors, and connections
for a variety of signal types. Provision is made for the
following types of pulses from the photocopier 4; 1)
contact closure signal (closed circuit between two
conductors), 2) contact open (open circuit between two
conductors), 3) positive logic pulse (any voltage
potential between 5V and 220V (ac or dc through
rectification) between two conductors), 4) negative logic
pulse ( <5v (ac or dc) between two conductors). The
output of this circuit represents the logical copy pulse
signal (3-19). As discussed above, these provisions are
implemented through changing the cabling arrangement (6)
to the photocopier external device harness. The details
of the electronic circuitry are not discussed since the
nature of these signals and controls would be understood
by a person skilled in the art.
Referring now to T~BLE I, along with FIG. 2, the
memory elements of the controller terminal (3) will be
described.
2080807
/~
Transa~1ion 90000 - EOOOO
Record Table
T-1 ~
Free Memory
T-2
T-18 5Unsoned Accounts
Account Record
Table
T-3
3-30
3-32
User Record
Tabie T-1' ~ Command P-ocessor
T-4
Appication
User/Account T-1G
T-S Re~ t, klion Table E 1 500
Special User Bios
T-6 ~Prking Tables T-17
T 7 Special Accoun~ EOOOO
Pricing Tables
T-~ ~Default Prking Tables
System Defaults
n~9~ t~ ~And
T-9 Oper~liona: Pala~
20000
T-10 ~Program Stack 8000
Storage Area For
T-11 ~Current List In Search
Background Working
T-12 ~Variables ~ 3 9
T-13 Forground Working
Variables
T-1~ ~Interrupt Vectors
0000
Memory
Address
(HEX)
2080807
Iq
There are three separate memory areas in the
controller terminal (3). These are: 1) system RAM (3-9),
2) data and configuration RAM (3-32), and 3) program
storage ROM (3-30). The system RAM (3-9) is a 32KByte
chip being accessible at memory address 00000h to 07FFFh.
This system RAM (3-9) is provided with battery (3-6)
backup power from the power monitor circuit (3-34) when
there is no power from the power supply (3-3).
The data and configuration RAM (3-32) is an area of
RAM that is variable in size from 32 to 768 KBytes
depending upon how many chips, and what type, are
installed. The RAM (3-32) receives address and decode
signals (3-31) from the power monitor and decoder circuit
(3-12), in a well known manner. This RAM starts at
memory address 20000h and can continue linearly up to
DFFFFh, and has similar battery back-up as described for
the system RAM (3-9).
The RAM (3-32), power monitor (3-12), and the backup
battery (3-7) are all contained on a separate circuit
board within the controller terminal main enclosure (3-
2). The purpose for this is to provide a means of
removing the RAM for service or device swap purposes,
while still maintaining the integrity of the data.
The last region of memory in the controller terminal
(3) is the program storage ROM (3-30). This ROM can be a
32, 64, or 128 KByte device and is accessible starting at
memory address EOOOOh. The ROM device is installed into
a chip socket to allow easy upgrades to the program.
Referring again to TABLE I, the usage of the various
sections of memory is shown. The system RAM (3-9) is
broken into five general areas as used by the software
means. These five areas are, from low memory address to
2080807
high memory address; 1) the interrupt vector table (T-
14), 2) the foreground working variables (T-13) used by
the BIOS program (T-17) and application program (T-16),
3) the background state and working variables (T-12) used
by the command processor program (T-15), 4) a storage
area used to maintain the current list (T-ll) in
interactive search operations, and 5) the system stack
(T-10) as used by the microprocessor and various
programs.
The removable data and configuration RAM (3-32)
contains a number of areas, so they will be discussed in
two sections; 1) configuration and programming storage
areas, and 2) local database storage areas.
The configuration and programming section is broken
into five areas, they are; 1) system defaults registers
and operational parameters (T-9), 2) default pricing
table (T-8), 3) special account pricing (T-7), 4) special
user pricing tables (T-6), and 5) user/account
combination restriction table (T-5).
The local database storage section is divided into
five areas, they are; 1) the user record database (T-4),
2) the sorted region of the account record database (T-
3), 3) the unsorted region of the account record database
(T-18), 4) the free (unallocated) memory region (T-2),
and 5) the transaction record database (T-1).
The last section of memory in the controller
terminal (3) is the program storage ROM (3-30), which is
divided into three basic areas corresponding to the
associated programs. These three areas are; 1) the BIOS
program (T-17) providing control over the electrical
components of the contr,oller terminal (3), 2) the
foreground application program (T-16) which implements
the interactive process with the user, and 3) the
20808a7
-
background command processor program (T-15) which
processes commands and communications on the
communications network (2). Further discussion of the
specific registers, data structures, programs, and how
they are used will follow in the description of the
programs (T-15),(T-16) and (T-17).
FIG. 3 shows a diagram of the appearance of the
controller terminal (3). The controller terminal
enclosure (3-2) is represented in actual proportion,
indicating the exact positioning of the keyboard keys (3-
24) and the LCD display (3-26). The LCD display (3-26)
in this drawing is also divided into a character position
matrix, indicating the exact position in which characters
being displayed to the screen will appear. Further, a
side view is provided to illustrate the ability of the
display portion of the enclosure to articulate to about
70 degrees from horizontal. Also displayed in this
diagram are the connector and cable that connect the
controller terminal (3) to the communications network
(2). The copier interface cable (3-4) and connectors are
also shown in their correct position, and connecting
ultimately to the copier interface circuit (3-3).
The layout of the keyboard (3-24), the positioning
of the function keys F1 to F4 of the keyboard (3-24), the
size of the display area and the positioning of the LCD
display (3-26), are designed to facilitate easy user data
input. In particular, the layout of the keyboard in a
Q~ organization results in a familiar medium for user
data input (both numeric and alphanumeric), as compared
to other conventional (linear layout, numeric only,...)
designs for photocopier control terminals. The QWERTY
layout represents a significant improvement since it is
so widely known and most office staff are familiar with
it, reducing confusion and stress when using the
invention. The QWERTY region of the keyboard has the
2080807
digits 1 through 0 on the top row, the full English
alphabet on the bottom three rows, a "<-" key in the
third column from the right, a "->" key in the second
column from the right, and a double sized "Enter" key
straddling the two bottom rows in the rightmost column.
Each key is made with a full travel positive response
keyswitch and a sculpted keycap with the key legend on
it. This design is felt to provide the user with the
highest degree of comfort in keyboarding.
The keys labelled 1 to 0 and A to Z are interpreted
by the BIOS software (T-17) as representing the symbol on
the ledged (ie pressing the "A" key is interpreted as the
letter "A"). The "<-" key is interpreted by the BIOS
software as a backspace, for deleting the previously
entered character if there is one. The "->" key is
interpreted as a space character, much like the space bar
on a typewriter. The "Enter" key is interpreted as a
terminator for the current sequence of keys that have
been entered, in accordance with the convention followed
by many computer systems.
The other region of the keyboard (3-24) is the line
of four function keys, between the QWERTY region and the
LCD display (3-26). These function keys are further
positioned in such a way that they line up with the LCD
display (3-26) character positions. These four keys are
labelled Fl, F2, F3, F4 and have no inherent meaning or
function on their own. They do have a meaning and
function when coupled with the messages appearing on the
LCD display (3-26) as a result of the application program
T-16. By displaying the current meaning of each function
key on the bottom line of the LCD display so that the
current meaning lines up directly above the key, and
configuring the application program to react to each
function key with the meaning associated with it at any
given state of the application, an intuitive method of
- ~LI 2080807
accessing special functions is achieved. Further,
conventional designs relying on dedicated special
function keys are limited in the number of special
functions by the number of keys they can use for those
special functions. The approach taken by the preferred
embodiment of the invention provides an effective means
of providing the user with clear indications of those
functions available to him/her at any time, and how to
trigger them.
It is this function key arrangement and the general
"user-friendliness" that are the prime motivations behind
the positioning of the keyboard and display, and for the
size (character capacity) of the display. The use of
dynamic function keys makes it possible to implement a
wide variety of functions/features discussed in greater
detail below, whereas conventional dedicated function
keys or mnemonic function codes would be overly
cumbersome to be practical. Further description of the
use and function of the function keys will be discussed
in the description of the various controller terminal
programs in which the function keys are utilized.
Referring now to FIG. 4, the communications network
will be described. The network (2) is used to transfer
data to and from each controller terminal (3) and the
central computing device (1). This network follows the
electrical characteristics of the RS-422 stAn~Ard, using
asynchronous serial communications. The serial bit rate
on this network ranges from 2400 Baud to 34.8 KBaud in
the preferred embodiment.
The communications network (2) uses two twisted
pairs of conductors to carry the electrical signals,
where one pair (2-1, 2-2) is used for transmission from
all of the controller terminals (3) to the central
computing device (1), and the other pair (2-3, 2-4) is
- 2080807
used to carry the signals from the central computing
device (1) to all of the controller terminals (3). This
results in a master/slave network configuration, where
the central computing device (1) functions as the master,
and the controller terminals (3) function as slaves.
Mechanically, the communications network is
connected to the central computing device RS-422
interface (1-9), by a DB-25 connector. FIG. 4 shows the
Rx+ (2-5), Rx- (2-6), Tx+ (2-7), and Tx- (2-8) conductors
connected to the central computing device. The
conductors coming from this connection must the travel to
each controller terminal device. The network layout has
few restrictions in terms of topology, the connections
can be daisy-chained, star configuration, or back-bone,
so long as the electrical connections are maintained.
FIG. 2 shows the network in a back-bone topology,
where the conductors (2-9, 2-10, 2-11, 2-12) to a
particular controller terminal (3) are connected to the
back-bone (2-1, 2-2, 2-3, 2-4) at a junction point (2-
13). The mechanical connection to the controller
terminal of the conductors (2-9, 2-10, 2-11, 2-12) is
made through a DE-9 connector. It should be noted that
the diagram shows the Rx (2-1, 2-2) pair of the central
computing device (1) connected to the Tx pair (2-11, 2-
12) of the controller terminal (3), and that the Tx pair
(2-3, 2-4) of the central computing device (1) is
connected to the Rx pair (2-9, 2-10) of the controller
terminal (3). This is consistent with the master/slave
configuration so that whatever the master (1) transmits
is received by all slaves (3), but only one slave (3) may
transmit at any given time to the master (1), otherwise
an electrical conflict will occur and the signal will be
corrupted.
Turning now to the central computing device (1) and
~ 2û80807
FIG. 5, the central computing device (1) is shown in the
form of an IBM PC/XT/AT compatible computer using the MS-
DOS operating system version 3.0 or higher. This family
of computing devices and the peripheral systems are
widely understood, so a detailed description of this
device will be omitted. The central computing device (1)
is mounted within a computer main chassis (1-1). The
computing device (1) must have the following
capabilities/peripherals; 1) CPU board and 640 Kbytes
RAM, 2) Keyboard (1-2), 3) CRT or other display device
(1-3), 4) Hardcopy device (1-4), 5) Floppy disk system
(1-5), 6) Video or other display interface (1-6), 7)
Hardcopy device interface (1-7), 8) Hard Disk (1-8)(min
20MByte capacity recommended) 9) RS-422 serial interface
(1-9), and 10) Power supply (1-10).
The hard disk (1-8) is used to store the programs
and data that are executed by the central computing
device (1). TABLE II is a memory storage map for the
computing device (1).
Tfi~L~ 11 2080807
USER RECORDS DATABASE
U-7
ACCOUNT RECORDS DATABASE
U-6
COPY TRANSACTIONS DATABSE
U-5
VALID ACCOUNTS FILES FROM HOT ACCOUNTING
SYSTEM
U-4
TRANSACTIONS WAITING TO BE POSTED TO HOST
ACCOUNTING SYSTEM
U-3
1-8
SDS PROGRAM 8 CONFIGURATION FILES
TEMPORARY FILES TOO
U-2
OTHER STORAGE AREAS OF FIXED DISK:
- OPERATING SYSTEM
- OTHER PROGRAMS AND DATA
- SYSTEM FILES
- UNUSED STORAGE SPACE
U-l
2080807
The operating system, system files, unused storage,
and any programs generic to the computing device itself,
are represented by the section (U-1) of TABLE II.
The application programs required to implement the
system of the invention are stored in a section labelled
(U-2). This storage area (U-2) also contains a variety
of configuration and support files used by the
applications programs.
The remaining sections represent various databases
that are maintained by the system of the present
invention. These databases include; 1) a file containing
photocopy transactions that have been collected and
verified by the system and which are ready for the host
accounting system (not shown) to import, 2) a collection
of files supplied by the host accoun~ing system
containing account code information (U-4), 3) an indexed
database of all photocopy transactions (U-5) monitored
and recorded by the system, 4) an indexed database of all
the current valid account codes (U-6) with details for
each account, and 5) an indexed database of all users (U-
7) allowed access to the photocopiers through the system
including account class usage analysis results.
A further description of the data structures which
are used and their operation will follow in the
discussion of the applications programs which run on the
central computing device.
Preliminary to a discussion of the controller
terminal program, a description will be made of the "low-
level" BIOS program (T-17) in TABLE I, which is used
extensively by the "high-level" application programs (T-
16). The BIOS program implements the majority of thecontrol and monitoring tasks over the electrical
circuitry in the controller terminal (3). The BIOS
20808~7
provides functions in five groups divided by the systems
being controlled: 1) Keyboard (3-24) scanning, 2) LCD
display (3-26) control, 3) Real time clock support, 4)
Copier interface support, 5) Beeper (3-35) control. Each
of these function groups provide several services
specific to the group.
There are three services performed by the keyboard
(3-24) BIOS function group, as follows:
1) The first service is referred to as the
"keypressed service", and is a function which determines
whether a new key has been pressed. This service is
implemented by scanning the keyboard keyswitches and
comparing the result with the result of the previous
scan. Any new contact closures that have been closed for
a sufficient period (called the debouncing delay) are
then considered valid keypresses, and this service
returns indicating that a key has been pressed, otherwise
it returns a no key pressed indication.
2) The second service is referred to as the "get
character service", which attempts to read a single
keystroke from the keyboard. This service continually
calls the keypress service to determine if a key has been
pressed. The service will terminate in one of two
conditions: 1) a key was pressed, in which case a number
representing the key is returned, or 2) no key was
pressed during the system-wide timeout period which is
stored in (T-9).
3) The third service provides a string entry
function. This service is called with the following
parameters: 1) security "on" or "off", if "on" the
service causes a "*" tQ appear instead of the character
typed, and 2) the maximum number of characters which are
allowed to be typed. This service uses the previous
2080807
service to get characters form the keyboard and echo them
to the display as they are typed. It also interprets the
"<-" (backspace) key and updates the display accordingly.
This service always returns all of the characters typed
(excluding those that were deleted with backspace), and
the number of characters typed. It further provides a
return code indicating why the entry was completed. The
possible return codes are: 1) system wide timeout elapsed
before "Enter" or a function key was pressed, 2) "Enter"
was pressed, or 3) a function key was pressed.
An auxiliary function provided by the "keypressed
service" is that it turns on the EL backlighting panel
behind the LCD display whenever a key is pressed.
Control over the EL panel is implemented by accessing the
parallel interface circuit and activating the bit that is
connected to the EL panel switch transistor. Further,
the "get character service" turns off the EL backlighting
panel when a timeout occurs, again by accessing the
parallel interface circuit. These two additional
functions built into the keyboard BIOS functions provide
a means to greatly improve the lifespan of the EL
backlighting panel by keeping the panel off when the
system is not in use, but turning it on as soon as a key
is pressed. The brightness half-life of current
technology EL panels is about 4500 hours on-time, which
results in rapid deterioration of the EL backlighting
system, rendering it effectively non-functional within
two years. With the system according to the present
invention the effective lifespan of the EL panel can
usually be improved by a factor of 3 to 20 times
(depending upon usage frequency and timeout period).
There are three services provided in the LCD display
BIOS function group. All of these services are
implemented by controlling the parallel interface circuit
(3-2S) to deliver commands to the LCD display (3-26).
2080807
The first service allows the current position of the
cursor to be set. The cursor is an abstract pointer in
the display area indicating where the next character to
be written should go. The second service provides for
displaying an ASCII string to the current cursor position
of the display. The last service provides a clear
display function which blanks the display and puts the
cursor at the top leftmost character position.
There are only two services provided by the real
time clock BIOS function group. The two functions are 1)
set current date and time,and 2) get the current date and
time. These services are implemented by accessing the
real time clock circuit (3-8) and reading or setting the
appropriate registers.
The photocopy interface BIOS function group provides
four services. Two of the services are used to enable or
disable the photocopier. These two services simply
access the serial interface circuit (3-13) and set the
appropriate register to provide a logical enable or
disable signal. A third service provides a means of
clearing the current page count monitored from the
photocopier. The last service returns the current count
of the number of photocopies detected.
Two services are provided to control the audible
alarm or beeper (3-35) in the controller terminal(3).
One service causes a steady tone beep to be generated,
and the other produces a rapidly oscillating tone. The
first beep is usually used to indicate an error, and the
second is used to try to attract the user's attention.
FIG. 6 is the first program flow diagram for the
program stored in ROM (3-30). The entry point for the
program (A) is located by the microprocessor (3-17) when
power is applied to the controller terminal (3) and
2080807
.
~q
program execution begins in the BIOS program (T-17).
Step (A-l) performs the system initialization which
includes self diagnostics, memory sizing and testing,
set-up of the interrupt vector table (T-14), clearing of
the LCD display (3-26), and clearing of the keyboard (3-
24) state.
Upon successful completion of the system
initialization (A-l), the command processor program (T-
15) is activated (A-2) by clearing all data buffers of
the communications network (2), and setting the command
processor program (T-15) state to idle in the background
working variables area (T-12).
Various registers in the system defaults and
operational parameters area (T-9) are then verified for
valid settings (A-3). If the current settings are not
valid, then the entire contents of the data and
configuration RAM (3-32) are reset to default values (A-
4), and program flow is directed to the entry point (A).
This resetting to default condition arises when a
controller terminal (3) is first powered-up or when the
RAM (3-9) is erased or corrupted.
If, however, the verification (A-3) is successful,
then flow control continues to (A-5) which represents an
entry into the application program (T-16). The display
(3-26) is cleared and the main user code entry screen is
displayed with the following function key assignments; Fl
= HELP, F2 = STATUS, F3 = INFO, and F4 = CLEAR.
The system then waits for the user to enter his/her
user code (A-6), or to select a function. If the "get
string service" has experienced a timeout, then program
flow is returned to (A-5).
2080807
-
3~
If a key has been pressed, then the program checks
(A-7) if Fl (HELP) was pressed, and if so displays the
help message (A-8) for this screen and then returns
control to (A-5).
The program then checks (A-9) for F2, and if F2
(STATUS) has been pressed, then the Status screen is
displayed (A-10) until another key is pressed, otherwise
program flow continues to (A-ll).
The Status screen displays the following
information; 1) the current date and time, 2) the current
state of the command processor, 3) the number of users in
the local user database, 4) the number of accounts in the
local accounts database, 5) the number of current
transactions in the local transaction database, and 6)
the percentage free memory and the total capacity of the
data and configuration memory.
The F3 key is tested at (A-ll), if F3 (INFO) has
been pressed, then control is passed to (A-12), otherwise
program flow continues to (A-13).
The INFO screen (A-12) displays the following
information until a key is pressed; 1) controller
terminal serial number, 2) controller terminal software
revision number, 3) name assigned to the particular unit
(3), 4) the communications network address of this unit,
and 5) the copyright notice.
Use of the F4 key is then checked (A-13), and if F4
(CLEAR) has been pressed then program flow is transferred
to (A-5), otherwise program flow continues to (A-14).
At (A-14) the program will have determined that no
function key has been pressed, so a string may have been
entered as a user code. If the length of the string
2080807
..
~1
entered is zero, then program flow returns to (A-5),
otherwise it continues to (A-15).
The entered string is compared with the copier
access code stored in memory area (T-9), if it matches
the interactive user search program (A-16) is called (as
discussed in greater detail below), otherwise flow
continues to (A-17).
The register that contains information as to whether
normal user code access (stored in memory area (T-9)) is
allowed, is then checked. If user code access is allowed
then program flow continues to user validation (A-19),
otherwise the invalid user code screen is displayed (A-
18). The purpose of the user code access control (A-17)
is to provide a mode of operation where only photocopier
operators that know the copier access code are allowed to
use the photocopier.
When user code access is allowed, step (A-19) will
search for a user in the local user database (T-4) that
matches the entered string. If a match is found the
program continues to (A-20), otherwise the invalid user
code screen (A-18) is displayed and control is returned
to (A-5). This provides "hard" validation of the user
code so that only programmed users may access the
photocopier and controller terminal functions.
When the user code is found, a check is made (A-20)
to see if the user code is programmed for manager access,
meaning the user is to be given access to the programming
and configuration of the controller terminal device. If
the user is found to be a manager, then the manager
system (B) is invoked, otherwise the user record is
loaded (A-21) from the local database as the current user
and the copy job procedure (C) is invoked.
20808a7
The user record which is loaded in step (A-21)
contains several pieces of information about the user
which allows the controller terminal (3) to react in an
appropriate fashion to the user. The following is a list
of the different fields of the user record:
1- The user code used to reference this user
(maximum 8 characters).
2- The name assigned to this user code (maximum 15
characters).
3- The total value of all photocopy usage of the
system by this user as reported by the central
computing device (1).
4- The total value of all non-billable class
account usage of the system by this user as
reported by the central computing device (1).
5- The total number of uses of override class
accounts on the system by this user as reported
by the central computing device (1).
6- The user access mode for override class
accounts, possible values being; 1) use system
defaults to determine access, 2) override class
usage enabled for this user, or 3) override
class disabled for this user.
7- The maximum number of uses of the override
class account allowed for this user. This
field is valid only if field 6- above has value
= 4.
8- The account validation mode for this user,
possible values being; 1) use system defaults
to determine validation mode, 2) "soft"
validation, 3) "syntax" validation, or 4)
"hard" validation.
9- The non-billable control mode for this user,
possible values being; 1) use system defaults
to determine non-billable control mode, 2)
warning non-billable mode, 3) describe non-
billable mode, or 4) restrict non-billable
2080807
.
mode.
10- The allowable usage limit of non-billable class
accounts as a percentage of non-billable usage
out of total usage. This field is valid only
if field 9- above is not set to value = 1.
11- Non-billable reaction screens enable being
either true or false. This field determines
whether the account class alternative screens
that are activated upon passing a non-billable
usage limit are displayed for this user.
12- Manager status being true or false indicating
whether this user code is used to access the
manager system.
13- Transaction description status for this user
being forced or not forced. When this is set
to forced, then the user will be forced to
enter a description each time the photocopier
is used if the length of transaction
descriptions is greater than 0 characters.
14- A field used by the local database program to
maintain the database.
The interactive user database search program
referred to above comprises a method of scAnn;ng and
searching the local user database for the purpose of
selecting a user record. Upon entry to this program, the
first user record (in terms of alphabetic ordering by
user name) is displayed. The operator of the system is
provided with an entry field where a search string can be
entered and the following function key options; Fl = CODE
or NAME to switch between user code alphanumeric ordering
or alphabetic user name ordering of the list, F2 = PREV
to move to the previous record in the current ordering,
F3 = NEXT to move to the next record in the current
ordering, and F4 = CANCEL to cancel the user record
selection operation. If the "Enter" key alone is
pressed, the current record is selected and returned to
2080807
the calling program. If a string is entered followed by
"Enter" then a search operation is performed.
The method of the search depends upon the current
ordering of the list of user records. If the current
ordering is by user name, then a search is made for the
first user record containing the entered string, if no
match is found then the closest alphabetic name is made
the current record. If the current ordering is by user
code, then a search is made for the exact or closest
higher user code in the local user database, and this
record is then made the current record. If F1 (CODE or
NAME) is pressed, then the current record is not changed,
but the meaning of the F2 (PREV), F3 (NEXT) and search
operation is modified to use the new ordering method. F4
can be used at any point to cancel the user record
selection operation in which case the interactive user
database search program returns a cancel result to the
calling program.
The manager system (B) referred to above, provides
interactive access to all registers, tables, and
databases in the controller terminal (3). The manager
system is activated at (A-20) from the controller
terminal main program flow when a user code that has
manager access enabled is entered. The manager system
(B) is implemented as a large menu tree (FIG. 7) with
terminal nodes representing choices for inspecting or
modifying particular elements of
defaults/databases/registers. The function keys and the
"Enter" key are used to move down and up through the tree
respectively. At each tree node starting at the manager
menu (B-1) the function keys F1 through F4 represent a
method of accessing a sub tree or a terminal node.
As an example of how the menu tree system is
implemented, consider the manager main menu (B-l). This
2080807
screen displays the menu name "Manager Menu" on the top
line of the display (3-26), the second line is blank, the
third line displays the message "Use the Fkeys to select
or Enter to exit", and the bottom line has the following
function key assignments; F1 = USERS, F2 = ACCOUNTS, F3 =
REPORTS, F4 = SYSTEM. Pressing "Enter" results in moving
up one level in the tree, in this case representing an
exit from the manager system. Pressing any of the
function keys results in moving down the tree along the
path represented by the particular function key.
For example, in the event F2 is pressed, the
"Accounts Maintenance Menu"(B-13) would be displayed,
with a new set of function key assignments to indicate
further choices for movement in the tree. This menu
program coupled with the dynamic function keys and a
logical tree classification of the terminal nodes,
provides a fast and intuitive method of selecting the
desired program to modify the controller terminal data.
Conventional methods using mnemonic codes or static
function keys have been found to not effectively present
the user with the number of program options that are
present in the controller terminal manager system of the
system according to the present invention since too many
codes would be required to be memorized or an excessive
number of static function keys would be needed to fit on
the keyboard.
The following description discloses various programs
that are accessed through the manager system and the data
areas that they affect. The disclosure will, in general,
be limited to a summary of functions and impact upon
operation, disregarding the mec-h~n;cs of the operation
since the methods of displaying and accepting data would
be well known to a person skilled in the art.
The first group of functions available through the
2080~7
manager system are the user database maintenance
functions accessed using Fl from the "Manager Menu" (B-
1). The four categories of functions available from the
"User Maintenance Menu" (B-2) are; 1) Add/Edit a user (F1
= ADD/EDIT), 2) Delete a user (F2 = DELETE), 3) Set user
access (F3 = SET-ACCESS), and 4) Set user exceptions (F4
= EXCEPTION).
The add/edit function allows a new user code and
name to be added to the local user database, or change
the name assigned to an existing user code. Any new
users added using this function are set to default
operation, those fields in the user record that determine
exceptional operational parameters are set to use the
system wide defaults. Manager access is disabled by
default, transaction descriptions are not forced by
default, non-billable screens are enabled by default, and
the account class totals for the new user record are set
to zero upon creation.
The delete function allows user records to be
removed from the local user database after the deletion
is confirmed.
The set-access option provides access to a lower
level menu "SET USER ACCESS MENU" (B-5) which provides
access to two functions; 1) set access mode (B-6) (Fl =
ACCESS MODE) and 2) set user/account restriction (B-7)
(F4 = ACCOUNT RESTRICTION). The set access mode function
allows the manager mode enable and the force transaction
descriptions to be set to true or false for any given
user record. The user/account restriction function
provides a method of registering illegal combinations of
user and account codes. This function will accept pairs
of a user code (or user code mask expression) and an
account code (or account code mask expression) and will
store these in the User/Account Restriction Table (T-5).
2080807
3q
The facility of entering a mask for the user code or
account code in the user/account restriction function
uses a string expression methodology which is used to
implement other aspects of the invention, and so will be
described herein. The purpose of a "mask" as opposed to
a specific code is to provide a method of generalizing a
group of codes that are somehow similar using a single
expression. The methodology used by the invention is
that of a character based expression syntax where each
character position of a code can be defined as being a
specific symbol, or some subset of all possible symbols.
The following table describes the mask expression syntax:
2080807
3~
Mask Character Will Match:
A to Z and space If the character is an exact match.
0 to 9 If the character is an exact match.
* Always.
5 ? If the character is A to Z or 0 to 9.
- If the character is A to Z or blank.
@ If the character is A to Z.
% If the character is 0 to 9 or blank.
# If the character is 0 to 9.
This mask expression syntax can be compared with any
string to test whether one string (not a mask) is a
subset of a mask syntax expression. In operation, the
program simply compares each character in the string
under test with the mask, and returns a match indication
if all character positions of the string under test meet
the mask expression syntax. As an example, consider the
mask A~##%% and the following test strings; 1) the string
AB123 would be considered a match, 2) CB123 would not
match since the first character is not an "A", 3) AZ1
would not match either because there is only one digit
following the AZ, and the mask expression re~uires 2 to 4
digits.
Returning now to the manager system and specifically
the "EXCEPTION" option of the user maintenance menu (B-
2), this option invokes a sub-menu "USER EXCEPTIONS MENU"
(B-8) where functions available are; 1) set user price
exception (B-9) (F1 = "PRICE), 2) set user validation
exception (B-10) (F2 = "VATTDATION"), 3) set user
override class usage exception (B-11) (F3 = "OVERRIDE"),
and 4) set user non-billable mode exception (B-12) (F4 =
"NON-BILL).
The set user price exception provides a method of
defining a special pricing table with up to three price
levels that is to be used for a specific user or users
20808~7
3q
matching a user mask expression. This function (B-9) is
used by entering a user code or user code mask expression
to which it is desired to apply a special price. If a
special price is already defined for this user code or
mask then the current special price table is provided for
inspection, change, or deletion. If no special price
table already exists for this user code or mask, then a
new table is created with default values, and it can be
inspected, changed, or deleted. If this function is
terminated without using the delete option, the special
price table is stored to the special user pricing tables
(T-6).
The set user validation exception (B-10) allows the
account validation mode for a particular user to be
changed from the system wide default value. The function
(B-10) works by setting the validation field of the user
record that is selected for an exception to one of the
following values; 1) soft validation, 2) syntax
validation, and 3) hard validation.
The set user override mode exception (B-11) allows
the use of override class accounts to be explicitly
enabled or disabled for any user, and provides for
setting the maximum number of uses to allow. This
override control setting is implemented by setting the
appropriate fields of the user record in the local user
database.
The last function available in the "USERS EXCEPTIONS
MENU" is set non-billable mode (B-12). This function (B-
12) allows the non-billable mode for any particular user
to be changed from the system default to warning,
describe, or restrict. It also allows a special reaction
percentage to be set as an exception for any given user.
This is implemented by setting the non-billable mode
fields in the user record in the local user database.
20808~7
L~b
The second group of functions available from the
manager system are concerned with maintenance of the
accounts database and accounts exceptions. Pressing F2
(ACCOUNTS) from the main manager menu results in entering
S the "ACCOUNT MAINTENANCE MENU" (B-13) with the following
options; 1) add or edit an account (B-14) (F1 =
"ADD/EDIT", 2) delete an account (B-15) (F2 = "DELETE"),
3) display account status (B-16) (F3 = "STATUS"), and 4)
set special account price (B-17) (F4 = "PRICE").
The add or edit an account function (B-14) provides
a method of adding account codes and names to the local
account database, or editing the name associated with an
existing account code. When a new account is added, the
operator is asked to identify the account as being a
client class or non-billable class account code. When a
new account is added the account record is stored into
the local accounts database unsorted region (T-18).
The delete function (B-15) provides a method of
removing accounts from the local accounts database after
confirmation.
The status function (B-16) provides a method of
inspecting the accumulated charges to any given account,
and provides a facility to scroll up and down through the
account records in account code alpha-numeric ordering.
The special account price function (B-17) allows
special prices to be set for a specific account code or
account code mask. The operation of this function is
virtually identical to the special user price functions,
except that the table is stored to the special accounts
pricing tables (T-7).
The third major group of functions available from
the manager system is the reports menu. These functions
2080807
-
are not implemented in the preferred embodiment of the
invention, but exist as a framework for future
implementation. The purpose of these functions is to
provide a capability of producing reports to a serial
printer that would be connected to the communications
network port of the controller terminal (3). The absence
of these functions from the system of the preferred
embodiment does not limit the functionality of the system
since hardcopy reports are available through the central
computing device (1).
The last major group of functions available from the
manager system is the system group of functions. This is
by far the largest group of functions in the manager
system which are used to configure the device for
different modes of operation. The "SYSTEM MENU" (B-23)
provides four options; 1) set system default pricing (B-
24) (Fl = "PRICE"), 2) set system wide timeout period (B-
25) (F2 = "TIMEOUT"), 3) set the current date and time
(B-26) (F3 = "DATE/TIME"), and 4) enter the configuration
menu (B-28) (F4 = "CONFIG"), provided that a valid
password is entered by the user (B-27).
The set default pricing function (B-24) provides
means of setting up to eight different prices depending
upon quantity to be used in absence of any user or
account special pricing.
The set system wide timeout function (B-25) allows
the system timeout to be set between 15 seconds and 59
minutes and 59 seconds.
The set date and time function (B-26) allows the
current date and time to be entered. This function
stores the entered time into the real time clock circuit
(3-8).
2080807
The configuration option from the "SYSTEM MENU"
causes a password entry and verification screen to be
displayed (B-27). As discussed above, the operator is
required to enter the valid password in order to access
the "CONFIGURATION MENU". The reason for the password is
that the functions available at this point in the tree
and downward should only be set during installation by
trained operators.
The configuration menu provides the following
options; 1) go to system operational defaults menu (B-29)
(F1 = "DEFAULTS"), 2) pick the menu for the
communications network port parameters (B-43) (F2 =
"PORT"), 3) select the photocopier configuration menu (B-
44) (F3 = "COPIER"), and 4) enter feature access control
(B-50) (F4 = "SECURITY").
The security function allows authorized operators to
configure the controller terminal feature availability
(B-50) at the time of shipping the system to an end
customer. The parameters and registers that can be set
in these "CONFIGURATION MENU" (B-28) functions are,
unless otherwise noted, stored in the data and
configuration memory area (T-9). The remaining three
options, each being substantial, are discussed
individually in the subsequent paragraphs.
The "DEFAULTS MENU" (B-29) provides access to
fundamental parameters and tables that control the
default operations and program flow for the controller
terminal (3). This menu provides four options; 1) set
the default validation mode and/or validation mask syntax
(B-30) (F1 = "VALIDATION"), 2) enter the "ACCOUNT
DEFAULTS MENU" (B-31) (F2 = "ACCOUNTS"), 3) set the
default transaction description mode and/or length (B-35)
(F3 = "TRANSACTIONS"), and 4) select the "SPECIAL
DEFAULTS MENU" (B-36) (F4 = "SPECIAL").
2080807
-
43
The set validation mode and syntax function allows
the operator to select the default validation mode,
possible values being; 1) soft validation placing no
restriction on the account code which is entered, 2)
syntax validation such that all account codes must match
a mask expression, or 3) hard validation whereby only
account codes that are present in the local accounts
database are accepted. If the mode selected is syntax,
then an account code mask expression is accepted and
stored which is used to enforce the syntax account code
validation.
The set transaction descriptions mode and length
program provides the operator a method of selecting how
the transaction descriptions are to be used, and how long
they are. The mode can be set to 1) disabled so that
transaction descriptions are never stored, the length
being implied as 0, 2) available meaning if a description
is required, space is allocated to store it, or 3)
enabled such that a transaction description is accepted
and stored for each use of the photocopier. The length
of the transaction description may be set between 0 and
30 characters, with the caveat that any transactions in
the local database are lost when the length is changed
since this leads to a restructuring of the local
transaction database.
The "ACCOUNT DEFAULTS MENU" (B-31) from the
configuration menu provides access to three options which
allow configuration of the controller terminal (3)
parameters regarding account code operations. The three
options are 1) set the account names mode and/or length
(B-32) (F1 = "NAMES"), 2) set the default account search
mode (B-33) (F2 = "SEARCH") for the interactive account
code search (H), and 3) set the usage rules for override
class accounts (B-34) (F4 = "OVERRIDE").
2080807
~Y
The set account names mode and length provides for
setting the account names mode to; 1) available meaning
the space in each account record is reserved for a name,
or 2) forced so that whenever a new account is used, a
name must be entered for it. The length of the account
name filed is variable from 0 to 30 characters, with the
restriction that all accounts and transactions in the
local databases are lost when the length of account names
is changed, since this too leads to restructuring of the
local databases.
The default account search mode can be set to either
1) account code field search, or 2) name/description
keyword search.
The set override usage rules function (B-34)
provides a method of globally enabling or disabling the
use of override class accounts, and if enabled, to
specify the maximum number of uses by each user.
The "SPECIAL DEFAULTS MENU" (B-36) provides access
to two primary groups of functions; 1) set the non-
billable class usage mode, limits, and sanctions (B-37)
(F1 = "NON-BILLABLE"), and 2) set the account
confirmation register (B-42) (F4 = "CONFIRM ACCOUNTS").
The function (B-42) provides a means of globally
enabling (setting to true) or disabling (setting to
false) the account confirmation register, which ensures
that each user is asked to confirm the account to charge
before the photocopier is enabled.
The "NON-BILLABLE DEFAULTS MENU" (B-37) provides
four options to configure the automatic non-billable
analysis and usage controls, they are; 1) set the account
class usage analysis period (B-38) (F1 = "PERIOD"), 2)
set the non-billable alternate account class screens (B-
20808~7
39) (F2 = "SCREENS"), 3) set the non-billable delay
period (B-40) (F3 = "DELAY"), and 4) set the non-billable
mode and reaction levels (B-41) (F4 = "MODE").
The function (B-38) provides a method of setting the
period of the account class analysis that will be
reported to the user if the non-billable usage limit is
exceeded. This field is not actually used in calculation
for the following two reasons; 1) when the controller
terminal (3) is not networked (not connected to a central
computing device (1) through the communications network
(2)), then the analysis period is fixed at 30 days, and
2) when the controller terminal (3) is networked, the
effective analysis period is determined by the
configuration of the central computing device (1), since
it sends the results of its centralized class usage
analysis to all controller terminals on the network.
The "SCREENS" function (B-39) provides a method of
determining which screens (each corresponding to a
strategy) to use when a user exceeds the allowable non-
billable class usage. This function (B-39) allows each
of the three screens to be enabled or disabled. The
three screens which it controls are; 1) a non-billable
class accumulated charge display screen and prompt to
abandon the non-billable charge, 2) a screen which
prompts the user to search for a client code instead of
procee~ing with a non-billable charge, and 3) a screen
which prompts the user to enter a client name (override
class account) so that an unknown or new account can be
charged instead of a non-billable class account.
The program (B-40) allows the delay period that the
system uses when a description is entered for a non-
billable charge to be set between 0 and 99 seconds.
The non-billable mode and limits function (B-41)
20808D7
sets the default mode for determining and controlling
excessive use of the non-billable class accounts. This
mode can be set to one of three values; 1) warning,
meaning that once the limit is exceeded, only the non-
billable screens are used, 2) describe, causing the non-
billable screens to be displayed, and if no alternate
account class is selected, forcing the entry of a
transaction description, and optionally waiting for the
delay period, and 3) restrict, such that the non-billable
screens are displayed, but the user is restricted from
using any non-billable class account while his/her usage
limit is exceeded.
Once the default mode is set, two numeric parameters
are used to define what is acceptable non-billable class
account usage. The first parameter is a percentage of
non-billable class usage value out of the total
photocopier usage value. The second parameter is a
minimum total value of all photocopier usage before which
no usage limit will be considered, this can be set
between 0 to 99 dollars.
The percentage parameter allows definition of the
target recovery level of non-billable value as a
percentage of total photocopier usage value, where the
usage is considered past the limit if the user's
calculated percentage exceeds this value.
The minimum value parameter allows the definition of
a usage limit free zone so that trivial uses of non-
billable class accounts may be allowed, even if the
percentage parameter is exceeded.
A special combination is used to fully disable the
non-billable analysis and control system in situations
where it is not desired. This combination is mode set to
warning and the percentage parameter set to 0.
2080807
~1
The "SERIAL PORT CONFIGURATION" menu (B-43) provides
access to functions which are used to configure the
characteristics of the communications network port for
proper operation. This menu provides four options; 1)
set port mode and network address (B-51) (F1 = "MODE"),
2) set the serial port baud rate (B-52) (F2 = "BAUD"), 3)
set the serial communications data and stop bits (B-53)
(F3 = "BITS"), and 4) set the serial communications
parity (B-54) (F4 = "PARITY").
The "MODE" option (B-51) provides a selection of; 1)
networked to central computing device (1), 2) Copy/SYS
protocol emulation, 3) printer connection with XON/XOFF
flow control, or 4) printer with DSR/DTR flow control.
The only mode of interest to the scope of this
specification is the networked mode. This function
further accepts the network address that is to be used to
uniquely access a particular controller terminal (3), the
address being 1 to 98.
The set baud rate function (B-52) allows the serial
bit rate to be set to; 1) 2400, 2) 9600, 3) 19.2K, or 4)
38.4K bits per second.
The "BITS" option (B-53) allows the data width to be
defined as 7 or 8 bits, and defines serial operation with
1 or 2 stop bits.
The last option, set serial parity, provides for
using no parity, even parity, or odd parity.
The "COPIER CONFIGURATION" menu (B-44) provides
access to the registers and parameters which are specific
to each photocopier (4) controlled by the system. The
four options from this menu are; 1) set the photocopier
name (B-45) (F1 = "NAME"), 2) set the company name (B-46)
(F2 = "COMPANY"), 3) set the photocopier access code and
2080807
,
mode (B-47) (F3 = "CODE"), and 4) set the photocopier
interface mode (B-48) (F4 = "INTERFACE").
The copier name function (B-45) simply allows a
short string to be entered that is used to label the
photocopier.
The company name facility (B-46) is used to store
the name of the owner/user of the system to the data and
configuration RAM so it can be identified in the future
if required.
The set access code and mode function (B-47) allows
an access code to the interactive user record search
procedure to be defined, and to establish whether normal
user codes in the local user database will be permitted
access to the photocopier.
The copier interface function (B-48) is used to
indicate to the controller terminal (3) how to interpret
the logical photocopy pulses to count pages. The default
copier interface mode is "AUTOMATIC" which means that for
each logical copier pulse, one page is counted.
Through this function (B-48), custom interpretations
of the photocopier pulse may be defined using a three
part expression. The custom copier interface expression
follows the following syntax XYYZZ where: X is either H
or L indicating the logical level of a valid photocopy
pulse which is high or low, YY representing a value from
00 to 99 representing the minimum time in 1/100ths of a
second that the pulse must be valid for a page to be
counted, and ZZ representing a value from 00 to 99
corresponding to the wait time in l/100ths of a second
between sensing successive photocopy pulses as pages.
This facility for custom photocopier interfaces provides
for accommodating page count signals from photocopiers
-- 2080807
~9
where simple R-C pulse shaping is not sufficient for
accurately detecting a pulse.
Returning now to the description of the program flow
diagrams, reference will be made to FIG. 10, which shows
the program flow for (C) which is the account code entry
and option system. The start point (C) is called as a
subroutine, either from the main controller terminal
program flow FIG. 6 (A) , or from the copy job program
flow FIG. 18 (L). This subroutine (C) assumes that the
current user record is loaded, and firstly calls the
account class usage analysis subroutine (E) for the
current user, described later.
Upon completion of the analysis, it displays (C-l)
the account code entry screen, which greets the current
user with the user's name, and prompts the user to enter
the account code that he or she wishes to charge. This
account code entry screen has the following function key
options; 1) display help (F1 = "HELP"), 2) use the last
account used by the current user (F2 = "LAST ACCT."), and
3) perform interactive account search (F4 = "SEARCH").
The system then checks (C-2) the defaults and user
record to determine if override class accounts are
enabled, and if they are, then a further function key
option is displayed as client name (F3 = "CLIENT NAME"),
otherwise flow control continues to (C-5).
The system then waits for a string to be entered as
an account code, or for a function key to be pressed, if
a timeout occurs while waiting for input then flow
control proceeds to (X) where the account code entry
subroutine terminates.
If F1 (HELP) is pressed then the help screen is
displayed (C-4) and program flow returns to (Z), the re-
2080807
entry point for the sub-routine.
Next, the F2 (LAST ACCOUNT) key is tested (C-6) and
program flow continues to (F) if it was pressed.
Then, the F3 (CLIENT NAME) key is tested and program
flow continues to (C-8) where it is determined whether
override class accounts are enabled. If they are
enabled, then program flow continues to (G), otherwise
the flow returns to the re-entry point (Z).
The last function key option F4 (SEARCH) is then
tested (C-9), and the interactive account code search (H)
is invoked if the F4 key was pressed.
Assuming that there has been no timeout and no
function key has been pressed, program flow proceeds to
(C-10) where the length of the entered string is checked.
If no characters were typed, then program flow proceeds
to (X) which is the termination point of the account code
entry subroutine. However, if characters were typed, the
string is stored as the current account, and flow control
proceeds to the account code validation program (I).
As discussed above, the first operation performed by
the account code entry subroutine is to call the account
class usage analysis routine (E). This routine (E) is
now described, referring to FIG. 11.
Upon entry to this routine, the working analysis
totals are first cleared (E-1). A determination is then
made as to whether the analysis is to be a networked
analysis (E-2), meaning an analysis including account
class usage information provided earlier by the central
computing device (1) t~ the local user database, or a
"standalone" analysis.
2080807
51
If it is not to be a networked analysis, then the
analysis start date/time is set (E-3) to today - 30 days
(the fixed standalone analysis period) and program flow
continues to (E-6).
If the analysis is to be networked, then the
analysis totals from the user record are copied (E-4) to
the working analysis totals, and the start date/time for
the analysis is set (E-5) to the date/time of the last
class usage analysis update from the central computing
device (1). The working variable representing the start
date/time for the analysis is used to limit the range of
the records in the local transaction database used for
the account class usage analysis.
Steps (E-6) through (E-10) perform the summing of
the transactions for analysis. The most recent
transaction is loaded (E-6), if the local transaction
database is empty then program flow continues to (E-ll).
The current transaction is then checked for inclusion (E-
7) in the analysis by comparing the current transaction
date with the established analysis start date/time. If
the transaction is before the analysis start date/time,
then program flow continues to (E-ll), otherwise the
transaction is summed (E-9) to the working analysis
totals for the appropriate class (E-8). The next most
recent transaction is then loaded if it exists and
program flow returns to (E-7). If the end of the local
transaction database is reached, then program flow
proceeds to (E-ll).
The step (E-ll) performs an algorithm on the working
analysis totals to determine the current class usage
results, and the analysis subroutine terminates by
returning to the caller (E-12). The following is a list
of information collected and calculated by this analysis
routine:
20808a7
1) Total value of all photocopier usage in the
analysis period by the current user.
2) Total value of all non-billable class account
usage in the analysis period by the current
user.
3) Total number of override class account uses in
the analysis period by the current user.
4) The amount of non-billable class usage as a
percentage of total usage by the current user.
When the last account option (C-6) is selected from
the account code entry subroutine (C), then the last
account program (F) assumes program control. The program
flow diagram for (F) is shown in FIG. 12, and is
described herein.
The first step (F-1) retrieves the most recent
transaction in the local transaction database, if the
local dat~h~se is empty then program flow continues to
(F-5).
The current transaction is then checked (F-2) as to
whether it was made by the current user or not. If this
transaction was made by the current user, then program
flow proceeds to (F-6). If the current user and
transactions do not match, then the next most recent
transaction is loaded (F-4) and program flow returns to
(F-2).
If, in step (F-4) there are no more transactions,
then program flow continues to (F-5). Step (F-5)
displays a message indicating that no last account could
be found for the current user, and program flow is
directed to the account code entry routine re-entry point
(Z)-
When a last account is found in step (F-2), step
20808~7
-
~3
(F-6) displays (3-26) the account code and name (if --
available) from the transaction for confirmation.
At (F-7) the last account program waits for user
input, if a timeout occurs then flow continues to the
account code re-entry point (Z). The input is otherwise
checked for a confirmation of the displayed account, and
if not confirmed then the account code entry routine is
re-entered (Z). If the account is confirmed then it is
stored (F-10) as the current account, and program flow
proceeds to the account code validation program (I).
As described earlier, when the client name option is
selected and enabled, program flow continues to the
override account entry program (G). This program is
represented by the flowchart in FIG. 13 and is described
herein.
The first operation determines whether the user has
exceeded the allowable limit of override class account
usage. This is performed by comparing (G-1) results of
the current user account class analysis with the user's
access level for override accounts, being either the
system default or an exception setting in the current
user record.
If the user has exceeded his/her limit then a
message indicating this condition is displayed to the
user (G-2) and program flow continues to the account code
entry routine re-entry point (Z).
If the user has not exceeded the allowable limit,
then a screen is displayed (G-3) which prompts the user
to enter the name of the client to charge. The
controller terminal then waits for the user to enter a
string, if a timeout occurs then the flow returns to the
re-entry point (Z).
208081~7
If the F1 (HELP) key is pressed then a help screen
is displayed and flow returns to (G-3).
When "Enter" is pressed, the length of the entered
string is checked (G-6), if the length is 0 then program
flow returns to the re-entry point (Z).
If the length of the string is greater than 0 then a
new account record is composed in the following manner;
1) the account code for the override account is composed
of the "+" character plus the first 11 characters of the
entered string, 2) then account name (if account names
are available or forced) is loaded with the entire
entered string, and 3) the account record is set to
override class.
This override account is then stored (G-7) to the
local accounts database in the unsorted region and loaded
(G-8) as the current account. Once the override account
has been loaded as the current account, then program flow
continues to the transaction set-up means (J).
An important function available from the account
code entry routine (C) is the ability to search for a
valid account code. This function is implemented by the
interactive account database search program (H) as shown
in a flowchart in FIG. 14. This subroutine accepts a
string from the caller which is used as a "seed" for the
search operations.
The first step (H-1) is to determine the default
search mode as either by account name keyword or by
account code. Each mode of the search program will be
discussed individually, and then the facility for
switching modes will be discussed.
In general terms, the account name keyword search
2080837
,
provides a method of searching the entire local accounts
database for the occurrence of account codes having one
or more keywords in the account name. It further
provides a means of displaying the number of matches
found and scrolling through the list of matches at any
point in the search operations. This display, scrolling,
and subsequent keyword searching allows the user to
quickly reduce the number of matching accounts and find
the desired account record.
The first operation (H-2) in the keyword search mode
is to define the current list of account records
qualifying for the next search operation as the entire
local accounts database.
The current search string is then set (H-3) to the
string passed when the search program was invoked.
The step (H-4) performs the search of the account
names of all the account records defined by the current
list. This keyword search operation produces as output a
new current list of all account records in which a match
was found. If no matches were found in the current list,
then the current list is not updated.
Step (H-5) then sets the current record as the first
account record in the current list.
The current record is then displayed (H-6) to the
user showing the account code and the account name
(assuming account names exist) along with the following
function key options available at this point; 1) switch
to account code based search method (F1 = "CODE-SRCH"),
2) go to previous account record in current list (F2 =
"PREVIOUS"), 3) go to next account record in current list
(F3 = "NEXT"), and 4) cancel the search operation (F4 =
"CANCEL").
20808~7
The program then waits for user input (H-7). If a
timeout occurs or F4 (CANCEL) is pressed, then flow
control returns to the re-entry point (Z). If a string
of characters is entered (H-8), then this string is made
the current search string (H-9).
The user input is then tested (H-10) to see if the
F3 (NEXT) key was pressed, if it was then the current
record is incremented (H-11) in the current list if
possible, and program flow returns to (H-6).
Next, the F2 (PREVIOUS) key is checked (H-12) and if
it was pressed then the current record is decremented (H-
13) in the current list if possible, and program flow
returns to (H-6).
The F1 key (CODE-SRCH) is then tested (H-14).
Discussion on switching search modes is discussed later.
Finally, the entered string is checked (H-15) for
length. If the length is 0 then only the "Enter" key was
pressed, which indicates that the current account is to
be selected. If "Enter" was not the only key pressed,
then program flow returns to (H-4) to perform a
subsequent search operation.
If the current record is selected, then the current
record is loaded as the current account (H-16) and
program flow continues to the account code validation
program (I).
The account code mode of the interactive local
accounts dat~h~ce search program provides closest match
searching of all of the account codes in the local
database, and scrolling of the database records in an
alpha-numeric ordering of the account records by account
code.
2080807
~1
The first operation (H-17) is to set the current
search string equal to the string passed to the search
program.
Step (H-18) performs a search of the local accounts
database for an exact match or closest higher account
code to the search string, and sets the resulting record
as the current record. If no exact match or closest
higher match is found, then the current record becomes
the first record in the local accounts database.
The current record is then displayed (H-19) showing
the account code and name (if available), and the user is
also presented with four function key options; 1) switch
to account name keyword search (F1 = "NAME-SRCH"), 2)
display the previous account record (F2 = "PREVIOUS"), 3)
display the next account record (F3 = "NEXT"), and 4)
cancel the search operation (F4 = "CANCEL").
The system then waits for user input, and if a
timeout occurs or F4 (CANCEL) is pressed then program
flow returns to the ré-entry point (Z). The user input
is first checked for a string entry, if a string of
characters was entered then this string is made (H-22)
the current search string.
The F3 (NEXT) key is then checked (H-23), if it was
pressed then the current record is incremented (H-24) if
possible, and program flow returns to (H-19).
Next, the F2 (PREVIOUS) key is checked (H-25), if it
was pressed then the current record is decremented (H-26)
if possible, and program flow returns to (H-19).
The Fl (NAME-SRCH) key is then checked (H-28). As
mentioned in the prior discussion, switching of search
modes will be described in greater detail below.
20808a7
-
Next, the user input is checked (H-29) to see
whether an "Enter" key was pressed, which indicates that
the current record is to be selected. If the "Enter" key
was not pressed in isolation, then program flow is
directed to (H-18) for a search operation.
If the current record has been selected, then it is
loaded as the current account (H-30) and program flow
continues to the account code validation program (I).
In each of the two search modes described above,
there exists a function key option to switch from one
method of searching to the other. In order to implement
this switch of modes and determine the state of the new
search mode, specialized logic is provided to effect a
smooth and intuitive transition.
In the first case, where the current mode is
account name keyword search, the Fl key is used to
trigger the change in search mode at (H-14). The effect
of this action is to maintain the current record, but to
use the alpha-numeric ordering of the entire local
accounts database for scrolling operations.
In the second case, where the current search mode is
by account code, the Fl key is again used to switch modes
at (H-28). In this case however the current list must be
defined for subsequent keyword search operations. The
current list when making this transition is defined as
all account codes in the local database matching a
keyword search of the current search string, and the
current record is considered to be the first record in
the list. Once this transition current list is defined,
program flow is passed to (H-5).
The following is an example of the code to name
transition; 1) search is invoked with a search string
2080807
~q
"AB", 2) the exact match or closest higher match to "AB"
is then displayed, 3) F1 is pressed to switch the search
mode, and all account codes containing the search string
"AB" are identified in the current list, 4) the first
account record whose account code contains "AB" is
displayed (ie. "0AB10"), 5) the name search program waits
for scrolling, subsequent keyword searches on the account
name, or account record selection.
Once an account has been selected as the current
account by the user through direct entry, last account,
or search, program flow continues to the account code
validation program (I). This validation program means is
shown in a flowchart in FIG 15, and is described herein.
The general purpose of the validation routine is to
verify the acceptability of an account code which the
user has selected in terms of the system default and user
exception programming, and to allow new accounts to be
defined in the course of usage in both soft and syntax
validation modes.
The first operation performed by the validation
program is to compare (I-l) the current user and the
current account combination with all of the user/account
restrictions stored in memory area (T-5).
If the current user/account pair is found in the
restriction table, then a message is displayed (I-2)
indicating that the current account is restricted from
use, and program flow returns to the re-entry point (Z).
The next operation performed is a search to locate
the current account code in the local accounts database
(I-3). If the account code is not found, then program
execution continues to (I-8). If it is found however,
the current account code is checked (I-5) for hold
2080807
status. If the account is held, then a message to that
effect is displayed to the user and program flow returns
to the re-entry point (Z).
If the account is not found to be on hold, then its
class is determined (I-6). If the account is not in the
non-billable class then program flow continues to the
transaction preparation program means (J).
If the account is in the non-billable class then the
current account code analysis results are compared (I-7)
with the non-billable usage limit defined for the user,
and if the level has been exceeded, program flow is
diverted to the non-billable event program means (K).
If the acceptable non-billable class usage has not
been exceeded, the program flow continues to the
transaction preparation program (J).
When the current account is not found in the local
database, control is passed from (I-3) to (I-8) where the
current validation mode is checked (I-8) to see if it is
hard validation. If the current validation mode is hard
validation (bearing in mind that a user record validation
exception takes precedence over the system default
validation mode), then a message is displayed (I-9)
indicating that the account code could not be found, and
program flow continues to the re-entry point (Z).
If the hard validation check fails, the validation
mode is checked (I-10) for syntax mode. If the current
validation is in syntax mode, then the current account
code is compared (I-11) with the validation syntax mask.
If the current account matches the validation syntax,
then program flow continues to (I-13), otherwise a
message is displayed (I-12) indicating that the entered
account code does not match the required syntax, and
2080807
~/
program flow is returned to the re-entry point (Z).
When (I-13) is reached it is assumed that the
account is validated, but does not exist in the local
accounts database. At (I-13) the user is alerted of this
condition and is asked to confirm the account code. The
system waits for confirmation (I-14) and proceeds to (I-
15) if it is confirmed, otherwise program flow returns to
the re-entry point (Z).
Once confirmed, the account description (an alias
for account name) mode is checked (I-15). If account
descriptions are forced, then the program continues to
(I-16), otherwise it proceeds to (I-17). At (I-16), the
system prompts the user to enter the account name and
stores it to the current account and proceeds to (I-17).
At (I-17) the current account is stored to the
accounts database in the unsorted region (T-18), since
new uses of an account code cause it to be added to the
top of the local accounts database.
Finally, the newly created account code record is
stored (I-18) as the current account for the transaction,
and program flow continues to the transaction
preparation program (J).
When a user is past the allowable limit for non-
billable account class usage, and that user selects a
non-billable class account, the non-billable event
program (K) is activated. This program means is shown in
a flowchart in FIG. 16 and is described herein.
The action taken is comprised of two stages; 1)
provide the user with an opportunity to select an
alternate class of account, and 2) if the user does not
choose an alternate class of account, provide some
2080807
6~
sanction to restrict or dissuade non-billable class
account usage.
Depending on the system defaults and the user
exception programming, as with many of the system
features, this program may react differently for
different users, allowing the controls to be targeted for
maximum effectiveness.
The first operation is to check (K-l) if the
"status" non-billable event is enabled, which means it
must be globally enabled (default setting) and screens
must be enabled (also default setting) for the current
user record.
If this screen is enabled, then the system will beep
(K-2), display an "Excessive Office Charge" message,
display the total non-billable class usage value, display
the programmed non-billable analysis period, and prompt
the user with an enquiry as to whether they want to
charge a client. The user is provided with two function
key options; 1) chargé to a client (F3 = "YES"), and 2)
do not charge to a client (F4 = "NO).
If the user terminates the input (K-3) with anything
but F4 (NO) or a timeout occurs, then program flow
returns to the re-entry point (Z), otherwise program flow
continues to (K-4).
The "search" screen is then checked (K-4)to see if
it is enabled, using the same methodology as the "status"
screen. If it is enabled, then the user is prompted (K-
5) to search for a client code and asked to type "NO" or
use the F4 (F4 = "SEARCH") key to activate the search
program means.
If a timeout occurs or F4 (SEARCH) is pressed (K-6),
2080807
-
6~
then program flow is directed to the interactive local
account database program (H). If the user types "NO"
followed by enter however, program flow proceeds to (K-
7).
The last screen, the "override" screen, is then
checked (K-7) to see if it is enabled, using the
methodology already explained. If this screen is enabled
then the user is prompted (K-8) to charge the photocopies
to a client name using an override class account. The
user is required to respond with F4 (F4 = "CLIENT NAME")
or type "NO", if F4 is pressed (K-9) then program flow is
routed to (G), otherwise if "NO" is typed, then program
flow continues to (K-10).
When program flow has reached (K-10) it is presumed
that the user wishes to continue with the non-billable
class account usage. The operation next performed is to
identify the non-billable mode (K-10) for this user,
being either the system default setting or a user record
exception setting.
If the mode is "warning", then program flow proceeds
to the transaction preparation program (J) without
further impediment.
If the mode is "restrict", then a message (K-11) is
displayed indicating that the user has exceeded allowable
non-billable usage limits and that non-billable class
accounts privileges are temporarily suspended, and
program flow the returns to the re-entry point (Z).
The last possibility is that non-billable mode is
"describe", in which case the user is prompted to enter a
description for the non-billable job.
The system waits for input (K-12) and provides the
- ,~ 2080807
lp
following two function key options; 1) display help (F1 =
"HELP"), and 2) cancel this photocopy job (F4 =
"CANCEL"). If F1 (HELP) is pressed then the help screen
is displayed (K-15), and program flow returns to (K-12).
If F4 (CANCEL) is pressed or a timeout occurs, then
program flow is directed to the account code entry exit
point (X).
Once a transaction description is entered, it is
stored to the current transaction, and the system
displays (K-13) a message "Please wait while office
charge is being verified and recorded", and then waits
(K-14) for the non-billable delay period to expire.
Program flow then continues to the transaction
preparation program (J).
The non-billable delay (K-14) is not actually
required for the system to execute any function, but is
provided so that the user will hopefully be discouraged
by the imposed wait from inappropriate use of the non-
billable class of accounts. It should be noted that if
the delay period is set to 0 seconds, the screen will
never be visible to the user, providing a method of
disabling the delay.
Prior to enabling the photocopier and monitoring the
number of pages being photocopied, the transaction
preparation program (J) is called. This program
completes all actions required before allowing access,
and determines what pricing table is to be used. The
flowchart for this program (J) is shown in FIG. 17 and is
described herein.
The first operation is to determine whether the
account confirmation feature is enabled (J-1). If it is,
then program flow continues to (J-2), otherwise it
proceeds to (J-5).
20808~7
6~
At (J-2) the progress of the account code entry so
far is tested to see if a confirmation or implied
confirmation has already been made. If it is determined
that confirmation has been made because of; 1) an
override class account being used, 2) last account
feature being used, or 3) a new account code entered
through soft or syntax validation, then the program flow
side-steps what would be a redundant confirmation and
continues to (J-5).
Otherwise, the user is presented with a confirmation
screen (J-3) showing the current account code and the
current account name (if available) and is presented with
two function key options; 1) confirm this account (F1 =
"CONFIRM"), and cancel this account (F4 = "CANCEL"). If
the account is confirmed (J-4) with F1 (CONFIRM) then
program flow continues to (J-5), otherwise if F4 (CANCEL)
is pressed, then program flow is returned to the re-entry
point (Z).
Once the account is confirmed, the program
identifies the pricing table to be used. Pricing can be
determined by a special account price, a special user
price, or the system default price, where the account has
highest priority, user second priority, and default
lowest priority in terms of which price to use.
The first step in determining the pricing table to
be used is to check (J-5) for a special account price by
comparing the current account code with each special
account price table in (T-7).
If a special account price table is found, then this
special pricing table is loaded (J-6) as the current
pricing table, and program flow continues to (J-10).
If no special account price has been identified,
2080807
then the current user is compared (J-7) with the special
user price tables in (T-6).
If a special user price table is found, then this
special pricing table is loaded (J-8) as the current
pricing table, and program flow continues to (J-10).
If no special user price is found, then the system
default pricing table is loaded (J-9) as the current
pricing table.
Once the current pricing is established, the last
operation before proceeding to the actual photocopier
usage is to get a transaction description if such
descriptions are required.
Step (J-10) determines whether transaction
descriptions are required. This is determined as true if
transaction descriptions are globally enabled or if they
are available and the user has the transaction
descriptions field set to forced. If this determination
is true, then program flow continues to (J-ll), otherwise
program flow is routed to the copy job program (L).
At (J-11) it is determined whether a transaction
description has already been entered due to a non-
billable event in describe mode. If the transaction
description has already be entered, then program flow
continues to the copy job program (L). The transaction
description is otherwise prompted for at (J-12), and
subsequently accepted and stored to the current
transaction at (J-13), after which program flow continues
to the copy job program (L).
The copy job program (L), shown in FIG. 18 as a
flowchart, performs actual monitoring of the photocopy
usage, displaying of copy progress, and storing of the
20808~7
G~1
transaction to the local transaction database.
The copy job screen is first displayed (L-1) showing
the following information; 1) the current user name, 2)
the current account code, 3) the current account name (if
available), 4) the number of copies made so far in the
transaction (0 at this point), 5) the total value of the
transaction (also 0 at this point).
Further, the following three function key options
are displayed; 1) end this transaction and select the
next account to charge maintaining the current user (F1 =
"NEXT ACCT."), 2) extend the system timeout (F2 =
"EXTEND"), and 3) end this transaction and log off
current user (F4 = "END").
The job interrupt flag in the foreground working
variables area (T-13) is then checked (L-2) to see if a
job interrupt is active. If it is active then program
flow continues to (L-4), otherwise the job interrupt
feature is displayed (L-3) as F3 = "JOB INTERRUPT".
The photocopier (4) is then enabled (L-4) through a
call to the BIOS services and the copy job timeout is
reset. Once the copier has been enabled, the user is
free to begin making photocopies while the copy job
program continually updates the screen and scans the
keyboard for further action to be taken.
The current number of photocopies is read using the
BIOS services, and step (L-5) calculates the total value
of those copies according to the current pricing table
and displays to the screen the number of copies and the
total value of those copies.
The copy job timeout is then processed, and if the
number of copies has in the last execution of (L-5) been
2080807
incremented, the timeout is reset, otherwise if a timeout
has occurred, program execution continues to (L-8).
The keyboard is then checked (L-6) to determine if a
key has been pressed, and if not then program flow
returns to (L-5). When a key has been pressed, the first
action taken is to reset the copy job timeout (L-22).
The key is then read and compared (L-7) with F4 (END) and
"Enter". If F4 or "Enter" have been pressed, then program
flow continues to (L-8), and otherwise goes to (L-10).
After disabling the photocopier (L-8) and storing
the transaction (L-9), both of which will be discussed
below, program flow returns to the account code re-entry
exit point (X).
The next key that is checked is the F1 (NEXT ACCT.)
key (L-10). If it has been pressed, then flow control is
routed to (L-11), otherwise it continues to (L-13).
After disabling the photocopier (L-11) and storing the
transaction (L-12), both of which will be discussed
below, program flow returns to the account code re-entry
exit point (Z).
The last key to be checked (L-13) is F3 (JOB
INTERRUPT), if this key has been pressed and the job
interrupt f lag is inactive (L-14) then program f low
continues to (L-15), otherwise program flow returns to
(L-5).
When the job interrupt is allowed, several actions
are taken to save the state of the current job so that a
new one may be started, while the original job is
suspended. The f irst operation taken is to disable the
photocopier (L-15) through a BIOS service call.
Following this, the variables determining the state of
the current job are saved (L-16) in a reserved area of
208081~7
the foreground working variables area (T-13). These
saved variables include the current user, current
account, current transaction, current account class
analysis, and the current pricing table.
The job interrupt flag is then set (L-17) to
indicate to the new copy job that interrupt is already
active. This is used to ensure that only one interrupt is
possible so as not to destroy the suspended copy job
state.
These steps having been taken, the account code
entry subroutine (C) is called to activate the new job.
Upon termination of the account code entry routine (C),
the job interrupt flag is cleared (L-18), allowing
further use of this feature.
The saved state of the suspended copy job is
restored (L-19) to the current working variables and the
screen re-displayed, and the photocopier is enabled (L-
20). This represents a completion of the job interrupt
and program flow returns to (L-5) so that the original
job may be resumed.
In the two methods of terminating the current
transaction, one being through F4 (End) or the "Enter"
key and the other being through F1 (NEXT ACCT.), the
photocopier gets disabled (L-8) or (L-11), and the
current transaction is stored to the local transaction
database (L-9) or (L-12). The storage of the transaction
to the local database will nor be discussed in further
detail.
The current transaction is only stored to the
database if actual photocopies have been made and
detected, so that no 0 page and 0 cost transactions will
be stored. Further, the transaction contains the
20808~7
1~
following fields which constitute the information stored
for each transaction:
1) The exact date and time that the transaction
s was started.
2) A pointer to the user record of the user
performing the photocopy job.
3) A pointer to the account record of the account
code charged with the transaction.
4) An indicator of the class of the account record
used being either 1) client, 2) non-billable,
or 3) override.
5) The total number of photocopies made during the
job.
6) The total value of the photocopies made.
7) An optional transaction description of length
between 0 and 30 characters.
8) A flag set to false indicating whether the
transaction has been reported to the central
computing device or not.
This completes the description of the application
program (T-16) stored in (3-30). The last program, the
interrupt system and command processor (T-15), that is
stored in the program storage ROM (3-30), will now be
described.
FIG. 8 is a flowchart of the interrupt handler
program (M). When any of the three interrupt sources; 1)
serial transmitter empty interrupt, 2) serial data
received, or 3) logical copier pulse edge (3-19) are
detected by the serial interface circuit (3-13) the
interrupt request signal (3-18) is asserted to the
microprocessor and control logic (3-17). This signal (3-
18) causes the microprocessor to halt execution of thecurrent instructions, and causes program flow to jump to
the memory address specified in the interrupt vector
2080807
q~
table (T-14). These interrupt vectors (T-14) contain the
memory address or the first instruction of the interrupt
handler program (M).
The interrupt handler program first determines the
source (M-l) of the interrupt from the serial interface
circuit, and routes program flow control to (M-2), (M-
13), or (M-14) depending upon the interrupt source. If
the interrupt source cannot be identified, then program
execution of the interrupted program is resumed (M-12).
The details of proper handling of the interrupt and
safe resumption of the interrupted program are omitted
from this discussion since these principles are widely
understood.
If the interrupt source is for serial data received,
then program flow continues at (M-2). The received data
is stored to the serial receive buffer, unless it is a
hAn~sh~king signal, in which case it is used to update
the data flow control state. The serial interface is
then checked (M-4) to see if this data was the result of
a break signal on the communications network (2). If it
was, then the command processor is re-started (M-5),
terminating any current processing it was performing and
resetting its state to idle, and then the interrupted
program is resumed.
If no break was detected, then the data received is
compared (M-6) with the number "13", which represents a
carriage return in ASCII, and which is used to indicate
the end of a message to the command processor. If this
is the case, then the command processor (D) is invoked.
Whether the command processor is invoked or not, the
subsequent action is to resume execution (M-7) of the
interrupted program.
2080807
1~
If the interrupt source is a serial transmit empty
condition, then program flow continues at (M-13). The
transmit data buffer is checked (M-9) to see if there are
any characters waiting to be transmitted. If there are
none, then the serial interface is instructed (M-8) to
stop generating the transmitter empty interrupt and the
command processor (D) is invoked. If there are
characters waiting to be transmitted, then the current
handshaking status is checked (M-10) to see if the
central computing device is ready to accept data. The
handshaking referred to follows the XON/XOFF protocol
which is widely used and understood. If the handshaking
indicates that it is clear to send, then the next data
byte is removed from the transmit buffer and delivered
(M-11) to the serial interface for transmission,
otherwise the transmitter empty interrupt is disabled (M-
20). In any case, the final action taken is to resume
execution (M-12) of the interrupted program.
If the interrupt source is a transition of the
copier pulse signal, then program flow continues at (M-
14). A determination is first made (M-15) of the method
of copier pulse detection as automatic or custom. If the
detection mode is automatic, then the interrupt source is
checked (M-16) to see if it was a falling edge of the
pulse, if it was then program flow continues to (M-19),
otherwise the interrupted program resumes execution. If
the detection mode is custom, then the pulse edge is
processed (M-18) to determine whether it represents a
valid copy pulse signal. If this is a valid copy pulse,
then the BIOS copier counter is incremented (M-19), and
the interrupted program is resumed (M-12).
The command processor (T-15) stored in (3-30)
processes all commands and responses over the
communications network (2) with the central computing
device (1). It provides the central computing device
- 20808~7
~3
full access to all memory locations, each of the local
databases, and programming registers of the controller
terminal through the communications network.
A very simplified framework for the command
processor (D) is shown in FIG. 9. After describing the
flowchart, a description of the different commands is
presented, but the syntax and exact protocol for the
commands and data will be omitted since they are
considered outside the scope of the present
specification.
Upon entry to the command processor (D) the reason
for its' being invoked is determined (D-1). If it has
been invoked because a message has been received on the
communications network (2), then program flow continues
at (D-2).
The current state of the command processor is
checked (D-2) to see if this unit is currently selected
by the central computing device for communications on the
network. If this unit is not currently selected, then
program flow continues to (D-3), otherwise it proceeds to
(D-6).
At (D-3) the message just received is checked to
determine if it is a select of the particular controller
terminal (3). The selection message is a unique sequence
of characters that contains the network address of the
unit being selected. If the message is not a selection
of the unit, then program control proceeds to (D-9). If
the message is a select however, the transmit driver of
the serial interface is enabled (D-4) to allow the
controller terminal (3) to transmit back to the central
computing device (1) through the communications network
(2).
2080807
Following this, a selection response message
indicating the unit serial number and network address is
sent (D-5) to the central computing device (1) to confirm
that a communications channel has been established with
the terminal (3). Then program execution proceeds to (D-
9) -
If the terminal (3) has already been selected, thenthe current message is checked (D-6) to see if it is an
explicit deselect, or selection of a different network
address implying a deselection. If this is a deselection
message, then the transmit driver of the serial interface
is disabled (D-7) and program flow continues to (D-9).
If the message is not a deselection, the command is
processed and a response is made to the central computing
device (1) if appropriate, then program flow continues to
(D-g).
At (D-9) the command processor is terminated for
this message, and program flow returns to the calling
program.
If the command processor has been invoked because of
a transmit buffer empty condition, program flow continues
at (D-10) from (D-l). The command processor transmit
program vector is checked (D-10) to see if it is
installed. If it is, then the address stored in the
transmit program vector is given program flow as a
subroutine. Following this operation, or if no transmit
program vector was installed, the command processor
exits, returning program flow to the calling program.
Most of the commands sent by the central computing
device (1) to the command processor follow the following
syntax/protocol: 1) command received (by the controller
terminal (3)), 2) data response or command confirmation
2080807
1~
(from the controller terminal (3)).
Certain commands, such as a memory dump, cause the
command processor to transmit a long stream of
uninterrupted data. This is accomplished in the command
processor by setting up a transmit program vector to a
program that sends a packet of data each time the last
packet is finished, and causing this program to remove
itself from the transmit program vector when complete.0
The following is a list of the relevant command
processor commands and a short description of their
function:
Hex Dump
This command allows the central computing device (1)
to request any section of memory to be transmitted
to it from the controller terminal (3).
Hex Load
This command allows the central computing device (1)
to load or set any memory location or area by
transmitting the hex data to any place in RAM
memory.
Clear Users
This command allows the central computing device (1)
to clear the local users database. This command
marks each user as deleted, but does not actually
erase the records. This is done to prevent user
exceptions from being cleared in case the user is
added again later.
Clear Accounts
This command allows the central computing device (1)
to clear the local accounts database. The accounts
are effectively erased and the end of the sorted
region is reset.
Clear Transactions
This command will purge all transactions in the
20808~7
16
local database, both reported and unreported to the
central computing device (1).
2080807
11
Send Transactions
This command will instruct the controller terminal
(3) to send those transactions that have not already
been sent to the central computing device (1). As
each transaction is sent, it is marked as having
been sent in the local transaction database.
Upload Account Record
This command is issued to send the controller
terminal (3) account records for addition to the
local accounts database.
Mark End of Sorted Accounts
This command is used to tell the controller terminal
(3) when the last of the account records in sorted
order has been sent. This is used by the controller
terminal to optimize searches of the account codes
in the accounts database.
Update User Record
This command is used to add or update a user record
in the local database. If the user is currently
marked as deleted, then it is restored as valid.
The class usage analysis results from the central
computing device (1) may be sent with the user
record using this command.
This marks the end of the description of the
controller terminal (3) and its component parts. The
remaining parts of the description of the preferred
embodiment are dedicated to describing the programs that
reside on the central computing device (1), and the
interaction of all elements of the system of the
invention to achieve the desired operation.
A program referred to as Super DataSys (SDS) resides
on the hard disk of the central computing device (1)
which is a collection of procedures combined with two
flexible methods of activating the various procedures .
The first method, called the menu sub-system, of invoking
2080807
1~
any of the procedures is through a programmable pull-down
style menu system which provides full interactive
selection and control of the procedures. The second
method of triggering the procedures, called the event
sub-system, is through a flexible time based scheduling
system with programable scripts that are interpreted by
the SDS program, which provides a facility for defining
automatic operations that occur at specified times or
intervals. All of the procedures are referenced by
unique numeric codes and some of them take arguments in
the form of a character string. Both the menu and event
sub-systems have the facility to reference the procedures
by the procedure reference number and provide the
procedure with a text argument.
The SDS program also provides a variety of
facilities for use by the procedures contained within it.
Included in these built-in facilities are; 1) functions
for database management and indexing for the databases
maintained on the hard disk, 2) primitives for
transmission and reception of signals to the RS-422
interface (communications network), 3) a standard
windowing and user interface module, 4) a programmable
record editor system for implementing virtually any
record based editing functions, 5) a programmable report
generator providing a standard facility for the creation
of reports, and 6) a facility for the display of large
text files to the screen with scrolling capabilities.
These facilities are considered basic building blocks for
applications and a wide range of implementations are
available and in use, and therefore will not be described
in detail herein.
FIG. 19 shows the simplified flowchart for the SDS
program. When the program is started, the first
operation is system initialization (N-l) where the
capabilities of the central computing device (1) are
20808~7
19
identified and the built-in facilities are initialized
for operation.
Next the default menu definition for the menu sub-
system is loaded (N-2). Following this, the default
event script for the event sub-system is loaded (N-3).
Step (N-4) displays the SDS screen with the current date
and time and the top line menu items.
Program flow is directed (N-5) to the event sub-
system which performs processing to determine if a
procedure is to be activated or not, and if so it returns
the procedure reference code and the character string
argument if one is defined. If the event sub-system
indicates that a procedure is to be activated, then
program flow continues to (N-9), otherwise it proceeds to
(N-6).
The menu sub-system is called at (N-6) and returns
an indication of whether a menu item was selected or not.
Like the call to the event sub-system, the menu sub-
system returns the procedure reference code and a
character string argument if an item was selected. If a
procedure was selected from the menu sub-system, then
program execution continues at (N-9).
The last operation in the primary loop of the
program is to test (N-7) if the program is to terminate
(termination is set by either the menu or event sub-
system). If not, the program flow returns to (N-4),
otherwise program flow continues to (N-8).
At (N-8) an orderly termination of the program is
implemented, ensuring that all open files are closed, and
any data not yet updated to disk is flushed, and program
flow is returned to the operating system.
2080807
Step (N-9) is executed whenever a procedure is
activated from the menu or event sub-systems. This step
sets the action pending flag to true, indicating that a
procedure is to be activated.
The next step (N-10) then sets the action pending
flag to false, as the action is about to be activated in
the next step. Program flow is then routed (N-11) to the
procedure selected by the current procedure reference
code. When program flow returns from the selected
procedure, the action pending flag is tested to see if
another procedure is to be activated. If this is the
case, then program flow returns to (N-10), otherwise
program flow returns to the main loop (N-4). The action
pending flag and the test (N-12) provides procedures with
the facility to "chain" other procedure codes to execute
immediately following their termination.
The following is a short description of all
procedures relevant to the invention in SDS that are
available to the menu and event sub-systems. The
procedures are listed in order of their assigned code. A
description is provided for each procedure, indicating
any parameters it accepts, along with an example of its
usage, where appropriate.
The procedures are divided into three broad classes;
interactive, report, and non-interactive. Interactive
procedures are those that require user input to execute,
whereas non-interactive procedures require no user input.
Report procedures are those procedures that produce
report output and are typically available as interactive
or non-interactive.
INTERACTIVE PROCEDURES
These procedures require user input in order to
2080807
gl
execute to completion. They are meant primarily for
access through the menu sub-system, and are not
particularly suitable for event activation.
AmtalNameEdit 1300
This procedure is a standard SDS editor that is used
to maintain the names that are assigned to the
communications network members. These names are used in
reports where a reference is made to a particular unit on
the network.
InitNet 1602
This procedure provides menu access to the
initialize network members procedure. The only
difference between this and the NetInitialize (13000) is
that this one prompts the user for the unit number to
initialize. Refer to NetInitialize (13000) for more
details on this procedure.
DumpFromNet 1603
This procedure allows a memory image to be
transferred from any network member to the SDS computer.
It requires the user to identify the unit that is to be
dumped, and the destination file name for the memory
image. The memory image is stored in ASCII format with a
checksum. This procedure determines the amount of memory
installed in the unit, and will always provide a full
memory image. Error detection/correction confidence is
very high for this procedure.
DumpToNet 1604
This procedure performs the opposite function of
DumpFromNet (1603). It will send a memory image file of
the same format as created by DumpFromNet (1603) and send
it to a particular network member. This procedure does
not check the compatibility of the destination unit with
the source of the memory image, so care must be taken
2080807
that the data being transferred is appropriate for the
destination network member. Again error
detection/correction confidence is high for t-his
procedure.
LoadScrollWin 1630
This simple procedure will load the SDS scroll
window with a text file that is specified by the user.
If there is something in the scroll window already, it
will be discarded, if the file is not found there will be
no change. If "CLEAR" is entered as the file name, this
procedure will simply clear the current scroll window.
EventEdit 1640
This is a standard SDS editor that is used to edit
the current Event file that is being used by the event
sub-system.
UnDoCopyPost 1661
This copy module utility allows the state of copy
transactions to be reset to error, which will cause them
to be processed as if they were just read from the
terminal (3). The range of transactions is between two
dates. This procedure is useful for creating new host
files from old transaction data, but care must be used
since this may cause duplicate posting. This procedure
can also be used to update charge allocation with a new
validation table, since each transaction that is unposted
will be reprocessed using the current validation table.
DoAction 1670
This general utility provides a method of activating
a particular Procedure by entering its' action code.
RemoveCopyDuplicates 1681
This copy module utility will scan the copies
transaction database over a date range and identify and
~ 2080807
remove any duplicate photocopy transactions. This
utility is provided for recovery from an duplicate
transaction situation. Duplicate transactions typically
occur when the same transactions have been imported from
disk more than once.
ShellToDos 1700
This general utility provides a method of suspending
execution of SDS and start a DOS session.
CopyErrorEdit 2100
This procedure is used to change the account code
for copy transactions that are flagged as errors. When
initiated, it requests the user code of the errors to
edit. It then reads all the error transactions for that
user and provides a standard SDS editor for changing the
account code allocations. Upon termination of the
editing session, any changed transactions are updated.
NOTE that the edited errors are not checked to see if
they are now correctly allocated, this function is
reserved for the procedure FixExceptions (17000).
UserEdit 4100
This procedure provides access to a standard SDS
editor for maintaining the user's database.
AccountEdit 4200
This procedure is a standard SDS editor that is used
to maintain the SDS database of accounts. Special note
should be made that any accounts added using this editor
are flagged as being entered from SDS, and transactions
referencing these accounts will not be sent to the host
~system until the host system indicates that they are
valid accounts. However, if an existing account is
edited, it will be saved as edited, even if the account
type has been changed to host-client or host
non-billable.
2080807
~/
ReadNetTransactionsDisk 11000
This Procedure will read a text file of
communications network transactions and place them in the
data base as if they came over the communications
network. This process asks for the file name and the
network address to attribute the data to.
REPORT PROCEDURES
Report procedures are grouped separately here since
they can be run interactively or directly from the event
sub-system. Each type of report is identified only once,
but two action codes are given. The first action code is
to be used to invoke the interactive version of the
report where the report interval and report destination
are requested from the user. The second action code (in
brackets, 9000 series) will invoke the non-interactive
version where the current interval is automatically
selected, and the output defaults to the printer and the
disk.
GblCpyRec_User(O,false) 3121 (9121)
This procedure activates the Global Copier Recovery
sorted by User report.
GblCpyRec_Acct(0,false) 3122 (9122)
This procedure activates the Global Copier Recovery
sorted by Account report.
GblCpyRec_Chron(0) 3123 (9123)
This procedure activates the Global Copier Recovery
sorted by Date report.
GblCpyRec_User(O,True) 3124 (9124)
This procedure activates the Non-Billable Copier
Recovery sorted by User report.
20808G7
g~'
GblCpyRec_Acct(O,True) 3125 (9125)
This procedure activates the Non-Billable Copier
Recovery sorted by Account report.
NBReport 3150 (9150)
This procedure activates the non-billable analysis
report.
NBReport_copier 3151 (9151)
This procedure activates the weekly non-billable
analysis by copier report.
AcctList_Code 3311 (9311)
This procedure activates the account list sorted by
account code report.
AcctList_Name 3312 (9312)
This procedure activates the account list sorted by
client name report.
AcctList_FLN 3313 (9313)
This procedure activates the account list sorted by
file lawyer code.
AcctList_CLN 3314 (9314)
This procedure activates the account list sorted by
client lawyer code.
AcctList_Added 3315 (9315)
This procedure activates the added account list
report. This is a report of all accounts added from the
host system since this report was last run.
UserList_Ext 3341 (9341)
This procedure activates the user list sorted by
extension report.
2080807
UserList_Code 3342 (9342)
This procedure activates the user list sorted by
user code report.
UserList_Name 3343 (9343)
This procedure activates the user list sorted by
user name report.
CopyErrorRep 3410 (9410)
This procedure activates the copy transactions error
report.
NON-INTERACTIVE PROCEDURES
These procedures do not require user input to
execute to completion. They can safely be activated from
either the menu or event sub-systems.
SetCurrentCompany 100 - 109
This procedure can be used to switch the current
company, but this function is primarily provided to set
the current company to 0, which is recognized by the
report generator as the global company. When the current
company is O, the reports will ignore the separation of
data between companies and provide consolidated reports.
This function saves the current company and this is
restored by the report generator after a report is
generated.
ChainEventFile 1000
This event is used by the Event sub-system to chain
to a new event file. It will accept the name of the new
event file to load in the text argument from the event
system. It will also store the current event file on a
stack for eventual return. It will not allow re-entrancy
of an Event file; that is, it is not possible to chain to
20808~7
-
~1
an Event file that is already on the stack. It will take
no action if a re-entrancy is attempted or if the Event
file could not be found.
ReturnFromEventFile 1010
This event is used by the Event sub-system to return
from a previous chain. It will take no action if the
event stack is empty or the previous event file could not
be loaded.
AboutSuperDataSys 1100
This procedure displays information about SDS.
Included in this is the serial number, the software
version, the license expiry, which modules are enabled,
and the type of host accounting system. This procedure
will exit upon a keypress or timeout.
Status 1200
This procedure shows the current status of SDS
including the amount of memory available (conventional
and EMS), the amount of disk space available, the status
of the expense recovery modules, and the status of the
communications network. This procedure will exit upon a
keypress or timeout.
RebuildValidIndex 1621
This procedure will delete the current index files
for the accounts database, and then proceed to rebuild
them from scratch from the accounts data file. This
procedure displays its progress as it executes.
RebuildUserIndex 1622
This procedure will delete the current index files
for the user's database, and then proceed to rebuild them
from scratch from the users data file. This procedure
displays its progress as it executes.
20808~
RebuildCopyIndex 1623
This procedure will delete the current index files
for the copy transactions database, and then proceed to
rebuild them from scratch from the copy transactions data
file. This procedure displays its progress as it
executes.
Surveycommunications network 10000
This Procedure will survey the communications
network through the serial port and the PC Bus (for FAX
operations) and update the network status portion of the
configuration table/file. This process occurs without
any indication to the user, and takes 3 to 8 seconds.
ReadNetTransactions 11000
This Procedure will poll every net member on
communications network and collect transactions.
Transactions are validated against the accounts database
and stored in the transaction database.
GetHostAccts 11100
This Procedure checks all the account information
from host file paths and updates the accounts database
accordingly. It displays its progress as it executes.
ReadClientFile 11200
This procedure is used to read a client file where
client names are not available in the host's validation
file, but are available as a separate client list. This
is a specialized event and should only be used under
direction of the manufacturer.
NetAddAccounts 12000
This procedure will broadcast all new accounts to
the communications network. It will mark each account as
being sent to the network once it has completed. This
procedure displays its progress as it executes. This
20~08~7
function should not be used if Maximum Accounts feature
is used since it will try to send all accounts to the
copier control devices.
NetInitialize 13000 - 13099
This procedure performs a network initialize without
user summaries (NB analysis) to the unit specified by the
last two digits of the code. ie 13001 initializes unit
number 1. Network Initialize clears all transactions from
the destination, and sends the entire list of accounts
and users. If MAXIMUM ACCOUNTS in the configuration is
non-zero, then it will only send the MAXIMUM ACCOUNTS
most recently used accounts.
NetInitialize 13100 - 13199
Same as above, but includes user summaries (NB
analysis.)
PrepareHostFile 16000
This procedure will write all validated transactions
to the host files for each of copy, phone, and fax
transactions. As soon as transactions are written to the
host file, they are marked as posted.
FixExceptions 17000
This procedure will check every error transaction in
the SDS databases to see if they are now valid, if they
are found to be valid, the database is updated
accordingly.
UserNBAccum 18000
This procedure performs an analysis of all users'
transactions over a period which is placed in the first
10 characters of the Text Argument field of the event
that triggered this procedure. For example, for an
analysis over the past two weeks, the text argument would
be 0000140000 indicating 14 days. The result of the
20808~7
q~
analysis is placed in the user record for each user.
This information can then be used by NetInitialize
(13100-13199) or NetUpdateUsers (20100-20199).
SDSExec 19000
This procedure will perform and Exec (Run a program)
using the Text Argument as an argument. For Example if
Text Argument = 'SDSUTIL.EXE' then this procedure will
run the program SDSUTIL.EXE and then return to SDS. This
procedure should only be activated by the event
sub-system. To use Exec to run batch files, a new
iteration of command.com must be run with the /c option
to interpret the batch file. Also, a path must be
provided for DOS to find Command.Com. Example: In order
to run the batch file test.bat, the following must be
entered as a text argument: C:\Command.Com /c TEST.BAT
NetUpdateUsers 20000 - 20099
This procedure will update the user table of the
unit specified by the last two digits of the procedure
code. If the last two digits are 99, then it will
initialize all units on the communications network in
sequence. This procedure will NOT include user summaries
(NB analysis.)
NetUpdateUsers 20100 - 20199
This procedure will update the user table of the
unit specified by the last two digits of the procedure
code. If the last two digits are 99, then it will
initialize all units on the communications network in
sequence. This procedure will include user summaries (NB
analysis.)
ReadUserFile 22000
This special function procedure will read SP4 format
user table from the file USERS.SDS into the SDS database.
Only new user codes are accepted from the file,
2080807
ql
duplication is not a concern. This procedure then
activates RebuildUserIndex (1622) in order to clean up
the user file.
TABLE III shows a list of the procedures that are
typically activated in the course of normal operation of
the system.
TABLB III
TYPICAL 8D8 OPBRATION8
Automatic (Activ~ted by Bvent 8ub-8ystem~
(Hourly, or when first run)
10000 Survey communications
network.
11000 Read Transactions from all
Units on communications
network.
20199 Send User Table to all
controller terminals on
communications network.
11100 Read Validation files and
make any additions or
deletions as necessary to
the account database.
12000 Send any new accounts to
all units on communications
network.
(Nightly)
10000 Survey communications
network.
11000 Read Transactions for all
units on communications
2080807
q~
network.
18000 Perform central account
class usage analysis for
each user.
13199 Initialize all units on
communications network;
send sorted list of
accounts, and send user
list with central recovery
level analysis results.
17000 Try to validate any matter
code errors by comparison
to updated account
database.
16000 Produce file of
transactions to be posted
to the host accounting
system.
20 Manual (Activated by lI-nu 8ub-8ystem)
(Daily)
1200 Check the status of the
communications network and SDS to
make sure things are running.
3410 Produce a copier error report for
distribution to the users.
2100 Enter any returned copier error
reports in to the system for
correction.
(Weekly)
3123 Copier recovery detail report sorted
by date.
3151 Non-Billable analysis by photocopier
report.
3150 Non-Billable analysis by user report.
20808~7
93
(As Required)
4100 Edit the central users database.
4200 Edit the central accounts database.
The list in TABLE III is broken into two sections,
one being those actions triggered automatically by the
event sub-system and the other being those operations
triggered by the operator through the menu sub-system.
In each section, some indication is given of the
frequency or timing of the operation.
This table of typical operations is only an example
of the operations that may occur with any use of the
system according to the present invention, but a wide
variety of implementations is available to the installer
and operator to meet the differing needs of companies
using the system.
In the section of TABLE III listing the automatic
operations, the first set of procedures are activated in
turn when the program is first started, and every hour
thereafter. The first operation is (10000) survey the
communications network for all devices connected to it.
Following this, any transactions in the local
databases of the controller terminals connected to the
communications network are collected (11000) and stored
in the central database.
The list of user records including the most recent
account class analysis is then transmitted (20199) to all
the controller terminals on the network.
The files from the host accounting system are then
checked to see if there are any additions, changes, or
deletions required to the accounts database. If
20808Q7
qS~
modifications are required, then the files are processed
and the accounts database updated accordingly.
The Add Accounts procedure is called as the last
hourly procedure, and it transmits any new accounts in
the accounts database to each of the controller terminals
on the network.
On a nightly basis, the list of procedures starts
with another survey of the network and transactions from
all of the controller terminals are read into the central
transaction database.
The next step taken is to perform the central
account class usage analysis, and store the results to
the user database. Once this is complete, each of the
controller terminals (3) is provided with an entire list
of the accounts database in sorted order, as well as the
entire list of user records. This process is required on
a regular basis to provide the terminals (3) with a
sorted list of accounts, allowing each terminal to
perform its operations more quickly.
A procedure is then activated which processes the
"error" transactions as a batch in an attempt to correct
them. Error transactions are transactions for which no
matching account code can be found in the central
accounts dat~h~c~. Examples of error transactions are
those that are allocated to new accounts not yet provided
by the host accounting system, those that used the
override class of accounts, or using incorrect account
codes entered through soft or syntax validation means.
As new accounts may arrive from the host accounting
system, be entered manually to the accounts database, or
the account code allocation of the error transactions may
be changed, this procedure is used regularly to reconcile
2080807
q5
the changes by correcting any transactions possible.
The last of the nightly operations is to produce or
update the file of transactions being provided to the
host accounting system. Once a transaction has been sent
to this file, SDS marks it as having been posted so that
it will not be sent to the accounting system.
Transactions are typically posted only after they are
validated against the accounts database, thus preventing
error transactions from being sent to the accounting
system, only to have them rejected.
The manual operations of SDS are usually performed
by one or two operators of the system of the present
invention for the purpose of system management and
monitoring.
On a daily basis, most operators would inspect the
status screen of SDS to ensure that everything is
operating. An operator may also produce error reports
for distribution to the users of the invention so that
any uses of client name or account code errors could be
properly allocated. If such reports are produced, it is
expected that they will also need to enter the
corrections from the previous set of reports they issued,
so they will use the copier error editor to enter the
corrections provided by the office staff.
On a weekly basis, most operators will require
reports for archiving hardcopy of the transactions, and
to monitor the performance and overall usage of the
system according to the present invention. Of further
interest to many operators is a weekly non-billable class
usage analysis sorted by person, which the operator can
use to strategically configure the system to curb abuse
of the non-billable charges and improve recovery levels.
2080807
-
9~
From time to time is further expected that the
operator will have to maintain the accounts and user
databases to make additions, changes, and deletions to
reflect the changing environment of the company using the
system of the invention.
Modifications and variations of the invention are
possible. For example, the function keys F1, F2, F3 and
F4 can be replaced by a touch sensitive screen (3-26), or
by a generalized pointer device and menu system. In
addition, although the various programs ahve been
described herein as being executed on predetermined ones
of either the central computing device (1) or the
controller terminal (3), the location for storage of and
execution of said programs in not essential to the
invention. For example , in a distributed processing
embodiment of the invention, such programs and the
algorithms embodied thereby may be executed at various
locations within the system,
These and other modifications and variations are
beleived to be within the sphere and scope of the
invention as defined by the claims appended hereto.
