JP6890747B2 - Information processing equipment, information processing methods, programs - Google Patents

Description

The present invention relates to a technical field of an information processing device for managing recipes, an information processing method, and a program. Specifically, it relates to various processes for presenting a recipe to a user.

JP-A-2015-153286 Japanese Unexamined Patent Publication No. 2003-256577 Japanese Unexamined Patent Publication No. 2015-028767

In recent years, recipe search services that provide recipe information accumulated by posting by general users have become widespread.
In general, thinking about daily meals is a tedious task. Therefore, various techniques for recommending (providing) recipe information to users have been proposed.
For example, Patent Document 1 describes a technique for providing menu information using ingredients suitable for a user's taste by using cooking menu information, food material inventory information, and user's taste information.
Further, Patent Document 2 describes a technique for ordering a lunch box set to a menu schedule selected by the user among menu schedules according to the user's health condition, living environment and disease.
Further, Patent Document 3 describes a technique in which a previously recommended recipe is stored as an already-existing recipe, and a recipe for excluding a recipe overlapping the already-existing recipe and providing the remaining recipe is provided.

However, since the menu provided by the technique described in Patent Document 1 is limited to the menu including the material of the user's preference, the options that can be selected by the user become a rut.
Further, since the menu provided by the technique described in Patent Document 2 is limited to the menu according to the health condition, living environment and disease, there is a problem that the choices that can be selected by the user become one pattern.
Further, the recipe provided by the technique described in Patent Document 3 can be prevented from being provided again within a predetermined period, but there is a problem that it is not possible to flexibly respond to the tendency of the user to select a recipe. is there.
Therefore, the present invention provides a service capable of providing information for a timeless meal in consideration of the tendency of the user to select a menu while suppressing the troublesomeness of thinking about daily meals.

The information processing apparatus according to the present invention acquires meal information including at least a usage time corresponding to a user specifying unit that identifies a target user to whom information is presented and an information provider user related to the specified target user. The most used of the meal information acquisition unit, the usage cycle specifying unit that specifies the usage cycle for each cooking category based on the usage time included in the acquired meal information, and the usage time included in the acquired meal information. Based on the recommended category identification unit that specifies the cooking category to be the recommended category based on the late final usage time, the specified usage cycle, and the presentation time for each cooking category calculated based on the recommended category, and the recommended category. The cooking category has a hierarchical structure, and the recommended category specifying unit has a specified usage cycle equal to or less than a predetermined lower limit threshold. Or, when the usage cycle is less than or equal to the lower limit threshold value, the usage cycle and the presentation time of the lower category of the cooking category are acquired to specify the recommended category.
As a result, information (recommended category) that captures the potential needs of the user is presented.

The information processing apparatus described above may further include a presentation time adjusting unit that adjusts the presentation time of the specified recommendation category based on the use of the cooking category related to the specified recommendation category.
As a result, information is presented when a similar cooking category is used within a predetermined period or in consideration of the user's future schedule.

The cooking category has a hierarchical structure, and the recommended category specifying unit of the information processing device has a usage cycle of less than or equal to the lower limit threshold when the specified usage cycle is equal to or less than a predetermined lower threshold. The recommended category may be specified by acquiring the usage cycle and the presentation time for the subcategories of the cooking category.
As a result, it is not necessary to acquire the usage cycle and presentation time for all cooking categories.

The recommended category has a hierarchical structure, and the presentation time is calculated for a cooking category whose usage cycle is equal to or greater than the lower limit threshold value among the cooking categories, and the recommended category specifying unit of the information processing apparatus described above. May specify the recommended category from the cooking categories whose specified utilization cycle is equal to or larger than a predetermined lower limit threshold value.
As a result, the presentation time is not calculated for the cooking category whose usage cycle is too short.
For example, the presentation time is calculated for the lower cooking category. As a result, the same cooking category is not frequently presented as a recommended category.

The presentation control unit of the information processing apparatus may assign a priority to each of the recommended categories and perform the presentation according to the priority.
As a result, the more meaningful the information is to the user, the higher the priority can be.

The meal information acquisition unit of the information processing device may determine the acquisition start time of the meal information based on the usage cycle, and may acquire the meal information from the acquisition start time to the present.
As a result, the range (period) of acquiring meal information for each process from the next time onward is determined based on the usage cycle calculated once.

When the related user related to the target user is registered, the meal information acquisition unit of the information processing device described the meal information of the target user and the related user whose meal information is enriched. May be obtained.
As a result, the usage cycle and the presentation time are calculated based on the rich meal information, and the recommended category specified by the usage cycle is presented.

The information processing method according to the present invention acquires meal information including a user identification step for specifying a target user to whom information is presented, and at least a usage time corresponding to an information provider user related to the specified target user. The most used of the usage cycle specifying step for specifying the usage cycle for each cooking category based on the meal information acquisition step to be performed and the usage time included in the acquired meal information, and the usage time included in the acquired meal information. Based on the recommended category identification step to specify the cooking category to be the recommended category based on the late final usage time, the specified usage cycle, and the presentation time for each cooking category calculated based on the recommended category, and the recommended category. The cooking category has a hierarchical structure, and the specified usage cycle is a predetermined lower limit threshold value in the recommended category specifying step. The recommended category is specified by acquiring the usage cycle and the presentation time for the subcategories of the cooking category whose usage cycle is equal to or less than or less than the lower limit threshold.
This information processing method provides an environment in which it is possible to provide information for a timeless meal in consideration of the tendency of the user to select a menu while suppressing the troublesomeness of thinking about daily meals.
The program according to the present invention is a program that causes an information processing apparatus to execute a process to be executed as the above information processing method. The above information processing apparatus is realized by these programs.

According to the present invention, it is possible to provide a service capable of providing information for eating a meal that does not get tired, while suppressing the troublesomeness of thinking about daily meals and considering the tendency of the user to select a menu.

It is explanatory drawing which shows the whole structure including the information processing apparatus of embodiment of this invention. It is a figure which shows the functional structure of the recipe management server. It is a block diagram of a computer device. It is a figure which shows the example of the user DB. It is a figure which shows the example of the meal information DB. It is a figure which shows an example of the processing flow. It is a flowchart which shows the recommendation information acquisition process. It is a flowchart which shows a batch process. It is a flowchart which shows the meal information acquisition process. It is a flowchart which shows the use cycle specifying process. It is a flowchart which shows the recommendation information acquisition process in 2nd Embodiment. It is a flowchart which shows the 2nd example of a batch process. It is a flowchart which shows the presentation time adjustment process in the 2nd example of a batch process. It is a flowchart which shows another example of the presentation time adjustment processing in the 2nd example of a batch process. It is a flowchart which shows the presentation time adjustment process in 3rd example of a batch process. It is a flowchart which shows the meal information acquisition process in 4th example of a batch process. It is a flowchart which shows the use cycle specifying process in 4th example of a batch process. It is a flowchart which shows the modification 2 of the information providing source user identification processing. It is a flowchart which shows the modification of the presentation time calculation process. It is a figure which shows the example of the hierarchical cooking category.

Hereinafter, embodiments will be described in the following order.
<1. Overall configuration>
<2. Hardware configuration>
<3. DB>
[3-1. User DB]
[3-2. Recipe DB]
[3-3. Search DB]
[3-4. Meal information DB53]
[3-5. Web page DB]
<4. Process flow>
[4-1. First Embodiment]
[4-2. Batch processing]
[4-3. Second Embodiment]
[4-4. Second example of batch processing]
[4-5. Third example of batch processing]
[4-6. Fourth example of batch processing]
<5. Modification example>
[5-1. Modification example of information provider user identification process 1]
[5-2. Modification example of information provider user identification process 2]
[5-3. Modification example of presentation time calculation process]
<6. Summary>
<7. Programs and storage media>

<1. Overall configuration>

First, the overall configuration of the embodiment of the present invention will be described.
In the following description, a cooking recipe (hereinafter, simply referred to as a recipe) will be described as an example of a recipe. The recipe contains information such as cooking procedures, ingredients used, and cooking utensils.
In addition, the information provided to the user for a timeless meal (hereinafter referred to as recommended information) is information that the user can refer to when eating, and specifically, the ingredients used and the cooking method are described. It may be one or more recipe information described, or it may be information on a cooking category (such as "ramen" or "curry") as information for selecting a store when eating out.

As an example of a portal site for providing a service capable of searching for a recipe and posting a recipe according to a search query, a recipe site operated by the recipe management server 1 is taken as an example.

The overall configuration including the information processing apparatus of the present invention is shown in FIG.
The recipe management server 1 is connected to the user terminals 3, 3, 3, ... Via the communication network 2 in a state in which they can communicate with each other. Further, the recipe management server 1 includes a user DB (Database) 50 that stores information about the user, a recipe DB 51 that stores information about the recipe, a search DB 52 that stores information about search queries and search results, and user's meal information. It is connected to the meal information DB 53 in which (described later) is stored and the web page DB 54 in which the web page data of various web pages constituting the recipe site are stored.
The recipe management server 1 corresponds to the embodiment of the information processing apparatus of the present invention.

The recipe management server 1 is an information processing device that performs a process of managing a recipe posted by a user and a process of presenting a recipe corresponding to a search query. In addition, the recipe management server 1 executes various processes for presenting recommendation information (recipe information and cooking category information) to be presented to the user. The specific configuration will be described later.

The configuration of the communication network 2 is not particularly limited, and for example, the Internet, an intranet, an extra net, a LAN (Local Area Network), a CATV (Community Antenna TeleVision) communication network, a virtual private network, and a telephone line. Networks, mobile communication networks, satellite communication networks, etc. are assumed.
Further, various examples are assumed for the transmission medium constituting all or a part of the communication network 2. For example, IEEE (Institute of Electrical and Electronics Engineers) 1394, USB (Universal Serial Bus), power line carrier, telephone line, etc., infrared rays 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 terrestrial digital networks.

The user terminal 3 is a terminal used by a user who posts a recipe to the recipe management server 1 and a user who searches and browses recipe information managed by the recipe management server 1. It is also a terminal used by a user who browses the recommendation information presented by the recipe management server 1.
On the user terminal 3, various transmission / reception processing, display processing, and the like are executed as necessary. Further, the user terminal 3 is, for example, a PC (Personal Computer) having a communication function, a feature phone, a PDA (Personal Digital Assistant), or a smart device such as a smartphone or a tablet terminal.

As shown in FIG. 2, the recipe management server 1 includes a recipe management unit 1a, a user management unit 1b, a meal information acquisition unit 1c, a usage cycle identification unit 1d, a presentation time calculation unit 1e, a presentation time adjustment unit 1f, and a recommendation category identification. It includes a unit 1g, a recommended recipe extraction unit 1h, and a presentation control unit 1i.

The recipe management unit 1a recipes the recipe information posted by the user (the recipe title, the ingredients used, the cooking method, the cooking category information to which the recipe belongs, etc. are the information associated with the identification information that identifies the user who posted the recipe information). It is managed by storing it in the DB 51. For example, a recipe for "vegetable curry" posted by a user is a recipe that belongs to the category "curry", and as information on ingredients used, "potato", "carrot", "onion", "broccoli", "tomato", etc. "Spring grass", seasonings (such as "salt" and "pepper"), and similar items (such as "curry roux") are associated and memorized.

In addition, the recipe management unit 1a manages the creation report posted for the posted recipe for each recipe. The creation report is an impression of the recipe when another user actually cooks using the posted recipe (for example, the deliciousness of the dish felt by the user who cooked and the ease of the cooking procedure, etc. ) Is a report. The creation report is managed in association with each recipe of the recipe DB 51.

The user management unit 1b performs various processes in order to manage information on users who use various services provided by the recipe management server 1.
For example, a user ID that can uniquely identify a user is associated with a name, age, gender, and contact information (telephone number, e-mail address, etc.) and stored in the user DB 50 for management. In addition, a process of acquiring user information from the user DB 50 is performed.

The meal information acquisition unit 1c performs a process of acquiring from the meal information DB 53 the meal information eaten and eaten before the processing time of the target user and the meal information estimated to be eaten and eaten in the future after the processing time.
Various meal information stored in the meal information DB 53 will be described later.

The period for which the meal information is acquired may be a predetermined period such as the latest one month, or may be a period different depending on the user. In addition, the period may be determined according to the usage cycle of the cooking category described later.
Specific examples will be described later.
The meal information acquisition unit 1c determines the acquisition start time according to a predetermined period or the calculated acquisition target period, and acquires the meal information from the acquisition start time to the present. For example, when the acquisition target period is 10 days, the acquisition start time 10 days before the present is calculated, and the meal information up to the present is acquired from there.

In addition, some examples can be considered for the user who is the target of acquiring the meal information. For example, it may be the user himself / herself who logs in and receives the presentation of the recommendation information regarding the meal, or the user designated by the user who receives the presentation of the recommendation information (for example, the husband of the user). Further, among the users who receive the information and the related users, the user who has the most complete meal information may be used.
Of course, the meal information of all the plurality of users (for example, the user who receives the information presentation and the three users of the husband and the child) may be acquired.

The usage cycle specifying unit 1d calculates for each user the cycle of using the dishes belonging to the cooking category for each cooking category based on the past meal information. The use of dishes belonging to a cooking category means the use of recipes related to dishes belonging to the cooking category (including the state in which the recipe is presumed to be used) and eating and drinking of dishes belonging to the cooking category (that is, eating out). Is. That is, it means that the food belonging to the cooking category was eaten or eaten in some way.

The presentation time calculation unit 1e calculates the presentation time for each cooking category based on the usage cycle and the final usage time of the cooking category. The last use time is information indicating the time (or time) when the cooking category was last used.
The presentation time calculation unit may calculate for each category level in the hierarchical cooking category, or may calculate only a predetermined category level. Further, it may be calculated for different category levels for each cooking category, or it may be calculated for different numbers of category levels for each cooking category.

The presentation time adjustment unit 1f executes a process of adjusting the presentation time calculated for each cooking category according to various factors. That is, for a cooking category whose presentation time is 3 days later, a process of setting (that is, adjusting) 2 days earlier, which is one day earlier, is executed in consideration of various factors described later.
In addition, the presentation time will be adjusted based on the use of similar cooking categories. For example, when the cooking category of "soba" has been used most recently, a process of postponing (that is, extending it to the back) the presentation time of the cooking category of "udon" similar to "soba" is executed.
Various specific examples will be described later.

The recommended category specifying unit 1g refers to the presentation time finally determined by the presentation time calculation unit 1e and the presentation time adjustment unit 1f, and executes a process of specifying the cooking category whose presentation time has arrived as the recommended category.

The recommended recipe extraction unit 1h executes a process of extracting recipes belonging to the recommended category.

The presentation control unit 1i executes a process for presenting the extracted recipe to the user terminal 3. When there are a plurality of pieces of information to be presented, the presentation priority may be given to each piece of information. That is, the information is presented to the user terminal 3 according to the presentation priority.
For example, when presenting a plurality of recipes as an example of presenting recommendation information, the information is transmitted so that the recipes are lined up on the screen of the user terminal 3 according to the presentation priority.

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

<2. Hardware configuration>

FIG. 3 is a diagram illustrating the hardware of the recipe management server 1 and the user terminal 3 shown in FIG. 1, and the hardware of the user DB 50, the recipe DB 51, the search DB 52, the meal information DB 53, and the web page DB 54. The CPU (Central Processing Unit) 101 of the computer device in each server, terminal, and DB is loaded into the RAM (Random Access Memory) 103 from the program stored in the ROM (Read Only Memory) 102 or the storage unit 108. Perform various processes according to the program. The RAM 103 also appropriately stores data and the like necessary for the CPU 101 to execute various processes.
The CPU 101, ROM 102, and RAM 103 are connected to each other via the bus 104. An input / output interface 105 is also connected to the bus 104.
The input / output interface 105 includes an input device 106 including a keyboard, a mouse, and a touch panel, a display including an LCD (Liquid Crystal Display), a CRT (Cathode Ray Tube), an organic EL (Electroluminescence) panel, and an output including a speaker. A device 107, a storage unit 108 composed of an HDD (Hard Disk Drive), a flash memory device, and the like, and a communication unit 109 that performs communication processing and inter-device communication via the communication network 2 are connected.
A media drive 110 is also connected to the input / output interface 105 as needed, and a removable media 111 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory is appropriately attached to write information to the removable media 111. Reading is performed.

In such a computer device, data and programs can be uploaded and downloaded by communication by the communication unit 109, and data and programs can be transferred via the removable media 111.
When the CPU 101 performs processing operations based on various programs, information processing and communication described later can be performed in each of the recipe management server 1, the user terminal 3, the user DB 50, the recipe DB 51, the search DB 52, the meal information DB 53, and the web page DB 54. Will be executed.
The information processing devices constituting the recipe management server 1, the user terminal 3, and the user DB 50, the recipe DB 51, the search DB 52, the meal information DB 53, and the web page DB 54 have a single computer device as shown in FIG. It is not limited to being configured, and may be configured by a plurality of systemized computer devices. The plurality of computer devices may be systematized by a LAN or the like, or may be arranged in a remote place in a state where communication is possible by a VPN (Virtual Private Network) using the Internet or the like.

Each function as the recipe management server 1 is a function realized by a process executed by the CPU 101 according to a program in the information processing apparatus. However, all or part of the processing of each configuration described below may be realized by hardware.
Further, when each function is realized by software, it is not necessary for each function to be realized by an independent program. The processing of a plurality of functions may be executed by one program, or one function may be realized by the cooperation of a plurality of program modules.

<3. DB>

Each DB managed by the recipe management server 1 will be described. Each DB may be realized in any form as long as the recipe management server 1 is accessible. For example, all of each DB may be formed in a storage unit in the same system as the recipe management server 1, a part or all of each DB may be separated, or a computer system in a remote location or the like. It may be provided in. Of course, it is not necessary for each DB to be formed in one device (for example, one HDD or the like). Further, it is not necessary for each of the DBs to be configured as one DB. For example, the information stored as the user DB 50 may be stored and managed by a plurality of user DBs (for example, a user DB for login and a user DB for transactions). Each DB described below merely exemplifies a storage unit of information related to the processing of the embodiment in the form of one DB.

[3-1. User DB]
The user DB 50 stores information on the user who receives the service provided by the recipe management server 1. For example, personal information such as a login password, name, age, gender, and e-mail address is associated with and stored in one user ID (Identification) that can identify one user. In addition, the usage cycle and regular meal information for each cooking category are also stored in association with the user ID.

Here, the regular meal information will be described. Regular meal information is information on meals that users eat and drink on a daily basis, and is different for each user. For example, a regular meal for a user is "rice,""bread," or "miso soup." These recipes are eaten and eaten on a daily basis so that it is inappropriate to calculate the usage cycle. Such a recipe (or cooking category) is not subject to calculation such as presentation time, and does not have to be included in the recommendation information presented to the user.
The recipe (or cooking category) stored as regular meal information is a cooking category whose usage cycle is shorter than a predetermined period (for example, one day), and there is no cooking category that cannot be further subdivided (that is, there is no lower cooking category). ) Belongs to. Also, such recipes are widely combined with other recipes. Specifically, for users who add salad to every meal, salad becomes a regular meal. That is, for such a user, calculating the presentation time from the salad usage cycle and providing the information to the user is unlikely to provide valuable information to the user.

Even if the usage cycle is shorter than the predetermined period, if there is a lower cooking category, the presentation time is calculated in the lower cooking category. Specifically, even if the usage cycle of the cooking category of "noodles" is one day, it is longer than one day in the subcategories such as "ramen", "pasta", "udon", and "soba". There is a high possibility that the usage cycle will be appropriate.
Therefore, the presentation time is calculated from the usage cycle of the cooking categories of "ramen" and "pasta".

In addition, the user DB 50 may store preference information for each user. The preference information includes information on the user's favorite ingredients (favorite ingredients) and disliked ingredients (non-favorite ingredients) determined by the recipe management server 1 according to the behavior of the user such as searching and browsing the recipe information and cooking information. These are the user's favorite ingredients (favorite ingredients) and disliked ingredients (non-favorite ingredients) determined by the recipe management server 1 based on the posted information (text information, tag information, image information, etc.) related to the user. The preference information is used when the user performs a recipe search.

Specifically, various information stored in the user DB 50 will be described with reference to FIG.
FIG. 4 shows a part of the information about the user A stored in the user DB 50. The login password, name, age, gender, and e-mail address are associated with the user ID and stored. In addition, usage information for each cooking category is stored. The usage information is information in which a usage cycle, a final usage time, and a presentation time are associated with a cooking category ID, and is information used for presenting recommendation information to a user.

[3-2. Recipe DB]
The recipe DB 51 is a DB in which information on recipes posted by users is stored. Specifically, for the recipe ID that can identify each recipe, the user ID that identifies the user who posted the recipe, the posting date and time information, the category information to which the recipe belongs, and the information on the ingredients used in the recipe (quantity, etc.) (Including), recipe cooking procedures, image information such as cooking images (images of finished dishes and images of dishes in the middle of cooking), and posted by other users who actually used the recipe (created the dish). The creation report ID that identifies the created creation report is associated and stored.

Further, the URL (Uniform Resource Locator) information of the recipe detail page may be stored in association with the recipe ID.
Further, the recipe DB 51 stores the information of the creation report posted for each recipe. As the information of the created report, text data indicating the contents of the report, an image of cooked food, a user ID that can identify the poster, posting date and time information, and the like are stored.

[3-3. Search DB]
The search DB 52 is a DB in which search results corresponding to the search query are stored. Specifically, multiple recipes are linked and stored as search results according to a search query such as a cooking name such as "curry" or "hamburger" or an ingredient name such as "mushroom" or "tomato". ..
For example, the search process is executed according to the search query specified by the user, and the search result extracted as a result is associated with the search query and stored in the search DB 52. By linking in this way, when there is a new search request, there is an increased opportunity to present the search result using the previous search result without executing the search process.
It should be noted that the search process using the search keyword may be executed periodically in advance, and the search result extracted as a result may be associated with the search keyword and stored in the search DB 52.

[3-4. Meal information DB53]
The meal information DB 53 stores meal information that the user has eaten in the past and meal information that is estimated to be eaten in the future as history information.
For example, information on recipes used in the past or estimated to be used in the future, information on dishes eaten in the past or estimated to be eaten in the future, information on cooking categories, and the like. In each meal information stored in the meal information DB 53, the meal information of the information user of the cooking category is stored.
The information stored in the meal information DB 53 as the meal information eaten and eaten in the past is identified or estimated to be the recipe used by the user based on, for example, the recipe usage history, browsing history, search history, etc. included in the history information. Based on the recipe information, browsing history and search history of restaurants and menus included in the history information, information on dishes and cooking categories that are specified or estimated to have been eaten by the user during eating out, and posted information. Based on the text information, tag information, image information, and the like included in the above, the information is information on the food or cooking category that is specified or estimated that the user has eaten or eaten. In addition, the information may be obtained in advance from the menu table for food and drink.
The information stored in the meal information DB 53 as the meal information estimated to be eaten in the future is obtained from the information on the schedule of the meal to be eaten in advance (for example, the menu information of the school lunch and the menu information of the employee cafeteria) as described above. This is the information obtained. Further, it may be information on a dish or a cooking category specified or estimated based on information on a service that provides a dish such as a restaurant that is frequently used. It should be noted that such information may be acquired from a web page or the like related to a service that provides food such as a restaurant, or information input by a user may be acquired.
Each meal information as history information stored in the meal information DB 53 includes information on a cooking category.
Specifically, as shown in FIG. 5, the usage history of a plurality of cooking categories is stored as meal information for the user ID that identifies the user. The date and time of use (time of use), cooking category ID, acquisition route, and usage pattern are linked and stored for one usage history.

FIG. 5 is an example in which the history is arranged in order of usage date and time. The cooking category ID can uniquely identify the cooking category.

Here, the cooking category will be described. The cooking categories are hierarchized, for example, the types as major categories such as "Japanese food" and "Western food", and the regional level types such as "Japanese food", "Chinese food", "Italian food", "French food", and "Thai food". There are level types such as "curry", "hamburger", and "ramen" according to the cooking name, and fine level types such as "beef curry", "chicken curry", and "keema curry".

There are various levels of cooking types. For example, as shown in (A) below, the middle classification may be a classification of staple foods such as meat dishes, fish dishes, and vegetable dishes, or as shown in (B) below. , The major classification may be "staple food", "side dish", "side dish", etc.
(A) Major classification: Japanese food (Other: Western food, etc.)
Middle classification: Meat dishes
Subclassification: Nikujaga / Beef boiled in soy sauce, etc.
Middle classification: Fish dishes
Subclassification: Mackerel miso boiled / salmon chan-chan grilled, etc.
Middle classification: Vegetable dishes
Sub-category: Roasted roasted vegetables / Kinpira burdock, etc. (B) Major classification: Staple food (Other: Side dishes / Side dishes, etc.)
Middle classification: Meat dishes
Subcategory: hamburger / croquette, etc.
Middle classification: Fish dishes
Subcategory: Octopus frit / cod meuniere, etc.
Middle classification: Vegetable dishes
Subclassification: Pot-au-feu / vegetables boiled in tomato, etc.

In the following examples, each explanation will be given using an example in which the cooking categories are layered in three stages.
The major categories in the cooking category are classified according to the main ingredients such as "rice", "noodles", "meat dishes", "fish dishes", and "curry".
Then, in the subcategory (middle category) of the cooking category of "noodles", cooking categories such as "ramen", "pasta", "udon", and "soba" are provided.
Further, in the subcategory (sub-category) of the cooking category of "ramen", cooking categories such as "soy sauce ramen", "miso ramen", "salt ramen", and "pork bone ramen" are provided.

In the following description, the major cooking categories (such as "noodles") will be referred to as category level 1 cooking categories. In addition, the lower cooking category (middle classification such as "ramen") is described as the cooking category of category level 2. Similarly, a lower cooking category (sub-category such as "soy sauce ramen") is described as a category level 3 cooking category. That is, it is set so that the numerical value indicating the category level increases as the lower category (subdivided category) increases.

Various recipes belong to each cooking category. For example, the recipe "My home miso ramen" is a recipe that belongs to the cooking category of "miso ramen", a recipe that belongs to the cooking category of "ramen", and a recipe that belongs to the cooking category of "noodles".

Returning to the explanation of FIG. 5, the cooking category ID is configured so that the relationship between the cooking categories can be understood in the hierarchical cooking categories.
Specifically, it is composed of a two-digit numerical value indicating a cooking category of category level 1, a two-digit numerical value indicating a cooking category of category level 2, and a single-digit numerical value indicating a cooking category of category level 3. .. For example, the cooking category ID set to "C01002" specifies a numerical value "01" for specifying a cooking category of category level 1, a numerical value "00" for specifying a cooking category of category level 2, and a cooking category of category level 3. It is configured to include the numerical value "2".
That is, it can be seen that the cooking category whose category ID is "C01002" and the cooking category whose category ID is "C01013" belong to the same cooking category at category level 1 and to different cooking categories at category level 2.

Next, the acquisition route will be described. The acquisition route is information indicating by what route the meal information as the usage history was acquired. For example, the history information whose acquisition route is "posted by SNS (Social Networking Service)" is history information estimated to have eaten or drank a dish belonging to the cooking category based on the article posted on SNS. In addition, the history information defined as "recipe use" is history information presumed to have eaten or eaten a dish belonging to the cooking category based on the posting of a creation report or the browsing history of the recipe. Further, the history information referred to as "school lunch information" is history information presumed to have eaten or eaten a dish belonging to the cooking category from information on a cooking schedule such as a menu table for school lunch. These pieces of information are used, for example, as the certainty of historical information (that is, the certainty of whether or not a person has really eaten or eaten).

Finally, the usage pattern will be described.
The usage pattern indicates the usage pattern of the cooking category. For example, if eating and drinking at a store such as a set meal shop is presumed, it is considered as "restaurant". Also, if the acquisition route is "recipe use", if the use of the recipe (that is, the use of the cooking category) is estimated by printing the recipe, it will be "printed" and the recipe will be used by posting the creation report. If is inferred, it is referred to as "posting a creation report", and if the use of the recipe is inferred by browsing the recipe for a predetermined time, it is referred to as "browsing". The usage pattern information is used, for example, as the certainty of the history information together with the acquisition route.

[3-5. Web page DB]
The web page DB 54 stores data of various web pages provided to the user by the recipe management server 1. Specifically, it is web page data such as a recipe search page, a special page, a search result page, a recipe detail page, and a user page.
As the web page data, URL (Uniform Resource Locator) information of the web page and placement information of objects (images, texts, banners, etc.) placed on each web page are stored. The placement information is information that describes the placement mode (position, size, color, etc.) of each object on the web page.
The information stored in the web page DB 54 may be stored in a structured document file such as HTML (Hyper Text Markup Language) or XHTML (Extensible HyperText Markup Language).

<4. Process flow>

Various processes executed by the recipe management server 1 will be described.

[4-1. First Embodiment]
First, the overall flow of the first embodiment when the user requests recommendation information for meals (information on recommended categories and recommended recipes) will be described with reference to FIG.

In order for the user to obtain the recommendation information, it is necessary to log in to the service operated by the recipe management server 1.
Therefore, in response to the user performing the operation of displaying the login screen using the user terminal 3, the user terminal 3 requests the login screen information (that is, the web page data for displaying the login screen) in step S101. To execute.

When the 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 the login screen information transmission process in step S201.
As a result, 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.
At this time, the recipe management server 1 may store the display of the login screen on the user terminal 3 as a history (that is, the browsing history of the login screen).

Next, in step S102, the user terminal 3 executes a login information transmission process 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 the authentication process in step S202, executes the process of storing the login history in the following step S203, and the authentication result in step S204. Execute notification processing.
Specifically, the recipe management server 1 compares the user ID and password entered on the user terminal 3 with the information stored in the user DB 50, determines whether or not the user can log in, and authenticates the login possibility information. As a result, the user terminal 3 is notified. The authentication result may be transmitted to the user terminal 3 and the web page data of the top page of the recipe site may be transmitted. As a result, the user is authenticated and the top page of the recipe site is displayed on the user terminal 3.

The series of flows shown in FIG. 6 shows a case where it is determined that login is possible in the authentication process of 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.

Subsequently, in step S103, the user terminal 3 executes a process of requesting recommendation information based on the user operation. This user operation is, for example, an operation of pressing a "view recommended information" button for obtaining recommended information provided on a web page.

When the recommendation information request is transmitted from the user terminal 3 to the recipe management server 1, the recipe management server 1 executes the recommendation information acquisition process in step S205. The recommendation information acquisition process is a process of acquiring a cooking category (that is, a recommendation category) presented as recommendation information to the user terminal 3.
The details of the recommendation information acquisition process in step S205 will be described with reference to FIG. 7.
The recipe management server 1 selects one cooking category in step S301, and acquires the presentation time information of the cooking category in the following step S302.
The cooking category presentation time may be calculated in advance by batch processing or the like before executing each of the processes of FIGS. 6 and 7, and may be stored in the user DB 50 shown in FIG. The details of batch processing will be described later.

Subsequently, in step S303, the recipe management server 1 determines whether the presentation time satisfies the condition for the cooking category (that is, whether the presentation time has passed at the current time).
When it is determined that the presentation time satisfies the condition, the recipe management server 1 selects the cooking category as the recommended category in step S304.

After step S304 or after determining in step S303 that the presentation time does not satisfy the condition, the recipe management server 1 determines in step S305 whether or not there is a cooking category that has not been processed.
If it is determined that there is a cooking category that has not been processed, the recipe management server 1 re-executes the processes of steps S301 to S305.
On the other hand, when it is determined that there is no cooking category that has not been processed, the series of processing shown in FIG. 7 is terminated.
That is, by executing the process shown in FIG. 7, the cooking category whose presentation time has come is selected as the recommended category.

Returning to the description of FIG.
The recipe management server 1 that has acquired the recommendation category information as the recommendation information executes the priority assignment process in step S206.
The priority assignment process is a process to be executed when there are a plurality of recommended categories, and the process of step S206 is not executed when the acquired recommendation category is one.

There are several possible examples of the prioritization process. For example, it is conceivable to raise the priority of recommended categories that have a long elapsed time since the last use time. Specifically, in the recommendation category A whose last use time is yesterday and the recommendation category B one week ago, the priority of the recommendation category B is raised over the recommendation category A.

Further, as another example of the priority assignment process, it is conceivable to raise the priority of the recommendation category A having a short usage cycle. Specifically, in the recommendation category A having a usage cycle of one week and the recommendation category B having a usage cycle of one month, the priority of the recommendation category A is higher than that of the recommendation category B. This is due to the impact of not using low priority recommendation categories. That is, when the one-week usage cycle is extended by one day and the one-month usage cycle is extended by one day, it is considered that the one-week usage cycle is extended by one day to have a relatively large effect. .. Therefore, raise the priority of the recommended category, which has a large impact if it is not used.

The recipe management server 1 that gives priority to the recommended category performs the presentation process in step S207.
In the presentation process, the recipe management server 1 transmits the information of the recommended category to which the priority is given to the user terminal 3. For example, HTML data for displaying a web page in which information on recommended categories is arranged in order of priority is transmitted.

[4-2. Batch processing]
The batch process executed by the recipe management server 1 will be described. In the batch process, a process of calculating the presentation time for each cooking category is executed.
Specifically, it will be described with reference to FIG.

The batch process shown in FIG. 8 is a process for calculating the presentation time to one user. That is, when calculating the presentation time for all users, the series of processes shown in FIG. 8 is repeatedly executed for the number of users. Further, when there is only one user who needs to perform batch processing, the series of processing shown in FIG. 8 may be performed only once.

First, in step S401, the recipe management server 1 executes a process of identifying a user whose recipe information is to be acquired. While the user who is the target user for presenting the recommendation information is described as the target user, the user who is the target for acquiring the recipe information is the user who provides the information for presenting the recommendation information. Describe.
That is, the recommendation information determined based on the information of the information providing source user is presented to the target user.

The target user and the information provider user are not necessarily the same user. For example, a case where the user A receives the service of the recipe management server 1 using the user terminal 3 will be described. That is, the target user is the user A.
At this time, the information providing source user may be the user A himself / herself who receives the service of the recipe management server 1, or may be the user B designated by the user A.

Specifically, when the user A receives the recommendation information based on his / her own meal information, both the target user and the information providing source user are the user A.
When the user A receives the recommendation information based on the meal information of the spouse user B, the target user is the user A and the information provider user is the user B specified by the user A.
In other words, determining the information provider user determines who's dietary information is used to calculate when to submit a cooking category.

Subsequently, in step S402, the recipe management server 1 executes a process of acquiring the meal information of the information providing source user from the meal information DB 53.
Some examples of the meal information acquisition process will be described. Here, one example will be described with reference to FIG. 9, and other examples will be described later.
In the meal information acquisition process, the recipe management server 1 acquires the meal information in the latest predetermined period as in step S501. The predetermined period is set as a fixed numerical value (period) such as one month. It is desirable that the fixed predetermined period is a period sufficient to calculate the usage cycle of the cooking category. That is, it is desirable that one cooking category is used a plurality of times.

Returning to the description of FIG.
Subsequently, the recipe management server 1 executes the usage cycle specifying process in step S403.
The usage cycle specifying process will be described with reference to FIG.
The usage cycle specifying process is a process of specifying (calculating) the usage cycle for each cooking category based on the meal information of the information providing source user (information acquired in the previous step S402).

First, the recipe management server 1 executes a process of selecting one cooking category in step S601.
Subsequently, the recipe management server 1 confirms in step S602 whether the selected cooking category includes (belongs to) the regular meal information.

If it is determined that the regular meal information is not included, the recipe management server 1 acquires the last usage date and time (last usage time) of the selected cooking category in step S603, and further the previous usage date and time (the previous usage date and time (). (Usage time) is acquired in step S604. Information on each usage date and time is acquired from the meal information DB 53.
The usage date and time is the time when the cooking category described above is used (or date information may be used), that is, the date and time when the recipe belonging to the cooking category is used and the date and time when the food belonging to the cooking category is eaten out. ..
In the following step S605, the recipe management server 1 executes a process of calculating the usage cycle from the difference between these two usage dates and times.
It should be noted that the average difference may be calculated from more usage dates and times instead of the two usage dates and times as the usage cycle.

After executing step S605, the recipe management server 1 confirms in step S606 whether or not there is a cooking category that has not been processed.
If it is determined that there is a cooking category that has not been processed, the recipe management server 1 executes the process of step S601 again.
On the other hand, when it is determined that there is no cooking category that has not been processed, the recipe management server 1 ends a series of processes shown in FIG.

If it is determined in step S602 that the regular meal information is included, the process of step S606 is executed without executing each of the processes of steps S603 to S605. This is because it is not necessary to calculate the usage cycle because it is inappropriate to present the cooking category including the regular meal information as the recommendation information as described above.

Returning to the description of FIG. 8 again.
The recipe management server 1 that has calculated the usage cycle for all cooking categories executes a process of calculating the presentation time from the usage cycle in step S404.
The presentation time is calculated from the final usage time and the usage cycle when the next usage is expected as the presentation time. Specifically, for example, when the final usage time is 3 days before and the usage cycle is 10 days, the presentation time is 7 days later.
By executing the series of processes shown in FIG. 8, the presentation time for each cooking category is calculated. Then, when a request for recommendation information is received from the user, the recommendation category based on the presentation time is presented by executing each of the processes of steps S205 to S207 of FIG.

It should be noted that the cooking category whose presentation time has passed by the time the request for recommendation information from the user is received may or may not be presented to the user. At this time, it may be decided whether or not to present depending on the length of time passed. Specifically, if the time has not passed since the passing, the cooking category is presented to the user as a recommended category, but if the time has passed since the passing, the cooking category is recommended. It is conceivable that it will not be presented as information.
Of course, the recommendation information may be presented to the user regardless of the length of time passed.

The presentation time of step S404 in FIG. 8 may be calculated for all cooking categories or for some cooking categories. When calculating the presentation time for some cooking categories, the usage cycle of some cooking categories may be calculated also in the usage cycle specifying process shown in FIG.
As an example of calculating the presentation time for some cooking categories, for example, it is conceivable to calculate the presentation time for the cooking category of category level 2. This is because the cooking category belonging to category level 1 has a too short usage cycle and the presentation time comes frequently, and the cooking category belonging to category level 3 has a too long usage cycle and the presentation time does not come very often. It is a consideration.

[4-3. Second Embodiment]
In the second embodiment, the recipe information (recommended recipe) is presented instead of presenting the cooking category (recommended category) as the recommended information.
Specifically, it will be described with reference to FIGS. 6 and 11.

As shown in FIG. 6, when the recipe management server 1 receives the recommendation information request from the user terminal 3, the recipe management server 1 acquires the recommendation information to be presented to the user in step S205, gives a priority in the subsequent step S206, and presents it in step S207. Execute the process.
In the second embodiment, the processing content of the recommendation information acquisition process in step S205 is different.

An example of the recommendation information acquisition process in the second embodiment is shown in FIG.
In the recommendation information acquisition process, as shown in FIG. 11, the recipe management server 1 acquires the presentation time for each cooking category in steps S301 to S304, and selects the cooking category whose presentation time has arrived as the recommendation category. Execute. Since these processes are the same as the processes described with the same reference numerals in FIG. 7, detailed description thereof will be omitted.

The recipe management server 1 that has selected the recommended category executes a process of extracting a recipe belonging to the recommended category as a recommended recipe in the following step S306.
For example, when the recommended category is "curry", recipes such as "home seafood curry" and "indian curry with plenty of tomatoes" belonging to the cooking category "curry" are extracted as recommended recipes.

In the extraction of the recommended recipes in step S306, only the recipes belonging to the recommended category that are appropriate to be recommended to the user may be extracted as the recommended recipes.
The recipes that are appropriate to be recommended to the user are, for example, a recipe containing the user's favorite ingredients and a recipe not containing the unfavorable ingredients. In addition, recipes that can be cooked by the user (for example, the user possesses cooking utensils used in the cooking method) and recipes that are easy for the user to cook (for example, including frequently used cooking processes, cooking methods, or ingredients). Etc. are extracted as recommended recipes. As a result, a recipe more appropriate for the user can be presented as a recommended recipe, and a recipe more inappropriate for the user can be prevented from being presented as a recommended recipe.

The recipe management server 1 that has completed the process of FIG. 11 for all cooking categories and extracted the recommended recipe executes the priority assignment process in step S206 of FIG. 6, and executes the presentation process in step S207.
In the priority assignment process of step S206, the priority assignment process for the recommended recipe is performed. The priority may determine the recommendation category to be given a high priority, and may increase the recommendation recipe belonging to the recommendation category to which the high priority is given. In addition, priority may be given to each recommended recipe without considering which cooking category it belongs to.
In this case, for example, it is conceivable to raise the priority of recipes containing ingredients that the user likes, recipes that do not contain ingredients that the user does not like, recipes that the user can cook, and recipes that are easy for the user to cook. Also, recipes that are inappropriate to present to the user may be given lower priority. In addition, recipes that the user has never used may be given higher priority.

In the presentation process of step S207, the information of the recommended recipe to which the priority is given is transmitted from the recipe management server 1 to the user terminal 3. For example, HTML data for displaying a web page in which information on recommended recipes is arranged in order of priority is transmitted.

[4-4. Second example of batch processing]
A second example of batch processing will be described with reference to FIGS. 12 and 13.
In the second example of batch processing, a process of adjusting the calculated presentation time is executed.

First, the recipe management server 1 acquires the meal information of the information providing source user by executing steps S401 to S404 shown in FIG. 12, and executes a process of calculating the presentation time from the usage cycle for each specified cooking category. ..
Each process of steps S401 to S404 is the same process as each process described with reference to FIG. 8 with the same reference numerals, and details thereof will be omitted.

The recipe management server 1 that has calculated the presentation time executes a process of adjusting the presentation time in the following step S405.
There are several possible examples of the presentation timing adjustment process. First, the first example will be described with reference to FIG.

First, the recipe management server 1 selects one of the cooking categories targeted for the presentation time calculation process (step S404) in step S701. That is, one cooking category for which the presentation time has been calculated is selected.
Subsequently, in step S702, the recipe management server 1 acquires meal information (usage history) of another cooking category having a common upper category from the meal information DB 53.

Specifically, for example, cooking categories such as "ramen", "pasta", "udon", and "soba" belong to the subcategories of the cooking category "noodles". When the cooking category "udon" is selected in step S701, the other cooking categories having the same upper category are "ramen", "pasta", and "soba". Therefore, the process of step S702 is a process of acquiring the usage history for the cooking categories of "ramen", "pasta", and "soba".

The usage history information acquired in step S702 relates to the user who is the information provider in step S401 of the batch processing. For example, when there are a plurality of information providing source users, the usage history is also acquired for the plurality of users.

Subsequently, in step S703, the recipe management server 1 sets the latest predetermined period (predetermined) for the final usage time for each other cooking category (for example, the cooking categories of "ramen", "pasta", and "soba"). Judge whether or not it is within (may be time). That is, it is determined whether or not a dish belonging to another cooking category has been eaten or eaten within the latest predetermined period. The predetermined period is, for example, 3 days, which is a period for avoiding recommending similar recipes and cooking categories to the user.
In the determination process of step S703, if there is at least one cooking category in the other cooking category whose final usage time is within the latest predetermined period, the final usage time is within the latest predetermined period. Judge that there is.

When it is determined that the last use time of the other cooking category is within the latest predetermined period, the recipe management server 1 executes a process of adjusting the presentation time in step S704. That is, the presentation time is pushed back. Specifically, for example, since the time to present the cooking category "Udon", which has a usage cycle of one week, has arrived, I would like to present "Udon" to users as a recommended category, but the cooking category "Soba" was used yesterday. Therefore, the presentation time of the cooking category "Udon" will be moved back by a few days from today. The amount of movement at this time is set so that there is a week from the last use time (yesterday) of the cooking category "soba" to the usage cycle of the cooking category "udon" (that is, 7 days after yesterday). Alternatively, since the cooking category "udon" itself has not been used for one week, it may be set to be delayed by about half of the usage cycle (that is, 3 or 4 days).
By adjusting the presentation time according to the final usage time of other cooking categories (in other words, similar cooking categories), the recommendation information that is presumed to be unlikely to be selected by the user even if presented is transmitted. It is possible to control and suppress an increase in processing load caused by transmitting recommendation information having a relatively low priority.

After executing the process of step S704, or after determining in step S703 that the final use time of the other cooking category is not within the latest predetermined period, the recipe management server 1 presents the target cooking category (that is, presents) in step S705. It is determined whether or not the above processing has been applied to all of the cooking categories for which the timing was calculated).
If there is an unprocessed cooking category among the target cooking categories, the recipe management server 1 executes the process of step S701 again.
When there is no unprocessed cooking category among the target cooking categories, the recipe management server 1 ends the batch processing shown in FIG. 12 by ending the series of processing shown in FIG. 13.

In addition, instead of acquiring the last use time of another cooking category in which the upper category is common, the last use time of the upper category may be acquired. This is because when the lower category is used, the last use time of the lower category is updated and the last use time of the upper category is also updated.

Next, a second example of the presentation timing adjustment process will be described with reference to FIG.
The second example is the adjustment of the presentation time in consideration of the attributes of the food and drink that the user has eaten and eaten.
First, the recipe management server 1 selects one of the cooking categories targeted for the presentation time calculation process (step S404) in step S801. This process is the same as the process of step S701 in FIG.
Subsequently, in step S802, the recipe management server 1 acquires the meal information of the information providing source user (the user whose meal information is to be acquired) for a predetermined period. The target period may be determined by the usage cycle of the cooking category selected in step S801. For example, if the usage cycle is one week, the meal information (usage history) of the latest one week is acquired.

Next, in step S803, the recipe management server 1 acquires the attribute information of the dish presumed to have been eaten or eaten within a predetermined period based on the meal information. The attribute information is, for example, the type of taste, such as "miso taste" or "curry taste".

Then, in step S804, the recipe management server 1 determines whether or not there is meal information (usage history) having attribute information common to the selected cooking category.
Specifically, when the cooking category "curry" is selected in step S801 and it is estimated that the user has eaten or eaten "curry udon" within a predetermined period based on the meal information acquired in step S802, the determination process of step S804 Then, it is determined that there is meal information having common attribute information (curry taste).

In step S804, when it is determined that there is meal information having common attribute information (for example, when a dish having a different cooking category but a similar taste is eaten or eaten within the latest predetermined period), the recipe management server 1 In step S805, the process of adjusting the presentation time is executed. Specifically, the presentation time of the cooking category determined to have meal information having common attribute information is adjusted to be longer (later). The process for adjusting is the same as step S704 in FIG. 12, and may be adjusted according to the presentation time of the cooking category selected in step S801 (in this example, the usage cycle of "curry"). ..

After executing the process of step S805, or after determining in step S804 that there is no meal information having common attribute information, the recipe management server 1 sets the target cooking category (that is, the cooking category for which the presentation time is calculated) in step S806. ), It is determined whether or not the above processing has been applied.
If there is an unprocessed cooking category among the target cooking categories, the recipe management server 1 executes the process of step S801 again.
When there is no unprocessed cooking category among the target cooking categories, the recipe management server 1 ends the batch processing shown in FIG. 12 by ending the series of processing shown in FIG.

[4-5. Third example of batch processing]
A third example of batch processing will be described with reference to FIGS. 12 and 15.
In the third example of batch processing, the timing of presenting recommendation information is adjusted by taking into account not only past meal information but also future meal information.

The recipe management server 1 executes the process of acquiring the meal information in the step S402 after identifying the information providing source user by executing the step S401. Further, the recipe management server 1 specifies the usage cycle in step S403 and calculates the presentation time in step S404. The presentation time may be calculated for all cooking categories or for some cooking categories.

Next, the flow of the presentation timing adjustment process of step S405 executed by the recipe management server 1 is the same as the flow described in the second example of the previous batch process (flow chart of FIG. 13), but the processing contents are partially different. ..
An example of the presentation timing adjustment process in the third example of the batch process will be described with reference to FIG.

First, the recipe management server 1 selects one of the cooking categories for which the presentation time is calculated in step S701 of FIG. 15, and in the following step S706, another cooking category (that is, similar cooking) having a common upper category. Get meal information for category).
At this time, as the meal information for other cooking categories, not only past meal information (that is, usage history) but also future meal information is acquired. The future meal information is information on meals that the user plans to eat and drink in the future, such as a menu table for school lunches, a menu table for employee cafeterias, and daily set meal information for a favorite set meal shop, as described above. In addition, it may be a meal schedule (for example, a restaurant schedule) entered by the user himself / herself.

Then, in step S707, the recipe management server 1 determines whether or not the past final use time and the future use time are within the latest predetermined period. In other words, it is confirmed whether the final usage period is included in the latest predetermined period or the future usage period is included.
For example, if the predetermined period is one week and the last usage time of the cooking category selected in step S701 is three days before, or the future usage time is three days later, the usage time is the latest predetermined usage time. Judge that it is within the period.

When it is determined that the usage time is within the latest predetermined period, the recipe management server 1 adjusts the presentation time in step S704. As described in FIG. 13 above, this process may be adjusted by delaying the presentation time so that the period is vacant by the amount of the usage cycle.

In addition, it may be adjusted by advancing the presentation time. For example, if the usage cycle of the cooking category "udon" is one week and the final usage time is five days ago, the presentation time may be two days later. However, in the future meal information, if it is known that "udon" will be served in the lunch after 5 days, if the cooking category "udon" is presented 2 days later, "udon" will be eaten 3 days later. This will result in shorter intervals.
Therefore, the intermediate time (today) between the last use time (5 days before) and the next use time (5 days later) may be set as the presentation time. As a result, it is possible to prevent a large bias in the usage interval of the cooking category.
Also, if the interval between the last use time and the next use time is shorter than the use cycle, or if it is not much longer than the use cycle, stop setting the presentation time between the last use time and the next use time. You may.

After executing the process of step S704, or after determining in step S707 that the usage time is not within the latest predetermined period, the recipe management server 1 sets the target cooking category (that is, the cooking category for which the presentation time is calculated) in step S705. ), It is determined whether or not the above processing has been applied.
If there is an unprocessed cooking category among the target cooking categories, the recipe management server 1 executes the process of step S701 again.
When there is no unprocessed cooking category among the target cooking categories, the recipe management server 1 ends the batch processing shown in FIG. 12 by ending the series of processing shown in FIG. 13.

In the presentation time adjustment process considering the future usage time, as shown in FIG. 14, whether or not the food having common attribute information is eaten or eaten within a predetermined period from the acquired past and future meal information. The presentation time may be adjusted according to (whether or not).

[4-6. Fourth example of batch processing]
A fourth example of batch processing will be described with reference to FIGS. 8, 16 and 17.
In the fourth example of batch processing, the acquisition period of meal information for calculating the usage cycle is different from the above.
Specifically, the recipe management server 1 first identifies the information providing source user in step S401 of FIG. 8, and acquires meal information in step S402.

The processing content of the meal information acquisition process is different from that of FIG. This will be described with reference to FIG.
In the meal information acquisition process, the recipe management server 1 executes a process of calculating the acquisition start time in step S502. As described above, the acquisition start time point is the time information that is the starting point of the period for which the meal information is to be acquired. In this example, the acquisition start time is calculated based on the usage cycle of each cooking category related to the information providing source user. That is, when the usage cycle has already been calculated in the batch processing so far, the acquisition start time is calculated from the calculated usage cycle.
For example, if there are cooking categories A, B, and C, and the usage cycle is 3, 5, and 21 days, respectively, the acquisition start time is 21 days or earlier when the usage cycle of cooking category C can be recalculated. It is desirable to set it as time. For example, if the meal information for 42 days, which is twice the period of the usage cycle, is acquired, there is a high possibility that two or more usage histories of the cooking category C exist in the information.
In addition, when calculating the average usage cycle from three or more meal information (usage history), for example, the date and time before 63 days (for example, 70 days before), which is three times as many as 21 days, is acquired at the time of calculation. Is conceivable. If the meal information for 70 days is acquired, it is highly possible that sufficient information can be obtained for the cooking categories A and B, and further, it is highly possible that three meal information can be obtained for the cooking category C as well.

The recipe management server 1 that has calculated the acquisition start time is executed in the following step S503 to acquire the meal information from the acquisition start time to the present.

The recipe management server 1 that has completed the meal information acquisition process executes the usage cycle specifying process in step S403 of FIG.
The usage cycle specifying process will be described with reference to FIG.
First, the recipe management server 1 selects one cooking category in step S601, and confirms in step S602 whether the selected cooking category includes (belongs to) regular meal information.

Subsequently, the recipe management server 1 acquires the final usage time of the cooking category selected in step S603, and further acquires the previous usage time (usage date and time) in step S604.
Each process of steps S601 to S604 is the same as described above, and details thereof will be omitted.

The recipe management server 1 that has acquired two pieces of information, the last use time and the previous use time, executes a process of determining at least whether or not the two pieces of information have been obtained in step S607.
If two pieces of information cannot be obtained, the usage cycle cannot be calculated. Therefore, in such a case, the recipe management server 1 executes a process of additionally acquiring meal information in step S608.
Steps S604, S607, and S608 are repeated until two pieces of information, the last use time and the previous use time, can be obtained, but the use of the cooking category is used even though the meal information is too old. If the information for calculating the cycle cannot be obtained, the process may proceed to step S605. For example, even if the usage cycle is calculated based on the information one year ago, it is unlikely that the cooking category is used on a regular basis, and it is unlikely that the user can provide meaningful recommendation information. is there.

The recipe management server 1 that has acquired the information for calculating the usage cycle calculates the usage cycle from the difference time of the usage time in step S605.

After executing step S605 or determining in step S602 that the regular meal information is included, the recipe management server 1 determines in step S606 whether there is a cooking category in which each of the processes S601 to S605 is not executed. To judge.
When it is determined that there is a cooking category in which each of the processes of steps S601 to S605 has not been executed, the recipe management server 1 executes the process of step S601 again.
On the other hand, when it is determined that there is no cooking category for which each of the processes of steps S601 to S605 has not been executed, the recipe management server 1 ends the series of processes shown in FIG.

When calculating the average usage cycle from three or more meal information (usage history), in steps S603 and S604, a process of acquiring a necessary number of meal information is performed. Further, in the process of step S607, it is determined whether or not a necessary number of meal information can be acquired.
Further, even when the required number of meal information can be acquired, when the usage cycle is calculated from the difference time of the usage time, if the usage cycle varies widely, the process of step S608 is executed. May be good. For example, if the usage history of category A is 80 days ago, 75 days ago, 21 days ago, and 20 days ago, the usage cycle is calculated from the three difference times of 5 days, 46 days, and 1 day, but it varies. Is large, so an appropriate usage cycle cannot be estimated. Therefore, it is conceivable that after trying to calculate the usage cycle in step S605, additional meal information is acquired in step S608, and the usage cycle is calculated again in step S605. In this case, based on the additionally acquired meal information, whether the usage cycle of cooking category A is set to around 46 days, set to around 5 days, or another period such as the average number of days is set as the usage cycle. Determine if you want to set it.

When the DB is configured so that a predetermined number of meal information related to a specific cooking category can be obtained from the meal information DB 53, a predetermined number of meal information is eaten instead of steps S603, S604, S607, and S608. The process of acquiring from the information DB 53 may be executed.

The recipe management server 1 that has completed the usage cycle specifying process shown in FIG. 17 executes a process of calculating the presentation time from the usage cycle of step S404 of FIG. The details of this process are as described above, and the details are omitted.

<5. Modification example>

Some examples of modification in each process will be described.

[5-1. Modification example of information provider user identification process 1]
In the above-mentioned information providing source user identification process, the case where the target user and the information providing source user are the same (that is, the case where the recommendation information based on the own meal information is desired to be presented) has been described. In addition, the case where the user designated by the target user is the information providing source user (that is, the case where the user A wants to receive the presentation of the recommendation information based on the meal information of the spouse user B) has been described.

On the other hand, in the first modification of the information providing source user identification process, a case where all the members of the group to which the user A belongs is set as the information providing source user will be described. The group is, for example, a family group to which user A and his / her family members (users B, C, D) belong. In other words, it is a group of users who are likely to eat with User A.

By designating other users B, C, and D, user A identifies users A, B, C, and D as information provider users. Further, each member of the group to which the user A belongs, which is estimated based on the user's address, posted information, and the like, may be configured to be specified as the information providing source user.

As a result, recommendation information (cooking category and recipe) considering the meal information of all users A, B, C, and D is presented, so that it is possible to prevent some users from eating the same food for two consecutive days. It becomes possible to do.

[5-2. Modification example of information provider user identification process 2]
In the second modification of the information providing source user identification process, among the related users related to the user A (for example, the users B, C, and D in the above-mentioned group), the user having abundant meal information is set as the information providing source user. Identify. A user who has abundant meal information is a user who has a relatively large amount of information contained in the meal information for other users who belong to the group, or a user who belongs to the group for the meal information. For example, users have a relatively large number of types of cooking categories included.
Here, the information about the related user of the user A is stored in the DB managed by the recipe management server 1. That is, information indicating which user is associated with the user A and information such as meal information of the related user are stored in each DB.

Specifically, it will be described with reference to FIG.
In step S901, the recipe management server 1 acquires the information of the related user of the target user. That is, it is confirmed which user is the related user of the user A who is the target user.

Subsequently, in step S902, the recipe management server 1 acquires the number of records of meal information regarding the target user and the related user from the meal information DB 53. The number of records is the number of information stored in the meal information DB 53. For example, in the list shown in FIG. 5, each set of information constituting one line is regarded as one record. That is, in FIG. 5, it is shown that at least 6 records of the meal information of the user with the user ID = U0001 are stored.

Next, in step S903, the recipe management server 1 sets a user having a relatively large number of records among the target user and the related user as the information providing source user. That is, in the meal information acquisition process (FIGS. 8 and 12) in step S402 in the batch process, only the meal information of the user having a relatively large number of records is acquired.

When the information provider user is specified according to the type of the cooking category included in the meal information, the number of cooking categories of the meal information regarding the target user and the related user is acquired in step S902, and the meal information is obtained in step S903. A user with a relatively large number of cooking categories is set as an information provider user.

[5-3. Modification example of presentation time calculation process]
A modified example of the presentation time calculation process will be described with reference to FIG.
In the presentation time calculation process described above, an example of calculating the presentation time of some cooking categories has been described. Further, as an example of selecting some cooking categories, an example of uniformly selecting cooking categories at the same category level (for example, cooking categories of category level 2) has been described.
In the modified example of the presentation time calculation process, an example in which the usage cycle is used when selecting some cooking categories will be described.
At the start of the process of FIG. 19, it is assumed that the usage cycles of all cooking categories are specified. However, the usage cycle may not be specified for the cooking category that includes regular meal information.

First, the recipe management server 1 executes a process of acquiring the usage cycle of the cooking category in step S1001. For example, one of the cooking categories of category level 1 (cooking categories of major categories) is selected to acquire the usage cycle.

Subsequently, the recipe management server 1 determines in step S1002 whether or not the usage cycle is equal to or less than the lower limit threshold value. The lower threshold is, for example, one week or one month.

When the usage cycle is equal to or less than the lower limit threshold value (for example, when the lower limit threshold value is one week and the usage cycle is two days), the recipe management server 1 acquires the usage cycle of the lower category in step S1003. .. Then, the recipe management server 1 executes step S1002 again to determine whether or not the usage cycle of the lower category is equal to or less than the lower limit threshold value.

For example, a case where there is a cooking category A as a cooking category of category level 1 and there are cooking categories A1, A2, A3, and A4 as subcategories of the cooking category A will be described with reference to FIG.
When the usage cycle of the cooking category A is 4 days with respect to the adjustment threshold value of one week, the usage cycles of the cooking categories A1, A2, A3, and A4, which are lower categories, are acquired by steps S1002 and S1003. When the usage cycle of cooking categories A1, A2, A3, and A4 is 6, 30, 30, and 60 days, the usage cycle of only cooking category A1 is below the lower limit threshold, so the process of step S1003 is executed again. Then, the usage cycles of the lower categories A11 and A12 are acquired.
When the cooking categories A11 and A12 are on the 15th and 10th days, the processing for the lower category is not performed, and the series of processing shown in FIG. 19 for the cooking category A is completed.

As a result, for example, instead of presenting the cooking category "curry (cooking category A)" as recommendation information every four days, the subcategories "Japanese-style curry (cooking category A2)" and "European-style curry (cooking category A3)" are used. Is presented as recommendation information at an appropriate cycle. As for "Indian curry (cooking category A1)", further subdivided "keema curry (cooking category A11)" and "mutton curry (cooking category A12)" are presented as recommended information.
For this user, curry is a cooking category that is frequently eaten and eaten. Therefore, it is preferable to present the recommendation information based on the subdivided cooking categories rather than roughly presenting the cooking category "curry" as the recommendation information every four days, in view of the eating tendency of this user.
Furthermore, for example, if this user eats and drinks the cooking category "noodles" (including the cooking categories "ramen", "pasta", "udon", and "soba") only once a month, the cooking categories with different category levels "Noodles" and cooking category "Mutton Curry" are presented as recommended information. That is, it is possible to present appropriate recommendation information according to the bias of the user's taste for each cooking category.

Here, an example in which the usage cycle for each cooking category has already been specified at the start of the process of FIG. 19 has been described, but the present invention is not limited to this. For example, in the process of S1001 of FIG. 19, the usage cycle may be calculated instead of acquiring the usage cycle. Further, by executing the process of calculating the usage cycle of the lower category in step S1001 after the processing of step S1003, the usage cycle of the lower category is calculated as necessary. As a result, since the usage cycle is not calculated for the cooking category that does not require the calculation of the usage cycle, the processing of the recipe management server 1 can be reduced, and the processing load can be reduced.

<6. Summary>

The recipe management server 1 described above includes a user management unit 1b as a user identification unit that identifies a target user to whom information is presented, and at least a usage period corresponding to an information provider user related to the specified target user. The meal information acquisition unit 1c for acquiring meal information, the usage cycle specifying unit 1d for specifying the usage cycle for each cooking category based on the usage time included in the acquired meal information, and the usage time included in the acquired meal information. Of these, the recommended category identification unit 1g, which specifies the cooking category to be the recommended category based on the presentation time for each cooking category calculated based on the last usage time specified as the latest usage time and the specified usage cycle, and the recommendation It includes a presentation control unit 1i that controls to present recommended information to a target user based on a category.
As a result, information (recommended category) that captures the potential needs of the user is presented. That is, the recommended category information is presented in consideration of the selection pattern considering not only the user's preference but also the cycle. For example, a cooking category that the user wants to eat is extracted and presented to the user.
Therefore, it is possible to provide a recommendation category suitable for each user while suppressing the troublesomeness of thinking about daily meals.
Further, since the information can be presented without the user performing a search operation such as a recipe, it is possible to provide a service with less burden on the user.
Since the information suitable for the user is presented, the opportunity for the user to perform a further search operation or the like can be reduced, so that the processing load of the information processing device (recipe management server 1 or user terminal 3) can be reduced and communication can be performed. The amount can be reduced.

Further, as described in the second example of batch processing and the third example of batch processing, the recipe management server 1 presents the recommended category specified based on the use of the cooking category related to the specified recommended category. The presentation time adjusting unit 1f for adjusting the above may be further provided.
As a result, for example, information is presented in consideration of the case where similar cooking categories are used within a predetermined period.
That is, for example, it is prevented that the cooking category of "udon", which is the same noodles, is presented within a predetermined period after the cooking category of "soba" is used (recipe use, eating out use, etc.).
Therefore, it is possible to present the optimum information considering not only the usage cycle for each cooking category but also the usage status of similar cooking categories.
In addition, the recommendation category including the user's future schedule is specified and presented.
That is, it is possible to prevent the user from ingesting a meal belonging to the same category again in a short period of time after ingesting a meal according to the recommended category.
Therefore, it is possible to present comprehensive information in consideration of both the past meal information and the future meal information of the user, and it is possible to improve the convenience of the user.

Further, as described in the modified example of the presentation time calculation process, the cooking category has a hierarchical structure, and the recommended category specifying unit 1g has a usage cycle when the specified usage cycle is equal to or less than a predetermined lower limit threshold value. The recommended category may be specified by acquiring the usage cycle and the presentation time for the lower category of the cooking category in which is less than or equal to the lower limit threshold value.
As a result, it is not necessary to acquire the usage cycle and presentation time for all cooking categories.
Therefore, the processing load of the recipe management server 1 can be reduced.
In particular, when the specified usage cycle is less than or equal to a predetermined lower limit threshold value and the presentation time for the lower category is calculated, the processing load can be further reduced.

Furthermore, as described in the modified example of the presentation time calculation process, the recommendation category has a hierarchical structure, and the presentation time calculation unit 1e is a cooking category in which the usage cycle is equal to or larger than the lower limit threshold value. The recommended category identification unit 1g may specify the recommended category from the cooking categories in which the specified usage cycle is equal to or greater than or larger than the predetermined lower limit threshold value.
As a result, the presentation time is not calculated for the cooking category whose usage cycle is too short. For example, the presentation time is calculated for the lower cooking category. As a result, the same cooking category is not frequently presented as a recommended category.
Therefore, it is possible to provide meaningful information that the user will never get tired of.
In addition, the variation in the usage cycle of the cooking category for which the presentation time is calculated is alleviated to some extent. That is, when setting up a menu schedule for a predetermined period such as one week, it becomes easy to set up based on the calculated presentation time.

Then, as described in the first embodiment, the presentation control unit 1i assigns a priority to each recommended category and presents according to the priority.
As a result, the more meaningful the information is to the user, the higher the priority can be.
For example, a cooking category whose presentation time has passed significantly has a higher priority, so that it is possible to provide a service that is highly convenient for the user.

Further, as described in the fourth example of the batch processing, the meal information acquisition unit 1c determines the acquisition start time of the meal information based on the usage cycle, and acquires the meal information from the acquisition start time to the present.
As a result, the range (period) of acquiring meal information for each process from the next time onward is determined based on the usage cycle calculated once.
That is, it is possible not to acquire meal information for an unnecessarily long period of time.
Therefore, since the amount of information of the meal information to be processed is suppressed, the processing load of the information processing device can be reduced.

Furthermore, as described in the second modification of the information provider user identification process, when the related user related to the target user is registered, the meal information acquisition unit 1c performs the meal information among the target user and the related user. It may be configured to acquire the meal information of a user who has abundant information.
As a result, for example, the usage cycle and the presentation time are calculated based on the most complete information, and the recommended category specified by the calculation is presented.
Therefore, the recommendation category presented to the user tends to be meaningful information based on abundant information, so that a highly convenient service can be provided.

The processing contents described in each processing example can be replaced by the processing described in the other processing examples, or the processing described in the other processing examples can be additionally executed. That is, the process may be executed based on the contents described in other processing examples without being bound by the contents described in the processing example.
As an example, the third example of batch processing shows an example of making adjustments based on future meal information, and the fourth example of batch processing shows an example of how to determine a predetermined period when acquiring meal information within a predetermined period in the past. However, the future meal information acquisition period may be determined based on the usage cycle as in the fourth example of batch processing.

The length of the predetermined period and the predetermined time shown above may be one year, one month, one week, or the like, or one hour or several hours.

<7. Programs and storage media>

The recipe management server 1 as an embodiment of the information processing device of the present invention has been described above, but the program of the embodiment is a program that causes the information processing device (CPU or the like) to execute each process in the recipe management server 1. Is.

The program of the embodiment causes the information processing apparatus to execute a user identification function for identifying a target user to whom information is presented.
In addition, the information processing device is made to execute a meal information acquisition function for acquiring meal information including at least the usage time corresponding to the information providing source user related to the specified target user.
Further, the information processing apparatus is made to execute the usage cycle specifying function for specifying the usage cycle for each cooking category based on the usage time included in the acquired meal information.
Furthermore, among the usage times included in the acquired meal information, the last usage time, which is the latest usage time, the specified usage cycle, and the recommended category based on the presentation time for each cooking category calculated based on the specified usage cycle. Let the information processing device execute the recommended category identification function to specify the cooking category.
Then, the information processing apparatus is made to execute a presentation control function that controls the presentation of the recommendation information to the target user based on the recommendation category.
That is, this program is a program that causes the recipe management server 1 to execute each process of steps S201 to S207 of FIG. 6 and each process of FIGS. 7 to 19.

With such a program, the information processing device as the recipe management server 1 described above can be realized.
Such a program can be recorded 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 temporarily or permanently stored (recorded) in a removable storage medium such as a semiconductor memory, a memory card, an optical disk, a magneto-optical disk, or a magnetic disk. Further, such a removable storage medium can be provided as so-called package software.
In addition to installing such a program from a removable storage medium on a personal computer or the like, it can also be downloaded from a download site via a network such as a LAN or the Internet.

1 Recipe management server, 1a Recipe management unit, 1b User management unit, 1c Meal information acquisition unit, 1d Usage cycle identification unit, 1e Presentation time calculation unit, 1f Presentation time adjustment unit, 1g Recommended category identification unit, 1h Recommended recipe extraction unit 1i presentation control unit, 2 communication network, 3 user terminal, 50 user DB, 51 recipe DB, 52 search DB, 53 meal information DB, 54 web page DB

Claims (8)

A user identification unit that identifies the target user to whom information is presented, and
A meal information acquisition unit that acquires meal information including at least the usage time corresponding to the information provider user related to the specified target user, and a meal information acquisition unit.
Based on the usage time included in the acquired meal information, the usage cycle specifying unit that specifies the usage cycle for each cooking category, and the usage cycle specifying unit.
A cooking category that is a recommended category based on the last usage time that is the latest of the usage time included in the acquired meal information, the specified usage cycle, and the presentation time for each cooking category calculated based on the specified usage cycle. Recommended category identification department to identify
A presentation control unit that controls the presentation of recommendation information to the target user based on the recommendation category is provided .
The meal information acquisition unit is an information processing device that determines the acquisition start time of the meal information based on the usage cycle and acquires the meal information from the acquisition start time to the present. A user identification unit that identifies the target user to whom information is presented, and
A meal information acquisition unit that acquires meal information including at least the usage time corresponding to the information provider user related to the specified target user, and a meal information acquisition unit.
Based on the usage time included in the acquired meal information, the usage cycle specifying unit that specifies the usage cycle for each cooking category, and the usage cycle specifying unit.
A cooking category that is a recommended category based on the last usage time that is the latest of the usage time included in the acquired meal information, the specified usage cycle, and the presentation time for each cooking category calculated based on the specified usage cycle. Recommended category identification department to identify
A presentation control unit that controls the presentation of recommendation information to the target user based on the recommendation category is provided.
When the related user related to the target user is registered
The meal information acquisition unit acquires the meal information of the user whose meal information is substantial among the target user and the related user.
Information processing device.
The invention according to any one of claims 1 to 2, further comprising a presentation time adjusting unit for adjusting the presentation time of the specified recommendation category based on the use of the cooking category related to the specified recommendation category. Information processing device. The recommendation category has a hierarchical structure and has a hierarchical structure.
The presentation time is calculated for the cooking category in which the usage cycle is equal to or greater than the lower limit threshold value.
The recommended category specifying unit is described in any one of claims 1 to 3 , wherein the recommended category is specified from the cooking categories whose specified usage cycle is equal to or larger than a predetermined lower limit threshold value. Information processing device. A user identification step that identifies the target user to whom information is presented, and
A meal information acquisition step for acquiring meal information including at least the usage time corresponding to the information provider user related to the specified target user, and
Based on the usage time included in the acquired meal information, the usage cycle specifying step for specifying the usage cycle for each cooking category and the usage cycle specifying step
A cooking category that is a recommended category based on the last usage time that is the latest of the usage time included in the acquired meal information, the specified usage cycle, and the presentation time for each cooking category calculated based on the specified usage cycle. Recommended category identification steps to identify, and
Includes a presentation control step that controls the presentation of recommendation information to the target user based on the recommendation category.
In the meal information acquisition step, an information processing method executed by an information processing device that determines the acquisition start time of the meal information based on the usage cycle and acquires the meal information from the acquisition start time to the present. A user identification function that identifies the target user to whom information is presented, and
A meal information acquisition function that acquires meal information including at least the usage time corresponding to the information provider user related to the specified target user, and
A usage cycle identification function that specifies the usage cycle for each cooking category based on the usage time included in the acquired meal information, and
A cooking category that is a recommended category based on the last usage time that is the latest of the usage time included in the acquired meal information, the specified usage cycle, and the presentation time for each cooking category calculated based on the specified usage cycle. Recommended category identification function to identify
Includes a presentation control function that controls the presentation of recommendation information to the target user based on the recommendation category.
The meal information acquisition function is a program that determines the acquisition start time of the meal information based on the usage cycle and causes an information processing device that acquires the meal information from the acquisition start time to the present to execute the program. A user identification step that identifies the target user to whom information is presented, and
A meal information acquisition step for acquiring meal information including at least the usage time corresponding to the information provider user related to the specified target user, and
Based on the usage time included in the acquired meal information, the usage cycle specifying step for specifying the usage cycle for each cooking category and the usage cycle specifying step
A cooking category that is a recommended category based on the last usage time that is the latest of the usage time included in the acquired meal information, the specified usage cycle, and the presentation time for each cooking category calculated based on the specified usage cycle. Recommended category identification steps to identify, and
Includes a presentation control step that controls the presentation of recommendation information to the target user based on the recommendation category.
When the related user related to the target user is registered
In the meal information acquisition step, the meal information of the target user and the related user whose meal information is substantial is acquired.
An information processing method executed by an information processing device. A user identification function that identifies the target user to whom information is presented, and
A meal information acquisition function that acquires meal information including at least the usage time corresponding to the information provider user related to the specified target user, and
A usage cycle identification function that specifies the usage cycle for each cooking category based on the usage time included in the acquired meal information, and
A cooking category that is a recommended category based on the last usage time that is the latest of the usage time included in the acquired meal information, the specified usage cycle, and the presentation time for each cooking category calculated based on the specified usage cycle. Recommended category identification function to identify
Includes a presentation system function that controls the presentation of recommendation information to the target user based on the recommendation category.
When the related user related to the target user is registered
The meal information acquisition function acquires the meal information of the user whose meal information is substantial among the target user and the related user.
A program to be executed by an information processing device.

Images