PREDICTIVE DEFROSTING FOR BEVERAGE STORES

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to Chinese Patent Application No. 202410859153.5, filed on Jun. 28, 2024, and Chinese Patent Application No. 202410859150.1, filed on Jun. 28, 2024, which are hereby incorporated by reference in their entirety.

TECHNICAL FIELD

This specification relates to predictive defrosting for beverage stores.

BACKGROUND

Beverage stores (e.g., coffee houses, bubble tea shops, juice bars) usually prepare beverages using a variety of ingredients. Some beverage stores are equipped with freezers maintained at low temperatures (e.g., below −15° C.) to preserve the ingredients as inventory. Prior to use, frozen ingredients need to be defrosted in advance, for example, defrosted to a usable liquid state. The defrosted ingredients are usually intended for immediate or short-term use.

SUMMARY

This specification describes apparatuses, systems, methods for predictive defrosting for beverage stores.

According to a first aspect, a computer-implemented method is provided. The method includes receiving amounts of ingredients consumed in one or more previous operation cycles; generating, based on the amounts of ingredients consumed in the one or more previous operation cycles, predicted amounts of ingredients needed in a next operation cycle; sending the predicted amounts of ingredients to a defrosting device; and determining a target temperature curve for defrosting the ingredients needed in the next operation cycle.

With reference to the first aspect, in some implementations, receiving the amounts of ingredient consumed in one or more previous operation cycles includes: receiving, from a workstation, amounts of ingredients consumed in each operation cycle at an end of the operation cycle, wherein the workstation is in the same store as the defrosting device.

With reference to the first aspect, in some implementations, generating the predicted amounts of the ingredients needed in the next operation cycle includes: generating initial predicted amounts of the ingredients needed in the next operation cycle; determining a factor indicating whether the next operation cycle includes a workday or a non-workday; and determining final predicted amounts of the ingredients needed in the next operation cycle by multiplying the initial predicted amounts with the factor.

With reference to the first aspect, in some implementations, generating the predicted amounts of the ingredients needed in the next operation cycle further includes: in response to determining that a defrosting duration is longer than an operation cycle, determining the factor based on a future operation cycle that follows the defrosting duration, the factor indicating whether the future operation cycles includes a workday or a non-workday.

With reference to the first aspect, in some implementations, generating the predicted amounts of the ingredients needed in the next operation cycle further includes: determining whether a defrosted inventory is sufficient based on the final predicted amounts.

With reference to the first aspect, in some implementations, generating predicted amounts of ingredients needed in the next operation cycle includes: determining historical demand and demand variation based on the amounts of ingredients consumed in the one or more previous operation cycles; determining types of ingredients needed for the next operation cycle based on the demand variation; and predicting an amount for each type of ingredient needed in the next operation cycle based on the types of ingredients and the demand variation.

With reference to the first aspect, in some implementations, the method further includes: receiving historical operation data of more than one store, where the historical operation data of each store includes amounts of ingredients consumed in the corresponding store in one or more previous operation cycles; generating first operation data by processing historical operation data; generating second operation data based on a relationship graph indicating similarities among the more than one store; training a prediction model using features derived from the first operation data and the second operation data; and generating, by the prediction model, predicted amounts of ingredients needed in the next operation cycle in each of the more than one store.

With reference to the first aspect, in some implementations, generating the second operation data based on the relationship graph indicating similarities among the more than one store includes: collecting store-level information, wherein the store-level information includes at least one of scale, location, business district information, regional attributes and regional weather type of each store in a chain store system; generating a feature matrix based on the relationship graph indicating similarities among stores in the store chain system, performing clustering analysis on the stores in the chain store system based on the feature matrix, and determining a representative store for each store cluster; and selecting the store-level information of target stores of each store cluster as the second operation data, wherein the target stores are selected based on the representative stores.

With reference to the first aspect, in some implementations, sending the predicted amounts of ingredients to the defrosting device includes: sending the predicted amounts of ingredients to the defrosting device via an Internet of Thing (IoT) network. A controller of the defrosting device is connected to one or more central servers via the IoT network.

With reference to the first aspect, in some implementations, the method further includes: determining whether the defrosting device is connected to one or more central servers; and in response to determining that the defrosting device is not connected to one or more central servers, scanning, by a scanner, a QR code comprising information on ingredients needed in the next operation cycle; and sending the information on ingredients needed in the next operation cycle to the defrosting device. The scanner and the defrosting device are connected via a personal area network (PAN).

With reference to the first aspect, in some implementations, the method further includes receiving, by a workstation from the one or more central servers, the information on ingredients needed in the next operation cycle; and generating the QR code by the workstation.

With reference to the first aspect, in some implementations, determining the target temperature curve includes: sending a plurality of temperature curves to the defrosting device, where the plurality of temperature curves correspond to a plurality of ingredients; storing the plurality of temperature curves in a memory of the defrosting device; and selecting, by the defrosting device, the target temperature curve from the plurality of temperature curves.

With reference to the first aspect, in some implementations, the method further includes: preconfiguring the plurality of temperature curves based on defrosting tests on the plurality of ingredients.

With reference to the first aspect, in some implementations, the method further includes defrosting ingredients by controlling a temperature and/or a defrosting duration in the defrosting device based on the target temperature curve.

With reference to the first aspect, in some implementations, the target temperature curve is selected based on: types of the ingredients needed in the next operation cycle; and/or the amounts of the ingredients needed in the next operation cycle.

With reference to the first aspect, in some implementations, the target temperature curve corresponds to an ingredient that is the most difficult to defrost among the ingredients needed in the next operation cycle.

With reference to the first aspect, in some implementations, the plurality of temperature curves have the same fixed defrosting duration.

With reference to the first aspect, in some implementations, the method further includes: displaying the predicted amounts of ingredients on a screen of the defrosting device.

With reference to the first aspect, in some implementations, the method further includes: generating a relationship graph of a plurality of stores; identifying stores that are similar to a first store based on the relationship graph, where the first store has the defrosting device; and generating, based on amounts of ingredients consumed in the stores similar to the first store, predicted amounts of ingredients needed in the first store.

With reference to the first aspect, in some implementations, the relationship graph is generated based on at least one of: store sizes, store locations, regional attributes, and regional weather type.

According to a second aspect, one or more computer-readable storage media is provided. The one or more computer-readable storage media stores one or more instructions that, when executable by one or more computers, cause the one or more computers to perform the method according to the first aspect and/or one or more implementations of the first aspect.

According to a third aspect, a computer-implemented system is provided. The computer-implemented system includes one or more computers and one or more computer memory devices interoperably coupled with the one or more computers. The one or more computer memory devices have computer-readable storage media storing one or more instructions that, when executed by the one or more computers, perform the method according to the first aspect and/or one or more implementations of the first aspect.

The details of one or more embodiments of the subject matter of this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a flow chart of a method of predictive defrosting.

FIG. 2 illustrates a system having central server(s) and defrosting device in communication with the central server(s).

FIG. 3 illustrates a flow chart of an example process of obtaining a defrosting list under an online mode or an offline mode.

FIG. 4 illustrates a flowchart of an example method of predictive defrosting.

FIG. 5 illustrates a flowchart of an example method for controlling a defrosting device by predicting ingredient demands for a next operation cycle.

FIG. 6 illustrates a flowchart of another example method for controlling a defrosting device by predicting ingredient demands for a next operation cycle.

FIG. 7 illustrates example temperature curves for defrosting.

FIG. 8 illustrates an example configuration of a defrosting mode.

FIG. 9 is an example computing system.

Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

In chain-operated beverage stores, it is common to prepare beverages using ingredients that are kept frozen and need to be defrosted in advance, such as milk, coffee concentrate, tea extract, and fruit purde. To meet service demands and ensure timely order fulfillment, ingredients are typically defrosted before the start of each operation cycle (e.g., daily or per shift). The defrosting process often relies on rough estimation or static defaults, which can result in over-defrosting, causing waste as defrosted ingredients typically cannot be preserved for a long time, or under-defrosting, impairing service capacity and product quality. Inaccurate defrosting planning may adversely affect the store's finished product rate and overall turnover.

The present disclosure provides techniques to predict ingredient demands for upcoming operation cycles and to control defrosting devices based on the predicted demands. In some implementations, ingredient demands of the upcoming operation cycle can be predicted based on ingredient consumption of previous operation cycles (e.g., of the same store, or of similar stores). Further, according to the predicted types and amounts of demanded ingredients, a smart defrosting device can select a suitable defrosting temperature curve from multiple predefined temperature curves, so that the ingredients can be defrosted efficiently while avoiding thermal damage or degradation in quality.

The described techniques can achieve one or more technical benefits. For example, the described techniques can allow more accurate prediction of defrosting needs in future operation cycles, which can improve store readiness and reduce waste. For another example, by collecting ingredient consumption information and sending predictions on defrosting needs to individual stores, the described techniques can achieve centralized and adaptive defrosting control across multiple stores, thereby improving operational efficiency for chain-based beverage operations. In some implementations, different or additional advantages can be achieved.

FIG. 1 illustrates a flow chart of a method 100 of predictive defrosting. For convenience, the method 100 will be described as being performed by a system (e.g., the system 200 shown in FIG. 2 or the system 900 shown in FIG. 9), located in one or more locations, and programmed appropriately in accordance with the present disclosure. Further, some of the operations may be omitted, or performed simultaneously or in a different order than shown in FIG. 1.

At 102, amounts of ingredients consumed in one or more previous operation cycles are received (e.g., by a central server). For example, the amounts of ingredients consumed in one or more previous operation cycles can be collected from each store managed and connected to the central server.

In some implementations, receiving the amounts of ingredients consumed in one or more previous operation cycles includes receiving, from a workstation, amounts of ingredients consumed in each operation cycle at the end of the operation cycle. The workstation can be in the same store as the defrosting device. In some implementations, on top of sending the types and quantities of beverages sold at the store, the workstation can also send the types and amounts (e.g., quantities of bottles, cartons, boxes, bags, etc.) of consumed ingredients. For example, at the end of each operation cycle, a store employee can conduct an inventory check, and count the amounts of ingredients consumed in the current operation cycle. The store employee can then input the counted amounts into the workstation or a mobile device. The central server can receive the amounts of consumed ingredients from the workstation or the mobile device.

At 104, predicted amounts of ingredients needed in a next operation cycle are generated based on the amounts of ingredients consumed in the one or more previous operation cycles. In some implementations, the amounts of ingredients needed in the next operation cycle can be predicted using an artificial intelligence model.

In some implementations, step 104 can include steps 404 to 408 of the method 400, as shown in FIG. 4.

In some implementations, generating predicted amounts of ingredients needed in the next operation cycle includes: determining historical demand and demand variation based on the amounts of ingredients consumed in the one or more previous operation cycles; determine types of ingredients needed for the next operation cycle based on the demand variation; and predicting an amount for each type of ingredient needed in the next operation cycle based on the types of ingredients and the demand variation.

In some implementations, generating predicted amounts of ingredients needed in the next operation cycle includes: predicting quantities of beverages to be sold in the next operation cycle; and determining predicted amounts of ingredients needed in the next operation cycle based on a mapping relationship between beverages and ingredients.

At 106, the predicted amounts of ingredients are sent to a defrosting device. In some implementations, a controller of the defrosting device is in communication with one or more central servers. In some implementations, the predicted amounts of ingredients can be displayed on a screen of the defrosting device.

In some implementations, sending the predicted amounts of ingredients to the defrosting device includes: sending the predicted amounts of ingredients to the defrosting device via an Internet of Thing (IoT) network. A controller of the defrosting device is connected to one or more central servers via the IoT network.

At 108, a target temperature curve is determined for defrosting the ingredients needed in the next operation cycle. In some implementations, a plurality of temperature curves are sent to the defrosting device, the temperature curves corresponding to a plurality of ingredients; and the plurality of temperature curves are stored in a memory of the defrosting device. In some implementations, the defrosting device can select the target temperature curve from the plurality of temperature curves, e.g., based on types of the ingredients needed in the next operation cycle; and the amounts of the ingredients needed in the next operation cycle. In some implementations, the temperature curve corresponding to an ingredient that is the most difficult to defrost among the ingredients needed is selected as the target temperature curve. In some implementations, the plurality of temperature curves are preconfigured based on defrosting tests on the plurality of ingredients.

In some implementations, determining the target temperature curve includes: sending a plurality of temperature curves to the defrosting device, where the plurality of temperature curves correspond to a plurality of ingredients; storing the plurality of temperature curves in a memory of the defrosting device; and selecting, by the defrosting device, the target temperature curve from the plurality of temperature curves.

In some implementations, the defrosting device can operate in an offline mode (e.g., when disconnected from the one or more central servers). The method can further include: determining whether the defrosting device is connected to one or more central servers; and in response to determining that the defrosting device is not connected to one or more central servers, scanning, by a handheld scanner or a scanner embedded in the defrosting device, a QR code including information on ingredients needed in the next operation cycle. In some implementations, a workstation or a mobile device operated by a store employee receives the information on ingredients needed in the next operation cycle from the one or more central servers, and then generates the QR code. The defrosted device can be connected to the mobile device and/or the workstation via Bluetooth or other personal area network.

In some implementations, a relationship graph of a plurality of stores (e.g., all chain stores in a specific region) can be generated. In some cases, when a first store does not have enough historical data for making predictions, stores that are similar to the first store can be identified based on the relationship graph. Predicted amounts of ingredients needed in the first store can be generated based on amounts of ingredients consumed in stores similar to the first store, e.g., according to steps 302 to 310 of process 300. In some implementations, the relationship graph is generated based on at least one of store sizes, store locations, store district attributes, or store-area weather types.

In some implementations, upon receiving historical operation data of more than one store, where the historical operation data of each store comprises amounts of ingredients consumed in the corresponding store in one or more previous operation cycles, the central server can make a prediction applicable for all of the more than one store. For example, the central server can generate first operation data by processing historical operation data; generate second operation data based on a relationship graph indicating similarities among the more than one store; train a prediction model using features derived from the first operation data and the second operation data; and generate, by the prediction model, predicted amounts of ingredients needed in the next operation cycle in each of the more than one store.

FIG. 2 illustrates an example diagram of a system having central server(s) 202 and defrosting device 204 (including 204a, 204b, 204c) in communication with the central server(s) 202. In some implementations, the central server(s) 202 may be part of a backend management center for a chain store operation. The central server(s) 202 can be configured to collect store-level operational data (e.g., sales volume and revenue) and transmit instructions or schedules to individual stores.

Each defrosting device 204 can be a smart defrosting refrigerator located within a corresponding store. The defrosting device 204 may be configured to defrost inventory ingredients to be consumed for beverage preparation. In some implementations, before the start of each operation cycle of the store, the ingredients expected to be consumed during the upcoming operation cycle need to be defrosted to a usable state (e.g., from solid to liquid). As an example, the ingredients can include milk, coffee concentrate, tea extract, fruit juice, flavored syrup, sweeteners, fruit pulp, fruit puree, flavor powders, etc. The ingredients may be stored in a frozen state and require defrosting before use. An operation cycle can be a fixed number of hours, one day, one week, or any suitable time interval. For example, an operation cycle can be the high-activity time window in beverage store operations (e.g., from 9:00 a.m. to 21:00 p.m. on a specific day).

In some implementations, each defrosting device 204 may include a controller having a communication module (e.g., an Internet of Things (IoT) module) configured to communicate with the central server(s) 202. For example, an IoT module can allow the defrosting device 204 to receive defrosting instructions or parameters from the central server(s) 202, and to send usage data to the central server(s) 202. The defrosting device 204 can also include a display screen for showing the types and quantities of ingredients currently in the defrosting device 204, and/or types and quantities of ingredients that need to be put in the defrosting device 204.

In some implementations, the defrosting device 204 may further include a code scanner configured to scan packaging labels or store inventory barcodes, allowing employees to confirm ingredient identity or update inventory status. The code scanner may be embedded in the defrosting device, e.g., mounted on the front panel. The code scanner can be configured to capture and decode QR codes that contain ingredient defrosting information, including the types and amounts of ingredients needed for the next operation cycle. The decoded information can be processed by a local controller of the defrosting device to determine which temperature curve to apply and how to schedule the defrosting procedure. The code scanner may be operable by a store employee through a simple manual action, such as presenting a QR code displayed on a mobile device or printed from a workstation.

In some implementations, when the defrosting device 204 is disconnected from the IoT network and unable to receive data from the central server(s) 202, the defrosting device 204 can operate in an offline mode. In the offline mode, the defrosting instructions may be delivered via a QR code generated by a workstation in a store, after the workstation receives the defrosting instructions from the central server(s) 202. By scanning the QR code, the defrosting device 204 can locally reconstruct the defrosting instructions. As such, even when the defrosting device 204 is disconnected from the network, defrosting and preparation of ingredients may not be interrupted.

As an example, at a designated time in each operation cycle (e.g., when the store closes on each day), a store employee may check the amounts of ingredients consumed during the current operation cycle and upload the consumption data to the central server(s) 202 using a mobile terminal or a workstation. The central server(s) 202 can analyze the historical and current data to predict the amounts of ingredients needed for the next operation cycle. The central server(s) 202 can send the prediction to the mobile terminal or the workstation of the store employee, so that the store employee can place a suitable amount of frozen ingredients into the defrosting device 204 for defrosting. In some implementations, the central server(s) 202 can send the prediction to the defrosting device 204. As explained in greater detail with respect to FIGS. 2-6, the defrosting device 204 can select an appropriate defrosting temperature curve based on the types and amounts of the ingredients to be defrosted, and perform the defrosting task according to the defrosting temperature.

As such, ingredients can be defrosted in advance and be ready for use when the next operation cycle begins, reducing delays in beverage preparation and improving store readiness and product delivery efficiency.

FIG. 3 illustrates a flow chart of an example process 300 of obtaining a defrosting list under an online mode or an offline mode. The process 300 may be implemented by a system (e.g., the system 200 of FIG. 2) including central server(s), an IoT system, a defrosting device in a beverage store, and a workstation in the beverage store, where the workstation (e.g., a computer) can be operated by a store employee. The operations of process 300 may be performed in a distributed manner, depending on connectivity and system configuration.

The process 300 starts at 302. At 302, a defrosting session may be initiated in response to a scheduled event, a system prompt, or a request submitted by a store employee. In some implementations, the request to initiate a defrosting session may be triggered automatically at a designated time interval, e.g., prior to the start of an operation cycle.

At 304, the central server(s) generate a defrosting list for a specific store location. In some implementations, the defrosting list may be computed based on predicted ingredient demands derived from historical operation data, inventory levels using predefined prediction models. The defrosting list may include identifiers for each ingredient type, required quantities, defrosting urgency levels, and/or estimated time windows for execution. The defrosting list may be formatted in a machine-readable structure (e.g., JSON or XML) and transmitted to the store through the IoT network.

At 306, the generated defrosting list is sent to an IoT network operable to relay information to local defrosting devices and workstation interfaces. The IoT system may include a message queue broker, a secure cloud server, or an edge computing gateway.

At 308, the IoT system determines whether the defrosting device is currently connected to the network. In some implementations, this determination may be made through a heartbeat signal or connectivity check performed between the defrosting device and the IoT network.

If the defrosting device is connected to the IoT network, the process 300 proceeds to 310. At 310, the defrosting device receives the defrosting list from the IoT network. The defrosting device can be equipped with a communication module and memory configured to store preconfigured temperature curves locally. The temperature curves may be indexed according to ingredient types, group identifiers, and/or defrosting level classifications.

At 312, the defrosting device selects a target temperature curve based on the received defrosting list. In some implementations, the device may select the curve corresponding to the most difficult-to-defrost ingredient included in the defrosting list, thereby ensuring adequate defrosting for all ingredients. The selected temperature curve may have multiple temperature steps, hold durations, and slope transitions optimized for the target defrosting behavior.

At 314, if the defrosting device is not connected to the IoT network, a defrosting interface on the local workstation may be used to retrieve the defrosting list. In some implementations, the interface may be implemented as a software module or a graphical user interface (GUI) accessible to the store employee. The employee may click a button or input a command to initiate retrieval of the most recent defrosting list from the central server.

At 316, the workstation determines whether a defrosting list is available. For example, the workstation can check whether a valid and unexpired list exists in local memory, or whether the request to the central server was successful. In some implementations, the defrosting list may be retained for a defined validity window corresponding to the length of an operation cycle.

If the defrosting list is not available, the process 300 proceeds to 320, where a prompt message is displayed to the store employee. The message may indicate that the defrosting list is missing or expired, and may instruct the employee to re-initiate the request or perform a manual procedure.

If the defrosting list is available, the process 300 proceeds to 318. At 318, the workstation or a mobile device of the store employee generates a QR code corresponding to the defrosting list. The QR code may encode all or a subset of the defrosting list information, including ingredient types and amounts. In some implementations, the QR code may be displayed on a screen, printed, or presented on a portable terminal.

At 322, a store employee operates a scanner (e.g., a hand scanner) to scan the QR code. In some implementations, the scanner may transmit the decoded information wirelessly to the defrosting device. For example, the scanner and the defrosting device can be connected to each other via a personal area network (PAN), such as via Bluetooth, near field communication (NFC), radio frequency identification (RFID). In some implementations, the defrosting device can have an embedded scanner to scan the QR code and obtain the decoded information.

Upon receiving the decoded information in the QR code, the defrosting device can extract the defrosting list. At 312, the defrosting device can select a target temperature curve based on the defrosting list.

At 324, the defrosting process is completed. The defrosting device executes defrosting by controlling its temperature according to the target temperature curve in preparation for the next operation cycle.

FIG. 4 illustrates a flow chart of an example method 400 of predictive defrosting. The method 400 can be implemented by the system 200 of FIG. 2, e.g., by the central server(s) 202 in communication with a plurality of defrosting devices 204. It is understood that some of the operations may be omitted, or performed simultaneously or in a different order than shown in FIG. 4.

At 402, the system (e.g., by the central server(s)) receives amounts of ingredients consumed in one or more previous operation cycles. In some implementations, at the end of each operation cycle, a store employee can conduct an inventory counting, and input the types and amounts of ingredients consumed in the current operation cycle to a workstation in the store, and the workstation can send these information to the central server(s).

At 404, the system generates initial predicted amounts of the ingredients needed in the next operation cycle. For example, the central server can execute a prediction model by inputting collected data on consumed ingredients from previous operation cycles (e.g., seven operation cycles, sixteen operation cycles, or any suitable number of operation cycles), and obtain the initial predicted amounts.

At 406, the system determines a factor indicating whether the next operation cycle includes a workday or a non-workday. For example, if the next operation cycle is a workday, beverage sales to nearby office workers may typically be higher, which means ingredient consumption may be greater, so the factor may be greater than 1; if the next operation cycle is a non-workday, the factor may be smaller than 1.

At 408, the systems determines final predicted amounts of the ingredients needed in the next operation cycle by multiplying the initial predicted amounts with the factor. As such, the final predicted amounts may be different depending on whether the next operation cycle includes a workday or a non-workday.

In some cases, a defrosting duration (that is, the time needed to adequately defrost the ingredient to a usable state) may end on a later operation cycle after the next operation cycle. For example, the defrosting duration for certain ingredients may be longer than an operation cycle. As an example, certain ingredients may take more than 36 hours to be defrosted to a usable state, while each operation cycle may be one day. In such case, in response to determining that the defrosting duration is longer than an operation cycle, the factor can be determined based on a future operation cycle that follows the defrosting duration, where the factor indicates whether the future operation cycle includes a workday or a non-workday. As an example, if the defrosting duration is equivalent to X operation cycles, the future operation cycle can be the (X+1)^th operation cycle after the current operation cycle, which is the operation cycle that the defrosted ingredient will actually be used.

In some implementations, based on the final predicted amounts, whether a defrosted inventory is sufficient can be determined. In some implementations, a staff employee can receive the final predicted amounts (e.g., from the workstation of a mobile device). The staff employee can further check the current defrosted inventory (e.g., by counting currently defrosted ingredients), and determine whether the current defrosted inventory is sufficient. If the current defrosted inventory is sufficient, the store employee does not need to move additional ingredients from the freezer into the defrosting device for defrosting. If the current inventory is insufficient, the store employee can move additional ingredients from the freezer to the defrosting device, based on a difference between the final predicted amounts and the current defrosted inventory. In some implementations, defrosting devices may be equipped with sensors (such as weight sensors, RFID, or vision systems) to detect the types and amounts of ingredients stored inside, which can enable real-time inventory tracking without needing store employees to do manual inventory counting.

At 410, the predicted amounts of ingredients are sent to a defrosting device (e.g., from the central server(s)). In some implementations, a controller of the defrosting device is in communication with the central server(s) and can receive information from the central server(s), e.g., via the IoT network.

At 412, a target temperature curve is determined for defrosting the ingredients needed in the next operation cycle. In some implementations, a plurality of temperature curves are sent to the defrosting device, the temperature curves corresponding to a plurality of ingredients. The plurality of temperature curves are stored in a memory of the defrosting device. In some implementations, the defrosting device can select the target temperature curve from the plurality of temperature curves, e.g., based on types and/or amounts of the ingredients needed in the next operation cycle.

FIG. 5 illustrates a flowchart of an example method 500 for controlling a defrosting device by predicting ingredient demands for a next operation cycle. The method 500 can be implemented by the system 200 of FIG. 2, e.g., by the central server(s) 202 in communication with a plurality of defrosting devices 204. It is understood that some of the operations may be omitted, or performed simultaneously or in a different order than shown in FIG. 5.

At 502, the system collects historical operation data of one or more stores, and determines historical demand data and demand variation data from the historical operation data, e.g., based on historical defrosting records. The historical operation data can include types and amounts of ingredients consumed in different stores, types and quantities of beverages sold at different stores, sales revenue from different stores, etc. In some implementations, the historical demand data includes ingredient combinations, ingredient types, and ingredient amounts consumed or needed in previous operation cycles. The ingredient combination can be a predefined set of beverage ingredients consumed in different formulation schemes for preparing beverages aggregated over each operation cycle. Demand variation data can indicate differences between the actual amount of ingredients consumed in the previous operation cycles, and the predicted amount of ingredients needed in the previous operation cycles.

In some implementations, a first threshold can be pre-set to identify normal-activity operation cycles, and a second threshold can be pre-set to determine high-activity operation cycles. The system can determine whether the historical demand data of a given operation cycle exceeds the first threshold, and if so, determine whether the historical demand data also exceeds the second threshold. If the historical data of the given operation cycle demand data exceeds the second threshold, the given operation cycle can be determined as an anomaly, and the system can selectively exclude such data or incorporate additional operation cycles for more accurate and stable prediction.

In some implementations, the first threshold can be a statistical sales benchmark determined from aggregate values (such as the mean, median, and mode) over a defined period (e.g., one month or two weeks). The second threshold can be a statistical upper bound, such as a fixed percentile or standard deviation range above the first threshold, used to identify anomalously high demand. Historical demand data that fall below the first threshold or exceed the second threshold can be excluded from being used for the prediction.

In some implementations, the second threshold can be determined based on a continuity analysis of profit rate trends. If the profit rate consistently stays positive or negative over multiple cycles (e.g., without alternation), the corresponding data can be excluded from the prediction. Only periods with alternating positive and negative profit rates are retained, as they can better reflect true operational dynamics and can contribute to more accurate predictions.

In some implementations, the historical defrosting record can include the quantity of each ingredient defrosted, the type of each ingredient defrosted, the urgency level, and the corresponding defrosting time. For example, types of ingredients include “single ingredient”, referring to individual components within each combination, “combination ingredient”, referring to a predefined group of two or more single ingredients used together in beverage preparation, “base ingredient”, referring to primary liquid components that form the main volume or basis of a beverage, and “auxiliary ingredient”, referring to seasoning or flavoring components that are added in small quantities to adjust taste, texture, or aroma, such as syrups, powders. For example, condensed milk may be treated as a seasoning ingredient even though it is dairy-based.

It should be noted that stores may offer various beverage products with different formulations, requiring diverse combinations of base ingredients and auxiliary ingredients (e.g., seasoning ingredients). Accordingly, both base ingredients and auxiliary ingredients need to be predicted, allowing for timely scheduling of defrosting operations based on specific product compositions.

In some implementations, determining the demand variation data includes: matching timestamps between historical demand data and corresponding historical defrosting records; calculating the deviation between the predicted demand and the actual defrosted quantity for the same cycle to obtain a set of first deviation values; calculating second deviation values based on the variance between consecutive first deviation values across adjacent operation cycles. The first deviation values and second deviation values can be used as indicators of prediction accuracy.

At 504, the system determines types of target ingredients needed for a next operation cycle based on the demand variation data, e.g., by using a data change rate algorithm and a demand-matching rule, and predicts a target defrosting list associated with the types of target ingredients, e.g., by using a prediction model based on the types of ingredients and the demand variation data.

The target defrosting list can be a data structure that indicates the types and quantities of ingredients to be defrosted at a given store in the upcoming operation cycle. The list may also include data such as defrosting urgency levels, recommended defrosting start times, and/or whether the listed ingredients are to be defrosted individually or as part of a combination batch.

In some implementations, the data change rate algorithm can be configured to calculate how rapidly demand deviation values change over time. For example, the data change rate algorithm may compute the percentage change between adjacent deviation values to reflect demand volatility, and help the system determine whether the demand pattern is stable or shifting before selecting a defrosting strategy. The demand-matching rule can be a set of logic-based or data-driven criteria used to align the fluctuation patterns in historical demand data with representative ingredient types or usage categories. For example, if the demand variation data shows a consistent increase in fruit-based beverage orders during weekend cycles, the system may match this pattern to fruit juice or related base ingredients as candidates for inclusion in the target defrosting list. In some implementations, the demand-matching rule can prioritize ingredients that show a high correlation between sales trends and previous defrosting records.

In some implementations, determining types of target ingredients includes: calculating a first data change rate from the first deviation values; generating a threshold based on the first change rate, and processing the second deviation values accordingly to compute a second data change rate; feeding the first and second data change rates, along with the historical mapping between demand and defrosting types, into a trained classification model to output a target defrosting type for the next operation cycle. The target defrosting type may include a specific ingredient type, a defrosting urgency level, and a defrosting time window.

The classification model is trained using a dataset comprising predicted demand variation data, actual defrosting outcomes, and corresponding defrosting labels.

In some implementations, the prediction model can include, for example, a classification model trained to output the type, urgency, and expected usage of ingredients based on input demand variation data. Additionally or alternatively, a regression model may be used to estimate the quantity and defrosting time of each ingredient. For example, the prediction model can be a combination of a decision tree-based classifier (e.g., random forest or XGBoost) for ingredient type selection and a time-series model (e.g., autoregressive integrated moving average (ARIMA) model, or long short-term memory (LSTM) model) for demand forecasting.

In some implementations, predicting the target defrosting list includes: selecting a target prediction model from a preconfigured set of material combination models, where the target prediction model includes a strategy model and a defrosting time model; inputting demand variation data into the strategy model to generate predicted ingredient groupings (including combinations of single, seasoning, and flavoring ingredients), along with their respective quantities; feeding the ingredient combination strategy and demand variation data into the time prediction model to estimate the defrosting time for each group. As such, a target defrosting list can be generated. The target defrosting list can include the ingredient type, groupings, quantities, and defrosting schedule.

At 506, the system generates a target defrosting curve based on historical defrosting lists and predicted target defrosting lists. A defrosting curve can be a temperature curve for defrosting. In some implementations, the system can first generate a preliminary defrosting curve and then simulate and correct the preliminary defrosting curve using a simulation model to obtain a final defrosting curve.

In some implementations, generating and refining the defrosting curve includes extracting historical defrosting parameters (e.g., such as defrosting time, temperature, and type coefficient) for both single ingredients and combination combinations. The parameters can be collected from a small subset (e.g., 1%-5%) of all historical defrosting records per cycle, e.g., by using temperature sensors. In some cases, real-time temperature data collection cannot be performed on every defrosting instance. Therefore, a representative sample set may be used to train a model.

Generating and refining the defrosting curve can further include: training a model with historical defrosting curves to compute the average similarity between single ingredients and combination ingredients, obtaining a first similarity; generating a defrosting curve for the target ingredients, and computing its similarity with respect to historical defrosting curves, obtaining a second similarity; and calculating a weighted average between the first and second similarities to yield a third similarity. The third similarity can be used as an input to further adjust the model parameters through iterative optimization, such that the resulting target defrosting curve more accurately reflects the defrosting behavior of both single ingredients and combination ingredients. In some implementations, final defrosting parameters can be determined according to the target defrosting list and the refined defrosting curve.

In some implementations, a set of defrosting curves can be determined by conducting experiments on various ingredients, including single ingredients and combination ingredients. For example, ingredients can be assigned into different groups, each group corresponding to a defrosting level (e.g., levels A to E) from the least difficult to defrost, to the most difficult to defrost. Each ingredient can be assigned to a group based on its defrosting characteristics. In some implementations, each of the set of defrosting curves can correspond to a group. It should be noted that the number of groups is not fixed and can be adjusted based on actual demand granularity.

Ingredients can be defrosted according to a defrosting curve selected based on the target defrosting list. To defrost an ingredient that belongs to a specific group, the defrosting curve corresponding to the specific group can be applied. In some implementations, to defrost more than one ingredient in a single defrosting session, the defrosting curve corresponding to the group that the most difficult-to-defrost ingredient belongs to can be applied. For example, the most difficult-to-defrost ingredient can be the one that requires the longest defrosting time, the most precise temperature control, or the narrowest allowable thermal fluctuation range.

At 508, the system outputs a target defrosting plan based on the target defrosting list and the target defrosting curve to execute the ingredient defrosting process. In some implementations, the target defrosting plan can be sent from the central server to a defrosting device in the corresponding store. The target defrosting plan can also be sent to a mobile device operated by a store employee, enabling the employee to manually retrieve the required ingredients from a freezer and place them into a defrosting device.

Method 500 can be used to predict the defrosting type for the next operation cycle of a beverage store using historical operation data and historical or pre-defined defrosting curves. Based on the predicted types of ingredients to be defrosted, the system can generate a target defrosting list and refine its corresponding defrosting curve through iterative model adjustment. In some implementations, by using method 500, defrosting operations can be well aligned with actual ingredient demands, improving the accuracy and efficiency of defrosting workflows and enhancing the beverage store's product readiness and service speed.

FIG. 6 illustrates a flow chart of another example method 600 of controlling a defrosting device by predicting ingredient demands for a next operation cycle. The method 600 can be implemented by the system 200 of FIG. 2, e.g., by the central server(s) 202 in communication with a plurality of defrosting devices 204. It is understood that some of the operations may be omitted, or performed simultaneously or in a different order than shown in FIG. 6.

At 602, the system collects historical time-series operation data from one or more stores (e.g., chain stores). The system can fit the set of historical data and generate a predicted operation threshold. In some implementations, the system can process (e.g., process) the historical time-series data using the operation threshold to generate first operation data.

At 604, the system collects store-level information of the one or more stores. The system can further generate a relationship graph based on the store-level information, and determine similar features among the stores based on the relationship graph. The features can be used to process (e.g., process) the store-level information and generate second operation data.

At 606, the system fuses spatiotemporal features determined from the first and second operation data. Prediction sample selection is periodically evaluated for anomalies based on the fused feature errors. In some implementations, the prediction sample set and store list can be updated in real time accordingly.

At 608, the system classifies the beverage products sold at each store based on the updated prediction sample data, and identifies the ingredient combination and corresponding single ingredient types for each beverage. A mapping relation can be determined to associate finished beverages with their ingredients. The mapping relation can be used to determine defrosting requirements before making beverages.

At 610, the system inputs the defrosting requirements with the first and second operation data into a prediction model to generate a predicted defrosting demand curve and its associated probability. A defrosting list for the next operation cycle can be generated based on the predicted defrosting demand curve and the probability.

At 612, the system matches the prediction sample data to corresponding defrosting curves (e.g., temperature curves for defrosting) based on the mapping relation between single ingredients and finished beverages. The system further generates a defrosting plan based on the defrosting list and a defrosting curve selected based on the defrosting list, e.g., according to step 406 of method 400.

At 614, the system controls and executes the defrosting tasks of each store based on the store-specific defrosting list and corresponding defrosting plan.

In some implementations, the system collects historical time-series sales data from each store in units of operation cycle (e.g., a time interval period between store opening and closing). Step 602 further includes:

• • (1) organizing historical sales data (e.g., types and quantities of beverages sold) per store and per operation cycle;
  • (2) segment the historical sales data into peak-season and off-season cycles based on probability density;
  • (3) fit the two data segments separately by the prediction model to produce corresponding historical sales curves;
  • (4) extracting and weighing intersection points of the two historical sales curves are based on the rate of change in each curve. A weighted average of these intersections can be computed to determine the operation threshold; and
  • (5) comparing the historical time-series operation data of each operation cycle with the operation threshold. Operation cycles with sales data exceeding the operation threshold can be selected as part of the first operation data set.

In some implementations, step 604 further includes:

• • (1) collecting store-level information, the store-level information including at least one of scale, location, business district information (e.g., the business district that the store belongs to), regional attributes (e.g., attributes such as city tier level, proximation to transportation hubs, neighboring business types), and regional weather type (e.g., average temperature, humidity level, seasonal precipitation patterns) of each store in a chain store system;
  • (2) generating a feature matrix based on the relationship graph indicating similarities among stores in the chain store system, performing clustering analysis on the stores in the chain store system, analyzing each store cluster based on similar features, and determining a representative store for each store cluster; and
  • (3) selecting the store-level information of target stores of each store cluster as the second operation data, where the target stores are determined based on the representative stores.

In some implementations, step 606 further includes:

• • (1) fusing temporal attributes (e.g., cycle timing) and spatial attributes (e.g., store location and region) using an attention mechanism to assess inter-store correlation;
  • (2) selecting historical operational data that are most relevant to the correlated stores as prediction sample data; and
  • (3) collecting forecasted and actual ingredient demand for each sample, calculating cycle-level deviations, and determining a target error by computing a weighted average of the deviations. If the deviation for a prediction sample exceeds the target error, the sample and target error can be updated.

In some implementations, the defrosting demand includes the quantities and types of one or more ingredients, such as single ingredients, base ingredients, axillary ingredients, and combination ingredients needed in a given operation cycle. The prediction sample data can include predicted amounts of ingredients to be defrosted, actual amounts of ingredients defrosted, ingredient types, defrosting urgency levels, and defrosting durations.

In some implementations, the defrosting requirement is determined by performing regression analysis on the prediction sample data using the mapping relation between beverages and ingredients.

In some implementations, step 610 further includes:

• • (1) training the prediction model using historical store time-series data;
  • (2) creating a test set from clustered beverage data and associated defrosting data. The test set, along with the first and second operation data, can be input into the trained model; and
  • (3) generating a predicted defrosting demand curve and probability distribution using the training prediction model. Based on the predicted defrosting demand curve and probability distribution, a defrosting list for the next operation cycle can be generated. For example, the defrosting list can include ingredient quantities, types, urgency levels, and defrosting durations.

In some implementations, step 612 further includes:

• • (1) determining a defrosting level gradient for various ingredients;
  • (2) configuring the parameter range for each gradient level;
  • (3) identifying the defrosting gradient of each item in the defrosting list based on parameter range;
  • (4) assigning defrosting curves to each single ingredient and combination ingredient based on their gradient classification; and
  • (5) configuring defrosting parameters through the assigned defrosting curves to generate a defrosting plan.

In some implementations, the method 600 enables the system to construct prediction sample data with spatiotemporal features by selecting representative stores and relevant operation records. By periodically evaluating prediction error and updating sample data in real time, the system maintains adaptive accuracy. The method 600 can also decompose beverage formulations into single and combination ingredients, predict defrosting demand, classify defrosting types, and generate defrosting plans. As a result, the system enhances material preparation accuracy for the upcoming operation cycle, reduces the risk of ingredient shortages or over-defrosting, and improves the overall consistency of beverage output and order fulfillment efficiency.

FIG. 7 illustrates example temperature curves 702, 704, 706, 708 for defrosting operations. Each temperature curve can represent a distinct temperature profile over time and can be used to control the operation of a defrosting device. In some implementations, each temperature curve can include one or more stepped segments, with each step indicating a temperature hold level and a duration during the defrosting process. It should be noted that FIG. 7 shows four temperature curves for illustration purpose. Any suitable number of temperature curves can be preconfigured and sent to defrosting devices for local storage. It should be noted while FIG. 7 shows the temperature curves as stepped linear profiles, the temperature curves may also be continuous curves (e.g., smooth, gradually varying temperature profiles.

As shown in FIG. 7, the temperature curves 702, 704, 706, 708 are different from each other in one or more aspects, including: (i) the number of steps, (ii) the hold temperature at each step, and (iii) the time held at each step. For example, temperature curve 702 includes more steps than curve 710, indicating a more gradual defrosting process. Different ingredients may require different defrosting temperature curves for defrosting. For example, fruit purée may require a lower maximum defrosting temperature, while frozen milk may require more steps and a longer overall curve duration. The required defrosting curve may also vary based on the quantity of the ingredients to be defrosted. For instance, a larger volume may call for a more gradual, multi-step curve to avoid thermal shock, while smaller quantities may be defrosted using less steps.

In some implementations, the defrosting duration (e.g., the total defrosting time from the starting temperature to the ending temperature) of different temperature curves can be the same and equal to a preset fixed duration. For example, while temperature curve 706 and temperature curve 708 have different number of steps and hold at different temperatures at each step, the defrosting duration corresponding to temperature curve 706 can be same as the defrosting duration corresponding to temperature curve 708. As an example, the preset fixed duration may be 10 hours, which may be the time between store closing of a previous operation cycle and store opening of a next operation cycle. It is understood that the preset fixed duration can be any suitable time length, for example, can be shorter than, equal to, or longer than an operation cycle.

In some implementations, the starting temperature and the ending temperature of the temperature curves 702, 704, 706, and 708 can be the same across different curves. For example, the starting temperature may correspond to the storage temperature of the freezer from which the frozen ingredients are retrieved, and the ending temperature may correspond to a holding temperature suitable for keeping the ingredient in a defrosted, ready-to-use state during the current operation cycle, such as the internal temperature of a refrigeration unit used for short-term ingredient preservation. In some other implementations, the starting temperature and the ending temperature of different temperature curves can be different, e.g., according to configurations or operation ranges of different defrosting devices. In some implementations, ingredients may be grouped into defrosting categories based on defrosting difficulty, such as temperature sensitivity, phase change behavior, moisture content, and structural density. Each category of ingredients can be assigned a corresponding temperature curve. For example, category A may include easily defrosted items such as flavored syrups; category B may include moderately difficult ingredients such as coffee concentrate; and category C may include ingredients that require longer or more controlled defrosting, such as frozen fruit pulp or dairy-based mixtures.

In some implementations, a defrosting device (e.g., the defrosting device 204 of FIG. 2) can store preconfigured temperature curves in local memory, for example, each curve corresponding to one of the defined ingredient categories. As an example, the temperature curve 702 can correspond to the category that is the easiest to defrost (e.g., needing the least steps, and reaching the ending temperature the earliest). The temperature curve 708 can correspond to the category that is the most difficult to defrost (e.g., needing more steps, and reaching the ending temperature the latest).

In some implementations, the preconfigured curves can each correspond to a type of ingredient. The preconfigured curves can be obtained by conducting defrosting tests on different types of ingredients, and analyze the testing results with respect to defrosting time, temperature sensitivity, structural integrity, and post-defrosting usability. The defrosting tests may include physical experiments using actual ingredients, or simulations based on ingredient-specific parameters such as thermal conductivity, moisture content, and phase change behavior. In some implementations, to defrost the same ingredient (or the same groups of ingredients) in different amounts, the defrosting device can select a different temperature curve.

Upon receiving a target defrosting list, the defrosting device can select the appropriate temperate curve based on the type and quantity of ingredients. If the ingredients to be defrosted in the same batch fall into multiple groups, the device may select the temperature curve associated with the most difficult-to-defrost ingredient among those scheduled for use in the next operation cycle, which can ensure defrosting adequacy while avoiding under-defrosting of critical ingredients.

In some implementations, ingredients can be defrosted in different batches (e.g., in different defrosting devices or different chambers of a defrosting device). For example, the ingredients to be defrosted can be grouped into different categories based on defrosting durations (time needed to adequately defrost to a useable state) of the ingredients. Ingredients that require a longer defrosting duration can be grouped into one category, and ingredients that require a shorter defrosting duration can be grouped into another category. It is understood that the ingredients can be grouped into any suitable number of categories. The defrosting device can determine a temperature curve corresponding to each category of ingredients. As such, different categories of ingredients can be defrosted separately, according to their corresponding temperature curves.

FIG. 8 illustrates an example configuration of a defrosting mode of a defrosting device. In some implementations, defrosting modes can be preconfigured at the central server(s) and then sent to defrosting devices. Each defrosting device can then select an appropriate defrosting device based on the predicted types and/or amounts of ingredients to be defrosted.

As shown in FIG. 8, the defrosting mode configuration can include basic information such as defrosting mode name, and defrosting mode number. The defrosting mode configuration can further include mode configuration, which can correspond to a temperature curve (e.g., one of temperature curves 702, 704, 706 and 708). For example, the mode configuration can be divided into different defrosting phases, where each defrosting phase can correspond to a step of the corresponding temperature curve. As an example, the mode configuration in FIG. 8 can be divided into four defrosting phases. It is understood that a mode configuration can be divided into any suitable number of defrosting phases. The total time duration of all defrosting phases can be a fixed duration (e.g., 10 hours, or any other suitable time duration). For instance, during the first defrosting phase, the defrosting device can keep its temperature at 15° C. for 210 minutes; during the second defrosting phase, the defrosting device can keep its temperature at 6° C. for 210 minutes; during the third defrosting phase, the defrosting device can keep its temperature at 6° C. for 120 minutes; and during the fourth defrosting phase, the defrosting device can keep its temperature at 5° C. for 210 minutes. In some implementations, the temperature of the defrosting device decreases from a higher temperature to a lower temperature from an earlier phase to a later phase, as shown in FIG. 8. Under such defrosting mode, the temperature of the ingredients being defrosted in the defrosting device can increase from a lower temperature (e.g., the temperature of the ingredients in the frozen state) to a higher temperature (e.g., temperature of the ingredients in the usable state), e.g., as shown in FIG. 7. As such, the ingredients can be better defrosted (e.g., using the higher temperature of the defrosting device in earlier phases) and better preserved (e.g., using the lower temperature of the defrosting device in later phases).

In some implementations, the defrosting mode configuration can include information of the associated ingredient category, including the ingredient category name, ingredient category number, and the amount of ingredient being defrosted. In response to determining a category that one or more ingredients to be defrosted belong to, the defrosting device can select the associated defrosting mode to defrost the ingredients. In some implementations, the defrosting mode configuration can include additional settings, such as whether the remaining space in the defrosting device can be used for placing pre-cooled ingredients (e.g., pure milk, coconut milk, etc.) that are already been defrosted to a usable state. By putting the pre-cooled ingredients in the remaining space of the defrosted device, the freshness of the pre-cooled ingredients can be preserved longer.

FIG. 9 is an example computer or computer-implemented_system 900. The system 900 can be used for the operations described in association with the implementations described herein, for example, as a data processing apparatus or server for making predictions on materials (e.g., ingredients) needed by a store in a next operation cycle. For example, the system 900 may be included in computing devices of the one or more online components and/or the one or more offline components. The system 900 includes a processor 910, a memory 920, a storage device 930, and an input/output device 940. The components 910, 920, 930, and 940 are interconnected using a system bus 950. The processor 910 is capable of processing instructions for execution within the system 900. In some implementations, the processor 910 is a single-threaded processor. In some implementations, the processor 910 is a multi-threaded processor. The processor 910 is capable of processing instructions stored in the memory 920 or on the storage device 930 to display graphical information for a user interface on the input/output device 940.

The memory 920 stores information within the system 900. In some implementations, the memory 920 is a computer-readable medium. The memory 920 can be a volatile memory unit or a non-volatile memory unit. The storage device 930 is capable of providing mass storage for the system 900. The storage device 930 is a computer-readable medium. The storage device 930 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device. The input/output device 940 provides input/output operations for the system 900. The input/output device 940 includes a keyboard and/or pointing device. The input/output device 940 includes a display unit for displaying graphical user interfaces.

In this specification the term “engine,” “collector,” “sampler,” “manager,” “calibrator,” or “calculator” will be used broadly to refer to a software-based system or subsystem that can perform one or more specific functions. Generally, an engine (or a collector, a sampler, a manager, a calibrator, a calculator) will be implemented as one or more software modules or components, installed on one or more computers in one or more locations. In some cases, one or more computers will be dedicated to a particular engine (or collector, sampler, manager, calibrator, calculator); in other cases, multiple engines (or collectors, samplers, managers, calibrators, calculators) can be installed and running on the same computer or computers.

Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible non-transitory storage medium for execution by, or to control the operation of, data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. Alternatively or in addition, the program instructions can be encoded on an artificially-generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus.

The term “data processing apparatus” refers to data processing hardware and encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can also be, or further include, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). The apparatus can optionally include, in addition to hardware, code that creates an execution environment for computer programs, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

A computer program, which may also be referred to or described as a program, software, a software application, an app, a module, a software module, a script, or code, can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data, e.g., one or more scripts stored in a markup language document, in a single file dedicated to the program in question, or in multiple coordinated files, e.g., files that store one or more modules, sub-programs, or portions of code. A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a data communication network.

The processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuitry, e.g., an FPGA or an ASIC, or by a combination of special purpose logic circuitry and one or more programmed computers.

Computers suitable for the execution of a computer program can be based on general or special purpose microprocessors or both, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a central processing unit for performing or executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or incorporated in, special purpose logic circuitry. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device, e.g., a universal serial bus (USB) flash drive, to name just a few.

Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user's device in response to requests received from the web browser.

Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface, a web browser, or an app through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits data, e.g., an HTML page, to a user device, e.g., for purposes of displaying data to and receiving user input from a user interacting with the device, which acts as a client. Data generated at the user device, e.g., a result of the user interaction, can be received at the server from the device.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any disclosure or on the scope of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular disclosures. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially be claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous.