Integrated management system for stock loss of perishable item

A system using machine learning and edge cameras for dynamic pricing adjusts inventory levels and reduces perishable goods loss by optimizing stock turnover and customer demand.

JP2025186153APending Publication Date: 2025-12-23TOSHIBA TEC KK
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2025041767
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-05-21
Filing Date
2025-03-14
Publication Date
2025-12-23

AI Technical Summary

Technical Problem

Perishable goods such as dairy products, fruits, and baked goods experience significant inventory loss due to rapid deterioration and unpredictable consumer behavior, leading to financial losses and environmental impact without effective data-driven pricing strategies.

Method used

A system utilizing machine learning models and real-time data from edge cameras to dynamically adjust prices based on stock levels, expiration dates, and expected deliveries, minimizing inventory loss through dynamic pricing adjustments.

Benefits of technology

Improves retail efficiency and sustainability by optimizing inventory levels and reducing perishable inventory loss through data-driven pricing decisions.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025186153000001_ABST
    Figure 2025186153000001_ABST
Patent Text Reader

Abstract

To provide a method, system and computer-readable medium for dynamic price-determination adjustment and stock optimization.SOLUTION: A method includes: receiving stock level data including an estimated stock level of a product batch in a physical place through a camera 705, acquiring product information including expiration date and first price concerning the product batch from a database 710, determining a second price of the product batch based on the expiration date and the estimated stock level using a machine learning (ML) model 715, and updating the database with the second price of the product batch 720.SELECTED DRAWING: Figure 7
Need to check novelty before this filing date? Find Prior Art

Description

[Background technology]

[0001]

[0001] Products such as dairy products, fruits, vegetables, and baked goods are highly susceptible to perishable shrinkage in retail environments, primarily due to their rapid deterioration rates and short shelf lives. Increased perishable shrinkage for these products typically occurs due to an imbalance between supply and demand. For example, when stock levels are higher than customer demand, excess inventory can result that cannot be consumed in time. Furthermore, perishable shrinkage can be exacerbated by unpredictable fluctuations in consumer purchasing behavior, which is influenced by various factors, such as seasonal trends, weather conditions, and economic changes. Such perishable shrinkage not only results in financial losses for stores, but also has detrimental effects on the environment. [Brief explanation of the drawings]

[0002] [Figure 1] FIG. 1 is a diagram illustrating an example environment for perishable product inventory loss control and management, according to some embodiments of the present disclosure. [Figure 2]

[0003] FIG. 2 is a diagram illustrating an exemplary perishable inventory loss control system according to some embodiments of the present disclosure. [Figure 3]

[0004] FIG. 3 is a diagram illustrating an exemplary electronic shelf label (ESL) according to some embodiments of the present disclosure. [Figure 4]

[0005] FIG. 4 is a diagram illustrating an example method for controlling inventory loss of perishable goods through dynamic pricing and inventory management, according to some embodiments of the present disclosure. [Figure 5]

[0006] FIG. 5 is a diagram illustrating an example method for an ESL device to update and display prices according to some embodiments of the present disclosure. [Figure 6]

[0007] FIG. 6 is a diagram illustrating an example method for a point-of-sale (PoS) device to obtain updated prices upon product scanning, according to some embodiments of the present disclosure. [Figure 7]

[0008] FIG. 7 is a flow diagram illustrating an example method for dynamic pricing and inventory monitoring according to some embodiments of the present disclosure. [Figure 8]

[0009] FIG. 8 is a diagram illustrating an exemplary computing device configured to perform various aspects of the present disclosure, according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0003]

[0010] DETAILED DESCRIPTION OF THE INVENTION Embodiments herein describe a system for waste management and control based on dynamic pricing adjustments and real-time inventory monitoring.

[0004]

[0011] Products such as dairy products, fruits, vegetables, and baked goods typically have relatively short shelf lives, making them highly susceptible to perishable inventory loss in retail environments. To reduce perishable inventory loss, a common strategy involves lowering prices to motivate customers to purchase more. However, traditionally, retailers may apply price reductions at their discretion without a data-driven understanding of how much to lower prices or what discounts to apply to effectively minimize perishable inventory loss and optimize inventory levels. Optimizing inventory levels through strategic price reductions can significantly increase revenue and improve profit margins. However, the absence of a data-driven pricing approach can gradually undermine these potential profits, leading to inadequate pricing strategies that neither significantly reduce valuation inflates nor increase profitability.

[0005]

[0012] The present disclosure addresses these challenges by introducing a fresh produce inventory loss management and control system that dynamically adjusts prices using machine learning (ML) models and real-time data from edge cameras. As used herein, fresh produce inventory loss (also referred to in some embodiments as retail shrink) refers to the loss of inventory of fresh products (e.g., milk, baked goods, vegetables) at a retail store due to damage or expiration. In some embodiments, fresh produce inventory loss (or retail shrink) may be determined by calculating the difference between the amount of inventory purchased and the amount of inventory actually sold. In some embodiments, the price of fresh products may be adjusted based on estimated stock levels of product batches, expiration dates, calculated product margins, and expected upcoming deliveries (or stock levels) arriving at the store. The system enables a data-driven decision-making process regarding price adjustments that not only minimizes (or at least reduces) fresh produce inventory loss by promoting timely purchases of fresh goods, but also maintains improved inventory levels. Through dynamic price adjustments, the system can improve overall retail efficiency and sustainability.

[0006]

[0013] FIG. 1 illustrates an example environment 100 for perishable goods inventory loss control and management, according to some embodiments of the present disclosure.

[0007]

[0014] The environment 100 may correspond to a business location, such as a retail facility (e.g., a supermarket, grocery store, bakery), etc. The illustrated environment 100 includes three shelves 105. The different shelf levels are used to display either distinct products or the same product from different batches. For example, as illustrated, the top shelf displays items belonging to batch 110-1 of product A (e.g., milk). The middle shelf displays items belonging to batch 110-2 of product A. The bottom shelf displays items belonging to batch 115-1 of product B (e.g., sandwiches). As used herein, items within the same batch may share the same characteristics, such as weight, production date, or expiration date, indicating that the items are from the same production cycle. For example, items within batch 110-1 of product A (e.g., milk) may share a best-by date or may have best-by dates that fall within a predetermined range (e.g., plus or minus three days). The items in batch 110-2 of product A differ from the items in batch 110-1 of product A in one or more of these characteristics, such as having a later expiration date that exceeds a predetermined range, indicating that the items in batch 110-2 are from a different manufacturing cycle.

[0008]

[0015] As illustrated, shelf input / output (IO) devices 120 are used to indicate different product types and batches. For example, shelf IO device 120-1 is mounted on the top shelf of shelf 105 and indicates information related to batch 110-1 of product A. Shelf IO device 120-2 is mounted on the middle shelf of shelf 105 and indicates information related to batch 110-2 of product A. Shelf IO device 120-3 is mounted on the bottom shelf of shelf 105 and indicates information related to batch 115-1 of product B.

[0009]

[0016] In some embodiments, shelf IO device 120 may provide various information associated with each product batch, including product name, description, pricing details (such as unit price or total price), product ID (e.g., stock keeping unit (SKU)), discount information, current stock count (including on the shelf and in the back of the store), and environmental certifications (e.g., organic, fair trade). Additionally, various types of barcodes, such as GS1 Logistic Label barcodes (1D barcodes) or GS1 Digital Link barcodes (QR Codes), may be displayed within shelf IO device 120 to facilitate easy product identification.

[0010]

[0017] In the illustrated environment 100, camera 125 is installed near shelf 105. Camera 125 may be either wall-mounted or ceiling-mounted and may be pointed directly toward shelf 105 to ensure a clear view of shelf 105 and its contents. In some embodiments, camera 125 may be configured to capture images of shelf 105 periodically or in real time. The captured images may then be transmitted as raw image data to a server for further processing and analysis. Transmission may occur over a wired or wireless network, as described in more detail with reference to FIG. 2. Upon receiving the raw image data, the server may use image processing and recognition algorithms to analyze the content of each image. These algorithms may be configured to identify the product type (e.g., product A) and batch (e.g., batch 110-1) of items on shelf 105 by recognizing unique features such as package designs, labels, or barcodes (printed on their packages or displayed on shelf IO device 120). Based on the identified product type and batch, the server may then determine the stock level by either counting the visible items or estimating the quantity of items present given the item's arrangement and the space it occupies on the shelf. For example, by analyzing an image of shelf 105, the server may identify the items on the top shelf as belonging to batch 110-1 of product A (e.g., milk) and determine that there are three items present in this category, indicating that the current stock level of batch 110-1 of product A is three. Similarly, the server may identify the items on the middle shelf as belonging to batch 110-2 of product A and indicate that the current stock level of this category is five. Furthermore, the server may identify the items on the bottom shelf as belonging to batch 115-1 of product B and indicate that the current stock level of this category is four.

[0011]

[0018] In some embodiments, after recognizing the product category (including product type and batch), the server may subsequently search a database to access more detailed product information (beyond what is directly identified in the image), such as expiration dates, manufacturer information, ingredient lists, and historical sales data, among others. Using that product information, along with estimated stock levels and / or estimated future stock levels from a supply chain ordering system, the server may determine price adjustments for different products (e.g., product A, product B) or different batches of the same product (e.g., batch 110-1, batch 110-2). In some embodiments, price adjustments may be determined by running a trained ML model. The training process may begin with the collection of a dataset including historical sales patterns, price changes, customer responses, expiration dates of one or more products and their corresponding stock levels, and other relevant variables. Historical data may be collected from store transaction records or inventory management systems. Once collected, the historical data may be cleaned and preprocessed to resolve inconsistencies and fill missing values, making it more suitable for training. From the preprocessed data, input features and target outputs may be identified and extracted. As used herein, input features may refer to variables that may affect sales and inventory turns, such as time to expiration and historical demand trends for similar products at similar times, etc. Target outputs may refer to price adjustments that incur minimal (or at least reduced) perishable inventory loss (setbacks), or a decision whether to lower prices (binary classification).

[0012]

[0019] Once the data is prepared, in some embodiments, a model can be trained using historical data to learn correlations between input features and target outputs. Depending on the complexity of the data and / or the specific requirements of the application, various algorithms can be used. These algorithms can include, but are not limited to, regression trees, support vector machines (SVMs), random forests, or neural networks. In some embodiments, model performance can be measured using validation techniques such as k-fold cross-validation. In some embodiments, the model can be iteratively refined by updating it with new data incorporating current market conditions and consumer behavior. Through training, the model adapts to predict price adjustments that minimize (or at least reduce) perishable inventory losses based on newly received data. The data-driven price adjustment process enables effective inventory management, such as lowering prices to accelerate sales, which in turn minimizes (or at least reduces) predictable perishable inventory losses. Furthermore, the dynamic nature of the data-driven price adjustment process allows for real-time reaction to changing market conditions, inventory availability, and product expiration dates. As new data about sales, fluctuations in customer demand, inventory levels, and upcoming expiration dates is incorporated, the model can adjust its forecasts to provide the most effective pricing strategy at any given time.

[0013]

[0020] In some embodiments, the camera 125 may have built-in processing capabilities (also referred to in some embodiments as an edge camera) that enable more efficient data handling and analysis. Rather than sending raw image data to a server, the camera 125 may directly analyze the image to identify the product and determine the associated stock level. After processing the image, the camera 125 may then send compiled information, such as product identifiers, batch details, and estimated stock levels, to the server. The use of edge cameras in the retail environment 100 may reduce the bandwidth required for data transfer and / or reduce the computational load on the central server. Such integration may facilitate faster reactions to changes in stock levels, as the server receives processed data ready for immediate use in inventory management and dynamic pricing adjustments.

[0014]

[0021] 2 illustrates an exemplary perishable goods inventory loss control system 200 according to some embodiments of the present disclosure. The figure illustrates the network architecture of the exemplary system 200 within a business location (e.g., a retail store). As illustrated, the perishable goods inventory loss control system 200 includes a gateway 225 that serves as a central hub for data transmission. The gateway 225 connects various components within the perishable goods inventory loss control system 200 for dynamic pricing and inventory management. These components include an electronic shelf label (ESL) 205, a camera 210, a checkout station 215, a central server 220, a point-of-sale (PoS) database 230, and an ESL database 235, all of which communicate with each other via the gateway 225.

[0015]

[0022] In some embodiments, ESL 205 may correspond to shelf IO device 120 illustrated in FIG. 1. ESL 205 may be attached to a shelf and utilized to dynamically display current pricing information for products. In some embodiments, ESL 205 may receive (or actively retrieve) pricing updates from ESL database 235 to ensure that displayed prices are current.

[0016]

[0023] In some embodiments, camera(s) 210 may correspond to camera 125 illustrated in FIG. 1. In some embodiments, camera 210 may be a standard surveillance camera that captures images of store shelves (e.g., 105 in FIG. 1) and transmits them to a central server 220 for analysis. In some embodiments, camera 210 may be an edge camera configured with built-in processing capabilities. The edge camera may process the images locally to identify products and their respective stock levels. The edge camera may then send the processed data to a server for dynamic price adjustments.

[0017]

[0024] In some embodiments, a checkout station 215 in a retail environment may be configured to calculate an accurate bill and / or assist customers in completing their purchases. For accurate billing, the checkout station 215 may scan labels or barcodes (either GS1 Logical Labels or GS1 Digital Link barcodes) printed on products in a shopping cart. Upon scanning, the checkout station 215 may send a request to the PoS database 230 via the gateway 225 to obtain the latest product information. In some embodiments, the information obtained may include product name, description, and current price, which may be dynamically adjusted based on stock levels or other factors. The checkout station 215 may then calculate a total price based on the updated price and quantity of items to ensure the customer is accurately charged according to the latest pricing information.

[0018]

[0025] In some embodiments, server 220 may process images from cameras 210 (installed throughout the site) to identify products on shelves and / or assess their respective stock levels. Following product identification, server 220 may also retrieve additional product information, such as expiration dates for perishable items, from ESL database 235. Using the received data, including but not limited to expiration dates and assessed stock levels, server 220 may then determine dynamic pricing adjustments for each product type and each batch. In some embodiments, ML models may be used to refine and enhance the decision-making process. ML models may analyze historical sales data, customer behavior patterns, and other relevant factors following price changes to predict price adjustments that maximize (or at least improve) sales and profitability while ensuring effective inventory management. Upon determining a price adjustment, the server may communicate with both PoS database 230 and ESL database 235 and provide them with updated pricing information. Through communication, ESL 205 displays updated prices directly on store shelves, and checkout station 215 applies the most recent prices during the billing process, ensuring consistency across retail operations. By updating these databases 230 and 235, server 220 ensures that retail devices are synchronized and provide accurate, transparent, and up-to-date pricing information to customers.

[0019]

[0026] In some embodiments, gateway 225 may have both router and modem capabilities and serve as a central hub for both internal and external data transmission. As illustrated, gateway 225 provides connectivity to the Internet 240, allowing store managers, staff, and even customers to interact with the system from any location. For example, through the Internet 240, store managers and staff can monitor and manage pricing and inventory levels from any location using their computers 245, smartphones 250, or other computing devices. In embodiments where an error occurs during the pricing adjustment process, such as an ESL being unable to update a display or a database being unresponsive or returning incomplete information, server 220 may automatically send a notification via the Internet 240 to staff devices, such as smartphones 250 or computers 245. The notification ensures that staff are immediately aware of the operational problem and / or take relevant measures to minimize disruptions to the pricing system. In addition to or instead of adjusting prices, in embodiments in which the server determines (based on analysis of historical sales data, market trends, and / or future inventory supply deliveries) that the supply of a particular product (e.g., sandwiches) should be reduced, server 220 may send a notification to a device at the supply chain management end point (e.g., a kitchen) over Internet 240. The notification allows personnel involved in supply chain management to adjust production or distribution plans accordingly.

[0020]

[0027] In some embodiments, the remote access capabilities provided by gateway 225 via a connection to the Internet 240 may be extended to customers. For example, a customer may use their personal device, such as a smartphone 250, to scan a barcode displayed on ESL 205. Upon scanning, the customer may access ESL database 235 over the Internet 240 to view updated prices and other product information.

[0021]

[0028] In some embodiments, connections between the various components in perishable inventory loss control system 200 (e.g., ESL 205, camera 210, checkout station 215, server 220, PoS database 230, and ESL database 235) and gateway 225 can be either wired or wireless, depending on the requirements, constraints, and capabilities of the network infrastructure.

[0022]

[0029] Although the PoS database 230 and the ESL database 235 are illustrated as two separate components within the perishable inventory loss control system 200, in some embodiments, a single centralized database may be used. In this configuration, both the PoS devices (e.g., checkout stations 215) and the ESL 205 may access the unified database to obtain updated pricing and other product information.

[0023]

[0030] Although a central server 220 is illustrated in perishable inventory loss control system 200, in some embodiments, system 200 may include more than one server, and the functions of analyzing images to identify products on shelves, estimating stock levels, and determining price or supply adjustments may be distributed across these servers. A distributed server architecture allows the computational load to be shared across multiple servers, thereby improving the scalability and reliability of the system.

[0024]

[0031] FIG. 3 illustrates an exemplary electronic shelf label (ESL) 300 according to some embodiments of the present disclosure. The illustrated ESL 300 may correspond to the shelf IO device 120 illustrated in FIG. 1. As illustrated, the ESL 300 includes a display 305, a Wi-Fi interface 310, a near-field communication (NFC) interface 315, and a button 320. The display 305 may be an electronic ink display, which conserves power compared to other types of display screens. When the ESL 300 operates on battery power, the display 305 may be an electronic ink display. In embodiments in which the ESL 300 is not battery-operated but is coupled to a power source, the display 305 may be another type of display, such as an LED or LCD. In some embodiments, the display 305 may be a touchscreen that allows a user to interact with the ESL, such as by selecting a virtual button that indicates the customer is seeking help or expert advice.

[0025]

[0032] The Wi-Fi interface 310 may include a transmitter / receiver (transceiver) for transmitting and receiving Wi-Fi data. The Wi-Fi interface 310 may connect the ESL 300 to a perishable goods inventory loss control system (e.g., 200 in FIG. 1) through a gateway (e.g., 225 in FIG. 2) that manages the Wi-Fi network in the retail environment. The wireless connection may enable the ESL 300 to receive real-time updates on pricing and other product information, ensuring that the displayed data is current and accurately reflects the system's dynamic adjustments.

[0026]

[0033] NFC interface 315 allows ESL 300 to communicate with store employee devices and customer user devices using NFC. Store employee can use NFC interface 315 to update display 305 without requiring direct physical access or manual data entry, or customer user devices can use NFC interface 315 to receive pricing or other product information.

[0027]

[0034] Button 320 can be a physically actuated button or a capacitive button. In this example, ESL 300 includes printed text instructing the customer to press button 320 if they need help (e.g., to contact a professional). This text can be printed on ESL 300 or output on display 305.

[0028]

[0035] The illustrated ESL 300 represents only one example of an ESL and its features. For example, other ESL implementations may not include all of the features shown. Some ESLs may include a Wi-Fi interface 310 but not an NFC interface 315 or a button 320. Some ESLs may include an NFC interface 315 but not a Wi-Fi interface 310 or a button 320. Further, some ESLs may include a Wi-Fi interface 310 and a button 320 but not an NFC interface 315.

[0029]

[0036] 4 illustrates an example method 400 for controlling inventory loss of perishable goods according to some embodiments of the present disclosure. In some embodiments, method 400 may be performed by one or more computing devices, such as server 220 illustrated in FIG. 2 and / or computing device 800 illustrated in FIG. 8.

[0030]

[0037] Method 400 begins at block 405, where a perishable inventory loss control server (e.g., 220 in FIG. 2) receives images from cameras installed throughout a business location (e.g., a retail store). The images depict shelves (e.g., 105 in FIG. 1) at the location, noting the products displayed and their placement.

[0031]

[0038] At block 410, the server preprocesses these captured images to enhance their quality for future data analysis. Preprocessing may include adjusting image parameters (e.g., brightness, contrast) and filtering out noise to improve accuracy for subsequent image recognition operations. In some embodiments, preprocessing may also include cropping the image to focus on relevant areas (e.g., top shelves) to ensure more efficient recognition and analysis.

[0032]

[0039] In block 415, the server uses image recognition algorithms to identify products and their batches on the shelf. In some embodiments, identification may involve analyzing visual features such as packaging details, labels, barcodes, or other identifiable marks unique to each product type or batch. For example, a GS1-128 barcode may include a Global Trade Item Number (GTIN) application identifier indicating the product type and additional identifiers such as batch / lot number, weight, or other relevant product information. Items sharing the same GS1-128 barcode indicate that they are of the same product type and belong to the same batch. These barcodes are typically printed directly on product packaging or displayed on an ESL, making them easy to capture with a camera.

[0033]

[0040] In block 420, following product identification by its visual characteristics and barcode, the server retrieves detailed product information from a database (e.g., ESL database 235 of FIG. 2). In some embodiments, the product information may include, among other things, product name, product ID (e.g., SKU), expiration date, brand, and manufacturer information.

[0034]

[0041] The server calculates stock levels for the identified products and their respective batches at block 425. In some embodiments, the calculation may involve detailed analysis of images received from the camera, either counting visible items or estimating quantities based on shelf space occupation.

[0035]

[0042] At block 430, the server determines whether to adjust the price of the product to improve sales and / or reduce perishable inventory loss. In some embodiments, the price adjustment may be determined based on various factors, including, but not limited to, assessed stock levels, product expiration dates, calculated product margins, historical sales data and market trends, and / or projected near-term stock levels based on planned product purchases. In some embodiments, an ML model trained based on historical sales patterns, price changes, and customer responses may be utilized to predict price adjustments. In some embodiments, adjusting prices may accelerate sales (thereby reducing perishable inventory loss) while avoiding excessive discounting that could lead to significant revenue losses. If the server determines that the price of a particular product batch (e.g., batch 110-1 of product A in FIG. 1 ) should be adjusted, method 400 proceeds to block 435, where the server communicates with the PoS database and the ESL database to communicate the updated pricing information. Synchronization ensures that the most recent prices are reflected at the checkout stations and ESLs. However, if the server determines not to adjust the price, method 400 proceeds to block 440, where the server evaluates whether a change in supply is desirable, taking into account, among other things, current stock levels, historical sales data, and customer behavior patterns. Reducing supply may be desirable in embodiments where, even with a lower price, the supply of the product is still high enough to risk perishable inventory loss. In such a configuration, the server may recommend reducing incoming stock or temporarily halting production to allow existing stock to be fully sold. By reducing supply in this way, the server can effectively align supply more closely with demand, further reducing the likelihood of perishable inventory loss.

[0036]

[0043] If the server determines that a supply adjustment should be made (e.g., reducing the order quantity of a particular product), method 400 proceeds to block 445, where the server sends a notification to the relevant store personnel or department. This may include alerting the supply chain management team via an automated system or notifying suppliers directly so that they adjust their manufacturing or distribution plans accordingly. Method 400 then returns to block 405. However, if the server determines that no supply adjustment is desired, or after the notification has been sent, method 400 returns to block 405, and the server continues to monitor stock levels within the business location.

[0037]

[0044] 5 illustrates an example method 500 for an ESL device to update and display prices according to some embodiments of the present disclosure. In some embodiments, method 500 may be performed by shelf IO device 120 illustrated in FIG. 1 and / or ESL 205 illustrated in FIG. 2.

[0038]

[0045] In block 505, the ESL (e.g., 205 in FIG. 2) actively checks for updates from the ESL database (e.g., 235 in FIG. 2) periodically, such as hourly or daily, depending on the requirements of the retail operation and the configuration of the ESL system. Alternatively, in other embodiments, the ESL database may be configured to send notifications to connected ESLs after the perishable inventory loss control server (e.g., 220 in FIG. 2) updates the database with price adjustments. These notifications inform the ESLs that updated pricing information is available and prompt them to retrieve and display the updated prices. Both methods (periodic checks and direct notifications) ensure that the ESLs remain current with the most recent pricing information and / or reflect changes in a timely manner.

[0039]

[0046] At block 510, upon notification or during a scheduled check, the ESL connects to the ESL database to obtain the most recent pricing information for the products it displays.

[0040]

[0047] In block 515, the ESL processes the retrieved data and updates the display (eg, 305 in FIG. 3) to show the latest prices.

[0041]

[0048] At block 520, the ESL monitors the price update process for errors. Possible errors may include problems such as communication failures (e.g., loss of Wi-Fi connectivity preventing the ESL from receiving notifications from the ESL database), data acquisition issues (e.g., the ESL database is unresponsive or returns incomplete information), or failures updating the display (e.g., the ESL screen remains unchanged due to a hardware malfunction). If an error is detected during this process, method 500 proceeds to block 525, where the ESL proactively flags the problem for human intervention. In some embodiments, the ESL may send an alert to the store management system or notify store personnel directly via a smartphone or tablet (e.g., 245 or 250 in FIG. 2 ). The alert and / or notification may include detailed information about the nature of the error and its location in the store, guiding the personnel to manually address the issue. If no errors are detected, method 500 returns to block 505, where the ESL continues to check for further updates to ensure that the pricing information remains current.

[0042]

[0049] 6 illustrates an example method 600 for a POS device to obtain updated prices upon product scanning, according to some embodiments of the present disclosure. In some embodiments, method 600 may be performed by one or more PoS devices, such as checkout station 215 illustrated in FIG. 2.

[0043]

[0050] In block 605, a PoS device (e.g., checkout station 215 of FIG. 2) scans the product's label, which may be a GS1 Logistics Label (1D barcode) or a GS1 Digital Link (2D barcode). The scanning operation may capture the product's unique identifier, such as the GTIN, or other information encoded in the barcode, such as a batch number or weight.

[0044]

[0051] At block 610, the PoS device uses the product's unique identifier to retrieve detailed product information from the PoS database (e.g., 230 in FIG. 2 ). The product information may include, among other things, the product name, description, SKU, expiration date, ingredient list, manufacturer information, and latest price (which may have been dynamically updated by the store's perishable inventory loss control system).

[0045]

[0052] In block 615, the PoS device calculates the total price of the customer's purchase. If multiple items are being purchased, the actions of blocks 605 and 610 can be repeated for each item, with the total price calculated by cumulatively adding the prices of the scanned items. The repetition of the process ensures that the final price accurately reflects any price adjustments applied by the store's perishable inventory loss control system.

[0046]

[0053] FIG. 7 is a flow diagram illustrating an example method for dynamic pricing and inventory monitoring according to some embodiments of the present disclosure.

[0047]

[0054] At block 705, a computing device (e.g., server 220 in FIG. 2) receives stock level data via a camera (e.g., 125 in FIG. 1 or 210 in FIG. 2), the stock level data including estimated stock levels of a product batch (e.g., batch 110-1 of product A in FIG. 1) at a physical location. In some embodiments, a product batch may comprise a group of items of the same type that share a matching expiration date.

[0048]

[0055] In some embodiments, the camera may comprise an edge camera with built-in processing capabilities that generates one or more images of a product batch at a physical location and uses image recognition techniques to determine an estimated stock level of the product batch based on the one or more images.

[0049]

[0056] In block 710, the computing device retrieves product information for the batch of products from a database (eg, 230 or 235 in FIG. 2), where the product information includes a best-by date and a first price of the products.

[0050]

[0057] At block 715, the computing device calculates a second price for the product batch using a machine learning (ML) model based on the expiration date and the estimated stock level.

[0051]

[0058] At block 720, the computing device updates the database with the second price for the batch of products.

[0052]

[0059] In some embodiments, the computing device may further send the second price of the product batch to a shelf input / output (IO) device. In some embodiments, the shelf IO device (e.g., 120 in FIG. 1 or 205 in FIG. 2) may be attached to a shelf that presents the product batch at a physical location. In some embodiments, the shelf IO device may be connected to a database to receive the second price of the product batch and update a display screen of the shelf IO device (e.g., 305 in FIG. 3) based on the second price.

[0053]

[0060] In some embodiments, the checkout station may be connected to a database to obtain a second price for the product batch upon scanning a label associated with the product batch during the checkout process.

[0054]

[0061] 8 illustrates an exemplary computing device configured to perform various aspects of the present disclosure, according to some embodiments of the present disclosure. While illustrated as a physical device, in some embodiments, computing device 800 may be implemented using virtual device(s) and / or across multiple devices (e.g., in a cloud environment). Computing device 800 may be embodied as any computing device or system, such as server 220 illustrated in FIG. 2.

[0055]

[0062] As illustrated, computing device 800 includes a CPU 805, memory 810, storage 815, one or more network interfaces 825, and one or more I / O interfaces 820. In the illustrated embodiment, CPU 805 retrieves and executes programming instructions stored in memory 810, as well as stores and retrieves application data resident in storage 815. CPU 805 generally represents a single CPU and / or GPU, multiple CPUs and / or GPUs, a single CPU and / or GPU with multiple processing cores, etc. Memory 810 is generally considered to represent random access memory. Storage 815 may be any combination of disk drives, flash-based storage devices, etc., 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).

[0056]

[0063] In some embodiments, I / O devices 835 (e.g., keyboard, monitor, etc.) are connected via I / O interface(s) 820. Additionally, via network interface 825, computing device 800 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), etc.). As illustrated, CPU 805, memory 810, storage 815, network interface(s) 825, and I / O interface(s) 820 are communicatively coupled by one or more buses 830.

[0057]

[0064] In the illustrated embodiment, memory 810 includes an image pre-processing component 850, a stock estimation component 855, and a perishable inventory loss control component 860. While illustrated as separate components for conceptual clarity, in some embodiments, the operations of the illustrated components (and other components not illustrated) may be combined or distributed across any number of components. Furthermore, while illustrated as software resident in memory 810, in some embodiments, the operations of the illustrated components (and other components not illustrated) may be implemented using hardware, software, or a combination of hardware and software.

[0058]

[0065] In the illustrated embodiment, the image preprocessing component 850 may process and / or enhance the quality of raw image data received from the store's cameras for further analysis. In some embodiments, the image preprocessing component 850 may adjust various image parameters, such as brightness and contrast, filter out noise, and / or crop the image to focus on specific areas of interest. After the images are preprocessed, the stock estimation component 855 may analyze them to estimate the stock level of each product batch displayed on the shelf. The stock estimation component 855 may use image recognition algorithms to identify products and calculate the quantity of available stock. The analysis may include counting visible items in the image or estimating quantities based on the space occupied by the products on the shelf. In some embodiments, the stock estimation component 855 may also retrieve detailed information for each identified product from a database. The detailed information may include, but is not limited to, product name, description, SKU, expiration date, manufacturing information, and ingredient list. Based on the information provided by the stock estimation component 855, the perishable inventory loss control component 860 may determine price adjustments and / or supply adjustments for each product. These adjustments may be determined based on a variety of factors, including, but not limited to, proximity to expiration dates, current stock levels, and historical sales data. By considering these factors, the perishable inventory loss control component 860 may optimize pricing or supply strategies for on-shelf products to accelerate sales and reduce perishable inventory loss.

[0059]

[0066] In the illustrated example, storage 815 may contain various data to support the operation of the system. The data may include, but is not limited to, raw image data 870 captured by cameras in the store, detailed information obtained about products on the shelves 875, and their estimated stock levels 880. In some embodiments, the data may be stored in a remote database (e.g., 230 or 235 in FIG. 2 ) that connects to computing device 800 over a network.

[0060]

[0067] The description of various embodiments of the present disclosure has been presented for illustrative purposes, 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 terms used herein have been selected to best explain the principles of the embodiments, practical applications, or technical improvements over technologies found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0061]

[0068] Reference will be made hereinafter to the embodiments presented in this disclosure. However, the scope of the present disclosure is not limited to the described embodiments. Rather, 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 the prior art, whether or not an advantage is achieved by a given embodiment does not limit the scope of the present disclosure. Accordingly, 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 "the present disclosure" should not be considered a generalization of any inventive subject matter disclosed herein, nor should it be considered an element or limitation of the appended claims unless expressly recited in the claim(s).

[0062]

[0069] Aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which may be collectively referred to herein as a "circuit," "module," or "system."

[0063]

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

[0064]

[0071] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but 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 further 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 discs (DVDs), memory sticks, floppy disks, mechanical coding devices such as punch cards or ridge structures with grooves in which instructions are recorded, and any suitable combination of the foregoing. Computer-readable storage media, as used herein, should not be considered to be transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses through a fiber optic cable), or electrical signals transmitted through electrical wires.

[0065]

[0072] 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 within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to a computer-readable storage medium within the respective computing / processing device for storage.

[0066]

[0073] The computer-readable program instructions for carrying out the operations of the present disclosure 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, for example, object-oriented programming languages ​​such as Smalltalk or C++, and traditional procedural programming languages ​​such as the "C" programming language or similar programming languages. 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 to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry 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 circuitry to implement aspects of the present disclosure.

[0067]

[0074] Aspects of the present disclosure 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.

[0068]

[0075] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine in which the instructions, executed by the processor of the computer or other programmable data processing apparatus, provide means for implementing 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 on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other device to function such that the computer-readable storage medium storing the instructions functions to provide 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.

[0069]

[0076] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device, such that the instructions, when executed on the computer, other programmable apparatus, or other device, produce a computer-implemented process that implements the function(s) / act(s) specified in one or more blocks of the flowcharts and / or block diagrams.

[0070]

[0077] 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 instructions, comprising one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or that implements a combination of dedicated hardware and computer instructions.

[0071]

[0078] Embodiments of the present disclosure may be delivered to end users through a cloud computing infrastructure. Cloud computing generally refers to the provisioning of scalable computing resources as a service over a network. More formally, cloud computing may be defined as a computing capability that provides abstraction between computing resources and their underlying technical architecture (e.g., servers, storage, network), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal administrative effort or service provider interaction. Thus, cloud computing allows users to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in the "cloud" without regard to the underlying physical systems (or the location of these systems) used to provide the computing resources.

[0072]

[0079] Typically, cloud computing resources are provided to users on a pay-per-use basis, where users are charged for the computing resources they actually use (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 across the Internet. In the context of the present disclosure, users may access available applications (e.g., dynamic pricing and perishable goods inventory loss control applications) or related data in the cloud. For example, the dynamic pricing and perishable goods inventory loss control applications may process data, generate corresponding instructions, and store related results in a storage location in the cloud via the cloud computing infrastructure. Doing so allows users to access this information from any computing system connected to a network (e.g., the Internet) connected to the cloud.

[0073]

[0080] 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. receiving stock level data via a camera, the stock level data including an estimated stock level of a product batch at a physical location; obtaining product information from a database for the batch of products, the product information including a best-by date and a first price for the batch of products; determining a second price for the batch of product based on the expiration date and the estimated stock level using a machine learning (ML) model; updating the database with the second price for the batch of products; A method comprising:

2. The method of claim 1 , wherein the product batch comprises a group of items of the same type that share a matching expiration date.

3. The camera is generating one or more images of the product batch at the physical location; using image recognition techniques to determine the estimated stock level of the product batch based on the one or more images; 10. The method of claim 1, further comprising: an edge camera having built-in processing capabilities for:

4. The method of claim 1 , further comprising sending the second price for the product batch to a shelf input / output (IO) device.

5. The method of claim 4 , wherein the shelf IO device is attached to a shelf that represents the product batch at the physical location.

6. The shelf IO device is connected to the database, receiving the second price for the batch of products; updating a display screen of the shelf IO device based on the second price; The method according to claim 4, wherein

7. The method of claim 1 , wherein a checkout station is connected to the database to obtain the second price of the product batch upon scanning a label associated with the product batch during a checkout process.

8. one or more processors; one or more memories storing a program; wherein the program, when executed on any combination of the one or more processors, receiving stock level data via a camera, the stock level data including an estimated stock level of a product batch at a physical location; obtaining product information from a database for the batch of products, the product information including a best-by date and a first price for the batch of products; determining a second price for the batch of product based on the expiration date and the estimated stock level using a machine learning (ML) model; updating the database with the second price for the batch of products; A system that performs the operations comprising:

9. The system of claim 8 , wherein the product batch comprises a group of items of the same type that share a matching expiration date.

10. The camera is generating one or more images of the product batch at the physical location; using image recognition techniques to determine the estimated stock level of the product batch based on the one or more images; 10. The system of claim 8, comprising an edge camera having built-in processing capabilities for:

11. 9. The system of claim 8, wherein the program, when executed on any combination of the one or more processors, performs an operation further comprising sending the second price for the product batch to a shelf input / output (IO) device.

12. The system of claim 11 , wherein the shelf IO device is attached to a shelf that represents the product batch at the physical location.

13. The shelf IO device is connected to the database, receiving the second price for the batch of products; updating a display screen of the shelf IO device based on the second price; The system of claim 11 , further comprising:

14. 10. The system of claim 8, wherein a checkout station is connected to the database to obtain the second price of the product batch upon scanning a label associated with the product batch during a checkout process.

15. One or more non-transitory computer-readable media containing computer program code in any combination, said computer program code, when executed by operation of a computer system, receiving stock level data via a camera, the stock level data including an estimated stock level of a product batch at a physical location; obtaining product information from a database for the batch of products, the product information including a best-by date and a first price for the batch of products; determining a second price for the batch of product based on the expiration date and the estimated stock level using a machine learning (ML) model; updating the database with the second price for the batch of products; [0023] 1. One or more non-transitory computer-readable media that perform operations comprising:

16. 16. The one or more non-transitory computer-readable media of claim 15, wherein the product batch comprises a group of items of the same type that share a matching expiration date.

17. The camera is generating one or more images of the product batch at the physical location; using image recognition techniques to determine the estimated stock level of the product batch based on the one or more images; 16. The one or more non-transitory computer-readable media of claim 15, comprising an edge camera having built-in processing capabilities to:

18. 16. The one or more non-transitory computer-readable media of claim 15, wherein the computer program code, when executed by operation of a computer system, performs operations further comprising sending the second price for the product batch to a shelf input / output (IO) device.

19. the shelf IO device is attached to a shelf that represents the product batch at the physical location, the shelf IO device is connected to the database, receiving the second price for the batch of products; updating a display screen of the shelf IO device based on the second price; 20. The one or more non-transitory computer-readable media of claim 18,

20. 16. The one or more non-transitory computer-readable media of claim 15, wherein a checkout station is connected to the database to obtain the second price of the product batch upon scanning a label associated with the product batch during a checkout process.