Including point of sale terminal or electronic cash register

Method and system for accumulating marginal discounts and applying an associated incentive

6609104

Abstract

A method for customer promotion includes sequentially processing each of a plurality of items in a customer order. A marginal discount associated with each item is determined. All unapplied marginal discounts are accumulated for application to the customer order. A discount is applied to the customer order in response to a signal that is generated that indicates the accumulated discounts exceeds a predetermined minimum.


Claims

What is claimed is:

1. A method for customer promotion of a retail store comprising:

sequentially processing each of a plurality of items in a customer order;

accumulating the price of the each item;

determining a marginal discount associated with the each item;

after processing, and determination of a marginal discount for the each item, accumulating all unapplied marginal discounts;

generating a first signal indicating that a sum of the accumulated prices exceeds a predetermined threshold;

generating a second signal indicating that the accumulated discount exceeds a predetermined minimum; and

in response to the first signal and the second signal, applying a price reduction to the customer order.

2. The method of claim 1, wherein sequentially processing each of a plurality of items in a customer order comprises sequentially processing each of a plurality of items in a customer order received over the Internet.

3. The method of claim 1, wherein applying a price reduction to the customer order comprises applying a price reduction in response to the first signal and the second signal and upon processing an item in the customer order having a price that is no less than the price reduction.

4. The method of claim 1, wherein applying a price reduction to the customer order comprises applying the minimum discount.

5. The method of claim 1, wherein applying a price reduction to the customer order comprises applying the accumulated discount.

6. The method of claim 1, wherein determining a marginal discount associated with the each item comprises applying a constant percentage discount on the each item.

7. The method of claim 1, wherein determining a marginal discount associated with the each item comprises applying a variable percentage discount on the each item.

8. A system for customer promotion over the Internet comprising:

a computer-readable medium; and

a computer program encoded on the computer-readable medium, the computer program operable, when executed on a computer, to

sequentially receive signals indicative of the respective prices of a plurality of items in a customer order received over the Internet and in response sequentially determine a discount associated with each item;

accumulate the price of the each item;

accumulate all unapplied discounts after the determination of a discount for the each item;

determine that a sum of the accumulated prices exceeds a predetermined threshold;

determine that the accumulated discount exceeds a predetermined minimum; and

in response to the determination that a sum of the accumulated prices exceeds a predetermined threshold and the accumulated discount exceeds a predetermined minimum, initiate application of a price reduction to the customer order.

9. The system of claim 8, wherein the computer program is further operable to initiate application of a price reduction in response to the determination that a sum of the accumulated prices exceeds a predetermined threshold, the accumulated discount exceeds a predetermined minimum, and a price of an item in the customer order has a price that is no less than the price reduction.

10. The system of claim 8, wherein the computer program is further operable to initiate application of a price reduction having a value equal to the minimum discount.

11. The system of claim 8, wherein the computer program is further operable to initiate application of a price reduction having a value equal to the accumulated discount.

12. The system of claim 8, wherein the computer program is further operable to determine a discount associated with each item by applying the same percentage discount on each item.

13. The system of claim 8, wherein the computer program is further operable to determine a discount associated with each item by applying a variable percentage discount on each product.

14. A computerized system for customer promotion comprising:

a storage medium;

a processor coupled to the storage medium; and

a computer program encoded on the computer-readable medium, the computer program operable, when executed on the processor to

sequentially receive signals indicative of the respective prices of a plurality of items in a customer order received over the Internet and in response sequentially determine a discount associated with each item;

accumulate the price of the each item;

accumulate all unapplied discounts after the determination of a discount for the each item;

determine that a sum of the accumulated prices exceeds a predetermined threshold;

determine that the accumulated discount exceeds a predetermined minimum; and

in response to the determination that a sum of the accumulated prices exceeds a predetermined threshold and the accumulated discount exceeds a predetermined minimum, initiate application of a price reduction to the customer order.

15. The system of claim 14, wherein the computer program is further operable to initiate application of a price reduction in response to the determination that a sum of the accumulated prices exceeds a predetermined threshold, the accumulated discount exceeds a predetermined minimum, and a price of an item in the customer order has a price that is no less than the price reduction.

16. The system of claim 14, wherein the computer program is further operable to initiate application of a price reduction having a value equal to the minimum discount.

17. The system of claim 14, wherein the computer program is further operable to initiate application of a price reduction having a value equal to the accumulated discount.

18. The system of claim 14, wherein the computer program is further operable to determine a discount associated with each item by applying the same percentage discount on each product.

19. The system of claim 14, wherein the computer program is further operable to determine a discount associated with each item by applying a variable percentage discount on each item.

20. A method for customer promotion of a retail store comprising:

sequentially processing, at a remote computer at a location remote from the retail store on a substantially real-time basis, each of a plurality of items in a customer order;

accumulating the price of the each item;

determining a marginal discount associated with the each item;

after processing, and determination of a marginal discount for the each item, accumulating, by the remote computer, all unapplied marginal discounts;

generating a first signal indicating that a sum of the accumulated prices exceeds a predetermined threshold;

generating, by the remote computer, a second signal indicating that the accumulated discount exceeds a predetermined minimum; and

in response to the first signal and the second signal, applying a price reduction to the customer order.

21. The method of claim 20, wherein sequentially processing each of a plurality of items in a customer order comprises sequentially processing each of a plurality of items in a customer order received over the Internet.

22. The method of claim 20, wherein applying a price reduction to the customer order comprises applying a price reduction in response to the first signal and the second signal and upon processing an item in the customer order having a price that is no less than the price reduction.

23. The method of claim 20, wherein applying a price reduction to the customer order comprises applying the minimum discount.

24. The method of claim 20, wherein applying a price reduction to the customer order comprises applying the accumulated discount.

25. The method of claim 20, wherein determining a marginal discount associated with the each item comprises applying the same percentage discount on the each item.

26. The method of claim 20, wherein determining a marginal discount associated with the each item comprises applying a variable percentage discount on the each item.

27. A system for customer promotion over the Internet comprising:

a computer-readable medium; and

a computer program encoded on the computer-readable medium, the computer program operable, when executed on a computer, to

sequentially receive, at a location remote from the retail store on a substantially real-time basis, signals indicative of the respective prices of a plurality of items in a customer order received over the Internet and in response sequentially determine a marginal discount associated with each item;

accumulate the price of the each item;

accumulate all unapplied marginal discounts after the determination of a marginal discount for the each item;

determine that a sum of the accumulated prices exceeds a predetermined threshold;

determine that the accumulated discount exceeds a predetermined minimum; and

in response to the determination that a sum of the accumulated prices exceeds a predetermined threshold and the accumulated discount exceeds a predetermined minimum, initiate application of a price reduction to the customer order.

28. The system of claim 27, wherein the computer program is further operable to initiate application of a price reduction in response to the determination that a sum of the accumulated prices exceeds a predetermined threshold, the accumulated discount exceeds a predetermined minimum, and a price of an item in the customer order has a price that is no less than the price reduction.

29. The system of claim 27, wherein the computer program is further operable to initiate application of price reduction having a value equal to the minimum discount.

30. The system of claim 27, wherein the computer program is further operable to initiate application of a price reduction having a value equal to the accumulated discount.

31. The system of claim 27, wherein the computer program is further operable to determine a marginal discount associated with each item by applying the same percentage discount on each item.

32. The system of claim 27, wherein the computer program is further operable to determine a marginal discount associated with each item by applying a variable percentage discount on each item.

33. A system comprising a remote computer coupled to a retail store, the remote computer located remote from the retail store, the remote computer comprising:

a storage medium;

a processor coupled to the storage medium; and

a computer program encoded on the computer-readable medium, the computer program operable, when executed on the processor to

detect, at the remote computer on a substantially real-time basis, sequential signals indicative of the respective prices of a plurality of items in a customer order received over the Internet and in response sequentially determine a marginal discount associated with each item;

accumulate the price of the each item;

accumulate all unapplied marginal discounts after the determination of a marginal discount for the each item;

determine that a sum of the accumulated prices exceeds a predetermined threshold;

determine that the accumulated discount exceeds a predetermined minimum; and

in response to the determination that a sum of the accumulated prices exceeds a predetermined threshold and the accumulated discount exceeds a predetermined minimum, initiate application of a price reduction to the customer order.

34. The system of claim 33, wherein the computer program is further operable to initiate application of a price reduction in response to the determination that a sum of the accumulated prices exceeds a predetermined threshold, the accumulated discount exceeds a predetermined minimum, and a price of an item in the customer order has a price that is no less than the price reduction.

35. The system of claim 33, wherein the computer program is further operable to initiate application of a price reduction having a value equal to the minimum discount.

36. The system of claim 33, wherein the computer program is further operable to initiate application of a price reduction having a value equal to the accumulated discount.

37. The system of claim 33, wherein the computer program is further operable to determine a marginal discount associated with each item by applying the same percentage discount on each item.

38. The system of claim 33, wherein the computer program is further operable to determine a marginal discount associated with each item by applying a variable percentage discount on each item.

39. A method for customer promotion of a retail store comprising:

sequentially processing each of a plurality of items in a customer order;

accumulating the price of the each item;

determining a marginal discount associated with the each item, the value of the marginal discount being dependent on the price of the item and otherwise independent of the identity of the item;

after processing, and determination of a marginal discount for the each item, accumulating all unapplied marginal discounts;

generating a first signal indicating that a sum of the accumulated prices exceeds a predetermined threshold;

generating a second signal indicating that the accumulated discount exceeds a predetermined minimum; and

in response to the first signal and the second signal, applying a price reduction to the customer order.

40. The method of claim 39, wherein sequentially processing each of a plurality of items in a customer order comprises sequentially processing each of a plurality of items in a customer order received over the Internet.

41. The method of claim 39, wherein applying a price reduction to the customer order comprises applying a price reduction in response to the first signal and the second signal and upon processing an item in the customer order having a price that is no less than the price reduction.

42. The method of claim 39, wherein applying a price reduction to the customer order comprises applying the minimum discount.

43. The method of claim 39, wherein applying a price reduction to the customer order comprises applying the accumulated discount.

44. The method of claim 39, wherein determining a marginal discount associated with the each item comprises applying a constant percentage discount on the each item.

45. The method of claim 39, wherein determining a marginal discount associated with the each item comprises applying a variable percentage discount on the each item.


Description

TECHNICAL FIELD OF THE INVENTION

This invention relates to targeted marketing and more particularly to a method and system for customer promotion.

BACKGROUND OF THE INVENTION

Coupon distribution is widely used as a method for marketing products. However, the distribution of coupons is not without disadvantages. For example, coupon distribution is logistically complex. Much effort is extended by stores in receiving, verifying, and submitting coupons for reimbursement. As a method of targeted marketing, coupons are also somewhat deficient. Coupons may be exchanged or sold, reducing any targeted marketing aspect of coupon distribution. Coupons are also cumbersome to customers. Gathering, storing, and remembering to take a redeemable coupon to a store are activities with which many customers simply do not have time to engage.

Fraud is also a problem. Store employees sometimes redeem coupons in the absence of the purchase of an associated product, either to allow a friend the benefit of the discount or as a means to obtain cash from their employer.

In addition to these problems, the unauthorized duplication of coupons also limits more widespread use of these coupons for marketing. Further, some systems utilize customer identity to provide incentives to the customer based upon the customer's prior shopping history. Although desirable, these systems incorporate identification systems, which can add cost.

SUMMARY OF THE INVENTION

Accordingly, a need has arisen for a method and system for providing of customer incentives that address disadvantages of prior methods and systems. The present invention provides such a method and system for providing customer incentives.

According to one embodiment of the invention, a method for customer promotion of a retail store includes sequentially processing each of a plurality of items in a customer order and determining a marginal discount associated with each item for application to the customer order. After processing and determination of a marginal discount for each item all unapplied marginal discounts are accumulated. A signal is generated indicating that the accumulated discount exceeds a predetermined minimum. In response to the signal, a discount is applied to the customer order.

According to another embodiment of the invention, a system for customer promotion over the Internet includes a computer-readable medium and a computer program encoded on the computer-readable medium. The computer program is operable, when executed on a computer, to sequentially receive signals indicative of the respective prices of a plurality of items in a customer order received over the Internet and in response sequentially determine a discount associated with each item for application to the customer order. When executed, the computer program accumulates all unapplied marginal discounts after the determination of a marginal discount for each item and determines that the accumulated discount exceeds a predetermined minimum and in response, initiates application of a discount to the customer order.

Embodiments of the present invention provide numerous technical advantages. For example, in one embodiment, accumulation of marginal discounts and application of the accumulated discount produces the appearance of the customer receiving a discount on a particular item. Because any given transaction likely will include the customer's preferred products, over time it may appear to the customer as if discounts are being provided for the customer's preferred items. Providing discounts for a customer's preferred items likely induces customers to return to the store providing such discounts. Additionally, a method of customer promotion does not suffer from disadvantages associated with redeemable coupons. Furthermore, such a method of customer promotion can be implemented without identification of the customer. Moreover, such customer promotion may be implemented in a context not amenable to redeemable coupons.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

FIG. 1 shows the check transaction processing system of this invention, including a multiple store remote/host configuration;

FIG. 2A shows a POS terminal, including the check reader, display and the keypad;

FIG. 2B shows a block diagram of the automatic check reader;

FIG. 2C illustrates a typical check with MICR symbols for reading by the check reader;

FIG. 2D shows schematic circuit detail for the transaction terminal;

FIG. 3 functionally diagrams the check transaction processing system;

FIGS. 4A-1 through 4A-3 illustrate the MICR parsing function;

FIG. 4B diagrams the verification function;

FIG. 5 diagrams the local status update function for both Add and Delete NEGATIVE status;

FIGS. 6A and 6B diagram the global update function for, respectively, the host and a remote system;

FIG. 7 shows the program tasks that form the check transaction processing program;

FIG. 8 is a program flow diagram of the System Kernal that provides task switching and intertask communication for the other program tasks;

FIG. 9A is a program flow diagram of the Data Manager Task;

FIGS. 9B-9H are program flow diagrams of selected function execution routines in the Data Manager Task, respectively, verify roll, add NEGATIVE, delete NEGATIVE, host global update (negative status records), host global update (customer records), and remote global update (customer records);

FIGS. 10A and 10B are program flow diagrams of, respectively, the Terminal Manager Task network polling function, and the terminal request subtask;

FIGS. 11A and 11B are program flow diagrams of, respectively, the Event Manager Task, and the event subtask;

FIG. 12 is a program flow diagram of the Modem Manager Task;

FIGS. 13A and B are a program flow diagram of the Build-Check-Database subroutine used to build a database;

FIGS. 14A and B are a program flow diagram of a non-customer database building technique;

FIGS. 15A and B are a program flow diagram of a last shopping date database building technique;

FIGS. 16A and B are a program flow diagram of a range of last shopping date database building technique;

FIGS. 17A and B are a program flow diagram of a technique for distributing point-of-sale coupons based upon predetermined shopper criteria; and

FIGS. 18A, B, and C are a program flow diagram for distributing point-of-sale coupons based upon the shopping habits of the customer in various departments of the retail store.

FIG. 19 is a block diagram of a second embodiment of the invention which provides check, credit card, debit card or the like transaction processing as well as targeted marketing;

FIG. 20 shows in greater detail the elements of a conventional electronic cash register ("ECR") system for use with the system shown in FIG. 19;

FIG. 21 is a block diagram of the All Payments/Marketing ("AP/M") system of the invention, including peripheral financial instrument reading devices and a coupon printer in accordance with the invention;

FIG. 22 is a program flow diagram of the first portion of the payment processing and point-of-sale ("POS") marketing technique used in conjunction with the system in FIG. 19. FIG. 22 illustrates scanning in of a product by the bar code scanner of FIG. 20;

FIGS. 23A, B, and C are a program flow diagram of the various techniques for verifying and accepting payments from the various readers shown in FIG. 21;

FIG. 24 is a program flow diagram of the acceptance of shopping cards by the present system;

FIG. 25 is a program flow diagram illustrating the storage and access of account records by the present system;

FIG. 26 is a program flow diagram illustrating the building of a marketing record based upon multiple accounts in a single household;

FIGS. 27 and 28 are program flow diagrams illustrating a method of tracking infrequent shoppers who are to receive a Coupon "A";

FIG. 29 is a program flow diagram illustrating a method of increasing a customer's average purchase by providing the customer with a Coupon "M";

FIGS. 30 and 31 are program flow diagrams illustrating the method of building a coupon list for a POS disbursement of coupons;

FIG. 32 is a program flow diagram of a subroutine for coupon disbursements, providing the perform build coupon list in the flow diagram of FIG. 30;

FIG. 33 is a program flow diagram of a method for disbursing electronic point-of-sale incentives previously stored on a smart card or controller's mass storage device.

FIG. 34 is a program flow diagram illustrating the disbursement of point-of-sale incentives for future shopping visits by the customer;

FIG. 35 is a program flow diagram of a subroutine for the echo coupon procedure shown in FIG. 32;

FIG. 36 is a program flow diagram of the transfer of marketing data from a store's CVC controller via a dial-out telephone line to a remote master controller at another store;

FIG. 37 is a program flow diagram of the building of a profile value indicating what products a customer bought;

FIG. 38 is a program flow diagram illustrating use of the profile value to denote how valuable a coupon will be for the customer of FIG. 37;

FIG. 39 is a schematic electronic diagram of the AP/M terminal of FIG. 21;

FIG. 40 is a program flow diagram of the operation of the AP/M terminal of FIGS. 21 and 39;

FIG. 41 is a program flow diagram of the Perform Polling Process subroutine of FIG. 40;

FIG. 42 is a program flow diagram for the routine of determining a criteria for infrequency to a product or product group based on actual consumption;

FIG. 43 is a program flow diagram for the routine for response driven marketing based on shopping history criteria;

FIGS. 44A and B are a program flow diagram for a method of tracking infrequency to a product group and using Coupon "A";

FIGS. 45A and B are a program flow diagram for a method of maximizing purchases to a product group with Coupon "M";

FIGS. 46A and B are a program flow diagram illustrating the use of a value formula and consumption rate analysis in the generation of incentive coupons;

FIG. 47 is a program flow diagram illustrating the selection of products for use as ECHO coupon incentives;

FIG. 48A is a block diagram illustrating a system for providing incentives to customers who perform at least a portion of the shopping process through of a computer;

FIG. 48B is a block diagram illustrating a system for providing incentives to customers through the use of a kiosk;

FIG. 49 is a simplified block diagram of the system illustrated in FIGS. 19-21 for performing targeted marketing;

FIG. 50 is a block diagram of another embodiment of a system for effecting communication of an incentive to a customer;

FIG. 51 is a block diagram of a system for effecting communication of an incentive to a customer at the point of sale;

FIG. 52 is a flow chart illustrating a process for providing incentives to customers of a store who visit a computer site associated with the store;

FIG. 53 is a flow chart illustrating another embodiment of a process for providing incentives to customers of a store who visit a computer site associated with a store;

FIG. 54 is a flow chart illustrating another embodiment of a process for providing incentives to customers of a store who visit a computer associated with the store;

FIG. 55 is a flow chart illustrating an additional embodiment of a process for providing incentives to customers of a store who visit a computer associated with the store;

FIG. 56 is a flow chart illustrating a method for presenting incentives to a customer at a retail store;

FIG. 57A is a flow chart illustrated in embodiment of a process for providing automatic discount in a store;

FIG. 57B is a flow chart illustrating yet another embodiment of a process for targeted marketing of customer shopping through the use of a computer;

FIG. 58A is a flow chart illustrating a process for providing incentives to a customer;

FIG. 58B is a schematic drawing of a customer receipt generated according to the process of FIG. 58A;

FIG. 58C is a flow chart illustrating an additional embodiment of a process for providing incentives to a customer shopping on-line;

FIG. 59A is a flow chart showing an alternative embodiment for a process for providing incentives to a customer;

FIG. 59B is an internal alternative embodiment of a process for providing incentives to a customer shopping on-line;

FIG. 60A is a flow chart showing yet another embodiment of a process for providing incentives to a customer;

FIG. 60B is yet another embodiment of a process for providing customers incentives to a customer shopping on-line;

FIG. 61A is a flow chart illustrating yet another embodiment of a process for providing incentives to customers;

FIG. 61B is a flow chart illustrating yet another embodiment of a process for providing incentives to customers shopping on-line;

FIG. 62A is a flow chart illustrating a portion of the process of FIG. 61A;

FIG. 62B is a flow chart illustrating a portion of the process of FIG. 61B;

FIG. 63 is a flow chart illustrating one example of the application of a discount according to the process of FIGS. 61A and 61B;

FIG. 64A is a flow chart of yet another embodiment of a process for providing incentives to a customer;

FIG. 64B is a flow chart showing yet another embodiment of the process for providing incentives to a customer;

FIG. 65 is a flow chart illustrating a process for determining a discount rate in a minimum discount; and

FIG. 66 is a flow chart illustrating a number of techniques for identifying a customer of a store.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

A first embodiment of the present invention and its advantages are best understood by referring to FIGS. 1 through 18A-C of the drawings, like numerals being used for like and corresponding parts of the various drawings. A second embodiment is shown in FIGS. 19 through 47.

The check transaction processing system of the present invention enables a store with a significant volume of check transactions to accumulate and process transactional customer information for check verification and customer profiles for target marketing. The system operates at the store using a local database of customer information useful in that store's business.

A customer's bank checking account number provides a unique identification for that customer--using this check ID, a customer record is created and included in the local customer database. The customer record includes an assigned customer verification status, as well as selected transactional data. Customer status designations include POSITIVE, NEGATIVE and CAUTION, while transactional data includes transaction frequency and dollar volume over given intervals (such as Day/Week/Total or DWT). Selected transactional (CALL MANAGER) limits are assigned to both CAUTION and POSITIVE status. This customer information (customer status and transactional data) in the customer database is continuously updated (a) on a local basis through either processing check verification requests, or inputting customer status, and (b) in the case of a multiple store business, on a global basis through inter-store transfers of selected customer information (such as CAUTION and NEGATIVE status information).

The description of the first and second embodiment of the check transaction processing system is organized as follows:

1.0 Hardware Description

1.1. System Overview

1.2. Data Communications Network

1.3. POS Terminal

1.4. Multiple-Store Configuration

1.5. Exemplary Components

2.0 Functional Description

2.1. Database Structure

2.2. Function Codes

2.3. Verify/Query

2.4. Local Status Update

2.5. Global Update

2.6. Purge

2.7. Event/Activities

2.8. Communications

2.9. System

2.10. Risk Management

2.11. Customer Information Reporting

3.0 Program Description

3.1. General

3.2. System Kernal

3.3. Data Manager Task

3.4. Terminal Manager Task

3.5. Event Manager Task

3.6. Modem Manager Task

4.0 Alternative Embodiments

5.0 Targeted Marketing Features

5.1. Automatic Building Of A Database For A Retail Store Marketing Program

5.2. Targeted Marketing Program

5.3. Infrequent Shopper Database And Marketing Techniques

5.4. Marketing Based On Range Of Last Shopping Dates

5.5. Dissemination Of Point-Of-Sale Coupons And Direct Mail Coupons Based Upon Shopping History

5.6. Dissemination Of Point-Of-Sale Coupons And Direct Mail Coupons Based Upon Scanned Data

5.7. Second Alternate Embodiment Of Payment Processing And Point-Of-Sale Marketing System

1.0 Check Transaction Processing System

The check transaction processing system is located at a store, and maintains a local customer database for that store. For a multiple store business, a local system is located at each store and global customer information transfers are used to supplement the essentially local customer database.

1.1. System Overview. As shown in FIG. 1, a check transaction processing system 110 located at a store includes a transaction processor 112 coupled to a disk system 114 that stores the customer database used in check transaction processing. Transaction processor 112 handles all file I/O for accessing, managing and updating the customer database.

Transaction processor 112 is coupled through a network data communications interface 116 (including network communications ports and associated drivers) and a network bus 118 to a plurality of transaction terminals 120. Transaction processor 112 is able to communicate with other check transaction processing systems through a telecommunications interface 117 (including a modem).

Transaction terminals 120 are each located at a point-of-sale (such as a grocery store checkout stand). Transaction terminals 120 are used to communicate information to transaction processor 112 for check transaction processing and customer database management. A transaction terminal transmits a request (including a function code identifying the requested function together with other request data) to the transaction processor, which processes the request and returns an appropriate response.

For example, in the case of check verification, a transaction terminal is used to transmit a verification request--the customer's check ID, the verification function code, and the dollar amount. The transaction processor processes the request, updates the customer database to reflect that transaction, and returns a customer verification status response.

1.2. Data Communications Network. Data communications between transaction processor 112 and transaction terminals 120 is implemented using a multi-drop token ring network. Network bus 118 connects the transaction terminals to the transaction processor in a star configuration so that all data signals transmitted over the network are received at each node. Each transaction terminal 120 is assigned a unique terminal address to identify its data communications.

Transaction processor 112 implements a token-passing protocol by broadcasting polling sequences (or cycles) in which tokens are sequentially addressed to the transaction terminals. For each poll, the transaction processor sends to a terminal one of two tokens (which both include the terminal address):

POLL Token An invitation for the terminal to transmit data

RXDATA Token Includes data requested by the terminal

In response to a POLL token, the transaction terminal transmits back one of two answers:

TXDATA Answer Includes data entered into the terminal

NODATA Answer Indicates no data

During any given polling sequence, each transaction terminal is in one of three polling states that control the polling operation:

Poll Send a POLL token

Wait Do not send a token until requested data is available

Data Send an RXDATA token that includes the requested data in the terminal's buffer

For example, in response to a POLL token, a transaction terminal may transmit a TXDATA Answer containing a check verification request. Once the request is transmitted, the terminal is placed in the Wait state until the verification response from the transaction processor is available. The response is placed in the terminal's buffer, and the terminal is placed in the Data state. The response is included in an RXDATA token sent to the terminal during the next polling sequence, and the terminal is placed in the Poll state ready to receive a POLL token in the next polling sequence.

For the preferred embodiment, network communications interface 116 provides 32 ports for up to 32 transaction terminals. The data communications network uses the RS485 line protocol, which specifies differential signal lines SIG+ and SIG-, as well as +12V and ground lines. The network communications interface and the corresponding interfaces for each transaction terminal use a differential line driver for signal communication over network bus 118, which provides the necessary 4-wire signal path.

1.3. POS Terminal. As shown in FIG. 2A, each POS terminal 120 includes an automatic check reader 119 and a transaction terminal 121 which includes a keypad 122 and a display 124. A bar code reader 123a is also connected to terminal 121 and is used to read bar code numbers on products purchased at the point-of-sale. Further, a coupon dispenser 123b is connected to terminal 121 to dispense coupons at the point-of-sale. Keypad 122 is a 4.times.4 key matrix that includes specific keys for Function, Enter, Scroll, Clear and Back Space, as well as 0-9 and $. Display 124 is a liquid crystal display capable of displaying two lines of up to twenty characters each.

For example, to initiate a check verification request, check reader 121 automatically scans the magnetic ink character recognition (MICR) data printed along the bottom edge of the customer's check and then the store clerk operates the keypad 122 to enter the amount of the check, along with the function code designating check verification. This request is displayed on display 124, and sent, along with data from the check reader 121, to transaction processor 112. The check verification response, including the customer's verification status (such as POSITIVE, NEGATIVE or CAUTION), and marketing information (such as the type of coupon to be dispensed) returned by the transaction processor is then displayed on display 124.

FIG. 2B illustrates a block diagram of an automatic check reader 119 in accordance with the present invention. Automatic check readers have been heretofore known, and the descriptions of such previously developed automatic check readers are found in U.S. Pat. Nos. 4,277,689; 4,143,355; 4,396,902 and 5,054,092, the subject matter of which is incorporated by reference herein. The present automatic check reader differs in that it contains a properly programmed processor and sufficient memory to enable the desired "parsing" and omitting of certain portions of the MICR code contained at the bottom of checks being read.

The MICR encoding of checks is known, and a detailed explanation of the MICR encoding scheme may be found in The MICR Handbook by Rylla R. Goldberg, published by Heath Printers, the subject matter which is hereby incorporated by reference. As noted in The MICR Handbook, and as will be subsequently described, the field of the MICR symbology located on the bottom of the check is broken into various data fields in which different banks can place different data at different locations. Conventional automatic check readers such as those noted in the above-noted patents often cannot detect a customer's checking account number because it is interspersed with other data such as the check sequence number.

The present automatic check reader is provided with structure which enables the customer checking account number and the bank transit number (which identifies the bank) to be detected within the code printed on the customer's check. This process involves detecting or parsing (the examination or analysis of a string of numbers or characters which is designed to detect or identify various subgroupings or sets within the string) followed by extraction of that set or sets which have been defined as the customer checking account number. The present automatic check reader is thus provided with circuitry which enables the customer's checking account number and the bank transit number to be parsed or detected and the remainder of the data extracted or omitted, such that the customer's checking account number and the bank transit number may be used as the unique customer identification code for the present invention. The present check reader thus provides substantial advantages over prior check readers which have not been useful for check verification or marketing techniques because it was not possible for such prior check readers to consistently detect customer account numbers on checks presented from different banks and bank branches.

Referring to FIG. 2B, the check reader 119 of the present invention incorporates a read head 125a which comprises a magnetic or optical read head operable to read MICR characters imprinted on checks which are passed through the check reader. The output from read head 125a is applied to a magnetic wave-form analyzer 125b which applies an analog signal to the analog to digital converter 125c. A digital output from converter 125c is applied to the character recognition logic 126b of the present invention. A disk or EEPROM 126a contains stored therein an E-13(b) character table which is applied to the character recognition logic 126b. Utilizing conventional technology, the logic 126b generates recognition data to data store registers 127 for application to microprocessor 128a when required. The disk or EEPROM data storage 126a includes a transit code table and a parsing program, and provides data and instructional programming for the microprocessor 128 to perform a parsing program discussed in more detail in FIG. 4B. An input/output device 129a is connected to microprocessor 128a, as is an output device 129b.

In operation, the read head 125a reads MICR characters on the check and applies signals to the analyzer 125b to provide an output from the analog to digital converter 125c of the MICR characters being detected. The character recognition logic 126b provides optical character recognition to generate an indication of the characters represented by the MICR symbology on the check. This data is stored in the data stored registers 127 for application to the microprocessor 128a. The microprocessor 128 utilizes information from the transit code table in the disk or EEPROM 128b to determine the particular bank whose check is being scanned and also the particular location of the customer account number in the MICR code for that particular bank. The parsing program 128 is then operable to parse or eliminate all aspects of the MICR code except for the desired customer account number. The microprocessor 128 then generates an output to the output device 129b which indicates the desired customer account number of that particular check. The output device 129b is connected to pins 1-3 which serve as the I/O of the transactional terminal 121 circuitry which is shown in FIG. 2D, to be subsequently described.

The detected customer account number and bank transit number are then subsequently used in the various programs and subroutines of the present invention to provide check verification and marketing techniques in accordance with the invention. As noted, the present automatic check reader differs from previously developed check readers in its ability to detect the location of the customer account number and to omit all other portions of the MICR code except for the desired account number and perhaps the transit number. In this way, the present automatic check reader may be used to process all checks from all banks and their branches, regardless of the location of the customer account number and regardless of which branch of a particular bank is being utilized or even in such situations where a branch is sold or transferred to another entity.

FIG. 2C illustrates a typical check which will be used to illustrate the operation of the automatic check reader of the invention. As described in The MICR Handbook by Rylla R. Goldberg, and as is commonly known, the MICR check field contains four fields, namely the Amount, On Us, Transit, and Auxiliary On Us fields. Conventionally, the Amount field includes positions 1-12 in the MICR field, the On Us field includes positions 14-31, the Transit field positions 33-43 and the Auxiliary On Us field encompasses positions 45-65 in the MICR band. In the illustrated check in FIG. 2C, the Transit field comprises symbols plus the transit number sequence 101010733. This transit number identifies the particular banking institution. This transit number is set apart from the data contained in the On Us field, which field contains the customer's account number and also contains the number of the particular check. In this instance, the number sequence in the On Us field is 179201476663. The last two digits 0 and 1 in the MICR field are optionally included on many checks and may be offset by a symbol to indicate the branch number of the particular bank.

It can thus be seen that the sequence 179201476663 contains both the sequence number of the particular check, which in this particular instance is 1792, and also the customer's checking account number 01476663. As noted, it is very important in the present invention to automatically detect the customer's checking account number. It is common for many banks to provide symbology which separates the number of the particular check and the customer's account number. However, with many banks, as in the illustrated check of FIG. 2C there is no symbology which separates two pieces of information and therefore it has not been heretofore possible to automatically determine the actual customer's account number in all banks by conventional check readers. For example, conventional check readers which would scan the On Us field for the account number would indicate that the customer's account number was 179201476663, whereas the customer's true account number is 01476663.

An important aspect of the present invention is the ability of automatic check reader 119 to find the sequence number of the check and omit that number to leave the true customer account number. The encoding scheme may be different for each bank. This is accomplished by utilization of the disk or EEPROM 128a which contains tables which designate what encoding scheme is used in the MICR band for each bank. For example, the table stored in EEPROM 128b would indicate that the Mills County Bank, identified by the transit number 101010733, had a convention of always placing the check number in the first four locations of the On Us field. In the case of the check in FIG. 2C, the check reader 119 would access this information to know that the first four digits of the On Us field were merely the number of the check and should thus be omitted or parsed in order to determine the true checking account number of the customer, which was 01476663. Specifically, in the check illustrated in FIG. 2C, it can be seen that the number of the check at the upper right hand corner is 1792. This number would then be omitted by the check reader 119 to provide the true customer account number. In some instances, the customer account number may be combined with the transit number to provide a unique ID number.

It will be understood that the check number advances one unit each time a new check is written and therefore the data contained in the On Us field of the Mills County Bank would be continuously changing. Only by the check reader of the present invention having a stored knowledge of a particular location of the check number of the Mills County Bank would it be able to detect and omit or parse out the unwanted check number information.

The present check reader of the invention can determine the instances when the On Us field contains a space or suitable symbology separating the check number from the customer's account number, in addition to the scheme previously noted. In such cases, the check reader parses and omits the shortest number, which will be the check number. A particularly important aspect of the present invention is that the automatic check reader can read the MICR code of all banks and accurately pick out the customer's account number for utilization as a unique customer ID to perform the advantages of the invention.

Another important aspect of the invention, as will be described in greater detail in FIGS. 4A-1 through 4A-3, is the ability of the automatic check reader 119 to be taught by the operator to recognize the eccentricities of each bank's MICR code. For example, if the system were for the first time attempting to read a check by the Mills County Bank and thus could not pick out the customer's account ID because it did not know the code for Mills County Bank, the present system could be taught by the operator and the new knowledge stored in table 128b. From that point forward, the system would be trained to recognize the customer's account number and to omit the unwanted check number in the first four positions of the On Us field.

The present automatic check reader 119 also can be taught to detect changes of a bank's branch number, and instances in which institutions are purchased and their transit number is changed, and cases wherein financial institutions run into difficulties and are required to change owners and therefore change transit IDs. Previous check readers were not able to keep track of such changes in banks and transit numbers. With the present check reader 119, such information can be stored in the transit code table 128b. Therefore, if the Mills County Bank of FIG. 2C changes its transit number or its branch number, that information can be entered into the transit code table 128b and from that point forward, the system will continue to recognize Jack Smith's checks and his unique checking account number even though the bank's transit number has been changed. With prior check readers, such changes in transit numbers would be scanned and considered to be a different bank and therefore Jack Smith's account number would not be recognized as belonging to the particular Jack Smith.

In addition, banks often have different types of accounts such as money markets, now accounts, commercial accounts, personal accounts and the like. So for a given bank transit number, there may be several non-obvious embedded locations for the particular next sequence number. For example, in the check shown in FIG. 2C, the first four digits in a personal checking account are known to represent the check sequence number. However, for a savings, NOW or money market account for the Mills County Bank, the check sequence number might be moved to the middle or the end of the On Us field. The information for each particular bank is stored in the transit code table 128b of the present reader 119 such that all branches and types of accounts of a bank may be accurately detected. The ability to teach or train the system to accommodate such new information upon the occurrence of changes is also important, as such new information may be input by the operator into the transit code table 128b and used from that point onward to detect accurately the customer's checking account number, as well as all customers for that bank.

Another important aspect of the invention is that the MICR parsing operation previously described and shown in FIGS. 4A-1 through 4A-3 does not have to be accomplished inside the automatic check reader 119. Indeed, the transit code table and parsing program may be incorporated in the host computer 110. A conventional check reader may thus be used to read in the information and the parsing program shown in FIGS. 4A-1 through 4A-3 can be accomplished in the host computer 110. It will also be understood that the automatic check reader 119 might be incorporated into the transactional terminal 121 and that both the automatic check reader 119 and the transactional terminal 121 might be incorporated or associated directly with an automatic cash register commonly in use by retailers.

The important aspect of the invention is the ability to always recognize a customer's checking account number in a MICR line automatically, no matter which bank or which type of account is involved. With the ability to generate an extremely accurate indication of the customer's account number and the bank transit number, a unique customer identification code is provided which may be utilized to provide the many advantages of the invention to be subsequently described.

While the preferred customer identification code comprises the checking account number and the bank transit number, it should be understood that various aspects of the invention may be practical using different customer identification codes. For example, many of the marketing and verification techniques hereinafter described can be accomplished by the store clerk manually entering the name, address and/or phone number into the system through data terminal keypad 122. This unique identifying data could then be used to identify the store customer. While such manual entry is slower and not as efficient or accurate as the automatic reading of the MICR code, the manual technique may have applications in certain circumstances.

As shown in FIG. 2D, the transaction terminal 121 includes:

(i) A Z8 microprocessor 130;

(ii) An associated address latch 132;

(iii) An EPROM 134;

(iv) An LCD (liquid crystal display) module 136; and

(v) A differential transceiver 138.

Address and data paths are provided by an Address/Data Bus and a separate Address Bus.

The transaction terminal is coupled to the RS485 multi-drop network bus (118 in FIG. 1) through a 5-Pin DIN connector 140. The RS485 network bus provides signal lines SIG+ and SIG-, along with a +12 volt power line and a ground line.

EPROM 134 provides program memory for microprocessor 130, while LCD module 136 constitutes data memory. That is, the LCD module functionally interfaces to the microprocessor as memory, providing an 80-character display data register that is treated by the microprocessor as data memory.

EPROM 134 stores programs to control keypad 122, display 124 (i.e., LCD module 136) and network data communications. The keypad program includes conventional routines for decoding key-struck signals and receiving entered characters, as well as key-debouncing and N-key rollover. The display program includes conventional routines that write characters to and read characters from the display data register in LCD module 136. To that end, the display program provides mode control commands to LCD module 136 that control read/write operations, as well as operations for cursor positioning, backspace and scroll. The network program controls token-ring network communications, including establishing a terminal polling address when the transaction terminal becomes active, detecting POLL tokens addressed to the transaction terminal, building and sending NODATA and TXDATA answers, and receiving RXDATA tokens containing response data for the transaction.

LCD module 136 is a self-contained liquid crystal display module that includes liquid crystal display 124, and provides many display control functions internally. Display 124 is arranged in two lines of 20 characters each, with the internal 80-character display data register providing 40 characters of display memory for each line. Each line is independently scrolled under control of the LCD module in response to microprocessor mode control commands (for example, when the scroll key on keypad 122 is depressed). In addition to the internal display data register, the LCD module includes an internal control/status register. Logically, these registers are treated as, respectively, data and control/status ports. Data may be read to or written from the data port, while control is written to and status is read from the control/status report.

From above, the display control program in EPROM 134 provides the various mode control commands that invoke the display control functions implemented by the LCD module. For example, in response to appropriate mode control commands, the LCD module performs the necessary internal operations to move the cursor, output the character under the cursor, write a character in the cursor position, delete a character in the cursor position, clear the display, and output sequentially all characters in the display data register (such as after the enter key is depressed).

Microprocessor 130 provides four input/output ports 0-3. Port 0 is output only, and provides the higher order address bits A08-A12 over the Address Bus (the 3 higher order bits A13-A15 of the 16-bit Z8 microprocessor address are not used by the transaction terminal). Port 1 is input/output, providing the lower order address bits A00-A07 and receiving 8-bit data bytes over the Address/Data Bus. Port 2 is input only, and is coupled to the column/row matrix lines of the 4.times.4 keypad matrix for keypad 122, i.e., column lines C0-C3 and row lines R0-R3.

Port 3 (0-7) is a multi-purpose input/output port. Pins 0 and 7 are a serial I/O port for an internal UART (universal asynchronous receiver transmitter). Pin 5 is an output drive enable line that controls the transmit/receive state of differential line driver 138. Pin 4 is a data memory DM line used to select either program memory (i.e., EPROM 134) or data memory (i.e., LCD module 136). Pins 1-3 are an I/O port for the check reader 119 or for a credit card reader, and Pin 6 is an output port for a buzzer.

In addition to the four I/O ports, microprocessor 130 provides an address strobe line AS, a data strobe line DS and read/write line R/W.

A clock circuit 131 includes a crystal oscillator that establishes a 7.3728 MHz system clock. The Z8 microprocessor is clocked down (from its 12 MHz specification) to accommodate the LCD module's response time.

Address latch 132 receives the lower order address bits A00-A07 from microprocessor port 1 over the Address/Data Bus during the first address cycle. The address latch is enabled to latch these address bits by a microprocessor address strobe provided through an inverter 142. The latched address bits A00-A07 are available at the output of address latch 132 which is coupled to the Address Bus.

EPROM 134 receives a 12-bit address A00-A12 from the Address Bus. The lower order bits A00-A07 are provided by address latch 132, and are available on the Address Bus during the second address cycle when the higher order bits A8-A12 are provided by microprocessor port 0 over the Address Bus. Thus, EPROM 134 receives the complete 12-bit address A00-A12 from the Address Bus during the second address cycle. The addressed data byte AD0-AD7 is available from the EPROM output port over the Address/Data Bus and may be read when microprocessor 130 provides a data strobe DS to the chip enable CE input to the EPROM.

LCD module 136 includes an I/O port (pins D0-D7) coupled to the Address/Data Bus (lines AD0-AD7). To connect either the display data register or the control/status register to the I/O port, Microprocessor 130 selects either data port operation or control/status port operation with a register select signal provided by the address bit A00 from the Address Bus to the R/S input of the LCD module--if A00 is even (logic 0), the display data register is connected to the I/O port, and if A00 is odd (logic 1), the control/status register is connected. Read/write operation is selected by R/W signal from microprocessor 130 to the R/W input to LCD module 136.

LCD module 136 is enabled for output over the Address/Data Bus by an enable signal from a NOR gate 146, which receives input from the microprocessor's data strobe DS line and data memory DM line (port 3, pin 4). That is, LCD module 136 may be read only if both the data strobe and data memory lines are active. In contrast, EPROM 134 is enabled for a read operation only if the data strobe line is active while the data memory line is inactive causing an active output from an inverter 144. In this manner, microprocessor 130 uses the data memory line to select between program memory (EPROM 134) and data memory (LCD module 136).

A potentiometer 148 is used to adjust contrast for the LCD display 124. The potentiometer is connected between the pins +5 volts and ground on LCD module 136, with the potentiometer voltage being applied to the voltage reference pin VREF.

To read instructions from EPROM 134, microprocessor 130 provides a 12-bit address on the Address Bus--the lower order address bits A00-A07 from port 1 through address latch 132, and the higher order address bits A08-A12 from port 0. EPROM 134 is enabled for output by the data memory line (port 3, pin 4) being held inactive resulting in an active output-enable signal from inverter 144 to the EPROM. Conversely, LCD module 136 is disabled for a read operation because the inactive data memory line insures an inactive signal from NOR gate 146 to the LCD module, thereby insuring that EPROM 134 has exclusive access to the Address/Data Bus. During the read cycle, microprocessor 130 enables EPROM 134 to output the addressed data byte by providing a data strobe DS to the chip-enable input to the EPROM.

To read display data from the display data register in LCD module 136, Microprocessor 130 executes a read display routine in the display control program stored in EPROM 134. Microprocessor 130 first disenables EPROM 134 by holding the data memory line (port 3, pin 4) active, causing the output-enable output from inverter 146 to be inactive. LCD module 136 is then enabled for input/output when a microprocessor data strobe drives active the output from NOR gate 148, which now has both its inputs (DM and DS) active.

Once LCD module 136 has been given access to the Address/Data Bus, a display-data-register read operation is accomplished as follows. Microprocessor 130 outputs from port 1 an LCD mode control byte including a register select bit A00 over the Address/Data Bus. The register select bit is coupled through address latch 132 and the Address Bus to the RS input to LCD module 136 which selects bit is in the C/S state, causing LCD module 136 to select the control/status register for I/O access to the Address/Data Bus. Microprocessor 130 also places its read/write R/W line in the write state, so that the mode control byte can be written into the control/status register. Microprocessor 130 then provides a data strobe DS that enables LCD module 136 to latch the mode control byte from the Address/Data Bus into the control/status register.

In accordance with this mode control command, LCD module 136 places a not-ready status byte in the control status register, makes the designated display character in the display data register available for output on the Address/Data Bus, and then places a ready status byte into the control/status register. Microprocessor 130 switches the read/write line to read (the control/status register is still selected for I/O), and then provides a data strobe DS to read the status byte in the control/status register. (The microprocessor continually strokes the LCD Module until a ready status byte is returned from the control/status register.)

Microprocessor 130 then outputs a register select bit (A00) that causes LCD module 136 to select the display data register for output. Finally, the microprocessor provides a data strobe to read the first display data character over the Address/Data Bus into port 1.

This procedure--select control/status, read status, select display data, read display data--is continued until all requested display data characters have been read. That is, microprocessor 130 first reads the status register to determine when LCD module 136 is ready (i.e., when the next display data character is available), and then reads the character.

The procedure by which microprocessor 130 provides display data characters for display by LCD module 136, writing the characters into the display data register, is analogous to the procedure for reading display data characters. Executing a write display routine in the display control program, microprocessor 136 first writes a corresponding mode control command into the control/status register of the LCD module, and then reads status to determine when the LCD module is ready. Microprocessor 130 then selects the display data register, and writes the first display data character over the Address/Data Bus. Microprocessor 130 reads the status register to confirm that the LCD module is ready prior to writing the next display data character. This procedure of reading the status register and then writing a display data character is continued until all display data characters have been written.

Differential transceiver 138 controls data communications over the network bus 118 connected to connector 140. The RS485 communications protocol is implemented by microprocessor 130 executing the network communications program stored in EPROM 134. Port 3 of microprocessor 130 is used as a communications port, with pins 0 and 7 providing a serial I/O port, and pin 5 providing a transceiver drive enable line through an inverter 152 (the differential transceiver is in the transmit mode if the signal is active, and in the receive mode if the signal is inactive).

On the network side of differential transceiver 138, signal lines 6 and 7 are coupled, respectively, to the network bus signal lines SIG+ and SIG-. These signal lines are coupled to the +12 volt line through opposite sides of a protective diode network 154.

While waiting for a token (either POLL or RXDATA) over the network bus, microprocessor 130 holds the transceiver drive enable line inactive, thereby placing differential transceiver 138 in the receive mode. When a token is received through differential transceiver 138 into the serial I/O port (port 3, pins 0 and 7), microprocessor 138 switches the transceiver drive enable line active and transmits either a TXDATA or NODATA answer via the serial I/O port and the differential transceiver.

Keypad input is accomplished in a conventional manner using a 4.times.4 keypad matrix with column lines C0-C3 and row lines R0-R3. Key-struck decoding is accomplished as follows. Column lines C0-C3 are normally held high by a resistor network 160, while microprocessor 130 (port 2) holds the row lines R0-R3 low. When a key is struck, the corresponding column line is brought into contact with that key's row line, and the column line is brought low, which is detected by microprocessor 130. The microprocessor then switches the port 2 lines high, and sequentially drops a row line low until the key-struck column line goes low, thereby identifying the key that was struck by its row/column intersection.

Keypad control functions, such as debouncing and N-key rollover are accomplished in a conventional manner using program routines of the keypad control program stored in EPROM 134.

Power for the transaction terminal is provided by a voltage regulator 165 that receives +12 volts from the +12 volt line of the network bus. Voltage regulator 165 provides a stable +5 volt logic level.

A transaction terminal is initialized as follows. At power on, voltage regulator 165 provides a reset signal to microprocessor 130 when the +5 volt logic level is stable. Microprocessor 130 turns port 0 off, so that the Address Bus is controlled by the low-current resistor network 160, which holds the Address Bus lines A08-A12 high.

Microprocessor 130 outputs from port 1 an initialization address over the Address/Data Bus, which is latched into address latch 132 and placed on the Address Bus. EPROM 134 receives the initialization address A00-A12 (with bits A08-A12 being held high by resistor network 160), and makes the addressed instruction available at its data output port. Microprocessor 130 then reads the first instruction over the Address/Data Bus. Port 0 is turned on, so that resistor network 160 no longer controls the address lines A08-A12 of the Address Bus, and normal operation commences under control of microprocessor 130.

1.4. Multiple-Store Configuration. As shown in FIG. 1, for businesses with multiple stores, a check transaction processing system 110 is located in each store.

One store is designated as a "host" system, and the other stores are designated as "remote" systems. The host system coordinates the global exchange of check verification data and other customer information, but otherwise operates as a local system for that store in the same manner as the remote systems. Operation as a host does not affect concurrent local operation, i.e., host/remote status is transparent to the check transaction processing operation at each store.

Each store operates relatively autonomously in developing and maintaining its local customer database and providing check transaction processing. However, the stores are also able to globally exchange certain customer information useful to all of the stores, particularly for purposes of check verification. For example, while it is probably unnecessary from a credit standpoint for the stores to exchange information about customers who typically frequent only a single store and do not present check transaction problems, the stores will probably want to exchange information about customers who have written bad checks at one or more stores, or who are in a cautionary status as new customers. Moreover, the present system permits exchange of data between stores for marketing purposes. Such a global exchange of customer information reduces the likelihood that the business will experience a significant loss from a concerted bad check writer.

Each store's customer database is updated with both local and global customer information. Each local check transaction processing system 110, including the designated host system, continually updates its customer database with local customer information, either automatically through processing check transactions or through operator-input of customer status data (such as negative status information). At regular intervals, each remote system transfers to the host selected customer information (such as negative and caution status information). The host updates its customer database with this customer information, and transfers back to each remote system global customer information from all remote systems. Each remote system then updates its customer database with this global customer information.

1.5. Exemplary Components. The detailed specifications for transaction processor 112, and its associated disk storage 114, and network communications interface 116 are not critical to this invention, being a matter of design choice. For the preferred embodiment, transaction processor 112 uses a Western Digital Processor Board Model No. WD286-WDM2 based on the Intel 80286 processor chip. Disk storage unit 114 is a Seagate Technologies Model ST225, and communications interface 116 is Sealevel Systems RS485 Communications Board Model No. SIO-485. The transaction processor runs MSDOS 3.3.

The detailed specification for point-of-sale transaction terminals 120 is not critical to this invention, being a matter of routine design specification. For the preferred embodiment, transaction terminal 120 includes the following components:

          Microprocessor 130       Zilog Z8 (86C9112PSC)
          Address Latch 132        74HC373
          EPROM 134                27C64
          LCD Module 136           Optrex DMC16207
          4 .times. 4 Keypad       Standard 4 .times. 4 matrix
          Diff. Transceiver        75176 (R5485 compatible)
          Voltage Regulator        LM2925


Alternative similar point-of-sale units are commercially available, such as from Omron Business Systems Model No. C.A.T. 90.

2.0 Functional Description

As diagrammed in FIG. 3, the check transaction processing system performs the following general functions:

(a) Verification (with Transactional Update) and Query

(b) Local Status Update

(c) Global Update

(d) Event-driven activities

(e) Customer database purge

(f) Host/Remote communications

as well as the customer database management operations necessary to support these functions. In addition, certain system information and diagnostic functions are performed.

The verification function involves sending a request for check transaction verification from a point-of-sale terminal 120 to the transaction processor, which performs the necessary database operations to process the request, update the customer database with transactional data (such as frequency and dollar amount) to reflect the current transaction, and return an appropriate response. The local status update function involves continuously inputting customer status changes (particularly to reflect bad check experience) for customers in a store's local customer database. The global update function, for multiple-store systems, involves continuously transferring among the stores selected customer information (preferably caution and negative status information). The purge function involves removing obsolete or unwanted customer records from the customer database based on specified purging criteria. The event-driven activities involve certain database management functions (such as purge and backup), as well as host/remote communications for global update, automatically performed at regular intervals.

2.1. Database Structure. The customer database includes all customer information used and maintained by the check transaction processing system. The customer database comprises two separate files containing customer information: the customer file and the negative status file. In addition, a system control file contains transactional limits used during check verification and purge limits.

The customer file contains customer records that include the following customer information:
    Field                  Description
    Check ID               Customer checking account number
    Verification Status    POSITIVE, NEGATIVE, CAUTION, CASH
                           ONLY, or STOLEN
    User Flags             User assigned flags that
                           designate a customer as
                           PREAPPROVED for check
                           transactions regardless of any
                           transactional limits, or as being
                           authorized for check transactions
                           on a MANAGER ONLY approval basis
                           regardless of actual status
    Transfer Date/Time     Date/time the customer record was
                           last accessed and updated
                           (written to disk), used in host/
                           remote transfers for global
                           update (transfers from host to
                           remote generally do not affect
                           this date)
    Access Date/Time       Last date/time the customer
                           record was accessed and updated
                           (a query function does not change
                           the access date/time)
    Status Change Date     Date/time customer status changed
                           (e.g., CAUTION TO POSITIVE)
    DWT Frequency          Day/Week/Total values for
                           transaction frequency (updated
                           transactionally during check
                           verification and globally
    DWT $Amount            Day/Week/Total dollar amounts
                           (updated transactionally during
                           check verification and globally
    Previous Status        Customer's previous status (such
                           as CAUTION prior to being rolled
                           POSITIVE)
    Frequency Since        number of check
    Transfer Total         transactions since the last
                           global transfer
    $Amount Since Transfer Total dollar amount volume since
                           the last global transfer
    Marketing Data         Purchases made of predetermined
                           products, store departments and
                           the like


The file specification for a customer record is set forth in Table 1 at the end of the specification.

The customer file is indexed by (a) check ID, and (b) status/transfer date/check ID.

The preferred intervals for maintaining frequency and dollar amount transactional data are Day/Week/Month/Total, where the day is the current 24-hour period, the week is the previous 7 days, the month is trailing 30 days, and the total is the total since the customer's first check transaction. The DWT designation will be used throughout this specification to indicate the three separate values for either Frequency or $Amount. Preferably, DWT Frequency and $Amounts are maintained on a global basis, so that for those records that have been globally updated (such as NEGATIVE and CAUTION status customer records), the DWT values will be global rather than local. Alternatively, separate local and global DWT transactional data can be maintained in the customer records, as shown in Table 2.

A customer can be assigned one of five check verification status designations:
        Status             Description
        CAUTION            The customer is a new customer, and a
                           specified check clearance interval
                           since the customer's first check
                           transaction has not passed
        NEGATIVE           The customer has one or more
                           outstanding bad checks at any store
                           location
        POSITIVE           The specified check clearance interval
                           since the customer's first check
                           transaction has passed, and no bad
                           checks are outstanding at any store
                           location
        CASH ONLY          The customer is not authorized to cash
                           checks, even though no bad checks are
                           outstanding
        STOLEN             The customer has reported stolen checks


Customer status is assigned during customer record creation, and then updated (transactionally, locally or globally) to reflect changes in customer status, such as due to elapsed time between check transactions or bad check history.

In addition, the local update function can be used to assign to a customer either of the following user flag designations, which override normal status responses to check verification or status query requests:
        User Flag          Description
        PREAPPROVED        The customer has been preapproved for
                           check transactions that may otherwise
                           exceed certain transactional limits
                           applied even to customers with POSITIVE
                           status
        MANAGER ONLY       The customer is not authorized to cash
                           checks without manager approval, even
                           though no bad checks are outstanding


In response to a check verification (or status query) request entered at a transaction terminal, the transaction processor returns a response with either customer status, or if specified transactional limits have been exceeded, a CALL MANAGER directive, unless the PREAPPROVED or MANAGER ONLY user flags in the customer's record have been set. Generally, a check transaction will be authorized if the customer has a POSITIVE status or is PREAPPROVED, will require manager approval for MANAGER ONLY regardless of status, and will be refused if customer status is NEGATIVE, CASH ONLY or STOLEN. Check authorization for customers with CAUTION status is a matter of store policy. For example, check authorization can depend upon DWT Frequency or $Amount, or the type of check transaction (such as amount of purchase only), or upon having the check transaction approved by a store manager.

The CALL MANAGER directive is not a verification status contained in a customer record, but rather, is the response to a verification request if, for any status (including POSITIVE), the current check transaction causes transactional limits specified in the system control file for DWT Frequency and $Amount to be exceeded.

The negative status file contains negative status records that include the following customer information (by location for multiple store systems):
    Field                    Description
    Check ID                 Customer checking account number
    Location                 The location identification for the
                             store (each store having a NEGATIVE
                             and/or CASH ONLY status history is
                             assigned a separate negative status
                             record)
    NEGATIVE Status          Active -- That location has a bad check
                             outstanding
                             Inactive -- That location has no bad
                             checks outstanding
    CASH ONLY Status         Active -- That location has designated
                             the customer as CASH ONLY
                             Inactive -- That location has not
                             designated the customer CASH ONLY
    Access Date/Time         Last date/time the negative status
                             record was accessed and updated (a
                             query function does not change this
                             date)
    NEGATIVE Date/Time       Date/time the status first became
                             NEGATIVE
    CASH ONLY Date/Time      Date/time the status first became CASH
                             ONLY
    BAD Frequency            Total number of bad checks at that
                             location
    BAD $Amount              Total dollar amount in bad checks at
                             that location


The file specification for a negative status record is set forth in Table 2 at the end of the specification.

The negative status file is indexed by (a) status/check ID/location, and (b) status/access date/check ID/location.

The negative status file supplements the customer file for those customers with a bad check history by recording BAD Frequency/$Amount by location, and also maintains CASH ONLY status by location.

The system control file includes the following selectable limits:
        Limits               Description
        CAUTION/POSITIVE     This limit defines a check clearance
                             interval for new customers who will be
                             rolled for check transactions after
                             that interval (assuming the first check
                             is not returned)
        CALL MANAGER         Separate DWT limits are provided by
                             status for both Frequency and $Amount,
                             defining the transactional limits
                             applied to each status
        PURGE                Separate Purge limits are specified for
                             each of the five customer status
                             designations; also used to define a
                             Reset/CAUTION interval


The file specification for the system control file, including coupon control filer, is contained in Table 3 at the end of the specification.

These limits are all specified by the user during system configuration. The CALL MANAGER limits are used to override the normal customer status response to a verification request when any DWT Frequency/$Amount CALL MANAGER limit is exceeded by the current check transaction. As an alternative to using the Purge limits for deleting customer records with a specified (by status) degree of obsolescence, these limits can be used to roll a POSITIVE or any other status back to CAUTION if the specified Reset/CAUTION interval between check transactions (defined by the corresponding Purge limit) has passed. In addition to these limits, the system control file contains various system information.

The specific design of the customer database, and in particular the file specifications for the customer file, negative status file, and system control file, are not critical to the invention, being a matter of design choice. Any customer database will likely comprise customer records identified by the customer check ID, and include selected transactional/customer information; such as check verification status and transactional frequency and dollar volume over specified intervals.

2.2. Function Codes. The specific functions available in the check transaction processing system are invoked by entering at a transaction terminal 121 a request including an appropriate function code (function key plus code number) and request data (such as check ID and $Amount).

The specific check transaction processing functions are set forth in Table 4 at the end of the specification, with each function being described in terms of function code, description, keypad input, and keypad output. These functions are in the following general categories:
    Function          Description (Function Code)
    Verify            Request check verification status for
                      the current check transaction (F55)
                      (updating the corresponding customer
                      record to reflect the current
                      transaction)
    Query             Request information about status (F1),
                      NEGATIVE status and locations (F2, F3,
                      F4) and DWT Frequency and $ Amounts
                      (F5) (the customer database is not
                      updated)
    Input Status      Add (F40, F41, F44) and Delete (F60,
                      F61, F62, F63, and F66) the status
                      values CASH ONLY, STOLEN and NEGATIVE,
                      and Add (F42, F43) and Delete (F62,
                      F63) PREAPPROVED and MANAGER ONLY user
                      flags
    Event Activity    Start (F950) and Stop (F951) an event
                      activity, request event time (F952),
                      and request activity status (F953)
    System Information Request certain system information,
                      including memory usage (F902), disk
                      usage (F903), customer file size
                      (F904), negative status file size
                      (F905), CAUTION/POSITIVE roll period
                      (F906, F907), Purge limits (F906, F908-
                      F912), CALL MANAGER limits (F906, F913-
                      F917)
    System Diagnostics Request system diagnostic functions,
                      including log-in/out (F77/F88), keypad
                      debug (F960), modem debug (F970), data
                      manager debug (F980), open/close
                      customer database (F981/F982) and
                      shutdown (F999)


2.3. Verify/Query. The verify function is used both to provide verification status (such as POSITIVE, NEGATIVE or CAUTION) for a check transaction, and to update the transactional data in the customer database. The principal difference between the verify and query functions is that, while both functions retrieve the specified (by check ID) customer record (or in the case of query, the negative status record) to provide an appropriate response, only the verify function actually updates the customer database by writing the updated customer record back to disk.

As previously noted, check reader 119 reads the MICR code on checks and senses the customer account number in order to generate a unique customer ID for use by the processor of the present invention. As previously discussed, an advantage of the present check reader 119 is its ability to detect the customer account number on any and all bank checks, regardless of the location of the account number within the MICR number and regardless of whether the account number is properly identified by spaces or symbols. In addition, the present check reader operates to check against a stored Transit Code Table to detect changes in the bank's transit code and the like.

FIGS. 4A-1 through 4A-3 illustrate a flow chart illustrating the operation of the MICR parsing and omitting function of the present invention. This function can be accomplished in the processor and storage of the check reader 119 or in the host processor 110. Explanation of the MICR parsing and omitting function is as follows:
        Step      Description
          4       Check is taken for tendering purchase
                  at retail store.
          5       Scanning device is used to read the
                  MICR code from the bottom of the check.
          6       Scanning device sends MICR data to
                  parsing processor 128a. Processor may
                  be in reader itself or external
                  computer.
          8       MICR code must now be parsed for
                  meaningful data. ANSI standards
                  specify the following field locations
                  within MICR band:
                  Amount field                 1-12
                  On Us                       14-31
                  Transit                     33-43
                  Auxiliary On Us             45-64
         9-10     Use transit field for the first part of the
                  customer's ID number.
         12       The check's sequence number (which matches
                  the number on the top right hand corner of
                  the check) must be located in order to
                  determine the customer's bank checking
                  account number.
         13       A variable length, dynamic TRANSIT CODE
                  TABLE is maintained for checks that cannot
                  be successfully parsed. In addition,
                  information for MICR changes such as new
                  transit number or addition or change of
                  Transaction Processing Code (TPC - used for
                  branch banking) are indicated in the table.
                  The indexed key for this table is the
                  transit number allowing duplicates for
                  multiple entries for each bank. Included
                  for each table entry is the current MICR
                  "mask" and a prior "mask" to show any
                  changes. Updates to this table can be
                  entered from the keypad or downloaded from
                  another computer.
         14       START a database query in the TRANSIT CODE
                  TABLE at the FIRST entry with the transit
                  number scanned from the check.
         16       If NO entry is found for this transit
                  number, proceed to the parsing functions
                  starting at step 29. Otherwise continue to
                  step 17 to determine if this table entry
                  pertains to this check.
        17-18     Use the current MICR "mask" in the table as
                  a template to determine if this MICR data
                  corresponds with this table entry. If they
                  do match proceed to step 19, otherwise go to
                  step 24 to try the next entry.
        19-20     Locate the sequence number in the current
                  MICR "mask" and use this to remove sequence
                  number from MICR data.
         21       If the prior "mask" indicates that the
                  banking institution has either changed
                  transit numbers or made additions to their
                  account number (such as TPC code for branch
                  banking), use this prior mask to build the
                  key for the OLD record. Proceed to step 61;
         24       Query for the NEXT entry in the TRANSIT CODE
                  TABLE for this transit number. If no
                  additional entry was found, proceed to
                  parsing functions starting at step 29,
                  otherwise go to step 17 to determine is this
                  table entry pertains to this check.
        29-32     Data in the Auxiliary On Us field, unless
                  otherwise indicated in the TRANSIT CODE
                  TABLE, is the check sequence number. This
                  would indicate that all data in the On Us
                  field make up the customer's bank account
                  number.
        35-37     Parse On Us field. Use any data within
                  positions 13 through 32 as the On Us field.
                  Discrete numbers are usually divided with 2
                  or more spaces or the ANSI On Us character.
                  Embedded single spaces and the ANSI MICR
                  dash are removed from within said discrete
                  numbers.
         38       Test for number of discrete numbers parsed
                  from the On Us field.
        40-43     If one, or more than three discrete numbers
                  are located in the On Us field, the sequence
                  number is either not present or is embedded
                  in such a way that its location cannot be
                  determined. The operator is signaled that
                  the sequence number cannot be determined.
                  Operator then enters the sequence number
                  including any lead zeros. The system can
                  then determine the relative position of the
                  sequence number in the On Us field and
                  stores this as an additional entry to the
                  TRANSIT CODE TABLE.
        47-49     If two discrete numbers are located in the
                  On Us field, unless otherwise indicated in
                  the TRANSIT CODE TABLE, the number with the
                  lesser value is the check sequence number,
                  and the number with the greater value is the
                  customer's checking account number.
        51-55     If three discrete numbers are located in the
                  On Us field, unless otherwise indicated in
                  the TRANSIT CODE TABLE, the number with the
                  greatest value is the customer's checking
                  account number. The smallest value is the
                  Transaction Processing Code and is appended
                  to the end of the checking account number.
                  The middle value is the check sequence
                  number.
         61       Once the bank's transit number and
                  customer's checking account number are
                  parsed from the MICR band, they are combined
                  (transit number followed by account number)
                  to form the customer's unique checking
                  account ID.
        63-64     A packet such as following is built and
                  passed to the Data Manager:
                  char source_id;      /* Node ID indicating
                                       source of packet */
                  char FLAG;           /* A flag signaling a
                                       change in account
                                       number */
                  char ID_CODE[30];    /* 30 byte field
                                       containing current ID
                                       CODE */
                  char OLD_CODE[30];   /* 30 byte field
                                       containing old ID CODE
        65-67     Use ID CODE as primary key for accessing
                  check database.
         68       If record is found, go to step 83 for the
                  verification process. Otherwise proceed to
                  step 72 for possible account change
                  processing.
         72       If FLAG indicates there was a change in the
                  account number, proceed to step 73 to locate
                  the old record, otherwise go to step 83 for
                  the verification process.
        73-75     Using OLD CODE as primary key to query the
                  check database. If no record is found,
                  proceed to step 83 for the verification
                  process, otherwise proceed to step 76 to
                  transfer the information from the OLD record
                  to the NEW.
         76       Copy OLD record to NEW record.
         77       DELETE OLD record from check database.
         78       Move new ID code into NEW record. WRITE NEW
                  record to check database.
         83       VERIFICATION PROCESS.


It can thus been seen that the check reader 119, in combination with the MICR parsing subroutine of FIGS. 4A-1 through 4A-3 operates to detect and extract the customer's account number on all checks, regardless of where located or even if improperly identified by a space or symbol. By teaching the processor any changes in the bank transit number or any unique positioning of the account number, the system thus is always able to promptly identify and detect a customer's unique ID for further use.

FIG. 4B diagrams the check verification function. A check verification function is initiated (202) by entering a verify request (check ID/function code/$Amount) from a transaction terminal, which is transmitted to the transaction processor for check transaction processing and to determine the appropriate check verification response.

The transaction processor uses the check ID input from the MICR parsing subroutine of FIGS. 4A-1 through 4A-3 to search (204) the customer file for a corresponding customer record, which is retrieved (206), or if it does not exist, created (208) with a CAUTION status. The customer record is updated (210) by rolling Access Date/Time, Status and DWT Frequency and $Amount to reflect the current access date/time.

First, the Access Date/Time in the customer record is rolled (212) forward to the date/time for the current check transaction, establishing the transaction interval, i.e., the time elapsed since the customer's last check transaction.

Next, for a given status, the transaction interval is compared (214) with a corresponding selected reset/CAUTION interval--if the transaction interval is such that the reset/CAUTION interval for the customer's status is exceeded, Status is rolled (215) to CAUTION, and the customer is treated as a new customer from that time. If the customer record has a CAUTION status, the transaction interval is compared (216) with a selected CAUTION/POSITIVE limit defining a check clearance period--if this check clearance period has passed, the CAUTION status is rolled (217) POSITIVE.

The last roll/update operation is to roll (218) the DWT values for Frequency and $Amount to reflect the current access date/time.

After the roll/update operation. (210) updates the customer record to reflect the current access date/time, the current transactional data are added (220) by incrementing DWT Frequency and adding the transaction $Amount to the corresponding DWT $Amount. The DWT transactional data in the updated customer record now reflects the current transaction.

Next, the user flags in the customer record are checked (222)--if the MANAGER ONLY flag is set, a MANAGER ONLY response is returned (225) regardless of status, while if the PREAPPROVED flag is set, the normal status response (POSITIVE) is returned (226) regardless of any transactional CALL MANAGER limits.

Finally, DWT Frequency/$Amount are compared (228) with the CALL MANAGER limits for the customer's status to determine whether any of these limits are exceeded. If not, a normal response with the customer's check verification status is returned (226); if any limit is exceeded, a CALL MANAGER response is returned (229).

For the status query function, the same roll/update operation (210) is performed to provide a customer record with updated Access Date/Time, Status and DWT Frequency/$Amount from which an appropriate status response can be derived. However, the updated customer record is only used to derive the response to the query request--the updated record is not written back to disk, so the customer database is not updated.

2.4. Local Status Update. Local status update of the customer database is accomplished by inputting certain status (and user flag) information to reflect bad check experience or store policy.

Status input functions are used to Add or Delete the status values NEGATIVE, CASH ONLY and STOLEN. Typically these functions will involve modifying the Status of an existing customer record and/or negative status record, although new records may be created. In addition, local input functions are used to Add or Delete user flags that designate the customer as PREAPPROVED or MANAGER ONLY.

For multiple store systems, a separate negative status record is kept for each location having a NEGATIVE and/or CASH ONLY status history. Thus, assuming negative status records are transferred during the global update function, each store's negative status file will contain separate negative status records for the various locations, sometimes for the same customer. Generally, a store can only affect through the local update function, negative status records for its location.

For each status input function, the update operation for the customer record includes the roll/update operation described in connection with FIG. 4B (210) to reflect the current access (update) to the customer record (which is written to disk to update the customer file).

FIG. 5 diagrams the local status input function for Add/Delete NEGATIVE status. A store uses this operation only for the negative status records for that location, and only when all bad checks have been recovered or otherwise resolved. For the Add NEGATIVE status function, the corresponding negative status record for that location is retrieved or created (230), and NEGATIVE status is set (232) Active and BAD Frequency/$Amount is adjusted (233) by adding the current bad check transaction. The corresponding customer record is then retrieved or created (235), and updated by the roll/update operation (238) but with status set (239) to NEGATIVE.

For the Delete NEGATIVE Status function, the corresponding negative status record is retrieved (230), and NEGATIVE Status is set (232) to Inactive and BAD Frequency/$Amount are set (233) to zero. If that customer has no other bad checks outstanding at any location (i.e., no other negative status records with NEGATIVE Status Active) (236), then the corresponding customer record is retrieved or created (237) and updated by the roll/update operation (238), but with status rolled (239) to its previous state (i.e., prior to becoming NEGATIVE).

For status input functions that Add/Delete CASH ONLY (which status is also kept by location in negative status file), the basic operation is the same as for Add/Delete NEGATIVE except that the BAD Frequency/$Amount data are unaffected.

For the status input functions that Add/Delete STOLEN, only the customer file need be updated. For the Add STOLEN function, the corresponding customer record is updated in accordance with the roll/update operation, but with status rolled to STOLEN. For the Delete STOLEN function, the corresponding customer record is updated and rolled to CAUTION.

For the user flag input functions that Add/Delete PREAPPROVED or MANAGER ONLY, again, only the corresponding customer record need be updated.

2.5. Global Update. For multiple-store systems, the global update function is used to coordinate the exchange of certain customer information among the individual stores.

Global update is accomplished by file (record) transfers between each remote system and the host system. The host system receives selected customer records and negative status records from each remote, updates its customer database, and then transmits globally updated records back to each of the remotes. Each remote is able to maintain a local customer database, supplemented with selected global customer information deemed to be useful to all stores in the system.

The type of customer information transferred by the global update function is based on store management policies. The recommended approach to exchanging global customer information is as follows:

(a) Negative Status Records--All NEGATIVE status records (NEGATIVE or CASH ONLY status) accessed (created or updated) since the last transfer; and

(b) Customer Records--All customer records with status values CAUTION, NEGATIVE, CASH ONLY and STOLEN accessed (created or updated) since the last file transfer;

(c) POSITIVE status records (even those designated MANAGER ONLY) are not recommended for global transfer.

As a result, the local customer database contains negative status records (including NEGATIVE and CASH ONLY status and BAD Frequency/$Amount) for all store locations (although each remote system only transfers to the host the negative status records for its location). For those customer records transferred, DWT Frequency/$Amounts can be maintained either globally or locally and globally. That is, a store may decide not to maintain both global and local transaction data since, for regular customers that primarily frequent that store (i.e., the customers of primary interest) global and local transaction data are essentially the same anyway. On the other hand, a store may want to keep its local transaction data completely separate from the global data attributable to all stores.

The host/remote file transfers that support global update are accomplished automatically through the event/activity function described in Section 2.7. Generally, for each remote system, host/remote file transfer constitutes an activity automatically invoked at predetermined regular event intervals. This procedure insures that the local customer databases are regularly supplemented with globally updated status and other customer information affecting check verification.

A global update session is initiated by a remote system, or in the alternative by a host computer. The remote transmits only those negative status or selected customer records accessed (updated) since the last host/remote file transfer. Since a remote only updates (or creates) negative status records for its location (although negative status records for other locations may be queried), a remote only transfers those local records (but will receive back from the host recently updated negative status records for all locations). And, only those updated customer records meeting the selected status criteria are transferred (i.e., POSITIVE status records are not transferred, even if designated MANAGER ONLY).

Negative status records are extracted using the index [status/transfer/date/ID/location], while customer records are extracted using the index [status/access date/ID].

FIG. 6A diagrams the host global update function by which the host system receives recently updated negative status and customer records, and performs a global update of its customer database. For remote negative status records (remote location only), the host retrieves or creates (240) a corresponding host record, and sets (243, 244) host status (NEGATIVE/CASH ONLY, ACTIVE/INACTIVE) and host BAD Frequency/$Amount equal to the corresponding remote values. For remote customer records, the host retrieves or creates a corresponding host record, and updates existing host records using the roll operation (246). Host and Remote status are compared, and if different, the host assigns status (247) according to predetermined status arbitration criteria. The host then adds (248) the Frequency/$Amount accumulated at the remote since last transfer to the Host DWT Frequency/$Amount, and selects (249) the greater of host/remote DWT data as correct, updating the host record accordingly.

After global update of the host customer database, the host transmits to the remote all negative status records and selected customer records accessed (updated) at the host since the previous transfer. Because every remote record transferred to the host caused a corresponding host record to be created or updated, and therefore accessed, the host-to-remote file transfer necessarily includes all host records corresponding to the remote records transferred to the host during that session. In particular, host negative status records for all locations, meeting the recently accessed transfer criteria, are transferred to the remote. For negative status records from other locations, the remote merely copies (253) the host record (remote location records received from the host are necessarily the same as the remote record). For customer records, the remote first rolls (254) the DWT Frequency and $ Amount. If host DWT Frequency/$Amount is less than the corresponding remote DWT data (255), the remote rolls (256) access data to insure that the remote record is transferred back to the host during the next global update transfer session (to update the corresponding host record with the greater DWD data); otherwise, the remote selects (257) the host DWT data. That is, the global update function assumes that the greater DWT Frequency/$Amount is correct. Finally, the remote compares host/remote status, and if different, assigns status (258) according to predetermined status arbitration criteria.

0 2.6. Purge. The customer database purge function allows a store to orient its customer database toward active customers, stabilizing the database size by deleting certain customer records and negative status records deemed to be obsolete.

During database purge, customer records or negative status records with a given status are read, and the access data/time is compared with the corresponding purge limit from the system control file. Records not accessed during the interval defined by the purge limit are deleted.

Implementing the purge function is optional as a matter of store policy. For the preferred embodiment, the purge limits are also used to define a reset/CAUTION interval (described in connection with FIG. 4B). If a record is not accessed during that interval, its status is rolled to CAUTION. Thus, the check transaction processing system defaults to the reset/CAUTION operation if the purge function is not operational.

The purge limits are a matter of design selection. The following purge limits are recommended:
                CAUTION                    270 days
                POSITIVE                   360 days
                NEGATIVE                   360 days
                CASH ONLY                  360 days
                STOLEN                     360 days


Because customer record status is not rolled automatically from CAUTION to POSITIVE, but only as a result of a transaction in which the access date/time is also rolled current, the customer database maintains an accurate record of CAUTION status for those first-time customers who do not return after the check clearance interval. Those CAUTION status customers who do not return to a store within a reasonable period of time can be eliminated from the customer database. Likewise, POSITIVE status customers who stop transacting business with a store can be eliminated from the active customer database.

Selected purge limits are entered into the system control file during system installation/ configuration. If the purge function is selected, performing it automatically as an event-driven activity (described in Section 2.7) is recommended.

2.7. Event/Activities. Event-driven activities are performed automatically by the check transaction processing system to implement certain functions without operator intervention.

The configuration and timing of these activities is a matter of routine design selection. The following event-driven activities, and the associated event intervals, are recommended:
            Host/Remote File Transfer    Every 15 minutes
            System Backup                Every 10 minutes
            Purge                        Every 24 hours


In addition, certain report functions can be made automatic as event-driven activities, such as reporting every day all customer records with CAUTION or NEGATIVE status.

The specified event-driven activities and associated event intervals are contained in an event table established during system installation/configuration. These activities are then executed in background at the designated event times without user intervention, and without affecting other foreground functions such as check verification. Once the event table is configured, the various activities may be started or stopped by invoking appropriate functions from a transaction terminal (functions F950 and F951 in Table 4).

For multiple-store systems, performing the host/remote file transfers necessary for global update on a regular, event-driven basis insures that CAUTION/ NEGATIVE status information for check verification purposes is kept current throughout the system. Performing such transfers at relatively short intervals keeps the individual host/remote communications sessions sufficiently short that other functions, such as check verification, are not significantly affected. Moreover, performing host/remote file transfers on a regular basis at short intervals helps guard against fraudulent bad check passing schemes.

Regularly, purging the customer database facilitates database stabilization, and focuses the database on reasonably regular customers. The need for regular, and often, event-driven driven backup is obvious, and is not burdensome of system computing resources because only those customer records actually updated during the short interval between backup events need be backed up.

2.8 Communications. The communications function is primarily used to support host/remote file transfers for global update in multiple-store systems. In addition, the communications function can be used for remote diagnostic operations.

The communications function is implemented in a conventional manner. Both the implementation of the communications function and the mode of communications (such as using modem communications over dial up lines) are a matter of routine design selection. Implementing the communications function so as to be essentially transparent to the local operation of the remote and host check transaction processing systems is recommended (see Section 3.6).

2.9. System. Certain system diagnostic and system information functions are available to users of the check transaction processing system.

These system functions are not critical to the inventory but are a matter of routine design selection. The recommended system functions are identified in Section 2.2 and Table 4, and include querying the customer database and system control file, obtaining disk usage and file size information, starting/stopping activities in the event file, and controlling certain keypad and modem configuration functions, as well as controlling certain system level functions such as log-on, log-off, open/close database, debug and system shutdown. In particular, these system functions are useful to store supervisory personnel for querying the customer database and for controlling event-driven activities, and to vendor support personnel for remote diagnostic purposes.

2.10. Risk Management. The check transaction processing system enables a store to adopt a risk management approach to check verification. Specifically, through selection of the CALL MANAGER limits for each status (including POSITIVE) a store has considerable flexibility in adjusting its check authorization policy to accommodate the different risks presented by different customers, both in terms of bad check risks and recovery risk.

Adopting specific risk management procedures for check verification is a matter of store policy implemented by routine design selection. In addition to selecting the CALL MANAGER transactional limits for each status, the reset/CAUTION interval can be selected to force customers who do not return for that interval into a CAUTION status. Moreover, the user flags--PREAPPROVED and MANAGER ONLY--can be used to assign special check verification treatment to selected customers regardless of status or transactional (CALL MANAGER) limits.

Adopting risk management approach to check verification through selecting transactional CALL MANAGER limits enables each store to make a policy decision about the degree of risk the store is willing to take within a given interval. Moreover, this approach can be tailored to the specific business climate of the store in terms of dollar volume, profitably, customer base and management philosophy. By specifying transactional CALL MANAGER limits in terms of status, frequency, dollar amount and transaction interval, the store's risk management approach to check verification can reflect statistical patterns for bad check/recovery risks.

For example, frequency and dollar volume limits are important for the CAUTION status to reduce the risk that a store will be hit by a concerted bad check scheme. (Global update is particularly important in this area.) Depending on past experience with its typical customer, or store policy, a new customer can be restricted in terms of numbers of checks and/or dollar volume during the selected check clearance interval.

Frequency and dollar volume limits are just as important for the POSITIVE status. A store should not assume any significant risk in terms of dollar volume (either for a current transaction or over a given relatively short interval such as a week) just because a customer has had one or a few checks clear. That is, total historical check transaction frequency is a significant factor in assessing the risk of cashing a given check; both in terms of likelihood that the check is bad and likelihood that a bad check will be recovered.

2.11. Customer Information Reporting. The check transaction processing system allows a store to build and maintain a customer database containing customer information useful for identifying new customers and developing customer profiles, in addition to its use for check verification.

Reporting customer information, such as verification status and DWT Frequency/$Amounts, is a matter of routine design selection and store policy.

Customer information reports are recommended (a) to identify new customers, and (b) to develop customer profiles, both of which can be used in targeting marketing, advertising and promotional programs, and for other customer relations purposes. Specifically, new customers are identified by regularly reporting customer records with a CAUTION status. Regular customers are identified by reporting customer records based on DWT Frequency data, while the level of a customer's business is identified by reporting customer records based on DWT $Amount data. Additional customer information that can be readily collected in the customer records includes zip code and marital status information useful in demographic analysis.

The check transaction processing system permits the customer information contained in the customer database to be collected in an unobtrusive and efficient manner during high volume check transactions.

3.0 Program Description

The various check transaction processing functions described in Section 2.0 are implemented using a check transaction processing system ("CTPS") program executed by the transaction processor.

The CTPS Program must implement several operations in real time:

(a) transaction terminal network communications, including communicating verification requests and the corresponding responses;

(b) database operations, including responding to verification requests and updating the customer database;

(c) event-driven activities, including global update, which must execute in the background while the check verification function is executing; and

(d) host/remote communications to support global update.

Moreover, while the purge function may be run after-hours as a batch operation, system backup should be executed at regular intervals throughout a business day as an event-driven background activity.

To achieve acceptable performance using a 286-class engine for the transaction processor, the preferred embodiment of the CTPS Program uses a multi-tasking architecture. The various functions performed by the CTPS Program are implemented as separate program tasks executed by the transaction processor in a multi-tasking mode. For the preferred system configuration (described in connection with FIG. 1), a multi-tasking architecture for the CTPS Program is superior in performance to available alternatives, such as polled interrupts.

3.1. General. As shown in FIG. 7, the CTPS Program includes various task programs interfaced through a System Kernal. Since the preferred MS/DOS Operating System is not multi-tasking, the System Kernal is required to implement (a) task switching, and (b) intertask communications. In this operating environment, the MS/DOS operating system is used only for disk file I/O, with the System Kernal interfacing functionally to the individual task programs as an operating system.

System Kernal 400 controls task switching, intertask message communications (requests and responses), subtask spawning, and task synchronization using semaphores.

Data Manager Task 500 controls all database operations used in check transaction processing functions (such as verification with transactional update, query, local status update, global update and purge), executing function requests from the other task programs (such as the Terminal Manager Task and the Event Manager Task) and returning response data.

Terminal Manager Task 700 controls data communications over the transaction terminal network, receiving function requests from the transaction terminals and spawning terminal request subtasks that transmit a request to an executing task (usually the Data Manager Task) and then build an appropriate response from the response data provided by that executing task.

Event Manager Task 800 implements activities designated for automatic execution on an event-drive basis, such as host/remote file transfers for global update, spawning a background event subtask at the specified event time to execute the specified activities.

Modem Manager Task 900 controls telecommunications primarily for host/remote file transfer for global update, but also for remote diagnostic purposes.

In addition to these check transaction processing tasks, a Screen Manager Task 950 and a System Utilities Task 960 are provided for maintenance and diagnostic purposes.

In general, for the Verify/Query and Local Status Update functions, the Terminal Manager Task sequentially polls the transaction terminals which enter and transmit requests, such as:

Verify [Function Code/check ID/Function Code/$Amount]

Query [Function Code/check ID]

Add/Delete [Function Code/check ID/Status]

For each terminal request, the Terminal Manager Task spawns a corresponding terminal request subtask that dispatches the request to a corresponding function/request routine, which sends the request to the Data Manager Task. The Data Manager Task executes the request, and notifies the function/request routine (by a semaphore operation) that response data is ready. The function/request routine then builds the appropriate response from the response data, and writes it into the terminal buffer for the requesting terminal. The Terminal Manager Task sends the response to the requesting terminal in the next polling sequence.

For the Global Update function, the Event Manager Task running in a remote system sequences through an event table, and at specified event times and intervals, spawns a corresponding event subtask to execute the global update activities, i.e., send/receive customer records and negative status records. The subtask dispatches to corresponding activity routines, i.e., activities that send/receive customer and negative status records. The send activity routines first request the remote Data Manager Task to retrieve records accessed since the previous global update, and then request the remote Modem Manager Task to transfer those records to the host Data Manager Task for global update. The receive activity routines first send requests for globally updated records through the remote Modem Manager Task to the host Data Manager Task, and then requests the remote Data Manager Task to globally update the remote customer database using the records returned by the host.

3.2. System Kernal. The System Kernal Program is implemented functionally by a multi-tasking module and a system services module.

The multi-tasking module controls resource allocation through task switching, with multi-task execution being implemented using standard context switching to swap task instructions/data between (a) the program and data memory areas allocated to the task, and (b) the task execution registers (i.e., the program counter, stack and other specified and general purpose registers). To implement intertask communications, the multi-task module allocates for each task data memory areas for request and response data, and maintains a task control block that contains for each task (a) task queues for intertask requests, and (b) semaphore flags.

The system services module implements intertask communications through calls to the multi-task module. For intertask communication, the system services module implements semaphore operations on the allocated semaphore flags in the task control block.

Functionally, the System Kernal interfaces to the various task programs that comprise the CTPS Program as a multi-tasking operating system. The Kernal performs four principal operations that establish a multi-tasking environmen