US20150161912A1

US20150161912A1 - Analytics-based design and planning of creative menus

Info

Publication number: US20150161912A1
Application number: US14/564,224
Authority: US
Inventors: Debarun Bhattacharjya; Florian Pinel; Lav R. Varshney
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2013-12-09
Filing date: 2014-12-09
Publication date: 2015-06-11
Also published as: US20150324711A1; US10915846B2; US10019689B2; US20150161531A1; US20150161748A1; WO2015088978A1; US20180260751A1; US20180260750A1; US20170067866A1; US20150157752A1; US20150324938A1; US9600793B2; US10026050B2; US10217072B2; US10936983B2; US20150371164A1; US10127512B2

Abstract

In one embodiment, the present disclosure provides a method for analytics-based design and planning of creative menus. A method for designing and planning a menu, wherein the menu comprises at least one dish comprising a set of ingredients prepared according to a recipe includes obtaining a user-specified ingredient that must be included in the menu, obtaining a user-specified criterion that must be satisfied by the menu, automatically formulating an optimization problem that evaluates a plurality of potential dishes for inclusion in the menu by optimizing over the user-specified criterion, and automatically selecting the at least one dish from among the plurality of potential dishes, wherein the automatically selecting is performed based at least in part on a solution to the optimization problem, and wherein the at least one dish includes the user-specified ingredient.

Description

FIELD OF THE DISCLOSURE

This disclosure relates generally to the field of food preparation, and relates more specifically to the use of analytics to design and plan creative menus that meet a set of stated requirements.

BACKGROUND OF THE DISCLOSURE

A menu is a set of dishes (i.e., sets of ingredients prepared according to respective recipes) that, together, constitute a meal (e.g., a soup, an entrée, a side, a dessert, and/or a beverage). A menu may be defined by one or more attributes (i.e., potentially measurable features), such as novelty (e.g., how “new” the person consuming the food perceives the menu to be), nutrition level (e.g., how healthy the menu is), profitability (e.g., how much profit the menu is expected to bring to the person or establishment providing the menu), or the like.
There is an increasing demand in the field of food preparation for “creative” menus. A creative menu is a menu that is perceived to be highly novel, and that may optionally also be perceived as superior when considering other attributes. In addition, there is an increasing demand for menus that meet specific constraints, such as restrictions on ingredients (e.g., must be vegetarian, kosher, gluten-free, use locally-sourced ingredients, etc.), nutritional requirements (must not contain more than/less than x calories), or other constraints.
A menu creator should, for practical purposes, have access to the recipes for all of the dishes constituting the menu. A recipe is a list of component ingredients and series of actionable tasks for modifying/cooking the ingredients to produce a dish. The menu creator should also have access to a work plan (also referred to as a “menu plan”). A work plan is a schedule of tasks for joint preparation of the recipes for all dishes constituting the menu, based on available resources and facilities.
Planning a creative menu is thus complicated by the consideration of required attributes and/or constraints for the menu, as well as the availability of the required resources and facilities.

SUMMARY OF THE DISCLOSURE

In one embodiment, the present disclosure provides a method for analytics-based design and planning of creative menus. For example, a method for designing and planning a menu, wherein the menu comprises a plurality of dishes, and each dish in the plurality of dishes comprises a set of ingredients prepared according to a recipe includes obtaining a user-specified ingredient that must be included in the menu, obtaining a user-specified criterion that must be satisfied by the menu, automatically formulating an optimization problem that evaluates a plurality of potential dishes for inclusion in the menu by optimizing over the user-specified criterion, and automatically selecting the plurality of dishes from among the plurality of potential dishes, wherein the automatically selecting is performed based at least in part on a solution to the optimization problem, and wherein at least one dish in the plurality of dishes includes the user-specified ingredient.
In another embodiment, the present disclosure provides a device for designing and planning a menu, wherein the menu comprises a plurality of dishes, and each dish in the plurality of dishes comprises a set of ingredients prepared according to a recipe includes obtaining a user-specified ingredient that must be included in the menu, where the device includes a processor and a computer-readable medium storing instructions, which when executed by the processor, cause the processor to perform operations. The operations include obtaining a user-specified ingredient that must be included in the menu, obtaining a user-specified criterion that must be satisfied by the menu, automatically formulating an optimization problem that evaluates a plurality of potential dishes for inclusion in the menu by optimizing over the user-specified criterion, and automatically selecting the plurality of dishes from among the plurality of potential dishes, wherein the automatically selecting is performed based at least in part on a solution to the optimization problem, and wherein at least one dish in the plurality of dishes includes the user-specified ingredient.
In another embodiment, the present disclosure provides a system for designing and planning a menu, wherein the menu comprises a plurality of dishes, and each dish in the plurality of dishes comprises a set of ingredients prepared according to a recipe. The system includes a database storing recipes for a plurality of potential dishes and an application server for automatically selecting the plurality of dishes from among the plurality of potential dishes, wherein the automatically selecting is performed by automatically evaluating the plurality of dishes by optimizing over a user-specified criterion, wherein the plurality of dishes includes at least one dish that includes a user-specified ingredient.

BRIEF DESCRIPTION OF THE DRAWINGS

The teachings of the present disclosure can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 illustrates one embodiment of a system for planning a menu, according to the present disclosure;

FIG. 2 is a block diagram illustrating the application server of FIG. 1 in greater detail;

FIG. 3 illustrates an exemplary set of clusters of ingredients;

FIG. 4 illustrates an exemplary set of clusters of recipes;

FIG. 5 depicts two exemplary recipes modeled as directed acyclic graphs;

FIG. 6 depicts an exemplary recipe modeled as a Latent Dirichlet Allocation topic model;

FIG. 7 is a diagram depicting conversion of an exemplary menu into an exemplary work plan, in which the recipes comprising the menu are represented as directed acyclic graphs;

FIG. 8 depicts an exemplary detailed work plan in which tasks are scheduled on a common timeline and allocated to specific individuals or equipment for completion;

FIG. 9 is a flow diagram illustrating the high level method 900 for planning a menu, according to embodiments of the present disclosure; and

FIG. 10 is a high-level block diagram of a general purpose computing device suitable for use in performing the functions described herein.

DETAILED DESCRIPTION

In one embodiment, the present disclosure is related to a method and apparatus for analytics-based design and planning of creative menus. Design of a menu involves the selection of the dishes that constitute the menu, while planning of the menu involves scheduling and delegating (e.g., to people or equipment) the tasks necessary to prepare the dishes. For example, one embodiment of the present disclosure automatically (i.e., with little or no human assistance) designs a menu that may be perceived to be novel and varied, and may also be perceived as superior when considering other attributes or constraints. Further embodiments plan the menu for execution in a manner that considers the available facilities and resources. The present disclosure has particular applicability in the food industry, where it may be applied to design and plan menus in collaboration with entities that provide planning services to their customers (e.g., restaurants, nursing homes, schools, airlines, etc.). Embodiments of the disclosure can provide direct analytical support to such entities.
One aspect of the present disclosure is to modify a function of a computer based on whether certain resources are available. For instance, the computer may assign specific menu preparation tasks to certain individuals and/or equipment based on availability, need, and/or time constraints. Notably, a machine is required to modify certain portions of the computer as tasks are identified, scheduled, and assigned.
Embodiments of the present disclosure transform a set of disparate criteria (e.g., individual ingredients, desired attributes, constraints, etc.) into a suggested menu and/or work plan (e.g., a set of dishes satisfying the criteria and/or a plan for preparing the set of dishes using available resources and facilities). In other words, a set of ingredients or attributes does not typically dictate how, when, or by whom specific tasks will be performed. However, embodiments of the present disclosure take a set of disparate criteria and transform it into a suggested menu and/or work plan. Although some of the disparate criteria may be supplied by a human user, the transformation of the criteria into the suggested menu and/or workplan is performed with little or no human assistance (i.e., automatically).
An “attribute” as used herein refers to a feature of a menu or recipe that is deemed to be desirable. For example, some desirable features of menus and recipes include, but are not limited to: menus/recipes that are perceived to be novel, menus/recipes that are perceived to be tasty and flavorful, menus/recipes that demonstrate variety over time, menus/recipes that are compatible with a healthy lifestyle that meets nutritional requirements, menus/recipes that increase profit, menus/recipes that satisfy kitchen constraints and use available resources, menus/recipes that are opportunistic and economical with ingredient availability, menus/recipes with low carbon footprints, menus/recipes that are personalized for disparate tastes, and menus/recipes that meet dietary restrictions (e.g., nut-free, gluten-free, etc.).
FIG. 1 illustrates one embodiment of a system 100 for planning a menu, according to the present disclosure. The system 100 generally comprises one or more endpoint devices 102 ₁-102 _n(hereinafter collectively referred to as endpoint devices 102″) coupled to a network 104. The network 104, in turn, generally comprises an application server 106 and one or more databases 108 ₁-108 _m(hereinafter collectively referred to as “databases 108”).
The network 104 is a communications network. The network 104 may be any type of communications network, such as for example, a traditional circuit switched network (e.g., a public switched telephone network (PSTN)) or an Internet Protocol (IP) network (e.g., an IP Multimedia Subsystem (IMS) network, an asynchronous transfer mode (ATM) network, a wireless network, a cellular network (e.g., 2G, 3G and the like), a long term evolution (LTE) network, and the like) related to the current disclosure. It should be noted that an IP network is broadly defined as a network that uses Internet Protocol to exchange data packets. Additional exemplary IP networks include Voice over IP (VoIP) networks, Service over IP (SoIP) networks, and the like.
In one embodiment, the network 104 may comprise a core network that is in communication with one or more access networks (not shown), where the access networks may include a wireless access network (e.g., a WiFi network and the like), a cellular access network, a PSTN access network, a cable access network, a wired access network and the like. In one embodiment, the access networks may all be different types of access networks, may all be the same type of access network, or some access networks may be the same type of access network and other may be different types of access networks. The core network and the access networks may be operated by different service providers, the same service provider or a combination thereof.
As discussed above, the network 104 includes an application server 106 and one or more databases 108. Although only a single application server 106 and two databases 108 are illustrated, it should be noted that any number of application servers 106 or databases 108 may be deployed.
One embodiment of an application server 106 is described in greater detail in connection with FIG. 2. In another embodiment, the application server 106 may comprise a general purpose computer configured as a special purpose computer, as illustrated in FIG. 10 and discussed below. In one embodiment, the application server 106 may perform the methods and algorithms discussed below related to planning a menu and/or work plan. For instance, the application server 106 may suggest a menu in response to a set of inputs (received from the endpoint devices 102, for example) including required ingredients, desired flavor profiles/cuisines (e.g., seasonal and/or ethnic influences), and/or constraints (e.g., restrictions on ingredients, nutritional requirements, etc.). The application server 106 may additionally suggest a work plan based on available facilities and/or resources.
In one embodiment, the databases 108 may store data relating to menu planning. For instance, a first database 108 ₁may store a plurality of recipes. The recipes are grouped according to one or more criteria, such as by cuisine (e.g., Italian, holiday, etc.), by dish (e.g., pasta, chicken, etc.), by course (e.g., appetizer, entrée, etc.), or the like. A single recipe may belong to more than one group (e.g., a recipe for lasagna may belong to groups comprising “entrées” and “Italian cuisine”). Each recipe comprises a list of ingredients and a series of steps for preparing the ingredients to produce a dish. A second database 108 _mmay store information relating to ingredients and chemical compounds. These ingredients and chemical compounds may also be grouped according to one or more criteria. In an alternative embodiment, multiple databases 108 may store the recipes, or multiple databases 108 may store the information relating to the ingredients and chemical compounds. In a further embodiment still, all recipes and all information relating to the ingredients and chemical compounds are stored in a single database 108.
In one embodiment, the network 104 is in communication with the endpoint devices 102. In one embodiment, the endpoint devices 102 may be any type of computing device such as a desktop computer, a tablet computer, a laptop computer, a netbook, an ultrabook, a cellular telephone, a smart phone, a portable media device (e.g., an MP3 player), a gaming console, a portable gaming device, and the like. It should be noted that although only three endpoint devices 102 are illustrated in FIG. 1, any number of endpoint devices 102 may be deployed.
In an alternative embodiment, the methods performed by the application server 106 may be performed locally by the endpoint devices 102. In this case, the endpoint devices 102 access the databases 108 directly over the network 104 and perform the methods and algorithms discussed below related to planning a menu.
It should be noted that the network 104 has been simplified. For example, the network 104 may include other network elements (not shown) such as border elements, routers, switches, policy servers, security devices, a content distribution network (CDN) and the like.
FIG. 2 is a block diagram illustrating the application server 106 of FIG. 1 in greater detail. In general, the application server 106 receives a plurality of inputs from endpoint devices 102. The plurality of inputs relate to a menu to be planned, and may include, for example, required ingredients, desired flavor profiles/cuisines, and/or other constraints (e.g., restrictions on ingredients, nutritional requirements, etc.) on the menu. The application server 106 produces as output a suggested menu responsive to the plurality of inputs. In addition, the application server may also produce as output a work plan for preparing the menu based on the available facilities and resources. Thus, the application server 106 according to embodiments of the present disclosure transforms a set of criteria (e.g., individual ingredients, constraints, etc.) into a suggested menu and/or work plan (e.g., a set of dishes incorporating the criteria and/or a plan for preparing the set of dishes using available resources and facilities).
The application server 106 generally comprises an assessment modeling engine 200, a menu design engine 202, and a menu planning engine 204. Any of the modeling engine 200, menu design engine 202, and menu planning engine 204 may be implemented as a processor.
The assessment modeling engine 200 receives as input data gathered from a plurality of sources and, using this input, builds models to assess menu attributes. In one embodiment, the types of data received by the assessment modeling engine 200 include recipes, expert opinions (e.g., from chefs), and management interviews. The models built by the assessment modeling engine 200 assess menu attributes such as novelty, variety, nutrition, and the like. The data from which the models are built may be retrieved, for example, from one or more of the databases 108. Some embodiments of methods for building models to assess menu attributes are discussed in greater detail below in connection with FIGS. 5-6.
The menu design engine 202 receives as input the models built by the assessment modeling engine 200 and user-specified criteria, and, using this input, designs a menu. In one embodiment, the user-specified criteria include required ingredients, desired flavor profiles/cuisines, and/or other attributes or constraints on the menu. The user-specified criteria may be obtained, for example, from one of the endpoint devices 102. The menu design engine 202 optimizes over the user-specified criteria and attempts to satisfy any constraints. Embodiments of methods for designing a menu are discussed in greater detail below in connection with EQNs. 1-5.
The menu planning engine 204 receives as input the menus created by the menu design engine 202 and, using this input, schedules the work plan for preparing the menu. One embodiment of a method for preparing a work plan is discussed in greater detail below in connection with FIGS. 7 and 8. The menu and/or work plan may be output by the menu planning engine 204, for example to one or more of the endpoint devices 102.
As discussed above, building the models to assess menu attributes relies on data gathering. The data gathering process may collect several different types of data, including recipes, expert opinions, interviews, and/or external datasets. The recipes may be retrieved from one or more of the databases 108, which serve as sources for potentially performing re-combinations and modifications of existing recipes, and also for measuring novelty of menus. The expert opinions may be provided by chefs and can be used to generate ideas for novel recipes and for performing other attribute assessment-related tasks. The interviews may be provided by managers and/or other sources in the food preparation industry and contain information relating to available resources in the menu preparation facility, to costs and revenues associated with ingredients and dishes, and other types of information. The expert opinions and interviews may be retrieved from one or more of the databases 108. The external datasets comprise data from external sources (e.g., databases other than the databases 108), which may be required depending on the desired attributes of the menu. Data from external datasets may include information relating to the nutritional content of ingredients, to the seasonality of ingredients, or other information.
At a high level, data gathering may involve clustering ingredients and recipes into groups of like items. Ingredients may be clustered according to various categoies, such as type of ingredient (e.g., fruit, spice, etc.) or type of cuisine (e.g., Jamaican, Hungarian, etc.). Each cluster will contain ingredients that fall into a stated category, and a given ingredient may be included in more than one cluster.
FIG. 3, for example, illustrates an exemplary set of clusters of ingredients. In particular, FIG. 3 depicts three distinct ingredients: bananas, quinces, and paprika. In turn, each of these ingredients is included in one or more of four potential clusters: “fruit,” “spices,” “Hungarian cuisine,” and “Jamaican cuisine.” For example, bananas are included in the clusters for both “fruit” and “Jamaican cuisine,” while quinces are included in the clusters for both “fruit” and “Hungarian cuisine.” Paprika is included in the clusters for both “spices” and “Hungarian cuisine.”
Similarly, recipes may be clustered according to various categories, such as type of dish (e.g., pasta, pizza, etc.) or type of cuisine (e.g., American, Italian, etc.). Each cluster will contain recipes that fall into a stated category, and a given recipe may be included in more than one cluster.
FIG. 4, for example, illustrates an exemplary set of clusters of recipes. In particular, FIG. 4 depicts three distinct recipes: “Mario's Pizza,” “Anna's Spaghetti Bolognese (Spag Bol),” and “My Mac and Cheese.” In turn, each of these recipes is included in one or more of four potential clusters: “pizza dishes,” “pasta dishes,” “Italian cuisine,” and “American cuisine.” For example, “Mario's Pizza” is included in the clusters for both “pizza dishes” and “Italian cuisine,” while “Anna's Spag Bol” is included in the clusters for both “pasta dishes” and “Italian cuisine.” “My Mac and Cheese” is included in the clusters for both “pasta dishes” and “American cuisine.”
FIGS. 3 and 4 depict only one embodiment of a suitable approach to organizing data. Once sufficient data has been gathered and optionally organized as illustrated in FIGS. 3 and 4, the assessment modeling engine 200 uses the gathered data to build assessment models for specified attributes. The assessment models quantify a measure of how well a given recipe and/or menu satisfies a given attribute. Different types of data will be useful for modeling different attributes. Moreover, different modeling techniques may be implemented depending on the attributes to be modeled. Table 1, for example, presents some exemplary menu attributes, along with some of the data and modeling techniques that are considered useful for building assessment models of the stated attributes.

TABLE 1

Data and Modeling Techniques by Attribute

Menu Attribute	Useful Data	Modeling Techniques

Novelty	Recipe database; Interviews with chefs	Machine learning;
		Probabilistic analysis
Taste	External datasets relating to ingredient	Chemical compound
	pairings; Interviews with chefs	and olfactory analysis
Variety	Recipe database; Interviews with chefs	Machine learning;
		Probabilistic analysis
Healthy	External datasets relating to nutrition	Statistical analysis
	and dietetics
Satisfies kitchen	Internal information on kitchen	Work orchestration
constraints	resources, facilities, and operations	and planning
Satisfies dietary	External datasets relating to types of	Constraint satisfaction
restrictions	restrictions
Carbon footprint	Internal information on supply;	Statistical analysis
	External datasets relating to ingredient
	availability
Personalization to	External datasets relating to ingredient	Chemical compound
disparate tastes	pairings; Interviews with chefs	and olfactory analysis
Profit	Internal information on marketing	Statistical analysis;
	conditions, kitchen resources, facilities	Operations research
	and operations, cost data, and past
	economic data

As an example, suppose that one wants to measure the variety of a set of recipes. In one embodiment, variety may be modeled using graph edit distance. In this case, the recipes are represented as directed acyclic graphs.
FIG. 5, for example, depicts two exemplary recipes modeled as directed acyclic graphs. In each instance, the graph representation G of the recipe includes vertices V representing ingredients or steps, edges E representing relationships between the vertices, and labels L that identify the specific ingredient or step represented by each vertex.
Several graph editing operations may be defined, including one or more of the following: substituting a vertex label, deleting a vertex, inserting a vertex, deleting an edge, and inserting an edge. The graph edit distance d(G₁, G₂) is then defined between the labeled graphs G₁and G₂as the minimum number of edits needed to convert G₁into G₂. In one embodiment, then, the variety of several graphs is defined as the variance of the pairwise edit distances among the graphs. Other measures of variety may include the standard deviation, mean, or entropy of the graphs, among other metrics.
Alternatively, variety may be modeled using probabilistic analysis (see, e.g., Table 1). One particular probabilistic analysis technique that may be used in this case is topic modeling. In this case, the recipes are considered as documents that can be modeled as probabilistic mixtures, where the ingredients are probabilistically selected from a potential list of “topics” (i.e., combinations of ingredients). Thus, each recipe is a distribution of topics, and the distance between recipes can be measured to generate a measure of variety.
FIG. 6, for example, depicts an exemplary recipe modeled as a Latent Dirichlet Allocation (LDA) topic model. In this instance, one assumes the existence of a corpus of M recipes or “documents.” Document M, illustrated in FIG. 6, contains N words. Those words include ingredients x and topics z, where the topics are sets or combinations of ingredients. For example, an exemplary topic might include the following ingredients: lemon juice, salt, cooking spray, green onions, sour cream, canola oil, Dijon mustard, radishes, pita, and black olives. The parameters α, β, and θ represent parameters of a machine learning model and describe the kinds of topics present in the database 108.
From the topic model, every recipe can be associated with a probability distribution over topics. A menu can then be evaluated for variety based on the distance between the probability distributions over topics for recipes included in the menu. Thus, the variety may be scored quantitatively as:
D(P _T|R ₁ , . . . ,P _T|R _K) (EQN. 1)
Where P_Tis the topic distribution for an associated recipe R₁, . . . , R_K.
As discussed above, once the assessment models have been built, the menu design engine 202 may design a menu. In addition to the assessment models, the menu design engine 202 obtains as input one or more ingredients, one or more flavor profiles/cuisines, and/or one or more other attributes or constraints (e.g., on dietary compliance, cost, or ingredient availability).
In one embodiment, design of a menu may start with a number S of initially selected (e.g., user-specified) ingredients, and then extend the ingredient set to include one or more new (e.g., not user-specified) ingredients. For instance, the user may allow the system 100 to recommend further ingredients beyond the initially selected group of ingredients. In this case, additional ingredients may be recommended based on frequent pairings (i.e., where the additional ingredients are those that are observed by the system 100 to be most frequently paired with one or more of the initially selected ingredients) and/or on common chemical compounds (i.e., where the additional ingredients are those that are observed by the system to share the most or the least chemical compounds with the initially selected ingredients).
Once the set of ingredients has been optionally extended, the menu design engine 202 determines a dish superset (i.e., the set of potential dishes from which the menu may be chosen). In one embodiment, determining the dish superset comprises selecting all dishes that are both: (1) typical of the selected cuisines (e.g., pasta would be typical of Italian cuisine); and (2) contain at least one of the ingredients. In one embodiment, at least one ingredient in the set of initially selected ingredients is maintained in the menu.
Additionally, each dish in the dish superset can be substituted with one or more of: (1) a canonical recipe for that dish (e.g., the most highly rated pizza recipe); (2) all of the recipes for that dish, as long as they contain at least one of the initially selected ingredients; or (3) a recipe for the dish that contains at least one of the initially selected ingredients and is generated using a computational creativity algorithm. There are a variety of computational creativity algorithms that are suitable for use in this context. Substitute recipes may be obtained from the databases 108. The number of dishes contained in the final dish superset may be denoted as M.
Optimization is then employed to select specific dishes from the dish superset in order to generate a menu. In one embodiment, selection of specific dishes is formulated as an optimization model that optimizes a weighted linear function of scores for three attributes (e.g., novelty, taste, and variety), under constraints such as the availability of ingredients. In this optimization model, the following notation is employed:
i ε {1, . . . , M}: Index for a dish in the superset of dishes (e.g., quiche, pie, etc.)
j ε {1, . . . , N}: Index for ingredient (e.g., chicken, saffron, etc.)
k ε {1, . . . , K}: Index for ingredient category (e.g., vegetable, meat, etc.)
s ε {1, . . . , s}: Index for initially selected ingredient
x_ijε {0,1}∀i, j: Whether ingredient j is in dish i
y_iε {0,1}∀i: Whether dish i is included in the selected menu
w_jkε {0,1}∀i, j: Whether ingredient j is of category type k
B_jε {0,1}∀j: Whether ingredient j is available
L_ik: Lower bound on number of ingredients of category type k in dish i
U_ik: Upper bound on number of ingredients of category type k in dish i
D: Maximum number of dishes in menu
Co_j1: Number of chemical compounds shared by ingredients j and 1
d(G_n): Graph edit distance between recipes for dishes i and 1
Where x_ijand y_iare decision variables, and w_jk, B_j, L_ik, and U_ikare optional variables.
As discussed above, different attributes may be measured in different ways. For instance, the novelty of a menu is the sum of the novelty measures of each dish in the menu. The novelty of a dish can be computed, in one embodiment, by applying a metric such as Bayesian surprise to the ingredients of the dish. In this case, the novelty of the menu, NOV (y₁, . . . , y_M; x₁, . . . , x_N) may be computed as:
$\begin{matrix} NOV (y_{1}, \dots, y_{M}; x_{1}, \dots, x_{N}) = \sum_{i = 1}^{M} y_{i} \cdot f_{NOV} (x_{i 1}, \dots, x_{iN}) & (EQN . 2) \end{matrix}$
Where f_NOVis the novelty score for a set of ingredients.
The taste of a menu (i.e., how “good” the taste is) can be computed by considering a known food pairing hypothesis that suggests that pairs of ingredients taste better when the component ingredients share more chemical compounds. In this case, the taste of the menu, TASTE (y₁, . . . , y_M; x₁, . . . , x_N) may be computed as:
$\begin{matrix} TASTE (y_{1}, \dots, y_{M}; x_{1}, \dots, x_{N}) = \sum_{i = 1}^{M} y_{i} (\sum \sum_{j < i}^{} x_{ij} \cdot x_{il} {Co}_{jl}) & (EQN . 3) \end{matrix}$
The variety of a menu can be computed by comparing the graph edit distances between pairs of recipes for dishes in the menu, or by using topic modeling, or by a combination of graph edit distance comparison and topic modeling. For instance, a graph edit distance-based measure may compute the variety of the menu, VAR (y₁, . . . , y_M; x₁, . . . , x_N), as:
$\begin{matrix} VAR (y_{1}, \dots, y_{M}) = \sum \sum_{j < i}^{} y_{i} \cdot y_{l} \cdot d (G_{il}) & (EQN . 4) \end{matrix}$
Where d(G_i1) is the distance between the graphs for recipes i and 1.
The objective function is thus the weighted linear function of the measures for the attributes being balanced. In the exemplary case (i.e., where the attributes being balanced are novelty, variety, and taste), the objective function is:
$\max_{x_{ij} \forall i, j; y_{i} \forall i} ⌊ w_{1} NOV (y_{1_{1}}, \dots, y_{M}; x_{1}, \dots, x_{N}) + w_{2} TASTE (y_{1_{1}}, \dots, y_{M}; x_{1}, \dots, x_{N}) + w_{3} VAR (y_{1}, \dots, y_{M})]$
Such that:
$\begin{matrix} x_{ij} \in {0, 1} \forall i, j y_{i} \in {0, 1} \forall i \max_{i} ⌊ x_{ij} ⌋ \leq B_{j} \forall_{j} (Restriction on ingredient availability) y_{i} = 1 - \prod_{j} (1 - x_{ij}) \forall i (Dishes are in the menu when they contain at least one ingredient) \sum_{i} y_{i} \leq D (Restriction on the total number of dishes) y_{i} \cdot L_{ik} \leq y_{i} \cdot \sum_{j} (x_{ij} \cdot w_{jk}) \leq y_{i} \cdot U_{ik} \forall i, k (Restrictions on the number of ingredients in each category for the selected dishes) \prod_{i, s} (1 - x_{is}) = 0 (At least one of the initially selected ingredients should be in a dish in the menu) & (EQN . 5) \end{matrix}$
Once the menu has been designed (i.e., the dishes comprising the menu have been selected), the menu planning engine 204 creates a work plan for preparing the menu. As discussed above, the work plan is a schedule of tasks for joint preparation of the recipes for all dishes constituting the menu, based on available resources and facilities.
In one embodiment, the menu planning engine 204 takes as inputs directed acyclic graphs representing all of the recipes required to prepare the menu. The menu planning engine 204 produces as an output the work plan, while determining if the menu can be prepared within any given time constraints.
FIG. 7 is a diagram depicting conversion of an exemplary menu into an exemplary work plan, in which the recipes comprising the menu are represented as directed acyclic graphs. The directed acyclic graphs represent the menus as mathematical formalisms. In particular, the vertices of the graphs represent actions to be taken by different people or equipment (e.g., boil water, slice vegetables, bake potatoes, etc.). The edges connecting the vertices represent the sequences in which the actions are to be taken (e.g., the water should be boiled before the pasta is put in the water), and the edges are annotated with timing constraints that set limits on the maximum amount of time that may elapse between sequential actions (e.g., no more than eight minutes should elapse between putting the pasta in the boiling water and removing the pasta from the boiling water). Given such a graph for each recipe in the menu (illustrated on the left side of FIG. 7), and a list of available resources (e.g., people and/or equipment), the menu planning engine 204 produces a plan (illustrated on the right side of FIG. 7) for the individual resources to prepare the menu (and other summaries, such as the total time required). For instance, the plan may assign specific actions in the directed acyclic graphs to specific individuals who are available to prepare the menu (e.g., John will slice the vegetables). FIG. 8, for example, depicts an exemplary detailed work plan in which tasks are scheduled on a common timeline and allocated to specific individuals or equipment for completion.
FIG. 9 is a flow diagram illustrating the high level method 900 for planning a menu, according to embodiments of the present disclosure. The method 900 may be performed, for example, by the application server 106 illustrated in FIGS. 1 and 2 and described in detail above. However, it will be appreciated that the method 900 is not limited to implementation on the application server 106; in alternate embodiments, the method 900 may be performed by other devices or systems, including the endpoint devices 102 or a general purpose computing device that is configured as a special purpose computing device.
The method 900 begins in step 902. In step 904, the assessment modeling engine 200 gathers data from one or more sources. As discussed above, the gathered data may include one or more of the following types of data: recipes, chef expert opinions, or management interviews. Any one or more of these types of data may be obtained from one of the databases 108, or from an external database.
In step 906, the assessment modeling engine 200 builds one or more models in accordance with the data gathered in step 904. As discussed above, the models are build to help assess menu attributes, such as novelty, variety, nutrition, or the like. For instance, the assessment modeling engine 200 may use one or more of the modeling techniques listed in Table 1 (above) to build models using the gathered data.
In step 908, the menu design engine 202 obtains a plurality of inputs. As discussed above, the inputs obtained by the menu design engine 202 may include one or more of the following: one or more user-specified cuisines (e.g., Indian, holiday, etc.), one or more user-specified ingredients (e.g., chicken, eggs, etc.), one or more user-specified desired attributes (e.g., novelty, variety, etc.), or one or more user-specified constraints (e.g., no more than x calories, no gluten, etc.). In one embodiment, any one or more of the user-specified inputs may be provided using one or more of the endpoint devices 102.
In optional step 910 (illustrated in phantom), the menu design engine 202 extends the ingredient set. As discussed above, the ingredient set may be extended by adding new ingredients that pair well in the menu (but not necessarily in the same recipe) with user-specified ingredients obtained in step 908. In one embodiment, the menu design engine 202 consults a database of recipes (e.g., one of the databases 108) for information on pairing of ingredients. Alternatively or in addition, the menu design engine 202 may evaluate taste metrics (e.g., sharing of chemical compounds) for ingredient pairs.
In step 912, the menu design engine 202 determines a dish superset. As discussed above, the dish superset comprises a set of all potential dishes from which the menu may be selected. The dish superset may be constructed by performing standard database queries (e.g., to the databases 108) that identify all dishes in the database that correspond to user-specified cuisines and contain at least one of the ingredients in the (optionally extended) ingredient set.
In step 914, the menu design engine 202 determines the menu in accordance with the dish superset. That is, the menu design engine 202 selects one or more of the dishes in the dish superset for inclusion in the menu. In one embodiment, dishes are selected from the dish superset in accordance with an optimization technique that finds a set of dishes that “fit together” (e.g., based on a weighted function of user-specified attributes, subject to user-specified constraints). For instance, dishes may be selected from the dish superset by considering the optimization problem detailed in EQNs. 1-5, above.
In step 916, the menu planning engine 204 designs a work plan in accordance with the menu designed in step 914 and the available resources and facilities. That is, the menu planning engine 204 plans a detailed schedule of tasks to be performed, concurrently, by the available people and equipment in order to produce the menu within a specified period of time. As discussed above in connection with FIG. 7-8, designing the work plan may involve representing each recipe in the menu as a directed acyclic graph and then implanting bipartite matching in the individual stages of the recipes.
In step 918, the menu planning engine 204 outputs the work plan (e.g., to one or more of the endpoint devices 102). The method 900 then ends in step 920.
FIG. 10 depicts a high-level block diagram of a general-purpose computer suitable for use in performing the functions described herein. As depicted in FIG. 10, the system 1000 comprises a hardware processor element 1002 (e.g., a central processing unit (CPU), a microprocessor, or a multi-core processor), a memory 1004, e.g., random access memory (RAM) and/or read only memory (ROM), a module 1005 for planning a menu and/or work plan, and various input/output devices 1006 (e.g., storage devices, including but not limited to, a tape drive, a floppy drive, a hard disk drive or a compact disk drive, a receiver, a transmitter, a speaker, a display, a speech synthesizer, an output port, an input port and a user input device (such as a keyboard, a keypad, a mouse, a microphone and the like)). Although only one processor element is shown, it should be noted that the general-purpose computer may employ a plurality of processor elements. Furthermore, although only one general-purpose computer is shown in the figure, if the method(s) as discussed above is implemented in a distributed manner for a particular illustrative example, i.e., the steps of the above method(s) or the entire method(s) are implemented across multiple general-purpose computers, then the general-purpose computer of this figure is intended to represent each of those multiple general-purpose computers.
It should be noted that the present disclosure can be implemented in software and/or in a combination of software and hardware, e.g., using application specific integrated circuits (ASIC), a general purpose computer or any other hardware equivalents, e.g., computer readable instructions pertaining to the respective systems and/or methods discussed above can be used to configure a hardware processor to perform the steps functions and/or operations of the above disclosed systems and methods. In one embodiment, instructions and data for the present module or process 1005 for planning a menu and/or work plan (e.g., a software program comprising computer-executable instructions) can be loaded into memory 1004 and executed by hardware processor element 1002 to implement the steps, functions or operations as discussed above in connection with the exemplary systems 100 and 106 and/or method 900. The processor executing the computer readable or software instructions relating to the above described method(s) can be perceived as a programmed processor or a specialized processor. As such, the present module 1005 for planning a menu and/or work plan (including associated data structures) of the present disclosure can be stored on a tangible or physical (broadly non-transitory) computer-readable storage device or medium, e.g., volatile memory, non-volatile memory, ROM memory, RAM memory, magnetic or optical drive, device or diskette and the like. More specifically, the computer-readable storage device may comprise any physical devices that provide the ability to store information such as data and/or instructions to be accessed by a processor or a computing device such as a computer or an application server. In addition, it should be noted that the hardware processor can be configured or programmed to cause other devices to perform one or more operations as discussed above. In other words, the hardware processor may serve the function of a central controller directing other devices to perform the one or more operations as discussed above.
Referring to FIG. 10, the present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional 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, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention 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 invention. 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.
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, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The 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 to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart 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 invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

What is claimed is:

1. A method for designing and planning a menu, wherein the menu comprises a plurality of dishes, and each dish in the plurality of dishes comprises a set of ingredients prepared according to a recipe, the method comprising:

obtaining, by a processor, a user-specified ingredient that must be included in the menu;

obtaining, by the processor, a user-specified criterion that must be satisfied by the menu;

automatically formulating, by the processor, an optimization problem that evaluates a plurality of potential dishes for inclusion in the menu by optimizing over the user-specified criterion; and

automatically selecting, by the processor, the plurality of dishes from among the plurality of potential dishes, wherein the automatically selecting is performed based at least in part on a solution to the optimization problem, and wherein at least one dish in the plurality of dishes includes the user-specified ingredient.

2. The method of claim 1, wherein the user-specified criterion is a type of cuisine that must be included in the menu.

3. The method of claim 1, wherein the user-specified criterion is an attribute that must be maximized in the menu.

4. The method of claim 3, wherein the attribute is novelty of the menu.

5. The method of claim 3, wherein the attribute is variety of the menu.

6. The method of claim 1, wherein the plurality of potential dishes includes dishes that satisfy the user-specified criterion and contain the user-specified ingredient.

7. The method of claim 1, wherein the optimization problem comprises a weighted linear function of scores including a score for the user-specified criterion.

8. The method of claim 7, wherein the optimization problem additionally attempts to satisfy a constraint on the menu.

9. The method of claim 8, wherein the constraint is user-specified.

10. The method of claim 9, wherein the constraint relates to a nutritional requirement of the menu.

11. The method of claim 8, wherein the constraint is an availability of a resource required to prepare the menu.

12. The method of claim 7, wherein at least the score for the user-specified criterion is generated in accordance with an assessment model.

13. The method of claim 12, wherein the assessment model is built using data from a plurality of recipes.

14. The method of claim 12, wherein the assessment model is built using data from a plurality of expert opinions relating at least to the user-specified criterion.

15. The method of claim 12, wherein the assessment model is built using data from a plurality of interviews relating at least to resource and facility availability.

16. The method of claim 1, further comprising:

automatically designing, by the processor, a work plan, wherein the work plan specifies a schedule of tasks for preparation of the menu.

17. The method of claim 16, wherein the work plan accounts for resources and facilities available for use in the preparation of the menu.

18. The method of claim 1, wherein the work plan accounts for a time constraint on the preparation of the menu.

19. A device for designing and planning a menu, wherein the menu comprises a plurality of dishes, and each dish in the plurality of dishes comprises a set of ingredients prepared according to a recipe, the device comprising:

a processor; and

a computer-readable medium storing instructions which, when executed by the processor, cause the processor to perform operations, the operations comprising:

obtaining a user-specified ingredient that must be included in the menu;

obtaining a user-specified criterion that must be satisfied by the menu;

automatically formulating an optimization problem that evaluates a plurality of potential dishes for inclusion in the menu by optimizing over the user-specified criterion; and

automatically selecting the plurality of dishes from among the plurality of potential dishes, wherein the automatically selecting is performed based at least in part on a solution to the optimization problem, and wherein at least one dish in the plurality of dishes includes the user-specified ingredient.

20. A system for designing and planning a menu, wherein the menu comprises a plurality of dishes, and each dish in the plurality of dishes comprises a set of ingredients prepared according to a recipe, the system comprising:

a database storing recipes for a plurality of potential dishes; and

an application server for automatically selecting the plurality of dishes from among the plurality of potential dishes, wherein the automatically selecting is performed by automatically evaluating the plurality of dishes by optimizing over a user-specified criterion, wherein the plurality of dishes includes at least one dish that includes a user-specified ingredient.