Synchronizing shelf input / output system and transaction system

Abstract

To provide a method and a system for synchronizing values, that are efficiently automated between computing systems.SOLUTION: In a method for synchronization between a shelf input / output system and a transaction system, a shelf IO component 106 of a transaction system 105 identifies an updated value 117 for a physical item for sale in a space, and transmits the updated value 117 to a shelf I / O system 120. Also, a delay component 107 of the transaction system 105 determines one or more delay criteria based on comparing the updated value and a prior value for the physical item. Moreover, an update component 108 of the transaction system 105 receives confirmation 130 that the updated value has been implemented by the shelf I / O system, and updates the transaction system based on the updated value in accordance with the one or more delay criteria and the confirmation.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] In many user-facing environments, multiple computing systems are used to track data updates and provide updated information to users. For example, retail environments often include a transaction-centralized system (e.g., a point-of-sale (POS) system) and an information provision or display system (e.g., electronic shelf labels (ESLs)). In many conventional environments, updating the information provision system (which may include ESLs and / or paper shelf labels) is an entirely separate process from updating the transaction system(s), and conventional approaches do not allow for the effective elimination of value discrepancies (e.g., price differences) between these disparate systems. Such pricing discrepancies are subject to audits, which can result in retailers paying significant fines (in addition to being subject to negative publicity and / or user reviews or sentiment). Additionally, such information discrepancies can cause significant revenue loss as users may decide not to complete transactions when faced with unexpected price differences. [Brief explanation of the drawings]

[0002] [Figure 1]

[0002] An illustrative environment for enabling effective data synchronization between computing systems is illustrated, in accordance with some embodiments of the present disclosure. [Figure 2]

[0003] 1 illustrates an example shelf input / output device according to some embodiments of the present disclosure. [Figure 3]

[0004] FIG. 1 is a flow diagram illustrating an example method for synchronizing updates between a shelf input / output system and a trading system, according to some embodiments of the present disclosure. [Figure 4]

[0005] 1 is a flow diagram illustrating an example method for determining and evaluating delay criteria for synchronizing updates, according to some embodiments of the present disclosure. [Figure 5]

[0006] FIG. 1 is a flow diagram illustrating an example method for value updates, according to some embodiments of the present disclosure. [Figure 6]

[0007] 1 illustrates an exemplary computing device for synchronizing computing system updates, in accordance with some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0003]

[0008] SUMMARY Embodiments of the present disclosure provide techniques and systems for efficient and automated value synchronization between computing systems.

[0004]

[0009] In some embodiments, value updates (e.g., changes to prices of items in a retail environment) for transaction computing system(s) and shelf input / output (IO) system(s) may be managed through a single system (e.g., a transaction system), where the single system manages updates to itself and other systems (e.g., shelf IO systems). For example, when the price of a given item is updated in a transaction system (e.g., in a database used by the transaction system to complete transactions), the transaction system may determine whether the updated price is displayed or implemented on the shelf IO system. If determined not to be displayed or implemented, the transaction system may perform an update to the shelf IO system to reflect the correct price applied by the transaction system (e.g., at checkout, also referred to as the "register price").

[0005]

[0010] In some embodiments, the trading system may be used to synchronize the timing of value updates to the trading system with the shelf IO system. Often, an audit passes if a user benefits from a discrepancy in updates (e.g., no fines or other penalties are applied). For example, if the value reflected by the shelf IO system is higher than the value applied by the trading system (e.g., an item is actually cheaper than the user expected), the user benefits from the discrepancy. In some embodiments, the trading system may therefore ensure that any price changes that increase prices are first confirmed or implemented on the shelf IO system before updating the trading system. In some embodiments, because an incorrectly higher price in the shelf IO system may reduce user engagement (e.g., causing users to refrain from selecting an item due to an incorrect price), trading criteria may determine fixed or dynamic delay criteria to ensure that pricing is synchronized quickly without surprising users with a higher checkout price.

[0006]

[0011] In some embodiments, updates that reduce the price of an item by a relatively small amount (e.g., a fixed amount defined by the retailer, such as less than $1) may be implemented at any time (e.g., by setting the delay criterion to 0 or deciding not to delay trading system updates). In some embodiments, changes that reduce price above a defined threshold may be subject to update synchronization techniques, described in more detail below. That is, in some embodiments, when value update(s) are provided, the trading system may calculate or determine which updates should use delayed update operations (e.g., price increases, changes to unit pricing schemes, adding or removing promotions, and the like). In some embodiments, such changes are marked as delayed by the trading system, and the trading system may continue to operate off the prior value (e.g., while the shelf IO system is being updated). In some aspects, once the trading system receives confirmation that the shelf IO system successfully executed or implemented the update, the trading system may update its own value.

[0007]

[0012] In some embodiments, this confirmation may be received directly from the shelf IO system(s). For example, in some embodiments, the shelf IO devices may be capable of two-way communication (e.g., receiving updated information from the shelf IO management system and returning a confirmation or acknowledgement that the update has been implemented). In some such embodiments, the shelf IO management system may therefore wait until each shelf IO device associated with the update (e.g., each shelf IO device associated with the stock keeping unit (SKU) being updated) confirms that they are displaying the updated information. The shelf IO systems may then return a confirmation to the trading system.

[0008]

[0013] In some embodiments, updates to shelf IO devices may not have a one-to-one correlation, and / or one or more of the shelf IO devices may not be capable of bidirectional communication. For example, some shelf IO devices may receive updated information (e.g., via an infrared optical link) but may not be able to send a response back to the shelf IO system. In some embodiments, the system may use one or more cameras to verify the update(s) of the shelf IO device(s). That is, one or more images depicting the associated shelf IO device may be captured and analyzed to verify whether the displayed information has updated as expected. The trading system may then proceed with the update as the shelf IO device is updated. Illustrative environment for enabling effective data synchronization between computing systems

[0009]

[0014] FIG. 1 illustrates an example environment 100 for enabling effective data synchronization between computing systems, in accordance with some embodiments of the present disclosure.

[0010]

[0015] In the illustrated example, trading system 105 is communicatively coupled to value database 110 and shelf IO system 120. While illustrated as separate components for conceptual clarity, in some aspects, the operations of trading system 105, value database 110, and shelf IO system 120 may be combined or distributed across any number of systems. Trading system 105, value database 110, and shelf IO system 120 may be communicatively linked via any suitable technology, including one or more wired links, one or more wireless links, or a combination of wired and wireless links. For example, trading system 105, value database 110, and shelf IO system 120 may be connected via a local network within a physical enterprise (e.g., a retail store such as a grocery store).

[0011]

[0016] In the illustrated example, trading system 105 accesses updated value(s) 115 from value database 110. As used herein, “accessing” data may generally include receiving, retrieving, requesting, obtaining, generating, collecting, or otherwise gaining access to data. Value database 110 generally corresponds to one or more data repositories that store or maintain various information related to physical items (e.g., products) available in or present in a physical environment. For example, value database 110 may store current, future, and / or prior (past) values ​​for variables such as price, unit formula, any applicable promotions, inventory (e.g., number of items available), and the like. In some embodiments, value database 110 generally includes any information that affects the price a user(s) will pay for a physical item(s). In some embodiments, value database 110 maintains this information on a per-item basis, such as using a unique identifier per physical item type (e.g., per SKU).

[0012]

[0017] In some embodiments, trading system 105 updates value database 110. That is, updates to value(s) may be provided to value database 110 via trading system 105 (e.g., by a user using a terminal). In some aspects, one or more other systems may update value database 110 (e.g., one or more users may use one or more other terminals to update values). In the illustrated example, updated values ​​115 are provided to or accessed by trading system 105. In some embodiments, updated values ​​115 are provided using a push mechanism (e.g., where value database 110 sends updates or notifications that updates are available, either periodically and / or in response to the occurrence of various events). In some embodiments, updated values ​​115 are provided using a pull mechanism (e.g., where trading system 105 requests information related to any updated values ​​periodically and / or in response to the occurrence of various events, such as when a user requests the latest price information for a given item).

[0013]

[0018] In the illustrated example, trading system 105 includes shelf IO component 106, delay component 107, and update component 108. Although illustrated as separate components for conceptual clarity, in embodiments, the operations of the illustrated components (and others not illustrated) may be combined or distributed across any number of components and systems.

[0014]

[0019] In the illustrated example, shelf IO component 106 is generally used to update shelf IO system 120 whenever updated values ​​115 are received. That is, as illustrated, shelf IO component 106 may send updates 117 (e.g., updated value(s) 115 or any related information derived therefrom) to shelf IO system 120. For example, in some embodiments, if updated value 115 includes a new price per unit, shelf IO component 106 may send updated value 115 to shelf IO system 120 and instruct shelf IO system 120 to implement the updated value (e.g., to cause associated shelf IO devices 125 to display the updated price). As another example, if updated value 115 indicates a newly applicable promotion for an item (e.g., buy two for the price of one), shelf IO component 106 may instruct shelf IO system 120 to update corresponding shelf IO devices 125 to indicate the promotion.

[0015]

[0020] In the illustrated example, shelf IO system 120 receives updates 117 from shelf IO component 106 and updates associated shelf IO device(s) 125 accordingly. For example, shelf IO system 120 may maintain a mapping or database that identifies shelf IO device(s) 125 in a space (e.g., by their unique identifiers such as their media access control (MAC) addresses) and indicates the physical items (e.g., SKUs) to which each shelf IO device 125 corresponds (e.g., item(s) for which each shelf IO device 125 displays information such as pricing). When update 117 is received, shelf IO system 120 may determine which item(s) are affected by update 117 and then identify the associated shelf IO device(s) for the determined item(s). As illustrated, shelf IO system 120 can then update the associated shelf IO device(s) 125.

[0016]

[0021] In general, techniques used to update shelf IO devices 125 may vary depending on implementation. For example, in some embodiments, shelf IO system 120 may use a bidirectional communication link (e.g., a WiFi link) to shelf IO devices 125 to push updated information to associated shelf IO device(s) 125. In some embodiments, shelf IO system 120 may use a unidirectional link to update shelf IO devices 125, such as an infrared optical link (e.g., sending an infrared signal that is detected by an infrared receiver on shelf IO device(s) 125).

[0017]

[0022] In some embodiments, by using a push mechanism to update shelf IO devices 125, shelf IO system 120 can substantially extend the lifespan of shelf IO devices 125. For example, shelf IO devices 125 may be battery-powered devices that normally remain dormant or inactive until an update is received. Once an update is received, shelf IO devices 125 may update their displays and return to a dormant state. This can improve the battery life of the devices. In some embodiments, shelf IO devices 125 may also use non-volatile displays (e.g., electronic ink displays) that can maintain the displayed information without power consumption (or with very little power consumption). For example, a relatively small amount of power may be used to change the display, which then remains fixed until the next update.

[0018]

[0023] In some embodiments, one or more of shelf IO devices 125 may return or send a response to shelf IO system 120 to indicate that the update has been implemented on the display(s). In response, shelf IO system 120 may inform trading system 105 via confirmation 130 that the update has been completed. In some embodiments, if shelf IO device(s) 125 are not capable of providing this confirmation, one or more other techniques or approaches may be used. For example, in some embodiments, a user (e.g., an employee) may visually inspect each associated shelf IO device 125 and confirm that the update has been completed (e.g., via a tablet or smartphone communicatively connected to shelf IO system 120 and / or trading system 105).

[0019]

[0024] As another example, in some embodiments, one or more cameras or other imaging sensors in environment 100 may capture image(s) illustrating associated shelf IO device(s) 125. These image(s) may then be evaluated using one or more machine learning techniques, such as optical character recognition (OCR) and / or object recognition, to determine whether shelf IO device 125 has been updated. If determined to have been updated, confirmation 130 may be returned to trading system 105.

[0020]

[0025] As used herein, “performing” an update on a display and / or by shelf IO system 120 and / or shelf IO device 125 may generally correspond to updating a display to show or output an updated value. Similarly, “performing” an update on transaction system 105 may generally correspond to updating a value used to quantify a transaction, such as the price charged to a user for an item.

[0021]

[0026] In the illustrated example, before, during, or after update(s) 117 are sent to shelf IO system 120, delay component 107 may determine or select one or more delay criteria for updated values ​​115. The delay criteria generally indicate when transaction system 105 should update its own records to reflect updated value(s) 115. As discussed above, once the values ​​used by transaction system 105 are updated, the new value(s) are applied to the user transaction. For example, at checkout, the updated value(s) are used for the selected items, which may affect the price of the items and / or the overall cost of the transaction.

[0022]

[0027] In some embodiments, delay component 107 uses a set of rules or mappings to determine the delay criteria. For example, in some embodiments, delay component 107 may compare updated value(s) 115 with prior value(s) for item(s). If updated value(s) 115 are less than the prior value(s), delay component 107 may decide to implement the update immediately. That is, delay component 107 may determine that there is no reason to delay the update because user(s) will not be harmed by the change. For example, even if shelf IO system 120 and trading system 105 are out of sync, the user will receive a lower price at checkout than the user expected based on shelf IO device(s) 125. Because such a discrepancy is unlikely to cause negative sentiment or result in audit fees, delay component 107 may decide to proceed with the update immediately.

[0023]

[0028] In some embodiments, the delay component 107 may proceed with implementing the update immediately if the price reduction is below a threshold (e.g., less than $1). In some embodiments, reductions above a threshold may be delayed some amount. That is, the delay component 107 may determine a non-zero delay amount to implement the update slowly (e.g., gradually reducing the price, such as by 25 cents, periodically, such as every few minutes). As another example, the delay component 107 may decide to wait for user confirmation (e.g., from a manager) before implementing the update. As another example, the delay component 107 may decide to implement the update after a defined period of time has passed and / or after a specified time (e.g., after closing time).

[0024]

[0029] In some embodiments, if the updated value 115 is higher than the prior value, the delay component 107 may similarly determine to delay updating the trading system 105. For example, the delay component 107 may determine a defined or static period of time for delaying the update of the trading system 105. As an example, the delay time may be determined or specified (e.g., by a user, such as a manager) based on the average or expected time it takes to traverse the environment. For example, based on how much average time elapses between when a user enters the facility and when the user checks out and / or leaves. By delaying by this average amount (plus, in some embodiments, a buffer percentage or value), the delay component 107 can reduce the probability that any user will be harmed by the change. That is, there is a high probability that any user who saw the prior (lower) price on the shelf IO device 125 completed their transaction (e.g., checked out and / or left the store) before the new (higher) price was implemented by the trading system 105.

[0025]

[0030] In some embodiments, the delay component 107 may use a fixed delay duration for all items based on the crossing time. In some embodiments, the delay component 107 may use different delay durations based on the item configuration. For example, some item(s) may cause a longer delay than other items based on the item's positioning within the store, etc. (Here, an item closer to the entrance of the environment may be associated with a longer delay than an item closer to the register or POS, since less time is likely to elapse between seeing the pre-value on the shelf IO device and completing the transaction for an item closer to the exit area.)

[0026]

[0031] In some embodiments, in addition to or instead of a fixed delay duration, delay component 107 may use dynamic delay criteria. For example, in some embodiments, delay component 107 may determine to delay updating trading system 105 until any transactions associated with the prior value are completed. For example, delay component 107 may identify a set of transactions associated with the prior value (e.g., pending transactions that were initiated before updated value 115 was received from value database 110 and / or that were initiated before receiving confirmation 130 that the update was complete and have not yet completed or closed). That is, in some embodiments, the associated transactions correspond to pending transactions that were initiated before updated value 115 was received. In some embodiments, the associated transactions correspond to pending transactions that were initiated before receiving confirmation 130 that shelf IO device 125 was updated to reflect updated value 115.

[0027]

[0032] The delay component 107 may then delay implementation of the updated values ​​on the transaction system 105 until all transactions in the identified set of related transactions are completed (e.g., the user checks out, the user aborts or otherwise abandons the transaction, and the like).

[0028]

[0033] In general, delay component 107 may use a variety of criteria and techniques to identify a set of associated or related transactions and / or transaction initiation points. For example, in some embodiments, some or all of the transactions may be manually or automatically initiated by a user (e.g., upon entering a store or by interacting with a user device, such as a retail application on the user's smartphone). That is, in some embodiments, a user may manually initiate a transaction using their device, and / or one or more systems in environment 100 (e.g., transaction system 105) may automatically initiate a transaction upon entering the environment (e.g., based on recognizing the user as they enter). In some embodiments, delay component 107 may therefore identify pending or open transaction(s) that have a start timestamp before the time updated value 115 was received (or before confirmation 130 was received).

[0029]

[0034] As another example, delay component 107 may identify a set of associated or related transactions based on the user's movements or actions in the environment. For example, in some embodiments, delay component 107 may identify any user(s) who entered a defined area associated with the physical item (e.g., entered a store, entered an aisle where the item is available, entered a defined radius or distance from the item, were within line of sight of shelf IO device(s) 125, and the like) prior to the value update (e.g., prior to receiving updated value 115 and / or confirmation 130). Delay component 107 may then identify transactions associated with these users (e.g., transactions for which the user may have seen a prior value on shelf IO device(s) 125) as relevant or associated pending transactions for the update. For example, delay component 107 may use techniques such as facial recognition or device authentication (based on a personal device carried by the user) to identify the user and then identify the transaction(s) associated with the user.

[0030]

[0035] As yet another example, the delay component 107 may identify a set of associated or related transactions based on user actions, such as picking up or selecting an item(s). For example, in some embodiments, the delay component 107 may identify any user(s) who selected associated item(s) (e.g., by placing the item(s) in the user's cart, basket, or other container) prior to the value update (e.g., prior to receiving the updated value 115 and / or confirmation 130). The delay component 107 may then identify transactions associated with these users (e.g., transactions in which the user may have selected the item(s) based on the prior value) as related or associated pending transactions for the update. For example, the delay component 107 may use techniques such as facial recognition or device authentication (based on a personal device carried by the user) to identify the user and then identify the transaction(s) associated with the user.

[0031]

[0036] In general, a wide variety of delay criteria may be used depending on the implementation.

[0032]

[0037] In the illustrated example, the updating component 108 may be used to implement the updated value 115 on the trading system 105 according to the delay criteria (determined by the delay component 107) and / or confirmation 130. For example, the updating component 108 may determine whether the delay criteria have been met (e.g., a determined time duration has passed and / or other criteria or events have occurred, such as the last trade associated with the prior value being closed). In some embodiments, the updating component 108 determines whether confirmation 130 has been received (e.g., refrains from updating the trading system 105 until confirmation 130 is received).

[0033]

[0038] In some embodiments, the updating component 108 or another system evaluates the confirmation 130 to ensure that the confirmation 130 is sufficient. For example, the updating component 108 (or shelf IO system 120) determines the number of shelf IO devices 125 associated with the relevant item (e.g., based on a mapping maintained by the shelf IO system 120). The updating component 108 (or another system) may then determine whether the updated number of shelf IO devices 125 matches the number of shelf IO devices 125 associated with the item. For example, if there are N shelf IO devices 125 associated with the item and an image in the environment 100 is used to verify the update, the updating component 108 may verify that the N devices illustrate the updated values ​​based on the image.

[0034]

[0039] In the illustrated example, once the delay criteria are met and / or confirmation 130 is received and / or validated, updating component 108 may implement the update on trading system 105. That is, updating component 108 may, for example, cause trading system 105 to begin using updated value 115 whenever an item is entered in a transaction (e.g., scanned at a register, entered via a user device, and the like).

[0035]

[0040] In these ways, the trading system 105 can ensure that values ​​remain synchronized across computing systems to reduce or prevent harm to users (e.g., due to surprising increases in prices at registers) while implementing uniform values ​​across the system as quickly as practicable (in accordance with decision rules and criteria).

[0036]

[0041] While the illustrated example depicts shelf IO device 125 configured to update the display, in some embodiments, transaction system 105 may interact with physical shelf labels or tags (e.g., paper tags, whiteboards or chalkboards, and the like) as well. For example, when updated values ​​115 are received, transaction system 105 may monitor the space (e.g., based on input from employees when they post the updated values ​​and / or based on images captured by a camera and evaluated using OCR, as discussed above) to confirm when the shelf labels have been updated (e.g., to generate confirmation 130). This can enable transaction system 105 to maintain efficient and synchronized updates even in environments 100 where some or all of the labels are non-electronic. Illustrative shelf input / output devices

[0037]

[0042] 2 illustrates an example shelf IO device 200 according to some embodiments of the present disclosure. For example, shelf IO device 200 may correspond to one of shelf IO device(s) 125 of FIG.

[0038]

[0043] Shelf IO device 200 includes display 205, Wi-Fi interface 210, NFC interface 215, and button 220. Display 205 may be an electronic ink display, which conserves power compared to other types of display screens. If shelf IO device 200 operates under battery power, display 205 may be an electronic ink display. However, in other embodiments, display 205 may be another type of display, such as an LED or LCD, and may be coupled to a power source rather than battery-powered. In other embodiments, display 205 may be a touch screen, such that a user can interact with the touch screen, such as selecting a virtual button that indicates the customer is seeking help or advice from an expert.

[0039]

[0044] The Wi-Fi interface 210 may include a transmitter / receiver (transceiver) for transmitting and receiving Wi-Fi data. For example, the Wi-Fi interface 210 may connect to a store's Wi-Fi network. The Wi-Fi interface 210 may be used by the store (e.g., by the transaction system 105 and / or the shelf IO system 120, respectively, of FIG. 1) to remotely change what is displayed on the display 205. For example, the price of a product may be updated if the corresponding product is on sale.

[0040]

[0045] NFC interface 215 allows shelf IO device 200 to use NFC to communicate with store employee devices and customer user devices. As discussed above, store employee can use NFC interface 215 to update display 205, or customer user device can use NFC interface 215 to receive product ID to contact a specialist.

[0041]

[0046] Button 220 may be a physically actuated button or a capacitive button. In some embodiments, shelf IO device 200 may include printed text instructing a customer to press button 220 if the customer needs help (e.g., to contact a specialist). This text may be printed on shelf IO device 200 or output on display 205.

[0042]

[0047] 2 is merely an example of shelf IO device 200 and its features. For example, implementations of other shelf IO devices (e.g., ESL) may not include all of the features shown. One shelf IO device may include Wi-Fi interface 210 but not NFC interface 215 or button 220. Another shelf IO device may include NFC interface 215 but not Wi-Fi interface 210 or button 220. Yet another shelf IO device may include Wi-Fi interface 210 and button 220 but not NFC interface 215. Additionally, some shelf IO devices may include one-way communication components (e.g., infrared receivers).

[0043]

[0048] As discussed above, shelf IO device 200 may generally receive updated values ​​from one or more other systems (such as shelf IO system 120 of FIG. 1). In some embodiments, shelf IO device 200 may send a confirmation that the update(s) have been implemented (e.g., the updated information is displayed on display 205).

[0044]

[0049] In the illustrated example, camera 230 is configured to or positioned to capture images illustrating all or a portion of shelf IO device 200 (e.g., at least display 205), as illustrated by line of sight 235. While a single camera 230 is illustrated for conceptual clarity, in some aspects multiple cameras 230 may be positioned to capture images illustrating shelf IO device 200. Furthermore, while one shelf IO device 200 is illustrated for conceptual clarity, in some embodiments a single camera 230 may be positioned to capture images illustrating multiple shelf IO devices 200.

[0045]

[0050] In some embodiments, as discussed above, the image(s) captured by camera(s) 230 may be evaluated (by camera 230 itself or by another system, such as shelf IO system 120 and / or transaction system 105, respectively, of FIG. 1 ) to determine whether display 205 has been updated. In some embodiments, verifying that display 205 has been updated includes processing all or a portion of the image using one or more OCR techniques to determine whether the information being displayed matches the updated value(s) for the item. For example, the image may be analyzed to determine whether the price is correct, whether a promotion is being accurately displayed, and the like.

[0046]

[0051] In some embodiments, in addition to or instead of verifying the accuracy of the information displayed on display 205, the image(s) may be evaluated to see if display 205 has generally been updated (regardless of accuracy). For example, many displays (such as electronic ink displays) exhibit a short "flash" or other visual effect when the display is updated (e.g., changing to completely black and / or completely white before displaying the updated information). In some embodiments, a sequence of images may be evaluated to detect whether such a flash (or other effect) has occurred on display 205.

[0047]

[0052] For example, the timestamp of when an update was sent to shelf IO system and / or shelf IO device 200 may be recorded, and the sequence of images closest to this timestamp (e.g., beginning at that timestamp and continuing for a defined duration, such as 5 seconds) may be accessed and evaluated. If a flashing (or other visual effect) of an update is detected during a window, it may be reasonably inferred that shelf IO device 200 has updated display 205 to illustrate new information. This may allow trading system 105 and / or shelf IO system 120 to verify or confirm an update without actually verifying the content or accuracy of the update. This may substantially reduce computational costs, as the visual effect of an update can generally be effectively detected with a simple model (e.g., without relying on machine learning or computer vision techniques).

[0048]

[0053] As discussed above, the images provided by the camera 230 may be used to confirm updates to the shelf IO device(s) 200 (either alone or in conjunction with explicit feedback from the shelf IO device(s) 200) to determine when to implement updates on the trading system. Illustrative Method for Synchronizing Updates Between Shelf Input / Output Systems and Trading Systems

[0049]

[0054] 3 is a flow diagram illustrating an example method 300 for synchronizing updates between a shelf input / output system and a trading system, according to some embodiments of the present disclosure. In some embodiments, method 300 is performed by a trading system, such as trading system 105 of FIG. 1.

[0050]

[0055] In block 305, the transaction system accesses updated values ​​(e.g., updated values ​​115 of FIG. 1 ) for physical items in the physical environment (e.g., retail facility). As discussed above, in some embodiments, the updated values ​​may generally include any updated or modified data that may affect whether a user selects an item, such as price, any applicable promotions, unit formulas, and the like. In some aspects, as discussed above, the updated values ​​are accessed from a user (e.g., an employee or manager), a value database (e.g., value database 110 of FIG. 1 ), and the like.

[0051]

[0056] In block 310, the trading system sends the updated values ​​(or information derived therefrom, such as the new unit system) to a shelf IO system (e.g., shelf IO system 120 of FIG. 1 ). For example, as discussed above, rather than immediately implementing the updated values, the trading system may send the updates to the shelf IO system (or other system responsible for updating in-store displays). In some embodiments, in addition to or instead of sending updates to electronic or automated display systems, the trading system may send updates to one or more users, as discussed above. For example, the trading system may instruct employee(s) to manually update one or more displays, such as to place new paper or sticker labels, rewrite or draw on a chalkboard or whiteboard, and the like.

[0052]

[0057] At block 315, the trading system determines one or more associated delay criteria based on the updated values. In some embodiments, as discussed above, determining the delay criteria includes determining a duration for delaying the trading system updates. In some embodiments, as discussed above, determining the delay criteria includes determining one or more events that should occur before updating the trading system. One illustrative method for determining the delay criteria is discussed in more detail below with reference to FIG. 4.

[0053]

[0058] For example, in some embodiments, the trading system determines that the delay criterion includes a delay duration of zero (e.g., no delay) in response to determining that the updated value is less than the prior value (e.g., the price is decreasing). In some embodiments, as discussed above, the trading system may determine that the delay criterion is a delay of zero duration if the decrease is less than a threshold, and that the delay criterion is greater than zero if the decrease is above a threshold, as discussed above.

[0054]

[0059] In some embodiments, the transaction system determines that the delay criteria include delaying transaction system updates until pending transactions associated with the prior value are completed (e.g., by checkout, abort, and the like). For example, as discussed above, the transaction system may identify a set of associated transactions that began before the update (or before the shelf IO update is confirmed), transactions in which a user entered a store, aisle, or other physical area for an item before the update (or before the shelf IO update is confirmed), transactions in which a user picked up or selected an item before the update (or before the update is confirmed), and the like. In some embodiments, the transaction system determines that the delay criteria include confirming that the shelf IO system has been fully updated (e.g., based on explicit signaling, based on detecting the update using a camera, as discussed above).

[0055]

[0060] At block 320, the trading system updates the trading system based on the delay criteria. For example, as discussed above, the trading system may wait until a determined duration expires, until a determined event occurs (e.g., the last pending trade associated with the prior value ends), until the update is confirmed on the shelf IO device, and the like.

[0056]

[0061] Once the criteria are met, the transaction system updates itself as discussed above, i.e., the transaction system implements or enables the updated values ​​so that they are used for any ongoing or future transactions (e.g., transactions that have not yet added an item), i.e., when a new transaction adds an item (e.g., an item is scanned at a POS), the updated values ​​can be applied. Illustrative Method for Determining and Evaluating Delay Criteria for Synchronizing Updates

[0057]

[0062] 4 is a flow diagram illustrating an example method 400 for determining and evaluating delay criteria for synchronizing updates, according to some embodiments of the present disclosure. In some embodiments, method 300 is performed by a trading system, such as trading system 105 of FIG. 1. In some embodiments, method 400 provides additional details about blocks 315 and / or 320 of FIG. 3.

[0058]

[0063] In block 405, the trading system determines the prior value for the item being updated, as discussed above. That is, if the updated value is to be referred to as the new "current" value, the trading system determines what the previous value was. In some embodiments, the new value may alternatively be referred to as the new value or the updated value, and the value prior to this update may be referred to as the current value.

[0059]

[0064] In block 410, the trading system determines whether the prior value is higher than the updated value. In other words, the trading system determines whether a change would be in the user(s)'s interest, such as whether the prior unit price is higher than the updated unit price. In some embodiments, this determination may be based on the price itself and promotions or other information (e.g., where adding a promotion is generally in the user's interest, while ending a promotion is generally not in the user's interest).

[0060]

[0065] If the change is in the user's interest (e.g., the new updated price is lower than the prior price or the current price), method 400 continues to block 415. At block 415, the trading system updates the trading system without delay. That is, because the change is in the user's interest, the trading system may proceed with updating the trading system immediately, even if the shelf IO system is not updated or the update is delayed, because the difference in the register is in the user's interest.

[0061]

[0066] Returning to block 410, if the trading system determines that the change is not in the user's interest (e.g., the new price is higher), method 400 continues to block 420. In block 420, the trading system determines whether the associated shelf IO device(s) for the item have been updated. For example, as discussed above, the trading system may determine whether confirmation has been received (e.g., from the shelf IO system) indicating that all associated shelf IO devices have been updated. In some embodiments, as discussed above, the trading system may additionally or alternatively evaluate image data to verify the update. For example, as discussed above, the trading system may use OCR or other techniques to verify that the displayed information is correct and / or may use various techniques to detect the update without actually verifying the content of the update (e.g., detecting a block of pixels that briefly turns black before returning to display).

[0062]

[0067] In some embodiments, as discussed above, the trading system may evaluate the image data (or other indication) to verify that the number of shelf IO devices associated with the item as shown in the image (e.g., the count of shelf IO devices illustrating information about the item in space) matches the count of updated shelf IO devices. If the trading system determines that one or more shelf IO device(s) have not been updated, method 400 repeats at block 420.

[0063]

[0068] If the trading system determines at block 420 that the shelf IO device(s) have been updated, method 400 continues at block 425. At block 425, the trading system determines whether a delay criterion has been met. For example, as discussed above, the trading system may determine whether a determined delay duration has elapsed (e.g., since the update was received or since the update to the shelf IO device was confirmed at block 420).

[0064]

[0069] As another example, as discussed above, the trading system may determine whether a set of associated or related transactions have been completed (e.g., whether any related transactions are still open). As discussed above, the set of related transactions associated with the prior value may be determined according to a variety of criteria, including identifying transactions that began before the update (e.g., before the shelf IO system confirmed that the update occurred in block 425), transactions in which the user entered a defined physical area, such as the store, the aisle in which the item is located, a defined distance to the item, and the like, before the update (and / or before the shelf IO system confirmed that the update occurred in block 425), transactions in which the user selected the item before the update (or before the update was confirmed on the shelf IO device), and the like. If any such transactions remain pending, the trading system may determine that the criteria have not been met.

[0065]

[0070] If, at block 425, the transaction system determines that the delay criteria have not been met, method 400 repeats block 425. If, at block 425, the transaction system determines that the delay criteria have been met, method 400 continues to block 430. At block 430, the transaction system updates the transaction system. That is, the transaction system implements the updates on the transaction system (e.g., at the point of sale, such as a register, self-checkout, and the like). In this manner, future selections or purchases of the item may be priced according to the updated value. Example methods for updating values

[0066]

[0071] 5 is a flow diagram illustrating an example method 500 for value updates according to some embodiments of the present disclosure. In some embodiments, method 500 is performed by a trading system, such as trading system 105 of FIG. 1.

[0067]

[0072] In block 505, updated values ​​for physical items for sale in the space (eg, updated values ​​115 of FIG. 1) are identified.

[0068]

[0073] In block 510, the updated values ​​are sent to the shelf IO system (eg, shelf IO system 120 of FIG. 1).

[0069]

[0074] At block 515, one or more delay criteria are determined based on comparing the updated value and the prior value for the physical item.

[0070]

[0075] At block 520, confirmation (e.g., confirmation 130 of FIG. 1) is received that the updated values ​​have been implemented by the shelf IO system.

[0071]

[0076] At block 525, a trading system (eg, trading system 105 of FIG. 1) is updated based on the updated value, according to one or more delay criteria and validations. Exemplary Computing Device for Synchronizing Computing System Updates

[0072]

[0077] FIG. 6 illustrates an example computing device 600 for synchronizing computing system updates, according to some embodiments of the present disclosure.

[0073]

[0078] While illustrated as a physical device, in some embodiments, computing device 600 may be implemented using virtual device(s) and / or across several devices (e.g., in a cloud environment). In some embodiments, computing device 600 corresponds to or comprises a trading system, such as trading system 105 of FIG. 1.

[0074]

[0079] As illustrated, computing device 600 includes a CPU 605, memory 610, storage 615, one or more network interfaces 625, and one or more I / O interfaces 620. In the illustrated embodiment, CPU 605 retrieves and executes programming instructions stored in memory 610, as well as stores and retrieves application data residing in storage 615. CPU 605 generally represents a single CPU and / or GPU, multiple CPUs and / or GPUs, a single CPU and / or GPU with multiple processing cores, and the like. Memory 610 is generally considered to represent random access memory. Storage 615 may be any combination of disk drives, flash-based storage devices, and the like, and may include fixed and / or removable storage devices such as fixed disk drives, removable memory cards, cache, optical storage, network attached storage (NAS), or storage area networks (SAN).

[0075]

[0080] In some embodiments, I / O devices 635 (such as a keyboard, monitor, etc.) are connected via I / O interface(s) 620. Additionally, via network interface 625, computing device 600 may be communicatively coupled to one or more other devices and components (e.g., via a network, which may include the Internet, local network(s), and the like). As illustrated, CPU 605, memory 610, storage 615, network interface(s) 625, and / or I / O interface(s) 620 are communicatively coupled by one or more buses 630. In the illustrated embodiment, memory 610 includes a shelf IO component 650, a delay component 655, and an update component 660.

[0076]

[0081] Although illustrated as separate components for conceptual clarity, in some embodiments, the operations of the illustrated components (and others not illustrated) may be combined or distributed across any number of components. Further, while illustrated as software residing in memory 610, in some embodiments, the operations of the illustrated components (and others not illustrated) may be implemented using hardware, software, or a combination of hardware and software.

[0077]

[0082] In the illustrated embodiment, shelf IO component 650 (which may correspond to shelf IO component 106 of FIG. 1 ) may be used to facilitate updates to shelf IO devices (e.g., shelf IO device 125 of FIG. 1 and / or shelf IO device 200 of FIG. 2 ), as discussed above. For example, shelf IO component 650 may send updated value(s) to a controller of the shelf IO device (e.g., shelf IO system 125 of FIG. 1 ) and may request that the shelf IO system implement the updates on the associated shelf IO devices.

[0078]

[0083] In the illustrated example, delay component 655 (which may correspond to delay component 107 of FIG. 1 ) may be used to determine a delay criteria for updating values ​​used by computing device 600, as discussed above. For example, delay component 655 may compare a new value to a previous value or a current value to determine whether to delay the update. Similarly, delay component 655 may determine the delay duration based on a fixed value, based on the location of items in the space, based on how busy the environment is (e.g., more users in the space may result in a longer delay duration), and the like. In some embodiments, delay component 655 may determine to delay the update until an identified set of transactions is completed, as discussed above.

[0079]

[0084] In the illustrated embodiment, an update component 660 (which may correspond to update component 108 in FIG. 1 ) may be used to update the value(s) used by computing device 600, as discussed above. For example, update component 660 may determine whether delay criteria have been met (e.g., whether all associated shelf IO devices have been updated, whether a duration has expired, whether associated transactions have completed, and the like). If so, the update may update the value to reflect the new information (e.g., updating item value 670 used by the trading system).

[0080]

[0085] In the illustrated example, storage 615 may include item values ​​670. In some embodiments, as discussed above, item values ​​670 may correspond to the value(s) currently being used by the transaction system (e.g., the price charged to the user upon checkout). While illustrated as residing in storage 615, in some embodiments, item values ​​670 may be stored in a variety of other locations, including in memory 610.

[0081]

[0086] The description of various embodiments of the present disclosure has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, practical applications, or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0082]

[0087] Reference will be made below to embodiments presented in the present disclosure. However, the scope of the present disclosure is not limited to the described embodiments. Instead, any combination of the following features and elements, whether associated with different embodiments, is contemplated to implement and practice the contemplated embodiments. Furthermore, while the embodiments disclosed herein may achieve advantages over other possible solutions or prior art, whether or not an advantage is achieved by a given embodiment does not limit the scope of the present disclosure. For this reason, the following aspects, features, embodiments, and advantages are merely exemplary and should not be considered elements or limitations of the appended claims unless expressly recited in the claim(s). Similarly, reference to embodiments of the present disclosure should not be construed as a generalization of all subject matter disclosed herein, nor should they be considered elements or limitations of the appended claims unless expressly recited in the claim(s).

[0083]

[0088] Aspects of the present disclosure may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects, all of which may be generally referred to herein as "circuits," "modules," or "systems."

[0084]

[0089] The present disclosure may be a system, a method, and / or a computer program product, which may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to implement aspects of the present embodiments.

[0085]

[0090] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanical coding devices such as punch cards or ridge structures in grooves having instructions recorded thereon, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as being a transitory signal, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through a fiber optic cable), or an electrical signal transmitted through a wire.

[0086]

[0091] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may comprise copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them for storage in a computer-readable storage medium within the respective computing / processing device.

[0087]

[0092] The computer-readable program instructions for carrying out the operations of the present embodiments may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, and traditional procedural programming languages ​​such as the "C" programming language or similar. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, an electronic circuit, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuit to perform aspects of the present embodiments.

[0088]

[0093] Aspects of the present embodiments are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0089]

[0094] These computer-readable program instructions may be provided to a general-purpose computer, a special-purpose computer processor, or other programmable data processing apparatus to produce a machine, such that the instructions executing on the computer processor or other programmable data processing apparatus create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a certain manner, such that a computer-readable storage medium having instructions stored therein comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0090]

[0095] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device such that a series of operational steps are executed on the computer, other programmable apparatus, or other device to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0091]

[0096] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of an instruction, comprising one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may not occur in the order noted in the figures. For example, depending on the functionality involved, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or that implements a combination of special-purpose hardware and computer instructions.

[0092]

[0097] In embodiments of the present disclosure, computing resources may be provided to end users through a cloud computing infrastructure. Cloud computing generally refers to the provision of scalable computing resources as a service over a network. More formally, cloud computing may be defined as computing power that provides abstraction between computing resources and their underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be quickly provisioned and released with minimal management effort or interaction with a service provider. From this, cloud computing enables users to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in the "cloud," regardless of the underlying physical systems used to provide the computing resources (or the location of those systems).

[0093]

[0098] Typically, cloud computing resources are provided to users on a pay-per-use basis, where users are charged for the computing resources actually used (e.g., the amount of storage space consumed by the user or the number of virtualization systems instantiated by the user). Users can access any of the resources present in the cloud at any time from anywhere on the Internet. In the context of the present disclosure, users may access applications (e.g., aspects of a trading system) or related data available in the cloud. For example, a trading system may run on a computing system in the cloud and determine and implement a delay criterion to synchronize value updates. In such a case, the trading system may determine the delay criterion and store the criterion and / or updated values ​​in a storage location in the cloud. Doing so allows users to access this information from any computing system attached to a network connected to the cloud (e.g., the Internet).

[0094]

[0099] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the present disclosure may be devised without departing from the basic scope thereof, which scope is determined by the following claims.

Claims

1. Identifying updated values ​​of items for sale within a given space; transmitting the updated value to a shelf input / output system; determining one or more delay criteria based on comparing the updated value with past values ​​for the item; receiving a confirmation that the updated value has been implemented by the shelf input / output system; updating a trading system based on the updated values ​​in accordance with the one or more delay criteria and the validation; method.

2. 2. The method of claim 1, wherein determining the one or more delay criteria comprises determining not to delay updates of the trading system based on determining that the updated value is lower than the past value.

3. 2. The method of claim 1, wherein determining the one or more delay criteria comprises determining to delay updates of the trading system for at least a period of time based on determining that the updated value is higher than the past value.

4. 4. The method of claim 3, wherein determining the one or more delay criteria further comprises determining to delay the updates of the trading system for a defined period of time.

5. Determining the one or more delay criteria includes: identifying a set of transactions associated with the historical values; determining to delay the update of the trading system until a last trade in the set of trades is completed; The method of claim 3 further comprising:

6. 6. The method of claim 5, wherein identifying the set of transactions associated with the past value comprises identifying transactions initiated prior to receiving the confirmation via one or more user devices.

7. 6. The method of claim 5, wherein identifying the set of transactions associated with the past value comprises identifying a set of users who entered a defined area associated with the item prior to receiving the confirmation.

8. The method of claim 5 , wherein identifying the set of transactions associated with the past value comprises identifying a set of users who selected the item prior to receiving the confirmation.

9. The method of claim 1 , wherein receiving the confirmation comprises receiving a transmission from the shelf input / output system.

10. 10. The method of claim 1, wherein receiving the confirmation comprises evaluating one or more images illustrating the one or more shelf input / output devices associated with the item to confirm that the one or more shelf input / output devices have been updated.

11. receiving the confirmation determining a first count of shelf input / output devices associated with the item within the predetermined space; determining a second count of the one or more shelf input / output devices identified as displaying the updated value; and verifying that the first count matches the second count; The method of claim 10 further comprising:

12. one or more memories that collectively store computer-executable instructions; one or more processors configured to collectively execute the computer-executable instructions to cause operations to be performed; wherein the processor: Identifying updated values ​​of items for sale within a given space; transmitting the updated value to a shelf input / output system; determining one or more delay criteria based on comparing the updated value with past values ​​for the item; receiving a confirmation that the updated value has been implemented by the shelf input / output system; updating a trading system based on the updated values ​​in accordance with the one or more delay criteria and the validation; system.

13. 13. The system of claim 12, wherein determining the one or more delay criteria comprises determining not to delay updates of the trading system based on determining that the updated value is lower than the past value.

14. 13. The system of claim 12, wherein determining the one or more delay criteria further comprises determining to delay the updates of the trading system for a defined period of time.

15. Determining the one or more delay criteria includes: identifying a set of transactions associated with the historical values; determining to delay the update of the trading system until a last trade in the set of trades is completed; The system of claim 12 further comprising:

16. 13. The system of claim 12, wherein receiving the confirmation comprises evaluating one or more images illustrating the one or more shelf input / output devices associated with the item to confirm that the one or more shelf input / output devices have been updated.

17. 1. A computer program product comprising one or more computer-readable storage media having computer-readable program code collectively embodied thereon, said computer-readable program code collectively executable by one or more computer processors to perform operations, said operations comprising: Identifying updated values ​​of items for sale within a given space; transmitting the updated value to a shelf input / output system; determining one or more delay criteria based on comparing the updated value with past values ​​for the item; receiving a confirmation that the updated value has been implemented by the shelf input / output system; updating a trading system based on the updated values ​​in accordance with the one or more delay criteria and the validation; Computer program products.

18. 20. The computer program product of claim 17, wherein determining the one or more delay criteria comprises determining not to delay updates of the trading system based on determining that the updated value is lower than the past value.

19. 20. The computer program product of claim 17, wherein determining the one or more delay criteria further comprises determining to delay the updates of the trading system for a defined period of time.

20. Determining the one or more delay criteria includes: identifying a set of transactions associated with the historical values; determining to delay the update of the trading system until a last trade in the set of trades is completed; 20. The computer program product of claim 17, further comprising:

Images