JP6262923B1 - Information processing apparatus, information processing method, and program - Google Patents

Abstract

The ingredients are distributed to the user's multiple meals, and various recipes can be proposed to the user each time. Therefore, information on ingredients satisfying a predetermined condition is acquired from a storage device that stores the storage history of the ingredients, the period in which the ingredients are added is determined, and the number of recipe provisions is specified based on the determined period. Then, each ingredient included in the obtained ingredient information is sorted, and the number of ingredient groups corresponding to the number of times the recipe is provided is set. For each food group, a recipe is specified based on the assigned food, and recipe presentation control is performed. In this case, the ingredients are distributed so that the number of recipes or the types of dishes specified for each ingredient group satisfy a predetermined quantity condition.

Description

  The present invention relates to an information processing apparatus, an information processing method, and a program, and more particularly to a technical field relating to a process of presenting a recipe to a user.

JP 2006-277410 A JP 2003-30753 A

There is known a service for providing recipes of dishes accumulated by posting by a general user (recipe provider).
Patent Document 1 describes a technique for providing a recipe that can be created by replacing some ingredients used in a recipe with alternative ingredients based on the ingredients at hand input by the user.
In Patent Literature 2, food is allocated from the inventory managed according to the ordered menu, and when the food is insufficient, the shortage is notified, or the alternative menu using the alternative food is searched. The technology to be provided is described.

By the way, for example, when assuming a user (recipe user) who wants to read a recipe in a general home, if the ingredients at hand are used up in one meal, the ingredients used for the meal on the next day will be insufficient, Even if a certain amount of ingredients remain, the types of recipes that can be cooked are remarkably limited, making it difficult to provide sufficient variation options that can be selected for the user viewing the recipe. .
This is because the number of recipes that can be cooked decreases as the amount of ingredients decreases.

Further, for example, it is more efficient for the user to purchase foods once a week or in conjunction with special sales, etc., and it is troublesome for the user to replenish foods that are insufficient every day.
In addition, as a user's style for purchasing ingredients, more and more people are making bulk purchases by cooperatives, grocery delivery services, bulk purchases via the Internet, and large-scale purchases once a week. Many people do not have the lifestyle of going shopping.
For these people, the amount of stored ingredients gradually decreases for a certain period until the next food purchase, but the ingredients can be distributed and used well in those days, and each day It is hoped that a recipe with sufficient options will be provided.

The technology described in Patent Document 1 is “providing a recipe that can be created by replacing some ingredients used in a recipe with substitute ingredients based on ingredients input by the user”, and depending on the provided recipe It is not considered whether there are enough recipe options that can be provided by the remaining ingredients, excluding the ingredients used.
The technology described in Patent Document 2 is “allocation of ingredients from inventory managed according to the ordered menu, and search for and provide an alternative menu using alternative ingredients when there is a shortage of ingredients”. Yes, it is not considered whether there are enough recipe options that can be provided by the remaining ingredients except for the ingredients used by the provided recipe.

  Therefore, the present invention realizes a recipe providing service that can secure a sufficient quantity of recipe options with the ingredients from the next day while suppressing the frequency of procurement of the ingredients.

An information processing apparatus according to the present invention is determined based on a food material information acquisition unit that acquires food information including at least inventory information from a storage device that stores a food storage history, and a storage history stored in the storage device. Based on the information on the acquired ingredients and the specified number of times of providing the recipe, each ingredient included in the information on the ingredients is determined based on the number of times of providing the recipe according to the cycle in which the ingredients are added. , A food material group setting unit that distributes the number of food groups according to the number of times the recipe is provided, a recipe specifying unit that specifies a recipe based on the distributed food material for each food material group, and a specific food material group And a presentation control unit that performs presentation control of the recipe. And the said foodstuff group setting part distributes a foodstuff so that the number of recipes or cooking classification which the said recipe specific | specification part specifies about each said foodstuff group may satisfy | fill predetermined quantity conditions.
For example, it is assumed that a user purchases foods once a week. The purchased ingredients are distributed according to the number of times the recipe is provided (for example, seven times for daily dinner for a week), and an ingredient group is set. And the recipe which can be cooked with the foodstuff in the foodstuff group for every foodstuff group is specified. Then, several recipes are presented to the user (recipe user) for each ingredient group, that is, for each daily dinner.
The storage history is information such as the added amount, added date / time, used amount, and used date / time for each food.

In the information processing apparatus described above, the food group setting unit acquires information indicating versatility for each of the ingredients included in the acquired information on the food, and the value indicated by the acquired information indicating the versatility is relative. It is conceivable to set a food group so that expensive food can be distributed to different food groups.
A highly versatile food is a food used in a larger number of recipes. When only a highly versatile ingredient is collected in a certain ingredient group, the number of corresponding recipes increases for that ingredient group, but it is assumed that the number of corresponding recipes decreases in other ingredient groups. Therefore, foods having high versatility are prevented from being concentrated on a certain food material group.

In the information processing apparatus described above, the food material group setting unit assigns food materials to each food material group in units of quantities, and sets the food material groups. It is possible to reset the amount of ingredients distributed to the group.
It is not always necessary to distribute all the ingredients to one ingredient group. Therefore, sort according to the amount.
If one food is distributed for each specific amount, the number of corresponding recipes may be extremely reduced in some cases. Therefore, the amount to be distributed is adjusted and reset so as to satisfy the quantity condition.

In the information processing apparatus described above, after acquiring the recipe corresponding to each food group, when acquiring information on the food that can be added, the food group setting unit reassigns the food, and the recipe specifying unit It is conceivable that an additional recipe is specified in the reallocation state, and the presentation control unit performs recipe presentation control in a state where the additional recipe is added.
For example, the first presentation presents a recipe that can be cooked with ingredients that are the first food group. However, surplus ingredients are generated depending on which recipe is selected and cooked by the user as a recipe user. Therefore, at the time of presentation for the second time and thereafter, after surplus ingredients are distributed to the remaining ingredient groups, recipes that can be cooked are specified and presented as additional recipes.
For example, when an ingredient is added after assigning ingredients for one week and specifying a recipe, as a subsequent recipe presentation, a recipe reflecting the additional ingredients is additionally presented.

In the information processing apparatus described above, the quantity condition for the number of recipes specified for each ingredient group or the deviation of the number of cooking types in the recipe specified for each ingredient group is set according to the number of ingredient groups. It is possible.
That is, it is a condition that the number of corresponding recipes and the number of types of dishes are about the same for each ingredient group. The range determined to be the same degree corresponds to the number of food groups.

In the information processing apparatus described above, the quantity condition as the minimum value of the number of recipes specified for each ingredient group or the number of cooking types in the recipe specified for each ingredient group is set according to the number of ingredient groups. It can be considered.
In other words, the condition is that the number of recipes corresponding to each food group and the number of types of recipes are equal to or greater than a predetermined minimum value for any food group. In this case, the minimum value depends on the number of food groups.

The information processing method according to the present invention is determined based on a food material information acquisition step of acquiring food information including at least inventory information from a storage device storing food storage history, and a storage history stored in the storage device. The number of times of providing the recipe according to the period in which the ingredients are added, and the number of steps included in the information of the ingredients based on the information on the acquired ingredients and the specified number of times of providing the recipes. , An ingredient group setting step for assigning to the number of ingredient groups according to the number of times the recipe is provided, a recipe specifying step for specifying a recipe based on the assigned ingredients for each ingredient group, and an ingredient group specified for each ingredient group A presentation control step for controlling the presentation of the recipe. In the food group setting step, the foodstuffs are distributed so that the number of recipes or the type of recipe specified for each food group in the recipe specifying step satisfies a predetermined quantity condition.
By this information processing method, a rich recipe can be provided by the information processing apparatus.
The program according to the present invention is a program that causes an information processing apparatus to execute a procedure corresponding to each of the above steps. This implements the processing of the information processing apparatus described above.

  ADVANTAGE OF THE INVENTION According to this invention, according to the purchase style which suppressed the user's food procurement frequency, the enriched recipe provision which has sufficient choices can be performed every time a recipe is provided several times.

It is explanatory drawing of the system configuration | structure of embodiment of this invention. It is explanatory drawing of a function structure of the recipe management server of embodiment. It is a block diagram of the information processor of an embodiment. It is explanatory drawing of the recipe database of embodiment. It is explanatory drawing of the storage history database and foodstuff database of embodiment. It is explanatory drawing of the presentation setting database of embodiment. It is a flowchart of the process regarding the provision of a recipe of an embodiment. It is explanatory drawing of the example of the recipe shown in embodiment. It is explanatory drawing of the recipe presentation example of embodiment. It is a flowchart of the batch process for the presentation setting of embodiment. It is a flowchart of the presentation setting process of 1st Embodiment. It is explanatory drawing of the distribution unit setting of the foodstuff of embodiment. It is explanatory drawing of the foodstuff distribution to the foodstuff group of embodiment. It is a flowchart of the foodstuff distribution process of embodiment. It is a flowchart of quantity condition check processing of an embodiment. It is a flowchart of quantity condition check processing of an embodiment. It is a flowchart of the process of the recipe management server of embodiment. It is a flowchart of the presentation setting process of 2nd Embodiment. It is a flowchart of the batch process for the presentation setting of 3rd Embodiment. It is a flowchart of the re-presentation setting process of 3rd Embodiment.

Hereinafter, embodiments will be described in the following order.
<1. Overall configuration>
<2. Hardware configuration>
<3. DB>
<4. Flow of processing between terminal and server>
<5. First Embodiment>
<6. Second Embodiment>
<7. Third Embodiment>
<8. Summary>
<9. Program and Storage Medium>

<1. Overall configuration>
The overall system configuration in the embodiment will be described with reference to FIG. The system of the embodiment is a system that realizes a service that provides a user with a cooking recipe (hereinafter simply referred to as a recipe).
In the system of this example, as shown in FIG. 1, a recipe management server 1, a user terminal 3, and an EC (electronic commerce) server 4 are connected via a communication network 2 in a state where they can communicate with each other. .
The recipe management server 1 can access a recipe database 50, a user database 51, a search database 52, a storage history database 53, an ingredient database 55, and a presentation setting database 56.
The EC server 4 can access a user database 51, a storage history database 53, and a product database 54.
Further, as shown as a storage history database 53A, a storage history database may be constructed in the user terminal 3, and the recipe management server 1 may acquire information on the storage history database 53A from the user terminal 3. In the following description, the process in which access to the storage history database 53 occurs may be considered as a process for the storage history database 53A.
Hereinafter, “database” is referred to as “DB”.

The recipe management server 1 is an information processing apparatus that manages a recipe posted by a user (recipe provider) and performs a process of providing a recipe in response to a request from the user (displayed on the user terminal 3). A specific configuration will be described later.
This recipe management server 1 corresponds to an embodiment of an information processing apparatus according to the claims of the present invention.

The configuration of the communication network 2 is not particularly limited. For example, the Internet, an intranet, an extranet, a LAN (Local Area Network), a CATV (Community Antenna TeleVision) communication network, a VPN (Virtual Private Network), A telephone line network, a mobile communication network, a satellite communication network, etc. are assumed.
Various examples of transmission media constituting all or part of the communication network 2 are also envisaged. For example, IEEE (Institute of Electrical and Electronics Engineers) 1394, USB (Universal Serial Bus), power line carrier, telephone line, etc., infrared such as IrDA (Infrared Data Association), Bluetooth (registered trademark), 802.11 wireless It can also be used wirelessly, such as mobile phone networks, satellite lines, and digital terrestrial networks.

The user terminal 3 is a terminal used by a user (recipe provider) who submits a recipe to the recipe management server 1 or a user (recipe user) who searches and browses recipe information managed by the recipe management server 1.
The “user” who uses the service of the present embodiment can be either a recipe provider or a recipe user. However, unless otherwise specified, the “user” is a user who acts as a recipe user. Or a user who has the possibility of becoming a recipe user.

  In the user terminal 3, various transmission / reception processes and display processes are executed as necessary. The user terminal 3 is, for example, a PC (Personal Computer), a feature phone, a PDA (Personal Digital Assistant) having a communication function, or a smart device such as a smartphone or a tablet terminal.

The EC server 4 is an information processing apparatus that provides various services related to merchandise transactions. Examples of the various services include a product search service for searching for and displaying a product desired by a user from a product group handled in electronic commerce, and a product management service for managing a product that a product provider wants to sell. In addition, for example, a user information management service that manages user information and presents it as necessary, a product provider information management service that manages information of a product provider and presents it as necessary, There are also payment processing services that mediate the exchange of payments.
The EC server 4 performs processing for generating and transmitting web page data for realizing various services to the user terminal 3.
Further, the EC server 4 performs a process of transmitting various information to the recipe management server 1 in response to a request from the recipe management server 1.
Further, the EC server 4 updates the storage history DB 53 according to the purchase information of the user's food.

FIG. 2 shows a functional configuration as a recipe management server 1 configured by one or a plurality of information processing apparatuses, and a DB accessed by the recipe management server 1.
The recipe management server 1 includes an ingredient information acquisition unit 1a, an offer count identification unit 1b, an ingredient group setting unit 1c, a recipe identification unit 1d, a presentation control unit 1e, and a recipe management unit 1f.
In addition, each function as the foodstuff information acquisition part 1a, the provision frequency | count identification part 1b, the foodstuff group setting part 1c, the recipe specification part 1d, the presentation control part 1e, and the recipe management part 1f is CPU (for example, FIG. 3 mentioned later) in information processing apparatus. This function is realized by processing executed according to a program in the CPU 101). However, all or a part of the processing described below may be realized by hardware.
Further, when each function is realized by software, each function need not be realized by an independent program. Processing of a plurality of functions may be executed by one program, or one function may be realized by cooperation of a plurality of program modules.

The recipe management unit 1f is a function for performing information management necessary as a recipe providing service.
For example, the recipe management unit 1f registers the recipe DB 50 for the recipe posted by the recipe provider, and manages the registered recipe in association with the category information to which the recipe belongs, the food material information used for the recipe, and the like. Specifically, a recipe of “vegetable curry” posted by a recipe provider is a recipe that belongs to the cooking type “curry”, and the ingredients used are “potato”, “carrot”, “onion”, “broccoli” ”,“ Tomato ”,“ Spinach ”.

Note that the category level is set in a plurality of stages as the dish type. For example, types such as “Japanese”, “Western”, “Japanese”, “Chinese”, “Italian”, “French”, “Thai”, “Curry”, “Hamburg”, “Ramen”, etc. Depending on the type of level, there are further types such as “Beef Curry”, “Chicken Curry”, and “Kima Curry”.
In the following description, for the sake of explanation, it is only an example, but it is assumed that the level of the dish type (classification hierarchy) is set as follows.
Major classification level: Levels by region such as “Japanese cuisine” and “Chinese cuisine” Medium classification level: Level of dish name units such as “Curry” and “Hamburg” Subclassification level: Cuisine such as “Beef curry” and “Chicken curry” Detailed Level in Name The recipe management unit 1f also performs type management at each level for each recipe.

There are various types of dishes, for example, as shown in the following (A), the middle classification may be a classification of main ingredients such as meat dishes, fish dishes, and vegetable dishes, or as shown in (B) below. The major classification may be “main staple”, “side dish”, “side dish”, and the like.
(A) Major classification: Japanese food (Others: Western food, etc.)
Middle classification: Meat dishes
Subcategory: Meat potato / beef simmered
Middle classification: Fish dishes
Subcategory: Miso-boiled crab
Middle classification: Vegetable dishes
Subcategory: Roasted baked vegetables / Kinpira burdock, etc. (B) Large category: staple food (others: side dishes / side dishes, etc.)
Middle classification: Meat dishes
Subcategory: Hamburger / croquette etc.
Middle classification: Fish dishes
Subcategory: Octopus frit / Tara Meuniere, etc.
Middle classification: Vegetable dishes
Subcategory: Potov / Vegetable vegetable tomato

Moreover, the recipe management part 1f manages the number of the recipes in which the foodstuff is used for every foodstuff. For example, for all registered recipes, the number of recipes used for each ingredient is counted and registered in the ingredient DB 55 for management.
Moreover, the recipe management part 1f manages the normal food material with high use frequency for every category (dish type), for example. Specifically, for the category of “curry and rice”, “potato”, “carrot”, “onion”, “beef”, “pork”, and “chicken” that frequently appear in the ingredients used in recipes belonging to the category. Usually set as an ingredient. In addition to foodstuffs, seasonings (such as “salt” and “pepper”) and the like (such as “carrero”) may be set as normal foodstuffs.
Moreover, the recipe management part 1f manages the foodstuffs which are easy to be combined and used for every foodstuff. For example, when there are many examples where “potato” and “carrot” are used at the same time in various recipes, “potato” and “carrot” are managed as easy-to-combine ingredients.

  Moreover, the recipe management part 1f manages the creation report posted for every recipe. The created report is a report describing the deliciousness and ease of cooking that the user feels when cooking using the recipe. The creation report is associated with each recipe in the recipe DB 50 and managed.

The food material information acquisition unit 1a performs processing for acquiring food material information satisfying a predetermined condition from the storage history DB 53 that is a storage device that stores the storage history of food materials.
Although the storage history DB 53 will be described later, this is information in which information on the ingredients purchased for each user and information on the ingredients used are registered.
The food material information acquisition unit 1a acquires information in the storage history DB 53 for each user or a specific user at a predetermined timing. The recipe management server 1 performs the process for recipe presentation setting mentioned later based on the information of the foodstuff which the foodstuff information acquisition part 1a acquires.
In particular, the food material information acquisition unit 1a confirms the user's food stock from the contents of the storage history DB 53 in accordance with the user's food purchase, and satisfies the predetermined condition (for example, the condition related to the stock amount and the expiration date). Get information about.

  The provision number specifying unit 1b performs a process of determining a period in which a specific user's food is added based on the storage history stored in the storage history DB 53, and specifying a recipe provision number based on the determined period. It is.

  The ingredient group setting unit 1c acquires the information on the ingredients acquired by the ingredient information acquisition unit 1a, in this case, among the ingredients (stock ingredients) currently owned by a specific user, for example, according to the conditions relating to the inventory amount and the expiration date This is a function of performing processing for distributing each food material using information on the type and amount of the food material and setting the number of food material groups according to the number of times the recipe is provided.

  The recipe specifying unit 1d is a function that performs a process of specifying a recipe based on the assigned ingredients for each ingredient group set by the ingredient group setting unit 1c. That is, for each ingredient group, a recipe that can be cooked with ingredients assigned to the group is searched from recipes registered in the recipe DB 50. And the corresponding recipe is identified about each foodstuff group, and it manages as a recipe shown to the user. The identified recipe is managed using the presentation setting DB 56.

The presentation control unit 1e performs presentation control so that the recipe specified by the recipe specifying unit 1d is presented on the user terminal 3.
Specifically, when a certain user logs in to the recipe providing service website, web page data for displaying a list of recipes recommended for the user is generated, transmitted to the user terminal 3 and presented. So that
As will be described later, the food group setting unit 1c and the recipe specifying unit 1d set the above-described food groups corresponding to a plurality of meals (cooking opportunities) for the target user, and correspond to each food group. Identify one or more recipes. The presentation control unit 1e performs presentation control so as to recommend a corresponding recipe in response to a user login.
In addition, the presentation control unit 1c executes processing for transmitting various web page data corresponding to the user's operation. Examples of various web page data include web page data on a login screen, web page data on a recipe detail page, and web page data on a creation report posting page.
The data of these web pages is a structured document file such as HTML (Hyper Text Markup Language) or XHTML (Extensible HyperText Markup Language). The structured document file describes recipe names, ingredients used, image data such as text data and cooking images as cooking procedures, and their arrangement and display mode (character color, font, size, decoration, etc.). Yes.

In addition, the recipe management server 1 is provided with various units necessary for realizing a function of transmitting and receiving various types of information and an authentication process for a user login operation. The authentication process is a process for collating the user ID (Identification) and password as login information transmitted from the user terminal 3 with the authentication information stored in the user DB 51.

<2. Hardware configuration>
FIG. 3 shows the recipe management server 1, user terminal 3, and EC server 4 hardware shown in FIG. It is a figure which illustrates hardware.
A CPU (Central Processing Unit) 101 of a computer device in each server, terminal, or DB is loaded into a RAM (Random Access Memory) 103 from a program stored in a ROM (Read Only Memory) 102 or a storage unit 108. Various processes are executed according to the program. The RAM 103 also appropriately stores data necessary for the CPU 101 to execute various processes.

The CPU 101, ROM 102, and RAM 103 are connected to each other via a bus 104. An input / output interface 105 is also connected to the bus 104.
An input unit 106, an output unit 107, a storage unit 108, and a communication unit 109 are connected to the input / output interface 105.
The input unit 106 includes a keyboard, a mouse, a touch panel, and the like.
The output unit 107 includes a display made up of an LCD (Liquid Crystal Display), a CRT (Cathode Ray Tube), an organic EL (Electroluminescence) panel, etc., and a speaker.
The storage unit 108 includes an HDD (Hard Disk Drive), a flash memory device, or the like.
A communication unit 109 performs communication processing and communication between devices via the network 1.
A media drive 110 is also connected to the input / output interface 105 as necessary, and a removable medium 111 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory is appropriately mounted, and information can be written to the removable medium 111. Reading is performed.

In such a computer device, data and programs are uploaded and downloaded by communication by the communication unit 109. Data and programs can be exchanged via the removable medium 111.
When the CPU 101 performs processing operations based on various programs, necessary information processing and communication as the recipe management server 1, the user terminal 3, the EC server 4, and the like are executed.
In addition, the information processing apparatus which comprises the recipe management server 1 grade | etc., Is not restricted to a single computer apparatus as shown in FIG. 3, and a plurality of computer apparatuses may be systematized. The plurality of computer devices may be systemized by a LAN or the like, or may be arranged at a remote place by a VPN using the Internet or the like.

<3. DB>
Each DB will be described.
The recipe DB 50 is a DB that stores information on recipes posted from recipe providers. Specifically, as shown in FIG. 4, for a recipe ID that can identify each recipe, a user ID that identifies the recipe provider who posted the recipe, post date information, and a category (cooking) to which the recipe belongs. Type) information, recipe ingredients information, recipe cooking procedures, image information such as cooking images (completed cooking images and cooking images), and the actual use of the recipe (create a dish) And a creation report ID for identifying a creation report posted by another user is stored in association with each other.
Further, URL (Uniform Resource Locator) information of the recipe details page may be stored in association with the recipe ID.

  Further, the recipe DB 50 stores information on creation reports posted for each recipe. As the information of the created report, text data indicating the report content, a user ID that can identify the poster, posting date information, and the like are stored.

The user DB 51 is a DB that stores user login information. Specifically, a user ID that can identify each user and a login password are stored in association with each other. Various history information such as login history may be stored.
The user DB 51 stores purchase history information for each user. For example, history information when various foods are purchased by electronic commerce is accumulated.
The user DB 51 also stores recipe browsing history, recipe posting history, and the like for each user.

The search DB 52 is a DB that stores search results corresponding to search keywords. Specifically, multiple recipes are linked and stored as search results according to search keywords such as dish names such as “curry” and “hamburg” and ingredient names such as “mushroom” and “tomato”. .
For example, a search process is executed in response to a user search request, and the search result extracted as a result is stored in the search DB 52 in association with a search keyword. By performing the association in this way, there is an increased chance of not performing a new search process when a search request is made.
Note that a search process using a search keyword may be periodically performed in advance, and the search result extracted as a result may be associated with the search keyword and stored in the search DB 52.

The storage history DB 53 (or 53A) is a DB that stores the purchase history and the use history of ingredients for each user.
An example is shown in FIG. 5A. For example, as illustrated for a user whose user ID is “U001”, purchase history and usage history are stored for each ingredient such as “potato”, “onion”, “carrot”, etc. for one user. ing. For example, purchase and usage information is added as information for each data number.
As purchase data, an addition date and time and an additional amount are stored.
The usage date and time and usage amount are stored as usage data.
The storage history DB 53 constructed on the server side stores the purchase history and usage history in this way for each user, for example, “U001”, “U002”, “U003”... . Each user is, for example, a user who can register and log in to the recipe providing service.
When the storage history DB 53A is configured in the user terminal 3, the purchase history and the use history are stored only for a certain user who is a user of the user terminal 3, and the recipe management server 1 can refer to it. That's fine.

Data is added to the storage history DB 53 by the recipe management server 1 and the EC server 4. For example, the EC server 4 adds purchase data in response to acquiring information on the purchase of ingredients among the information of electronic commerce for each user. In particular, in the present embodiment, regular purchase by the user is assumed. For example, if the user purchases regular food in the market provided by the EC server 4, the information is reflected in the storage history DB 53. Can do.
In addition, when the user uses a cooperative or a food delivery service, since purchase history information for each user is managed by those vendors, for example, the recipe management server 1 receives each user's management terminal from the management terminal of the vendor. The food purchase history information may be acquired and the storage history DB 53 may be updated.
Furthermore, when the user is making a purchase at an actual store, the receipt information is read by the reader device connected to the user terminal 3, so that the information on the purchased ingredients can be provided to the recipe management server 1. Further, data of a POS system (Point of sale system) of an actual store may be collected by linking with user member information, for example, and reflected as purchased food information. For example, the recipe management server 1 sequentially registers purchase data acquired by these methods in the storage history DB 53.

Regarding the usage data, it is conceivable to store the usage data based on the estimation of the recipe used by the user. The “use” of the recipe means here that the dish is prepared with reference to the recipe.
For example, when it is estimated that a certain recipe is used, the ingredients and amount used in the recipe are confirmed, and they are registered as a use history.
The following examples can be considered as the recipe estimation method used.
If the user makes a request for a recipe detail page (hereinafter also referred to as “detail page”) once, it is estimated that the detail page used the requested recipe. The recipe detail page is a web page on which ingredients and actual cooking procedures are described. In general, the user selects a recipe from the list of recipes, requests a detailed page, browses, and cooks.
When the user makes a request for a recipe detail page for a plurality of recipes, it is estimated that the recipe related to the last request has been used. In many cases, the user decides a dish (use recipe) to be made after confirming a detailed cooking procedure of each recipe on a plurality of detail pages. Therefore, it can be presumed that the recipe that last viewed the detailed page is determined after confirming various recipes.
-When the user prints a detailed page, it is estimated that the recipe was used. This is because the print is considered to facilitate confirmation of the cooking procedure during actual cooking.
・ If the detailed page viewing time is longer than a certain time, it is estimated that the recipe is used. This is because it is assumed that actual cooking is performed while viewing a detailed page on the screen.
For example, the usage data can be added by estimating the usage recipe by the method described above.
Of course, in addition to the estimation, the user may actually be requested to input the usage recipe, and the usage data may be added accordingly. Further, when the user submits a cooking report or a cooking photo for a certain recipe, the above-described estimation processing may be fixed or corrected.

In any case, the storage history DB 53 may be configured so that the history of the purchase and use of ingredients is registered for each user, and the current user's ingredient inventory can be grasped. Grasping the ingredients inventory does not require strict accuracy, but at least the type and amount of ingredients currently in the user's home need only be roughly known. Of course, it is possible to construct a system for accurately knowing the food stock by linking with a refrigerator, stocker, etc. through network communication.
Note that FIG. 5 shows an example in which additional data and usage data are stored in units of ingredients, but the ingredients name, date and time, and additional amount are stored as additional data without being divided in particular ingredients, and the ingredients are used as usage data. Needless to say, the name, date and time of use, and amount used may be stored sequentially.

  The product DB 54 stores information on various products handled by the EC server 4 in electronic commerce. For example, various types of information such as prices, stocks, product images, and the like for products of each virtual store are registered.

The food DB 55 is a DB that stores information related to food used in the recipe.
Although an example is shown in FIG. 5B, the value which counted how many recipes each foodstuff is used is registered. Ingredients with a large number of recipes are considered to be easily used in various dishes, that is, highly versatile.
Although not shown, the food DB 55 may register information on ingredients that can be easily combined and information on ingredients that are easily used for various types of dishes. Information on ingredients that can be easily combined and information on ingredients that are likely to be used for each type of dish may be generated based on recipes registered in the recipe DB 50. For example, when targeting potatoes, among the registered recipes, the ingredients with the highest number of corresponding recipes are determined as “easy to combine”. Just register. In addition, for information on easy-to-use ingredients, for example, for “curry”, collect recipes whose curry type (medium classification level) is “curry”, and use frequency of each ingredient (use it) The number of recipes) may be confirmed, and the food at the top may be determined as “easy to use”.
Of course, it is not limited to registered recipes, and such information may be generated and registered based on general recognition.

In the presentation setting DB 56, information on the recipe currently being set is registered for each user.
As shown in FIG. 6, setting of n food groups GP1 to GPn (user: U001 is set to n = 7) corresponding to the user ID, information on the food ingredients distributed for each food ingredient group, food ingredient groups Recipe information corresponding to each is registered. Corresponding to each of the food groups GP1 to GP7, date and time information to be presented to the user is also stored.
The presentation setting DB 56 also stores information used to estimate the recipe that the user actually used. For example, information such as browsing history of detailed pages and printing. As an example, the use recipe is estimated based on the estimation information, and the use data of the food is stored in the above-described storage history DB 53 based on the estimated use recipe.
Details of the information stored in the presentation setting DB 56 will be described later.

Each of the above DBs (50 to 56) may be realized in any form as long as the recipe management server 1 or the EC server 4 is accessible. For example, all the DBs (recipe DB 50, user DB 51, search DB 52, storage history DB 53, food DB 55, presentation setting DB 56) may be formed in the storage unit in the same system as the recipe management server 1, or each of these DBs. May be provided in a computer system such as a separate body or a remote place. Of course, each DB does not need to be formed in one device (for example, one HDD). Each DB does not need to be configured as one DB. For example, information stored as the user DB 51 may be stored and managed by a plurality of user DBs (for example, a login user DB and a transaction user DB). Each of the above-described DBs is merely an example of a storage unit for information related to the processing of the embodiment in the form of one DB.

<4. Flow of processing between terminal and server>
An example of the flow of processing executed by the recipe management server 1 and the user terminal 3 will be described with reference to FIG.
Here, in order to receive various services provided by the recipe management server 1, an example will be described in which a user performs a login operation using the user terminal 3 and receives a recipe. The flow of FIG. 7 is merely an example that serves as a model for explanation. Actual processing is not always performed in this order.

In step S101, the user terminal 3 executes a login screen information request process corresponding to a login screen display operation by the user.
When a login screen information request is transmitted from the user terminal 3 to the recipe management server 1 by the login screen information request process, the recipe management server 1 executes a login screen information transmission process in step S201.
Thereby, for example, a web page corresponding to the login screen information (web page data) of the recipe site received from the recipe management server 1 is displayed on the user terminal 3.

  Next, in step S <b> 102, the user terminal 3 executes login information transmission processing for transmitting login information (user ID and login password) according to the user's input operation to the recipe management server 1.

When the login information is transmitted from the user terminal 3 to the recipe management server 1, the recipe management server 1 executes an authentication process in step S202, and executes an authentication result notification process in the subsequent step S203.
Specifically, the recipe management server 1 compares the user ID and password input on the user terminal 3 with information stored in the user DB 51 to determine whether the user can log in, and authenticates the login permission information. As a result, the user terminal 3 is notified.
Note that a series of flows shown in FIG. 7 shows a case where it is determined that login is possible in the authentication processing in step S202. If it is determined in step S202 that login is not possible, the user terminal 3 executes the process of step S102 again, and the recipe management server 1 executes the process of step S202 accordingly.

If the user can be authenticated, the recipe management server 1 proposes a recipe (presents a recommended recipe) to the user. For example, it may be presented as “today's recommended recipe” on the top page of the recipe site. Of course, it may be presented on the web page requested when the user wants to see the recommended recipe, but here, an example of displaying on the top page will be described.
In order to display the top page including such recommended recipe presentation, the recipe management server 1 performs steps S204, S205, and S206.
The recommended recipes here are not recommended recipes for unspecified users, such as generally popular recipes, but are recommended recipes for n times that are specific to the logged-in user and set based on the user's food stock. This is our time.

An outline of recommended recipe presentation settings presented in FIG. 8 will be described.
For example, assume that food information as illustrated can be acquired for a certain user. This is the user's current food stock obtained by referring to the storage history DB 53 for the user. For example, when the user has a lifestyle habit of purchasing foods once a week, the food information may be considered as information indicating the food stock immediately after purchase.
Ingredients F1, F2, F3... Shown as the ingredient information represent specific ingredients. For example, F1 is “pork”, F2 is “beef”, F3 is “potato”, and the like. The food material information includes information on the amount of the food material together with the types of the food materials.
The recipe management server 1 sets n food groups GP1 to GPn (GP7) assuming that this food material information is used for n meals (n = 7 in FIG. 8). “n” for n times is the number of times of cooking with reference to the recipe, and specifically corresponds to n meals. For example, when a user who purchases ingredients once a week prepares a meal for each dinner, n = 7 in the sense of a daily dinner for one week. The value of “n” is set for each user according to the circumstances of the user. For example, it is set based on the purchase cycle of the user that can be grasped from the information in the storage history DB 53.

The food material groups GP1 to GP7 are obtained by sorting food materials acquired as food material information into groups.
As a method of distribution, as one method, it is conceivable to distribute in units of ingredients. For example, it is assumed that one kind of food is assigned to one group. For example, the food F1 is a sorting method that includes all 600 g in one food group.
Moreover, you may distribute for every single unit. For example, when there are three potatoes, the number may be one for the food group GP1 and two for the food group GP2.
Of course, it may be divided by quantity. For example, when there is 400 g of pork, 100 g is assigned to the food group GP1, and 300 g is assigned to the food group GP2.
Moreover, combining these, it is also conceivable that a certain food F1 is divided by a food unit, the food F2 is a single unit, and the food F3 is divided by an amount.
The example of FIG. 8 shows an example in which the ingredients F1, F2,... Indicated by the ingredient information are divided into the ingredient groups GP1 to GP7 after being divided for each unit or amount.

For each of the food material groups GP1 to GP7, recipes that can be cooked with the assigned food materials are searched, and these are specified as recipes corresponding to the food material groups. In the figure, for example, recipes RP1, RP5, RP25, RP31, and RP45 are specified as corresponding recipes of the food group GP1.
In addition, the recipe specified as these corresponding recipes does not need to use up the foodstuff allocated to the foodstuff group, and should just be able to cook with the foodstuff allocated. Therefore, the same recipe may correspond to different food groups. For example, in FIG. 8, the recipe RP1 corresponds to the food material groups GP1 and GP2.

Recipes identified as corresponding to the respective food material groups GP1 to GP7 are recipes to be presented as recommended recipes each time to the user.
For example, after the setting is made, when the recommended recipe is presented to the login user for the first time (for example, on January 25 (Monday)), the recipe is presented as shown in FIG. 9A on a part of the top page, for example. Is done. These are images and texts for the recipes RP1, RP5, RP25, RP31, and RP45 shown as corresponding to the food group GP1 in FIG.
In addition, when the recommended recipe is presented to the login user for the second time (for example, presentation on Tuesday, January 26), the recipe is presented as shown in FIG. 9B. These are images and texts for the recipes RP1, RP15, RP43, RP51, RP61, and RP80 shown as corresponding to the food group GP2 in FIG.

As shown in FIG. 8, for each specific user, according to the current food inventory, the food material groups GP1 to GPn are set, and the recipe to be recommended and presented in the future n meals is specified. " Then, the setting contents are registered in the presentation setting DB 56 of FIG. In other words, for example, information on the ingredients set to the ingredient groups GP1 to GP7 and the corresponding recipes are registered.
The recipe management server 1 executes such a presentation setting process as a batch process, for example, every predetermined time corresponding to each user, and registers the presentation setting in the presentation setting DB 56 for each user.

In the process of FIG. 7, the recipe management server 1 confirms the presentation setting for the recommended recipe as shown in FIG. 8 for the login user, and performs presentation control.
In step S205, the recipe management server 1 refers to the presentation setting DB 56 and acquires the presentation setting content for the login user.
In step S206, the recipe management server 1 specifies a recipe to be presented as a recommendation this time. That is, if this time is the presentation opportunity at the timing before the second meal after setting (for example, the time before dinner on January 26 in the example of FIG. 6), the recipe RP1 corresponding to the ingredient group GP2 , RP15, RP43, RP51, RP61, RP80 are specified as recommended presentation recipes.
In step S206, presentation control is performed. The recipe management server 1 generates top page data incorporating a display of recommended recipes for this user and transmits the web page data to the user terminal 3.
In addition, while returning an authentication result to the user terminal 3, you may transmit the web page data of the top page of a recipe site. That is, in the case of login authentication OK, the top page data may be transmitted together with the authentication result in the step S206.

  The top page of the recipe site is displayed on the user terminal 3 by the processing of the recipe management server 1 described above. At this time, a list of recommended recipes as shown in FIG. 9B is displayed on a part of the top page, and if the user selects a recipe from that list, It is a recipe that can be cooked with the ingredients stock of the user.

  When the user browses the recommended recipe on the user terminal 3 and performs an operation of selecting an arbitrary recipe, the user terminal 3 executes a recipe selection process in step S103. That is, the user terminal 3 notifies the recipe management server 1 of which recipe the recipe selected by the user is as selected recipe information. This process is a process for requesting web page data of the detailed information page of the selected recipe.

In step S207, the recipe management server 1 that has received the selected recipe information performs a process of storing the browsing history of the recipe detail page in the presentation setting DB 56 as estimation information for estimating the used recipe. For example, if the second recommended recipe is presented to the user as the user “U001” this time, the browsing history of the detailed page is stored as the estimation information corresponding to the food group GP2.
In step S208, the recipe management server 1 transmits web page data describing detailed information of the selected recipe to the user terminal 3.
Through this process, detailed information related to the recipe selected by the user is presented on the user terminal 3. The detailed information is, for example, information on the ingredients used for the recipe, cooking procedures, cooking utensil information, and the like. In addition, information on a creation report posted for the selected recipe may be included.
The user can cook while browsing the detailed page, and if he / she does not like the food by browsing the detailed page, he can select another recommended recipe. Also in this case, the user can browse the detailed page of the selected recipe through the processes of steps S103, S207, and S208.

When an operation that can be estimated to be used by a user is performed on a recipe whose detailed information is displayed on the user terminal 3, information related to an operation that can be estimated to be used is transmitted to the recipe management server 1. The
For example, when an operation for printing detailed recipe information is performed as an operation for which recipe use is estimated, the user terminal 3 executes a process of transmitting information related to the printing operation to the recipe management server 1 in step S104. . The information regarding the printing operation includes the user ID of the user who performed the operation and the recipe ID of the recipe to be printed.
In step S209, the recipe management server 1 that has received the printing operation information stores the recipe printing history in the presentation setting DB 56 as estimated recipe information to be used.
In addition, as another example of the operation in which recipe use is estimated, for example, a creation report posting operation, an operation of registering in a favorite recipe, or a predetermined time of recipe detailed information (for example, 80% of cooking time) The above browsing operations can be listed.
Any of these operations is an operation in which the use of the recipe by the user (that is, the actual cooking has been performed) is estimated.

<5. First Embodiment>
The above is an example of the processing flow of the user terminal 3 and the recipe management server 1, but for the user, it is appropriate for each user according to the number of dishes until the next purchase, for example, in accordance with the purchase interval of the ingredients. A recommended recipe will be presented.
For example, the distribution of ingredients until the next purchase is cumbersome for Internet shopping, bulk purchases by consumer cooperatives, fresh food delivery services, and people who purchase large quantities in the market once a week. According to the present embodiment, for each meal up to the next purchase, ingredients are automatically distributed, and a recipe that can be cooked in the distributed state is presented each time.

Processing of the recipe management server 1 for appropriately realizing such a service will be described.
First, in order to realize the service as described above, it is desirable that a presentation setting in which a recommended recipe is specified for each user is performed and registered in the presentation setting DB 56 of FIG. Therefore, the recipe management server 1 performs presentation setting as needed for each user as a batch process at predetermined time intervals such as every 24 hours, for example, every day at midnight.

An example of batch processing for presentation setting is shown in FIG.
For example, the recipe management server 1 sequentially performs processing of FIG. 10 for each user registered as using the service of the present embodiment.
The recipe management server 1 first selects a certain user as a processing target in step S301. In step S302, the registered contents of the user's presentation setting DB 56 are confirmed. In this case, it is confirmed whether or not the currently effective presentation setting is registered. “Currently effective” means that a recommended recipe to be presented at the next presentation opportunity is set. For example, in the example of the user “U001” in FIG. 6, the current recipe is between January 25 and January 31, and the recommended recipe corresponding to the last food group GP7 has not yet been presented. In this case, there is an effective presentation setting.
If there is a valid presentation setting, no processing is required for the user this time, and the process proceeds from step S303 to S306. If another unprocessed user remains, the process returns to step S301 to perform processing for the next user.

If there is no presently effective presentation setting, the recipe management server 1 proceeds from step S303 to S304, and checks whether the current time is the food addition timing or the presentation setting timing for the target user.
The ingredient addition timing is, for example, whether or not it is the timing at which the ingredients for the user who purchases the ingredients regularly are acquired. For example, for a user whose food is delivered every Sunday by Internet shopping, the batch processing timing immediately after that is the food addition timing. Such a food addition timing may be determined by referring to the storage history DB 53 to check the user's purchase cycle and determine whether the current batch processing is immediately after the latest purchase time. .
In addition, referring to the user's storage history DB 53, when the latest purchase data is after the previous batch process, it may be determined as the food addition timing.
Further, the user may specify the presentation setting timing in advance. For example, the user designates in advance that the presentation setting for Monday through Sunday is made according to the ingredients at every Sunday. In that case, if the present timing is the relevant timing, it may be determined that it is the set timing.

If it is determined in step S304 that the present time is the food addition timing or setting timing for the user to be processed, the process proceeds to step S305.
Note that the process of step S304 may be omitted, and the process may always proceed from step S303 to S305 if there is no currently valid presentation setting for the target user.
The process of step S304 may be added when it is desired to proceed to step S305 only when it is the optimum timing for the presentation setting due to circumstances such as reduction of the processing load of the recipe management server 1.

In step S305, presentation setting for the user is performed.
When the presentation setting is performed, the remaining users are confirmed in step S306. If there are other unprocessed users, the process returns to step S301 to process the next user.
When the recipe management server 1 finishes the process for all users, the process of FIG. 10 ends.

  The presentation setting process in step S305 of FIG. 10 is shown in detail in FIG. The recipe management server 1 executes the presentation setting process of FIG. 11 mainly by the functions of the ingredient information acquisition unit 1a, the provision number specifying unit 1b, the ingredient group setting unit 1c, and the recipe specifying unit 1d shown in FIG.

When performing presentation setting for a certain processing target user, the recipe management server 1 first acquires the user's food information in step S401 of FIG.
This food material information is, for example, information on the type and amount of food as shown in FIG. That is, it is the information on the stock of the foodstuffs before allocating to each foodstuff group GP1-GPn.
The recipe management server 1 refers to the storage history DB 53 for the user and determines the ingredients currently owned (stocked) by the user. For example, the current user's stock quantity is determined by obtaining purchase data and usage data from the latest foods. When it is determined in step S304 in FIG. 10 that the batch processing is immediately after the food addition timing, information on the latest purchase data may be collected.
However, it is desirable that the information on the ingredients obtained here imposes a condition that the ingredients are suitable for use in cooking, not all the ingredients that the user stocks. For example,
-It is a condition to include in the ingredient information that the minimum usage amount set for each ingredient or the ingredient whose inventory amount is equal to or greater than the average usage quantity is within the deadline. Ingredients that are not suitable for these are not included in the ingredient information. This is because by imposing such conditions, it becomes possible to perform an appropriate recipe search by eliminating unusable ingredients.

Subsequently, in step S402, the recipe management server 1 determines the addition period of the ingredients from the information in the storage history DB 53. For example, for a user to be processed, if it is confirmed that the purchase of ingredients is performed once a week, the ingredient addition cycle is 7 days. Further, if there is food purchase data every 3 days, the food addition cycle is 3 days. If the user is shopping every day, the food addition period is one day.
Of course, the user does not always purchase food regularly, so for example, the interval from the latest food purchase to the previous food purchase is used as the food addition cycle, or the past average purchase interval is calculated. And it is good also as a foodstuff addition period.
However, since the processing of the present embodiment mainly targets users who purchase foods once a week, the food addition period is assumed to be stable to some extent.

  When the food addition cycle is determined, the recipe management server 1 specifies the number of times the recipe is provided in step S403. This is the value of “n” when the above-described recipe for n meals is provided. For providing the recipe, the user may select in advance whether he / she wants three meals, two meals, or one meal per day. For example, a user who wants to receive a recipe providing service only for dinner specifies that in advance. For example, the recipe management server 1 registers such user setting information in the user DB 51. If the user's food addition cycle is 7 days, the number of recipes provided may be 7 times. Moreover, if the ingredient addition period of the user who desires to provide a recipe twice a day is 5 days, the number of times the recipe is provided is 10 times.

In step S404, the recipe management server 1 sets a food distribution unit. The distribution unit is one unit assigned to a certain food material group.
For example, FIG. 12A is an example in which the food type is used as it is as a distribution unit. In this example, the ingredients F1, F2,... Are not divided into the ingredients F1 to Fm, and the ingredients F1, F2,.
FIG. 12B is an example in which distribution is made in units of quantity according to the foodstuff. For example, the food material F1 is divided into F1-1 to F1-4 and distributed to four food material groups. The food F3 is divided into F3-1 to F3-3 and distributed to three food groups.
A unit for such distribution is set. The distribution unit may be determined at random each time. However, in the case of a unit of quantity, it is appropriate that the minimum quantity is determined for each ingredient.

In the case of assigning foods in units of quantity, an example in which the quantity unit is a usage amount set for each food, for example, a reference usage amount, an average usage amount, a minimum usage amount, or the like can be considered.
The usage amount can also be set based on registered recipe information.
Furthermore, the usage amount may be specified based on the user's food history.
The quantity unit may be an amount corresponding to the number that needs to be sorted.

In step S405, the recipe management server 1 substitutes the value of the number of times of providing recipes into the variable n. The variable n is a value that determines the number of food groups to be set as the food material groups GP1 to GP (n).
In step S406, the recipe management server 1 selects a distribution condition. The distribution condition is a collective term for various conditions that define how to distribute the food in the distribution unit to the food groups GP1 to GP (n).
For example, as an algorithm for distribution processing,
・ Random distribution ・ Distribution considering the frequency of use of ingredients (general versatility) ・ Distribution considering the expiry date (algorithm that puts a short period until the expiry date into an ingredient group where recommended recipes are presented earlier)
・ Distribution taking into account the type of ingredients (for example, an algorithm that puts ingredients with a low freshness in an ingredient group where recommended recipes are presented quickly)
・ Algorithms that include leafy vegetables in all food groups ・ Algorithms that distribute meat and fish alternately
For example, a plurality of sorting algorithms such as these are prepared, and a process to be executed this time is selected in step S406. This does not correspond to individual users, and it is preferable to select which algorithm to use irregularly every time. This is because the combinations of ingredients allocated to the ingredient groups GP1 to GPn are also diversified. In other words, it is possible to increase the possibility of presenting various recipes to users who purchase similar foods every time.
In addition to the algorithm of the sorting process, for example, the minimum amount of food to be sorted, selection of a sorting unit, setting of a food that gives priority to the sorting order, and the like can be one of the sorting conditions.

In step S407, the recipe management server 1 performs an actual distribution process and sets the food material groups GP1 to GPn. In other words, using the sorting algorithm selected in step S406, the ingredients indicated by the ingredient information are sorted into n groups in the sorting unit set in step S404.
Various distribution algorithms can be considered as described above. Here, an example of a distribution process in consideration of the versatility of foods will be described.

Now, suppose that foodstuffs F1, F2,... Fm are highly versatile in this numerical order. High versatility means that it is used in many recipes. The recipe management server 1 can discriminate the highly versatile order of the ingredients listed in the ingredient information by referring to the ingredient DB 55.
FIG. 13 shows an example of distribution in consideration of versatility with n = 7. In the case where the distribution unit is set so that the most versatile food F1 is distributed to four groups, for example, the food F1 is allocated to four of the seven food groups GP1 to GP7. Here, it is assigned to every other food group GP1, GP3, GP5, GP7.
In addition, in this Embodiment, as for the foodstuff group GP1-GPn, the order of the number is demonstrated as a presentation order. Therefore, assigning food F1 to every other food group. This means that cooking recipes using the ingredients F1 are not continuously presented to the user.

Next, the food F2 having the second highest versatility is assigned to the food group GP2 that has not yet been assigned food.
Furthermore, when the allocation unit is set so that the third most versatile ingredient F3 is assigned to three groups, the ingredient F3 is first assigned to the ingredient groups GP4 and GP6 to which no ingredient is assigned. With the assignments so far, ingredients with relatively high versatility are included in all the ingredient groups. Therefore, a part of the remaining food material F3 and the food materials F4 to Fm are sequentially allocated, for example, as shown in FIG.
FIG. 14 shows a sorting process considering such versatility.
First, the recipe management server 1 assigns the first versatile food in step S501. At this time, it is confirmed whether or not all the food material groups GP1 to GPn include one or more food materials in step S511. If there is an ingredient group that has not yet been assigned an ingredient, the recipe management server 1 assigns the second versatile ingredient to the group without the ingredient in step S502. In step S512, it is confirmed whether or not all of the food groups GP1 to GPn include one or more foods. If there is an ingredient group that has not yet been assigned an ingredient, the recipe management server 1 assigns the versatile third-rank ingredient to the group without an ingredient in step S503. In step S513, it is confirmed whether or not all of the food groups GP1 to GPn include one or more foods.

As described above, the ingredients are assigned in descending order of versatility until all the ingredient groups GP1 to GPn include one or more ingredients.
When all the food groups GP1 to GPn include one or more foods, the process proceeds to step S520, where unassigned foods are selected and assigned to a certain food group. This is repeated until it is determined in step S521 that all ingredients have been allocated. When all the ingredients F1 to Fm are assigned, the assignment of the ingredients to the ingredient groups GP1 to GPn is completed.
In addition, even if the most versatile ingredients are assigned in step S50m, that is, even if the least versatile ingredients are allocated, if all the ingredient groups GP1 to GPn do not include one or more ingredients, the number of ingredients to be distributed (distribution unit) This is a case where the number of food groups (n) is larger than the number counted in (1). In such a case, since appropriate distribution is impossible, the process proceeds from step S51m to error processing in step S530. Although not shown in this case, it is conceivable to redo the food material allocation setting in step S404 in FIG. 17 or to end as a presentation setting error as the process for the user in FIG.

  By the processing as shown in FIG. 14 described above, foods having high versatility are distributed evenly to the food material groups GP1 to GP7. This produces an effect of increasing the number of recipes corresponding to each of the food material groups GP1 to GP7.

In addition, there are also ingredients with extremely low versatility, that is, ingredients that are very rare to appear in recipes. In the food DB 55, the number of recipes is extremely small.
About such a foodstuff, it is also considered that it is easy to extract a recipe using the foodstuff by distributing it to a plurality of foodstuff groups GP1 to GPn.
For example, the food Fx is a food having extremely low versatility. It is assumed that the recipes RPx using the ingredients Fx use the ingredients F1, F5, and Fx. Then, by assigning the foodstuff Fx to each group, the probability that a group having the foodstuffs F1 and F5 is generated can be increased, and the possibility that the recipe RPx can be extracted can be increased.

The above is an example of the distribution process of the foodstuff to foodstuff groups GP1-GPn. Various distribution processes are assumed by the various algorithms described above.
By this step S407, for example, as shown in FIG. 8, the food material groups GP1 to GPn to which the food materials are distributed are set.

When the food material groups GP1 to GPn are set, the recipe management server 1 subsequently performs a process of specifying recipes corresponding to the food material groups GP1 to GPn in steps S408 to S412.
First, the recipe management server 1 sets variable x = 1 in step S408. A variable x is a variable for designating a processing target food group.

Next, the recipe management server 1 performs a recipe search for the food group GP (x) in step S409. This is a process of searching the recipe DB 50 using the ingredients assigned to the ingredient group GP (x) as search keys and extracting recipes that can be cooked within the range of the ingredients. Note that it is not necessary for the recipe to use all the ingredients assigned to the ingredient group GP (x), and any recipe that can be cooked within the range of the assigned ingredients can be used.
Of course, it is also possible to extract recipes that use up the allocated food.
However, it is desirable to change the search conditions depending on the type of food and the expiration date. For example, in a food group, when a food material such as meat or fish that has a short expiration date is included, it is preferable to perform a process of extracting only a recipe that uses the food material.

  Initially, since the variable x = 1, the recipe management server 1 first performs a recipe search for the food group GP1 in step S409. In step S410, one or a plurality of recipes extracted as search results are specified as recipes corresponding to the food group GP1.

In step S411, it is confirmed whether or not the variable x has reached the variable n. If not, the process proceeds to step S412. That is, if the recipe specifying process has not been completed for all the food material groups GP1 to GPn, the variable x is incremented in step S412 and the process returns to step S409. Therefore, next, the corresponding recipe is similarly identified for the food group GP2.
By executing such processing for all the food material groups GP1 to GPn, recipes respectively corresponding to the food material groups GP1 to GPn are specified as shown in FIG.

When the variable x reaches the variable n, the recipes respectively corresponding to the food material groups GP1 to GPn are specified, and the recipe management server 1 proceeds from step S411 to S413 and performs a quantity condition check.
The quantity condition check is a process for checking, for example, whether the number of recipes or the type of recipe specified for each food group GP1 to GPn is equalized to some extent. Alternatively, it may be a process for checking whether or not a certain number of sufficient options can be secured each time.

In the present embodiment, the recommended recipes are proposed in n recipe providing opportunities, but it is preferable that various recipes can be proposed to the user each time. For example, in a state where 20 recipes are proposed at the first time and one recipe is proposed at the second time, it is assumed that the satisfaction level for the user is lowered. It is considered that the user's satisfaction with using this service is increased by making it possible to select a variety of recipes each time and making the food up to n times ahead with stock ingredients.
Therefore, it is checked whether the number and type of recipes corresponding to each of the food groups GP1 to GPn are not too biased or there are too few times.

As an example of the processing for the quantity condition check, an example in which the number of recipes or the type of dish is equalized will be described with reference to FIGS. 15A and 15B.
First, FIG. 15A is a processing example for checking whether or not the number of recipes is substantially equal.
In the processing example of FIG. 15A, the recipe management server 1 acquires the number of recipes corresponding to each of the food material groups GP1 to GPn in step S600 as the number of recipes NR1 to NRn.
The number of recipes NR1 is the number of recipes determined to correspond to the food group GP1 in step S410. In the example of FIG. 8, NR1 = 5.
The number of recipes NR2 is the number of recipes determined to correspond to the food group GP2 in step S410. In the example of FIG. 8, NR1 = 6.

  In step S601, the recipe management server 1 sets a threshold thNR for condition determination. The threshold thNR may be a fixed value, but may be a variable value. Here, it is assumed that the value is set according to the number “n” of the food material groups GP1 to GPn. For example, it is conceivable that the greater the number n of food groups, the stricter value (threshold value thNR) is, and the smaller the number of food groups n, the lower the value (threshold value thNR).

In step S602, the recipe management server 1 substitutes the maximum value for the variable NRmax and the minimum value for the variable NRmin among the recipe numbers NR1 to NRn. In step S603, a difference value ΔNR is obtained by calculating NRmax−NRmin.
In step S604, the recipe management server 1 compares the difference value ΔNR with a predetermined threshold thNR. If ΔNR ≦ thRN, the number of recipes to be presented each time is substantially equal, so the quantity condition is OK in step S605. To do.
That is, when the difference value ΔNR is larger than the threshold thNR, the difference between the number of proposed recipes with the largest number of recipes and the number of times with the least number of recipes is large, so it is not desirable. If the difference in the number of recipes at each time is small to some extent, it is determined that they are substantially equal.
Further, it is assumed that the greater the number n of food groups, the more the difference in the number of types of foods becomes, and the variation in the number of recipes increases. As a result, the number of recipes tends to be uneven. Therefore, as described above, the threshold value thNR is set according to the number n of food groups so that a more uniform situation can be easily maintained.

Note that the threshold thNR may be variable according to the total number of recipes to be handled.
For example, the total number of corresponding recipes is GNR = NR1 + NR2 +... + NRn, and the threshold thNR is thNR = (GNR / n) × k. If k = 0.3, when there is a difference exceeding 30% of the average number of recipes presented at one time, it is determined that the number is not substantially equal.
Of course, the threshold thNR may be a fixed value.

  There are other possible methods for checking the quantity condition for checking the uniformity of the number of recipes. For example, the presence / absence of a difference having a predetermined difference or more with respect to the average value of the number of recipes to be presented may be checked, and if it exists, it may be determined to be non-uniform.

FIG. 15B is an example on condition that the number of types of recipes of recipes corresponding to each of the food groups GP1 to GPn is substantially equalized.
The recipe management server 1 sets the level of the dish type in step S620. The dish type level is, for example, the above-described major classification level, middle classification level, or fine classification level.
The setting of the level of the dish type in step S620 may be fixed or may be a level designated by the user. Moreover, the level setting according to a user's preference and the level setting according to the corresponding recipe specified about each foodstuff group GP1-GPn may be sufficient.
The fixed level setting is an example in which the level set in step S620 is fixed to a large classification level such as “Japanese cuisine” or “Chinese cuisine”, or is fixed to a middle classification level “curry” or “hamburg”. is there. An example of randomly selecting a large classification, a medium classification, or a fine classification every time is also conceivable.
The level setting according to the user is an example in which a level suited to the user is used based on the recipe browsing history, recipe posting history, and the like of the user to be processed. For example, a large classification level or a medium classification level is set in step S620 for a user who uses, searches, or posts various cooking recipes. On the other hand, for a user who always browses and posts curry recipes, a sub-category level below “curry” such as “beef curry” and “chicken curry” is set. This makes it possible to determine the number of types of dishes according to the user's recipe search tendency.
The level setting according to the corresponding recipe specified for each of the food material groups GP1 to GPn is an example in which the type level is set according to the presence tendency of the cooking type of each recipe set as the corresponding recipe. For example, if all of the corresponding recipes that are supposed to correspond to each of the food groups GP1 to GPn include a large classification level and a plurality of types of dishes are included, the major classification level is set, or if there is only one middle classification level, the fine classification level is set. This is an example. Depending on the user's tendency to purchase ingredients, the corresponding recipe may be biased towards a certain large level of cuisine (for example, Vietnamese cuisine), and conversely, because the user frequently eats Vietnamese cuisine, It is because it is thought that it has purchased. In such a case, the middle classification level under Vietnamese cuisine is suitable as the level of the cuisine type.

In step S621, the recipe management server 1 acquires dish type information for each corresponding recipe of the food material groups GP1 to GPn. In this case, the dish type information may be information corresponding to the type level selected in step S620.
In step S622, the recipe management server 1 counts the number of cooking types in the recipe corresponding to each of the food material groups GP1 to GPn, and sets the number of cooking types as VNR1 to VNRn.
The number of cooking types VNR1 is the number of cooking types in the recipe group determined to correspond to the food group GP1 in step S410. The number of cooking types VNR2 is the number of cooking types in the recipe group determined to correspond to the food group GP2 in step S410.

  In step S623, the recipe management server 1 sets a threshold thVNR for condition determination. The threshold thVNR may be a fixed value, but may be a variable value. Here, it is assumed that the value is set according to the number “n” of the food material groups GP1 to GPn. For example, it is conceivable that the greater the number n of food groups, the more severe the value (threshold value thVNR), and the smaller the number of food groups n, the lower the value (threshold value thVNR).

In step S624, the recipe management server 1 substitutes the maximum value for the variable VNRmax and the minimum value for the variable VNRmin among the number of types of dishes VNR1 to VNRn. In step S625, a difference value ΔVNR is obtained by calculating VNRmax−VNRmin.
In step S626, the recipe management server 1 compares the difference value ΔVNR with a predetermined threshold thVNR. If ΔVNR ≦ thVRN, the number of types of recipes presented in each recipe is substantially equal, so the quantity condition is OK in step S627. If ΔVNR ≦ thVRN, the quantity condition is non-uniform in step S628. Judge that it does not meet.
That is, when the difference value ΔVNR is larger than the threshold thNR, it is not desirable because the difference between the number of cooking types of the recipe for one proposal is the largest and the number of times is the smallest. If the difference in the number of types of recipes in each recipe is small to some extent, it is determined that the recipes are substantially equal.
Further, since it is assumed that the number of types of cooking tends to be uneven as the number of food groups n increases, setting the threshold thVNR according to the number of food groups n as described above makes it more uniform. We try to make the situation easier to maintain.

Note that the threshold thVNR may be varied according to the number of types of dishes in all recipes that are to be handled.
For example, when the number of types of dishes is GVNR, the threshold thVNR is set to thVNR = (GVNR / n) × k. If k = 0.3, if there is a difference exceeding 30% of the number of types of dishes in a recipe presented at one time, it is determined that they are not substantially equal.
Of course, the threshold thVNR may be a fixed value.

  There are other methods for checking the quantity condition for checking the equality of the number of types of recipes in the recipe. For example, it may be determined that there is a difference that is greater than or equal to a predetermined difference with respect to the average value of the number of types of recipes to be presented.

Next, the processing example of FIG. 16A is a processing example in which at least a predetermined number of recipe options can be provided to the user each time.
The recipe management server 1 acquires the number of recipes corresponding to each of the food groups GP1 to GPn in step S610 as the number of recipes NR1 to NRn.

In step S611, the recipe management server 1 sets a threshold thNRmin for condition determination. The threshold thNRmin may be a fixed value, but may be a variable value. Here, it is assumed that the value is set according to the number “n” of the food material groups GP1 to GPn. For example, it is conceivable that the greater the number n of food groups, the more severe the value (threshold value thNRmin), and the smaller the number of food groups n, the lower the value (threshold value thNRmin).
In step S612, the recipe management server 1 substitutes the minimum value for the variable NRmin among the recipe numbers NR1 to NRn.
In step S613, the recipe management server 1 compares the variable NRmin, which is the minimum value, with a predetermined threshold thNRmin. If NRmin ≧ thRNmin, the quantity condition is determined to be OK in step S614. If NRmin ≧ thRNmin is not satisfied, it is determined that the quantity condition is not satisfied in step S615.
That is, the minimum number of recipes to be presented at one time is set as the threshold thNRmin, and if the number is at least that number, the quantity condition is satisfied. In this case, although the number of recipes may be extremely large, it is allowed, but the quantity condition is OK in the sense that at least a certain number of options can be prepared for each user.
Further, it is assumed that the greater the number n of food groups, the more the difference in the number of types of foods becomes, and the variation in the number of recipes increases. As a result, the number of recipes tends to be uneven. Therefore, as described above, the threshold value thNRmin is set according to the number n of food groups so that a more uniform situation can be easily maintained.

Of course, the threshold thNRmin may be a fixed value.
Further, when the number of recipes to be handled for the food groups GP1 to GPn is small due to the circumstances of the purchased food, there may be a situation where the condition cannot be satisfied if the fixed threshold thNRmin is satisfied. Therefore, the threshold thNRmin may be variably set based on the average value of the number of corresponding recipes for each of the food material groups GP1 to GPn.
For example, the total number of corresponding recipes GNR = NR1 + NR2 +... + NRn, and the threshold thNRmin is set to thNRmin = (GNR / n) × k. If k = 0.3, it is determined that the quantity condition is not satisfied when the number of recipes presented at one time is 30% or less of the average number of recipes.

FIG. 16B is an example on condition that the number of types of recipe types of recipes corresponding to each of the food material groups GP1 to GPn is equal to or greater than a predetermined number.
The recipe management server 1 selects a dish type level in step S630, and acquires dish type information for each corresponding recipe of the food material groups GP1 to GPn in step S631. In step S632, the recipe management server 1 counts the number of dish types in the corresponding recipe for each of the ingredient groups GP1 to GPn, and obtains the number of dish types VNR1 to VNRn. The above is the same as steps S621, S622, and S623 of FIG. 15B.
Also, the recipe management server 1 sets a threshold thVNRmin for condition determination in step S633. Here, it is assumed that the value is set according to the number “n” of the food material groups GP1 to GPn. For example, it is conceivable that the greater the number n of food groups, the more severe the value (threshold value thVNRmin), and the smaller the number of food groups n, the lower the value (threshold value thVNRmin).

In step S634, the recipe management server 1 substitutes the minimum value for the variable VNRmin among the number of types of dishes VNR1 to VNRn.
In step S635, the recipe management server 1 compares the variable VNRmin, which is the minimum value, with a predetermined threshold thVNRmin. If VNRmin ≧ thVRNmin, the quantity condition is determined to be OK in step S636. If VNRmin ≧ thVRNmin, it is determined in step S637 that the quantity condition is not satisfied.
That is, the minimum number of recipe types to be presented at one time is set as the threshold thVNRmin, and if it is at least the number, the quantity condition is satisfied. For this reason, the quantity condition is OK in the sense that at least a certain number or more of types of dishes can be prepared for each user.
Moreover, since it is assumed that the number of food types is likely to be non-uniform as the number of food material groups n is larger, setting the threshold thVNR according to the number of food material groups n as described above results in a more even situation. It is easy to maintain.

In this case, the threshold thNRmin may be a fixed value. However, when the number of types of dishes in the recipes corresponding to the ingredient groups GP1 to GPn is reduced due to the circumstances of the purchased ingredients, there may be a situation where the condition cannot be satisfied if the fixed threshold thVNRmin is set. is there. Therefore, the threshold thVNRmin may be variably set based on the average value of the number of cooking types for each of the food material groups GP1 to GPn.
For example, when the number of types of dishes in the entire corresponding recipe is GVNR, the threshold thVNR is set to thVNR = (GVNR / n) × k. If k = 0.3, it is determined that the quantity condition is not satisfied when the number of dish types in the recipe presented at one time is less than 30% of the average value.

Returning to FIG. 11, when the quantity condition check as described above is performed in step S413, the recipe management server 1 branches the process depending on whether the quantity condition is satisfied in step S414.
If the quantity condition is satisfied, the current setting, that is, the settings of the food material groups GP1 to GPn and the corresponding recipes are determined and stored in the presentation setting DB 56 in step S416. In other words, a recipe to be recommended and presented to a certain user at n cooking occasions in the future has been determined.
However, when it is determined that the quantity condition is not satisfied, the recipe management server 1 proceeds from step S414 to S415, and after changing the distribution condition etc., repeats the processing from step S407. For example, an algorithm different from that used last time is selected as the algorithm of the distribution process for generating the food material groups GP1 to GPn, and the process of step S407 is performed.
Alternatively, at the time of this step S415, the minimum amount of food to be distributed, selection of a distribution unit, setting of food for which the order of distribution is prioritized may be changed. In particular, it may be possible to newly redo or adjust the setting of the food distribution unit performed in step S404. For example, for an ingredient group with a small number of corresponding recipes, it is conceivable to increase the amount of ingredients to be allocated and subtract that amount from other ingredient groups. Of course, it is desirable that the food material group to be reduced is a recipe having a large number of corresponding recipes.

  In such a presentation setting process of FIG. 11, recommended recipes to be proposed for n cooking occasions are set for one user in the future, but the number of recipes to be presented and variations in the cooking types are to some extent. Recipes to be recommended are set so as to improve.

When the presentation setting process as shown in FIG. 11 is performed in step S305 in FIG. 10, the recommended recipe presentation setting for the current processing target user is completed and registered in the presentation setting DB.
The recipe management server 1 confirms whether or not there are remaining unprocessed users in step S306 of FIG. 10, and if there are remaining users, the process returns to step S301 to perform the same processing for the next user. Therefore, for a user who receives the service of this example provided by the recipe management server 1, if there is no effective presentation setting, the presentation setting is performed so that the user can receive the service.

The user terminal 3 and the recipe management shown in FIG. 7 are processed for a user who has been processed in a batch process and the presentation settings are registered in the presentation setting DB. The recommended recipe is presented by the exchange of the server 1.
The processing of the recipe management server 1 for realizing the processing of FIG. 7 is shown in FIG. The recipe management server 1 executes the process of FIG. 17 mainly by the functions of the presentation control unit 1e and the recipe management unit 1f shown in FIG.

The recipe management server 1 performs various processes continuously by sequentially executing steps S701, S711, and S721.
Specifically, a process for determining whether or not login information is received in step S701 is executed, and a process for determining whether or not a request for web page data is received in step S711, which is used in step S721. A process of determining whether or not the estimation information has been received is executed.
In addition to these, the recipe management server 1 also performs processing when a creation report post or recipe post is received, recipe search processing when a recipe search condition is received, and the like. Since they are not related, the description of these processes is omitted.

The login information is transmitted from the user terminal 3 to the recipe management server 1 when the user performs a login operation using the user terminal 3.
If it is determined in step S701 that login information has been received, the recipe management server 1 executes an authentication process in step S702, and executes a process of notifying the user terminal 3 of the authentication result in step S703.
In the authentication process, the login information sent from the user terminal 3 and the user information (for example, user ID and login password) stored in the user DB 51 are collated to determine whether or not login is possible.

If the authentication is not OK, the recipe management server 1 returns to the loop of steps S701, D711, and S721, but if the authentication is OK, the user terminal 3 of the user transmits the top page of the recipe site. For example, in this case, the current recommended recipe is presented to the user.
First, in step S704, the recipe management server 1 acquires information on the presentation user's presentation setting from the presentation setting DB 56. In step S705, the recipe to be presented this time is specified based on the number of times this presentation is made or the current date and time.
In step S706, the recipe management server 1 generates top page data including the recipe that is recommended and presented this time, and transmits the top page data to the user terminal 3 in step S707. As a result, as described in step S206 of FIG. 7, the current recommended recipe is presented on the user terminal 3 as shown in FIGS. 9A and 9B, for example.

In step S711, the recipe management server 1 executes processing for determining whether a web page data request has been received.
If it is determined that the web page data request has been received, the recipe management server 1 executes processing for acquiring the requested web page data from the DB in step S712. Specifically, web page data of a user page, web page data of a recipe detail page, web page data of a special feature page, and the like are acquired.
Then, the recipe management server 1 performs the process which transmits the said web page data to the user terminal 3 in step S713. Thereby, the web page desired by the user is displayed on the user terminal 3.

If the recipe management server 1 acquires the usage estimation information in step S721, the recipe management server 1 stores the estimation information or the usage recipe in the presentation setting DB 56 in step S723.
As described above, for example, a detailed page request, print operation information, or detailed page viewing time information is estimated information for specifying a used recipe. When such information is acquired, it is stored as estimated information corresponding to the current recipe presentation of the logged-in user in the presentation setting DB 56.
In response to the acquisition of the estimation information, the used recipe is estimated in step S724. The estimation method is as described above. If it is determined that the estimation accuracy of the used recipe is high, information on the ingredients contained in the recipe and the date and time of use are stored in the storage history DB 53 as usage data.
Note that the user does not necessarily use the recommended recipe. In some cases, the user searches for a recipe that is completely different from the recommended presentation. In step S724, when other recipes are estimated from the usage estimation information, it is estimated that the ingredients used in the recipe are used and stored in the storage history DB 53 as the usage data of the ingredients.
Further, instead of the estimated information, the user may be able to transmit information indicating the recipe used by the user to the recipe management server 1. For example, when viewing a detailed page, a question such as “Do you want to start cooking with this recipe?” May be displayed, and the user may enter a yes / no answer. It is appropriate to handle such answer information in the same manner as the estimated information, and store the estimated information and the usage data.
The recipe management server 1 may store the information indicating the estimated used recipe itself in the presentation setting DB 56 in association with the estimated information at the time of step S724, for example.

According to the above processing, a plurality of recommended recipes for cooking to be started are presented to the login user according to the date and time. Each time they can be cooked with ingredients purchased by the user.

<6. Second Embodiment>
A second embodiment will be described.
Hereinafter, in the description of the second and third embodiments, only processes different from those of the first embodiment will be described. Processing that is not mentioned is the same as in the first embodiment.

FIG. 18 illustrates a presentation setting process according to the second embodiment. That is, this is an example of processing performed in step S305 in FIG.
The same processes as those in FIG. 11 are given the same step numbers to avoid redundant explanation. 18 differs from FIG. 11 in the processing of steps S420 and S421.

When it is determined in the quantity condition check in step S413 that the quantity condition is not satisfied, the recipe management server 1 determines in step S420 whether or not there is a recipe that can change the amount of ingredients as the recipe itself. For example, the recipe management server 1 determines whether there is a recipe that can be cooked even if the amount of a certain ingredient contained in the recipe is slightly reduced.
For each recipe registered in the recipe DB 50, an ingredient whose amount can be changed is set in advance. For example, a recipe creator may be requested to have different amounts of information transmitted as an amount in the case of a shortage of materials, and may be acquired and registered.

If there is no recipe whose quantity can be changed in the recipe DB 50, the recipe management server 1 proceeds from step S420 to S415. That is, as in the first embodiment, the sorting condition is changed and the food groups GP1 to GPn are reset.
On the other hand, if there is a recipe whose quantity can be changed, in step S421, the recipe search setting is changed so that the recipe after the quantity change is targeted. And by the process after step S408, the recipe corresponding to each of each foodstuff group GP1-GPn is performed for the recipe which changed quantity setting.
This can be expected to increase the number of recipes that can be extracted as corresponding to the food group.
Therefore, if a corresponding recipe is specified in this process, there is a possibility that the quantity condition check in step S413 is OK.

As described above, in the second embodiment, when the quantity condition cannot be satisfied, whether or not the quantity condition is satisfied is tried by changing the amount of ingredients set in the recipe.

<7. Third Embodiment>
Processing of the recipe management server 1 according to the third embodiment will be described with reference to FIGS. 19 and 20. In FIG. 19, the same processes as those in FIG. 10 are denoted by the same step numbers and the description thereof is omitted.
FIG. 19 is obtained by adding steps S310 and S311 to the process of FIG.
In the example of FIG. 10, the presentation setting process is skipped for a user who currently has a valid presentation setting. In the example of FIG. 19, the confirmation in step S310 is performed for such a user.

  That is, in step S310, the recipe management server determines whether or not the initial recommended recipe presentation has already been completed for the user to be processed, or whether there is additional food by referring to the information in the storage history DB 53. To check.

For a user who has already presented a recommended recipe once or more, there is a possibility that there are ingredients that have not been used in the ingredient group depending on the recipe used. For example, the recipe corresponding to the ingredient group GP1 is not a recipe that uses all the ingredients of the ingredient group GP1, but a recipe that can be cooked with the ingredients of the ingredient group GP1 is selected.
Moreover, when a user purchases foodstuffs irregularly, the information of additional foodstuffs can be acquired.
In other words, new ingredients to be used are generated even during the period when the presentation setting is valid. Therefore, in the example of FIG. 19, the re-presentation setting process is performed in step S311 in such a case.
The re-presentation setting process is a process for identifying an additional recipe while the information on the recommended recipe identified in the presentation setting process performed in step S305 is valid.

The re-presentation setting process is shown in FIG.
In step S801, the recipe management server 1 refers to the storage history DB 53 of the user to be processed and determines the presence or absence of additional ingredients. That is, the information on the ingredients purchased at the time after the presentation setting process is performed in step S305.
If such a food exists, the recipe management server 1 acquires the type and amount of the food as additional food information in step S802.

In step S803, the recipe management server 1 has completed the presentation of the first recommended recipe at the present time, that is, the recipe corresponding to the ingredient group GP1 has been presented in the past, and now any of the ingredient groups GP2 to GPn It is determined whether or not it is time to present the corresponding recipe.
If the recommended recipe has been presented even once or more, there may be extra ingredients in the ingredient group depending on the actual recipe used at the time of presentation.
Therefore, if it has already been presented for the first time, the recipe management server 1 first identifies the ingredients used so far by referring to the storage history DB 53 in step S804. That is, the date and time data corresponding to the use data of the food is extracted.
In step S805, the recipe management server 1 calculates the amount of use for each ingredient from the extracted use data.
In step S806, the recipe management server 1 uses the information on the amount used for each ingredient and the information on the ingredients and the amount originally assigned to the corresponding ingredient group. , Calculate the type and amount of surplus ingredients.

In step S807, the recipe management server 1 substitutes the number of the ingredient group for presenting the corresponding recipe next time into the variable x. For example, if the present recipe has already been presented to the food groups GP1 and GP2 and the next presentation is the third presentation, x = 3.
In step S808, a process of distributing the remaining ingredients and additional ingredients to the ingredient groups GP (x) to GPn (which may be x = n) is performed.

After adding ingredients to the ingredient groups GP (x) to GPn for future presentation, the recipe management server 1 subsequently performs a process of specifying recipes corresponding to the ingredient groups GP (x) to GPn in steps S809 to S812. Do.
That is, the recipe management server 1 performs a recipe search for the food group GP (x) in step S809. This searches the recipe DB 50 as a search key including the ingredients assigned in the first presentation setting process to the ingredient group GP (x) and the ingredients additionally assigned this time, and cooking is performed within the range of the ingredients. This is a process for extracting possible recipes.
In step S810, an additional recipe of the food material group GP (x) is specified. In this case, it is expected that additional recipes will be extracted including the recipe for the first presentation setting due to the increase in food ingredients. Accordingly, the additional recipe is a recipe that is not included in the recipe extracted at the time of the first presentation setting among the recipes extracted this time.

The recipe management server 1 performs steps S809 and S810 while incrementing the variable x in step S812 until the variable x = n in step S811. Therefore, the corresponding recipe is added to the food material group that presents the corresponding recipe at a future time.
When the processing up to the food group GPn is finished, the process proceeds to step S813, and the contents of the presentation setting DB 56 are updated. In other words, for the ingredient group that presents the corresponding recipe at a future time, the corresponding recipe is stored.
Accordingly, when the recommended recipe is presented in the above-described process of FIG. 17, the recommended recipe is presented in consideration of the remaining ingredients and additionally purchased ingredients.

In this re-presentation setting, the quantity condition check may be unnecessary, and in this case, the quantity condition check may be executed.
For example, according to the idea of providing the minimum number of options as shown in FIG. 16, the quantity condition check has already been satisfied, so there is no need to perform the process in FIG.
On the other hand, if the uniformity as shown in FIG. 15 is considered, if the uniformity of the number of recipes and the number of types of dishes is to be maintained in the remaining times, the quantity condition check is performed by the processing as shown in FIG. 15A or 15B. If it is not satisfied, it can be considered to start again from step S808.
Of course, once the uniformity is ensured, there is a way of thinking that the uniformity may be slightly lost by the additional recipe, so the quantity condition check need not be performed.
By omitting the quantity condition check during the re-presentation setting process, the processing load on the recipe management server 1 can be reduced.

<8. Summary>
Although the embodiments have been described above, the following effects can be obtained in the embodiments.
The recipe management server 1 (information processing apparatus) according to the first to third embodiments obtains information on ingredients including at least inventory information from a storage device (storage history DB 53) that stores the storage history of ingredients. Part 1a (refer to S401 in FIG. 11). The recipe management server 1 also provides a provision number specifying unit 1b (see S402 and S403) that specifies the number of times the recipe is provided according to the period in which the ingredients determined based on the storage history stored in the storage history DB 53 are added. An ingredient group setting unit 1c that distributes each ingredient included in the ingredient information to the number of ingredient groups GP1 to GPn according to the number of recipe provisions based on the acquired ingredient information and the specified number of recipe provision times (S407). And a recipe specifying unit 1d (see S408 to S412) that specifies a recipe on the basis of the distributed ingredients for each of the ingredient groups GP1 to GPn. Furthermore, the recipe management server 1 includes a presentation control unit 1e (see S704 to S707 in FIG. 17) that performs presentation control of the recipe specified for each of the food material groups GP1 to GPn. The ingredient group setting unit 1c sorts the ingredients so that the number of recipes or the type of recipe specified by the recipe specifying unit 1d for each ingredient group satisfies a predetermined quantity condition (see S413, S414, S415, etc. in FIG. 11). ).

  For example, it is assumed that a user purchases foods once a week. The purchased ingredients are distributed to the number of times the recipe is provided (for example, seven times for dinner for one week), and the ingredient groups GP1 to GPn are set. And the recipe which can be cooked with the foodstuff in the foodstuff group for every foodstuff group GP1-GPn is specified. Then, several recipes are presented to the user for each ingredient group, for example, for each daily dinner.

  Thereby, after distributing ingredients to the required number of times, a recipe appropriate for each meal (that is, cooking with existing ingredients) is provided to the user. For the user, if an arbitrary recipe is selected from the recipes presented each time and cooking is performed, for example, ingredients purchased together for one week, etc. can be distributed and used for daily meals. . Therefore, the user does not have to be concerned about the distribution of ingredients.

Moreover, since the recipe shown with the foodstuff previously distributed for every meal is specified, various recipes are provided each time. In particular, by setting the food group so that the number or type of recipes satisfies the quantity condition, the number of recipes or the number of types of dishes presented each time can be moderately large and rich in variations. . Therefore, it is possible to realize a recipe providing service with abundant user options and high satisfaction.
In addition, while being able to select a variety of recipes to some extent each time, the user's satisfaction with using this service is increased by providing food up to n times ahead with the ingredients in stock.
It is particularly suitable for users who are performing regular purchases via Internet shopping, collective purchases by consumer cooperatives, purchases using fresh food delivery services, bulk purchases on the market once a week, and the like.

Further, it is possible to realize a recipe providing system with good usability so that the user can easily find a desired recipe in a short time. This is because recipes that can be cooked at present are presented with a wide range of choices.
In addition, since it is expected that the number of re-searches will be reduced, it is possible to promote the reduction of the total communication amount in the network system and the effective use of the communication traffic.
Furthermore, by presenting valuable information (recipe) in a limited presentation area (for example, a monitor) in the user terminal 3 used by the user, the resources of the user terminal 3 can be effectively utilized.

In the embodiment, regarding the setting of the food groups GP1 to GPn, information indicating the versatility of each food contained in the acquired food information is acquired, and the value indicated by the acquired information indicating the generality is relatively high The example which sets an ingredient group so that ingredients could be distributed to different ingredient groups was shown (refer to Drawing 13 and Drawing 14).
When only a highly versatile ingredient is collected in a certain ingredient group, the number of corresponding recipes increases for that ingredient group, but it is assumed that the number of corresponding recipes decreases in other ingredient groups. Therefore, avoid concentrating on groups with highly versatile ingredients. As a result, the number and types of recipes corresponding to each ingredient group can be equalized to some extent, and it becomes easy to secure the user's options for each presentation.
In addition, by setting the food material groups GP1 to GPn using this algorithm, the possibility that the quantity condition can be cleared increases, and it is expected that re-setting will be reduced. Therefore, the processing load on the recipe management server 1 can be reduced.

In the embodiment, an example has been described in which food ingredients are allocated to the food ingredient groups GP1 to GPn in units of quantities and the food ingredient groups GP1 to GPn are set (see FIGS. 8 and 12B).
Thereby, recipes using common ingredients can be handled in each of the ingredient groups GP1 to GPn, and the number of recipes and the number of types of dishes corresponding to the ingredient groups GP1 to GPn can be easily secured.
In the process of FIG. 11 as an embodiment, when the quantity condition cannot be satisfied by distributing the ingredients to each ingredient group in the unit of quantity set for each ingredient, adjustment of the quantity of ingredients to be assigned to each ingredient group An example of performing is described (S415).
This is to adjust the amount to be distributed so as to satisfy the quantity condition because the number of corresponding recipes may be extremely reduced in some cases if one food is distributed for each specific amount. Thereby, one foodstuff can be flexibly distributed to each foodstuff group, and it can be made easy to secure the number of recipes and the number of cooking types corresponding to each foodstuff group.

Further, in the process of FIG. 18 as the second embodiment, the amount of ingredients set in the recipe is changed when the quantity condition cannot be satisfied by distributing the ingredients to each ingredient group GP1 to GPn in units of quantities. By doing so, it is confirmed whether or not the quantity condition is satisfied (see S420 and S421).
In some cases, the amount of ingredients is insufficient, and a certain recipe cannot be handled by a certain ingredient group. In that case, the recipe can be made into the recipe corresponding to a foodstuff group by changing the quantity set to the recipe.
Thereby, the number of recipes corresponding to one food group and the number of types of dishes can be easily secured.
Further, when the quantity condition can be cleared by this method, the processing load on the recipe management server 1 is reduced because it is not necessary to redo the settings for the food material groups GP1 to GPn.

In the embodiment, after acquiring recipes corresponding to each ingredient group, if information on the ingredients that can be added is acquired, the ingredients are reassigned, the additional recipe is specified in the reassigned state, and the additional recipe is added. The example which performs the presentation control of the recipe in the state which carried out was given.
That is, in the third embodiment, after specifying the recipe corresponding to each food group GP1 to GPn, when the recipe is provided for the second time or later, the surplus ingredients related to the previous and previous recipes are reallocated. The additional recipe is specified in the reassigned state (see S311 in FIG. 19). And the presentation control of the recipe in the state which added the additional recipe is performed.
For example, the first presentation presents a recipe that can be cooked with ingredients that are the first food group GP1. However, surplus ingredients are generated depending on which recipe the user selects to cook. Therefore, at the time of presentation for the second time and thereafter, after the surplus ingredients are distributed to the remaining ingredient groups GP2 to GPn, a recipe that can be cooked is specified and presented as an additional recipe.
As a result, when presenting recipes for the second and subsequent times, a variety of recipes can be displayed by effectively using the remaining ingredients. Depending on the user's selection, the surplus ingredients can be used effectively. In addition, the user is given an opportunity to select a recipe that generates as little extra food as possible.
Moreover, in this 3rd Embodiment, also when the additional information of foodstuff is acquired, reassignment of an additional foodstuff is performed and an additional recipe is specified in the state of reassignment (refer S311 of FIG. 19). And the presentation control of the recipe in the state which added the additional recipe is performed.
For example, when an ingredient is added after assigning ingredients for one week and specifying a recipe, a recipe reflecting the additional ingredients is additionally presented as a subsequent recipe presentation.
Thereby, additional ingredients can be used effectively and various recipes can be displayed.

In the embodiment, as the quantity condition, an example in which the difference in the number of recipes specified for each food group GP1 to GPn or the difference in the number of cooking types in the recipe specified for each food group GP1 to GPn is within a predetermined range. (See FIGS. 15A and 15B).
This makes it possible to avoid a non-uniform state in which the number of recipes that are presented each time is extremely small or excessive in some cases, and a stable number of options can be provided to the user.
Here, the quantity condition about the number of recipes specified for each ingredient group GP1 to GPn or the deviation of the number of cooking types in the recipe specified for each ingredient group is set according to the number of ingredient groups. (See S601 in FIG. 15A and S623 in FIG. 15B).
For example, the larger the number of food groups, the more severe the conditions, thereby avoiding a non-uniform state and maintaining a state where a stable number of options can be provided to the user.

  It should be noted that the surplus of food itself is not a problem in the present embodiment. In other words, it may be left. For example, as a result, even if there is a surplus food material after one week, it may be reflected in the next presentation setting. Moreover, it is because a user should just use the surplus foodstuff freely. The present embodiment is mainly intended to provide a variety of recipes by distributing foods at a plurality of cooking occasions. Therefore, the first embodiment that does not perform additional recipe setting as in the third embodiment is also sufficiently effective.

In the embodiment, as the quantity condition, the number of recipes specified for each ingredient group GP1 to GPn, or the number of dish types in the recipe specified for each ingredient group GP1 to GPn is equal to or greater than a predetermined minimum value. (See FIGS. 16A and 16B).
As a result, it is possible to avoid presenting with an extremely small number of recipes and the number of types of dishes among recipes to be presented each time, and to provide sufficient options to the user each time.
Here, the quantity condition as the minimum value of the number of recipes specified for each ingredient group GP1 to GPn or the number of cooking types in the recipe specified for each ingredient group is set according to the number of ingredient groups. (See S611 in FIG. 16A and S623 in FIG. 16B).
For example, as the number of food groups increases, the condition of the minimum value is tightened, so that a non-uniform state can be avoided and a state where a stable number of options can be provided to the user can be maintained.

Note that the configuration and processing of the information processing apparatus of the present invention are not limited to the ones mentioned in the above embodiment, and various modifications can be assumed.
As a recommended recipe to be provided every time, for example, only a main dish, or a set of main dishes and side dishes, or a set of a plurality of recipes may be presented as a set of all meals. For example, a main recipe, a soup recipe, and a salad recipe may be used as a set of recommended recipes.

In the embodiment, the recommended recipe is presented to the user at each presentation opportunity. However, for example, the user may be able to view all the remaining times.
For example, when a recommended recipe for one week is specified for a certain user, when the user visits the recipe site, the recommended recipe for the week is presented. This makes it easier for the user to plan a menu.

Although not mentioned in the embodiment, by inputting recipe settings for a plurality of people in advance,
Naturally, it is conceivable that food group setting and recipe identification are performed accordingly.
For example, for a user of four family members, it is only necessary to search for recipes that can be cooked because the ingredients of the ingredient groups GP1 to GPn are ingredients for four people.

  The processing described with reference to FIGS. 10 to 16 is not necessarily performed by batch processing. If the above process can be realized at a sufficiently high speed, when the user logs in, the process shown in FIG. 10 may be performed for the logged-in user, and the presentation setting process may be performed as necessary.

It is not necessary to present the recommended recipe on the top page of the recipe site.
In that case, the recipe management server 1 may perform the processes of steps S704 to S707 in FIG. 17 in response to a request for presentation of a recommended recipe from the user terminal 3.

In the embodiment, the food material information is acquired from the actual additional history that can be grasped by the storage history DB 53. However, it is also conceivable to perform additional food material estimation and acquire additional food material information at a future time point.
For example, the additional amount at a certain point in time can be estimated based on the storage history of past food information.
Further, the additional amount can be estimated based on the remaining amount of the food material.
It is also possible to specify the amount of food added at a certain point in the future, based on order information from a consumer cooperative or internet supermarket, but not yet purchased.
Based on such additional estimation of ingredients, it is also possible to make a presentation setting at a future point in time or add a recommended recipe by performing a re-presentation setting.
Moreover, the possibility of addition of foodstuffs can be estimated based on the remaining amount of foodstuffs, for example, or can be estimated based on the current price of foodstuffs. In particular, it is possible to determine the market price of the purchase price for each user, and take into consideration that, when a certain ingredient becomes cheaper, estimate that it is likely to purchase soon, and reflect it in the presentation setting process and re-presentation setting process .

<9. Program and Storage Medium>
The program according to the embodiment of the present invention is an information processing apparatus that performs processing based on the functions of the ingredient information acquisition unit 1a, the provision number specifying unit 1b, the ingredient group setting unit 1c, the recipe specifying unit 1d, and the presentation control unit 1e in the recipe management server 1. This is a program to be executed by (CPU etc.)

  The program according to the embodiment includes an ingredient information acquisition procedure (S401) for acquiring information on ingredients satisfying a predetermined condition from a storage device that stores the storage history of ingredients, and a storage history stored in the storage device (storage history DB 53). The number of times of adding foods is determined, and the provision number specifying procedure (S402, S403) for specifying the number of times the recipe is provided based on the determined period and the information on the ingredients acquired in the ingredient information acquisition procedure are included. The ingredients group setting procedure (S407) for assigning each ingredient and setting the number of ingredient groups GP1 to GPn according to the number of times the recipe is provided, and the recipe identifying procedure for identifying the recipe based on the assigned ingredients for each ingredient group (S410) and a presentation control procedure (S704 to S707) for performing presentation control of the recipe specified for each of the food material groups GP1 to GPn. To be executed by the broadcast processing apparatus. Further, in the food material group setting procedure, the information processing apparatus is caused to execute a food material distribution in which the number of recipes or the cooking type specified for each food material group in the recipe specifying procedure satisfies a predetermined quantity condition (S407 to S415).

By such a program, the information processing apparatus as the above-described recipe management server 1 can be realized.
Such a program can be stored in advance in an HDD as a storage medium built in a device such as a computer device, a ROM in a microcomputer having a CPU, or the like. Alternatively, it can be stored (stored) temporarily or permanently in a removable storage medium such as a semiconductor memory, memory card, optical disk, magneto-optical disk, or magnetic disk. Such a removable storage medium can be provided as so-called package software.
Further, such a program can be installed from a removable storage medium to a personal computer or the like, or can be downloaded from a download site via a network such as a LAN or the Internet.

  DESCRIPTION OF SYMBOLS 1 Recipe management server, 1a Ingredient information acquisition part, 1b Provision number specification part, 1c Ingredient group setting part, 1d Recipe specification part, 1e Presentation control part, 1f Recipe management part, 2 network, 3 user terminal, 4 EC server, 50 Recipe DB, 51 User DB, 52 Search DB, 53, 53A Storage History DB, 54 Product DB, 55 Food DB, 56 Presentation Settings DB

Claims (8)

An ingredient information acquisition unit for acquiring information on ingredients including at least inventory information from a storage device for storing the storage history of the ingredients;
A provision number specifying unit that specifies the number of times the recipe is provided according to the period in which the ingredients determined based on the storage history stored in the storage device are added;
Based on the information on the acquired ingredients and the specified number of times of providing the recipe, each ingredient included in the information on the ingredients is divided into a number of ingredient groups according to the number of times of providing the recipe,
For each food group, a recipe identifying unit that identifies a recipe based on the sorted food,
A presentation control unit for controlling the presentation of the recipe specified for each food group;
With
The food material group setting unit distributes foods so that the number of recipes or the type of food specified by the recipe specifying unit for each food group satisfies a predetermined quantity condition. The food group setting unit acquires information indicating versatility for each food contained in the acquired information on the food, and the food groups having different relatively high values indicated by the acquired information indicating the versatility The information processing apparatus according to claim 1, wherein the food material group is set so as to be distributed to each other. The ingredient group setting unit assigns ingredients to each ingredient group in units of quantities and sets the ingredient groups. If the quantity condition cannot be satisfied for each ingredient group that has been set, the ingredient group assignment unit is re-established. The information processing apparatus according to claim 1, wherein setting is performed. After identifying recipes that correspond to each ingredient group, if you get information on ingredients that can be added,
The ingredient group setting unit reassigns ingredients,
The recipe identification unit identifies an additional recipe in the reassigned state,
The information processing apparatus according to claim 1, wherein the presentation control unit performs recipe presentation control in a state where the additional recipe is added. 5. The quantity condition for the number of recipes specified for each ingredient group or the deviation of the number of cooking types in the recipe specified for each ingredient group is set according to the number of ingredient groups. The information processing apparatus according to any one of the above. The quantity condition as the minimum value of the number of recipes specified for each ingredient group or the number of types of recipes in the recipe specified for each ingredient group is set according to the number of ingredient groups. The information processing apparatus according to any one of the above. As an information processing method executed by the information processing apparatus,
Ingredient information acquisition step for acquiring information on ingredients including at least inventory information from a storage device that stores the storage history of the ingredients;
A provision number specifying step for specifying the number of times the recipe is provided according to the period in which the ingredients determined based on the storage history stored in the storage device are added,
Ingredient group setting step of allocating each ingredient included in the ingredient information to the number of ingredient groups according to the recipe provision number based on the acquired ingredient information and the specified recipe provision number,
Recipe identifying step for identifying a recipe based on the sorted ingredients for each ingredient group,
A presentation control step for controlling the presentation of the recipe specified for each food group;
With
In the food material group setting step, the food material is distributed so that the number of recipes or the type of food specified for each food material group in the recipe specifying step satisfies a predetermined quantity condition. Ingredient information acquisition procedure for acquiring information on ingredients including at least inventory information from a storage device that stores the storage history of ingredients;
A provision number specifying procedure for specifying the number of recipe provisions according to the period in which the ingredients determined based on the storage history stored in the storage device are added,
Ingredient group setting procedure for allocating each ingredient included in the ingredient information based on the acquired ingredient information and the identified recipe provision number to the number of ingredient groups according to the recipe provision number,
Recipe identification procedure for identifying a recipe based on the sorted ingredients for each ingredient group,
A presentation control procedure for performing presentation control of the recipe specified for each food group;
To the information processing device,
In the food material group setting procedure, a program for causing the information processing apparatus to execute a food material distribution in which the number of recipes or the cooking type specified for each food material group in the recipe specifying procedure satisfy a predetermined quantity condition.

Images