Abstract:
A method of receiving product pricing errors within a store including multiple food product scales is provided. The method includes (a) providing a store scale communications network. At step (b), a primary food product scale is provided in the store including memory for storing product pricing data. At step (c), a secondary food product scale is provided in the store including memory for storing product pricing data. At step (d), food product pricing data is communicated to the primary food product scale via the communications network and the food product pricing data is stored in memory of the primary food product scale. At step (e), the secondary food product scale identifies a potential internal product pricing data error condition and responsively requests accurate product pricing data from the primary food product scale. At step (f), after step (e), at least some of the product pricing data is sent from the primary food product scale to the secondary food product scale.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority to U.S. Provisional Patent Application 60/888,854, filed Feb. 8, 2007, the details of which are incorporated by reference. 
     
    
     TECHNICAL FIELD 
       [0002]    The present application relates generally to networked scales used to weigh food products in supermarkets, and more particularly to a system and method for automatically updating scale database information. 
       BACKGROUND 
       [0003]    Scales have been used in stores such as supermarkets and groceries to weigh and price food items and to generate a pricing label for such food items. A typical store includes multiple scales located in multiple perishables departments. It is important that weighed items be priced properly and therefore scales are commonly connected into a store network so that the latest pricing information can be provided to the scales in a timely manner. Various types of scale networks exist. The product pricing offered by any given scale is only as accurate as the last pricing updates provided to the scale through the network, and therefore an issue arises when a scale drops offline of the network for some reason as the scale may not receive updated pricing information or when the network is not configured to provide updates to the scale. 
       SUMMARY 
       [0004]    In an aspect, a method of receiving product pricing errors within a store including multiple food product scales is provided. The method includes (a) providing a store scale communications network. At step (b), a primary food product scale is provided in the store including memory for storing product pricing data. At step (c), a secondary food product scale is provided in the store including memory for storing product pricing data. At step (d), food product pricing data is communicated to the primary food product scale via the communications network and the food product pricing data is stored in memory of the primary food product scale. At step (e), the secondary food product scale identifies a potential internal product pricing data error condition and responsively requests accurate product pricing data from the primary food product scale. At step (f), after step (e), at least some of the product pricing data is sent from the primary food product scale to the secondary food product scale. 
         [0005]    In another aspect, a method of updating a food product scale, the scale including a weighing station including an associated mechanism for producing weight indicative signals, and an operator interface screen including a display, is provided. The method includes (a) sending update data to a primary food product scale. The primary food product scale is connected to a store communications network and includes memory for storing the update data. At step (b), a connection is established between a secondary food product scale and the primary food scale over the store communications network after step (a). The secondary food product scale includes a communications interface for receiving the update data when the secondary food product scale is connected to the store communications network and memory for storing the update data. At step (c), the secondary food product scale sends a request to the primary food scale in response to the connection in step (b). At step (d), the update data is sent from the primary food product scale to the secondary food product scale over the store communications network as a response to the request of step (c). The secondary food product scale saves the update data in memory. 
         [0006]    Other advantages and features of the invention will be apparent from the following description of particular embodiments and from the claims. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]      FIG. 1  is a perspective view of an embodiment of a food product scale; 
           [0008]      FIG. 2  is a schematic illustration of the food product scale of  FIG. 1 ; 
           [0009]      FIG. 3  is a schematic diagram of an embodiment of a store including multiple departments; 
           [0010]      FIG. 4  is an embodiment of flow chart for synchronizing scale databases; 
           [0011]      FIG. 5  illustrates an embodiment of a method for processing changes received by a secondary scale; 
           [0012]      FIG. 6  illustrates an embodiment of a method for synchronizing secondary scales; 
           [0013]      FIG. 7  illustrates an embodiment of a method for synchronizing a secondary scale coming on-line from an off-line condition; and 
           [0014]      FIG. 8  illustrates an embodiment of a method for updating a primary scale coming on-line from an off-line condition. 
       
    
    
     DETAILED DESCRIPTION 
       [0015]    Referring to  FIG. 1  an exemplary scale  10  is shown including a weigh station  12  and a display  14 . Weigh station  12  may take the form of a platter-type member supported in relationship to a load cell (internal of the scale housing) that produces a weight indicative signal when a food item is placed on the weigh station  12  for weighing. Illustrated display  14  may take the form of an LCD-type display, but other technologies could be used. In the illustrated embodiment the display  14  is a touch screen-type display that also functions as a user input device  16  by displaying image buttons/icons  18  that can be triggered or selected by an operator. The buttons/icons  18  allow for user selection of an item to be weighed from a menu or group  21  of items  23  presented to the user by display  14 . In one variation, the group  21  may be a numeric keypad allowing manual entry of product numbers. In another variation, the group  21  may be images of specific products that might be weighed by the scale. A separate operator input device could also be provided, for example, in the form of manually activated keys/buttons located alongside the display  14 . A side portion  20  of the scale housing holds a label printer and associated supply of labels, which are dispensed through a label slot  22  in the housing. Although display screen  14  is shown incorporated into the housing of the scale  10 , the display could take the form of a marquee-type display located on a support extending upward from the scale housing. In some implementations (e.g., a scale weigh and label system associated with a package wrapping machine for prepack), the display need not be attached to the scale/printer via a support but could be a separately housed console that is logically attached to the scale/printer. 
         [0016]    Referring now to  FIG. 2 , an exemplary schematic of the scale  10  is shown. The scale includes a controller  30 , such as a microprocessor based unit, connected to control the display  14  and user input  16  and connected to receive weight indicative signals from the weighing station  12 . A print head  32  and associated supply of label stock  34  that can be moved past the print head  32  is also shown. In one example the print head  32  may be a thermal print head for use with thermally activated label stock. However, other types of printing technologies and label media could also be used. The controller  30  is also connected with a communications interface  36 , which may take the form of a standard connector (and associated circuitry) for a USB, RS-232, Ethernet or other hard-wired communication line. In another example the communications interface  36  may be formed by a wireless communication device such as an RF transceiver. The communications interface  36  may communicate with other scales over the network. The network may also be connected to the Internet. The illustrated controller  30  includes associated memory  38  for storing product information (e.g., product names, characteristics and pricing stored in association with corresponding product numbers). 
         [0017]    Referring also to  FIG. 3 , an exemplary store plan  50  is shown with multiple scales  10  in various store perishables departments  52 ,  54  and  56  (e.g., such as the deli department, the meat and fish department, the bakery department and/or the fruit and vegetable departments), each scale connected to a network  58  for communicating with one of the other scales  10  and/or for communicating a store computer, which may be located in the store as indicated by computer  60  or at a site remote from the store as indicated by computer  62 . In a typical store application, each scale receives update data (e.g., price changes, etc.) via the network connection so that the scales are capable of labeling, pricing, tracking, etc. products accurately. The scales may receive the update data directly from a store computer  60  or  62 , from one of the other scales or from a location remote from the store (e.g., from headquarters). If a scale goes offline for some reason and fails to receive the latest update data, subsequent use of that scale may result in the use of inaccurate information and thus incorrect pricing, labeling, etc. of one or more products weighed by the scale. 
         [0018]    Referring now to  FIG. 4 , an exemplary flow diagram  70  illustrates a method for consolidating and distributing data so that all the scales  10  receive the latest update information. In the embodiment of  FIG. 4 , a primary scale  10   a  is responsible for consolidating and distributing update data pertaining to itself and one or more secondary scales  10   b  to another or other secondary scales  10   b , for example, that missed the update data. As indicated above, update data may be received from a number of sources. Lines identified as A represent operator  72  interaction with a scale that causes changes to the scale&#39;s database. Lines identified as B represent updates from a location  74  remote from the scales, such as the store computer. Lines represented as C represent uploading of update data from the secondary scales  10   b  to the primary scale  10   a . Lines represented as D represent the primary scale  10   a  synchronizing the secondary scales  10   b  with the update data. 
         [0019]    By default, a scale  10  may be configured as a primary scale or as a secondary scale. However, without a secondary scale  10   b  registered to a primary scale  10   a , the primary scale may merely listen passively for update data and update its database when update data arrives. In some embodiments, an operator may change a scale from a primary scale to a secondary scale and vice versa using the user input device  16 . In most embodiments, there is a single primary scale  10   a  for a group of secondary scales  10   b . Typically, the secondary scale  10   b  maintains the primary scale&#39;s host name/IP address in order to communicate with the primary scale  10   a  over the network. 
         [0020]    When the primary scale  10   a  has one or more registered secondary scales  10   b , the primary scale stores and maintains any update data in the form of batches received from the remote location  74  or created at either the primary scale or at any of the secondary scales (this will be described in greater detail below). The primary scale  10   a  also assigns version information to all batches, which orders the batches. During synchronization, the primary scale  10   a  not only sends the batches of update data to the secondary scales  10   b , the primary scale also keeps track of the version information sent to the secondary scales. The next time the primary scale  10   a  attempts to synchronize a particular secondary scale  10   b , the primary scale will first read the version information of the secondary scale to determine which batches of update information to transfer. The secondary scale  10   b  stores the batches of update data sent by the primary scale  10   a , updates its database with each batch as soon as the batch is received and then disposes of the batches. In some embodiments, if one of the batches of update data sent by the primary scale  10   a  corresponds to a batch stored locally by the secondary scale  10   b , the secondary scale will dispose of the batch already saved and replace that batch with the batch sent most recently by the primary scale. 
         [0021]    The primary scale  10   a  may also maintain a list of the secondary scales  10   b  assigned to it. In some embodiments, the primary scale  10   a  can purge batches of update data the primary scale maintains when all secondary scales  10   b  have received a certain batch. As will be described later, the list of secondary scales  10   b  can also be used to help the primary scale  10   a  recover from an off-line/off-power condition. 
         [0022]    A responsibility of the secondary scale  10   b  is to notify the primary scale  10   a  of the presence of local batches of update data. The secondary scale  10   b  maintains the batches of update data whether they originate locally at the scale or at the remote location. When the secondary scale  10   b  has stored the update data belonging to a particular batch of update information, the secondary scale  10   b  notifies the primary scale  10   a  of the presence of the batch of update data. At the primary scale&#39;s request, the secondary scale  10   b  uploads the batches of update data to the primary scale  10   b . Once the batches are uploaded to the primary scale  10   a , the batches may be deleted from the secondary scale  10   b . As noted above, the primary scale  10   a  will assign version information to the batch of update information received from the secondary scale  10   b , which can then be sent to the all secondary scales during synchronization. 
         [0023]      FIG. 5  illustrates a process  76  for processing changes (e.g., by an operator locally at the scale) or uploads (e.g., sent from a remote location) received by the secondary scale  10   b . At step  78 , a new batch is created by the secondary scale  10   b . Each record or command received is assigned to the newly created batch at step  79  and the changes are reflected in the secondary scale&#39;s database at step  80 . At step  82 , the secondary scale  10   b  establishes a connection with the primary scale  10   a  using the host name/IP address information. At step  84 , the secondary scale  10   b  notifies the primary scale  10   a  of the existence of the new batch of update information and the connection is closed at step  86 . At step  88 , the primary scale  10   a  establishes a connection with the secondary scale  10   b . All batches of update information are requested from the secondary scale  10   b  at step  90 . For each batch uploaded, the primary scale  10   a  starts a new batch and assigns version information at step  92 . For each record received, the primary scale  10   a , in some instances, makes the change in its database at step  94  and then assigns the record to the new batch at step  96 . At step  98 , the primary scale  10   a  confirms reception of the batch of update information and the connection is closed at step  100 . A secondary scale&#39;s flag indicating new batch present is cleared at step  102 . 
         [0024]    Referring now to  FIG. 6 , a process  104  is illustrated for synchronizing the secondary scales, for example, with the batch of update information received from one of the secondary scales  10   b  (see  FIG. 5 ) or with a batch of update information received locally by the primary scale, e.g., from an operator or from the remote location. At step  106 , the primary scale  10   a  determines that it has one or more new batches of update information that it needs to make available to its secondary scales  10   b . For each secondary scale  10   b  marked On-line, the primary scale  10   a  marks them as Needs Synchronization at step  108 . At step  110 , the primary scale  10   b  establishes a connection with one of the secondary scales  10   b , indicating a primary scale communication. The primary scale  10   a  determines whether the secondary scale  10   b  has received the batch of update data, for example, using version information assigned to the batch at step  112 . If the secondary scale  10   b  has not received the batch, the primary scale  10   a  transfers the batch of update information to the secondary scale  10   b  at step  114 . At step  116 , the secondary scale  10   b  sends a confirmation message to the primary scale  10   a  that it received the entire batch. At step  118 , the primary scale  10   a  disconnects from the secondary scale  10   b . If the secondary scale  10   b  is marked Needs Synchronization, a flag is cleared at step  120 . If there is another secondary scale  10   b  marked On-line and Needs Synchronization, the primary scale  10   a  repeats the above steps for that secondary scale. 
         [0025]    Referring to  FIG. 7 , the primary scale  10   a  also updates the secondary scale  10   b  if the secondary scale goes off-line (e.g., powers down or gets disconnected from the network) and misses update data. If the secondary scale  10   b  was powered off and then powered on, the secondary scale performs a booting up operation at step  122 . The booting up operation can include completing current batches in the secondary scale&#39;s database and/or purging incomplete batches. At step  124 , the secondary scale  10   b  performs a starting up operation. The starting up operation can include any necessary initialization. Assuming the secondary scale  10   b  is connected to the network, it then performs a coming on-line procedure. The on-line procedure may also be performed if the scale is powered on and off-line and then connected to the network. A main purpose of the coming on-line procedure is to synchronize the secondary scale  10   b  with its primary scale  10   a . At step  126 , the secondary scale purges any batches older than a preselected period of time, as well as their associated records. If a scale parameter is set to Register, then the secondary scale  10   b  establishes a connection with the primary scale  10   a  at step  128 , indicating a secondary scale communication and includes the host name/IP address information. At step  130 , the secondary scale  10   b  requests registration with the primary scale  10   a , if needed. Once the secondary scale  10   b  is registered with the primary scale  10   a , the secondary scale requests to be synchronized at step  131  with the primary scale in a process similar to that described by  FIG. 6 . 
         [0026]    As mentioned above, referring to  FIG. 8 , in some instances the primary scale  10   a  may go off-line. In these instances, one or more of the secondary scales  10   b  may be used to synchronize the primary scale  10   a . If the primary scale  10   a  was powered off and then powered on, the primary scale performs a booting up procedure at step  132 . The booting up operation can include completing current batches in the primary scale&#39;s database and/or purging incomplete batches. At step  134 , the primary scale  10   a  performs a starting up operation. The starting up operation can include any necessary initialization. Assuming the primary scale  10   a  is connected to the network, it then performs a coming on-line procedure. The on-line procedure may also be performed if the primary scale is already on and then connected to the network. A main purpose of this coming on-line procedure is to synchronize the primary scale  10   a  with all its secondary scales  10   b . At step  136 , the secondary scale purges any batches older than a preselected period of time, as well as their associated records. For each secondary scale  10   b , the primary scale  10   a  attempts to establish a connection with the secondary scale  10   b  at step  138  indicating a primary scale communication. At step  140 , the primary scale  10   a  requests all batches of update data from the secondary scale  10   b  not already stored in the primary scale&#39;s database. At step  142 , once all batches have been transferred from the secondary scale  10   b  to the primary scale  10   a , the connection is closed and the process is repeated for each secondary scale. Then, at step  144 , the primary scale  10   a  synchronizes all secondary scales  10   b  in a process similar to that described by  FIG. 6 , which places all the scales in synchrony. 
         [0027]    In some embodiments, each department ( FIG. 3 ) contains a primary scale  10   a  and one or more secondary scales  10   b  registered with the primary scale. The secondary scales  10   b  of the department depend on the primary scale  10   a  of that department for consolidation of data and recovery from off-line conditions. In other embodiments, the scales  10  may be department aware and a single primary scale  10   a  may be used to synchronize all the secondary scales  10   b  of the store. In some embodiments, a multi-level hierarchy approach may be used having intermediate scales configured as both primary and secondary scales. As primary scales, the intermediate scales can be responsible for synchronizing their lower secondary scales. As secondary scales, the intermediate scales can be responsible for uploading information to be consolidated at their higher, primary scales. 
         [0028]    It is to be clearly understood that the above description is intended by way of illustration and example only and is not intended to be taken by way of limitation. For example, instead of a scale, a printer having many of the features described above except for a weighing station may be connected to the network and be used in synchronizing the scales. The printer may act as a primary printer and may be used to collect and distribute update information to secondary scales in a fashion similar to that described above. Other changes and modifications could be made.