WO2017175355A1 - 情報処理装置、情報処理方法、プログラム - Google Patents

情報処理装置、情報処理方法、プログラム Download PDF

Info

Publication number
WO2017175355A1
WO2017175355A1 PCT/JP2016/061395 JP2016061395W WO2017175355A1 WO 2017175355 A1 WO2017175355 A1 WO 2017175355A1 JP 2016061395 W JP2016061395 W JP 2016061395W WO 2017175355 A1 WO2017175355 A1 WO 2017175355A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
category
user
cooking
meal
Prior art date
Application number
PCT/JP2016/061395
Other languages
English (en)
French (fr)
Inventor
有紀 内田
Original Assignee
楽天株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 楽天株式会社 filed Critical 楽天株式会社
Priority to PCT/JP2016/061395 priority Critical patent/WO2017175355A1/ja
Priority to JP2018510190A priority patent/JP6641460B2/ja
Publication of WO2017175355A1 publication Critical patent/WO2017175355A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor

Definitions

  • the present invention relates to a technical field regarding an information processing apparatus, an information processing method, and a program for managing recipes. Specifically, the present invention relates to various processes for presenting a recipe to a user.
  • Patent Literature 1 describes a technique for providing menu information using materials that meet the user's preference using the menu information of food, the inventory information of ingredients, and the user's preference information.
  • Patent Document 2 describes a technique for placing an order for a lunch set set in a menu schedule selected by the user among menu schedules according to the user's health condition, living environment, and disease.
  • Patent Document 3 describes a technique in which a previously recommended recipe is stored as an existing recipe, and the remaining recipes are provided by excluding recipes that overlap with the existing recipe.
  • the menu provided by the technique described in Patent Document 1 is limited to a menu that includes a user's favorite material, the options that can be selected by the user become ruined.
  • the menu provided by the technique described in Patent Document 2 is limited to a menu corresponding to the health condition, living environment, and disease, there is a problem that the options that can be selected by the user become one pattern.
  • the recipe provided by the technique described in Patent Literature 3 can be suppressed from being provided again within a predetermined period, there is a problem that the recipe selection tendency by the user cannot be flexibly handled. is there. Therefore, the present invention provides a service capable of providing information for a timeless meal in consideration of a menu selection tendency by a user while suppressing annoyance of thinking about a daily meal.
  • the information processing apparatus obtains meal information including at least a use period corresponding to a user specifying unit that specifies a target user as a presentation destination of information and an information providing source user related to the specified target user.
  • a use period specifying unit for specifying a use cycle for each cooking category based on a use period included in the acquired meal information, and a use period included in the acquired meal information.
  • a recommended category identifying unit that identifies a cooking category to be a recommended category based on the presentation time for each cooking category calculated based on the latest usage time that is late and the identified usage cycle
  • a presentation control unit that performs control to present recommendation information to the target user. As a result, information (recommended category) based on the potential needs of the user is presented.
  • the information processing apparatus described above may further include a presentation time adjustment unit that adjusts the presentation time of the specified recommended category based on use of a cooking category related to the specified recommended category. Thereby, information presentation is performed in consideration of a case where a similar dish category is used within a predetermined period or a user's previous schedule.
  • the cooking category has a hierarchical structure, and the recommended category specifying unit of the information processing apparatus described above has a use cycle less than or less than the lower limit threshold when the specified use cycle is less than or less than a predetermined lower limit threshold.
  • the recommended category may be specified by acquiring the use cycle and the presentation time for the lower category of the cooking category. Thereby, it is not necessary to acquire the use period and presentation time about all the cooking categories.
  • the recommended category has a hierarchical structure, and the presentation time is calculated for a dish category in which the use period is greater than or equal to a lower threshold or greater than the lower limit threshold, and the recommended category specifying unit of the information processing apparatus described above May specify the recommended category from among the cooking categories in which the specified use cycle is greater than or equal to a predetermined lower threshold.
  • the presentation time is not calculated for the cooking category whose use cycle is too short.
  • the presentation time is calculated for the subordinate cooking category.
  • the same dish category is not frequently presented as a recommended category.
  • the presentation control unit of the information processing apparatus described above may assign a priority to each recommended category and perform the presentation according to the priority. This makes it possible to increase the priority of information that is meaningful to the user.
  • the meal information acquisition unit of the information processing apparatus described above may determine an acquisition start time of the meal information based on the use cycle, and acquire meal information from the acquisition start time to the present. Thereby, the range (period) of acquisition of meal information for each process after the next time is determined based on the use cycle calculated once.
  • the meal information acquisition unit of the information processing apparatus described above is the meal information of the user whose meal information is enriched among the target user and the related users. May be obtained.
  • the use cycle and the presentation time are calculated based on the substantial meal information, and the recommended category specified thereby is presented.
  • the information processing method obtains meal information including a user specifying step for specifying a target user as a presentation destination of information and at least a use period corresponding to an information provider user related to the specified target user.
  • a presentation control step for performing control to present recommendation information to the target user.
  • the program according to the present invention is a program that causes an information processing apparatus to execute processing executed as the information processing method.
  • the above information processing apparatus is realized by these programs.
  • a cooking recipe (hereinafter simply referred to as a recipe) will be described as an example of a recipe.
  • the recipe includes information such as cooking procedures, ingredients used, and cooking utensils.
  • 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 It may be one or a plurality of recipe information described, or information on a cooking category (such as “ramen” or “curry”) as information for selecting a store when eating out.
  • a recipe site operated by the recipe management server 1 is taken as an example as a portal site for providing a service capable of searching a recipe according to a search query and posting a recipe.
  • the recipe management server 1 is connected to the user terminals 3, 3, 3,... Via the communication network 2 so that they can communicate with each other.
  • the recipe management server 1 also includes a user DB (Database) 50 in which information about users is stored, a recipe DB 51 in which information about recipes is stored, a search DB 52 in which information on search queries and search results is stored, and user meal information It is connected to a meal information DB 53 for storing (described later) and a web page DB 54 for storing web page data of various web pages constituting the recipe site.
  • the recipe management server 1 corresponds to an embodiment of the information processing apparatus of the present invention.
  • the recipe management server 1 is an information processing apparatus that performs processing for managing a recipe posted by a user and processing for presenting a recipe according 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. A specific configuration will be described later.
  • the configuration of the communication network 2 is not particularly limited.
  • the Internet an intranet, an extranet, a LAN (Local Area Network), a CATV (Community Antenna TeleVision) communication network, a virtual private network (Virtual Private Network), a telephone line A network, a mobile communication network, a satellite communication network, etc. are assumed.
  • Various examples of transmission media constituting all or part of the communication network 2 are also envisaged.
  • IEEE Institute of Electrical and Electronics Engineers 1394, USB (Universal Serial Bus), power line carrier, telephone line, etc., infrared, IrDA (Infrared Data Association), Bluetooth (registered trademark), 802.11 wireless It can also be used wirelessly, such as mobile phone networks, satellite lines, and digital terrestrial networks.
  • the user terminal 3 is a terminal used by a user 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. Moreover, it is also a terminal used by a user who browses recommendation information presented from the recipe management server 1. In the user terminal 3, various transmission / reception processes and display processes are executed as necessary.
  • the user terminal 3 is, for example, a PC (Personal Computer), a feature phone, a PDA (Personal Digital Assistant) having a communication function, or a smart device such as a smartphone or a tablet terminal.
  • the recipe management server 1 includes a recipe management unit 1a, a user management unit 1b, a meal information acquisition unit 1c, a use cycle identification unit 1d, a presentation time calculation unit 1e, a presentation time adjustment unit 1f, and a recommended category specification. 1g, recommended recipe extraction unit 1h, and presentation control unit 1i.
  • the recipe management unit 1a uses 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, the information associated with the identification information identifying the user who posted the recipe information) as a recipe. Management is performed by storing the data in the DB 51.
  • a recipe of “vegetable curry” posted by a user is a recipe belonging to the category “curry”, and information on used ingredients is “potato”, “carrot”, “onion”, “broccoli”, “tomato”, “Spinach”, seasonings (such as “salt” and “pepper”), and equivalents (for example, “carrero”) are associated and stored.
  • the recipe management unit 1a manages the creation report posted for the posted recipe for each recipe.
  • the created report shows the impression of the recipe when the other user actually cooks using the posted recipe (for example, the taste of the dish felt by the user who cooked, the ease of the cooking procedure, etc.) ).
  • the creation report is associated with each recipe in the recipe DB 51 and managed.
  • 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, management is performed by associating a user ID that can uniquely identify a user with a name, age, gender, and contact information (such as a telephone number and an e-mail address) and storing them in the user DB 50. Moreover, the process which acquires user information from user DB50 is performed.
  • the meal information acquisition unit 1c performs a process of acquiring, from the meal information DB 53, meal information that was eaten or eaten in the past from the process time of the target user, meal information that is estimated to be eaten or eaten in the future after the process time.
  • meal information stored in the meal information DB 53 will be described later.
  • the period for which the meal information is acquired may be, for example, a predetermined period such as the most recent month, or may be a period that varies depending on the user. Further, the period may be determined according to the use cycle of the dish category described later. Specific examples will be described later.
  • the meal information acquisition unit 1c determines an acquisition start time according to a predetermined period or a calculated acquisition target period, and acquires meal information from the acquisition start time to the present. For example, when the period to be acquired is 10 days, the acquisition start point that is 10 days before the present is calculated, and the meal information from that point to the present is acquired.
  • some examples can be considered for the user from whom the meal information is acquired.
  • the user himself / herself who logs in and receives recommendation information related to a meal may be used, or a user (for example, the husband of the user) designated by the user who receives recommendation information.
  • a user for example, the husband of the user
  • the user who has the most complete meal information may be used.
  • you may acquire the meal information of all the users for example, the user who receives presentation of information, its husband, and three users of children).
  • the use cycle specifying unit 1d calculates, for each user, a cycle for using the dishes belonging to the food category for each food category based on past meal information.
  • the use of a dish belonging to a cooking category includes the use of a recipe relating to the cooking belonging to the cooking category (including a state estimated to have used the recipe), and the eating and drinking of a cooking belonging to the cooking category (that is, a meal by eating out) It is. That is, it means that the food belonging to the food category is eaten or eaten in some form.
  • the presentation time calculation unit 1e calculates the presentation time for each food category based on the use period and the last use time of the food 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 every category level in the hierarchical cooking category, or may calculate only a predetermined category level. Also, different category levels may be calculated for each cooking category, or different numbers of category levels may be calculated for each cooking category.
  • the presentation time adjustment unit 1f executes processing for adjusting the presentation time calculated for each cooking category according to various factors. That is, for a cooking category whose presentation time is three days later, a process of setting (ie, adjusting) two days earlier in the day as the presentation time is performed in consideration of various factors described later.
  • the presentation time is adjusted based on the use of similar cooking categories. For example, when the “soba” food category has been used most recently, a process of postponing the presentation time of the “udon” food category similar to “soba” (ie, extending back) is executed. Various specific examples will be described later.
  • the recommended category identification 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 identifying a cooking category that has reached the presentation time as a recommended category.
  • the recommended recipe extracting unit 1h executes processing for extracting recipes belonging to the recommended category.
  • the presentation control unit 1 i executes a process for presenting the extracted recipe to the user terminal 3.
  • presentation priority may be assigned to each piece of information. That is, information is presented to the user terminal 3 according to the presentation priority. For example, when a plurality of recipes are presented as an example of presentation of recommendation information, information is transmitted so that the recipes are arranged on the screen of the user terminal 3 according to the presentation priority.
  • the recipe management server 1 is provided with various units necessary for realizing a function of transmitting and receiving various types of information and an authentication process for a user login operation.
  • the authentication process is a process of collating the user ID (Identification) and the login password as login information transmitted from the user terminal 3 with the authentication information stored in the user DB 50.
  • FIG. 3 is a diagram illustrating hardware of the recipe management server 1 and the user terminal 3 shown in FIG. 1, and 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.
  • a CPU (Central Processing Unit) 101 of a computer device in each server, terminal, and DB is loaded into a RAM (Random Access Memory) 103 from a program stored in a ROM (Read Only Memory) 102 or a storage unit 108. Various processes are executed according to the program.
  • the RAM 103 also appropriately stores data necessary for the CPU 101 to execute various processes.
  • the CPU 101, ROM 102, and RAM 103 are connected to each other via a bus 104.
  • the input / output interface 105 is also connected to the bus 104.
  • the input / output interface 105 includes an input device 106 composed of a keyboard, mouse, touch panel, etc., a display composed of a liquid crystal display (LCD), a cathode ray tube (CRT), an organic EL (electroluminescence) panel, and an output composed of a speaker.
  • a device 107, a storage unit 108 including an HDD (Hard Disk Drive), a flash memory device, and the like, and a communication unit 109 that performs communication processing and communication between devices via the communication network 2 are connected.
  • a media drive 110 is also connected to the input / output interface 105 as necessary, and a removable medium 111 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory is appropriately mounted, and information can be written to the removable medium 111. Reading is performed.
  • a removable medium 111 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory is appropriately mounted, and information can be written to the removable medium 111. Reading is performed.
  • each information processing apparatus which comprises the recipe management server 1, the user terminal 3, user DB50, recipe DB51, search DB52, meal information DB53, and web page DB54 is a single computer apparatus as shown in FIG. It is not limited to being configured, and may be configured by a plurality of computerized systems.
  • the plurality of computer devices may be systemized by a LAN or the like, or may be arranged in a remote place in a communicable state 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 processing executed by the CPU 101 in accordance with the 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, each function need not be realized by an independent program. Processing of a plurality of functions may be executed by one program, or one function may be realized by cooperation of a plurality of program modules.
  • 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.
  • all the DBs may be formed in the storage unit in the same system as the recipe management server 1, or a part or all of each DB may be separated, or a computer system such as a remote place May be provided.
  • each DB does not need to be formed in one device (for example, one HDD).
  • Each DB does not need to be configured as one DB.
  • information stored as the user DB 50 may be stored and managed by a plurality of user DBs (for example, a login user DB and a transaction user DB).
  • Each DB described below is merely an example of a storage unit for information related to the processing of the embodiment in the form of one DB.
  • the user DB 50 stores information on users who receive services provided by the recipe management server 1. For example, personal information such as a login password, name, age, sex, and mail address is associated with one user ID (Identification) that can identify one user and stored. In addition, a use cycle for each cooking category, regular meal information, and the like are also stored in association with the user ID.
  • personal information such as a login password, name, age, sex, and mail address is associated with one user ID (Identification) that can identify one user and stored.
  • user ID Identity
  • a use cycle for each cooking category, regular meal information, and the like are also stored in association with the user ID.
  • Regular meal information is information on meals that the user eats and drinks on a daily basis, and is different for each user.
  • a regular meal for a user is “rice”, “bread”, or “miso soup”.
  • These recipes are eaten and consumed on a daily basis so that it is inappropriate to calculate the use cycle.
  • Such a recipe (or cooking category) is not subject to calculation such as the presentation time, and may not be included in the recommendation information presented to the user.
  • the recipe (or cooking category) stored as the regular meal information is a cooking category whose use cycle is shorter than a predetermined period (for example, one day) and cannot be further subdivided (that is, there is no lower cooking category). ).
  • Such recipes can be combined with a wide variety of other recipes.
  • the salad is a regular meal. That is, for such a user, it is difficult to provide valuable information to the user by calculating the presentation time from the salad use cycle and providing the information to the user.
  • the presentation time is calculated in the lower cooking category. Specifically, even if the use period of the “noodle” cooking category is one day, the lower categories “ramen”, “pasta”, “udon”, “soba”, etc. are longer than one day. There is a high possibility that the usage cycle will be appropriate. Therefore, the presentation time is calculated from the use cycle of the cooking category of “ramen” or “pasta”.
  • the user DB 50 may store preference information for each user.
  • the preference information is information on the user's favorite ingredients (favorable ingredients) or disliked ingredients (non-favorable ingredients) determined by the recipe management server 1 according to the behavior such as search and browsing of recipe information and cooking information by the user,
  • the preference information is used when the user performs a recipe search.
  • FIG. 4 shows a part of information related to the user A stored in the user DB 50.
  • a login password, name, age, sex, and e-mail address are stored in association with the user ID.
  • 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 the cooking category ID, and is information used to present recommended information to the user.
  • the recipe DB 51 is a DB that stores recipe information posted by the user. Specifically, for each recipe ID that can identify each recipe, a user ID that identifies the user who posted the recipe, post date information, category information to which the recipe belongs, and information on ingredients used for the recipe (such as quantity) ), Recipe cooking procedures, image information such as cooking images (finished cooking images and cooking images), and other users who actually used the recipe (created dishes)
  • the created report ID for specifying the created report is linked and stored.
  • URL Uniform Resource Locator
  • the recipe DB 51 stores information on creation reports posted for each recipe. As the information of the created report, text data indicating the report contents, cooked dish images, user IDs that can identify posters, posting date information, and the like are stored.
  • the search DB 52 is a DB that stores search results corresponding to the search query. Specifically, multiple recipes are linked and stored as search results according to a search query such as a dish name such as “curry” or “hamburg” or an ingredient name such as “mushroom” or “tomato”. .
  • a search process is executed according to a search query designated by the user, and the search result extracted as a result is linked to the search query and stored in the search DB 52.
  • a search process using a 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.
  • Meal information DB 53 In the meal information DB 53, meal information that the user has eaten in the past and meal information that is estimated to be eaten in the future are stored as history information. For example, information on recipes that have been used in the past or estimated to be used in the future, information on dishes that have been eaten in the past or estimated to be eaten in the future, information on cooking categories, and the like. Each meal information stored in the meal information DB 53 stores meal information of the information user of the cooking category. Information stored in the meal information DB 53 as meal information eaten or eaten in the past is specified or estimated to be a recipe used by the user based on, for example, a recipe usage history, browsing history, search history, or the like included in the history information.
  • Information on the recipe or category that the user specified or estimated to have eaten or eaten in the restaurant based on the information on the recipes that were read, the browsing history or search history of the restaurant or menu included in the history information, or the posted information
  • the information obtained from the menu of food and drink lunches in advance may be used.
  • Information stored in the meal information DB 53 as meal information estimated to be eaten and consumed in the future is based on information related to a meal schedule to be eaten and eaten in advance (for example, information on lunch menus and information on employee cafeterias). Information obtained.
  • the information may be information on a dish or a dish category that is specified or estimated based on information about a service that provides a dish such as a restaurant that is frequently used. Note that these pieces of information may be acquired from a web page related to a service providing 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 dish category. Specifically, as illustrated in FIG. 5, the use histories of a plurality of cooking categories are stored as meal information for a user ID that identifies the user. For one usage history, the usage date and time (use time), the cooking category ID, the acquisition route, and the usage mode are linked and stored.
  • FIG. 5 is an example in which histories are arranged in order of use date and time.
  • the cooking category ID can uniquely identify the cooking category.
  • the cooking categories are hierarchized. For example, types such as “Japanese food” and “Western food” are classified into major categories, such as “Japanese cuisine”, “Chinese cuisine”, “Italian cuisine”, “French cuisine”, and “Thai cuisine”. There are types of levels according to the names of dishes such as “curry”, “hamburger”, and “ramen”, and further types such as “beef curry”, “chicken curry”, and “kema curry”.
  • the middle classification may be the classification of main ingredients such as meat dishes, fish dishes, and vegetable dishes, as shown in (B) below.
  • the major classification may be “main staple”, “side dish”, “side dish”, and the like.
  • Major classification Japanese food (Others: Western food, etc.)
  • Subcategory Meat dishes
  • Meat potatoes / beef simmered etc.
  • Subcategory Fish dishes
  • Subcategory Miso-boiled crab / Minochan-chan, etc.
  • cooking categories are hierarchized in three stages.
  • the major categories in the cooking category are classified according to main ingredients such as “rice”, “noodles”, “meat”, “fish”, and “curry”.
  • main ingredients such as “rice”, “noodles”, “meat”, “fish”, and “curry”.
  • cooking categories such as “ramen”, “pasta”, “udon”, and “soba” are provided.
  • subcategory (small category) of the “Ramen” cooking category there are provided cooking categories such as “soy sauce ramen”, “miso ramen”, “salt ramen”, and “pork bone ramen”.
  • a large category of cooking category (such as “noodles”) is referred to as a category level 1 cooking category.
  • the subordinate cooking category (medium classification such as “ramen”) is described as a category level 2 cooking category.
  • a lower-level dish category small classification such as “soy sauce ramen” is described as a category level 3 dish category. That is, the numerical value indicating the category level is set so as to increase as the lower category (subdivided category).
  • Each recipe category has various recipes.
  • the recipe “My miso ramen” is a recipe belonging to the “miso ramen” cooking category, a recipe belonging to the “ramen” cooking category, and a recipe belonging to the “noodle” cooking category.
  • the cooking category ID is configured so that the relationship between the cooking categories can be understood in the hierarchical cooking category. Specifically, it is composed of a two-digit numerical value indicating the category level 1 cooking category, a two-digit numerical value indicating the category level 2 cooking category, and a single-digit numerical value indicating the category level 3 cooking category.
  • the cooking category ID set to “C01002” specifies the numerical value “01” that specifies the cooking category of category level 1, the numerical value “00” that specifies the cooking category of category level 2, and the cooking category of category level 3.
  • a numerical value “2” is included. That is, it can be seen that the cooking category with the category ID “C01002” and the cooking category with “C01013” belong to the same cooking category at the category level 1 and belong to different cooking categories at the category level 2.
  • the acquisition route is information indicating the route through which the meal information as the usage history has been acquired.
  • the history information in which the acquisition route is “SNS (Social Networking Service) posting” is history information that is estimated to have eaten or eat a dish belonging to the dish category based on an article posted to the SNS.
  • the history information set to “use recipe” is history information that is estimated to have eaten or eat food belonging to the food category by posting a creation report or browsing the recipe.
  • the history information set as “school lunch information” is history information estimated from eating and drinking food belonging to the cooking category from information relating to a cooking schedule such as a lunch menu.
  • the usage pattern indicates the usage pattern of the cooking category. For example, if eating and drinking at a store such as a restaurant is estimated, it is set as “dining out”. Also, if the acquisition route is “use recipe”, if the use of the recipe (ie use of the cooking category) is inferred by printing the recipe, it is “print”, and the use of the recipe is made by posting the creation report. Is assumed to be “post report”, and “receipt” is assumed when the use of the recipe is estimated by browsing the recipe for a predetermined time. The information on the usage mode is used as the probability of history information together with the acquisition route, for example.
  • 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 feature page, a search result page, a recipe detail page, and a user page.
  • web page data such as a recipe search page, a special feature page, a search result page, a recipe detail page, and a user page.
  • URL Uniform Resource Locator
  • the arrangement information is information that describes the arrangement 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).
  • the user terminal 3 In order for the user to obtain recommendation information, it is necessary to log in to a service operated by the recipe management server 1. Accordingly, in response to the user performing an operation for displaying the login screen using the user terminal 3, the user terminal 3 requests the login screen information (that is, web page data for displaying the login screen) in step S101. Execute.
  • the recipe management server 1 executes a login screen information transmission process in step S201. Thereby, for example, a web page corresponding to the login screen information (web page data) of the recipe site received from the recipe management server 1 is displayed on the user terminal 3.
  • the recipe management server 1 may store the fact that the login screen is displayed on the user terminal 3 as a history (that is, a browsing history of the login screen).
  • step S102 the user terminal 3 executes login information transmission processing for transmitting login information (user ID and login password) according to the user input operation to the recipe management server 1.
  • the recipe management server 1 executes an authentication process in step S202, and executes a process of storing a login history in the subsequent step S203, and the authentication result in step S204. Execute notification processing. Specifically, the recipe management server 1 compares the user ID and password input on the user terminal 3 with information stored in the user DB 50 to determine whether the user can log in, and authenticates the login permission information. As a result, the user terminal 3 is notified. In addition, while transmitting an authentication result to the user terminal 3, you may transmit the web page data of the top page of a recipe site. Thereby, user authentication is performed and the top page of the recipe site is displayed on the user terminal 3.
  • step S202 a series of flows shown in FIG. 6 shows a case where it is determined that login is possible in the authentication processing in step S202. If it is determined in step S202 that login is not possible, the user terminal 3 executes the process of step S102 again, and the recipe management server 1 executes the process of step S202 accordingly.
  • step S103 the user terminal 3 executes a process for requesting recommendation information based on a 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.
  • the recipe management server 1 executes a recommendation information acquisition process in step S205.
  • the recommended information acquisition process is a process for acquiring a cooking category (that is, a recommended category) to be presented as recommended information to the user terminal 3. Details of the recommendation information acquisition processing in step S205 will be described with reference to FIG.
  • the recipe management server 1 selects one dish category in step S301, and acquires presentation time information of the dish category in subsequent step S302. It should be noted that the cooking category presentation time may be calculated in advance by batch processing or the like and stored in the user DB 50 shown in FIG. 4 before executing the processes of FIGS. 6 and 7. Details of the batch processing will be described later.
  • 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).
  • the recipe management server 1 selects the dish category as a recommended category in step S304.
  • the recipe management server 1 determines whether there is a cooking category that has not been processed in step S305. If it is determined that there is a cooking category that has not been processed, the recipe management server 1 executes the processes of steps S301 to S305 again. On the other hand, when it is determined that there is no cooking category that has not been processed, the series of processes illustrated in FIG. In other words, by executing the processing shown in FIG. 7, the dish category whose presentation time has come is selected as the recommended category.
  • the recipe management server 1 that has acquired the recommendation category information as the recommendation information executes a priority assignment process in step S206.
  • the priority assigning process is a process executed when there are a plurality of recommended categories, and when the acquired recommended category is one, the process of step S206 is not executed.
  • the priority assignment processing For example, it is conceivable to increase the priority of a recommendation category having a long elapsed time from the last use time. Specifically, in the recommended category A whose last use time is yesterday and the recommended category B that is one week ago, the priority of the recommended category B is increased over the recommended category A.
  • the priority assignment process it is conceivable to increase the priority of the recommendation category A having a short use cycle.
  • the recommendation category A has a higher priority than the recommendation category B in the recommendation category A with a usage period of one week and the recommendation category B with a month. This is in consideration of the effect when the recommended category with low priority is not used.
  • the usage cycle for one week is extended by one day and when the usage cycle for one month is extended by one day, the case where the usage cycle for one week is extended by one day is considered to have a relatively large effect. . Therefore, the priority of the recommended category having a large influence when not used is increased.
  • the recipe management server 1 that assigns a priority to the recommended category performs a presentation process in step S207.
  • information on recommended categories to which priority is given is transmitted from the recipe management server 1 to the user terminal 3.
  • HTML data for displaying a web page in which recommended category information is arranged in order of priority is transmitted.
  • the batch process shown in FIG. 8 is a process for calculating the presentation time for one user. That is, when the presentation time is calculated for all users, the series of processing shown in FIG. 8 is repeated for the number of users. If there is only one user who needs to perform batch processing, the series of processing shown in FIG. 8 need only be performed once.
  • step S401 the recipe management server 1 executes a process for specifying a user from which recipe information is to be acquired. While the user who is the target of presentation of recommendation information is described as the target user, the user who is the target of acquisition of recipe information is the user who provides the information for presentation of 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.
  • the 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 user A.
  • the information providing source user may be the user A himself / herself who receives the service of the recipe management server 1 or the user B specified by the user A.
  • the target user and the information providing source user are both the user A.
  • the target user is user A and the information providing source user is user B designated by user A.
  • deciding the information provider user determines who is based on the meal information in order to calculate the submission time of the cooking category.
  • step S402 the recipe management server 1 executes a process of acquiring meal information of the information providing source user from the meal information DB 53.
  • the recipe management server 1 acquires meal information in the most recent predetermined period as in step S501.
  • the predetermined period is set as a fixed numerical value (period) such as one month.
  • the fixed predetermined period is desirably a period sufficient to calculate the use period of the cooking category. That is, it is desirable to set a period in which one dish category is used a plurality of times.
  • the usage cycle specifying process is a process of specifying (calculating) the use cycle for each cooking category based on the meal information of the information providing source user (information acquired in the previous step S402).
  • step S601 the recipe management server 1 executes processing for selecting one dish category. Subsequently, in step S602, the recipe management server 1 confirms whether or not the regular meal information is included (belongs) to the selected dish category.
  • the recipe management server 1 acquires the last use date and time (last use time) of the selected dish category in step S603, and further uses the previous use date and time ( Use time) is acquired in step S604. Information on each use date and time is acquired from the meal information DB 53.
  • the use date and time is the time (or date information) using the above-described cooking category, that is, the date and time when using a recipe belonging to the cooking category or the date and time when eating or drinking food belonging to the cooking category. .
  • the recipe management server 1 executes a process of calculating a use cycle from the difference between these two use dates and times. It should be noted that an average difference may be calculated not from two usage dates but from more usage dates and times as a usage cycle.
  • step S605 the recipe management server 1 checks in step S606 whether 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, if it is determined that there is a cooking category that has not been processed, the recipe management server 1 ends the series of processing shown in FIG.
  • step S606 when it determines with regular meal information being contained in step S602, the process of step S606 is performed without performing each process of step S603 thru
  • the recipe management server 1 that has calculated the use cycle for all the cooking categories executes processing for calculating the presentation time from the use cycle.
  • the presentation time is calculated from the last use time and the use cycle as the presentation time when the next use is expected. Specifically, for example, when the last use time is 3 days ago and the use cycle is 10 days, the presentation time is 7 days later.
  • the presentation time for each cooking category is calculated. After that, when a request for recommendation information is received from the user, a recommendation category based on the presentation time is presented by executing each process of steps S205 to S207 in FIG.
  • the cooking category whose presentation time has passed it is not necessary to show to the user about the cooking category whose presentation time has passed before receiving a request for recommendation information from the user.
  • whether or not to present may be determined according to the length of time passed. Specifically, if the time has not passed since passing, the dish category is presented to the user as a recommended category, but if the time has passed since passing, the dish category is recommended. It can be considered not to present it as information.
  • the recommendation information may be presented to the user regardless of the length of time passed.
  • the calculation of the presentation time in step S404 in FIG. 8 may be performed for all the cooking categories or for some cooking categories.
  • the usage cycles of some of the cooking categories may be calculated in the above-described usage cycle specifying process of FIG.
  • recipe information (recommended recipe) is presented instead of presenting a dish category (recommended category) as recommended information. This will be specifically described with reference to FIGS.
  • the recipe management server 1 when receiving a recommendation information request from the user terminal 3, acquires recommendation information to be presented to the user in step S205, gives priority in step S206, and presents it in step S207. Execute the process.
  • the processing content of the recommendation information acquisition processing in step S205 is different.
  • FIG. 11 An example of the recommendation information acquisition process in the second embodiment is shown in FIG.
  • the recipe management server 1 acquires a presentation time for each cooking category in steps S301 to S304, and selects a cooking category for which the presentation time has come as a recommended category. Execute. Since these processes are the same processes as those described with the same reference numerals in FIG. 7, detailed description thereof is omitted.
  • step S306 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.
  • a recipe belonging to the recommended category is “curry”
  • recipes such as “my home-made seafood curry” and “indian curry with plenty of tomatoes” belonging to the cooking category “curry” are extracted as recommended recipes.
  • only recipes that are recommended to be recommended to the user among recipes belonging to the recommended category may be extracted as recommended recipes.
  • the recipe suitable for recommendation to the user is, for example, a recipe including the user's favorite food or a recipe not including the unfavorable food.
  • the recipe which a user can cook for example, the user possesses the cooking utensil used in a cooking method
  • the recipe which a user is easy to cook for example, the cooking process and cooking method or ingredients which are frequently used are included
  • Etc. are extracted as recommended recipes. Accordingly, 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 extracted the recommended recipe after finishing the process of FIG. 11 for all the cooking categories executes the priority assignment process in step S206 of FIG. 6, and executes the presentation process in step S207.
  • a priority assigning process for the recommended recipe is performed.
  • a recommendation category that should have a higher priority may be determined, and a recommendation recipe that belongs to a recommendation category that has been given a higher priority may be increased. Further, priority may be given to each recommended recipe without considering which cooking category it belongs to.
  • step S207 information on the recommended recipe to which priority is given is transmitted from the recipe management server 1 toward the user terminal 3.
  • HTML data for displaying a web page in which recommended recipe information is arranged in order of priority is transmitted.
  • the recipe management server 1 executes steps S401 to S404 shown in FIG. 12 to acquire meal information of the information providing source user, and executes a process of calculating a presentation time from the use cycle for each identified cooking category.
  • the processes in steps S401 to S404 are the same as the processes described with reference to FIG. 8 with the same reference numerals, and will not be described in detail.
  • step S405 the recipe management server 1 that has calculated the presentation time executes processing for adjusting the presentation time.
  • the presentation time adjustment process There are several examples of the presentation time adjustment process. First, the first example will be described with reference to FIG.
  • step S701 the recipe management server 1 selects one of the cooking categories targeted for the presentation time calculation process (step S404). That is, one cooking category for which the presentation time is calculated is selected. Subsequently, in step S ⁇ b> 702, the recipe management server 1 acquires the meal information (use history) of the category of other dishes with the same upper category from the meal information DB 53.
  • the lower categories of the cooking category “noodles” belong to cooking categories such as “ramen”, “pasta”, “udon”, and “soba”.
  • the dish category “Udon” is selected in step S701
  • the other dish categories having the same upper category are “ramen”, “pasta”, and “soba”. Therefore, the process of step S702 is a process of acquiring a use history for the dish 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 use history is also acquired for the plurality of users.
  • the recipe management server 1 uses the most recent predetermined period (predetermined) for the final use time for each of the other food categories (for example, “Ramen”, “Pasta”, and “Soba” food categories). It is determined whether it is within time). That is, it is determined whether or not the food belonging to the other food category has been eaten or consumed within the most recent predetermined period.
  • the predetermined period is, for example, 3 days, and is a period for avoiding recommending a similar recipe or cooking category to the user.
  • the determination processing in step S703 if there is a dish category in which the last use time is located within the most recent predetermined period among the other food categories, the last use time is within the most recent predetermined period. Judge that there is.
  • the recipe management server 1 executes a process of adjusting the presentation time in step S704. That is, the presentation time is postponed. Specifically, for example, because it is time to present the cooking category “Udon” whose usage cycle is one week, we would like to present “Udon” to the user as a recommended category, but the usage of the cooking category “Soba” was yesterday. Therefore, the presentation time of the cooking category “Udon” is moved back several days from today.
  • the amount of movement at this time is set so that one week, which is the use cycle of the cooking category “Udon”, is vacated from the last use time (yesterday) of the cooking category “soba” (that is, 7 days after yesterday).
  • the cooking category “Udon” itself has not been used for one week, it may be set so as to be delayed by about half of the usage cycle (ie, 3 or 4 days).
  • step S705 After executing the process of step S704, or after determining in step S703 that the final use time of the other food category is not within the latest predetermined period, the recipe management server 1 in step S705, the target food category (that is, the presentation) It is determined whether or not the above-described processing is applied to all of the cooking categories for which the time has been 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 illustrated in FIG. 12 by terminating the series of processing illustrated in FIG. 13.
  • the last use time of the upper category may be obtained. 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.
  • step S801 the recipe management server 1 selects one of the cooking categories targeted for the presentation time calculation process (step S404). This process is the same as the process in step S701 in FIG.
  • step S802 the recipe management server 1 acquires meal information for a predetermined period of the information providing source user (a user who is a target for acquiring meal information).
  • the target period may be determined by the use cycle of the dish category selected in step S801. For example, if the use cycle is one week, meal information (use history) for the most recent one week is acquired.
  • the recipe management server 1 acquires the attribute information of the dish estimated to have been eaten or consumed 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”.
  • step S804 the recipe management server 1 determines whether there is meal information (use history) having attribute information common to the selected dish category. Specifically, when the cooking category “curry” is selected in step S801, and it is estimated that the user has eaten or consumed “curry udon” within a predetermined period based on the meal information acquired in step S802, the determination process in step S804 Then, it is determined that there is meal information having common attribute information (curry taste).
  • step S804 when it is determined that there is meal information having common attribute information (for example, when a dish having a different taste but having a similar taste is eaten / drinked within the most recent predetermined period), the recipe management server 1 In step S805, processing for 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 (slower). The adjustment process is the same as that in 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 “curry” usage period). .
  • step S806 After performing the process of step S805 or after determining that there is no meal information having common attribute information in step S804, the recipe management server 1 in step S806, the target cooking category (that is, the cooking category for which the presentation time is calculated) ) To determine whether or not the above-described 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. If 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.
  • the recipe management server 1 executes the process of acquiring meal information in step S402 after specifying the information providing source user by executing step S401. Furthermore, the recipe management server 1 specifies the use cycle in step S403, and calculates the presentation time in step S404. The presentation time may be calculated for all cooking categories, or may be calculated for some cooking categories.
  • 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 (the flowchart in FIG. 13), but the process content is partially different. .
  • An example of presentation time adjustment processing in the third example of batch processing will be described with reference to FIG.
  • the recipe management server 1 selects one of the cooking categories for which the presentation time has been calculated, and in the subsequent step S706, other cooking categories having a common upper category (that is, similar dishes). Category) meal information.
  • the meal information about the other dishes category acquires not only past meal information (that is, usage history) but also future meal information.
  • the future meal information is information on meals that the user plans to eat and drink in the future, as described above, such as the menu for lunch, the menu for the employee cafeteria, and the daily set meal for the set meal shop.
  • it may be a meal schedule (for example, a meal schedule) input by the user himself / herself.
  • step S707 the recipe management server 1 determines whether the past last use time and the future use time are within the latest predetermined period. In other words, it is confirmed whether the last use time is included in the latest predetermined period or whether the future use time is included. For example, when the predetermined period is one week and the last use time of the dish category selected in step S701 is 3 days ago or the future use time is 3 days later, the use time is the most recent predetermined time. It is determined that it is within the period.
  • the recipe management server 1 adjusts the presentation time in step S704. As described above with reference to FIG. 13, this processing may be adjusted by moving the presentation time backward so that the period of use is vacant.
  • the presentation time may be adjusted in advance. For example, when the use cycle of the dish category “Udon” is one week and the last use time is five days ago, the presentation time may be two days later. However, in 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 consumed after 3 days The interval will be shortened. Therefore, the presentation time may be an intermediate time (today) between the last use time (5 days before) and the next use time (after 5 days). Thereby, it is possible to prevent a large deviation in the use interval of the cooking category. In addition, if the interval between the last use time and the next use time is shorter than the use cycle or not much longer than the use cycle, the presentation time should not be set between the last use time and the next use time. May be.
  • step S705 After executing the processing of step S704, or after determining in step S707 that the use time is not within the latest predetermined period, the recipe management server 1 in step S705, the target cooking category (ie, the cooking category for which the presentation time has been calculated). ) To determine whether or not the above-described 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 illustrated in FIG. 12 by terminating the series of processing illustrated in FIG. 13.
  • the presentation time adjustment process that also considers the future use time, as shown in FIG. 14, whether or not a meal having common attribute information is eaten or consumed within a predetermined period from the acquired past and future meal information (whether or not The presentation time may be adjusted according to whether or not.
  • the meal information acquisition period for calculating the use cycle is different from that described above.
  • the recipe management server 1 first specifies an information provider user in step S401 of FIG. 8, and acquires meal information in step S402.
  • the meal information acquisition process differs from that shown in FIG. This will be described with reference to FIG.
  • the recipe management server 1 executes a process of calculating the acquisition start time in step S502.
  • the acquisition start time is time information that is the starting point of a period for which meal information is to be acquired.
  • the acquisition start time is calculated based on the use cycle of each dish category related to the information provider user. That is, when the use cycle has been calculated in the batch processing so far, the acquisition start point is calculated from the calculated use cycle.
  • the usage cycle of cooking category C before the 21st day when the usage cycle of cooking category C seems to be recalculated Time is desirable.
  • the meal information for 42 days which is a period twice as long as the use cycle
  • a date and time for example, 70 days before
  • 63 days is acquired. It can be considered. If meal information for 70 days is acquired, there is a high possibility that sufficient information can be acquired for the cooking categories A and B, and there is a high possibility that three meal information can be acquired for the cooking category C as well.
  • step S503 the recipe management server 1 that has calculated the acquisition start time executes processing for acquiring meal information from the acquisition start time to the present time.
  • step S601 the recipe management server 1 selects one dish category, and in step S602, the recipe management server 1 confirms whether or not the regular meal information is included in the selected dish category.
  • the recipe management server 1 obtains the last use time of the dish category selected in step S603, and obtains another use time (use date and time) in step S604.
  • Each process of steps S601 to S604 is the same as described above, and will not be described in detail.
  • step S607 the recipe management server 1 that has acquired the two pieces of information of the last use time and the previous use time executes a process of determining whether or not at least the two pieces of information have been acquired. If the two pieces of information cannot be acquired, the usage cycle cannot be calculated. Accordingly, in such a case, the recipe management server 1 executes a process for additionally acquiring meal information in step S608. Note that steps S604, S607, and S608 are repeated until two pieces of information of the last use time and the previous use time can be obtained. If the information for calculating the period cannot be acquired, the process may proceed to step S605. For example, even if the usage cycle is calculated based on information a year ago, the possibility that the cooking category is regularly used is low, and the possibility that meaningful recommendation information for the user can be provided is low. is there.
  • the recipe management server 1 that has acquired the information for calculating the use cycle calculates the use cycle from the difference time of the use time in step S605.
  • step S606 determines in step S606 whether or not there is a cooking category for which each process of S601 to S605 has not been performed. Determine. If it is determined that there is a cooking category for which the processes of steps S601 to S605 are not performed, 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 the processes in steps S601 to S605 are not performed, the recipe management server 1 ends the series of processes shown in FIG.
  • step S607 it is determined whether a necessary number of meal information has been acquired. Even when the necessary number of meal information can be acquired, when the use cycle is large when the use cycle is calculated from the difference time of the use time, the process of step S608 is executed. Also good. For example, when 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 three differential times of 5 days, 46 days, and 1 day. Therefore, an appropriate usage period cannot be estimated.
  • step S605 after trying to calculate the use cycle in step S605, additional meal information is acquired in step S608, and the use cycle is calculated again in step S605.
  • the use cycle of the cooking category A is set to around 46 days, around 5 days, or another period such as the average number of days, for example, as the use cycle Determine whether to set.
  • DB is comprised so that the predetermined number of meal information regarding a specific dish category can be acquired from the meal information DB 53
  • a predetermined number of meal information is mealed instead of steps S603, S604, S607, and S608. What is necessary is just to perform the process acquired from information DB53.
  • the recipe management server 1 that has completed the use cycle specifying process shown in FIG. 17 executes a process of calculating the presentation time from the use cycle in step S404 of FIG. The details of this processing are as described above, and will not be described in detail.
  • the group is, for example, a family group to which the user A and his family (users B, C, D) belong.
  • the group is a group of users who are likely to eat with the user A.
  • the user A, B, C, and D are specified as the information providing source user when the user A designates the other users B, C, and D. Moreover, you may comprise so that each member of the group to which the user A estimated based on a user's address, contribution information, etc. belongs may be specified as an information provider user.
  • a user who is enriched with meal information is set as the information provider user.
  • a user who is rich in meal information is a user who has a relatively large amount of information included in the meal information with respect to other users who belong to the group or a meal information for other users who belong to the group.
  • the user includes relatively many types of cooking categories.
  • information about the related user of user A is stored in the DB managed by the recipe management server 1. That is, information indicating which user is related to the user A and information such as meal information of the related user are stored in each DB.
  • step S ⁇ b> 901 the recipe management server 1 acquires related user information of the target user. That is, it is confirmed which user is the related user of the target user User A.
  • step S902 the recipe management server 1 acquires the number of meal information records related to the target user and related users from the meal information DB 53.
  • step S903 the recipe management server 1 sets a user having a relatively large number of records among the target user and related users as an information provider user. That is, in the meal information acquisition process (such as FIG. 8 and FIG. 12) in step S402 in the batch process, only meal information of a user having a relatively large number of records is acquired.
  • the number of dish categories of the meal information regarding the target user and the related user is acquired in step S902, and the meal information of the meal information in step S903.
  • a user with a relatively large number of cooking categories is set as an information provider user.
  • step S1001 the recipe management server 1 executes a process for acquiring the use cycle of the dish category. For example, one of the category level 1 food categories (large category food categories) is selected, and the use cycle is acquired.
  • step S1002 the recipe management server 1 determines whether or not the usage cycle is equal to or lower than the lower limit threshold value.
  • the lower threshold is, for example, one week or one month.
  • the recipe management server 1 acquires the usage cycle of the lower category in step S1003. . And the recipe management server 1 determines whether the utilization period of the said lower category is below a lower limit threshold value by performing step S1002 again.
  • the usage cycle of the cooking category A is 4 days with respect to the addition / subtraction threshold set to 1 week
  • the usage cycles of the cooking categories A1, A2, A3, and A4, which are lower categories are acquired in steps S1002 and S1003.
  • the usage cycle of the cooking categories A1, A2, A3, and A4 is 6, 30, 30, and 60 days
  • only the cooking category A1 has a usage cycle that is less than or equal to the lower limit threshold value, so the process of step S1003 is executed again.
  • the usage cycle of the lower categories A11 and A12 is acquired.
  • the processing for the lower category is not performed, and the series of processing shown in FIG.
  • the dish category “curry (dish category A)” is not presented as recommended information every four days, but the subordinate categories “Japanese-style curry (dish category A2)” or “European-style curry (dish category A3)”. "Is presented as recommendation information at an appropriate period. For “Indian curry (dish category A1)”, “Kemah curry (dish category A11)”, “mutton curry (dish category A12)”, etc., which are further subdivided, are presented as recommended information. For this user, curry is a food category that is frequently eaten and consumed.
  • the recommended information based on the subdivided cooking category rather than presenting the cooking category “curry” as recommended information every four days in view of the user's eating tendency. Further, for example, when 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 having different category levels are used. “Noodles” and the cooking category “mutton curry” are presented as recommended information. That is, it is possible to present appropriate recommendation information according to the user's preference bias for each cooking category.
  • the usage cycle for each cooking category has already been specified at the start of the processing of FIG. 19, but is not limited thereto.
  • the usage cycle may be calculated instead of the usage cycle.
  • the process of calculating the use period of the lower category is executed in step S1001, thereby calculating the use period of the lower category as necessary.
  • the above-described recipe management server 1 includes a user management unit 1b as a user specifying unit that specifies a target user as an information presentation destination, and at least a use period corresponding to an information provider user related to the specified target user.
  • a meal information acquisition unit 1c that acquires meal information
  • a use period specifying unit 1d that specifies a use period for each cooking category based on a use period included in the acquired meal information
  • a use period included in the acquired meal information A recommended category specifying unit 1g for specifying a cooking category to be a recommended category based on a presentation time for each cooking category calculated based on the latest usage time of the latest usage time and the specified usage cycle, and a recommendation A presentation control unit 1i that performs control to present recommendation information to the target user based on the category.
  • information (recommended category) based on the potential needs of the user is presented.
  • the recommended category information is presented in view of not only the user's preference but also the selection pattern considering the cycle.
  • the cooking category that the user wants to eat soon is extracted and presented to the user. Therefore, it is possible to provide a recommended category suitable for each user while suppressing the annoyance of thinking about daily meals. Further, since it is possible to present information without the user performing a search operation such as a recipe, a service with less burden on the user can be provided. Since the information suitable for the user is presented, the opportunity for the user to perform further search operations and the like can be reduced, so that the processing burden on the information processing apparatus (recipe management server 1 and user terminal 3) can be reduced and communication can be performed. The amount can be reduced.
  • the recipe management server 1 provides the recommended category presentation time specified based on the use of the cooking category related to the specified recommended category. You may further provide the presentation time adjustment part 1f which adjusts.
  • information presentation is performed in consideration of a case where a similar dish category is used within a predetermined period. That is, for example, it is possible to prevent the “noodle” cooking category that is the same noodles from being presented within a predetermined period after the “soba” cooking category is used (recipe use, restaurant use, etc.). Therefore, it is possible to present optimal information in consideration of not only the usage cycle for each cooking category but also the usage status of similar cooking categories.
  • the recommended category including the user's previous 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 that takes into account both past meal information of the user and future meal information, and the convenience of the user can be improved.
  • the cooking category has a hierarchical structure
  • the recommended category specifying unit 1g uses the use cycle when the specified use cycle is less than or less than a predetermined lower threshold.
  • the recommended category may be specified by acquiring the use cycle and the presentation time for the lower category of the cooking category whose value is less than or less than the lower threshold.
  • the recommended category has a hierarchical structure
  • the presentation time calculation unit 1e is a cooking category in which the use period is determined to be greater than or equal to the lower threshold value among the cooking categories.
  • the recommended category specifying unit 1g may specify the recommended category from among the cooking categories whose specified use cycle is greater than or equal to a predetermined lower threshold value.
  • the presentation time is not calculated for the cooking category whose use cycle is too short.
  • the presentation time is calculated for the subordinate cooking category.
  • the same dish category is not frequently presented as a recommended category. Therefore, meaningful information that does not get tired for the user can be provided.
  • the variation in the use cycle of the cooking category for which the presentation time is calculated is moderated to some extent. That is, when setting a menu schedule or the like for a predetermined period such as one week, it is easy to set based on the calculated presentation time.
  • the presentation control part 1i gives a priority for every recommendation category, and performs presentation according to this priority. This makes it possible to increase the priority of information that is meaningful to the user. For example, it is possible to provide a service that is highly convenient for the user because the priority is set higher for the cooking category for which the presentation time has passed significantly.
  • the meal information acquisition unit 1c determines the meal information acquisition start point based on the use cycle, and acquires the meal information from the acquisition start point to the present.
  • the range (period) of acquisition of meal information for each process after the next time is determined based on the use cycle calculated once. That is, it is possible not to acquire meal information for an unnecessarily long period. Therefore, since the information amount of the meal information to be processed is suppressed, the processing load on the information processing apparatus can be reduced.
  • the meal information acquisition unit 1c selects the meal information among the target user and the related users. May be configured to acquire meal information of a user who is enriched. Thereby, for example, the use cycle and the presentation time are calculated based on the most complete information, and the recommended category specified thereby is presented. Therefore, since the recommended category presented to the user is likely to be meaningful information based on the enriched information, a highly convenient service can be provided.
  • processing content described in each processing example can be replaced by the processing described in the other processing examples, and the processing described in the other processing examples can be additionally performed. That is, the process may be executed based on the contents described in the other process examples without being limited to the contents described in the process examples.
  • an example of performing adjustment based on future meal information in the third example of batch processing is shown, and an example of how to determine a predetermined period when acquiring meal information within a predetermined period in the past in the fourth example of batch processing
  • the acquisition period of future meal information may be determined based on the use cycle as in the fourth example of batch processing.
  • the length of the predetermined period or predetermined time shown above may be one year, one month, one week or the like, or may be one hour or several hours.
  • the program of embodiment is a program which makes an information processing apparatus (CPU etc.) perform each process in the recipe management server 1 It is.
  • the program according to the embodiment causes the information processing apparatus to execute a user specifying function for specifying a target user as a presentation destination of information. Further, the information processing apparatus is caused to execute a meal information acquisition function for acquiring meal information including at least a use period corresponding to the information providing source user related to the identified target user. Furthermore, the information processing apparatus is caused to execute a use cycle specifying function for specifying a use cycle for each cooking category based on the use time included in the acquired meal information. Furthermore, the recommended category based on the presentation time for each cooking category calculated based on the latest usage time of the latest usage time included in the acquired meal information and the specified usage cycle The information processing apparatus is caused to execute a recommended category specifying function for specifying a cooking category.
  • this program is a program for causing the recipe management server 1 to execute the processes in steps S201 to S207 in FIG. 6 and the processes in FIGS. 7 to 19.
  • Such a program can be recorded in advance in an HDD as a storage medium built in a device such as a computer device or a ROM in a microcomputer having a CPU. Alternatively, it can be stored (recorded) temporarily or permanently in a removable storage medium such as a semiconductor memory, memory card, optical disk, magneto-optical disk, or magnetic disk. Such a removable storage medium can be provided as so-called package software. Further, such a program can be installed from a removable storage medium to a personal computer or the like, or can be downloaded from a download site via a network such as a LAN or the Internet.
  • 1 Recipe Management Server 1a Recipe Management Unit, 1b User Management Unit, 1c Meal Information Acquisition Unit, 1d Use Period 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

毎日の食事を考える煩わしさを抑制しつつ、ユーザによるメニューの選択傾向を考慮し、飽きのこない食事を行うための情報を提供可能なサービスを提供する。そのために情報処理装置は、情報の提示先となる対象ユーザを特定するユーザ特定部と、前記特定された対象ユーザに関連する情報提供元ユーザに対応する少なくとも利用時期を含む食事情報を取得する食事情報取得部と、前記取得した食事情報に含まれる利用時期に基づいて、料理カテゴリ毎の利用周期を特定する利用周期特定部と、前記取得した食事情報に含まれる利用時期のうち最も利用時期が遅い最終利用時期と前記特定された利用周期と、に基づいて算出された料理カテゴリ毎の提示時期に基づいて推薦カテゴリとなる料理カテゴリを特定する推薦カテゴリ特定部と、前記推薦カテゴリに基づいて推薦情報を前記対象ユーザに提示する制御を行う提示制御部と、を備える。

Description

情報処理装置、情報処理方法、プログラム
　本発明は、レシピを管理する情報処理装置、情報処理方法及びプログラムについての技術分野に関する。詳しくは、ユーザにレシピを提示するための各種処理に関する。
特開２０１５－１５３２８６号公報 特開２００３－２５６５７７号公報 特開２０１５－０２８７６７号公報
　近年では、一般ユーザの投稿などによって蓄積されたレシピの情報を提供するレシピ検索サービスなどが普及している。
　一般的に毎日の食事を考えることは煩わしい作業である。そのため、ユーザにレシピ情報などを推薦（提供）するための様々な技術が提案されている。
　例えば、特許文献１には、料理のメニュー情報及び食材の在庫情報とユーザの嗜好情報を用いてユーザの好みにあった材料を使用したメニュー情報を提供する技術について記載されている。
　また、特許文献２には、ユーザの健康状態と生活環境と疾患に応じた献立スケジュールのうちユーザに選択された献立スケジュールに設定された弁当を発注する技術について記載されている。
　更に、特許文献３には、以前推薦されたレシピが既出レシピとして記憶されており、既出レシピと重複するレシピを除外して残りのレシピを提供する技術について記載されている。
　しかし、特許文献１に記載の技術によって提供されるメニューは、ユーザの好みの材料を含むメニューに限定されるため、ユーザによって選択できる選択肢がマンネリ化してしまう。
　また、特許文献２に記載の技術によって提供されるメニューは、健康状態と生活環境と疾患に応じたメニューに限定されるため、ユーザによって選択できる選択肢がワンパターンとなってしまうといった問題がある。
　更に、特許文献３に記載の技術によって提供されたレシピは、所定期間内に再度提供されることを抑制させることができるが、ユーザによるレシピの選択傾向に柔軟に対応することができないといった問題がある。
　そこで、本発明は、毎日の食事を考える煩わしさを抑制しつつ、ユーザによるメニューの選択傾向を考慮し、飽きのこない食事を行うための情報を提供可能なサービスを提供する。
　本発明に係る情報処理装置は、情報の提示先となる対象ユーザを特定するユーザ特定部と、前記特定された対象ユーザに関連する情報提供元ユーザに対応する少なくとも利用時期を含む食事情報を取得する食事情報取得部と、前記取得した食事情報に含まれる利用時期に基づいて、料理カテゴリ毎の利用周期を特定する利用周期特定部と、前記取得した食事情報に含まれる利用時期のうち最も利用時期が遅い最終利用時期と前記特定された利用周期と、に基づいて算出された料理カテゴリ毎の提示時期に基づいて推薦カテゴリとなる料理カテゴリを特定する推薦カテゴリ特定部と、前記推薦カテゴリに基づいて推薦情報を前記対象ユーザに提示する制御を行う提示制御部と、を備えたものである。
　これにより、ユーザの潜在的なニーズを汲み取った情報（推薦カテゴリ）が提示される。
　上記した情報処理装置は、前記特定された推薦カテゴリに関連する料理カテゴリの利用に基づいて前記特定された推薦カテゴリの前記提示時期を調整する提示時期調整部を更に備えてもよい。
　これにより、類似する料理カテゴリが所定期間内に利用された場合やユーザの先の予定を考慮した情報提示が行われる。
　前記料理カテゴリは階層構造を有し、上記した情報処理装置の前記推薦カテゴリ特定部は、前記特定された利用周期が所定の下限閾値以下または未満である場合に利用周期が前記下限閾値以下または未満とされた料理カテゴリの下位カテゴリについての前記利用周期及び提示時期を取得して前記推薦カテゴリの特定を行ってもよい。
　これにより、全ての料理カテゴリについての利用周期及び提示時期を取得する必要が無い。
　前記推薦カテゴリは階層構造を有し、前記提示時期は、前記料理カテゴリのうち前記利用周期が下限閾値以上またはより大きいとされた料理カテゴリについて算出され、上記した情報処理装置の前記推薦カテゴリ特定部は、前記特定された利用周期が所定の下限閾値以上またはより大きいとされた料理カテゴリの中から前記推薦カテゴリの特定を行ってもよい。
　これにより、利用周期が短すぎる料理カテゴリに対して提示時期が算出されることが無くなる。
　例えば、その下位となる料理カテゴリに対して提示時期が算出される。延いては、頻繁に同じ料理カテゴリが推薦カテゴリとして提示されることが無くなる。
　上記した情報処理装置の前記提示制御部は、前記推薦カテゴリ毎に優先度を付与し、該優先度に応じて前記提示を行ってもよい。
　これにより、ユーザにとって有意義な情報ほど優先度を高くすることが可能となる。
　上記した情報処理装置の前記食事情報取得部は、前記利用周期に基づいて前記食事情報の取得起算時点を決定し、該取得起算時点から現在までの食事情報を取得してもよい。
　これにより、一度算出した利用周期に基づいて次回以降の各処理のための食事情報の取得の範囲（期間）が決定される。
　前記対象ユーザと関連する関連ユーザが登録されている場合において、上記した情報処理装置の前記食事情報取得部は、前記対象ユーザと前記関連ユーザのうち前記食事情報が充実しているユーザの食事情報を取得してもよい。
　これにより、充実した食事情報を元に利用周期や提示時期が算出され、それによって特定された推薦カテゴリが提示される。
　本発明に係る情報処理方法は、情報の提示先となる対象ユーザを特定するユーザ特定ステップと、前記特定された対象ユーザに関連する情報提供元ユーザに対応する少なくとも利用時期を含む食事情報を取得する食事情報取得ステップと、前記取得した食事情報に含まれる利用時期に基づいて、料理カテゴリ毎の利用周期を特定する利用周期特定ステップと、前記取得した食事情報に含まれる利用時期のうち最も利用時期が遅い最終利用時期と前記特定された利用周期と、に基づいて算出された料理カテゴリ毎の提示時期に基づいて推薦カテゴリとなる料理カテゴリを特定する推薦カテゴリ特定ステップと、前記推薦カテゴリに基づいて推薦情報を前記対象ユーザに提示する制御を行う提示制御ステップと、を
を備えたものである。
　この情報処理方法により、毎日の食事を考える煩わしさを抑制しつつ、ユーザによるメニューの選択傾向を考慮し、飽きのこない食事を行うための情報を提供可能な環境を提供する。
　本発明に係るプログラムは、上記情報処理方法として実行する処理を情報処理装置に実行させるプログラムである。これらのプログラムにより上記の情報処理装置を実現する。
　本発明によれば、毎日の食事を考える煩わしさを抑制しつつ、ユーザによるメニューの選択傾向を考慮し、飽きのこない食事を行うための情報を提供可能なサービスを提供することができる。
本発明の実施の形態の情報処理装置を含む全体構成を示す説明図である。 レシピ管理サーバの機能構成を示す図である。 コンピュータ装置のブロック図である。 ユーザＤＢの例を示す図である。 食事情報ＤＢの例を示す図である。 処理の流れの一例を示す図である。 推薦情報取得処理を示すフローチャートである。 バッチ処理を示すフローチャートである。 食事情報取得処理を示すフローチャートである。 利用周期特定処理を示すフローチャートである。 第２の実施の形態における推薦情報取得処理を示すフローチャートである。 バッチ処理の第２例を示すフローチャートである。 バッチ処理の第２例における提示時期調整処理を示すフローチャートである。 バッチ処理の第２例における提示時期調整処理の別の例を示すフローチャートである。 バッチ処理の第３例における提示時期調整処理を示すフローチャートである。 バッチ処理の第４例における食事情報取得処理を示すフローチャートである。 バッチ処理の第４例における利用周期特定処理を示すフローチャートである。 情報提供元ユーザ特定処理の変形例２を示すフローチャートである。 提示時期算出処理の変形例を示すフローチャートである。 階層化された料理カテゴリの例を示す図である。
　以下、実施の形態を次の順序で説明する。
＜１．全体構成＞
＜２．ハードウェア構成＞
＜３．ＤＢ＞
［３－１．ユーザＤＢ］
［３－２．レシピＤＢ］
［３－３．検索ＤＢ］
［３－４．食事情報ＤＢ５３］
［３－５．ウェブページＤＢ］
＜４．処理の流れ＞
［４－１．第１の実施の形態］
［４－２．バッチ処理］
［４－３．第２の実施の形態］
［４－４．バッチ処理の第２例］
［４－５．バッチ処理の第３例］
［４－６．バッチ処理の第４例］
＜５．変形例＞
［５－１．情報提供元ユーザ特定処理の変形例１］
［５－２．情報提供元ユーザ特定処理の変形例２］
［５－３．提示時期算出処理の変形例］
＜６．まとめ＞
＜７．プログラム及び記憶媒体＞
＜１．全体構成＞

　先ず、本発明の実施の形態における全体構成を説明する。
　尚、以下の説明においては、レシピとして料理レシピ（以降では単にレシピという）を例に挙げて説明する。レシピには、調理手順や使用食材や調理器具などの情報が含まれている。
　また、飽きのこない食事をするためにユーザに提供する情報（以降推薦情報と記載する）は、ユーザが食事をする際に参考にできる情報であり、具体的には、使用食材や調理方法が記載された１又は複数のレシピ情報であってもよいし、外食の際の店舗選択のための情報として料理カテゴリ（「ラーメン」や「カレー」など）の情報であってもよい。
　検索クエリに応じたレシピの検索やレシピの投稿などが可能なサービスを提供するためのポータルサイトとして、レシピ管理サーバ１が運営するレシピサイトを例に挙げる。
　本発明の情報処理装置を含む全体構成を図１に示す。
　レシピ管理サーバ１は、通信ネットワーク２を介して、ユーザ端末３，３，３，・・・と相互に通信可能な状態で接続されている。また、レシピ管理サーバ１は、ユーザに関する情報が記憶されるユーザＤＢ（Database）５０、レシピに関する情報が記憶されるレシピＤＢ５１、検索クエリや検索結果の情報が記憶される検索ＤＢ５２、ユーザの食事情報（後述）が記憶される食事情報ＤＢ５３、レシピサイトを構成する各種ウェブページのウェブページデータが記憶されるウェブページＤＢ５４と接続されている。
　尚、レシピ管理サーバ１は、本発明の情報処理装置の実施の形態に相当する。
　レシピ管理サーバ１は、ユーザから投稿されるレシピを管理する処理や、検索クエリに応じたレシピを提示するための処理を行う情報処理装置である。また、レシピ管理サーバ１は、ユーザに提示する推薦情報（レシピ情報や料理カテゴリ情報）を提示するための各種処理を実行する。具体的な構成に関しては後述する。
　通信ネットワーク２の構成は特に限定されるものではなく、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網などが想定される。
　また通信ネットワーク２の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線などの有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網などの無線でも利用可能である。
　ユーザ端末３は、レシピをレシピ管理サーバ１に投稿するユーザや、レシピ管理サーバ１が管理するレシピ情報の検索や閲覧を行うユーザが使用する端末である。また、レシピ管理サーバ１から提示される推薦情報を閲覧するユーザが使用する端末でもある。
　ユーザ端末３では、必要に応じて各種の送受信処理や表示処理などが実行される。また、ユーザ端末３は、例えば、通信機能を備えたＰＣ（Personal Computer）やフィーチャーフォンやＰＤＡ（Personal Digital Assistant）、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。
　レシピ管理サーバ１は、図２に示すように、レシピ管理部１ａ、ユーザ管理部１ｂ、食事情報取得部１ｃ、利用周期特定部１ｄ、提示時期算出部１ｅ、提示時期調整部１ｆ、推薦カテゴリ特定部１ｇ、推薦レシピ抽出部１ｈ、提示制御部１ｉを備えている。
　レシピ管理部１ａは、ユーザが投稿したレシピ情報（レシピタイトルと使用食材と調理方法とレシピが属する料理カテゴリ情報などがレシピ情報を投稿したユーザを識別する識別情報と紐付けられた情報）をレシピＤＢ５１に記憶することにより管理する。例えば、あるユーザが投稿した「野菜カレー」のレシピは、カテゴリ「カレー」に属するレシピであり、使用食材情報として、「じゃがいも」、「人参」、「タマネギ」、「ブロッコリー」、「トマト」、「ほうれん草」や、調味料（「塩」や「胡椒」など）や、それに準ずるもの（例えば「カレールー」など）が紐付けられて記憶される。
　また、レシピ管理部１ａは、投稿されたレシピに対して投稿された作成レポートをレシピ毎に管理する。作成レポートは、投稿されたレシピを利用して他のユーザが実際に料理を行った際に、当該レシピに対する感想（例えば、料理を行ったユーザが感じた料理のおいしさや調理手順の手軽さなど）を記したレポートである。作成レポートは、レシピＤＢ５１の各レシピに紐付けられて管理される。
　ユーザ管理部１ｂは、レシピ管理サーバ１が提供する各種のサービスを利用するユーザの情報を管理するために、種々の処理を行う。
　例えば、ユーザを一意に特定可能なユーザＩＤに対して、氏名、年齢、性別、連絡先（電話番号や電子メールアドレス等）を紐付け、ユーザＤＢ５０へ記憶することにより管理を行う。また、ユーザＤＢ５０からユーザ情報を取得する処理を行う。
　食事情報取得部１ｃは、対象となるユーザの処理時点よりも過去に飲食した食事情報や処理時点よりも未来に飲食されると推定される食事情報などを食事情報ＤＢ５３から取得する処理を行う。
　食事情報ＤＢ５３に記憶される各種の食事情報については、後述する。
　食事情報の取得対象となる期間は、例えば、直近の１ヶ月間などのように所定期間であってもよいし、ユーザによって異なる期間であってもよい。また、後述する料理カテゴリの利用周期に応じて期間を決めてもよい。
　具体的な各例については、後述する。
　食事情報取得部１ｃは、所定期間或いは算出された取得対象となる期間に応じて取得起算時点を決定し、該取得起算時点から現在までの食事情報を取得する。例えば、取得対象となる期間が１０日であった場合、現在から１０日前となる取得起算時点を算出し、そこから現在までの食事情報を取得する。
　また、食事情報の取得対象となるユーザには、いくつかの例が考えられる。例えば、ログインを行い食事に関する推薦情報の提示を受けるユーザ自身であってもよいし、推薦情報の提示を受けるユーザが指定したユーザ（例えば当該ユーザの夫など）であってもよい。更に、情報の提示を受けるユーザ及びその関連ユーザの中で、食事情報が最も充実しているユーザであってもよい。
　勿論、複数のユーザ（例えば、情報の提示を受けるユーザとその夫と子供の３人のユーザ）全ての食事情報を取得してもよい。
　利用周期特定部１ｄは、過去の食事情報に基づいて、各料理カテゴリについて当該料理カテゴリに属する料理を利用する周期をユーザ毎に算出する。料理カテゴリに属する料理の利用とは、当該料理カテゴリに属する料理に関するレシピの利用（レシピを利用したと推定される状態を含む）や、当該料理カテゴリに属する料理の飲食（即ち外食による食事など）である。即ち、当該料理カテゴリに属する料理を何らかの形で飲食したことを指す。
　提示時期算出部１ｅは、料理カテゴリの利用周期と最終利用時期に基づいて、料理カテゴリ毎の提示時期を算出する。最終利用時期とは、料理カテゴリを最後に利用した時期（或いは時間）を示す情報である。
　尚、提示時期算出部は、階層化された料理カテゴリにおいて、全てのカテゴリレベル毎に算出してもよいし、所定のカテゴリレベルのみ算出してもよい。また、料理カテゴリ毎に異なるカテゴリレベルについて算出してもよいし、料理カテゴリ毎に異なる数のカテゴリレベルについて算出してもよい。
　提示時期調整部１ｆは、料理カテゴリ毎に算出された提示時期に対して、種々の要因に応じた調整を行う処理を実行する。即ち、提示時期が３日後となっている料理カテゴリに対して、後述する各種の要因を考慮して一日早い２日後を提示時期とする（即ち調整する）処理などを実行する。
　また、類似した料理カテゴリの利用に基づいた提示時期の調整を行う。例えば、「そば」の料理カテゴリの利用が直近にあった場合、「そば」と類似する「うどん」の料理カテゴリの提示時期を延期する（即ち後ろに延ばす）処理などを実行する。
　各種の具体的な例については、後述する。
　推薦カテゴリ特定部１ｇは、提示時期算出部１ｅや提示時期調整部１ｆによって最終的に決定された提示時期を参照し、提示時期が到来した料理カテゴリを推薦カテゴリとして特定する処理を実行する。
　推薦レシピ抽出部１ｈは、推薦カテゴリに属するレシピを抽出する処理を実行する。
　提示制御部１ｉは、抽出されたレシピをユーザ端末３へ提示するための処理を実行する。提示する情報が複数ある場合には、各情報に提示優先度を付与してもよい。即ち、提示優先度に応じて情報をユーザ端末３へ提示する。
　例えば、推薦情報の提示の一例として複数のレシピの提示を行う場合に、提示優先度に応じて各レシピがユーザ端末３の画面上に並ぶように情報を送信する。
　レシピ管理サーバ１には、他にも、各種情報を送受信する機能や、ユーザのログイン操作に対する認証処理などを実現するために必要な各部が設けられている。認証処理は、ユーザ端末３から送信されたログイン情報としてのユーザＩＤ（Identification）とログインパスワードを、ユーザＤＢ５０に記憶された認証情報と照合する処理である。
＜２．ハードウェア構成＞

　図３は、図１に示したレシピ管理サーバ１とユーザ端末３のハードウェア、及び、ユーザＤＢ５０とレシピＤＢ５１と検索ＤＢ５２と食事情報ＤＢ５３とウェブページＤＢ５４のハードウェアを例示する図である。それぞれのサーバや端末、ＤＢにおけるコンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ（Read Only Memory）１０２に記憶されているプログラム、又は記憶部１０８からＲＡＭ（Random Access Memory）１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
　ＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インターフェース１０５も接続されている。
　入出力インターフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力装置１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどよりなる出力装置１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、通信ネットワーク２を介しての通信処理や機器間通信を行う通信部１０９が接続されている。
　入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。
　このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
　ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、レシピ管理サーバ１、ユーザ端末３、ユーザＤＢ５０、レシピＤＢ５１、検索ＤＢ５２、食事情報ＤＢ５３、ウェブページＤＢ５４のそれぞれにおいて後述する情報処理や通信が実行される。
　尚、レシピ管理サーバ１、ユーザ端末３、及び、ユーザＤＢ５０、レシピＤＢ５１、検索ＤＢ５２、食事情報ＤＢ５３、ウェブページＤＢ５４を構成するそれぞれの情報処理装置は、図３のようなコンピュータ装置が単一で構成されることに限らず、システム化された複数のコンピュータ装置によって構成されてもよい。複数のコンピュータ装置は、ＬＡＮなどによりシステム化されていてもよいし、インターネットなどを利用したＶＰＮ（Virtual Private Network）などにより通信可能な状態で遠隔地に配置されたものでもよい。
　レシピ管理サーバ１としての各機能は、情報処理装置においてＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し以下において説明する各構成の処理の全部又は一部をハードウェアにより実現してもよい。
　また各機能をソフトウエアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。一つのプログラムにより複数の機能の処理が実行されてもよいし、一つの機能が複数のプログラムモジュールの連携で実現されてもよい。
＜３．ＤＢ＞

　レシピ管理サーバ１が管理する各ＤＢの説明を行う。各ＤＢは、レシピ管理サーバ１がアクセス可能とされていればどのような形態で実現されていてもよい。例えばレシピ管理サーバ１と同一システム内の記憶部に各ＤＢのすべてが形成されていてもよいし、各ＤＢの一部又は全部が別体とされていてもよいし、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん各ＤＢが一つの装置（例えば一つのＨＤＤ等）内に形成されている必要はない。また各ＤＢのそれぞれが、それぞれ一つのＤＢとして構成される必要もない。例えばユーザＤＢ５０として記憶される情報が、複数のユーザＤＢ（例えばログイン用のユーザＤＢと取引用のユーザＤＢなど）により記憶管理されてもよい。以下説明する各ＤＢは、実施の形態の処理に関連する情報の記憶部を、それぞれ一つのＤＢの形態で例示したものに過ぎない。
［３－１．ユーザＤＢ］
　ユーザＤＢ５０にはレシピ管理サーバ１が提供するサービスを受けるユーザの情報が記憶される。例えば、一人のユーザを特定可能な一つのユーザＩＤ（Identification）に対して、ログインパスワード、氏名、年齢、性別、メールアドレスなどの個人的な情報が紐付けられて記憶される。また、料理カテゴリ毎の利用周期や常用食事情報などもユーザＩＤに紐付けられて記憶される。
　ここで、常用食事情報について説明する。常用食事情報はユーザが毎日のように飲食している食事の情報であり、ユーザ毎に異なる。例えば、あるユーザにとっての常用食事は、「ご飯」や「パン」や「味噌汁」である。これらのレシピは、利用周期を算出することが不適当なほど毎日のように飲食されているものである。このようなレシピ（或いは料理カテゴリ）は、提示時期などの算出の対象とはならず、ユーザに提示する推薦情報に含まれなくてもよい。
　常用食事情報として記憶されるレシピ（或いは料理カテゴリ）は、利用周期が所定期間よりも短い（例えば１日）料理カテゴリであって、それ以上細分化できない料理カテゴリ（即ち下位の料理カテゴリが存在しない）に属している。また、そのようなレシピは、幅広く他のレシピと組み合わせられるものである。具体的には、あらゆる食事にサラダを付けるユーザにとっては、サラダが常用食事となる。即ち、そのようなユーザに対して、サラダの利用周期から提示時期を算出し、情報をユーザに提供することは、ユーザにとって価値のある情報提供にはなり難い。
　尚、利用周期が所定期間よりも短かったとしても下位の料理カテゴリが存在する場合には、下位の料理カテゴリにおいて提示時期の算出が行われる。具体的には、「麺類」の料理カテゴリの利用周期が１日であっても、その下位カテゴリである「ラーメン」、「パスタ」、「うどん」、「そば」などでは、１日よりも長い適切な利用周期となる可能性が高い。
　従って、「ラーメン」や「パスタ」の料理カテゴリの利用周期から提示時期が算出される。
　ユーザＤＢ５０には、他にも、ユーザ毎の嗜好情報が記憶されてもよい。嗜好情報は、ユーザによるレシピ情報や料理情報に関する検索や閲覧などの挙動に応じてレシピ管理サーバ１が判定したユーザの好みの食材（嗜好食材）や嫌いな食材（非嗜好食材）の情報や、ユーザに関わる投稿情報（テキスト情報やタグ情報や画像情報など）に基づいてレシピ管理サーバ１が判定したユーザの好みの食材（嗜好食材）や嫌いな食材（非嗜好食材）である。嗜好情報は、ユーザがレシピ検索を行った際に利用される。
　具体的に、ユーザＤＢ５０に記憶される各種情報について図４を参照して説明する。
　図４には、ユーザＤＢ５０に記憶されたユーザＡに関する情報の一部が示されている。ユーザＩＤに対して、ログインパスワード、氏名、年齢、性別、メールアドレスが紐付けられて記憶されている。また、料理カテゴリ毎の利用情報が記憶されている。利用情報とは、料理カテゴリＩＤに対して利用周期や最終利用時期や提示時期が紐付けられた情報であり、ユーザに推薦情報を提示するために用いられる情報である。
［３－２．レシピＤＢ］
　レシピＤＢ５１は、ユーザから投稿されたレシピの情報が記憶されるＤＢである。具体的には、それぞれのレシピを識別可能なレシピＩＤに対して、レシピを投稿したユーザを特定するユーザＩＤと、投稿日時情報と、レシピが属するカテゴリ情報と、レシピの使用食材情報（分量などを含む）と、レシピの調理手順と、料理画像（完成した料理の画像や調理途中の料理の画像）などの画像情報と、レシピを実際に利用した（料理を作成した）他のユーザによって投稿された作成レポートを特定する作成レポートＩＤと、が紐付けられて記憶される。
　また、レシピの詳細ページのＵＲＬ（Uniform Resource Locator）情報がレシピＩＤに紐付けられて記憶されてもよい。
　更に、レシピＤＢ５１には、各レシピに対して投稿された作成レポートの情報が記憶される。作成レポートの情報としては、レポート内容を示すテキストデータや調理した料理の画像や投稿者を識別可能なユーザＩＤや投稿日時情報などが記憶される。
［３－３．検索ＤＢ］
　検索ＤＢ５２は、検索クエリと対応した検索結果が記憶されるＤＢである。具体的には、「カレー」や「ハンバーグ」などの料理名や「きのこ」や「トマト」などの食材名などの検索クエリに応じて、複数のレシピが検索結果として紐付けられて記憶される。
　例えば、ユーザが指定した検索クエリに応じて検索処理が実行され、その結果抽出された検索結果が検索クエリに紐付けられて検索ＤＢ５２に記憶される。このように紐付けが行われることで、新たな検索要求があった際に検索処理を実行せずに以前の検索結果を利用した検索結果の提示を行うことができる機会が増える。
　尚、予め定期的に検索キーワードを用いた検索処理を実行しておき、その結果抽出された検索結果が検索キーワードに紐付けられて検索ＤＢ５２に記憶されるようにしてもよい。
［３－４．食事情報ＤＢ５３］
　食事情報ＤＢ５３には、ユーザが過去に飲食した食事情報や今後飲食すると推定される食事情報が履歴情報として記憶される。
　例えば、過去に利用した或いは未来に利用が推定されるレシピの情報や、過去に飲食した或いは未来に飲食が推定される料理の情報や料理カテゴリの情報などである。食事情報ＤＢ５３に記憶される各食事情報には、料理カテゴリの情報ユーザの食事情報などが記憶される。
　過去に飲食した食事情報として食事情報ＤＢ５３に記憶される情報は、例えば、履歴情報に含まれるレシピの利用履歴、閲覧履歴や検索履歴などに基づいて、ユーザが利用したレシピであると特定又は推定されたレシピの情報や、履歴情報に含まれる飲食店やメニューの閲覧履歴や検索履歴などに基づいて、外食などでユーザが飲食したと特定又は推定された料理や料理カテゴリの情報や、投稿情報に含まれるテキスト情報やタグ情報や画像情報などに基づいて、ユーザが飲食したと特定又は推定された料理や料理カテゴリの情報などである。尚、予め飲食給食の献立表などから得た情報であってもよい。
　未来に飲食されると推定される食事情報として食事情報ＤＢ５３に記憶される情報は、上記と同様に予め飲食される料理のスケジュールに関する情報（例えば給食の献立情報や社員食堂の献立情報など）から得た情報である。また、利用頻度の高い飲食店などの料理を提供するサービスに関する情報に基づいて特定又は推定された料理や料理カテゴリの情報であってもよい。尚、これらの情報は、飲食店などの料理を提供するサービスに関わるウェブページなどから取得してもよいし、ユーザによって入力された情報を取得してもよい。
　食事情報ＤＢ５３に記憶される履歴情報としての各食事情報には、料理カテゴリの情報が含まれる。
　具体的には、図５に示すように、ユーザを特定するユーザＩＤに対して、複数の料理カテゴリの利用履歴が食事情報として記憶される。利用履歴一つに対して、利用日時（利用時期）、料理カテゴリＩＤ、取得ルート、利用形態が紐付けられて記憶される。
　図５は、利用日時順に履歴が並べられている例である。料理カテゴリＩＤは、料理カテゴリを一意に特定可能なものである。
　ここで、料理カテゴリについて説明する。料理カテゴリは階層化されており、例えば「和食」「洋食」などの大分類としての種別、「日本料理」「中華料理」「イタリア料理」「フランス料理」「タイ料理」という地域レベルの種別、「カレー」「ハンバーグ」「ラーメン」などの料理名に応じたレベルの種別、さらには「ビーフカレー」「チキンカレー」「キーマカレー」などの細かいレベルの種別などがある。
　尚、料理種別のレベルは多様であり、例えば下記（Ａ）に示すように中分類は肉料理、魚料理、野菜料理のような主たる食材の分類としてもよいし、下記（Ｂ）のように、大分類は「主食」「おかず」「副菜」などとしてもよい。
（Ａ）大分類：和食（その他：洋食など）
　　　　　　　中分類：肉料理
　　　　　　　　　　　細分類：肉じゃが／牛肉のしぐれ煮など
　　　　　　　中分類：魚料理
　　　　　　　　　　　細分類：鯖の味噌煮／鮭のちゃんちゃん焼きなど
　　　　　　　中分類：野菜料理
　　　　　　　　　　　細分類：焼き野菜のロースト／きんぴらごぼうなど
（Ｂ）大分類：主食（その他：おかず／副菜など）
　　　　　　　中分類：肉料理
　　　　　　　　　　　細分類：ハンバーグ／コロッケなど
　　　　　　　中分類：魚料理
　　　　　　　　　　　細分類：タコのフリット／タラのムニエルなど
　　　　　　　中分類：野菜料理
　　　　　　　　　　　細分類：ポトフ／野菜のトマト煮など
　以下の例においては料理カテゴリが３段階に階層化されている例を用いて各説明を行う。
　料理カテゴリにおける大分類は「ご飯もの」、「麺類」、「肉料理」、「魚料理」、「カレー」などのように主たる食材によって分類されている。
　そして、「麺類」の料理カテゴリの下位カテゴリ（中分類）には、「ラーメン」、「パスタ」、「うどん」、「そば」などの料理カテゴリが設けられている。
　更に、「ラーメン」の料理カテゴリの下位カテゴリ（小分類）には、「醤油ラーメン」、「味噌ラーメン」、「塩ラーメン」、「豚骨ラーメン」などの料理カテゴリが設けられている。
　以降の説明においては、大分類の料理カテゴリ（「麺類」など）をカテゴリレベル１の料理カテゴリと記載する。また、その下位の料理カテゴリ（「ラーメン」などの中分類）をカテゴリレベル２の料理カテゴリと記載する。同様に、更に下位の料理カテゴリ（「醤油ラーメン」などの小分類）をカテゴリレベル３の料理カテゴリと記載する。即ち、下位カテゴリ（細分化されたカテゴリ）ほどカテゴリレベルを示す数値が増加するように設定されている。
　各料理カテゴリには、各種のレシピが属している。例えば、「我が家の味噌ラーメン」というレシピは、「味噌ラーメン」の料理カテゴリに属するレシピであり、「ラーメン」の料理カテゴリに属するレシピでもあり、更に「麺類」の料理カテゴリに属するレシピでもある。
　図５の説明に戻ると、料理カテゴリＩＤは、階層化された料理カテゴリにおいて料理カテゴリ間の関係が分かるように構成されている。
　具体的には、カテゴリレベル１の料理カテゴリを示す二桁の数値と、カテゴリレベル２の料理カテゴリを示す二桁の数値と、カテゴリレベル３の料理カテゴリを示す一桁の数値で構成されている。例えば、「Ｃ０１００２」とされた料理カテゴリＩＤは、カテゴリレベル１の料理カテゴリを特定する数値「０１」とカテゴリレベル２の料理カテゴリを特定する数値「００」とカテゴリレベル３の料理カテゴリを特定する数値「２」を含んで構成されている。
　即ち、カテゴリＩＤが「Ｃ０１００２」とされた料理カテゴリと「Ｃ０１０１３」とされた料理カテゴリは、カテゴリレベル１において同じ料理カテゴリに属すと共に、カテゴリレベル２において異なる料理カテゴリに属していることが分かる。
　続いて、取得ルートについて説明する。取得ルートは、当該利用履歴としての食事情報をどのような経路で取得したかを示す情報である。例えば、取得ルートが「ＳＮＳ（Social Networking Service）投稿」とされた履歴情報は、ＳＮＳに投稿された記事に基づいて当該料理カテゴリに属する料理を飲食したと推定された履歴情報である。また、「レシピ利用」とされた履歴情報は、作成レポートの投稿やレシピの閲覧履歴などによって当該料理カテゴリに属する料理を飲食したと推定された履歴情報である。更に、「給食情報」とされた履歴情報は、給食の献立表などの料理のスケジュールに関する情報から当該料理カテゴリに属する料理を飲食したと推定された履歴情報である。これらの情報は、例えば、履歴情報の確からしさ（即ち、本当に飲食したかどうかの確度）として用いられる。
　最後に利用形態について説明する。
　利用形態は、料理カテゴリの利用形態を示している。例えば、定食屋などの店舗での飲食が推定されたものであれば、「外食」とされる。また、取得ルートが「レシピ利用」であれば、レシピを印刷することによってレシピの利用（即ち料理カテゴリの利用）が推測された場合には「印刷」とされ、作成レポートの投稿によってレシピの利用が推測された場合には「作成レポート投稿」とされ、レシピの所定時間の閲覧によってレシピの利用が推測された場合には「閲覧」とされる。利用形態の情報は、例えば、取得ルートと合わせて履歴情報の確からしさとして用いられる。
［３－５．ウェブページＤＢ］
　ウェブページＤＢ５４には、レシピ管理サーバ１がユーザに提供する各種ウェブページのデータが記憶される。具体的には、レシピ検索ページや特集ページや検索結果ページやレシピ詳細ページやユーザページなどのウェブページデータである。
　ウェブページデータとしては、ウェブページのＵＲＬ（Uniform Resource Locator）情報と各ウェブページ上に配置されるオブジェクト（画像やテキストやバナーなど）の配置情報が記憶される。配置情報とは、ウェブページ上における各オブジェクトの配置態様（位置や大きさ、色等）が記載された情報である。
　尚、ウェブページＤＢ５４に記憶される情報は、例えば、ＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible HyperText Markup Language）などの構造化文書ファイルで記憶されてもよい。
＜４．処理の流れ＞

　レシピ管理サーバ１が実行する各種処理について説明する。

［４－１．第１の実施の形態］
　先ず、ユーザが食事のための推薦情報（推薦カテゴリや推薦レシピの情報）を要求する際の第１の実施の形態の全体の流れについて、図６を参照して説明する。
　ユーザが推薦情報を得るためには、レシピ管理サーバ１が運営するサービスにログインすることが必要である。
　従って、ユーザがユーザ端末３を用いてログイン画面を表示させる操作を行ったことに応じ、ユーザ端末３はステップＳ１０１において、ログイン画面情報（即ちログイン画面を表示させるためのウェブページデータ）の要求処理を実行する。
　ログイン画面情報要求処理によりユーザ端末３からレシピ管理サーバ１へログイン画面情報要求が送信されると、レシピ管理サーバ１はステップＳ２０１において、ログイン画面情報送信処理を実行する。
　これにより、例えば、レシピ管理サーバ１から受信したレシピサイトのログイン画面情報（ウェブページデータ）に応じたウェブページがユーザ端末３上に表示される。
　尚、レシピ管理サーバ１はこのとき、ログイン画面をユーザ端末３上に表示させたことを履歴（即ちログイン画面の閲覧履歴）として記憶してもよい。
　次に、ユーザ端末３はステップＳ１０２において、ユーザの入力操作に応じたログイン情報（ユーザＩＤとログインパスワード）をレシピ管理サーバ１へ送信するログイン情報送信処理を実行する。
　ユーザ端末３からレシピ管理サーバ１へログイン情報が送信されると、レシピ管理サーバ１はステップＳ２０２において認証処理を実行し、続くステップＳ２０３においてログイン履歴を記憶する処理を実行し、ステップＳ２０４において認証結果通知処理を実行する。
　具体的には、レシピ管理サーバ１は、ユーザ端末３上で入力されたユーザＩＤとパスワードをユーザＤＢ５０に記憶された情報と比較して当該ユーザのログイン可否を判定し、当該ログイン可否情報を認証結果としてユーザ端末３へ通知する。尚、認証結果をユーザ端末３へ送信すると共に、レシピサイトのトップページのウェブページデータを送信してもよい。これにより、ユーザ認証がなされると共に、ユーザ端末３上にレシピサイトのトップページが表示される。
　尚、図６に示す一連の流れは、ステップＳ２０２の認証処理においてログイン可と判定された場合を示している。ステップＳ２０２においてログイン不可と判定した場合は、ユーザ端末３は再度ステップＳ１０２の処理を実行し、これに応じてレシピ管理サーバ１はステップＳ２０２の処理を実行する。
　続いて、ユーザ端末３はステップＳ１０３において、ユーザ操作に基づいて推薦情報を要求する処理を実行する。このユーザ操作は、例えば、ウェブページ上に設けられた推薦情報を得るための「お勧め情報を見る」ボタンを押下する操作などである。
　推薦情報要求がユーザ端末３からレシピ管理サーバ１へ送信されると、レシピ管理サーバ１はステップＳ２０５において、推薦情報取得処理を実行する。推薦情報取得処理は、ユーザ端末３に推薦情報として提示する料理カテゴリ（即ち推薦カテゴリ）を取得する処理である。
　ステップＳ２０５の推薦情報取得処理の詳細について、図７を参照して説明する。
　レシピ管理サーバ１は、ステップＳ３０１において一つの料理カテゴリを選択し、続くステップＳ３０２において当該料理カテゴリの提示時期情報を取得する。
　尚、料理カテゴリの提示時期は、図６及び図７の各処理を実行する前にバッチ処理などによって予め算出され、図４に示すユーザＤＢ５０に記憶されているように構成してもよい。尚、バッチ処理の詳細については後述する。
　続いて、レシピ管理サーバ１はステップＳ３０３において、当該料理カテゴリについて提示時期が条件を満たしているか（即ち現時刻において提示時期が経過したか）を判定する。
　提示時期が条件を満たしていると判定した場合、レシピ管理サーバ１はステップＳ３０４において、当該料理カテゴリを推薦カテゴリとして選択する。
　ステップＳ３０４の後、或いは、ステップＳ３０３において提示時期が条件を満たしていないと判定した後、レシピ管理サーバ１はステップＳ３０５において、処理を行っていない料理カテゴリがあるかどうかを判定する。
　処理を行っていない料理カテゴリがあると判定した場合、レシピ管理サーバ１はステップＳ３０１乃至Ｓ３０５の処理を再度実行する。
　一方、処理を行っていない料理カテゴリがないと判定した場合、図７に示す一連の処理を終了する。
　即ち、図７に示す処理を実行することにより、提示時期が到来した料理カテゴリが推薦カテゴリとして選択される。
　図６の説明に戻る。
　推薦情報として推薦カテゴリの情報を取得したレシピ管理サーバ１は、ステップＳ２０６において優先度付与処理を実行する。
　尚、優先度付与処理は、推薦カテゴリが複数ある場合に実行する処理であり、取得した推薦カテゴリが一つであった場合はステップＳ２０６の処理を実行しない。
　優先度付与処理には、いくつかの例が考え得る。例えば、最終利用時期からの経過時間が長い推薦カテゴリの優先度を上げることが考えられる。具体的には、最終利用時期が昨日である推薦カテゴリＡと１週間前である推薦カテゴリＢでは、推薦カテゴリＡよりも推薦カテゴリＢの優先度を上げる。
　また、優先度付与処理の他の例として、利用周期が短い推薦カテゴリＡの優先度を上げることが考えられる。具体的には、利用周期が１週間の推薦カテゴリＡと１ヶ月の推薦カテゴリＢでは、推薦カテゴリＢよりも推薦カテゴリＡの優先度を上げる。これは、優先度の低い推薦カテゴリが利用されなかった場合の影響を考えてのことである。即ち、１週間の利用周期が１日延びた場合と１ヶ月の利用周期が１日延びた場合では、１週間の利用周期が１日延びた場合の方が相対的に影響が大きいと考えられる。従って、利用されなかった場合の影響が大きい推薦カテゴリの優先度を上げる。
　推薦カテゴリに優先度を付与したレシピ管理サーバ１は、ステップＳ２０７において提示処理を行う。
　提示処理では、レシピ管理サーバ１からユーザ端末３に向けて優先度が付与された推薦カテゴリの情報が送信される。例えば、優先度順に推薦カテゴリの情報が配置されたウェブページを表示するためのＨＴＭＬデータが送信される。
［４－２．バッチ処理］
　レシピ管理サーバ１が実行するバッチ処理について説明する。バッチ処理では、料理カテゴリ毎の提示時期を算出する処理を実行する。
　具体的に、図８を参照して説明する。
　図８に示すバッチ処理は、一人のユーザに対しての提示時期を算出する処理である。即ち、全ユーザに対して提示時期を算出する場合には、図８に示す一連の処理をユーザの数だけ繰り返して実行することとなる。また、バッチ処理を行う必要のあるユーザが一人である場合は、図８に示す一連の処理を１回だけ行えばよい。
　先ず、レシピ管理サーバ１はステップＳ４０１において、レシピ情報の取得対象となるユーザを特定する処理を実行する。推薦情報の提示対象となるユーザを対象ユーザと記載するのに対して、レシピ情報の取得対象となるユーザは推薦情報の提示のための情報の提供元のユーザであることから情報提供元ユーザと記載する。
　即ち、情報提供元ユーザの情報に基づいて決定された推薦情報を対象ユーザに提示する。
　対象ユーザと情報提供元ユーザは必ずしも同一のユーザとは限らない。例えば、ユーザＡがユーザ端末３を用いてレシピ管理サーバ１のサービスを受ける場合を説明する。即ち、対象ユーザがユーザＡとなる場合である。
　このとき、情報提供元ユーザは、レシピ管理サーバ１のサービスを受けるユーザＡ自身であってもよいし、ユーザＡが指定したユーザＢであってもよい。
　具体的には、ユーザＡが自身の食事情報に基づいて推薦情報を受け取る場合、対象ユーザ及び情報提供元ユーザは共にユーザＡとなる。
　また、ユーザＡが配偶者であるユーザＢの食事情報に基づいて推薦情報を受け取る場合、対象ユーザはユーザＡとなり情報提供元ユーザはユーザＡが指定したユーザＢとなる。
　換言すれば、情報提供元ユーザを決めることは、料理カテゴリの提出時期を算出するために誰の食事情報に基づくかを決めることとなる。
　続いて、レシピ管理サーバ１はステップＳ４０２において、情報提供元ユーザの食事情報を食事情報ＤＢ５３から取得する処理を実行する。
　食事情報取得処理についてはいくつかの例を説明する。ここでは、図９を参照して一つの例を説明し、他の例については後述する。
　レシピ管理サーバ１は、食事情報取得処理において、ステップＳ５０１のように直近の所定期間における食事情報を取得する。所定期間は、例えば１ヶ月などのように固定の数値（期間）として定められている。固定の所定期間は、料理カテゴリの利用周期を算出するのに十分な期間であることが望ましい。即ち、一つの料理カテゴリが複数回利用される期間とすることが望ましい。
　図８の説明に戻る。
　続いて、レシピ管理サーバ１はステップＳ４０３において、利用周期特定処理を実行する。
　利用周期特定処理について、図１０を参照して説明する。
　利用周期特定処理は、情報提供元ユーザの食事情報（先のステップＳ４０２において取得した情報）に基づいて料理カテゴリ毎の利用周期を特定（算出）する処理である。
　先ず、レシピ管理サーバ１はステップＳ６０１において、一つの料理カテゴリを選択する処理を実行する。
　続いて、レシピ管理サーバ１はステップＳ６０２において、選択された料理カテゴリに常用食事情報が含まれているか（所属しているか）を確認する。
　常用食事情報が含まれていないと判定した場合、レシピ管理サーバ１は、選択された料理カテゴリの最後の利用日時（最終利用時期）をステップＳ６０３で取得し、更にもう一つ前の利用日時（利用時期）をステップＳ６０４で取得する。各利用日時の情報は、食事情報ＤＢ５３から取得する。
　利用日時とは、先に説明した料理カテゴリを利用した時間（或いは日付情報でもよい）であり、即ち料理カテゴリに属するレシピを利用した日時や料理カテゴリに属する料理を外食などで飲食した日時である。
　続くステップＳ６０５では、これら二つの利用日時の差分から利用周期を算出する処理をレシピ管理サーバ１は実行する。
　尚、二つの利用日時ではなくもっと多くの利用日時から平均的な差分を算出して利用周期としてもよい。
　ステップＳ６０５を実行した後、レシピ管理サーバ１はステップＳ６０６において、処理を行っていない料理カテゴリがあるかどうかを確認する。
　処理を行っていない料理カテゴリがあると判定した場合、レシピ管理サーバ１はステップＳ６０１の処理を再度実行する。
　一方、処理を行っていない料理カテゴリがあると判定した場合、レシピ管理サーバ１は図１０に示す一連の処理を終了する。
　尚、ステップＳ６０２において常用食事情報が含まれていると判定した場合、ステップＳ６０３乃至Ｓ６０５の各処理を実行せずにステップＳ６０６の処理を実行する。これは、常用食事情報が含まれた料理カテゴリは、前述のように、推薦情報として提示することは不適当であるため、利用周期を算出する必要が無いためである。
　再び図８の説明に戻る。
　全ての料理カテゴリについての利用周期を算出したレシピ管理サーバ１は、ステップＳ４０４において、利用周期から提示時期を算出する処理を実行する。
　提示時期は、最終利用時期と利用周期から次回の利用が予想される時期を提示時期として算出する。具体的には、例えば最終利用時期が３日前であり利用周期が１０日である場合、提示時期は７日後となる。
　図８に示す一連の処理を実行することにより、料理カテゴリ毎の提示時期が算出される。そして、その後、ユーザから推薦情報の要求を受信した場合に、図６のステップＳ２０５乃至Ｓ２０７の各処理を実行することにより、提示時期に基づいた推薦カテゴリが提示される。
　尚、ユーザからの推薦情報の要求を受信するまでに提示時期が渡過した料理カテゴリについては、ユーザに提示してもしなくてもよい。このとき、渡過した時間の長さによって提示するかどうかを決定してもよい。具体的には、渡過してからそれ程時間が経過していない場合は当該料理カテゴリを推薦カテゴリとしてユーザに提示するが、渡過してからの時間経過が長い場合には当該料理カテゴリを推薦情報として提示しないなどが考え得る。
　もちろん、渡過した時間の長さによらずにユーザに推薦情報を提示してもよい。
　尚、図８のステップＳ４０４の提示時期の算出は、全ての料理カテゴリに対して行ってもよいし、一部の料理カテゴリに対して行ってもよい。一部の料理カテゴリに対して提示時期の算出を行う場合は、先の図１０の利用周期特定処理においても一部の料理カテゴリの利用周期を算出すればよい。
　一部の料理カテゴリに対して提示時期を算出する例としては、例えば、カテゴリレベル２の料理カテゴリに対して提示時期を算出することが考えられる。これは、カテゴリレベル１に属する料理カテゴリでは利用周期が短すぎるため提示時期が頻繁に来てしまうことや、カテゴリレベル３に属する料理カテゴリでは利用周期が長すぎるため提示時期が中々来ないことを考慮してのことである。
［４－３．第２の実施の形態］
　第２の実施の形態では、推薦情報として料理カテゴリ（推薦カテゴリ）を提示するのではなく、レシピ情報（推薦レシピ）を提示する。
　具体的に、図６及び図１１を参照して説明する。
　レシピ管理サーバ１は図６に示すように、ユーザ端末３から推薦情報要求を受信すると、ステップＳ２０５においてユーザに提示する推薦情報を取得し、続くステップＳ２０６において優先度を付与し、ステップＳ２０７において提示処理を実行する。
　第２の実施の形態では、ステップＳ２０５の推薦情報取得処理の処理内容が異なる。
　第２の実施の形態における推薦情報取得処理の例を図１１に示す。
　推薦情報取得処理では、図１１に示すように、レシピ管理サーバ１はステップＳ３０１乃至Ｓ３０４において、料理カテゴリ毎の提示時期を取得し、提示時期が到来した料理カテゴリについては推薦カテゴリとして選択する処理を実行する。これらの処理は、図７において同符号を付して説明した処理と同様の処理であるため、詳細な説明は省略する。
　推薦カテゴリを選択したレシピ管理サーバ１は、続くステップＳ３０６において、推薦カテゴリに属するレシピを推薦レシピとして抽出する処理を実行する。
　例えば、推薦カテゴリが「カレー」である場合、料理カテゴリ「カレー」に属する「我が家のシーフードカレー」や「トマトたっぷりインドカレー」などのレシピが推薦レシピとして抽出される。
　尚、ステップＳ３０６の推薦レシピの抽出では、推薦カテゴリに属するレシピのうちユーザに推薦することが適切なレシピのみを推薦レシピとして抽出してもよい。
　ユーザに推薦することが適切なレシピとは、例えば、ユーザの好みの食材を含むレシピや好まない食材を含まないレシピなどである。また、ユーザが調理可能な（例えば、調理方法において使用する調理器具をユーザが所持している）レシピやユーザが調理しやすい（例えば、頻繁に利用する調理工程や調理手法又は食材を含む）レシピなどを推薦レシピとして抽出する。これによって、ユーザにとってより適切なレシピを推薦レシピとして提示することができ、またユーザにとってより不適切なレシピが推薦レシピとして提示されてしまうことを防止することができる。
　全ての料理カテゴリに対して図１１の処理を終え、推薦レシピを抽出したレシピ管理サーバ１は、図６のステップＳ２０６によって優先度付与処理を実行し、ステップＳ２０７において提示処理を実行する。
　ステップＳ２０６の優先度付与処理では、推薦レシピに対する優先度付与処理を行う。優先度は、優先度を高くすべき推薦カテゴリを決定すると共に、高い優先度を付与された推薦カテゴリに属する推薦レシピを高くしてもよい。また、何れの料理カテゴリに属するかは考慮せずに推薦レシピ毎に優先度を付与してもよい。
　この場合、例えば、ユーザの好みの食材を含むレシピやユーザの好まない食材を含まないレシピやユーザが調理可能なレシピやユーザが調理しやすいレシピなどの優先度を高くすることが考えられる。また、ユーザに提示することが不適切なレシピの優先度を低くしてもよい。更に、ユーザが今まで利用したことのないレシピの優先度を高くしてもよい。
　ステップＳ２０７の提示処理では、レシピ管理サーバ１からユーザ端末３に向けて優先度が付与された推薦レシピの情報が送信される。例えば、優先度順に推薦レシピの情報が配置されたウェブページを表示するためのＨＴＭＬデータが送信される。
［４－４．バッチ処理の第２例］
　バッチ処理の第２例について、図１２及び図１３を参照して説明する。
　バッチ処理の第２例では、算出した提示時期を調整する処理を実行する。
　先ず、レシピ管理サーバ１は図１２に示すステップＳ４０１乃至Ｓ４０４を実行することにより、情報提供元ユーザの食事情報を取得し、特定した料理カテゴリ毎の利用周期から提示時期を算出する処理を実行する。
　ステップＳ４０１乃至Ｓ４０４の各処理については、同符号を付して図８で説明した各処理と同様の処理であり、詳述は省く。
　提示時期を算出したレシピ管理サーバ１は、続くステップＳ４０５において、提示時期を調整する処理を実行する。
　提示時期調整処理については、いくつかの例が考えられる。先ずは一つ目の例について、図１３を参照して説明する。
　先ず、レシピ管理サーバ１はステップＳ７０１において、提示時期算出処理（ステップＳ４０４）の対象となった料理カテゴリのうちの一つを選択する。即ち、提示時期を算出した料理カテゴリを一つ選択する。
　続いて、レシピ管理サーバ１はステップＳ７０２において、上位カテゴリが共通の他料理のカテゴリの食事情報（利用履歴）を食事情報ＤＢ５３から取得する。
　具体的に説明すると、例えば、料理カテゴリ「麺類」の下位カテゴリには「ラーメン」、「パスタ」、「うどん」、「そば」などの料理カテゴリが属している。ステップＳ７０１において料理カテゴリ「うどん」が選択された場合、上位カテゴリが共通の他料理カテゴリは「ラーメン」、「パスタ」、「そば」となる。従って、ステップＳ７０２の処理は、「ラーメン」、「パスタ」、「そば」の料理カテゴリについての利用履歴を取得する処理となる。
　尚、ステップＳ７０２で取得する利用履歴の情報は、バッチ処理のステップＳ４０１で情報提供元とされたユーザに関するものである。例えば、情報提供元ユーザが複数人である場合は、利用履歴の取得も当該複数人に対して行う。
　続いて、レシピ管理サーバ１はステップＳ７０３において、他料理カテゴリ（ここでの一例としては「ラーメン」、「パスタ」、「そば」の料理カテゴリ）毎の最終利用時期について、直近の所定期間（所定時間でもよい）内であるか否かを判定する。即ち、直近の所定期間内に他料理カテゴリに属する料理の飲食を行ったか否かを判定する。所定期間としては、例えば３日などであり、ユーザに対して似たようなレシピや料理カテゴリを推薦することを回避する期間とされる。
　尚、ステップＳ７０３の判定処理では、他料理カテゴリの中に一つでも直近の所定期間内に最終利用時期が位置している料理カテゴリがある場合には、最終利用時期が直近の所定期間内であると判定する。
　他料理カテゴリの最終利用時期が直近の所定期間内であると判定した場合、レシピ管理サーバ１はステップＳ７０４において提示時期を調整する処理を実行する。即ち、提示時期を後ろ倒しする。具体的には、例えば、利用周期が１週間である料理カテゴリ「うどん」の提示時期が到来したため、「うどん」を推薦カテゴリとしてユーザに提示したいが、料理カテゴリ「そば」の利用が昨日であったため、料理カテゴリ「うどん」の提示時期を本日から数日分後ろに移動させる。このときの移動量は、料理カテゴリ「そば」の最終利用時期（昨日）から料理カテゴリ「うどん」の利用周期である１週間の間が空くように（即ち昨日から７日後となるように）設定してもよいし、料理カテゴリ「うどん」自体は１週間利用していないことから、利用周期の半分程度（即ち３，４日）後ろ倒しとなるように設定してもよい。
　他料理カテゴリ（換言すれば類似する料理カテゴリ）の最終利用時期に応じて提示時期を調整することにより、仮に提示したとしてもユーザによって選択される可能性が低いと推定される推薦情報の送信を制御し、相対的に優先度の低い推薦情報を送信することによって生じる処理負担の増加を抑制することができる。
　ステップＳ７０４の処理を実行した後、或いは、ステップＳ７０３において他料理カテゴリの最終利用時期が直近の所定期間内ではないと判定した後、レシピ管理サーバ１はステップＳ７０５において、対象の料理カテゴリ（即ち提示時期を算出した料理カテゴリ）の全てに対して上述の処理を適用したか否かを判定する。
　対象の料理カテゴリのうち未処理の料理カテゴリがある場合、レシピ管理サーバ１は再びステップＳ７０１の処理を実行する。
　対象の料理カテゴリのうち未処理の料理カテゴリがない場合、レシピ管理サーバ１は図１３に示す一連の処理を終了することで、図１２に示すバッチ処理を終了する。
　尚、上位カテゴリが共通の他の料理カテゴリの最終利用時期を取得する代わりに、上位カテゴリの最終利用時期を取得してもよい。下位カテゴリが利用された場合、下位カテゴリの最終利用時期が更新されると共に上位カテゴリの最終利用時期も更新されるためである。
　次に、提示時期調整処理の二つ目の例について、図１４を参照して説明する。
　二つ目の例は、ユーザが飲食した料理の属性を考慮した提示時期の調整である。
　先ず、レシピ管理サーバ１はステップＳ８０１において、提示時期算出処理（ステップＳ４０４）の対象となった料理カテゴリのうちの一つを選択する。この処理は、図１３のステップＳ７０１の処理と同様の処理である。
　続いて、レシピ管理サーバ１はステップＳ８０２において、情報提供元ユーザ（食事情報の取得対象となるユーザ）の所定期間の食事情報を取得する。対象期間は、ステップＳ８０１で選択した料理カテゴリの利用周期によって決めてもよい。例えば、利用周期が１週間であれば、直近の１週間の食事情報（利用履歴）を取得する。
　次に、レシピ管理サーバ１はステップＳ８０３において、食事情報に基づいて所定期間内に飲食されたと推定される料理の属性情報を取得する。属性情報とは、例えば、味の種類などであり、「味噌味」や「カレー味」などである。
　そして、レシピ管理サーバ１はステップＳ８０４において、選択した料理カテゴリと共通の属性情報を持つ食事情報（利用履歴）があるかどうかを判定する。
　具体的には、ステップＳ８０１において料理カテゴリ「カレー」が選択され、ステップＳ８０２において取得された食事情報によってユーザが所定期間内に「カレーうどん」を飲食したと推定される場合、ステップＳ８０４の判定処理では、共通の属性情報（カレー味）を持つ食事情報ありと判定する。
　ステップＳ８０４において、共通の属性情報を持つ食事情報ありと判定した場合（例えば料理カテゴリは異なるが似たような味の料理を直近の所定期間内に飲食していた場合）、レシピ管理サーバ１はステップＳ８０５において、提示時期を調整する処理を実行する。具体的には、共通の属性情報を持つ食事情報ありと判定された料理カテゴリの提示時期を長くなる（遅くなる）ように調整する。調整する処理に関しては、図１２のステップＳ７０４と同様の処理であり、ステップＳ８０１で選択された料理カテゴリの提示時期（この例においては、「カレー」の利用周期）に応じて調整してもよい。
　ステップＳ８０５の処理を実行した後、或いは、ステップＳ８０４において共通の属性情報を持つ食事情報なしと判定した後、レシピ管理サーバ１はステップＳ８０６において、対象の料理カテゴリ（即ち提示時期を算出した料理カテゴリ）の全てに対して上述の処理を適用したか否かを判定する。
　対象の料理カテゴリのうち未処理の料理カテゴリがある場合、レシピ管理サーバ１は再びステップＳ８０１の処理を実行する。
　対象の料理カテゴリのうち未処理の料理カテゴリがない場合、レシピ管理サーバ１は図１４に示す一連の処理を終了することで、図１２に示すバッチ処理を終了する。
［４－５．バッチ処理の第３例］
　バッチ処理の第３例について、図１２及び図１５を参照して説明する。
　バッチ処理の第３例では、過去の食事情報だけではなく未来の食事情報も加味して推薦情報の提示時期を調整する。
　レシピ管理サーバ１はステップＳ４０１を実行することによって、情報提供元ユーザを特定した後、ステップＳ４０２において食事情報を取得する処理を実行する。更にレシピ管理サーバ１は、ステップＳ４０３で利用周期を特定し、ステップＳ４０４で提示時期を算出する。提示時期は、全ての料理カテゴリについて算出してもよいし、一部の料理カテゴリについて算出してもよい。
　次にレシピ管理サーバ１が実行するステップＳ４０５の提示時期調整処理の流れは、先のバッチ処理の第２例で説明した流れ（図１３のフローチャート）と同じであるが、処理内容は一部異なる。
　バッチ処理の第３例における提示時期調整処理の例について、図１５を参照して説明する。
　先ず、レシピ管理サーバ１は図１５のステップＳ７０１において、提示時期算出の対象となった料理カテゴリのうちの一つを選択し、続くステップＳ７０６において上位カテゴリが共通の他料理カテゴリ（即ち類似の料理カテゴリ）の食事情報を取得する。
　このとき、他料理カテゴリについての食事情報は、過去の食事情報（即ち利用履歴）だけでなく未来の食事情報も取得する。未来の食事情報は、ユーザが将来飲食する予定の食事の情報であり、前述したように給食の献立表や社員食堂の献立表や行きつけの定食屋の日替わり定食の情報などである。他にもユーザ自身によって入力された食事の予定（例えば外食の予定など）であってもよい。
　そして、レシピ管理サーバ１はステップＳ７０７において、過去の最終利用時期及び未来の利用時期が直近の所定期間内であるか否かを判定する。換言すれば、直近の所定期間内に最終利用時期が含まれているか、或いは、未来の利用時期が含まれているかを確認する。
　例えば、所定期間が１週間とされ、ステップＳ７０１で選択された料理カテゴリの最終利用時期が３日前であったり、未来の利用時期が３日後であったりする場合には、利用時期が直近の所定期間内であると判定する。
　利用時期が直近の所定期間内であると判定した場合、レシピ管理サーバ１はステップＳ７０４において提示時期の調整を行う。この処理は、先の図１３で述べたように、利用周期の分だけ期間が空くように提示時期を後ろ倒しすることで調整してもよい。
　また、他にも、提示時期を前倒しすることによって調整してもよい。例えば、料理カテゴリ「うどん」の利用周期が１週間であり、最終利用時期が５日前であった場合、提示時期は２日後とすることが考えられる。しかし、未来の食事情報では、５日後の給食で「うどん」が出されることが分かっている場合、２日後に料理カテゴリ「うどん」を提示してしまうと、更に３日後に「うどん」を飲食することとなり、間隔が短くなってしまう。
　そこで、最終利用時期（５日前）と次回の利用時期（５日後）の中間時期（本日）を提示時期としてもよい。これにより、料理カテゴリの利用間隔に大きな偏りが生じることを防止することができる。
　また、最終利用時期と次回の利用時期の間隔が利用周期よりも短い場合、或いは利用周期よりも余り長くない場合には、提示時期を最終利用時期と次回の利用時期の間に設けることを止めてもよい。
　ステップＳ７０４の処理を実行した後、或いは、ステップＳ７０７において利用時期が直近の所定期間内でないと判定した後、レシピ管理サーバ１はステップＳ７０５において、対象の料理カテゴリ（即ち提示時期を算出した料理カテゴリ）の全てに対して上述の処理を適用したか否かを判定する。
　対象の料理カテゴリのうち未処理の料理カテゴリがある場合、レシピ管理サーバ１は再びステップＳ７０１の処理を実行する。
　対象の料理カテゴリのうち未処理の料理カテゴリがない場合、レシピ管理サーバ１は図１３に示す一連の処理を終了することで、図１２に示すバッチ処理を終了する。
　尚、未来の利用時期も考慮した提示時期調整処理では、図１４のように、取得した過去及び未来の食事情報から所定期間内に共通の属性情報を持つ料理を飲食したか否か（するか否か）に応じて提示時期を調整してもよい。
［４－６．バッチ処理の第４例］
　バッチ処理の第４例について、図８，図１６及び図１７を参照して説明する。
　バッチ処理の第４例では、利用周期を算出するための食事情報の取得期間が前述とは異なる。
　具体的に、レシピ管理サーバ１は、先ず図８のステップＳ４０１において情報提供元ユーザを特定し、ステップＳ４０２において食事情報を取得する。
　食事情報取得処理は、図９と処理内容が異なる。図１６を参照して説明する。
　食事情報取得処理では、レシピ管理サーバ１はステップＳ５０２において、取得起算時点を算出する処理を実行する。取得起算時点は、前述のように、食事情報の取得対象となる期間の起点となる時間情報である。本例では、情報提供元ユーザに関する各料理カテゴリの利用周期に基づいて取得起算時点を算出する。即ち、これまでのバッチ処理において利用周期が算出済みである場合に、当該算出済みの利用周期から取得起算時点を算出する。
　例えば、料理カテゴリＡ，Ｂ，Ｃがあり、それぞれ利用周期が３日、５日、２１日であった場合、取得起算時点は料理カテゴリＣの利用周期が再算出可能と思われる２１日以前の時間とすることが望ましい。例えば、利用周期の倍の期間となる４２日間の食事情報を取得すれば、その中に料理カテゴリＣの利用履歴が二つ以上存在する可能性が高くなる。
　また、三つ以上の食事情報（利用履歴）から平均的な利用周期を算出する場合には、例えば、２１日の３倍である６３日よりも前の日時（例えば７０日前）を取得起算時点とすることが考えられる。７０日分の食事情報を取得すれば、料理カテゴリＡ，Ｂに関しては十分な情報が取得できる可能性が高く、更に料理カテゴリＣに関しても三つの食事情報が取得できる可能性が高い。
　取得起算時点を算出したレシピ管理サーバ１は、続くステップＳ５０３において、取得起算時点から現在までの食事情報を取得する処理を実行する。
　食事情報取得処理を終えたレシピ管理サーバ１は、図８のステップＳ４０３の利用周期特定処理を実行する。
　利用周期特定処理については、図１７を参照して説明する。
　先ず、レシピ管理サーバ１はステップＳ６０１において、一つの料理カテゴリを選択し、ステップＳ６０２において、選択された料理カテゴリに常用食事情報が含まれているか（所属しているか）を確認する。
　続いて、レシピ管理サーバ１はステップＳ６０３において選択された料理カテゴリの最終利用時期を取得し、ステップＳ６０４において更にもう一つ前の利用時期（利用日時）を取得する。
　ステップＳ６０１乃至Ｓ６０４の各処理は前述と同じであり、詳述は省く。
　最終利用時期及び一つ前の利用時期の二つの情報を取得したレシピ管理サーバ１は、少なくとも当該二つの情報が取得できたか否かを判定する処理をステップＳ６０７において実行する。
　二つの情報を取得できなかった場合、利用周期の算出ができない。従って、そのような場合には、レシピ管理サーバ１はステップＳ６０８において食事情報を追加で取得する処理を実行する。
　尚、最終利用時期及び一つ前の利用時期の二つの情報が取得できるまでステップＳ６０４，Ｓ６０７，Ｓ６０８が繰り返されるが、余りにも古い食事情報まで遡って取得したにも関わらず当該料理カテゴリの利用周期を算出するための情報が取得できなかった場合には、ステップＳ６０５の処理へと移行してもよい。例えば、１年前の情報に基づいて利用周期を算出しても、定期的に当該料理カテゴリを利用している可能性は低く、ユーザにとって有意義な推薦情報を提供できる可能性が低くなるためである。
　利用周期を算出するための情報が取得できたレシピ管理サーバ１は、ステップＳ６０５で利用時期の差分時間から利用周期を算出する。
　ステップＳ６０５を実行した後、又はステップＳ６０２において常用食事情報が含まれていると判定した後、レシピ管理サーバ１はステップＳ６０６において、Ｓ６０１乃至Ｓ６０５の各処理を実行していない料理カテゴリがあるかどうかを判定する。
　ステップＳ６０１乃至Ｓ６０５の各処理を実行していない料理カテゴリがあると判定した場合、レシピ管理サーバ１はステップＳ６０１の処理を再度実行する。
　一方、ステップＳ６０１乃至Ｓ６０５の各処理を実行していない料理カテゴリがないと判定した場合、レシピ管理サーバ１は図１７に示す一連の処理を終了する。
　尚、三つ以上の食事情報（利用履歴）から平均的な利用周期を算出する場合には、ステップＳ６０３及びＳ６０４において、必要な数の食事情報を取得する処理を行う。更に、ステップＳ６０７の処理では必要な数の食事情報を取得できたか否かを判定する。
　また、必要な数の食事情報を取得できた場合であっても、利用時期の差分時間から利用周期を算出する際に、利用周期のばらつきが大きい場合には、ステップＳ６０８の処理を実行してもよい。例えば、カテゴリＡの利用履歴が８０日前、７５日前、２１日前、２０日前であった場合、利用周期は三つの差分時間である５日、４６日、１日から算出することになるが、ばらつきが大きいため、適切な利用周期が推定できない。そのため、ステップＳ６０５で利用周期の算出を試みた後にステップＳ６０８で食事情報を追加取得し、再度ステップＳ６０５で利用周期の算出を行うことが考えられる。この場合には、追加で取得した食事情報に基づいて、料理カテゴリＡの利用周期を４６日付近に設定するのか、５日付近に設定するのか、或いは例えば平均日数など他の期間を利用周期として設定するのかを判定する。
　尚、特定の料理カテゴリに関する所定数の食事情報を食事情報ＤＢ５３から取得可能なようにＤＢが構成されている場合には、ステップＳ６０３，Ｓ６０４，Ｓ６０７，Ｓ６０８の代わりに所定数の食事情報を食事情報ＤＢ５３から取得する処理を実行すればよい。
　図１７に示す利用周期特定処理を終了したレシピ管理サーバ１は、図８のステップＳ４０４の利用周期から提示時期を算出する処理を実行する。この処理の詳細は先に述べたとおりであり、詳述を省く。
＜５．変形例＞

　各処理における変形例について、いくつかの例を説明する。

［５－１．情報提供元ユーザ特定処理の変形例１］
　前述した情報提供元ユーザ特定処理では、対象ユーザと情報提供元ユーザが同じ場合（即ち自身の食事情報に基づく推薦情報の提示を受けたい場合）を説明した。また、他にも、対象ユーザが指定したユーザを情報提供元ユーザとする場合（即ちユーザＡが配偶者であるユーザＢの食事情報に基づいて推薦情報の提示を受けたい場合）を説明した。
　それに対して、情報提供元ユーザ特定処理の変形例１では、ユーザＡが所属するグループのメンバー全員を情報提供元ユーザとする場合を説明する。グループとは、例えばユーザＡ及びその家族（ユーザＢ，Ｃ，Ｄ）が所属する家族グループなどである。換言すれば、ユーザＡと一緒に食事する可能性の高いユーザを集めたグループである。
　ユーザＡが他のユーザＢ，Ｃ，Ｄを指定することによってユーザＡ，Ｂ，Ｃ，Ｄが情報提供元ユーザとして特定される。また、ユーザの住所や投稿情報などに基づいて推定されたユーザＡの所属するグループの各メンバーを情報提供元ユーザとして特定するように構成してもよい。
　これにより、ユーザＡ，Ｂ，Ｃ，Ｄ全員の食事情報を考慮した推薦情報（料理カテゴリやレシピ）が提示されるため、二日連続同じ料理を食すことになるユーザが出てしまうことを防止することが可能となる。
［５－２．情報提供元ユーザ特定処理の変形例２］
　情報提供元ユーザ特定処理の変形例２では、ユーザＡと関連する関連ユーザ（例えば前述のグループにおけるユーザＢ，Ｃ，Ｄ）の中で、食事情報が充実しているユーザを情報提供元ユーザとして特定する。食事情報が充実しているユーザとは、グループに所属する他のユーザに対して食事情報に含まれる情報の量が相対的に多いユーザや、グループに所属する他のユーザに対して食事情報に含まれる料理カテゴリの種類が相対的に多いユーザなどである。
　ここで、ユーザＡの関連ユーザについての情報は、レシピ管理サーバ１が管理するＤＢに記憶されている。即ち、何れのユーザがユーザＡと関連しているのかを示す情報や、関連ユーザの食事情報などの情報が各ＤＢに記憶されている。
　具体的に、図１８を参照して説明する。
　レシピ管理サーバ１は、ステップＳ９０１において、対象ユーザの関連ユーザの情報を取得する。即ち、対象ユーザであるユーザＡの関連ユーザはどのユーザであるのかを確認する。
　続いて、レシピ管理サーバ１はステップＳ９０２において、対象ユーザ及び関連ユーザに関する食事情報のレコード数を食事情報ＤＢ５３から取得する。レコード数とは、食事情報ＤＢ５３に記憶されている情報の数であり、例えば、図５に示す一覧の中で１行を構成する各情報の組が１レコードとされる。即ち図５では、ユーザＩＤ＝Ｕ０００１とされたユーザの食事情報が少なくとも６レコード記憶されていることが示されている。
　次に、レシピ管理サーバ１はステップＳ９０３において、対象ユーザ及び関連ユーザのうちレコード数が相対的に多いユーザを情報提供元ユーザとして設定する。即ち、バッチ処理におけるステップＳ４０２の食事情報取得処理（図８や図１２など）では、レコード数が相対的に多いユーザの食事情報のみが取得される。
　尚、食事情報に含まれる料理カテゴリの種類に応じて情報提供元ユーザを特定する場合には、ステップＳ９０２において対象ユーザ及び関連ユーザに関する食事情報の料理カテゴリ数を取得し、ステップＳ９０３において食事情報の料理カテゴリ数が相対的に多いユーザが情報提供元ユーザとして設定される。
［５－３．提示時期算出処理の変形例］
　提示時期算出処理の変形例について、図１９を参照して説明する。
　先に述べた提示時期算出処理では、一部の料理カテゴリの提示時期を算出する例を述べた。また、そこでは、一部の料理カテゴリの選択例として、一律同じカテゴリレベルの料理カテゴリ（例えばカテゴリレベル２の料理カテゴリ）を選択する例を述べた。
　提示時期算出処理の変形例では、一部の料理カテゴリの選択に際して、利用周期を用いる例を説明する。
　尚、図１９の処理の開始時には、全ての料理カテゴリの利用周期が特定されている状態とされる。但し、常用食事情報を含む料理カテゴリについては、利用周期が特定されていなくても構わない。
　先ず、レシピ管理サーバ１はステップＳ１００１において、料理カテゴリの利用周期を取得する処理を実行する。例えば、カテゴリレベル１の料理カテゴリ（大分類の料理カテゴリ）のうちの一つを選択して、利用周期を取得する。
　続いて、レシピ管理サーバ１はステップＳ１００２において、利用周期が下限閾値以下であるかどうかを判定する。下限閾値は、例えば１週間や１ヶ月とされる。
　利用周期が下限閾値以下であった場合（例えば下限閾値が１週間であるのに対し利用周期が２日であった場合）、レシピ管理サーバ１はステップＳ１００３において、下位カテゴリの利用周期を取得する。そして、レシピ管理サーバ１は再びステップＳ１００２を実行することにより、当該下位カテゴリの利用周期が下限閾値以下であるか否かを判定する。
　例えば、カテゴリレベル１の料理カテゴリとしての料理カテゴリＡがあり、料理カテゴリＡの下位カテゴリとして料理カテゴリＡ１，Ａ２，Ａ３，Ａ４がある場合について、図２０を参照して説明する。
　１週間とされた加減閾値に対して、料理カテゴリＡの利用周期が４日である場合、ステップＳ１００２，Ｓ１００３によって下位カテゴリである料理カテゴリＡ１，Ａ２，Ａ３，Ａ４の利用周期が取得される。料理カテゴリＡ１，Ａ２，Ａ３，Ａ４の利用周期が６日、３０日、３０日、６０日である場合、料理カテゴリＡ１だけは利用周期が下限閾値以下であるため、再びステップＳ１００３の処理が実行されて、更に下位カテゴリＡ１１，Ａ１２の利用周期が取得される。
　料理カテゴリＡ１１，Ａ１２が１５日、１０日である場合、更に下位カテゴリについての処理は行われずに、料理カテゴリＡについての図１９に示す一連の処理が終了する。
　これにより、例えば、料理カテゴリ「カレー（料理カテゴリＡ）」を４日毎に推薦情報として提示するのではなく、下位カテゴリである「和風カレー（料理カテゴリＡ２）」や「欧風カレー（料理カテゴリＡ３）」が適切な周期で推薦情報として提示される。また、「インドカレー（料理カテゴリＡ１）」については、更に細分化された「キーマカレー（料理カテゴリＡ１１）」や「マトンカレー（料理カテゴリＡ１２）」などが推薦情報として提示される。
　このユーザにとっては、カレーは頻繁に飲食する料理カテゴリである。従って、大雑把に「カレー」という料理カテゴリを４日毎に推薦情報として提示するよりも、細分化した料理カテゴリに基づいて推薦情報を提示する方が、このユーザの食事傾向を鑑みても好ましい。
　更に、例えばこのユーザが料理カテゴリ「麺類」（料理カテゴリ「ラーメン」や「パスタ」や「うどん」や「そば」を含む）を月に１度しか飲食しない場合には、カテゴリレベルの異なる料理カテゴリ「麺類」と料理カテゴリ「マトンカレー」が推薦情報として提示される。即ち、料理カテゴリ毎のユーザの嗜好の偏りに応じた適切な推薦情報を提示することができる。
　尚、ここでは、図１９の処理の開始時において料理カテゴリ毎の利用周期が既に特定されている例を説明したがこれに限られることはない。例えば、図１９のＳ１００１の処理において、利用周期の取得の代わりに利用周期の算出を行ってもよい。更に、ステップＳ１００３の処理の後ステップＳ１００１において下位カテゴリの利用周期を算出する処理を実行することにより、必要に応じて下位カテゴリの利用周期が算出される。これにより、利用周期の算出が不要な料理カテゴリについては利用周期の算出が行われないため、レシピ管理サーバ１の処理を減らすことができ、処理負担の軽減を図ることができる。
＜６．まとめ＞

　上記したレシピ管理サーバ１は、情報の提示先となる対象ユーザを特定するユーザ特定部としてのユーザ管理部１ｂと、特定された対象ユーザに関連する情報提供元ユーザに対応する少なくとも利用時期を含む食事情報を取得する食事情報取得部１ｃと、取得した食事情報に含まれる利用時期に基づいて、料理カテゴリ毎の利用周期を特定する利用周期特定部１ｄと、取得した食事情報に含まれる利用時期のうち最も利用時期が遅い最終利用時期と特定された利用周期と、に基づいて算出された料理カテゴリ毎の提示時期に基づいて推薦カテゴリとなる料理カテゴリを特定する推薦カテゴリ特定部１ｇと、推薦カテゴリに基づいて推薦情報を対象ユーザに提示する制御を行う提示制御部１ｉと、を備えている。
　これにより、ユーザの潜在的なニーズを汲み取った情報（推薦カテゴリ）が提示される。即ち、ユーザの嗜好だけでなく周期を考慮した選択パターンを鑑みて推薦カテゴリ情報が提示される。例えば、ユーザがそろそろ食べたくなった料理カテゴリが抽出されて、ユーザに提示される。
　従って、毎日の食事を考える煩わしさを抑制しつつユーザ毎に適した推薦カテゴリを提供することが可能である。
　また、ユーザがレシピ等の検索操作を行わなくても情報を提示することが可能であるため、ユーザにとって負担の少ないサービスを提供することができる。
　そして、ユーザに適した情報を提示することから、ユーザが更なる検索操作等を行う機会を減少させることができるため、情報処理装置（レシピ管理サーバ１やユーザ端末３）の処理負担軽減や通信量の削減を図ることができる。
　また、バッチ処理の第２例やバッチ処理の第３例で説明したように、レシピ管理サーバ１は、特定された推薦カテゴリに関連する料理カテゴリの利用に基づいて特定された推薦カテゴリの提示時期を調整する提示時期調整部１ｆを更に備えてもよい。
　これにより、例えば、類似する料理カテゴリが所定期間内に利用された場合を考慮した情報提示が行われる。
　即ち、例えば、「そば」の料理カテゴリが利用（レシピ利用や外食利用など）されてから所定期間内に同じ麺類である「うどん」の料理カテゴリが提示されることが防止される。
　従って、料理カテゴリ毎の利用周期だけでなく、類似した料理カテゴリの利用状況も考慮した最適な情報を提示することができる。
　また、ユーザの先の予定まで含めた推薦カテゴリが特定されて提示される。
　即ち、ユーザが推薦カテゴリに従って食事を摂取した後、短い期間で再度同一カテゴリに属する食事を摂取してしまうことを防止することができる。
　従って、ユーザの過去の食事情報と未来の食事情報の双方を加味した総合的な情報提示を行うことができ、ユーザの利便性の向上を図ることができる。
　更に、提示時期算出処理の変形例で説明したように、料理カテゴリは階層構造を有し、推薦カテゴリ特定部１ｇは、特定された利用周期が所定の下限閾値以下または未満である場合に利用周期が下限閾値以下または未満とされた料理カテゴリの下位カテゴリについての利用周期及び提示時期を取得して推薦カテゴリの特定を行ってもよい。
　これにより、全ての料理カテゴリについての利用周期及び提示時期を取得する必要が無い。
　従って、レシピ管理サーバ１の処理負担の軽減を図ることができる。
　特に、特定された利用周期が所定の下限閾値以下または未満である場合に、下位カテゴリについての提示時期の算出を行う場合には、処理負担の更なる軽減が図られる。
　更にまた、提示時期算出処理の変形例で説明したように、推薦カテゴリは階層構造を有し、提示時期算出部１ｅは、料理カテゴリのうち利用周期が下限閾値以上またはより大きいとされた料理カテゴリの提示時期について算出し、推薦カテゴリ特定部１ｇは、特定された利用周期が所定の下限閾値以上またはより大きいとされた料理カテゴリの中から推薦カテゴリの特定を行ってもよい。
　これにより、利用周期が短すぎる料理カテゴリに対して提示時期が算出されることが無くなる。例えば、その下位となる料理カテゴリに対して提示時期が算出される。延いては、頻繁に同じ料理カテゴリが推薦カテゴリとして提示されることが無くなる。
　従って、ユーザにとって飽きのこない有意義な情報を提供することができる。
　また、提示時期の算出対象とされる料理カテゴリの利用周期のばらつきがある程度緩和される。即ち、一週間などの所定の期間における献立スケジュールなどを立てる場合に、算出された提示時期に基づいて立てることが容易となる。
　そして、第１の実施の形態で説明したように、提示制御部１ｉは、推薦カテゴリ毎に優先度を付与し、該優先度に応じて提示を行う。
　これにより、ユーザにとって有意義な情報ほど優先度を高くすることが可能となる。
　例えば、提示時期を大幅に経過してしまった料理カテゴリほど優先度を高くする
　従って、ユーザにとって利便性の高いサービスを提供することが可能となる。
　また、バッチ処理の第４例で説明したように、食事情報取得部１ｃは、利用周期に基づいて食事情報の取得起算時点を決定し、該取得起算時点から現在までの食事情報を取得する。
　これにより、一度算出した利用周期に基づいて次回以降の各処理のための食事情報の取得の範囲（期間）が決定される。
　即ち、不必要に長い期間の食事情報の取得を行わないことも可能となる。
　従って、処理の対象となる食事情報の情報量が抑制されるため、情報処理装置の処理負担の軽減を図ることができる。
　更にまた、情報提供元ユーザ特定処理の変形例２で説明したように、対象ユーザと関連する関連ユーザが登録されている場合において、食事情報取得部１ｃは、対象ユーザと関連ユーザのうち食事情報が充実しているユーザの食事情報を取得するように構成されていてもよい。
　これにより、例えば、最も充実した情報を元に利用周期や提示時期が算出され、それによって特定された推薦カテゴリが提示される。
　従って、ユーザに提示される推薦カテゴリは、充実した情報に基づく有意義な情報となり易いため、利便性の高いサービスを提供することができる。
　尚、各処理例において説明した処理内容は、他の処理例において説明した処理によって代替することや他の処理例において説明した処理を追加実施することが可能である。即ち、その処理例において記載した内容に縛られず、他の処理例に記載された内容に基づいて処理が実行されてもよい。
　一例として、バッチ処理の第３例において未来の食事情報に基づく調整を行う例を示し、バッチ処理の第４例において過去の所定期間内の食事情報を取得する際の所定期間の定め方の例を示したが、未来の食事情報の取得期間をバッチ処理の第４例と同様に利用周期に基づいて決定してもよい。
　上記に示した、所定期間や所定時間の長さは１年間や１ヶ月間や１週間などの長さであってもよいし、１時間や数時間などの長さであってもよい。
＜７．プログラム及び記憶媒体＞

　以上、本発明の情報処理装置の実施の形態としてのレシピ管理サーバ１を説明してきたが、実施の形態のプログラムは、レシピ管理サーバ１における各処理を情報処理装置（ＣＰＵ等）に実行させるプログラムである。
　実施の形態のプログラムは、情報の提示先となる対象ユーザを特定するユーザ特定機能を情報処理装置に実行させる。
　また、前記特定された対象ユーザに関連する情報提供元ユーザに対応する少なくとも利用時期を含む食事情報を取得する食事情報取得機能を情報処理装置に実行させる。
　更に、前記取得した食事情報に含まれる利用時期に基づいて、料理カテゴリ毎の利用周期を特定する利用周期特定機能を情報処理装置に実行させる。
　更にまた、前記取得した食事情報に含まれる利用時期のうち最も利用時期が遅い最終利用時期と前記特定された利用周期と、に基づいて算出された料理カテゴリ毎の提示時期に基づいて推薦カテゴリとなる料理カテゴリを特定する推薦カテゴリ特定機能を情報処理装置に実行させる。
　そして、前記推薦カテゴリに基づいて推薦情報を前記対象ユーザに提示する制御を行う提示制御機能を情報処理装置に実行させる。
　即ちこのプログラムは、レシピ管理サーバ１に対して図６のステップＳ２０１乃至Ｓ２０７の各処理、図７乃至図１９の各処理を実行させるプログラムである。
　このようなプログラムにより、上述したレシピ管理サーバ１としての情報処理装置を実現できる。
　そしてこのようなプログラムはコンピュータ装置などの機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭなどに予め記録しておくことができる。或いはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的或いは永続的に格納（記録）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
　また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータなどにインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。
　１　レシピ管理サーバ、１ａ　レシピ管理部、１ｂ　ユーザ管理部、１ｃ　食事情報取得部、１ｄ　利用周期特定部、１ｅ　提示時期算出部、１ｆ　提示時期調整部、１ｇ　推薦カテゴリ特定部、１ｈ　推薦レシピ抽出部、１ｉ　提示制御部、２　通信ネットワーク、３　ユーザ端末、５０　ユーザＤＢ、５１　レシピＤＢ、５２　検索ＤＢ、５３　食事情報ＤＢ、５４　ウェブページＤＢ

Claims (9)

  1. 　情報の提示先となる対象ユーザを特定するユーザ特定部と、
    　前記特定された対象ユーザに関連する情報提供元ユーザに対応する少なくとも利用時期を含む食事情報を取得する食事情報取得部と、
    　前記取得した食事情報に含まれる利用時期に基づいて、料理カテゴリ毎の利用周期を特定する利用周期特定部と、
    　前記取得した食事情報に含まれる利用時期のうち最も利用時期が遅い最終利用時期と前記特定された利用周期と、に基づいて算出された料理カテゴリ毎の提示時期に基づいて推薦カテゴリとなる料理カテゴリを特定する推薦カテゴリ特定部と、
    　前記推薦カテゴリに基づいて推薦情報を前記対象ユーザに提示する制御を行う提示制御部と、を備えた
    　情報処理装置。
  2. 　前記特定された推薦カテゴリに関連する料理カテゴリの利用に基づいて前記特定された推薦カテゴリの前記提示時期を調整する提示時期調整部を更に備えた
    　請求項１に記載の情報処理装置。
  3. 　前記料理カテゴリは階層構造を有し、
    　前記推薦カテゴリ特定部は、前記特定された利用周期が所定の下限閾値以下または未満である場合に利用周期が前記下限閾値以下または未満とされた料理カテゴリの下位カテゴリについての前記利用周期及び提示時期を取得して前記推薦カテゴリの特定を行う
    　請求項１または請求項２に記載の情報処理装置。
  4. 　前記推薦カテゴリは階層構造を有し、
    　前記提示時期は、前記料理カテゴリのうち前記利用周期が下限閾値以上またはより大きいとされた料理カテゴリについて算出され、
    　前記推薦カテゴリ特定部は、前記特定された利用周期が所定の下限閾値以上またはより大きいとされた料理カテゴリの中から前記推薦カテゴリの特定を行う
    　請求項１乃至請求項３の何れかに記載の情報処理装置。
  5. 　前記提示制御部は、前記推薦カテゴリ毎に優先度を付与し、該優先度に応じて前記提示を行う
    　請求項１乃至請求項４の何れかに記載の情報処理装置。
  6. 　前記食事情報取得部は、前記利用周期に基づいて前記食事情報の取得起算時点を決定し、該取得起算時点から現在までの食事情報を取得する
    　請求項１乃至請求項５の何れかに記載の情報処理装置。
  7. 　前記対象ユーザと関連する関連ユーザが登録されている場合において、
    　前記食事情報取得部は、前記対象ユーザと前記関連ユーザのうち前記食事情報が充実しているユーザの食事情報を取得する
    　請求項１乃至請求項６の何れかに記載の情報処理装置。
  8. 　情報の提示先となる対象ユーザを特定するユーザ特定ステップと、
    　前記特定された対象ユーザに関連する情報提供元ユーザに対応する少なくとも利用時期を含む食事情報を取得する食事情報取得ステップと、
    　前記取得した食事情報に含まれる利用時期に基づいて、料理カテゴリ毎の利用周期を特定する利用周期特定ステップと、
    　前記取得した食事情報に含まれる利用時期のうち最も利用時期が遅い最終利用時期と前記特定された利用周期と、に基づいて算出された料理カテゴリ毎の提示時期に基づいて推薦カテゴリとなる料理カテゴリを特定する推薦カテゴリ特定ステップと、
    　前記推薦カテゴリに基づいて推薦情報を前記対象ユーザに提示する制御を行う提示制御ステップと、を
    　情報処理装置が実行する情報処理方法。
  9. 　情報の提示先となる対象ユーザを特定するユーザ特定機能と、
    　前記特定された対象ユーザに関連する情報提供元ユーザに対応する少なくとも利用時期を含む食事情報を取得する食事情報取得機能と、
    　前記取得した食事情報に含まれる利用時期に基づいて、料理カテゴリ毎の利用周期を特定する利用周期特定機能と、
    　前記取得した食事情報に含まれる利用時期のうち最も利用時期が遅い最終利用時期と前記特定された利用周期と、に基づいて算出された料理カテゴリ毎の提示時期に基づいて推薦カテゴリとなる料理カテゴリを特定する推薦カテゴリ特定機能と、
    　前記推薦カテゴリに基づいて推薦情報を前記対象ユーザに提示する制御を行う提示制御機能と、を
    　情報処理装置に実行させるプログラム。
PCT/JP2016/061395 2016-04-07 2016-04-07 情報処理装置、情報処理方法、プログラム WO2017175355A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2016/061395 WO2017175355A1 (ja) 2016-04-07 2016-04-07 情報処理装置、情報処理方法、プログラム
JP2018510190A JP6641460B2 (ja) 2016-04-07 2016-04-07 情報処理装置、情報処理方法、プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/061395 WO2017175355A1 (ja) 2016-04-07 2016-04-07 情報処理装置、情報処理方法、プログラム

Publications (1)

Publication Number Publication Date
WO2017175355A1 true WO2017175355A1 (ja) 2017-10-12

Family

ID=60000935

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/061395 WO2017175355A1 (ja) 2016-04-07 2016-04-07 情報処理装置、情報処理方法、プログラム

Country Status (2)

Country Link
JP (1) JP6641460B2 (ja)
WO (1) WO2017175355A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019149035A (ja) * 2018-02-27 2019-09-05 ヤフー株式会社 提供装置、提供方法および提供プログラム
WO2019188102A1 (ja) * 2018-03-27 2019-10-03 カルチュア・コンビニエンス・クラブ株式会社 顧客の属性情報に基づきレコメンドを行う装置、方法、およびプログラム
JP2020057346A (ja) * 2019-04-04 2020-04-09 クックパッド株式会社 レシピ提案装置、レシピ提案方法、および、レシピ提案プログラム
CN112954066A (zh) * 2021-02-26 2021-06-11 北京三快在线科技有限公司 信息推送方法、装置、电子设备及可读存储介质
JP2021103340A (ja) * 2018-03-27 2021-07-15 カルチュア・コンビニエンス・クラブ株式会社 顧客の属性情報に基づきレコメンドを行う装置、方法、およびプログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09282139A (ja) * 1996-04-09 1997-10-31 Sony Corp 情報提供装置
WO2011122575A1 (ja) * 2010-03-30 2011-10-06 楽天株式会社 商品推奨装置、商品推奨方法、プログラム、ならびに記録媒体
JP2015035090A (ja) * 2013-08-08 2015-02-19 シャープ株式会社 献立提案方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09282139A (ja) * 1996-04-09 1997-10-31 Sony Corp 情報提供装置
WO2011122575A1 (ja) * 2010-03-30 2011-10-06 楽天株式会社 商品推奨装置、商品推奨方法、プログラム、ならびに記録媒体
JP2015035090A (ja) * 2013-08-08 2015-02-19 シャープ株式会社 献立提案方法

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019149035A (ja) * 2018-02-27 2019-09-05 ヤフー株式会社 提供装置、提供方法および提供プログラム
WO2019188102A1 (ja) * 2018-03-27 2019-10-03 カルチュア・コンビニエンス・クラブ株式会社 顧客の属性情報に基づきレコメンドを行う装置、方法、およびプログラム
CN111902836A (zh) * 2018-03-27 2020-11-06 文化便利俱乐部株式会社 基于顾客属性信息进行建议的装置、方法、及程序
JP2021103340A (ja) * 2018-03-27 2021-07-15 カルチュア・コンビニエンス・クラブ株式会社 顧客の属性情報に基づきレコメンドを行う装置、方法、およびプログラム
JP7283865B2 (ja) 2018-03-27 2023-05-30 カルチュア・コンビニエンス・クラブ株式会社 顧客の属性情報に基づきレコメンドを行う装置、方法、およびプログラム
JP2020057346A (ja) * 2019-04-04 2020-04-09 クックパッド株式会社 レシピ提案装置、レシピ提案方法、および、レシピ提案プログラム
JP7240936B2 (ja) 2019-04-04 2023-03-16 クックパッド株式会社 サーバ、サーバの制御方法及びプログラム
CN112954066A (zh) * 2021-02-26 2021-06-11 北京三快在线科技有限公司 信息推送方法、装置、电子设备及可读存储介质

Also Published As

Publication number Publication date
JP6641460B2 (ja) 2020-02-05
JPWO2017175355A1 (ja) 2019-01-31

Similar Documents

Publication Publication Date Title
US20190370916A1 (en) Personalized dining experiences via universal electronic food profiles
US20190050477A1 (en) Iterative image search algorithm informed by continuous human-machine input feedback
WO2017175355A1 (ja) 情報処理装置、情報処理方法、プログラム
US9087364B1 (en) System for enhancing the restaurant experience for persons with food sensitivities/preferences
US20140089321A1 (en) Method and system to recommend recipes
JP6856093B2 (ja) 情報処理装置、情報処理方法及びプログラム
CN104200409A (zh) 一种口味选择信息同应用对象的匹配方法
JP5615464B1 (ja) 料理レシピ情報提供装置、料理レシピ情報提供方法、プログラム、及び情報記録媒体
JP6083786B2 (ja) メニュー出力装置、メニュー出力方法、およびプログラム
JP6262923B1 (ja) 情報処理装置、情報処理方法、プログラム
JP6279823B1 (ja) 情報処理装置、情報処理方法、プログラム
JP2023113768A (ja) 情報処理システム、情報処理方法及びプログラム
JP2018010399A (ja) 食品情報提供システム、食品情報提供方法、及び食品情報提供プログラム
JP6488531B2 (ja) メニュー出力装置、メニュー出力方法、およびプログラム
JP6890747B2 (ja) 情報処理装置、情報処理方法、プログラム
JP2020052638A (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
JP2019087147A (ja) 食材配送支援装置、食材配送支援方法、食材配送支援プログラム
JP6681679B2 (ja) 情報処理装置、情報処理方法及びプログラム
TW201643804A (zh) 資訊處理裝置、ｐｏｓ系統、資訊處理方法及記憶有程序之計算機可讀取的記憶介質
JP2020024490A (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
JP6275932B1 (ja) 情報処理装置、情報処理方法、プログラム
JP2014052748A (ja) 情報提供システム及びプログラム
JP2019169097A (ja) 情報処理装置、情報処理方法及びプログラム
Daniels et al. Results of web-scale discovery: Data, discussions, and decisions
JP6807584B1 (ja) 情報提供装置、情報提供方法及び情報提供プログラム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2018510190

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16897912

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16897912

Country of ref document: EP

Kind code of ref document: A1