REGISTER  |  SIGN IN
United States Patent6377935
Deaton , ; et al.April 23, 2002
Title
Method and system for selective incentive point-of-sale marketing in response to customer shopping histories
Abstract
A system and method is disclosed for customer promotion. A terminal enters a customer's identification code, along with customer transaction data, at the point-of-sale. A memory stores a database of previously entered customer identification codes and transactions data. Circuitry is provided for generating a signal representative of a customer's shopping history, wherein incentive coupons may be issued to customers in dependence upon the signal.
Inventors:Deaton; David W. (Abilene, TX), Gabriel; Rodney G.  (Abilene, TX)
Assignee:Catalina Marketing International, Inc. (St. Petersburg, FL)
Appl. No.:815756
Filed:March 12, 1997
Current U.S. Class:705/14 
Field of Search:705/14
U.S. Patent Documents
2995727August 1961Quade
3316536April 1967Andrews et al.
3465289September 1969Lein
3528058September 1970Bond
3535682October 1970Dykaar et al.
3576539April 1971Huber
3605092September 1971Richard
3629829December 1971Ordower
3786421January 1974Wostl, et al.
3833885September 1974Gentile et al.
3876981April 1975Welch
3914789October 1975Coker, Jr., et al.
3941977March 1976Voss et al.
3949363April 1976Holm
3959624May 1976Kaslow
3987411October 1976Kruklitis et al.
4015701April 1977Templeton
4027142May 1977Paup, et al.
4053735October 1977Fondos
4053737October 1977Lafevers et al.
4063070December 1977Delarue et al.
4087789May 1978Beery
4088879May 1978Banka et a
4107653August 1978Kruklitis
4109238August 1978Creekmore
4124109November 1978Bissell et al.
4127770November 1978Baader
4142235February 1979Tadakuma et al.
4143355March 1979MacIntyre
4143356March 1979Nally
4148010April 1979Shiau
4176783December 1979Eppich
4201978May 1980Nally
4208575June 1980Haltof
4245211January 1981Kao
4260880April 1981Thomas
4277689July 1981Thomas et al.
4325117April 1982Parmet et al.
4332325June 1982Manizza
4356472October 1982Ku et al.
4380734April 1983Allerton
4381494April 1983Wisner
4396902August 1983Warthan et al.
4399553August 1983Toyama
4404649September 1983Nunley et al.
4425626January 1984Parmet et al.
4439670March 1984Basset et al.
4441204April 1984Hanna
4453074June 1984Weinstein
4510615April 1985Rohrer
4523330June 1985Cain
4547780October 1985Cummins
4547899October 1985Nally et al.
4554446November 1985Murphy et al.
4595997June 1986Parmet et al.
4617457October 1986Granzow et al.
4628194December 1986Dobbins et al.
4670853June 1987Stepien
4672377June 1987Murphy et al.
4672572June 1987Alsberg
4673802June 1987Ohmae et al.
4674041June 1987Lemon et al.
4676343June 1987Humble et al.
4678895July 1987Tateisi et al.
4703423October 1987Bado et al.
4722054January 1988Yorozu et al.
4723212February 1988Mindrum et al.
4727243February 1988Savar
4748668May 1988Shamir et al.
4748673May 1988Barre et al.
4750119June 1988Cohen et al.
4776021October 1988Ho
4791281December 1988Johnsen et al.
4797938January 1989Will
4799156January 1989Savit et al.
4809351February 1989Abramovitz et al.
4810866March 1989Lord, Jr.
4812628March 1989Boston et al.
4821186April 1989Munakata et al.
4825045April 1989Humble
4833308May 1989Humble
4872113October 1989Dinerstein
4882675November 1989Nichtberger et al.
4885685December 1989Wolfberg et al.
4887207December 1989Natarajan
4891503January 1990Jewell
4897880January 1990Wiber et al.
4908761March 1990Tai
4910672March 1990Off et al.
4933536June 1990Lindemann et al.
4941090July 1990McCarthy
4947321August 1990Spence et al.
4949256August 1990Humble
4972504November 1990Daniel, Jr. et al.
4975841December 1990Kehnemyi et al.
4982346January 1991Girouard et al.
5008518April 1991Taussig et al.
5010485April 1991Bigari
5014324May 1991Mazumder
5025372June 1991Burton et al.
5040226August 1991Elischer et al.
5053607October 1991Carlson et al.
5053955October 1991Peach et al.
5054092October 1991LaCaze
5056019October 1991Schultz et al.
5070452December 1991Doyle, Jr. et al.
5077805December 1991Tan
5091634February 1992Finch et al.
5095195March 1992Harman et al.
5117355May 1992McCarthy
5128520July 1992Rando et al.
5173851December 1992Off et al.
5179375January 1993Dick et al.
5185695February 1993Pruchnicki
5201010April 1993Deaton et al.
5202826April 1993McCarthy
5237496August 1993Kagami et al.
5245164September 1993Oyama
5245533September 1993Marshall
5249044September 1993Von Kohorn
5251152October 1993Notess
5253345October 1993Fernandes et al.
5256863October 1993Ferguson et al.
5310997May 1994Roach et al.
5353218October 1994De Lapa et al.
5621812April 1997Deaton et al.
5644723July 1997Deaton et al.
5832457November 1998O'Brien et al.
RE30579April 1981Goldman et al.
RE30580April 1981Goldman et al.
RE30821December 1981Goldman et al.
Foreign Patent Documents
2094 532Feb., 1981GB
5216941Aug., 1977JP
5547560Apr., 1980JP
5627468Mar., 1981JP
5815547Sep., 1983JP
5817847Oct., 1983JP
5918496Oct., 1984JP
5994166May., 1984JP
WO 86/03310Jun., 1986EP
WO 91/03789Mar., 1991EP
Other References
"Frequency Programs: Cashing in on Promotions The Marketing Institute Sep. 11 & 12, 1990" by Catalina Marketing Corporation. .
"Point-of-Scan, The News letter of Electronic Marketing", Jan. 1991. .
"The Unfulfilled Promise" Incentive (Sep. 1989) pp. 123-130. .
The title page, copyright page, and p. 266 (containing the definition of a coupon) of Webster's Collegiate Dictionary, Tenth Edition. .
The title page, copyright page, and p. 120 (containing of "database") of the First Computer Dictionary. .
The title page, copyright page, and p. 126 (containing a definition of "database") of the Second Computer Dictionary. .
The title page, copyright page, and p. 202 (containing of "file") of the Second Computer Dictionary. .
Cebulski, "P&G, Central Trust develop electronic marketing system". .
The Schedule of the presentations at the May 1991 FMI Chicago Conference and the Mannarino publication. .
The title page, copyright page, and p. 237 (Containing the definition of a computer) of Marriman-Webster's Collegiate Dictionary, Tenth Edition. .
"Scanning a New Horizon; Food marketing Research Through Computerized Frequent Buyer Program," Aug. 1989, Food & Beverage Marketing, vol. 8 No. 8, p. 32. .
Catalina publication--Market Imaging Systems dated Sep. 18, 1990. .
Catalina publication "Checkout Savings System and Frequency Marketing Overview". .
The title, copyright page, and p. 304 (containing the definition of "computer") of the Second College Edition of The American Heritage Dictionary, copyright 1985. .
The title, copyright page, and p. 332 (containing the definition of "coupon") of the Second College Edition of The American Heritage Dictionary, copyright 1985. .
Ballinger, "Coupon System Might 'Replace Mail'" in DM News, Nov. 12, 1990, p. 1. .
Peterson, "Catalina Launches Two New Coupon Programs" in Adweek, Nov. 12, 1990, p. 11. .
P. 1, index page, and Johnson, "Catalina Adds Coupon Options" in Advertising Age, Nov. 26, 1990, p. 58. .
P. 1 and "Catalina Readies Test"Advertising Age, Dec. 03, 1990, p. 40. .
Cover page, page showing address label, two index pages, and "Death of Frequent Shopper Programs?" article in Food and Beverge Marketing, vol. 9, No. 12, Dec. 1990, pp. 10+. .
Photocopy of cover of folder at FMI library entitled "Front End Electronic Marketing 1991-1992 Shopper Services," photocopy of date stamped cover page of "Point of Scan" Jan. 1991 date stamped "Received Feb. 28, 1991 F. M. I. Information Service," and photocopy of the entire Jan. 1991 issue, and date stamped by FMI library of Feb. 28, 1991; all from FMI library file. .
"Confusion reigns over checking and credit card law" by Tina Cassidy. Boston Business Journal, Apr. 6, 1992 issue pp. 1, 19. .
Program of "Profitable Trade Promotion Programs," The Marketing Institute, SEp. 11 & 12, 1998. .
Thissen, "Front End Electronic Marketing Frequent Shopper & Other Programs" copyright 1991, written for the Food Marketing Institute, Washington DC. .
Raphel, "Take a card . . . any card please" Direct Marketing, Feb. 1990 pp. 63-68. .
Lexis printout. Campbell "Looking for ways to protect privacy caller ID brings calls for safeguards" Chicago Tribune, May 13, 1990, Sec. C p. 21. .
Second Declaration of Roy Van Denburgh. .
Blattberg, "Assessing and Capturing the Soft Benefits of Scanning," A Study Conducted for the Coca-Cola Retailing Research Council, May 1988. .
Perspective on Electronic Marketing publication, written for FMI by Carlene Thissen, May 1990. .
Competitive Edge publication, "What are we Learning About Electronic Marketing," Jun. 1990 published by Willard Bishop Consulting, Ltd.. Obtained from FMI library from a folder entitled "Front-End Electronic Marketing 1989-1990 Shopper Services". .
Lexis printout. "DIY promos via video POS," Chain Store Age Executive with Shopping Center Age, Apr. 1988, p. 76. .
Lexis printout. An Article by Stuart Elliot entitled "A Last Hurdle for Shoppers: The Checkout-Counter Pitch" (hereinafter referred to as "the Elliot publication"was published in the New York Times, Jan. 11, 1993, late ed., sec. D, p. 7, col. 3. .
Lexis printout. An Article by Antonia Feuchtwanger entitled "Smarter cards think for themselves in US tests" (hereinafter referred to as "the Feuchtwanger publication"was published in the Daily Telegraph Telegraph on Nov. 2, 1990, p. 20. .
Lexis printout. An article by Mindy Fetterman entitled "Capturing customers in cool economy" (hereinafter referred to as "the Fetterman publication") was published in USA Today on Nov. 29, 1990, p. 8B. .
Lexis printout. An article by Sidney Feltenstein et al. entitled "Does couponing make good business sense?" was published in Restaurant Business Magazine on Jan. 20, 1991, vol. 90, No. 2, p. 152. .
Lexis printout. An article by Rob Jackson entitled "Packaged Goods' New Target: Database Marketing." Published Dec. 10, 1990 in DM News, p. 23. .
An article by Nancy Zeldis entitled "Targeted coupons hit non-users" was published in Advertising Age on Apr. 27, 1987 p. S-26. .
Lexis printout. An article by Susan Bass and Jerrold Ballinger, entitled "Early Use of Supermarket Scanners Brings DM and Sales Promotion Close2: Professors," published in DM News dated Mar. 01, 1989 p. 30. .
Lexis printout. An article by Jeffery Kutler entitled "Chase Forms Alliance with Terminal Vendor" from The American Banker dated May 18, 1988, p. 8. .
The title page, copyright pate, and p. 685 (containing the definition of "prospective") of Webster's Seventh New Collegiate Dictionary (1967). .
O'Brien Continuation Application, Serial No. 09/659,333 filed Sep. 12, 2000. .
Merriam Webster's Collegiate Dictionary 10.sup.th ed. p. 993 definition of "represenative" n. .
"Getting Personal", Retail Week, Jun. 1, 1990, p. 19. .
Facsimile to John Halak dated Oct. 23, 2000. .
"Frequent Shopper Programme at Vons", The IBM International Executive Conference for Retailers, Jun. 13-15, 1990. .
Facsimile to Alun Palmer dated Oct. 26, 2000. .
"Front End Electronic Marketing Frequent Shopper & Other Programs" Food Marketing Institute, 1991; Carlene A. Thissen. .
"Perspectives on Electronic Marketing with Emphasis on Promotion Inside Supermarkets", Food Marketing Institute, 1990, Carlene A. Thissen. .
"What's New in Supermarket Promotion", New York Times, Jun. 18, 1989, Lynette D. Hazelton. .
"In this Computer Age, Who Needs Coupons", New York Times, Jun. 15, 1989, Michael Freitag. .
Ronald Tanner "A New Dimension in Marketing", Progressive Grocer, vol. 66, No. 5, May 1987, pp 133-134, 136. .
Lena H. Sun, "Checking Out The Customer," The Washington Post, Sunday , Jul. 9, 1989. .
"UKROP's Test Data Base Marketing Program Electronic Couponing Tracks Buying Behavior of Valued Customers", Chain Store Age Executive, Sep. 1987. .
"Grocery Stores Copy Airlines With Frequent Flyer Bonuses", Wall Street Journal 3 Star, Eastern, Aug. 7, 1986. .
"S & H, Saffer Reward Frequent Shoppers", Advertising Age, Mar. 16, 1987, p. 22. .
"Frequent Buyer Programs Get Off the Ground", Dairy Foods, Nov. 1989, p. 64. .
"Giant to Test Supermarket Cash Rebates", Washington Post, Jun. 14, 1989, pp. A1, A32. .
"Quaker's Direct Hit", Direct Marketing, vol. 53, No. 9, p. 52, Jan. 1991..~
Primary Examiner: Stamber; Eric W.
Assistant Examiner: Champagne; Donald L.
Attorney, Agent or Firm:Oblon, Spivak, McClelland, Maier & Neustadt, P.C.
Parent Case Text


RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No. 08/178,052, filed Jan. 4,1994, now U.S. Pat. No. 5,644,723 pending; which is a continuation of U.S. application Ser. No. 08/096,921, filed Jul. 23, 1993, abandoned; which is a continuation-in-part of U.S. application Ser. No. 08/063,413, filed May 17, 1993, now U.S. Pat. No. 5,512,812; issued Apr. 15, 1997; which is a continuation of U.S. application Ser. No. 07/886,383, filed May 19, 1992, now abandoned; which is a continuation-in-part of U.S. application Ser. No. 07/826,255, filed Jan. 24, 1992, now abandoned, which is a continuation of U.S. application Ser. No. 07/345,475, filed May 1, 1989, now abandoned.

This application also relates to U.S. application Ser. No. 08/117,951, filed Aug. 30, 1993, abandoned; U.S. application Ser. No. 08/302,521, filed Sep. 6, 1994, now U.S. Pat. No. 5,675,662 issued Oct. 7, 1997; U.S. application Ser. No. 08/178,056, filed Feb. 28, 1994 now U.S. Pat. No. 5,638,457 issued Jun. 10, 1997; U.S. application Ser. No. 07/885,649, filed May 19, 1992, now U.S. Pat. No. 5,237,620, issued Aug. 17, 1993; U.S. application Ser. No. 07/886,383, filed May 19, 1992, now U.S. Pat. No. 5,305,196, issued Apr. 19, 1994; U.S. application Ser. No. 08/221,622, filed Mar. 30, 1994, now U.S. Pat. No. 5,448,471, issued Sep. 5, 1995; U.S. application Ser. No. 07/886,385, filed May 19, 1992, now U.S. Pat. No. 5,201,0101, issued Apr. 6, 1993; U.S. application Ser. No. 08/016,991, filed Feb. 10, 1993, now U.S. Pat. No. 5,327,508, issued Jul. 5, 1994; U.S. application Ser. No. 08/177,690, filed Jan. 1, 1994, now U.S. Pat. No. 5,388,165, issued Feb. 7, 1995; U.S. application Ser. No. 08/303,631, filed Sep. 8, 1994, now U.S. Pat. No. 5,592,560, issued Jan. 7, 1997; U.S. application Ser. No. 08/336,880, filed Nov. 9, 1994, now U.S. Pat. No. 5,430,644, issued Jul. 4, 1995; U.S. application Ser. No. 08/429,938, filed Jun. 3, 1995, pending; U.S. application Ser. No. 08/701,456, filed Aug. 22, 1996, pending, U.S. application Ser. No. 08/457,300, filed Jun. 1, 1995, pending; U.S. application Ser. No. 08/458,172, filed Jun. 1, 1995, pending; and U.S. application Ser. No. 08/457,299, filed Jun. 1, 1995, pending, by the present inventors and are assigned to Credit Verification Corporation, the assignee hereunder.
Claims

What is claimed is:
1. A method of performing customer promotion at a store with a computer having a processor and a memory, the method comprising the steps of:
storing in the memory data representative of a plurality of customer's prior purchases of a plurality of different products at a store in association with a customer's unique identification;
determining with the processor from said stored data information regarding a product frequently previously purchased on a plurality of separate shopping visits by an individual customer relative to said plurality of different products previously purchased in previous visits to the store by said individual customer; and
in response to said information, issuing a promotion to said customer at the point-of-sale in an effort to incent said customer to return to the store, said promotion providing incentives including a promotion on said product frequently previously purchased on a plurality of separate shopping visits by said customer relative to said plurality of different products purchased by said individual customer, such that promotions on specific products consistently preferred by said individual customer are issued to said individual customer.

2. The method of claim 1 wherein said promotion seeks to induce said customer to return to the store at a future time.

3. The method of claim 1 wherein said promotion seeks to induce said customer to buy said product previously purchased by said customer.

4. The method of claim 1 wherein said promotion seeks to induce said customer to increase future purchase values over an amount previously paid by said customer.

5. The method of claim 1 and further comprising:
detecting financial data regarding a customer's shopping history; and
storing said financial data in association with said customer's unique identification.

6. The method of claim 5 and further comprising:
issuing said promotion to those customers whose prior shopping history meets shopping requirements.

7. The method of claim 6 wherein said customer's number of said plurality of separate shopping visits equals said customer's number of shopping transactions at the store during a time period.

8. The method of claim 1 and further comprising:
monitoring whether or not said promotion has been effective; and
subsequently issuing an additional promotion depending upon the results of said monitoring.

9. The method of claim 8 wherein said promotion is monitored by scanning identification numbers on said promotion when it is redeemed.

10. The method of claim 8 wherein said additional promotion is issued in dependence upon the results of said monitoring and is increased in value over said prior promotion.

11. A system of customer promotion at a store comprising:
a memory for storing data representative of a customer's prior purchases of a plurality of different products at the store in association with a customer's unique identification;
circuitry responsive to said data stored in said memory for generating indications of a product frequently previously purchased on a plurality of separate shopping visits relative to the plurality of different products previously purchased by an individual customer in previous visits to the store; and
apparatus for issuing a promotion at the point-of-sale to said individual customer in response to said indications, in an effort to incent said individual customer to return to the store with a sales promotion on a specific product relatively favored by said individual customer, said promotion providing incentives for said product frequently previously purchased on a plurality of separate shopping visits by said individual customer relative to other products previously purchased by said individual customer.

12. The system of claim 11 wherein said apparatus issues said promotion to those customers whose prior shopping history meets shopping requirements.

13. The system of claim 11 wherein said customer's unique identification comprises the customer's credit card number.

14. The system of claim 11 wherein said customer's unique identification comprises the customer's checking account number.

15. The system of claim 11 wherein said customer's unique identification comprises the customer's debit card number.

16. The system of claim 11 wherein said customer's unique identification comprises a merchant issued unique customer identification code.

17. The system of claim 11 wherein said customer's number of plurality of separate shopping visits equals the number of said customer's shopping transactions at the store during a selected time period.
Description
TECHNICAL FIELD OF THE INVENTION

This invention relates to transaction processing and analysis methods and systems, including check, credit card and debit card verification and marketing systems, and more particularly, to a method and system for processing and developing a customer database of customer information, such as credit verification status and transaction frequency and dollar volume over specified intervals, that can be used for credit verification, targeted customer marketing and other customer relations purposes.

BACKGROUND OF THE INVENTION

Retail and other business establishments that serve a large number of customers generally have a problem obtaining transactional information about their customers, such as for identifying new customers and determining transactional patterns for repeat customers (such as transactional frequency and dollar volume).

For those stores that experience a high volume of transactions, an immediate customer information problem is determining whether to authorize a transaction, whether check, debit card or credit card, in the typical situation where the sales clerk does not personally know the purchaser. Beyond this immediate problem of credit verification, these stores have a broader need for gathering transactional information that could be used in developing customer profiles useful in targeting and implementing advertising, marketing and promotions.

For example, a typical grocery store does a high transactional volume with checks comprising a significant percentage of the total transactions (typically as much as 85%). These businesses strive for maximum efficiency in completing transactions at the checkout counter, which results in a minimum of contact between the customer and the sales clerk. In this sales environment, neither clerks nor store managers typically develop any significant personal relationship with an individual customer.

Since check transactions account for such a significant percentage of a grocery store's business, these stores naturally make an effort to minimize the number of bad checks that will be returned. Typically, the store will require an additional piece of identification, such as a driver's license and/or a major credit card. However, this requirement for additional identification reduces the efficiency of the checkout process, and inconveniences the significant majority of check transaction customers who do not write bad checks--typically, a grocery store's bad check experience will be approximately 2% of its check transactions.

Thus, check verification presents a store with problems in customer relations and risk management. A store naturally seeks to improve customer relations with the great majority of customers who do not present check transaction problems by efficiently and quickly authorizing check transactions. However, the store must guard against the financial risks from customers who do write bad checks, either as part of a concerted bad check scheme or as a result of less larcenous conduct that may range from simple bookkeeping mistakes to overly aggressive check floating. In the former case, bad check risk is greatly dependent upon abnormal check transaction activity over a given interval. In the latter cases, the bad check risk is greatly dependent upon check transaction history (total check transaction frequency and dollar volume at a store).

The check transaction risk management problem has two principal aspects--the risk that a person will write a bad check and the risk that a bad check cannot be recovered. Again, both of these risk factors are greatly dependent upon a customer's historical check transaction activity. As the total number of check transactions by a customer at a particular store increases, both the risk that the customer will write a bad check decreases, and more significantly, the risk that store will not be able to recover on a bad check decreases.

For example, a customer with fewer than 200-300 check transactions at a store presents a relatively high risk in terms of recovery on a bad check, while a customer with more than 600-700 check transactions presents a minimal risk. Thus, a store practicing risk management should put substantially more restrictions in terms of check transaction frequency and total dollar volume over given intervals in the former case than in the latter.

These risk management problems are multiplied in the case of multiple store businesses, particularly in the case of concerted bad check cashing schemes. In that case, the typical pattern is to move from store to store within a relatively short period of time. Such credit risks are also present with other forms of financial instruments, such as credit cards, or debit cards unless credit verification procedures are in place.

Beyond these check and credit verification and risk management problems, grocery and other retail stores have a broader problem in accumulating customer information because of the emphasis on minimizing the amount of time required for a sales transaction, and the attendant impersonality of the customer relationship. Thus, it is extremely difficult to develop any meaningful customer profiles, or to identify customer groups such as regular customers and new customers who might become regular customers. If a store could accumulate more detailed customer information, customer profiles could be developed and used for targeted advertising, marketing and promotional programs.

Accordingly, a need exists for a transaction processing system for individual stores (in both single and multiple store environments) that facilitates transactions by improving the efficiency of the verification process, and that maintains a local customer database containing transactional information about the store's customers useful for verification risk management, and for other customer relations purposes such as identifying new customers and profiling regular customers.

Prior credit verification systems require connecting a point-of-sale terminal through telephone lines to a remote transaction processing system, thereby increasing not only the cost of operating the systems, but also increasing the time for providing check or credit verification. Also, existing systems typically do not focus on maintaining a local customer database useful not only for check or credit or debit card transaction processing, but also for identifying new customers and developing customer profiles for regular customers.

In prior systems, information regarding checks returned to a store by its bank is entered into a computer (PC). This PC stores information on that check (name, address, dollar amount of the check, reason for the return of the check, etc.) and this PC can be programmed to transfer that data to other processors controlling point-of-sale keypad terminals, both in the same and in other store-based operations. Responses displayed by one of these point-of-sale terminals may be altered pursuant to these transfers of data. Alternatively, data on returned checks may be entered into a multiple tasking computer environment in which the same processor simultaneously manages the operations of returned check entry and point-of-sale keypad operation. This multiple tasking processor can be programmed to transfer data to other similar store-based operations by telephone communications.

Copending patent application Ser. No. 07/826,255 discloses a system and technique wherein a customer's checking account number may be used as a unique customer identification number to provide credit verification and also to perform marketing functions. In such a prior system, such customer checking account numbers have been manually entered by the retail store clerk, thus causing delay and possible inaccuracies. A need has thus arisen for an automated system for providing quick and efficient check verification and marketing follow-up. Previous automatic readers have, however, not been satisfactory for such purposes, because of their inability to uniformly detect desired account information on all checks in a consistent manner.

Marketing by retail stores has previously been confined to advertising to large segments of the population, and often to existing customers. Competition among stores has made it more important to target advertising, and a need has arisen for marketing techniques to target non-customers or infrequent customers. It would be particularly advantageous if such targeted marketing could be accomplished in conjunction with a check or credit verification system.

Retail stores have heretofore attempted to provide marketing to its customers by the issuing of cards bearing individual numbers associated with a customer (which may or may not be smart cards) which contain information which may be automatically detected by a reader. Before a customer can obtain such a card, the customer has to fill out a substantial amount of information, such information is being entered into the system prior to the card being issued. Stores, however, have found that it is difficult to get a large segment of its customers to provide such information and customers also do not wish to or forget to use such cards at the checkout terminal. Hence, use of such cards for marketing purposes has not been particularly successful.

For example, when such cards are used, another form of financial payment has to be implemented into the system, such as by accepting cash, verifying and accepting a check or verifying and accepting a credit or debit card or the like. Use of such shopping cards thus creates additional delays at the terminals and has not been found to enable stores to reach high-target individuals such as the infrequent shopper, since such people are unlikely to have or to utilize such cards. Moreover, prior stores which have used such shopping cards have tried marketing such as direct mail to an untargeted group of customers or for immediate discounts on current transactions. The providing of such rewards without requiring some future activity by the customer has not been found to provide good marketing results by inducing the customer to do some act in the future.

A need has thus arisen for a method and system utilizable by retail stores to provide targeted incentive marketing to customers by utilizing account codes on such financial instruments as a check, credit card or debit card, without the combination of a marketing card. It would be further advantageous for such a method and system to be able to utilize a multiplicity of transaction documents in order to identify individual customers to enable such targeted marketing. It would further be desirable to provide such targeted marketing in combination with credit verification.

SUMMARY OF THE INVENTION

Important aspects of the present invention are to facilitate transactions by reducing the requirements for customer identification, to enable a store to adopt a risk management approach to credit verification based on a customer's transactional history (frequency and dollar volume over specified intervals), and to improve a store's marketing and other customer relations programs by collecting transactional data for that store, both current and historical, that can be used to identify new or infrequent customers, develop customer profiles and to perform targeted marketing.

More specifically, this invention is a transaction processing system that uses a customer's financial instrument account number (check, credit card, debit card or the like) as a unique customer identification number. Thus, the system does not require time-consuming checking of additional customer identification, but only requires the speedy entry of the customer's account number by use of an improved automatic reader in accordance with the present invention. The system operates at an individual store, and maintains at that store a local customer database of customer records, each identified by the corresponding customer identification number. The customer records also include customer information, such as verification data (such as verification status) as well as other selected transactional data (such as transaction frequency and dollar volume), the verification and transaction data being regularly updated with new data (such as during transaction verification).

The system includes one or more transaction terminals, coupled to a transaction processor that stores the customer database. A transaction terminal is used to transmit a customer information request (such as for check or credit card transaction verification), which includes an automatically read customer's identification number, from the point-of-sale (POS) to the transaction processor.

The transaction processor processes the customer information request, using the identification number to search the customer database and retrieve the corresponding customer record, if any. Based on the customer information in the customer record, or the lack of a customer record, the transaction processor returns an appropriate response (such as credit verification status) and marketing response information to the transaction terminal.

Thus, the method of this invention for transaction processing involves various aspects of: (a) identifying a customer by automatically reading the customer's unique ID; (b) developing and maintaining for a store a local customer database of customer records, each identified by the corresponding customer identification number, and each including customer information (such as verification status and transactional data); (c) generating a customer information request; (d) processing the request using the customer identification number to access the corresponding customer record, if any; (e) returning an appropriate customer information response based on the customer information in the customer record; (f) updating the customer database regularly to reflect new customer information; and (g) utilizing the database to perform targeted marketing functions based upon the customer's prior shopping history.

More specific aspects of the preferred embodiment of the invention are the following:

One form of the transaction terminals and the transaction processor form a token ring data communication network, although other types of networks are possible. Each transaction terminal includes (a) an automatic reader constructed in accordance with the present invention for automatically entering identification numbers, along with a keypad for entering function codes and appropriate transaction data, which form customer information requests, and (b) a display for displaying the requests and the returned responses.

The customer records in the customer database include an assigned check verification status, such as POSITIVE (transaction authorized), NEGATIVE (transaction not authorized) or CAUTION (transaction should be scrutinized or subject to certain conditions). The first time a customer attempts a check transaction at a store (i.e., a search of the customer database pursuant to a check verification request indicates no existing customer record), a new customer record with a CAUTION status is created, and a CAUTION response is returned to the transaction terminal. The customer remains in the CAUTION status for a period of time sufficient for this initial check to clear or be returned. If this CAUTION/POSITIVE interval passes, the system automatically updates status to POSITIVE; if the check is returned, customer status is updated by inputting a NEGATIVE status.

In addition to, or in place of, check verification status data, the local customer database may include credit or debit card data and transactional data such as transaction frequency and dollar volume over specified intervals. This transactional data can be used to place conditions risk management on transaction verification over and above verification status. For example, in the case of a customer with either CAUTION or POSITIVE status, if a transaction exceeds certain specified transaction limits frequency and/or dollar amount over a specified interval (such as day, week or total), a CALL MANAGER response is returned in response to a verification request, regardless of customer status.

Moreover, because the transactional data is generated and maintained locally, it provides significant information about the store's customers over and above the information necessary for verification risk management. New customers are readily identified, and prior shopping history such as frequency and dollar volume information may be used to establish customer profiles and to target advertising, marketing and promotional programs, and for other customer relations purposes.

In the case of a multiple store business, each store has a local transaction processing system, with one of the systems being designated a host site and the rest being designated remote sites. At selected intervals, each remote system transmits to the host selected customer information from its local customer database (such as customer records for those customers with CAUTION and NEGATIVE status including transactional data), which is used to update the host customer database to include this global customer information. The host, in turn, transmits that global customer information to the other remote systems.

Transaction processing is implemented by a multi-tasking program executing in the transaction processor. The program includes: (a) a terminal manager task that implements network data communication for the transaction terminals, communicating customer information requests and responses; (b) a Data Manager Task that controls the database operations necessary to respond to customer information requests and to update the customer information in the database; and (c) an Event Manager Task that implements system activities such as backup and database purge, and in the case of multiple-store systems, implements host/remote communications activities to transfer selected customer information among the stores for updating each store's local customer database with the selected global customer information.

Important features and advantages of this invention are the following. The transaction processing system uses the automatic reading of the customer's identification number, which is used as a unique customer identification number, thus avoiding the requirement for additional identification and the attendant delay in completing the transaction.

The system develops and maintains a local customer database, allowing the store to accumulate customer information relevant to the store's customers over and above that information necessary for credit verification. The system provides for the selection of procedures and criteria for database management and credit verification, allowing the store owner/manager considerable flexibility in developing and using the customer information in the store's customer database.

For check verification, the system uses three primary status levels--POSITIVE, NEGATIVE and CAUTION--allowing the store to identify those customers with a bad check outstanding, and to identify new customers and establish selected interim risk management procedures for granting those customers check transaction privileges. In addition to check verification status, the system collects and accumulates selected additional transactional data, including frequency and dollar amounts over specified intervals (such as Day/Week/Month/Quarter/Total) and other historical information such as departments shopped, products purchased and the like, thus allowing the store to adopt risk management approach to check verification tailored to the store's particular customer and financial situation by conditioning check authorization on meeting certain selected transactional limits regardless of customer status (the CALL MANAGER response), and allowing the store to develop customer profiles and to target advertising, marketing and promotions, and otherwise improve customer relations.

For multiple-store businesses, the system can use automatic host/remote transfer of selected customer information to upgrade the local customer database at each store with global customer information (such as those customers with CAUTION and NEGATIVE check verification status), thereby maximizing protection against bad checks while maintaining the local character of the store's customer database.

The transaction processing system is implemented by a multi-tasking program, and uses local area network data communication among the transaction terminals and the transaction processor, allowing efficient operation of the system at each individual store.

The system and method of the invention also provides automatic targeting of individual customers based upon their shopping history. Thus, at the point-of-sale, coupons or other incentives may be generated which are specifically targeted to a specific customer based upon his prior history. Alternatively, coupons may be later mailed to selected customer. For example, substantial rewards may be given to an infrequent shopper, while less substantial rewards may be given to a more frequent shopper. A marketing program may be implemented whereby a customer is sequentially induced to purchase additional volume or additional products based upon the customer's prior history. Based upon that customer's prior history, the types of incentive coupons can be varied by the system. Further, the redemption and efficiency of the coupons are subsequently monitored, and subsequent coupons are varied in dependency upon the monitoring. All of these and many other marketing techniques described herein are able to be accomplished in coordination with a check verification or credit authorization system without requiring additional customer identification codes.

Other objects, features and advantages of this invention will be apparent from the drawings and the following detailed description of the preferred embodiment, and the appended claims.

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"; and

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

DESCRIPTION OF THE PREFERRED EMBODIMENT

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 45A-B.

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 terminal s 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:

(a) A Z8 microprocessor 130;

(b) An associated address latch 132;

(c) An EPROM 134;

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

(e) 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 ADO-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 ADO-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 Transfer Total number of check 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 design