CA2036172E - Expense management system - Google Patents

Abstract

A system for controlling user access to a device, comprising:
a) means for storing a plurality of valid user access codes;
b) means for storing a plurality of user records, each record incorporating charge recovery data representing user charges for use of said device to a non-billable account class;
c) means for a usage limit value for non-billable account class;
d) means for receiving a first user input from a user desirous of gaining access to use of said device;
e) means for comparing said first user input with respective ones of said plurality of valid user access codes and, in the event of a match then retrieving a predetermined one of said user records associated with said user, and in the absence of a match denying said user access to said device;
f) means for storing a plurality of valid account codes and one or more non-billable account codes;
g) means for receiving a second user input from said user for allocating a charge to be incurred upon using said device;
h) means for comparing said second user input with respective ones of said plurality of valid account codes and said one or more non-billable account codes and, in the event said second user input matches one of said valid account codes then enabling said device for usage by said user, and in the event said second user input matches one of said non-billable account codes then comparing said charge recovery data incorporated in said predetermined one of said user records with said usage limit value and, in the event said charge recovery data is less than said usage limit value then enabling said device for usage by said user, and in the event said charge recovery data is greater than said usage limit then interfering with access of said user to said device.

Description

-EXPENSE MANAGEMENT SYSTEM

FIELD OF THE I~v~NllON

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 lNV~. llON

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, thollcAn~s of dollars are lost every month due to such misuse.

In addition, file codes arè often incorrectly entered such that device usage charges accrue to incorrectly listed clients or matters.
One approach to overcoming these problems involves the use of a terminal controller connected to the device (e.g. photocopier) which monitors the r ecovery 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 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 s~con~ 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 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 T~E lNv~NllON

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: n 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 20~6 J 7,2 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 user's performance standards and intercedes or interferes with usage of the device in such circumstances by applying various "user sanctions"
for providing "moral suasion" designed to increase the user's awareness of the expenses that he or she is charging to the office (and therefore his or her sense of responsibility). These user sanctions for providing moral suasion may include requesting that the user consider charging a client for the device usage, reminding the user of the options available for charging a client instead of the office, slowing the user's 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 .~ , -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 of up to thirty characters in length and to assign a maximum number of such descriptions 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 entered descriptions to reflect the appropriate file codes, which can be provided by the users after the fact.
The system of the invention may be programmed to recalculate the user recovery performance analysis to take into an account any manually entered descriptions which were subsequently charged to a valid client file code.

Where the device to be used is centrally located and administered by a clerk (eg. copy center photocopier), the system of the invention can also control access to the device by means of a clerk access password, and by having the clerk search for the proper requesting user's identification 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 detect instances where a user has used the manually entered description option to charge "office" expenses, thereby circumventing the user sanctions.

The system is capable of removing the privilege of -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 ~G~ammed 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 ter_inal 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 Q~K1~ layout keyboard (for text entry), and a terminal size which does not violate accepted industry norms.

The keyboard design of the preferred emho~iment 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 user identity and usage patterns. In other words, the function keys take on different function 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 facilitate the juxtaposition of the keys next to their respect labels regardless of the users height.
According to an aspect of the present invention, there is provided a system for controlling user access to one or more devices for the purpose of accounting for the use of said one or more devices, comprising:
a) means for storing a plurality of account codes of a plurality of predetermined account classes, individual ones of said account classes being defined so as to provide one of either unlimited or limited access to said one or more devices;
b) means for determined one of either actual or estimated charge recovery data representing user charges for use of said one or more devices to said plurality of predetermined account classes;
c) means associated with said one or more devices for receiving a first user input for identifying a user desirous of gaining access to use of a particular one of said one or more devices;
d) means associated with said one or more devices for receiving a second user input from said user for allocating a charge to be incurred upon using said particular one or more devices; and e) means responsive to receipt of said second user input for comparing said second user input with respective ones of said plurality of account codes and, in the event said second user input matches one of said account codes of one of said account classes which is defined so as to provide unlimited access to said one or more devices then enabling said particular device by said 2~172 user, and in the event said second user input matchec one of said account codes of one of said account classe~
which are defined 60 ac to provide limited acce~s to ~aid one or more devices then retrieving and di6playing ~aid one of either actual or estimated charge recovery data to said user at said particular devicQ, thereby providing moral suasion for ~aid u~er to allocatQ said charge to ~e incurred to one of said plurality of account codes of one of caid account classes which are defined ~o as to provide unlimited access to said one or more devices According to yet another aspect of tho present invention there is provided a system for controlling user acces~ to one or mor- d-vice- for the purpo-- of accounting for the use of said on- or more device~, comprising:
a) mQ~ns for ~toring a plurality of account code~
of a plurality of predetermined accou ~ cla~se~, individual ones of said account claases being defined fiO
as to provide predetermined degrees of limited access to ~aid one or more devicQs;
b) means for determining on- of either actual or estimated charge ~c:v~ry data ~e~ ~enting user charge~
for u~e Or said on- or more devices to said plurality of predetermined a~co~ ~ clas~es;
c) mean~ associated with ~aid on- or more devices for receiving a first user input for identifying a user de~irous of gaining access to u~e of a particular one of said one or more devices;
d) means associated with said on- or more devices for receiving a second user input fro~ said u er for allocating a charge to be incurred upon u~ing ~aid particular one of said on- or more device-; and e) mean~ respon-iv- to receipt of ~aid sQcond user input for comparing said second user input with re~pective ones of said plurality of a~o~ ~ codes and, in the event said ~e:~n~ u~er input matche~ one of said account codes of an account class which i~ defined so as 2~361~2 8a to provide a lowest one of said predetermined degrees of limited access to said one or more devices then enablinq said particular device for usage by said user, and in the event said second user input matches one of said account codes of one of said account classes which are defined ~o a~ to provide other than said lowest one of aaid predstermined degrees o~ limited access to said one or more devices then retrieving and displaying said one of either actual or estimat~d charge recovery data to said user at said particular device, thereby providing moral suasion for said u~er to allocate ~aid charge to be incurrQd to on~ of said plurality of acc~ codes of ~aid account cla~s which is defin~d ~o a~ to provid~ said lowest on~ of ~aid præd~termined dc~ o~ limited access to said one or more d~vico~.

BRIEF DESCRIPTION OF THE DRAWINGS

20 FIG. 1 is a block connection diagram of an expense management ~y~tem according to the preferred embodiment of the invention.
FIG. 2 iS a block electrical diagra~ of a device controll~r terminal in accordanc~ with th~
sy~tem o~ the preferr~d m~oA~ment.
FIG. 3 iS a mechanical drawing o~ the devic~
CG..LLoll~r o~ FIG. 2.
FIG. 4 i5 an el~ctrical diagram o~ a communications network forming part of the syste_ according to the pre~erred embodinent.
FIG. 5 is a block diagram of the elements comprising a central computing d~vic~ ~orming part o~ the sy~t~ according to the pr~err~d embodlment.
FIG. C is a ~lowchart o~ a ~ir~t ~G~C ~or 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 ~rGyLam 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 d~pen~ng 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 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 finiSh~ 0 FIG. 19 is a flowchart of a fourteenth regularly executed program according to the preferred embodiment.

With reference to FIG.1, an ~Yp~e 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 terminàls (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 co~ ol.

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) 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 co~ ol 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 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 comprisinq 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 108~ 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 RAN
addressing, and 64 KByte I/O space addressing. The data, address, and control lines are collectively labelled as (3-16). The block labelled (3-17) also includes the ~ '~ logic, memory and I/O address ~eco~ing~ 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 four conductors. The two receive conductors (3-143 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 h~nAch~king 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 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 S 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 hav~ng 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 cor-LLolled 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 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 ehAp~r, 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). A~ 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 di~^llc~e~ since the nature of these signals and controls would be understood by a person skilled in the art.

Referring now to TABLE I, along with FIG. 2, the memory elements of the controller terminal (3) will be described.

7~03617~

l L~ ~_ T~

Tt~t ~OOOO EOOOO
R~ r~, .t T.2 ~ Frt ~, ~ U~d ~

~t T-.~ r C~t~n IPt~etu~r ~t ~tt~rt T.~ r ~ r. ~
~ ' So~U ~ ~.,7 r r.~ ~ EOOOO
TJ ~O lV~ ~rei ~t 0-~

.tv~ ~, ~ U 00 ~hlr T.-1 ~Cu~l l;TI h ~t y~ -T 11 ~ V~

M~
~ddr -(HEX

~03S17~
-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 de~n~;ng 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 ~UL~OS e for this is to provide a means of removing the RAM for service or device swap ~U1 ~OSeS, while still maint~ining the integrity of the data.

The last region of memory in the co,.LLoller terminal (3) i the ~ G~ am 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 ~rGyLam.

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 2036~72 -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 datAhAc~ (T-3), 3) the unsorted region of the account record datAhAs~
(T-18), 4) the free (unallocated) memory region (T-2), and 5) the transaction record datAhAæe (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 controller terminal (3), 2) the fo~e~Lound application program (T-16) which implements the interactive process with the user, and 3) the 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-l5),(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 ~pp~Ar. 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 t2). 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 Fl 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 ~W~K'l'~ 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 203617~

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 n_>-- 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 ~Kl~ 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 F1, 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 ` 2036172 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 A;-c~l~ced 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 st~ndArd, 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 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.

Me~hA~ically, 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-1J, 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 merhAnical connection to the controller terminal of the cQnA~lctors (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 (l) connected to the Tx pair (2-11, 2-12) of the ~ oller 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 co~ oller terminal (3). This is consistent with the master/slave configuration so that whatever the master (1) transmits i~ 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 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).

T~

USER RECOROS O~ABASE

~7 A~`~OUNT RcCOhOS O~T~ASE

U~
COPY TnANS.~CTlONS DATABSE
U-S
VALID ~CCOUNTS FILES FROM HOT ~CCOUNTING
SYSTEM

TFtANSACTlONS Wl~lTlNG TO BE ROSTED TO HOST
ACCOUNTING SYSTEM

SDS PROGR~M ~ CONflGURATlON FILES
TEMPOR~RY FILES TOO

OTHER STOR~GE ARE~S OF FIXED DISK:
OPER~TING SYSTEM
- OTHER PROGR~MS AND DATA
SYSTEM FLES
- UNUSED STOR~GE SPACE

U-l The operating system, system files, unused storage, and any programs generic to the computing device itself, are represented by the section (U-l) 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 dat~h~ses that are maintained by the system of the present invention. These dat~hAs^- include; 1) a file cont~;n;ng 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 accounting 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 dat~h~re of all the current valid accuu,,~ 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 ac~oul.L class usage analysis results.
A further description of the data structures which are used and their operation will follow in the ~;~cu~cion 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 ~G~Lam (T-17) in TABLE I, which i~ used extensively by the "high-level" application programs (T-16). The BIOS ~o~-am implements the majority of the control and monitoring tasks over the electrical circuitry in the controller terminal (3). The BIOS

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 t3-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 i~
implemented by sc~nning 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 "offn, if "on" the service causes a "*" to appear instead of the character typed, and 2) the maximum number of characters which are allowed to be typed. This service uses the previous ._ 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 h~h i n~ 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 transi~tor. Further, the "get character service" turns off the EL backlighting panel when a timeout o~ , again by accessing the parallel interface circuit. These two additional functions built into the keyboard BIOS functions provide a means to greatly im~rove 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 t~hnology EL panels is about 4500 hours on-time, which result~ 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 (dep~n~i ng 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-25) to deliver commands to the LCD display (3-26).

203~17~
_ 2~
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 heep~r (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 .

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-1), the command proce~or 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 s~ccescful, then flow control continues to (A-5) which represents an entry into the application ~LG~am (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).

_ 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 ~o~e~sor, 3) the number of users in the local user datAhAre, 4) the number of accounts in the local accounts dat~h~, 5) the number of current transactions in the local transaction datAhAr?, and 6) the percentage free memory and the total capacity of the data and configuration memory.

The F3 key is tested at (A-11), 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 entered is zero, then program flow returns to (A-5), otherwise it continues to tA-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-l9), otherwise the invalid user code screen is displayed (A-lS 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-l9) 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 i8. 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 ~ G~L amming 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 datAhA~e as the current user and the copy job procedure (C) is invoked.

2036~72 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 S 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 ao~o~.~ 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 20~172 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 O 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 CcAnning 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 u~er 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; F1 = 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 203i~172 .

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 datAhAc~, and this record is then made the current record. If Fl (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 datAhA~-~ 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 acces~ 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/dat~hAs~c/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-l) the function keys Fl 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 203617~

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 ~o~ams that are acc~sce~ 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 merh~nics 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 , 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 (Fl S = ADD/EDIT), 2) Delete a user (F2 = DE~ETE), 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 datAhAc~, 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 dat~h~se 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) (F1 =
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 ~o 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).

.

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:

Mask Character Will Match:
A to Z ~nd space If the character is an exact match.
o 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) AZl would not match either because there is only one digit following the AZ, and the mask expression requires 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) (Fl = "PRICE), 2) set user validation exception (B-10) (F2 = "VALIDATION"), 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 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 a~L~liate fields of the user record in the local user da~hA~ .

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.
Thi~ is implemented by setting the non-billable mode fields in the user record in the local user database.

_.

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 the "ACCOUNT MAINTENANCE MENU" (B-13) with the following options; 1) add or edit an account (B-14) (Fl =
"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 datAhAse, 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 a~coul,L code. When a new account is added the accou,lL 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 datAhAce 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 a~o~ 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 203617~
. .

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) (F1 = "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 dep~ing 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).

._ 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 S 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) tF2 5 "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 diA~ s individually in the subsequent paragraphs.

The "DEFAULTS MENU" (B-29) provides access to fundamental parameters and tables that control the default operations and ~rG~am 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 = ~v~TTn~TIoN~ 2) enter the "ACC~Dl.l DEFAULTS MENU" (B-31) (F2 = nACCOUNTS"), 3) set the default transaction description mode and/or length (B-35) (F3 - "TRANSACTIONSn), and 4) select the "SPECIAL
DEFAULTS MENU" (B-36) (F4 = "SPECIALn).

-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) tFl = "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").

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-BTrT~ART~n)~ 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) (Fl = "PERIOD"), 2) set the non-billable alternate account class screens (B-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 Ah~n~on the non-billable charge, 2) a screen which prompts the user to search for a client code instead of procee~;ng with a non-billable charge, and 3) a screen which prompts the user to enter a client name (override class accou.lL) 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) - 203617~

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.

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) (Fl = "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 secQn~.

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) (Fl = "NAME"), 2) set the company name (B-46) (F2 = "COMPANYn), 3) set the photocopier access code and 203617~
-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 dat~hA-e~ 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 OO to 99 corresponding to the wait time in 1/10Oths of a second between sensing successive photocopy pulses as pages.
This facility for custom photocopier interfaces provides for accommodating page count signals from photocopiers 20361~

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 a~oul.~ class usage analysis subroutine (E) for the current user, described later.

Upon completion of the analysis, it displays (C-1) the a~o~l.L 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 (Fl = "HELPn), 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"), otherwi~e flow control continues to (C-5).

The system then waits for a string to be entered as an ac O~ code, or for a function key to be pressed, if a timeout occurs while waiting for input then flow control ~oc~r~l~ to (X) where the account code entry subroutine terminates.
If Fl (HELP) is pressed then the help screen is displayed (C-4) and program flow returns to (Z), the re-_ 203617~

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 (SEA~CH) 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 procee~s to (C-10) where the length of the entered string is checked.
If no characters were typed, then ~y~am flow proce~-s 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) to the local user database, or a "standalone" analysis.

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 datAhace 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-11).
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 a~o~iate 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 dataha~e is reached, then program flow prore~C to (E-11).

The step (E-11) 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:

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 ~G~am control. The ~G~am 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 dat~h~c~, if the local database is empty then pLG~-am flow continues to (F-5).

The current transaction is then checke~ (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 proc~e~c to (F-6). If the current user and transactions do not match, then the next most recent transaction is loaded (F-4) and ~Loy~dm flow ~eLULn8 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 a~coul.L could be found for the current user, and ~ro~Lam flow is directed to the a~cou~,~ code entry routine re-entry point (Z)-When a last account is found in step (F-2), step -(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 ~Lo~Lam 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).

~03617~

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 O then a new account record is composed in the following manner;
1) the account code for the override account i8 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 acco~,L 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 ac~o~ 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 203617~

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 acco~,L 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 wa~ 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 a~cou-,L name (assuming account names exist) along with the following function key options available at this point; 1) switch to account code based search method (Fl = nCODE-SRCHn), 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").

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-ll) 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 Fl key (CODE-SRCH) is then tested (H-14).
Discussion on swit~hing search modes is ~i~cllcsed 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 le~ULI~S to (H-4) to perform a subsequent search operation.

If the current record is selected, then the current record is loaded as the current a~ou~.~ (H-16) and program f low continues to the acc~ code validation ~G~r am (I).

The account code mode of the interactive local accounts datAh~? search program provides closest match searching of all of the account code~ in the local database, and scrolling of the datAh~e records in an alpha-numeric ordering of the account records by account code.

2~36172 _ 55 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 datAhA~e 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 a~co~l~s datAh~sQ.

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 (Fl = "NAME-SRCHn), 2) display the previous acco~ record (F2 = "PREVIOUSn), 3) display the next account record (F3 = nNEXTn), and 4) cancel the search operation (F4 = "CANCEL").

The system then waits for user input, and if a timeout o ~L~ or F4 (CANCEL) is pressed then ~oy-am flow returns to the re-entry point (Z). The user input is first ch~ck~ for a string entry, if a string of character~ was entered then this string is made (H-22) the current search string.

The F3 (NEXT) key is then chPcke~ (H-23), if it was pressed then the current record is ir.cremented (H-24) if possible, and ~Gy,am flow returns to (H-l9).
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.

-Next, the user input is checked (H-29) to see whether an H Enter H key was pressed, which indicates that the current record is to be selected. If the H
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 a~-ou~.~ codes in the local datAh~e matc~ing 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 2~3~172 , -AB", 2~ the exact match or closest higher match to "AB"
is then displayed, 3) Fl 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. "OAB10"), 5) the name search program waits for scrolling, subsequent keyword searches on the a~ou.l~ name, or account record selection.

Once an account has been selected as the current ac~ou~.L by the user through direct entry, last account, or search, program flow continues to the accou..~ code validation program (I). This validation ~r ~ am 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 ~G~amming, 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 ~Gy~am is to compare (I-1) the current user and the current account combination with all of the user/account restriction~ stared 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 ~lG~Lam flow returns to the re-entry point (z)-The next operation performed is a search to locatethe current accou.,L code in the local accounts datAhA~Q
(I-3). If the account code is not found, then ~G~am execution continues to (I-8). If it is found however, the current account code is checked (I-5) for hold 203617~

status. If the account is held, then a me5sage 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, ~G~lam flow i~
diverted to the non-billable event ~LGyLam means (K).
If the acceptable non-billable class usage has not been eYc~e~ed, the ~L G~ram flow continues to the transaction preparation program (J).

When the current account is not found in the local datAhAc~, 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 i8 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 acco~ matches the validation syntax, then program flow continues to (I-13), otherwise a message s displayed (I-12) indicating that the entered account code does not match the required syntax, and 2036~7~

program flow is returned to the re-entry point (Z).

When tI-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 procee~ to (~-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 c~ke~ (I-15). If account descriptions are forced, then the program continues to (I-16), otherwise it pror~eAC to (I-17). At (I-16), the system prompts the user to enter the ac~o~.~ name and stores it to the current a~cu~.L and ~Lo~ to (I-17).

At (I-17) the current a~o~llL is stored to the accounts datAhA~ 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 datAhA~.

Finally, the newly created account code LecG~ is stored (I-18) as the current a~o~.L for the transaction, and program flow continues to the transaction preparation ~am (J).

When a user is past the allowable limit for non-billable account class usage, and that user selects a non-billable class acco~ , the non-billable event program (X) is activated. This y G~ am means is shown in a flowchart in FIG. 16 and is described herein.

The action taken i~ comprised of two stages; 1) provide the user with an O~G~ ~unity to select an alternate class of account, and 2) if the user does not choose an alternate class of account, provide some 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-1) 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) charge to a client (F3 = nYESn), and 2) do not charge to a client (F4 = nNO~).

If the user terminates the input (K-3) with anything but F4 (NO) or a timeout O~ , then ~lGyLam flow ~u~ to the re-entry point (Z), otherwise program flow continues to (K-4).

The "search" screen is then checked (R-4) to see if it is enabled, using the same methodology as th~ "status"
screen. If it i8 enabled, then the u~er is prompted (K-5) to search for a client code and a~ked to type "NO" or use the F4 (F4 = n SEARCH~) key to activate the search program means.

If a timeout occurs or F4 (SEARCH) is pressed (K-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 proc~eA~ 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 = "CLIEN-T 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 i8 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 "warningn, then ~G~Lam flow proceeds to the transaction preparation program (J) without further impediment.

If the mode is "restrict", then a message (K-ll) is displayed indicating that the user has PYcee~ed allowable non-billable usage limits and that non-billable class accounts privileges are temporarily susp~n~e~, and ~L G~ am 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 203617~

following two function key options; 1) display help (Fl =
"HELPn), and 2) cancel this photocopy job (F4 =
"CANCEL"). If Fl (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.
P~ V~L am flow then continues to the transaction preparation ~GyLam (J).

The non-billable delay (K-14) is not actually required for the ~ystem 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 cla~s of accounts. It should be noted that if the delay period is set to o 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 nu~ber of page~ being photocopied, the transaction preparation ~o~Lam (J) is called. Thi~ p~G~Lam complete~ 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-l). If it is, then ~ Lam flow continues to (J-2), otherwise it prscee~ to (J-5).

203~172 , 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-S).

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 ~ ented with two function key options; 1) confirm this account (Fl =
"CO~rl~I"), and cancel this account (F4 = nCANCEL"). If the account is confirmed (J-4) with Fl (COhrl~.) then program flow continues to (J-5), otherwise if F4 (CANCEL) is pressed, then ~oyLam flow is Le~L~ to the re-entry point (Z).

Once the account is confirmed, the ~ OyL am identifies the pricing table to be used. Pricing can be determined by a special a~co~-L price, a special user price, or the system default price, where the accou~-~ 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 ~G~Lam flow continues to (J-10).

If no special account price has been identified, 203617~

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 ~LG~ram 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 procee~ing 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 continue~ to (J-ll), otherwise ~o~am flow is routed to the copy job program (L).

At (J-ll) it is determined whether a transaction description has already been entered due to a nonbillable event in describe mode. If the transaction description ha~ already be entered, then program flow continues to the copy job ~oy~am (L). The transaction description is otherwise prompted for at (J-12), and sllh~e~uently accepted and stored to the current transaction at (J-13), after which ~o~Lam flow continues to the copy job ~v~am (L).

The copy job program (L), shown in FIG. 18 a~ a flowchart, performs actual monitoring of the photocopy usage, displaying of copy ~oy,ess, and storing of the _ 2036172 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 (O at this point), 5) the total value of the transaction (also o at this point).

Further, the following three function key options are displayed; 1) end this transaction and select the next ac~ou,~ to charge maintaining the current user (Fl =
NEXT ACCT."), 2) extend the system timeout (F2 =
~l~N~n), and 3) end this transaction and log off current user (F4 = "ENDn).

The job interrupt flag in the fote~ound 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 = nJOB lNl~KK~ln.

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 ~rc~m 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 tho~e copies.
The copy job timeout is then proc~ee~, and if the number of copies has in the last execution of (L-5) been 2036i72 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 Fl (NEXT ACCT.) key (L-10). If it has been pressed, then flow control is routed to (L-ll), 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 ac-~oul.L code re-entry exit point (Z).

The last key to be checked (L-13) is F3 (JOB
lNl~KK~'l), if this key has been pressed and the job interrupt flag is inactive ~L-14) then ~rGy.am flow 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 ~ob so that a new one may be started, while the original job is s~ p~n~ed. The first 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 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 ac-~ou"~ 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 Fl (NEXT ACCT.), the photocopier gets disabled (L-8) or (L-ll), and the current transaction is stQred to the local transaction datAhA~ (L-9) or (L-12). The storage of the transaction to the local datAhA~e will nor be discus6ed 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 203~17Z

following fields which constitute the information stored for each transaction:

1) The exact date and time that the transaction 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 O 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 ~G~Lam (T-16) stored in (3-30). The last ~G~am, the interrupt system and command processor (T-15), that is stored in the ~ G~ram storage ROM (3-30), will now be described.

FIG. 8 i8 a flowchart of the interrupt handler ~G~Lam (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 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-1) 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~h~ki~g 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 ~am is resumed.

If no break was detected, then the data received is compared (M-6) with the number " 13 n, 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 35 subsequent action is to resume execution (M-7) of the interrupted program.

20~6~72 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 h~n~hAking 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 han~chAking 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 ~G~ r am.

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 process~ (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-l9), and the interrupted ~L Gy r am is resumed (M-12).

The command prorcssor (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 20~172 .

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-l). 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 proce~ 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 i8 not a selection of the unit, then program control pLor~ to (D-s). 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).

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 aee 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 i8 not a deselection, the command is proc~Cce~ and a response is made to the central computing device (1) if a~u~riate, then program flow continues to (D-g).

At (D-9) the command procescor 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 proceC^Qr transmit program vector is checked (D-10) to see if it is installed. If it is, then the address stored in the transmit ~ GyLam vector i8. given program flow as a subroutine. Following this operation, or if no transmit program vector was installed, the command pro~C^or exits, returning ~Gy~am 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 203617~

(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 f; n; she~, and causing this program to remove itself from the transmit program vector when complete.
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 dat~h~q. This command markR 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 accoul-~s are effectively erased and the end of the sorted region is reset.
Clear Transactions This command will purge all transactions in the - 2~3~172 local database, both reported and unreported to the central computing device (1).

- 20361~2 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 dat~hAce.
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 ~ol.LLoller terminal (3) and its component parts. The remaining parts of the description of the preferred emho~iment 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 203617~

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 stAn~Ard windowing and user interface module, 4) a ~ O~L ammable record editor system for implementing virtually any record based editing functions, 5) a programmable report generator providing a stAn~Ard 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 show~ the simplified flowchart for the SDS
program. When the program is started, the first operation is system initialization (N-1) where the capabilities of the central computing device (1) are 203617~
, ............................... .

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 ~L O~ed~L e reference code and a character string argument if an item was selected. If a procedure was selected from the menu sub ~ em, 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 ~LGyLam is implemented, ensuring that all open files are closed, and any data not yet updated to disk is flushed, and ~-G~Lam flow is returned to the operating system.

203617~
-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. ~LG~ram flow is then routed (N-11) to the procedure selected by the current procedure reference code. When program flow returns from the selected proced~e, 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 ~LG~Lam flow returns to the main loop (N-4). The action p~n~ing flag and the test (N-12) provides procedures with the facility to "chain" other pLo~edure 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 pLocedu~e, indicating any parameters it accepts, along with an example of its usage, where appropriate.

The yLGccdures are divided into three broad classes;
interactive, report, and non-interactive. Interactive ~oc~ es are those that require user input to execute, whereas non-interactive procedures require no user input.
Report ~ G~ed~res are those proce~u~e~ that produce Le~o~ L output and are typically available as interactive or non-interactive.

INTERACTIVE PROCEDURES

These procedures require user input in order to 20~617~
-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 st~n~rd 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 that the data being transferred is appropriate for the destination network member. Again error detection/correction confidence is high for this 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 proreCFe~ as if they were just read from the terminal (3). The range of transactions is between two dates. This prore~llre 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 u~ed to update charge allocation with a new validation table, since each transaction that is unposted will be re~ G~e-:se~ 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 datAhA~e over a date range and identify and -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 error 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 s~n~Ard SDS editor for changing the aocou~lL 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 proced~le provides access to a stA~rd SDS
editor for maintaining the user's datAhAsD.

Ac~oullLEdit 4200 This ~lo~ed~re is a stAn~rd SDS editor that is used to maintain the SDS database of ac~oull~s. 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.

203~172 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 re~G~ ~ 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(0,false) 3121 (9121) This ~oced~e activates the Global Copier Recovery sorted by User report.
GblCpyRec_Acct(O,false) 3122 (9122) This procedure activates the Global Copier Recovery sorted by Account report.

GblCpyRec_Chron(O) 3123 (9123) This procedure activates the Global Copier Recovery sorted by Date report.

GblCpyRec_User(0,True) 3124 (9124) This proced~e activates the Non-Billable Copier Recovery sorted by User report.

2~36172 -GblCpyRec Acct(O,True) 312S (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 (91Sl) This procedure activates the weekly non-billable analysis by copier report.

AcctList_Code 3311 (9311) This procedure activates the ac~ou~l- list sorted by account code report.

AcctList_Name 3312 (9312) This procedure activates the accou~.L list sorted by client name report.
AcctList_FLN 3313 (9313) This procedure activates the a~G~-L list sorted by file lawyer code.

AcctList CLN 3314 (9314) This ~oc~ e activates the a~co~-L list sorted by client lawyer code.

AcctList_Added 3315 (9315) This PL O~ed~ e activates the added account list report. This is a report of all acco~.~ added from the host system since this report was last run.

~serList_Ext 3341 (9341) This procedure activates the user list sorted by extension report.

203~i72 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 r~co~ized 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 looo This event is used by the Event suL --ys~em 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 _ 20~617~

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 ~ his 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 PL o~ed~re 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 eYp?ns~ recovery modules, and the status of the communications network. This procedure will exit upon a keypress or timeout.
RebuildValidIndex 1621 This p~occd~e will delete the current index files for the a~ O~ S datAhA~?, and then proceed to rebuild them from scratch from the accounts data file. This procedure displays its progress as it executes.

RebuildUserIndex 1622 This proceduke will delete the current index files for the user's datAhA~e, and then ~Gceed to rebuild them from scratch from the users data file. This procedure displays its progress as it executes.

203~17~

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 C~con~.

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 dat~hA~e.
GetHostAccts 11100 This Pro~ed~Le checks all the account information from host file paths and updates the accounts datAh~?
accordingly. It displays its PL G~ eB8 as it executes.
ReadClientFile 11200 This proce~llre 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.

Ne~A~oul,~s 12000 This procedure will broadcast all new a~o~.~s 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 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 (N8 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 ~AxT~uM ACCOUNTS in the configuration is non-zero, then it will only send the ~AxT~uM 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 ~G~ e will check every error transaction in the SDS datAhA~e^ to see if they are now valid, if they are found to be valid, the datAhAce is updated accordingly.
UserNBAccum 18000 This pro~e~ e performs an analy~is 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 203517~

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 p~oced~re 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 proced~e will NOT include user summaries (NB analysis.) NetUpdateUsers 20100 - 20199 This ~o edu~e 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. Thi~ ~ocedu~e will include user su aries (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, 203~17~
_.

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.

TABL~ III

Auto~atic (Activat-d by Ev-nt 8ub-8yst-~) (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 neceCc~ry to the accoul.L database.
12000 Send any new a~oul.Ls to all units on communications network.

(Nightly) 10000 Survey co~munications network.
11000 Read Transactions for all units on communications 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 dat~h~c~.
16000 Produce file of transactions to be posted to the host a~ioul.l,ing system.

20 ~ u~l ~Activat-d by lI-nu 8ub-8yæt-a) (Daily) 1200 Check the status of the communications network and SDS to make æure things are r~lnning.
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.

2~36172 -(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 pro~eduLes are activated in turn when the ~LGyLam 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 datAhAc~ of the controller terminals connected to the communications network are collected (11000) and stored in the central datAhAF~.
The list of user records including the most recent a~oul-~ class analysis is then transmitted (20199) to all the cG..~Loller 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 datAhA-~e. If 2~3617~

modifications are re~uired, 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 dat~h~ce 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 proces~^C the "error" transactions as a batch in an attempt to correct them. Error transactions are transactions for which no matchin~ account code can be found in the central acco~ s dat^h~?. 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 code~ entered through soft or syntax validation means.

As new accounts may arrive from the host accounting system, be entered manually to the accounts dat^h~e, or the account code allocation of the error transactions may be changed, this procedure is used regularly to reconcile the changes by correcting any transactions possible.

The last of the nightly operations iæ 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 PULPOe 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 proAll~D~, it is expected that they will also need to enter the corrections from the previous set of Le~O~ Ls they issued, so they will use the copier error editor to enter the coLLe_Lions 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 analysi~ 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.

-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 have 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 ~ GYL ams and the algorithms embodied thereby may be executed at various locations within the system, These and other modifications and variations are believed to be within the sphere and scope of the invention as defined by the claims ~ppen~ hereto.

Claims (93)

1. A system for controlling user access to one or more devices for the purpose of accounting for the use of said one or more devices, comprising:
a) means for storing a plurality of account codes of a plurality of predetermined account classes, individual ones of said account classes being defined so as to provide one of either unlimited or limited access to said one or more devices;
b) means for determining one of either actual or estimated charge recovery data representing user charges for use of said one or more devices to said plurality of predetermined account classes;
c) means associated with said one or more devices for receiving a first user input for identifying a user desirous of gaining access to use of a particular one of said one or more devices;
d) means associated with said one or more devices for receiving a second user input from said user for allocating a charge to be incurred upon using said particular one of said one or more devices; and e) means responsive to receipt of said second user input for comparing said second user input with respective ones of said plurality of account codes and, in the event said second user input matches one of said account codes of one of said account classes which is defined so as to provide unlimited access to said one or more devices then enabling said particular device for usage by said user, and in the event said second user input matches one of said account codes of one of said account classes which are defined so as to provide limited access to said one or more devices then retrieving and displaying said one of either actual or estimated charge recovery data to said user at said particular device, thereby providing moral suasion for said user to allocate said charge to be incurred to one of said plurality of account codes of one of said account classes which are defined so as to provide unlimited access to said one or more devices.

2. The system of claim 1 further comprising:
f) means for storing one or more predetermined usage limits in connection with said account classes; and g) means for comparing said charge recovery data to said one or more usage limits and interfering with access of said user to said particular device in the event said charge recovery data is greater than said one or more usage limits, whereby said interfering with access of said user provides further moral suasion for said user to allocate said charge to be incurred to one of said plurality of account codes of one of said account classes which are defined so as to provide unlimited access to said one or more devices.

3. The system of claim 2 further comprising means for displaying said plurality of valid account codes to said user at said particular device subsequent to receiving said first user input and prior to receiving said second user input.

4. The system of claim 3 further comprising means for audibly alerting said user in the event said charge recovery data is greater than said one or more usage limits.

5. The system of claim 3 further comprising means for displaying to said user at said particular device a message prompting said user to charge said usage of said particular device to any one of said account codes of one of said account classes which are defined so as to provide unlimited access to said one or more devices.

6. The system of claim 5 further comprising means for searching said plurality of valid account codes for an appropriate code for charge allocation for said usage of said one or more devices.

7. The system of claim 5 further comprising means for storing a plurality of account names associated with predetermined ones of said valid account codes, and means for searching said plurality of associated account names for an appropriate code for charge allocation for said usage of said one or more devices.

8. The system of claim 6 or 7 wherein said message comprises an invitation to said user to search for said appropriate code for charge allocation for said usage of said one or more devices.

9. The system of claim 1 further comprising means for entering an override description of an account for charge allocation for said usage of said one or more devices.

10. The system of claim 2 further comprising means for entering an override description of an account for charge allocation for said usage of said one or more devices.

11. The system of claim 1 further comprising means for displaying to said user at said particular device a message prompting said user to enter a transaction description for identifying context of said usage of said one or more devices.

12. The system of claim 2 further comprising means for enabling said particular device for usage by said user after a predetermined time delay subsequent to said second user input being received.

13. The system of claim 2 further comprising means for displaying to said user at said particular device a message prompting said user to enter a transaction description for identifying context of said usage of said particular device, and means for enabling said particular device for usage by said user after a predetermined time delay subsequent to said transaction description being entered by said user.

14. The system of claim 1 or 2 further comprising means for displaying to said user at said particular device a message indicating to said user that said user is restricted from allocating charges to said account codes of one of said account classes defined so as to provide limited access to said one or more devices.

15. The system of claim 1 or 2 further comprising means for calculating said one of either actual or estimated charge recovery data representing user charges for use of said one or more devices to accounts of the class identified by said second user input as a percentage of total charges by said user to all account codes in all classes of accounts.

16. The system of claim I or 2 further comprising means for calculating said one of either actual or estimated charge recovery data representing user charges for use of said one or more devices to accounts of the class identified by said second user input in monetary denominations for comparison to a minimum total value in monetary denominations of all device usage by said user.

17. The system of claim 9 or 10 wherein entry of said override description comprises usage of a predetermined one of said account codes defined so as to provide limited access to said one or more devices.

18. The system of claim 7 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 valid account codes in which said string of characters appears in said associated account names, and means for selecting a predetermined one of said valid account codes from said list for charge allocation for said usage of said one or more devices.

19. The system of claim 18 wherein said means for searching further comprises means for receiving a further user entered string of characters representing a further position independent portion of said predetermined account name to be searched, means for comparing said further user entered string of characters to said predetermined ones of said valid account codes in said list, means for creating a further list of further predetermined ones of said valid account codes in which said further string of characters appears in said associated account names, and means for selecting a further predetermined one of said valid account codes from said further list for charge allocation for said usage of said one more devices.

20. The system of claim 1 or 2 wherein at least one of said plurality of predetermined account classes is a non-billable account class.

21. The system of claim 17 wherein at least one of said plurality of predetermined account classes is an override account class.

22. The system of claim 1 or 2, wherein at least one of said one or more devices is a photocopier.

23. The system of claim 1 or 2 wherein at least one of said one or more devices is a facsimile machine.

24. A system for controlling user access to one or more devices for the purpose of accounting for the use of said one or more devices, comprising:
a) means for storing a plurality of account codes of a plurality of predetermined account classes, individual ones of said account classes being defined so as to provide predetermined degrees of limited access to said one or more devices;
b) means for determining one of either actual or estimated charge recovery data representing user charges for use of said one or more devices to said plurality of predetermined account classes;
c) means associated with said one or more devices for receiving a first user input for identifying a user desirous of gaining access to use of a particular one of said one or more devices;
d) means associated with said one or more devices for receiving a second user input from said user for allocating a charge to be incurred upon using said particular one of said one or more devices; and e) means responsive to receipt of said second user input for comparing said second user input with respective ones of said plurality of account codes and, in the event said second user input matches one of said account codes of an account class which is defined so as to provide a lowest one of said predetermined degrees of limited access to said one or more devices then enabling said particular device for usage by said user, and in the event said second user input matches one of said account codes of one of said account classes which are defined so as to provide other than said lowest one of said predetermined degrees of limited access to said one or more devices then retrieving and displaying said one of either actual or estimated charge recovery data to said user at said particular device, thereby providing moral suasion for said user to allocate said charge to be incurred to one of said plurality of account codes of said account class which is defined so as to provide said lowest one of said predetermined degrees of limited access to said one or more devices.

25. The system of claim 24 further comprising:
f) means for storing one or more predetermined usage limits in connection with said account classes; and g) means for comparing said charge recovery data to said one or more usage limits and interfering with access of said user to said particular device in the event said charge recovery data is greater than said one or more usage limits, whereby said interfering with access of said user provides further moral suasion for said user to allocate said charge to be incurred to one of said plurality of account codes of said account class which is defined so as to provide said lowest one of said predetermined degrees of limited access to said one or more devices.

26. The system of claim 25 further comprising means for displaying said plurality of valid account codes to said user at said particular device subsequent to receiving said first user input and prior to receiving said second user input.

27. The system of claim 26 further comprising means for audibly alerting said user in the event said charge recovery data is greater than said one or more usage limits.

28. The system of claim 26 further comprising means for displaying to said user at said particular device a message prompting said user to charge said usage of said particular device to any one of said account codes of said account class which is defined so as to provide said lowest one of said predetermined degrees of limited access to said one or more devices.

29. The system of claim 28 further comprising means for searching said plurality of valid account codes for an appropriate code for charge allocation for said usage of said one or more devices.

30. The system of claim 28 further comprising means for storing a plurality of account names associated with predetermined ones of said valid account codes, and means for searching said plurality of associated account names for an appropriate code for charge allocation for said usage of said one or more devices.

31. The system of claim 29 or 30 wherein said message comprises an invitation to said user to search for said appropriate code for charge allocation for said usage of said one or more devices.

32. The system of claim 24 further comprising means for entering an override description of an account for charge allocation for said usage of said one or more devices.

33. The system of claim 25 further comprising means for entering an override description of an account for charge allocation for said usage of said one or more devices.

34. The system of claim 24 further comprising means for displaying to said user at said particular device a message prompting said user to enter a transaction description for identifying context of said usage of said one or more devices.

35. The system of claim 25 further comprising means for enabling said particular device for usage by said user after a predetermined time delay subsequent to said second user input being received.

36. The system of claim 26 further comprising means for displaying to said user at said particular device a message prompting said user to enter a transaction description for identifying context of said usage of said particular device, and means for enabling said particular device for usage by said user after a predetermined time delay subsequent to said transaction description being entered by said user.

37. The system of claim 24 or 25 further comprising means for displaying to said user at said particular device a message indicating to said user that said user is restricted from allocating charges to said account codes of one of said account classes whose degree of limitation provides for restriction of access to said one or more devices.

38. The system of claim 24 or 25 further comprising means for calculating said one of either actual or estimated charge recovery data representing user charges for use of said one or more devices to accounts of the class identified by said second user input as a percentage of total charges by said user to all account codes in all classes of accounts.

39. The system of claim 24 or 25 further comprising means for calculating said one of either actual or estimated charge recovery data representing user charges for use of said one or more devices to accounts of the class identified by said second user input in monetary denominations for comparison to a minimum total value in monetary denominations of all device usage by said user.

40. The system of claim 32 or 33 wherein entry of said override description comprises usage of a predetermined one of said account codes of one of said account classes which are defined so as to provide other than said lowest one of said predetermined degrees of limited access to said one or more devices.

41. The system of claim 30 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 valid account codes in which said string of characters appears in said associated account names, and means for selecting a predetermined one of said valid account codes from said list for charge allocation for said usage of said one or more devices.

42. The system of claim 41 wherein said means for searching further comprises means for receiving a further user entered string of characters representing a further position independent portion of said predetermined account name to be searched, means for comparing said further user entered string of characters to said predetermined ones of said valid account codes in said list, means for creating a further list of further predetermined ones of said valid account codes in which said further string of characters appears in said associated account names, and means for selecting a further predetermined one of said valid account codes from said further list for charge allocation for said usage of said one more devices.

43. The system of claim 24 or 25 wherein at least one of said plurality of predetermined account classes is a non-billable account class.

44. The system of claim 40 wherein at least one of said plurality of predetermined account classes is an override account class.

45. The system of claim 24 or 25, wherein at least one of said one or more devices is a photocopier.

46. The system of claim 24 or 25 wherein at least one of said one or more devices is a facsimile machine.

47. A system for controlling user access to one or more devices for the purpose of accounting for the use of said one or more devices, comprising:
a) means for storing a plurality of account codes of a plurality of predetermined account classes, individual ones of said account classes being defined so as to provide one of either unlimited or limited access to said one or more devices;
b) means for determining one of either actual or estimated charge recovery data for each user representing charges for use of said one or more devices to said plurality of account codes of said plurality of predetermined account classes;
c) means for storing one or more usage limit values for one or more users, said usage limit values being associated with respective ones of said plurality of predetermined account classes, wherein each of said usage limit values for each user represents a single usage limit for the associated account class defined so as to provide limited access to said one or more devices;
d) means associated with said one or more devices for receiving a first user input for identifying a user desirous of gaining access to use of a particular one of said one or more devices;
e) means associated with said one or more devices for receiving a second user input for allocating a charge to be incurred by said user upon using said particular one of said one or more devices; and f) means for comparing said second user input with respective ones of said plurality of account codes and, (i) in the event said second user input matches one of said account codes of one of said account classes which is defined so as to provide unlimited access to said one or more devices then enabling said particular device for usage by said user, and (ii) in the event said second user input matches one of said account codes of one of said account classes which is defined so as to provide limited access to said one or more devices then retrieving a predetermined one of said usage limit values for said user identified by said first user input and associated with said one of said account classes which is defined so as to provide limited access, comparing said one of either actual or estimated charge recovery data for said user with said retrieved usage limit value and, in the event said one of either actual or estimated charge recovery data is less than or equal to said usage limit value then enabling said particular device for usage by said user, and in the event said one of either actual or estimated charge recovery data is greater than said usage limit value then providing an indication to said user at said particular device that said predetermined one of said usage limit values has been exceeded, thereby providing moral suasion for said user to allocate said charge to be incurred to one of said plurality of account codes of one of said account classes other than said one of said account classes containing said one of said account codes which matches said second user input.

48. The system of claim 47 further comprising means for interfering with access of said user to said particular device in the event said second user input matches said one of said account codes of said one of said account classes which is defined so as to provide limited access and said one of either actual or estimated charge recovery data is greater than said retrieved usage limit, thereby providing further moral suasion for said user to allocate said charge to be incurred to one of said plurality of account codes of one of said account classes other than said one of said account classes containing said one of said account codes which matches said second user input.

49. The system of claim 48 further comprising means for displaying to said user at said particular device said plurality of account codes subsequent to receiving said first user input and prior to receiving said second user input.

50. The system of claim 49 further comprising means for audibly alerting said user in the event said second user input matches said one of said account codes of said one of said account classes which is defined so as to provide limited access and said one of either actual or estimated charge recovery data is greater than said at least one usage limit value.

51. The system of claim 49 further comprising means for displaying to said user at said particular device a message prompting said user to charge said usage of said particular device to any one of said account codes of one of said account classes which is defined so as to provide unlimited access to said one or more devices.

52. The system of claim 51 further comprising means for searching said plurality of account codes for an appropriate code for charge allocation for said usage of said one or more devices.

53. The system of claim 51 further comprising means for storing a plurality of account names associated with predetermined ones of said account codes, and means for searching said plurality of associated account names for an appropriate code for charge allocation for said usage of said one or more devices.

54. The system of claim 52 or 53 wherein said message comprises an invitation to said user to search for said appropriate code for charge allocation for said usage of said one or more devices.

55. The system of claim 47 further comprising means for entering an override description of an account for charge allocation for said usage of said one or more devices.

56. The system of claim 48 further comprising means for entering an override description of an account for charge allocation for said usage of said one or more devices.

57. The system of claim 47 further comprising means for displaying to said user at said particular device a message prompting said user to enter a transaction description for identifying context of said usage of said one or more devices.

58. The system of claim 48 further comprising means for enabling said particular device for usage by said user after a predetermined time delay subsequent to said second user input being received.

59. The system of claim 48 further comprising means for displaying to said user at said particular device a message prompting s id user to enter a transaction description for identifying context of said usage of said particular device, and means for enabling said particular device for usage by said user after a predetermined time delay subsequent to said transaction description being entered by said user.

60. The system of claim 47 or 48 further comprising means for displaying to said user at said particular device a message indicating to said user that said user is restricted from allocating charges to said account codes of a predetermined one of said account classes defined so as to provide limited access to said one or more devices.

61. The system of claim 47 or 48 further comprising means for calculating said one of either actual or estimated charge recovery data representing user charges for use of said one or more devices to accounts of the class identified by said second user input as a percentage of total charges by said user to all account codes in all classes of accounts.

62. The system of claim 47 or 48 further comprising means for calculating said one of either actual or estimated charge recovery data representing user charges for use of said one or more devices to accounts of the class identified by said second user input in monetary denominations for comparison to a minimum total value in monetary denominations of all device usage by said user.

63. The system of claim 55 or 56 wherein entry of said override description is interpreted by said system as usage of a predetermined one of said account codes defined so as to provide limited access to said one or more devices.

64. The system of claim 53 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 selecting a predetermined one of said account codes from said list for charge allocation for said usage of said one or more devices.

65. The system of claim 64 wherein said means for searching further comprises means for receiving a further user entered string of characters representing a further position independent portion of said predetermined account name to be searched, means for comparing said further user entered string of characters to said predetermined ones of said account codes in said list, means for creating a further list of further predetermined ones of said account codes in which said further string of characters appears in said associated account names, and means for selecting a further predetermined one of said account codes from said further list for charge allocation for said usage of said one more devices.

66. The system of claim 47 or 48 wherein at least one of said plurality of predetermined account classes is a non-billable account class.

67. The system of claim 63 wherein at least one of said plurality of predetermined account classes is an override account class.

68. The system of claim 47 or 48 wherein at least one of said one or more devices is a photocopier.

69. The system of claim 47 or 48 wherein at least one of said one or more devices is a facsimile machine.

70. A system for controlling user access to one or more devices for the purpose of accounting for the use of said one or more devices, comprising:
a) means for storing a plurality of account codes of a plurality of predetermined account classes, individual ones of said account classes being defined so as to provide predetermined degrees of limited access to said one or more devices;
b) means for determining one of either actual or estimated charge recovery data for each user representing charges for use of said one or more devices to said plurality of account codes of said plurality of predetermined account classes;
c) means for storing one or more usage limit values for one or more users, said usage limit values being associated with respective ones of said plurality of predetermined account classes, wherein each of said usage limit values for each user represents a single usage limit for the associated account class;
d) means associated with said one or more devices for receiving a first user input for identifying a user desirous of gaining access to use of a particular one of said one or more devices;
e) means associated with said one or more devices for receiving a second user input from said user for allocating to a predetermined account code of a predetermined account class a charge to be incurred by said user upon using said particular one of said one or more devices; and f) means for retrieving a predetermined one of said usage limit values for said user identified by said first user input and said second user input, comparing said one of either actual or estimated charge recovery data with said retrieved usage limit value and, in the event said one of either actual or estimated charge recovery data is less than or equal to said usage limit value then enabling said particular device for usage by said user, and in the event said one of either actual or estimated charge recovery data is greater than said usage limit value then providing an indication to said user at said particular device that said predetermined one of said usage limit values has been exceeded, thereby providing moral suasion for said user to allocate said charge to be incurred to one of said plurality of account codes of one of said account classes other than said predetermined account class associated with said second user input.

71. The system of claim 70 further comprising means for interfering with access of said user to said particular device in the event said one of either actual or estimated charge recovery data is greater than said retrieved usage limit, thereby providing further moral suasion for said user to allocate said charge to be incurred to one of said plurality of account codes of one of said account classes other than said one of said account classes containing said one of said account codes which matches said second user input.

72. The system of claim 71 further comprising means for displaying to said user at said particular device said plurality of account codes subsequent to receiving said first user input and prior to receiving said second user input.

73. The system of claim 72 further comprising means for audibly alerting said user in the event said one of either actual or estimated charge recovery data is greater than said at least one usage limit value.

74. The system of claim 72 further comprising means for displaying to said user at said particular device a message enquiring of said user whether to charge said usage of said particular device to any one of said account codes of one of said account classes other than said one of said account classes containing said one of said account codes which matches said second user input.

75. The system of claim 74 further comprising means for searching said plurality of account codes for an appropriate code for charge allocation for said usage of said one or more devices.

76. The system of claim 74 further comprising means for storing a plurality of account names associated with predetermined ones of said account codes, and means for searching said plurality of associated account names for an appropriate code for charge allocation for said usage of said one or more devices.

77. The system of claim 75 or 76 wherein said message comprises an invitation to said user to search for said appropriate code for charge allocation for said usage of said one or more devices.

78. The system of claim 70 further comprising means for entering an override description of an account for charge allocation for said usage of said one or more devices.

79. The system of claim 71 further comprising means for entering an override description of an account for charge allocation for said usage of said one or more devices.

80. The system of claim 70 further comprising means for displaying to said user at said particular device a message prompting said user to enter a transaction description for identifying context of said usage of said one or more devices.

81. The system of claim 71 further comprising means for enabling said particular device for usage by said user after a predetermined time delay subsequent to said second user input being received.

82. The system of claim 72 further comprising means for displaying to said user at said particular device a message prompting said user to enter a transaction description for identifying context of said usage of said particular device, and means for enabling said particular device for usage by said user after a predetermined time delay subsequent to said transaction description being entered by said user.

83. The system of claim 70 or 71 further comprising means for displaying to said user at said particular device a message indicating to said user that said user is restricted from allocating charges to said account codes of a predetermined one of said account classes.

84. The system of claim 70 or 71 further comprising means for calculating said one of either actual or estimated charge recovery data representing user charges for use of said one or more devices to accounts of the class identified by said second user input as a percentage of total charges by said user to all account codes in all classes of accounts.

85. The system of claim 70 or 71 further comprising means for calculating said one of either actual or estimated charge recovery data representing user charges for use of said one or more devices to accounts of the class identified by said second user input in monetary denominations for comparison to a minimum total value in monetary denominations of all device usage by said user.

86. The system of claim 78 or 79 wherein entry of said override description is interpreted by said system as comprising usage of a predetermined one of said account codes of one of said account classes.

87. The system of claim 76 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 selecting a predetermined one of said account codes from said list for charge allocation for said usage of said one or more devices.

88. The system of claim 87 wherein said means for searching further comprises means for receiving a further user entered string of characters representing a further position independent portion of said predetermined account name to be searched, means for comparing said further user entered string of characters to said predetermined ones of said account codes in said list, means for creating a further list of further predetermined ones of said account codes in which said further string of characters appears in said associated account names, and means for selecting a further predetermined one of said account codes from said further list for charge allocation for said usage of said one more devices.

89. The system of claim 70 or 71 wherein at least one of said plurality of predetermined account classes is a non-billable account class.

90. The system of claim 86 wherein at least one of said plurality of predetermined account classes is an override account class.

91. The system of claim 70 or 71, wherein at least one of said one or more devices is a photocopier.

92. The system of claim 70 or 71 wherein at least one of said one or more devices is a facsimile machine.

93. The system of claim 47 or 70 further including means for retrieving and displaying said one of either actual or estimated charge recovery data to said user at said particular device so as to provide said indication to said user at said particular device that said predetermined one of said usage limit values has been exceeded.