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

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 (8)

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

Images