Abstract:
A universal price/reward system for determining product prices or reward values. The system disclosed is implemented by utilizing a table of prices, reward information, or the like distinct from a POS system&#39;s existing Price Look-Up (PLU) file format. The table data utilized may be appended to an existing PLU file, or it may exist in a separate file located on the same file server, or on a separate file server. This approach allows a retail merchant to easily create and modify incentive pricing programs and promotional reward programs without having to modify the basic structure of the PLU file or the POS application program. The universal price/reward system can be implemented as part of the PLU file, or through a separate companion file on a POS store controller or file server.

Description:
FIELD OF THE INVENTION 
     The present invention relates generally to improvements in the creation and utilization of various methods of determining pricing and reward incentives within a retail transaction. In particular, the invention relates to advantageous methods and apparatus for calculating the price to be paid, or the amount of a reward to be given, for a given quantity of an item or grouping of items purchased. The present invention allows flexibility in changing the pricing, rewards, incentives and the like without the need to re-program application program code when those changes are made. 
     BACKGROUND OF THE INVENTION 
     Retailers have traditionally used a variety of pricing methodologies to incent customers to shop in their stores and to purchase more of a given product during a shopping trip. Among the earliest pricing incentives were those that were used to offer a percentage discount, a fixed amount discount or a quantity discount, such as three units for one dollar. With the introduction of programmable Point-of-Sale (POS) equipment, retailers developed many variations on these simple incentive pricing methods. Modern POS application programs typically use a Price Look-Up (PLU) file to contain the necessary pricing, product identification, product grouping and bar code information for all items carried in the retail establishment. 
     As retailers have demanded greater pricing flexibility options from their POS suppliers, the suppliers have generally responded by adding additional program fields to the record format structure used in the PLU file. In order to implement different pricing methods, the POS application programs then need to be modified to interpret the additional PLU record fields to achieve the desired incentive pricing result. One major problem faced by the POS suppliers is that they can never anticipate all of the possible pricing and reward combination features that their end-user customers will demand. This has resulted in a continuous cycle where the POS suppliers have added features to their application programs in response to demands from their customers. One outcome from this cycle is that the POS suppliers have modified their PLU file formats by adding additional fields and increasing the length of those fields to anticipate the demands of their customers. 
     In recent years, there has been a trend in the retail industry where the retailers have sought open systems from their POS suppliers. The earliest POS systems were comprised of hardware and software that were proprietary to a given manufacturer, requiring the retailer to purchase all of their POS system components from the same supplier. While this proprietary approach helped to ensure that all the components of a given system worked together properly, it also tended to force a given retailer to stay locked into one POS supplier&#39;s equipment for a long time. By contrast, an open system is one in which the hardware and software interfaces are designed around common standards that are widely known and accepted. Although it is now possible to purchase the hardware, operating system software and application program software components separately, there are still few accepted standards in the industry for file structures and interfaces. This is true for the file structure of PLU files. The result is that retailers are still faced with the expensive problem of modifying their POS application programs and PLU file structures whenever they choose to implement different pricing or reward incentive methods. This problem is further compounded by the difficulties of having to make frequent programming changes to older POS application programs that were written in computer languages such as ASSEMBLER, BASIC and other legacy languages. Retailers are having an increasingly difficult time finding skilled programmers that are fluent in these languages. As POS suppliers have moved to more open technologies for new POS solutions, many retailers are now forced to bear the expense of maintaining or modifying these older POS application programs and the associated PLU record file structure in order to implement new pricing methods and reward incentive plans such as frequent shopper programs. These frequent shopper programs typically consist of rewarding frequent shoppers with various benefits. Such benefits include discounts for selected merchandise given at the time of purchase, notification of future promotions, as well as point accumulation rewards for repeat customer purchases over time. 
     SUMMARY OF THE INVENTION 
     The present invention recognizes that there exists a need in a variety of contexts for a method of changing pricing and reward values more readily within a POS system. Such a method should advantageously allow the pricing or reward incentive value and structure to be changed without requiring modifications to the PLU file structure and the POS application program each time such changes are desired. Such modifications may include changing the number of fields and the field lengths contained within the PLU file, as well as changes to the POS application program that might also be required to interpret the changes to the PLU file structure. 
     To this end, among its other aspects, the present invention provides a universal method and apparatus for changing pricing and reward values within a retail transaction. One aspect of the present invention includes a method for setting the price or reward value for one item, or a grouping of items, based upon the quantity of that item, or grouping, purchased. The methods and apparatus described also allow for setting a price or reward value for multiple purchases of an item, or grouping of items, by a given customer over a period of time. The methods and apparatus described also provide the capability to repeat a sequence of different prices and reward levels based upon cumulative purchases. As described in greater detail below, the present invention may be much more readily implemented than existing methods, while providing more flexibility to make price and reward value changes than existing methods. 
    
    
     A more complete understanding of the present inventions, as well as further features and advantages, will be apparent from the following Detailed Description and the accompanying drawings. 
     DESCRIPTION OF THE DRAWINGS 
     FIG. 1 illustrates a POS terminal suitable for use in conjunction with the present invention; 
     FIG. 2 illustrates a POS store system suitable for implementing one embodiment of the present invention; 
     FIG. 3 illustrates a process for determining item pricing or reward level within a single transaction in accordance with the present invention; 
     FIG. 4A illustrates a universal price table in accordance with the present invention; 
     FIG. 4B illustrates a universal price table in accordance with the present invention; 
     FIG. 5 illustrates a process for determining item pricing or reward level within subsequent transactions in accordance with the present invention; and 
     FIG. 6 illustrates a table recording prior purchase quantities of various items in accordance with the present invention. 
    
    
     DETAILED DESCRIPTION 
     The disclosed and presently preferred embodiment is in the context of a point of sale (POS) system. However, the universal method of determining prices and rewards of the present invention can also be advantageously incorporated into Web based ordering, operator assisted telephone ordering, stand alone (POS) terminals or any application or apparatus that uses an item code method of determining prices. 
     FIG. 1 illustrates a POS terminal  100  adapted for use in conjunction with the present invention as described further below. A base unit  110  includes a microprocessor  111 , memory  112  and a communications adapter  113 . The POS terminal  100  communicates with other computers via the communications adapter  113  via the local area network connection  150 . Peripheral input and output devices are connected to the base unit  110 , including an operator keyboard  121 , an operator display  123 , a cash drawer  120 , and a receipt printer  122  for printing paper receipts. A barcode scanner  130  is also connected to the base unit. 
     The POS terminal  100  is adapted for use in conjunction with the present invention by storing software in memory  112  of the POS terminal. This software performs the routines required to determine the price or reward value of the items scanned by the barcode scanner  130 . 
     FIG. 2 illustrates a POS store system  200 , including one or more POS terminals  210  and one or more POS servers  220  that provide price data and universal price/reward value records to the POS terminals  210 . The item pricing data may be contained in a price look-up (PLU) file and the universal price/reward value records may be contained in the PLU file, or a separate universal price/reward file stored on a disk drive  221 . The POS store system  200  may include a central database  250  remotely located from the store and connected to the POS server via a communications link  251 . 
     FIG. 3 illustrates a procedure  300  for determining the item price or reward value in accordance with one aspect of the present invention. The process begins at process step  302 , when the barcode of an item is scanned by a scanner such as the barcode scanner  130  of FIG.  1 . At step  304 , the barcode scanner provides the Universal Product Code (UPC) to the POS application program, which in turn sends a query to a file server such as the POS server  220  in FIG.  2 . While the present invention makes reference to UPC codes, it will be recognized that other codes may also be suitably employed. At process step  306 , the POS server returns the PLU record to the POS terminal. The PLU record is read at step  308  to determine the item price and to determine if there is a universal price/reward record available for the item. If there is no universal price or reward record for the scanned item, the process proceeds to step  312 . At this step, the item price is read from the PLU record and the transaction total is incremented. At process step  314 , the POS application program waits for the next item to be scanned, or for the POS terminal operator to indicate that there are no more items to be scanned. If another item is scanned, the process returns to step  302 , wherein steps  304  through  314  are repeated. The POS operator would indicate that there are no more items to be scanned by pressing a total key on the operator keyboard such as the operator keyboard  121  in FIG.  1 . If step  308  determined that there was a universal price/reward record for the scanned item, the process would proceed to step  310  and the POS application program would send a query for the universal price/reward record to the POS server. Alternately, the PLU record may contain the universal price/reward record within the PLU file, obviating the need for a separate query in step  310 . As a further alternative, the PLU query of step  304  may execute a simultaneous query of the universal price/reward file, if such file exists separately from the PLU file. When the operator indicates that there are no more items to be scanned, the process proceeds to step  316 , wherein the collected universal price/reward records are processed. It will be recognized that the processing of said universal pricing records in step  318  may vary based upon the particular implementation of the universal price/reward system. For example, in one implementation, each scanned quantity of a given item may be priced at the normal regular price. Then, when the universal price record is processed, the POS application program may credit the total discount allowed on the sum of the quantity purchased, and indicate as such in a single line item on the customer&#39;s printed receipt. In another implementation, the universal price record is processed as each item is scanned and the discount is displayed and printed immediately. Another implementation may sort the purchased items before applying the discount or reward. This is useful in properly applying per dollar or per pound types of rewards. The process ends at step  318  when the POS operator indicates that the transaction is completed by pressing a tender type key on the POS terminal operator keyboard. 
     A preferred embodiment of the present method comprises three elements. The first element is a table of price or reward values, the second element is a mechanism for identifying the end of the table and the third element is a mechanism for indicating a point of repetition. In this implementation, the table of price or reward values contains a one element list that correlates an item price or reward value with the quantity of an item, or grouping of items. Another implementation may utilize a two element list. The first element is the count of items at the price or reward value specified in the second element. FIG. 4A illustrates a one element table where the first quantity of a given item is associated with the first price, the next unit of the same item is associated with the next price, and so on for subsequent units. The preferred embodiment applies such pricing values for all units of a given item purchased at one time. For example, if an item is $1.29 for one unit but is being promoted as two units for $2.38, the method uses a table look-up to determine that the first unit is $1.29 and the second is $1.09 for a total of $2.38. A method for identifying the end of the table, such as a table length variable or table end flag, is used to determine the price of any quantities of an item that exceeds the number of entries in the list. For example, if a table length variable indicates that there are seven entries in the table, all units in excess of six are priced the same as the seventh entry, or $0.79 in this example. This method allows for determining the price or reward value for large quantities of an item without having to provide an equally long table of prices or reward values. This method also allows for indicating a repetition point in the table of price or reward value entries. This repetition point is utilized to allow for a repetitive sequence of price or reward values within the table of values without having to provide a large table of repeating values. In this implementation, FIG. 4B illustrates an example where the table entries are set to result in two units selling for $2.38 with no further discounting. In this example the ‘Repeat Index Start’ entry has been set to quantity  1  and the ‘Repeat Index End’ has been set to quantity  2 . In another implementation, the ‘Repeat Index End’ may always be assumed to be the end of the given price or reward table. Thus, the price for each unit would alternate between the first two price entries, yielding a price of two units for $2.38. For example, the third unit would be $1.29 for a total of $3.67, and the fourth unit would be $1.09, resulting in a total of $4.76 for four units. In this embodiment of the present invention, the POS application program withholds the printing of the customer receipt until all items are scanned, allowing all quantities of a given item to be grouped together on the paper receipt. 
     In another embodiment of the present invention, the universal pricing method can also be applied to subsequent purchases of a given item at the same physical store location, or at other stores within a retail chain. This may be accomplished by adding a fourth element to the method described above that writes an entry into a record in a central database. This record is keyed to some type of customer identification, such as a frequent shopper program identification number. FIG. 6 illustrates such a record, wherein a customer specific record contains multiple named variables which can be used as counters to track specific items or group of items purchased in past transactions by that customer. The first entry in the record contains the customer number. Subsequent entries contain the variable name and quantity of such item or group of items purchased in past transactions. The variable name may be a PLU number or a user assigned ID to track a grouping of items. 
     FIG. 5 illustrates a procedure  500  for accumulating the past purchase activity of a frequent shopper in a grocery store. The process begins at step  502 , wherein the customer would present a barcoded frequent shopper card to the cashier to be scanned. At process step  504 , the POS application program would send a query to a central database facility, such as the central database  250  in FIG.  2 . The central database facility returns the query at step  506 , with the PLU information and prior purchase quantities as illustrated in FIG.  6 . The process then proceeds to step  302  of process  300  as illustrated in FIG.  3 . At step  316  of process  300 , the POS application program would utilize the PLU information from the central database query to determine the proper entry point into the each of the appropriate universal price and/or reward value records. For example, instead of starting at quantity  1  for PLU number  01  as illustrated in FIG. 6, the POS application program at step  316  of process  300  would determine that this customer had already purchased  3  units, and subsequently price the first unit of this transaction at the price corresponding to the fourth table entry, or $0.89 as illustrated in FIG.  4 A. After the transaction is completed at step  318  of process  300 , the POS application program returns to process  500  at step  510 . At step  512 , the customer&#39;s record of prior purchases is updated in the central database facility. In this embodiment of the present invention, the POS application program may withhold the printing of the customer receipt until all items are scanned such that all quantities of a given item are grouped together on the printed receipt.