特許 6262923 情報処理装置、情報処理方法、プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】6262923

(24)【登録日】2017年12月22日

(45)【発行日】2018年1月17日

(54)【発明の名称】情報処理装置、情報処理方法、プログラム

(51)【国際特許分類】

   G06F 17/30 20060101AFI20180104BHJP

   G06Q 10/00 20120101ALI20180104BHJP

   G06Q 50/22 20180101ALI20180104BHJP

【ＦＩ】

   G06F17/30 210D

   G06Q10/00

   G06Q50/22

【請求項の数】8

【全頁数】41

(21)【出願番号】特願2017-553200(P2017-553200)

(86)(22)【出願日】2016年4月7日

(86)【国際出願番号】JP2016061394

【審査請求日】2017年10月10日

【早期審査対象出願】

(73)【特許権者】

【識別番号】399037405

【氏名又は名称】楽天株式会社

(74)【代理人】

【識別番号】100116942

【弁理士】

【氏名又は名称】岩田 雅信

(74)【代理人】

【識別番号】100167704

【弁理士】

【氏名又は名称】中川 裕人

(72)【発明者】

【氏名】内田 有紀

【審査官】 齊藤 貴孝

(56)【参考文献】

【文献】 特開２００２−０４１６６７（ＪＰ，Ａ）

【文献】 特開２０１０−０６１２７６（ＪＰ，Ａ）

【文献】 特開２０１３−０５８０６１（ＪＰ，Ａ）

【文献】 特開２０１０−２５０７９３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １７／３０

Ｇ０６Ｑ １０／００−９９／００

(57)【特許請求の範囲】

【請求項1】

食材の格納履歴を記憶する記憶装置から少なくとも在庫情報を含む食材の情報を取得する食材情報取得部と、
前記記憶装置に記憶された格納履歴に基づいて判定された食材が追加される周期に応じてレシピ提供回数を特定する提供回数特定部と、
前記取得した食材の情報と前記特定されたレシピ提供回数に基づいて、当該食材の情報に含まれる各食材を、当該レシピ提供回数に応じた数の食材グループに振り分ける食材グループ設定部と、
前記食材グループ毎に、前記振り分けられた食材に基づいてレシピを特定するレシピ特定部と、
前記食材グループ毎に特定されたレシピの提示制御を行う提示制御部と、
を備え、
前記食材グループ設定部は、前記レシピ特定部が各前記食材グループについて特定するレシピの数または料理種別が所定の数量条件を満たすように食材の振り分けを行う
情報処理装置。

【請求項2】

前記食材グループ設定部は、前記取得した食材の情報に含まれる食材毎の汎用性を示す情報を取得し、当該取得した汎用性を示す情報で示される値が相対的に高い食材が異なる食材グループに振り分けられるように食材グループを設定する
請求項１に記載の情報処理装置。

【請求項3】

前記食材グループ設定部は、食材を分量単位で各食材グループに振り分けて食材グループを設定するとともに、設定した各食材グループについて前記数量条件を満たせなくなる場合は、各食材グループに振り分ける食材の分量の再設定を行う
請求項１又は請求項２に記載の情報処理装置。

【請求項4】

各食材グループに対応したレシピを特定した後において、追加可能な食材の情報を取得した場合、
前記食材グループ設定部が食材の再割り当てをおこない、
前記レシピ特定部が前記再割り当ての状態で追加レシピを特定し、
前記提示制御部は、前記追加レシピを追加した状態でのレシピの提示制御を行う
請求項１乃至請求項３のいずれかに記載の情報処理装置。

【請求項5】

各食材グループについて特定されたレシピ数又は各食材グループについて特定されたレシピにおける料理種別の数の偏りについての前記数量条件が、食材グループの数に応じて設定される
請求項１乃至請求項４のいずれかに記載の情報処理装置。

【請求項6】

各食材グループについて特定されたレシピ数又は各食材グループについて特定されたレシピにおける料理種別の数の最小値としての前記数量条件が、食材グループの数に応じて設定される
請求項１乃至請求項４のいずれかに記載の情報処理装置。

【請求項7】

情報処理装置が実行する情報処理方法として、
食材の格納履歴を記憶する記憶装置から少なくとも在庫情報を含む食材の情報を取得する食材情報取得ステップと、
前記記憶装置に記憶された格納履歴に基づいて判定された食材が追加される周期に応じてレシピ提供回数を特定する提供回数特定ステップと、
前記取得した食材の情報と前記特定されたレシピ提供回数に基づいて、当該食材の情報に含まれる各食材を、当該レシピ提供回数に応じた数の食材グループに振り分ける食材グループ設定ステップと、
前記食材グループ毎に、前記振り分けられた食材に基づいてレシピを特定するレシピ特定ステップと、
前記食材グループ毎に特定されたレシピの提示制御を行う提示制御ステップと、
を備え、
前記食材グループ設定ステップでは、前記レシピ特定ステップで各前記食材グループについて特定するレシピの数または料理種別が所定の数量条件を満たすように食材の振り分けを行う
情報処理方法。

【請求項8】

食材の格納履歴を記憶する記憶装置から少なくとも在庫情報を含む食材の情報を取得する食材情報取得手順と、
前記記憶装置に記憶された格納履歴に基づいて判定された食材が追加される周期に応じてレシピ提供回数を特定する提供回数特定手順と、
前記取得した食材の情報と前記特定されたレシピ提供回数に基づいて、当該食材の情報に含まれる各食材を、当該レシピ提供回数に応じた数の食材グループに振り分ける食材グループ設定手順と、
前記食材グループ毎に、前記振り分けられた食材に基づいてレシピを特定するレシピ特定手順と、
前記食材グループ毎に特定されたレシピの提示制御を行う提示制御手順と、
を情報処理装置に実行させるとともに、
前記食材グループ設定手順では、前記レシピ特定手順で各前記食材グループについて特定するレシピの数または料理種別が所定の数量条件を満たすことになる食材の振り分けを情報処理装置に実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は情報処理装置、情報処理方法、プログラムに関し、特にユーザに対するレシピの提示処理についての技術分野に関する。

【先行技術文献】

【特許文献】

【0002】

【特許文献1】特開２００６−２７７４１０号公報

【特許文献2】特開２００３−３０７５３号公報

【背景技術】

【0003】

一般のユーザ（レシピ提供者）の投稿などによって蓄積された料理のレシピを提供するサービスが知られている。
特許文献１には、ユーザが入力した手元にある食材に基づいてレシピで使用する一部の食材を代替食材に置換して作成可能なレシピを提供する技術について記載されている。
特許文献２には、オーダーされたメニューに応じて管理している在庫から食材の引当を行い、食材が不足した場合に当該不足したことを通知したり、代替食材を用いた代替メニューを検索して提供したりする技術について記載されている。

【発明の概要】

【発明が解決しようとする課題】

【0004】

ところで、例えば一般の家庭等におけるレシピ閲覧を求めるユーザ（レシピ利用者）を想定したときに、手元の食材を１回の食事で使いきってしまうと翌日以降の食事に用いる食材が足りなくなったり、ある程度の食材が残っていたとしても調理可能なレシピの種類が著しく限定されてしまったりして、レシピ閲覧を行うユーザに対して選択可能な十分なバリエーションの選択肢を提供することが困難であった。
食材が少なくなっていくにつれ、調理可能なレシピの数が減少するためである。

【0005】

また、例えば週に１回や特売などにあわせてまとめて食材を購入した方がユーザにとって効率的であり、足りなくなった食材を日々補充することはユーザのとって煩雑である。
さらに食材購入に関するユーザのスタイルとして、生活協同組合等による一括購入、食料品まとめ配送サービス、インターネット通販による一括購入、週一回のマーケットでの大量購入などを行う人も増えており、毎日食材の買い物に行くという生活習慣を持たない人も多い。
これらの人にとっては、次の食材購入までのある程度の期間、保存している食材が徐々に少なくなっていくわけであるが、それらの日々にうまく食材を分散して使用でき、かつそれぞれの日々に十分な選択肢のレシピが提供されることが望まれる。

【0006】

特許文献１に記載の技術は「ユーザの入力した食材に基づいてレシピで使用する一部の食材を代替食材に置換して作成可能なレシピを提供する」ものであり、当該提供されたレシピによって使用された食材を除いた、残余の食材によって提供可能なレシピの選択肢が十分であるかは考慮されていない。
特許文献２に記載の技術は「オーダーされたメニューに応じて管理している在庫から食材の引当を行い、食材が不足した場合に代替食材を用いた代替メニューを検索して提供する」ものであり、当該提供されたレシピによって使用された食材を除いた、残余の食材によって提供可能なレシピの選択肢が十分であるかは考慮されていない。

【0007】

そこで本発明では、食材の調達頻度を抑制できるようにしつつ、翌日以降の食材で十分な数量のレシピの選択肢を確保可能であるレシピ提供サービスを実現する。

【課題を解決するための手段】

【0008】

本発明に係る情報処理装置は、食材の格納履歴を記憶する記憶装置から少なくとも在庫情報を含む食材の情報を取得する食材情報取得部と、前記記憶装置に記憶された格納履歴に基づいて判定された食材が追加される周期に応じてレシピ提供回数を特定する提供回数特定部と、前記取得した食材の情報と前記特定されたレシピ提供回数に基づいて、当該食材の情報に含まれる各食材を、当該レシピ提供回数に応じた数の食材グループに振り分ける食材グループ設定部と、前記食材グループ毎に、前記振り分けられた食材に基づいてレシピを特定するレシピ特定部と、前記食材グループ毎に特定されたレシピの提示制御を行う提示制御部とを備える。そして前記食材グループ設定部は、前記レシピ特定部が各前記食材グループについて特定するレシピの数または料理種別が所定の数量条件を満たすように食材の振り分けを行う。
例えばユーザが一週間に一度、食材をまとめて購入することなどを想定する。この購入した食材を、レシピ提供回数（例えば一週間の毎日の夕食用とすると７回）に振り分けて食材グループを設定する。そして食材グループ毎に、その食材グループ内の食材で調理可能なレシピを特定する。そして食材グループ毎、即ち毎日の夕食毎に、いくつかのレシピをユーザ（レシピ利用者）に提示する。
なお格納履歴とは、各食材についての追加量、追加日時、使用量、使用日時などの情報である。

【0009】

上記した情報処理装置においては、前記食材グループ設定部は、前記取得した食材の情報に含まれる食材毎の汎用性を示す情報を取得し、当該取得した汎用性を示す情報で示される値が相対的に高い食材が異なる食材グループに振り分けられるように食材グループを設定することが考えられる。
汎用性が高い食材とは、より多数のレシピで使用される食材である。ある食材グループに汎用性が高い食材ばかり集められると、その食材グループについては対応するレシピ数が多くなるが、他の食材グループでは対応するレシピ数が少なくなってしまうことが想定される。そこで、汎用性が高い食材が或る食材グループに集中しないようにする。

【0010】

上記した情報処理装置においては、前記食材グループ設定部は、食材を分量単位で各食材グループに振り分けて食材グループを設定するとともに、設定した各食材グループについて前記数量条件を満たせなくなる場合は、各食材グループに振り分ける食材の分量の再設定を行うことが考えられる。
１つの食材を必ずしも全て１つの食材グループに振り分ける必要は無い。そこで分量に応じて振り分ける。
そして１つの食材を特定の分量毎に振り分けると、場合によっては対応するレシピ数が極端に減少してしまうこともあるため、数量条件を満たすように振り分ける分量を調整して再設定する。

【0011】

上記した情報処理装置においては、各食材グループに対応したレシピを特定した後において、追加可能な食材の情報を取得した場合、前記食材グループ設定部が食材の再割り当てをおこない、前記レシピ特定部が前記再割り当ての状態で追加レシピを特定し、前記提示制御部は、前記追加レシピを追加した状態でのレシピの提示制御を行うことが考えられる。
例えば１回目の提示は、１回目として１回目用の食材グループとされた食材で調理可能なレシピが提示される。しかし、レシピ利用者としてのユーザがその中でどのレシピを選択して料理を行うかに応じて余剰食材が生ずる。そこで２回目以降の提示の時点では、余剰食材を残りの各食材グループに振り分けた上で、調理可能なレシピを特定し、これを追加レシピとして提示する。
また例えば１週間分の食材の割り当てとレシピの特定を行った後に、食材が追加された場合、以降のレシピ提示としては、追加食材を反映させたレシピも追加提示されるようにする。

【0012】

上記した情報処理装置においては、各食材グループについて特定されたレシピ数又は各食材グループについて特定されたレシピにおける料理種別の数の偏りについての前記数量条件が、食材グループの数に応じて設定されることが考えられる。
つまり各食材グループについて対応するレシピの数や料理種別数が略同程度となることを条件とする。その同程度と判定する範囲は食材グループ数に応じたものとする。

【0013】

上記した情報処理装置においては、各食材グループについて特定されたレシピ数又は各食材グループについて特定されたレシピにおける料理種別の数の最小値としての前記数量条件が、食材グループの数に応じて設定されることが考えられる。
つまり各食材グループについて対応するレシピの数やレシピの料理種別の数が、どの食材グループにも所定の最小値以上となっていることを条件とする。その場合の最小値は食材グループ数に応じたものとする。

【0014】

本発明に係る情報処理方法は、食材の格納履歴を記憶する記憶装置から少なくとも在庫情報を含む食材の情報を取得する食材情報取得ステップと、前記記憶装置に記憶された格納履歴に基づいて判定された食材が追加される周期に応じてレシピ提供回数を特定する提供回数特定ステップと、前記取得した食材の情報と前記特定されたレシピ提供回数に基づいて、当該食材の情報に含まれる各食材を、当該レシピ提供回数に応じた数の食材グループに振り分ける食材グループ設定ステップと、前記食材グループ毎に、前記振り分けられた食材に基づいてレシピを特定するレシピ特定ステップと、前記食材グループ毎に特定されたレシピの提示制御を行う提示制御ステップとを備える。前記食材グループ設定ステップでは、前記レシピ特定ステップで各前記食材グループについて特定するレシピの数または料理種別が所定の数量条件を満たすように食材の振り分けを行う。
この情報処理方法により、情報処理装置によって充実したレシピ提供が可能となる。
本発明に係るプログラムは、上記各ステップに相当する手順を情報処理装置に実行させるプログラムである。これにより上述の情報処理装置の処理を実現する。

【発明の効果】

【0015】

本発明によれば、ユーザの、食材調達頻度を抑制した購入スタイルにあわせて、複数回のレシピ提供の度に十分な選択肢を有する充実したレシピ提供を行うことができる。

【図面の簡単な説明】

【0016】

【図1】本発明の実施の形態のシステム構成の説明図である。

【図2】実施の形態のレシピ管理サーバの機能構成の説明図である。

【図3】実施の形態の情報処理装置のブロック図である。

【図4】実施の形態のレシピデータベースの説明図である。

【図5】実施の形態の格納履歴データベース及び食材データベースの説明図である。

【図6】実施の形態の提示設定データベースの説明図である。

【図7】実施の形態のレシピ提供に関する処理のフローチャートである。

【図8】実施の形態において提示するレシピの例の説明図である。

【図9】実施の形態のレシピ提示例の説明図である。

【図10】実施の形態の提示設定のためのバッチ処理のフローチャートである。

【図11】第１の実施の形態の提示設定処理のフローチャートである。

【図12】実施の形態の食材の分配単位設定の説明図である。

【図13】実施の形態の食材グループへの食材振り分けの説明図である。

【図14】実施の形態の食材振り分け処理のフローチャートである。

【図15】実施の形態の数量条件チェック処理のフローチャートである。

【図16】実施の形態の数量条件チェック処理のフローチャートである。

【図17】実施の形態のレシピ管理サーバの処理のフローチャートである。

【図18】第２の実施の形態の提示設定処理のフローチャートである。

【図19】第３の実施の形態の提示設定のためのバッチ処理のフローチャートである。

【図20】第３の実施の形態の再提示設定処理のフローチャートである。

【発明を実施するための形態】

【0017】

以下、実施の形態を次の順序で説明する。
＜１．全体構成＞
＜２．ハードウェア構成＞
＜３．ＤＢ＞
＜４．端末とサーバ間の処理の流れ＞
＜５．第１の実施の形態＞
＜６．第２の実施の形態＞
＜７．第３の実施の形態＞
＜８．まとめ＞
＜９．プログラム及び記憶媒体＞

【0018】

＜１．全体構成＞
実施の形態におけるシステム全体構成を図１により説明する。実施の形態のシステムはユーザに対して料理レシピ（以降では単にレシピという）を提供するサービスを実現するシステムとしている。
本例のシステムは図１に示すように、レシピ管理サーバ１、ユーザ端末３、ＥＣ（electronic commerce：電子商取引）サーバ４が、通信ネットワーク２を介して相互に通信可能な状態で接続されている。
レシピ管理サーバ１は、レシピデータベース５０、ユーザデータベース５１、検索データベース５２、格納履歴データベース５３、食材データベース５５、提示設定データベース５６にアクセス可能とされている。
ＥＣサーバ４はユーザデータベース５１、格納履歴データベース５３、商品データベース５４にアクセス可能とされている。
また格納履歴データベース５３Ａとして示すように、ユーザ端末３に格納履歴データベースが構築され、レシピ管理サーバ１がユーザ端末３から格納履歴データベース５３Ａの情報を取得するようにしてもよい。以下の説明において、格納履歴データベース５３に対するアクセスが発生する処理は、格納履歴データベース５３Ａを対象とする処理と考えてもよい。
なお、以下「データベース」については「ＤＢ」と表記する。

【0019】

レシピ管理サーバ１は、ユーザ（レシピ提供者）から投稿されるレシピを管理し、またユーザからの要求に応じてレシピを提供する（ユーザ端末３において提示させる）処理を行う情報処理装置である。具体的な構成に関しては後述する。
このレシピ管理サーバ１が、本発明請求項の情報処理装置の実施の形態に相当する。

【0020】

通信ネットワーク２の構成は特に限定されるものではなく、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、ＶＰＮ（Virtual Private Network：仮想専用網）、電話回線網、移動体通信網、衛星通信網などが想定される。
また通信ネットワーク２の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線などの有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網などの無線でも利用可能である。

【0021】

ユーザ端末３は、レシピをレシピ管理サーバ１に投稿するユーザ（レシピ提供者）や、レシピ管理サーバ１が管理するレシピ情報を検索し閲覧するユーザ（レシピ利用者）などが使用する端末である。
なお、本実施の形態のサービスを利用する「ユーザ」はレシピ提供者、レシピ利用者のいずれにもなり得るが、以下では特に断らない限り、「ユーザ」はレシピ利用者として行動しているユーザ、もしくはレシピ利用者となる可能性を有するユーザを指すものとする。

【0022】

ユーザ端末３では、必要に応じて各種の送受信処理や表示処理などが実行される。また、ユーザ端末３は、例えば、通信機能を備えたＰＣ（Personal Computer）やフィーチャーフォンやＰＤＡ（Personal Digital Assistant）、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。

【0023】

ＥＣサーバ４は、商品の取引に関する各種サービスを提供する情報処理装置である。各種サービスとしては、例えば、電子商取引で扱っている商品群の中からユーザが所望する商品を検索して提示する商品検索サービスや、商品提供者が販売したい商品を管理する商品管理サービスがある。また例えば、ユーザ情報を管理し必要に応じて提示するユーザ情報管理サービスや、商品提供者の情報を管理し必要に応じて提示する商品提供者情報管理サービスや、商品の売買が成立した際の代金のやりとりを仲介する決済処理サービスなどもある。
ＥＣサーバ４は、ユーザ端末３へ各種サービスを実現するためのウェブページデータを生成し、送信する処理を行う。
更に、ＥＣサーバ４は、レシピ管理サーバ１からの要求に応じて各種情報をレシピ管理サーバ１へ送信する処理を行う。
またＥＣサーバ４はユーザの食材の購入情報などに応じて格納履歴ＤＢ５３の更新を行う。

【0024】

図２は、１又は複数の情報処理装置で構成されるレシピ管理サーバ１としての機能構成、およびレシピ管理サーバ１がアクセスするＤＢを示している。
レシピ管理サーバ１は、食材情報取得部１ａ、提供回数特定部１ｂ、食材グループ設定部１ｃ、レシピ特定部１ｄ、提示制御部１ｅ、レシピ管理部１ｆを備えている。
なお食材情報取得部１ａ、提供回数特定部１ｂ、食材グループ設定部１ｃ、レシピ特定部１ｄ、提示制御部１ｅ、レシピ管理部１ｆとしての各機能は、情報処理装置においてＣＰＵ（例えば後述する図３のＣＰＵ１０１）でプログラムに応じて実行される処理により実現される機能である。但し以下説明する全部又は一部の各構成の処理をハードウエアにより実現してもよい。
また各機能をソフトウエアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。１つのプログラムにより複数の機能の処理が実行されてもよいし、１つの機能が複数のプログラムモジュールの連携で実現されてもよい。

【0025】

レシピ管理部１ｆは、レシピ提供サービスとして必要な情報管理を行う機能である。
例えばレシピ管理部１ｆは、レシピ提供者が投稿したレシピについてレシピＤＢ５０の登録を行い、また登録したレシピについては、レシピが属するカテゴリ情報やレシピに使用する食材情報等とを紐付けて管理する。具体的には、あるレシピ提供者が投稿した「野菜カレー」のレシピは、料理種別「カレー」に属するレシピであり、使用食材情報として、「じゃがいも」、「人参」、「タマネギ」、「ブロッコリー」、「トマト」、「ほうれん草」が紐付けられる。

【0026】

なお、料理種別としてはカテゴリのレベルが複数段階に設定される。例えば「和食」「洋食」などの種別、「日本料理」「中華料理」「イタリア料理」「フランス料理」「タイ料理」という地域レベルの種別、「カレー」「ハンバーグ」「ラーメン」などの料理名に応じたレベルの種別、さらには「ビーフカレー」「チキンカレー」「キーマカレー」などの細かいレベルの種別などがある。
以下では説明上、あくまで一例ではあるが、次のように料理種別のレベル（分類の階層）が設定されているとする。
大分類レベル：「日本料理」「中華料理」などの地域別のレベル
中分類レベル：「カレー」「ハンバーグ」等の料理名単位のレベル
細分類レベル：「ビーフカレー」「チキンカレー」等の料理名内の詳細なレベル
レシピ管理部１ｆは、各レシピについて、このような各レベルでの種別管理も行う。

【0027】

なお、料理種別のレベルは多様であり、例えば下記（Ａ）に示すように中分類は肉料理、魚料理、野菜料理のような主たる食材の分類としてもよいし、下記（Ｂ）のように、大分類は「主食」「おかず」「副菜」などとしてもよい。
（Ａ）大分類：和食（その他：洋食など）
中分類：肉料理
細分類：肉じゃが／牛肉のしぐれ煮など
中分類：魚料理
細分類：鯖の味噌煮／鮭のちゃんちゃん焼きなど
中分類：野菜料理
細分類：焼き野菜のロースト／きんぴらごぼうなど
（Ｂ）大分類：主食（その他：おかず／副菜など）
中分類：肉料理
細分類：ハンバーグ／コロッケなど
中分類：魚料理
細分類：タコのフリット／タラのムニエルなど
中分類：野菜料理
細分類：ポトフ／野菜のトマト煮など

【0028】

また、レシピ管理部１ｆは、食材毎に、その食材が用いられるレシピの数を管理する。例えば登録している全てのレシピを対象とし、各食材が、それぞれいくつのレシピで使用されるかをカウントし、食材ＤＢ５５に登録して管理する。
またレシピ管理部１ｆは、例えばカテゴリ（料理種別）ごとに使用頻度の高い通常食材を管理する。具体的には、「カレーライス」のカテゴリに対して、同カテゴリに属するレシピの使用食材に頻出する「じゃがいも」、「人参」、「タマネギ」、「牛肉」、「豚肉」、「チキン」を通常食材として設定する。尚、食材に加えて調味料（「塩」や「胡椒」など）やそれに準ずるもの（例えば「カレールー」など）を、通常食材として設定してもよい。
また、レシピ管理部１ｆは、食材毎に、組み合わされて使用されやすい食材を管理する。例えば各種のレシピにおいて「じゃがいも」と「にんじん」が同時に用いられている例が多い場合、「じゃがいも」と「にんじん」を組み合わせられやすい食材として管理する。

【0029】

またレシピ管理部１ｆは、レシピごとに投稿された作成レポートを管理する。作成レポートは、ユーザが実際にレシピを利用して料理を行った際に感じた料理のおいしさや手軽さなどを記したレポートである。作成レポートは、レシピＤＢ５０の各レシピに紐付けられて管理される。

【0030】

食材情報取得部１ａは、食材の格納履歴を記憶する記憶装置である格納履歴ＤＢ５３から所定の条件を満たす食材の情報を取得する処理を行う。
格納履歴ＤＢ５３については後述するが、これはユーザ毎に購入した食材の情報や使用した食材の情報が登録されているものである。
食材情報取得部１ａは所定のタイミングで、各ユーザや特定のユーザについての格納履歴ＤＢ５３の情報を取得する。レシピ管理サーバ１は食材情報取得部１ａが取得する食材の情報に基づいて後述するレシピ提示設定のための処理を行う。
特には食材情報取得部１ａは、ユーザの食材購入に合わせて、格納履歴ＤＢ５３の内容から、そのユーザの食材在庫を確認し、所定の条件（例えば在庫量や消費期限に関する条件）を満たした食材の情報を取得する。

【0031】

提供回数特定部１ｂは、格納履歴ＤＢ５３に記憶された格納履歴に基づいて、特定のユーザの食材が追加される周期を判定し、判定した周期に基づいてレシピ提供回数を特定する処理を行う機能である。

【0032】

食材グループ設定部１ｃは、食材情報取得部１ａが取得した食材の情報、この場合は特定のユーザが現在所有する食材（在庫食材）のうちで例えば在庫量や消費期限に関する条件に応じて取得した食材の種類や量の情報を用いて、各食材を振り分け、レシピ提供回数に応じた数の食材グループを設定する処理を行う機能である。

【0033】

レシピ特定部１ｄは、食材グループ設定部１ｃが設定した食材グループ毎に、割り当てられた食材に基づいてレシピを特定する処理を行う機能である。即ち食材グループ毎に、そのグループに割り当てられた食材で料理可能なレシピを、レシピＤＢ５０に登録されているレシピの中から検索する。そして各食材グループについて対応するレシピを特定し、そのユーザに提示するレシピとして管理する。特定したレシピは提示設定ＤＢ５６を用いて管理する。

【0034】

提示制御部１ｅは、レシピ特定部１ｄが特定したレシピについてユーザ端末３において提示されるようにする提示制御を行う。
具体的には、或るユーザが、レシピ提供サービスのウェブサイトにログインした際に、そのユーザに薦める料理のレシピを一覧表示するウェブページデータを生成し、ユーザ端末３に送信して、提示されるようにする。
後述するが、食材グループ設定部１ｃ及びレシピ特定部１ｄによって、対象のユーザに対して、複数回の食事（料理機会）に対応させて上記の食材グループが設定され、それぞれの食材グループに対応して１又は複数のレシピを特定している。提示制御部１ｅはユーザのログインに応じて、対応するレシピを推奨すべく、提示制御を行う。
また、提示制御部１ｃは、ユーザの操作に応じた種々のウェブページデータを送信する処理を実行する。種々のウェブページデータとしては、例えばログイン画面のウェブページデータやレシピ詳細ページのウェブページデータや作成レポート投稿ページのウェブページデータなどである。
これらのウェブページのデータは、例えば、ＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible HyperText Markup Language）などの構造化文書ファイルである。構造化文書ファイルには、レシピ名や使用食材、或いは調理手順としてのテキストデータや料理画像等の画像データと、それらの配置や表示態様（文字色やフォントや大きさや装飾など）が記述されている。

【0035】

レシピ管理サーバ１には、他にも、各種情報を送受信する機能や、ユーザのログイン操作に対する認証処理などを実現するために必要な各部が設けられている。認証処理は、ユーザ端末３から送信されたログイン情報としてのユーザＩＤ（Identification）とパスワードを、ユーザＤＢ５１に記憶された認証情報と照合する処理である。

【0036】

＜２．ハードウェア構成＞
図３は、図１に示したレシピ管理サーバ１、ユーザ端末３、ＥＣサーバ４のハードウエア、及び、レシピＤＢ５０、ユーザＤＢ５１、検索ＤＢ５２、格納履歴ＤＢ５３、商品ＤＢ５４、食材ＤＢ５５、提示設定ＤＢ５６のハードウェアを例示する図である。
それぞれのサーバや端末、ＤＢにおけるコンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ（Read Only Memory）１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ（Random Access Memory）１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。

【0037】

ＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インターフェース１０５も接続されている。
入出力インターフェース１０５には、入力部１０６、出力部１０７、記憶部１０８、通信部１０９が接続されている。
入力部１０６はキーボード、マウス、タッチパネルなどにより構成される。
出力部１０７はＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどにより構成される。
記憶部１０８はＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などにより構成される。
通信部１０９はネットワーク１を介しての通信処理や機器間通信を行う。
入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

【0038】

このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われる。またリムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、レシピ管理サーバ１、ユーザ端末３、ＥＣサーバ４等としての必要な情報処理や通信が実行される。
なお、レシピ管理サーバ１等を構成する情報処理装置は、図３のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮ等によりシステム化されていてもよいし、インターネット等を利用したＶＰＮ等により遠隔地に配置されたものでもよい。

【0039】

＜３．ＤＢ＞
各ＤＢについて説明する。
レシピＤＢ５０は、レシピ提供者から投稿されたレシピの情報が記憶されるＤＢである。具体的には、図４に示すように、それぞれのレシピを識別可能なレシピＩＤに対して、レシピを投稿したレシピ提供者を特定するユーザＩＤと、投稿日時情報と、レシピが属するカテゴリ（料理種別）情報と、レシピの使用食材情報と、レシピの調理手順と、料理画像（完成した料理の画像や調理途中の料理の画像）などの画像情報と、レシピを実際に利用した（料理を作成した）他のユーザによって投稿された作成レポートを特定する作成レポートＩＤと、が紐付けられて記憶される。
また、レシピの詳細ページのＵＲＬ（Uniform Resource Locator）情報がレシピＩＤに紐付けられて記憶されてもよい。

【0040】

更に、レシピＤＢ５０には、各レシピに対して投稿された作成レポートの情報が記憶される。作成レポートの情報としては、レポート内容を示すテキストデータや投稿者を識別可能なユーザＩＤや投稿日時情報などが記憶される。

【0041】

ユーザＤＢ５１は、ユーザのログイン情報が記憶されるＤＢである。具体的には、それぞれのユーザを識別可能なユーザＩＤとログインパスワードが紐付けられて記憶される。また、ログイン履歴などの各種履歴情報が記憶されてもよい。
また、ユーザＤＢ５１には、ユーザごとの購入履歴情報が記憶される。例えば各種食材を電子商取引により購入した際の履歴情報が蓄積されている。
またユーザＤＢ５１には、ユーザ毎のレシピ閲覧履歴、レシピ投稿履歴なども記憶される。

【0042】

検索ＤＢ５２は、検索キーワードと対応した検索結果が記憶されるＤＢである。具体的には、「カレー」や「ハンバーグ」などの料理名や「きのこ」や「トマト」などの材料名などの検索キーワードに応じて、複数のレシピが検索結果として紐付けられて記憶される。
例えばユーザの検索要求に応じて検索処理が実行され、その結果抽出された検索結果が検索キーワードに紐付けられて検索ＤＢ５２に記憶される。このように紐付けが行われることで、検索要求があった際に新たな検索処理を実行せずに済む機会が増える。
なお、予め定期的に検索キーワードを用いた検索処理を実行しておき、その結果抽出された検索結果が検索キーワードに紐付けられて検索ＤＢ５２に記憶されるようにしてもよい。

【0043】

格納履歴ＤＢ５３（又は５３Ａ）は、ユーザ毎の食材の購入履歴や使用履歴が記憶されるＤＢである。
図５Ａに一例を示す。例えばユーザＩＤが“Ｕ００１”のユーザについて例示しているように、一人のユーザに対して、「じゃがいも」「タマネギ」「にんじん」・・・等の各食材について、購入履歴や使用履歴が記憶されている。例えば購入や使用の情報がデータナンバ毎の情報として随時追加されていく。
購入データとしては、追加日時や追加量が記憶される。
使用データとしては、使用日時や使用量が記憶される。
サーバ側が構築する格納履歴ＤＢ５３としては、図示のように各ユーザ、例えばユーザＩＤでいうと“Ｕ００１”“Ｕ００２”“Ｕ００３”・・・毎に、このように購入履歴や使用履歴が記憶される。各ユーザとは例えばレシピ提供サービスに登録してログイン可能なユーザである。
なお、ユーザ端末３において格納履歴ＤＢ５３Ａを構成する場合は、そのユーザ端末３の使用者で或るユーザのみについて購入履歴や使用履歴が記憶され、それをレシピ管理サーバ１が参照可能とされていればよい。

【0044】

格納履歴ＤＢ５３は、レシピ管理サーバ１やＥＣサーバ４がデータを追加していく。例えばＥＣサーバ４は各ユーザの電子商取引の情報のうちで食材購入の情報を取得することに応じて購入データを追加する。特に本実施の形態ではユーザによる定期的な購入を想定するため、例えばＥＣサーバ４が提供するマーケットにおいてユーザが定期的な食材に購入を行っていれば、その情報を格納履歴ＤＢ５３に反映することができる。
またユーザが協同組合や食材配達サービスなどを利用している場合、ユーザ毎の購入履歴情報はそれらの業者で管理されているため、例えばレシピ管理サーバ１が、その業者の管理端末から各ユーザの食材購入履歴情報を取得し、格納履歴ＤＢ５３を更新してもよい。
さらに、ユーザが実店舗で購入を行っている場合に、ユーザ端末３に接続したリーダー装置によりレシートを読み込ませることで、購入した食材の情報をレシピ管理サーバ１に提供することもできる。また実店舗のＰＯＳシステム（Point of sale system）のデータを例えばユーザの会員情報とリンクさせて収集し、購入食材の情報として反映させてもよい。レシピ管理サーバ１は、例えばこれらの手法で取得した購入データを、逐次格納履歴ＤＢ５３に登録する。

【0045】

使用データに関しては、ユーザが使用したレシピの推定に基づいて記憶することが考えられる。レシピの「使用」とは、ここではレシピを参照して料理を作ったという意味である。
例えば或る１つのレシピを使用したと推定した場合に、そのレシピで用いられる食材と量を確認し、それらを使用履歴として登録する。
使用したレシピの推定手法としては、次のような例が考えられる。
・ユーザがレシピ詳細ページ（以下、「詳細ページ」と略称することもある）の要求を１回行った場合は、その詳細ページが要求されたレシピを使用したと推定する。レシピ詳細ページとは、食材や実際の調理手順等が記載されているウェブページである。ユーザは一般に、一覧提示されたレシピの中から選んで詳細ページを要求し、閲覧して調理を行う。
・ユーザがレシピ詳細ページの要求を複数のレシピについて行った場合は、最後の要求に係るレシピを使用したと推定する。ユーザは、複数の詳細ページで各レシピの詳しい調理手順等を確認してから作る料理（使用レシピ）を決めることも多い。従って、最後に詳細ページを見たレシピが、各種レシピを確認した上で決めたものと推定することができる。
・ユーザが詳細ページのプリントを行った場合、そのレシピを使用したと推定する。プリントは、実際の調理の際に、調理手順を確認しやすくするためと考えられるためである。
・詳細ページの閲覧時間が或る程度の時間以上、長い場合に、そのレシピの使用と推定する。画面上で詳細ページを見ながら実際の調理を行っていると想定されるためである。
例えば以上のような手法で使用レシピを推定することで、使用データを追加できる。
もちろん、推定以外にも、実際にユーザに使用レシピの入力を求め、それによって使用データを追加してもよい。またユーザが或るレシピに対して調理のレポートや料理の写真を投稿した場合に、上述の推定処理を確定させたり修正してもよい。

【0046】

いずれにしても格納履歴ＤＢ５３は、ユーザ毎に、食材購入と食材使用の履歴が登録され、現在のユーザの食材在庫が把握できるものとされれば良い。食材在庫の把握は厳しい正確性を要求するものではなく、少なくとも現在ユーザの自宅にある食材の種類と量が大まかにわかればよい。もちろん冷蔵庫やストッカ等とネットワーク通信により連携して、食材在庫が正確にわかるようなシステムを構築してもよい。
なお図５では食材単位で追加データ、使用データが記憶される例を示しているが、特に食材単位で分けることなく、追加データとして食材名、追加日時、追加量が記憶され、使用データとして食材名、使用日時、使用量が逐次記憶されていくような形態でよいことはいうまでもない。

【0047】

商品ＤＢ５４は、ＥＣサーバ４が電子商取引において扱う各種商品の情報が記憶されている。例えば各仮想店舗の商品についての価格、在庫、商品画像等の各種情報が登録されている。

【0048】

食材ＤＢ５５はレシピに用いられる食材に関する情報が記憶されるＤＢである。
図５Ｂに例を示すが、各食材が、それぞれいくつのレシピで使用されるかをカウントした値が登録されている。レシピ数が多い食材は、各種の料理で使われやすい食材、つまり
汎用性が高い食材と考えられる。
なお図示していないが、食材ＤＢ５５としては、組み合わせられやすい食材の情報や、各種の料理種別毎に使用されやすい食材の情報を登録しても良い。組み合わせられやすい食材の情報や、料理種別毎で使われやすい食材の情報は、レシピＤＢ５０に登録されているレシピに基づいて生成すればよい。例えば「じゃがいも」を対象とした場合に、登録されているレシピの中で、じゃがいもとともに使われている食材のうちで、該当レシピ数が上位となる食材を「組み合わせられやすい食材」と判定して登録すればよい。また使用されやすい食材の情報は、例えば「カレー」については、料理種別（中分類レベル）が「カレー」とされているレシピを収集し、それらの中で各食材の使用頻度（使用しているレシピ数）を確認し、上位となる食材を「使用されやすい食材」と判定すればよい。
もちろん登録されているレシピに限らず、一般的な認識に基づいてこのような情報を生成し、登録しておくものでも良い。

【0049】

提示設定ＤＢ５６はユーザ毎に現在設定中のレシピの情報が登録される。
図６に示すように、ユーザＩＤに対応して、ｎ個の食材グループＧＰ１〜ＧＰｎ（ユーザ：Ｕ００１についてはｎ＝７としている）の設定、食材グループ毎に振り分けられた食材の情報、食材グループ毎に対応するレシピの情報が登録される。各食材グループＧＰ１〜ＧＰ７に対応しては、ユーザに提示すべき日時の情報も記憶されている。
また提示設定ＤＢ５６には、そのユーザが実際に使用したレシピを推定するために用いる情報も記憶される。例えば詳細ページの閲覧履歴や印刷等の情報である。一例としては、この推定情報に基づいて、使用レシピが推定され、推定された使用レシピに基づいて、上述の格納履歴ＤＢ５３において食材の使用データの記憶が行われる。
これらの提示設定ＤＢ５６に記憶される情報の詳細については後述する。

【0050】

以上の各ＤＢ（５０〜５６）は、レシピ管理サーバ１又はＥＣサーバ４がアクセス可能とされていればどのような形態で実現されていてもよい。例えばレシピ管理サーバ１と同一システム内の記憶部に各ＤＢ（レシピＤＢ５０、ユーザＤＢ５１、検索ＤＢ５２、格納履歴ＤＢ５３、食材ＤＢ５５、提示設定ＤＢ５６）のすべてが形成されていてもよいし、これら各ＤＢの一部又は全部が別体、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん各ＤＢが一つの装置（例えば一つのＨＤＤ等）内に形成されている必要はない。また各ＤＢのそれぞれが、それぞれ１つのＤＢとして構成される必要もない。例えばユーザＤＢ５１として記憶される情報が、複数のユーザＤＢ（例えばログイン用のユーザＤＢと取引用のユーザＤＢなど）により記憶管理されてもよい。上記した各ＤＢは、実施の形態の処理に関連する情報の記憶部を、それぞれ１つのＤＢの形態で例示したものに過ぎない。

【0051】

＜４．端末とサーバ間の処理の流れ＞
レシピ管理サーバ１とユーザ端末３が実行する処理の流れの一例について、図７を参照して説明する。
ここでは、レシピ管理サーバ１が提供する各種サービスを受けるために、ユーザがユーザ端末３を用いてログイン操作を行い、レシピ提供を受ける例を説明する。なお、この図７の流れはあくまで説明上のモデルとなる一例である。実際の処理が必ずしも常にこの順序で行われるわけではない。

【0052】

ユーザ端末３はステップＳ１０１において、ユーザによるログイン画面表示操作に応じたログイン画面情報要求処理を実行する。
ログイン画面情報要求処理によりユーザ端末３からレシピ管理サーバ１へログイン画面情報要求が送信されると、レシピ管理サーバ１はステップＳ２０１において、ログイン画面情報送信処理を実行する。
これにより、例えば、レシピ管理サーバ１から受信したレシピサイトのログイン画面情報（ウェブページデータ）に応じたウェブページがユーザ端末３上に表示される。

【0053】

次に、ユーザ端末３はステップＳ１０２において、ユーザの入力操作に応じたログイン情報（ユーザＩＤとログインパスワード）をレシピ管理サーバ１へ送信するログイン情報送信処理を実行する。

【0054】

ユーザ端末３からレシピ管理サーバ１へログイン情報が送信されると、レシピ管理サーバ１はステップＳ２０２において認証処理を実行し、続くステップＳ２０３において認証結果通知処理を実行する。
具体的には、レシピ管理サーバ１は、ユーザ端末３上で入力されたユーザＩＤとパスワードをユーザＤＢ５１に記憶された情報と比較して当該ユーザのログイン可否を判定し、当該ログイン可否情報を認証結果としてユーザ端末３へ通知する。
尚、図７に示す一連の流れは、ステップＳ２０２の認証処理においてログイン可と判定された場合を示している。ステップＳ２０２においてログイン不可と判定した場合は、ユーザ端末３は再度ステップＳ１０２の処理を実行し、これに応じてレシピ管理サーバ１はステップＳ２０２の処理を実行する。

【0055】

ユーザが認証できた場合、レシピ管理サーバ１は、当該ユーザに対して、レシピの提案（推奨レシピの提示）を行う。例えばレシピサイトのトップページにおいて「本日のお勧めレシピ」などとして提示するとよい。もちろん、ユーザが特に推奨レシピを見たいときに要求するウェブページにおいて提示しても良いが、ここではトップページにおいて表示する例で説明していく。
このような推奨レシピ提示を含むトップページを表示させるために、レシピ管理サーバ１はステップＳ２０４，Ｓ２０５，Ｓ２０６を行う。
ここでいう推奨レシピは、一般的に評判のいいレシピなどの不特定ユーザへのお勧めレシピではなく、ログインユーザに特化し、そのユーザの食材在庫に基づいて設定した、ｎ回分の推奨レシピのうちの今回分である。

【0056】

図８で提示する推奨レシピの提示設定の概要を説明する。
例えば或るユーザについて、図示するような食材情報が取得できたとする。これは、当該ユーザについての格納履歴ＤＢ５３を参照して取得する、ユーザの現在の食材在庫である。例えばユーザが１週間に一度、食材をまとめて購入する生活習慣を有しているとしたときに、食材情報は、購入直後の食材在庫を示す情報と考えればよい。
食材情報として図示する食材Ｆ１，Ｆ２，Ｆ３・・・とは、具体的な食材を表している。例えばＦ１は「豚肉」、Ｆ２は「牛肉」、Ｆ３は「じゃがいも」などである。食材情報は、これらの食材の種類とともに、食材の量の情報も有するようにする。
レシピ管理サーバ１は、この食材情報を、ｎ回分の食事に用いることを想定して、ｎ個（図８ではｎ＝７としている）の食材グループＧＰ１〜ＧＰｎ（ＧＰ７）を設定する。ｎ回分の“ｎ”は、レシピを参考にして料理を行う回数であり、具体的にはｎ回の食事に相当する。例えば１週間に一度食材を購入するユーザが、毎夕食の料理を行うという場合、１週間分の毎日の夕食という意味で、ｎ＝７とされる。“ｎ”の値はユーザ毎に、ユーザの事情に応じて設定される。例えば格納履歴ＤＢ５３の情報から把握できるユーザの購入周期などに基づいて設定される。

【0057】

この食材グループＧＰ１〜ＧＰ７は、食材情報として取得した食材を振り分けてグループ化したものである。
振り分け方としては、１つの手法として、食材単位で振り分けることが考えられる。例えば１つの種類の食材は１つのグループに割り当てるとする。例えば食材Ｆ１は６００ｇ全部を１つの食材グループに含めるような振り分け手法である。
また単体毎に振り分けてもよい。例えばじゃがいもが３個の場合、食材グループＧＰ１に１個、食材グループＧＰ２に２個などとしてもよい。
もちろん量で分割して振り分けても良い。例えば豚肉が４００ｇある場合に、１００ｇを食材グループＧＰ１に割り当て、３００ｇを食材グループＧＰ２に割り当てるなどである。
また、これらを組み合わせ、或る食材Ｆ１は食材単位、食材Ｆ２は単体単位、食材Ｆ３は量で分割することも考えられる。
図８の例では、食材情報で示される食材Ｆ１，Ｆ２・・・を、単体毎や量で分割して食材グループＧＰ１〜ＧＰ７に振り分けた例を示している。

【0058】

各食材グループＧＰ１〜ＧＰ７については、割り当てられた食材で料理が可能なレシピが検索され、それらが食材グループに対応するレシピとして特定される。図では、例えば食材グループＧＰ１の対応レシピとして、レシピＲＰ１，ＲＰ５，ＲＰ２５，ＲＰ３１，ＲＰ４５が特定された例を示している。
なお、これら対応レシピとして特定されたレシピは、その食材グループに割り当てられた食材を使い切るものである必要はなく、割り当てられた食材で調理可能であればよい。従って、異なる食材グループに同じレシピが対応することもある。例えば図８においてレシピＲＰ１は食材グループＧＰ１、ＧＰ２に対応している。

【0059】

各食材グループＧＰ１〜ＧＰ７に対応するものとして特定されたレシピが、ユーザに対して各回の推奨レシピとして提示するレシピとなる。
例えば当該設定を行った後、当該ログインユーザへの１回目の推奨レシピ提示の際（例えば１月２５日（月）の提示）には、例えばトップページの一部において図９Ａのようにレシピ提示が行われる。これらは図８に食材グループＧＰ１に対応するものとして示すレシピＲＰ１，ＲＰ５，ＲＰ２５，ＲＰ３１，ＲＰ４５についての画像やテキストとなる。
またその後の当該ログインユーザへの２回目の推奨レシピ提示の際（例えば１月２６日（火）の提示）には、図９Ｂのようにレシピ提示が行われる。これらは図８に食材グループＧＰ２に対応するものとして示すレシピＲＰ１，ＲＰ１５，ＲＰ４３，ＲＰ５１，ＲＰ６１，ＲＰ８０についての画像やテキストとなる。

【0060】

図８のように、特定のユーザ毎に、現在の食材在庫に応じて、食材グループＧＰ１〜ＧＰｎを設定し、今後ｎ回の食事において推奨提示するレシピを特定することを説明上、「提示設定」と呼ぶ。そしてその設定内容は、図６の提示設定ＤＢ５６に登録される。つまり例えば食材グループＧＰ１〜ＧＰ７とされた食材の情報や、それぞれの対応レシピが登録される。
レシピ管理サーバ１は、このような提示設定の処理を、例えばバッチ処理として所定時間おきに、各ユーザに対応して実行し、各ユーザについて、提示設定を提示設定ＤＢ５６に登録しておく。

【0061】

図７の処理においてレシピ管理サーバ１は、ログインユーザについて図８のような推奨レシピについての提示設定を確認して、提示制御を行うことになる。
ステップＳ２０５でレシピ管理サーバ１は、提示設定ＤＢ５６を参照して、ログインユーザについての提示設定内容を取得する。
ステップＳ２０６でレシピ管理サーバ１は、今回、推奨するものとして提示するレシピを特定する。即ち今回が、設定後の２回目の食事の前のタイミング（例えば図６の例での１月２６日の夕食前の時間帯）での提示機会であれば、食材グループＧＰ２に対応するレシピＲＰ１，ＲＰ１５，ＲＰ４３，ＲＰ５１，ＲＰ６１，ＲＰ８０を推奨提示レシピとして特定する。
そしてステップＳ２０６で提示制御を行う。レシピ管理サーバ１は、そのユーザについて今回分のお勧めレシピの表示を組み込んだトップページデータを生成し、そのウェブページデータをユーザ端末３に送信する。
尚、認証結果をユーザ端末３へ返すと共に、レシピサイトのトップページのウェブページデータを送信してもよい。即ち、ログイン認証ＯＫの場合には、ステップＳ２０６の段階で、認証結果送信とともにトップページデータの送信を行うものとしてもよい。

【0062】

以上のレシピ管理サーバ１の処理により、ユーザ端末３では、レシピサイトのトップページが表示される。このときに、トップページの一部には図９Ｂに示したような今回の推奨レシピの一覧が表示されることになり、ユーザは、その中でレシピを選ぶこととすれば、それは、そのときのユーザの食材在庫で調理可能なレシピとなっている。

【0063】

ユーザがユーザ端末３上で推奨レシピを閲覧し、任意のレシピを選択する操作を行うと、ユーザ端末３はステップＳ１０３において、レシピ選択処理を実行する。即ちユーザ端末３は、ユーザが選択したレシピが何れのレシピであるかを選択レシピ情報としてレシピ管理サーバ１に通知する。尚、この処理は、選択したレシピの詳細情報ページのウェブページデータを要求する処理である。

【0064】

選択レシピ情報を受信したレシピ管理サーバ１は、ステップＳ２０７において、レシピの詳細ページの閲覧履歴を提示設定ＤＢ５６に、使用レシピの推定のための推定情報として記憶する処理を行う。例えば今回、ユーザ“Ｕ００１”としてのユーザに対して２回目の推奨レシピ提示を行っているのであれば、食材グループＧＰ２に対応した推定情報として、詳細ページの閲覧履歴を記憶する。
そしてレシピ管理サーバ１はステップＳ２０８において、選択されたレシピの詳細情報が記載されたウェブページのデータをユーザ端末３に送信する。
この処理によって、ユーザ端末３上に、当該ユーザが選択したレシピに関する詳細情報が提示される。詳細情報とは、例えば、レシピに使用する食材情報や調理手順、調理器具情報などの情報である。他にも、選択されたレシピに対して投稿された作成レポートの情報などを含んでいてもよい。
ユーザは詳細ページを閲覧しながら調理を行うことができるし、もし詳細ページを閲覧して、その料理に気が進まなければ、他の推奨レシピを選択すればよい。その場合もステップＳ１０３，Ｓ２０７，Ｓ２０８の処理により、ユーザは選択したレシピの詳細ページの閲覧をすることができる。

【0065】

ユーザ端末３上に詳細情報が表示されたレシピに対し、ユーザが使用したことを推定可能な操作を行った場合、利用したことを推定可能な操作に関する情報がレシピ管理サーバ１に対して送信される。
例えば、レシピ使用が推定される操作として、レシピの詳細情報を印刷するための操作を行った場合、ユーザ端末３はステップＳ１０４において、印刷操作に関する情報をレシピ管理サーバ１に送信する処理を実行する。印刷操作に関する情報とは、操作を行ったユーザのユーザＩＤと印刷対象とされたレシピのレシピＩＤなどである。
印刷操作情報を受信したレシピ管理サーバ１は、ステップＳ２０９において、提示設定ＤＢ５６に使用レシピの推定情報として、レシピの印刷履歴を記憶する。
尚、レシピ使用が推定される操作の他の例としては、例えば、作成レポートの投稿操作や、お気に入りレシピに登録する操作や、レシピ詳細情報の所定時間（例えば、調理時間の８割の時間）以上の閲覧操作などを挙げることができる。
何れの操作も、ユーザによるレシピの使用（即ち実際に調理を行ったこと）が推測される操作である。

【0066】

＜５．第１の実施の形態＞
以上は、ユーザ端末３とレシピ管理サーバ１の処理の流れの一例であるが、結局ユーザにとっては、例えば食材の購入間隔に合わせて、次の購入までの料理の回数に応じて、毎回適切な推奨レシピが提示されることになる。
例えばインターネット通販、生活協同組合による一括購入、生鮮食料品配達サービス、週一でのマーケットでの大量購入をしている人などにとっては、次回の購入までの食材の配分も面倒なものであるが、本実施の形態によれば、次の購入までの毎回の食事について、食材が自動的に振り分けられ、かつ振り分けられた状態で調理可能なレシピが毎回提示されることになる。

【0067】

このようなサービスを適切に実現するためのレシピ管理サーバ１の処理を説明していく。
まず、以上のようなサービスを実現するには、ユーザ毎に毎回の推奨レシピが特定された提示設定が行われ、図６の提示設定ＤＢ５６に登録されている状態とすることが望ましい。そこでレシピ管理サーバ１は、例えば毎日午前零時としての２４時間おきなどの所定時間毎のバッチ処理として、各ユーザに対して必要に応じて提示設定を行うようにする。

【0068】

提示設定のためのバッチ処理例を図１０に示す。
レシピ管理サーバ１は、例えば本実施の形態のサービスを利用するものとして登録している各ユーザを順次対象にして図１０の処理を行う。
レシピ管理サーバ１はまずステップＳ３０１で或る一人のユーザを処理対象として選択する。そしてステップＳ３０２で当該ユーザの提示設定ＤＢ５６の登録内容を確認する。この場合は、現在有効な提示設定が登録されているか否かを確認することになる。現在有効であるとは、次回の提示機会に提示すべき推奨レシピが設定されているという意味である。例えば図６のユーザ“Ｕ００１”の例でいえば、現在が１月２５日から１月３１日のいずれかであって、まだ最後の食材グループＧＰ７に対応する推奨レシピの提示が行われていない場合は、有効な提示設定があるということになる。
有効な提示設定が存在すれば、今回は当該ユーザについては処理不要とし、ステップＳ３０３からＳ３０６に進む。そして他に未処理のユーザが残っていれば、ステップＳ３０１に戻って、次のユーザに対して処理を行う。

【0069】

現在有効な提示設定が存在しない場合は、レシピ管理サーバ１はステップＳ３０３からＳ３０４に進み、現在が対象のユーザにとっての食材追加タイミング又は提示設定タイミングのいずれかであるかを確認する。
食材追加タイミングとは、例えば定期的な食材購入を行っているユーザについての食材を取得したタイミングであるか否かである。例えばインターネット通販により、毎週日曜日に食材が届けられるユーザについては、その直後のバッチ処理タイミングが、食材追加タイミングとなる。このような食材追加タイミングは、格納履歴ＤＢ５３を参照して、ユーザの購入周期を確認し、バッチ処理を行っている現在が最新の購入時期の直後であるか否かを判定することによってもよい。
また実際にユーザの格納履歴ＤＢ５３を参照して、最新の購入データが、前回のバッチ処理以降である場合に、食材追加タイミングと判定してもよい。
また、ユーザが予め提示設定タイミングを指定しておいてもよい。例えば毎週日曜日時点の食材により、月曜から日曜までについての提示設定を行うように予めユーザが指定しておく。その場合、現在が該当のタイミングであれば、設定タイミングであると判定すればよい。

【0070】

ステップＳ３０４で現在が処理対象のユーザにとっての食材追加タイミング又は設定タイミングであればステップＳ３０５に進む。
なお、ステップＳ３０４の処理は省略して、対象のユーザに現在有効な提示設定が存在しなければ、常にステップＳ３０３からＳ３０５に進むようにしてもよい。
ステップＳ３０４の処理を加えるのは、レシピ管理サーバ１の処理負担の削減などの事情で、提示設定のための最適なタイミングである場合にのみステップＳ３０５に進むこととしたい場合でよい。

【0071】

ステップＳ３０５では、当該ユーザについての提示設定を行う。
そして提示設定を行ったら、ステップＳ３０６で残りのユーザを確認し、他に未処理のユーザが残っていれば、ステップＳ３０１に戻って、次のユーザに対して処理を行う。
レシピ管理サーバ１は全ユーザに対して処理を終えたら、図１０の処理を終える。

【0072】

図１０のステップＳ３０５の提示設定処理を図１１に詳細に示す。レシピ管理サーバ１は主に図２に示した食材情報取得部１ａ、提供回数特定部１ｂ、食材グループ設定部１ｃ、レシピ特定部１ｄの機能により図１１の提示設定処理を実行する。

【0073】

或る処理対象のユーザについて提示設定を行う場合は、レシピ管理サーバ１はまず図１１のステップＳ４０１で、そのユーザの食材情報を取得する。
この食材情報とは、例えば図８に示したような食材の種類と量の情報である。つまり各食材グループＧＰ１〜ＧＰｎに振り分ける前の食材の在庫の情報である。
レシピ管理サーバ１は当該ユーザについての格納履歴ＤＢ５３を参照し、現在、ユーザが所有（在庫）している食材を判定する。例えば各食材について、最新のものから購入データや使用データを溯っていくことで、現在のユーザの在庫量を判定する。図１０のステップＳ３０４で食材追加タイミングの直後のバッチ処理であると判定されているときは、最新の購入データの情報を集めることとしても良い。
但し、ここで取得する食材の情報は、ユーザが在庫している食材の全てではなく、料理への使用に適した食材であるという条件を課すことが望ましい。例えば、
・食材毎に設定された最小使用量、又は平均使用量以上の在庫量を有する食材
・食材毎に設定された消費期限が期限内の食材
ということを、食材情報に含める条件とする。これらに適しない食材については、食材情報に含めない。このような条件を課すことで、使えない食材を排除して適切なレシピ検索が行えるようになるためである。

【0074】

続いてステップＳ４０２でレシピ管理サーバ１は、格納履歴ＤＢ５３の情報から食材の追加周期を判定する。例えば処理対象のユーザについては、週１回のペースで食材購入が行われていることが確認されたら、食材追加周期は７日となる。また３日毎に食材購入のデータが存在すれば食材追加周期は３日となる。毎日買い物を行っているユーザであれば食材追加周期は１日である。
もちろんユーザは、常に規則的に食材購入を行っているとは限らないので、例えば最新の食材購入からその前回の食材購入までの間隔を食材追加周期としたり、過去の平均的な購入間隔を算出して食材追加周期としてもよい。
但し、本実施の形態の処理は、食材を週一度まとめて購入するようなユーザを主なサービス対象としているため、食材追加周期は、ある程度安定していることが想定される。

【0075】

食材追加周期を判定したらレシピ管理サーバ１はステップＳ４０３でレシピ提供回数を特定する。上述したｎ回分の食事のためのレシピ提供を行うとした場合の“ｎ”の値である。レシピ提供については、１日につき３食、２食、１食のいずれを希望するかを、ユーザが予め選択しておけば良い。例えば夕食についてのみレシピ提供サービスを受けたいユーザは、その旨を予め指定しておく。レシピ管理サーバ１は例えばユーザＤＢ５１に、そのようなユーザの設定情報を登録しておく。当該ユーザの食材追加周期が７日であれば、レシピ提供回数を７回とすればよい。また、１日２回のレシピ提供を希望するユーザの食材追加周期が５日であれば、レシピ提供回数は１０回となる。

【0076】

ステップＳ４０４でレシピ管理サーバ１は、食材の振り分け単位の設定を行う。振り分け単位とは、或る食材グループに割り当てる１単位である。
例えば図１２Ａは食材種別をそのまま振り分け単位とする例である。食材Ｆ１〜Ｆｍについて、各食材については分割しないで、食材Ｆ１，Ｆ２・・・をそれぞれその単位で振り分ける例である。
図１２Ｂは、食材に応じて、分量単位で振り分けるようにする例である。例えば食材Ｆ１はＦ１−１〜Ｆ１−４に分割して、４つの食材グループに振り分けるようにする。食材Ｆ３はＦ３−１〜Ｆ３−３に分割して、３つの食材グループに振り分けるようにする。
このような振り分けの単位を設定する。振り分けの単位は、毎回ランダムに決定することが考えられる。但し分量単位の場合、その分量は、食材毎に最低量が決められていることが適切となる。

【0077】

食材を分量単位で割り当てる場合には、その分量単位は、食材毎に設定された利用量、例えば基準利用量、平均的な利用量、最小利用量などとする例が考えられる。
また利用量は登録されているレシピ情報に基づいて設定することもできる。
さらにユーザの食材の使用履歴に基づいて利用量を特定するようにしてもよい。
また分量単位は、振り分けが必要な数に応じた量としてもよい。

【0078】

ステップＳ４０５でレシピ管理サーバ１は、レシピ提供回数の値を変数ｎに代入する。変数ｎは、食材グループＧＰ１〜ＧＰ（ｎ）として、設定する食材グループの数を決める値となる。
またステップＳ４０６でレシピ管理サーバ１は振り分け条件を選択する。振り分け条件とは、食材グループＧＰ１〜ＧＰ（ｎ）に振り分け単位の食材を振り分ける際の振り分け方を規定する各種条件のことを総称している。
例えば振り分け処理のアルゴリズムとして、
・ランダム振り分け
・食材使用頻度（汎用性）を考慮した振り分け
・消費期限を考慮した振り分け（消費期限までの期間が短いものを、推奨レシピが早く提示される食材グループに入れるようなアルゴリズム）
・食材種別を考慮した振り分け（例えば鮮度の落ち具合が早い食材を、推奨レシピが早く提示される食材グループに入れるようなアルゴリズム）
・全食材グループに葉物野菜を含めるアルゴリズム
・肉類と魚類を交互に振り分けるアルゴリズム
などがある。
例えばこれらのような振り分けアルゴリズムを複数用意しておき、ステップＳ４０６では今回実行する処理を選択するようにする。これは特にユーザ個人に対応するものではなく、どのアルゴリズムを用いるかは毎回不規則に選択するとよい。それによって食材グループＧＰ１〜ＧＰｎに割り当てられる食材の組み合わせも多様化するためである。つまり同じような食材を毎回購入するようなユーザに対しても、多様なレシピ提示を行う可能性を高めることができるためである。
なお振り分け処理のアルゴリズム以外にも、例えば振り分ける食材の最小分量、振り分け単位の選択、振り分ける順序が優先される食材の設定なども、振り分け条件の１つとすることができる。

【0079】

ステップＳ４０７でレシピ管理サーバ１は、実際の振り分け処理を行って、食材グループＧＰ１〜ＧＰｎを設定する。即ちステップＳ４０６で選択した振り分けアルゴリズムを用いて、食材情報で示される食材について、ステップＳ４０４で設定した振り分け単位で、ｎ個のグループに振り分けを行う。
振り分けアルゴリズムは上記のように各種考えられるが、ここでは食材の汎用性を考慮した振り分け処理の一例を示しておく。

【0080】

今、仮に、食材Ｆ１，Ｆ２・・・Ｆｍが、この数字の順序で汎用性が高いものであるとする。汎用性が高いとは、多くのレシピで使用されているという意味である。レシピ管理サーバ１は食材ＤＢ５５を参照することで、食材情報に挙げられた各食材の汎用性の高い順序を判別することができる。
図１３では、ｎ＝７として、汎用性を考慮した振り分けの例を示している。最も汎用性が高い食材Ｆ１が、４つのグループに振り分けるように振り分け単位設定されている場合、例えば７個の食材グループＧＰ１〜ＧＰ７のうちの４つに食材Ｆ１を割り当てる。ここでは一つおきの食材グループＧＰ１，ＧＰ３，ＧＰ５，ＧＰ７に割り当てている。
なお、本実施の形態では食材グループＧＰ１〜ＧＰｎは、その数字の順番が提示順として説明している。従って、一つおきの食材グループに、食材Ｆ１を割り当てるということは。食材Ｆ１を用いる料理のレシピが、連続してユーザに提示されることはないということになる。

【0081】

次に２番目に汎用性が高い食材Ｆ２を、まだ食材割り当てのない食材グループＧＰ２に割り当てる。
さらに３番目に汎用性が高い食材Ｆ３は、３つのグループに振り分けるように振り分け単位設定されている場合、まず食材割り当てがない食材グループＧＰ４，ＧＰ６に割り当てる。ここまでの割り当てで、比較的汎用性が高い食材が、全ての食材グループに含まれたことになる。そこで、残りの食材Ｆ３の一部及び食材Ｆ４〜Ｆｍを順次、例えば図１３に示すように割り当てていく。
図１４はこのような汎用性を考慮した振り分け処理を示している。
レシピ管理サーバ１はまずステップＳ５０１で汎用性１位食材を割り当てる。この時点で、ステップＳ５１１で全食材グループＧＰ１〜ＧＰｎが１以上の食材を含むものとなったか否かを確認する。まだ食材割り当てのない食材グループが存在する場合、次にレシピ管理サーバ１はステップＳ５０２で汎用性２位食材を、食材無しのグループに割り当てる。そしてステップＳ５１２で全食材グループＧＰ１〜ＧＰｎが１以上の食材を含むものとなったか否かを確認する。まだ食材割り当てのない食材グループが存在する場合、次にレシピ管理サーバ１はステップＳ５０３で汎用性３位食材を、食材無しのグループに割り当てる。そしてステップＳ５１３で全食材グループＧＰ１〜ＧＰｎが１以上の食材を含むものとなったか否かを確認する。

【0082】

以上のように、全食材グループＧＰ１〜ＧＰｎが１以上の食材を含むまで、汎用性が高い順に食材の割り当てを行っていく。
そして全食材グループＧＰ１〜ＧＰｎが１以上の食材を含む状態となったら、ステップＳ５２０に進み、未割り当ての食材を選択して、或る食材グループに割り当てる。これをステップＳ５２１で全食材の振り分けが完了したとされるまで繰り返す。全食材Ｆ１〜Ｆｍについて割り当てを行った時点で食材グループＧＰ１〜ＧＰｎへの食材の振り分けが完了する。
なお、ステップＳ５０ｍで汎用性ｍ位、つまり最も汎用性のない食材を割り当てても、全食材グループＧＰ１〜ＧＰｎが１以上の食材を含むものとならなかった場合は、振り分ける食材の数（振り分け単位で数えた数）よりも食材グループ数（ｎ）が多い場合である。このような場合は、適切な振り分けが不可能であるため、ステップＳ５１ｍからステップＳ５３０のエラー処理に進む。この場合については図示していないが、図１７のステップＳ４０４の食材の振り分け設定をやり直すか、或いは図１６における当該ユーザについての処理として提示設定エラーとして終了させることが考えられる。

【0083】

以上の図１４のような処理により、汎用性が高い食材が各食材グループＧＰ１〜ＧＰ７にまんべんなく振り分けられる。これは、各食材グループＧＰ１〜ＧＰ７に対応するレシピ数を増加させる効果を生ずる。

【0084】

なお、著しく汎用性の低い食材、つまりレシピに登場することが極めてまれな食材というものもある。食材ＤＢ５５においてレシピ数が極端に少ない食材である。
そのような食材については、各食材グループＧＰ１〜ＧＰｎのうちの複数に振り分けることで、その食材を用いたレシピを抽出しやすくすることも考えられる。
例えば食材Ｆｘが、汎用性が極めて低い食材とする。この食材Ｆｘを用いるレシピＲＰｘは、食材Ｆ１、Ｆ５、Ｆｘを用いるとする。すると、食材Ｆｘを各グループに割り当てることで、食材Ｆ１，Ｆ５を有するグループが発生する確率を高くでき、レシピＲＰｘを抽出できる可能性を高めることができる。

【0085】

以上は食材グループＧＰ１〜ＧＰｎへの食材の振り分け処理の一例である。上述した各種アルゴリズムにより多様な振り分け処理が想定される。
このステップＳ４０７により、例えば図８に示したように食材が振り分けられた食材グループＧＰ１〜ＧＰｎが設定されることになる。

【0086】

食材グループＧＰ１〜ＧＰｎを設定したら、続いてレシピ管理サーバ１はステップＳ４０８〜Ｓ４１２により、各食材グループＧＰ１〜ＧＰｎに対応するレシピを特定する処理を行う。
レシピ管理サーバ１はまずステップＳ４０８で変数ｘ＝１とする。変数ｘは処理対象の食材グループを指定する変数である。

【0087】

次にレシピ管理サーバ１はステップＳ４０９で、食材グループＧＰ（ｘ）についてレシピ検索を行う。これは食材グループＧＰ（ｘ）に割り当てられた食材を検索キーとして、レシピＤＢ５０を検索し、その食材の範囲で調理が可能なレシピを抽出する処理となる。なお、食材グループＧＰ（ｘ）に割り当てられた食材を全て使うレシピである必要はなく、その割り当てられた食材の範囲内で調理可能なレシピであればよい。
もちろん、割り当てられた食材を使い切るようなレシピを抽出することも考えられる。
但し、食材の種別や賞味期限の事情によっては検索条件を変更することが望ましい。例えば食材グループ内で、肉や魚など、賞味期限までが短い食材が含まれている場合、必ずその食材が使用されるようなレシピに絞って抽出するという処理を行うとよい。

【0088】

最初は変数ｘ＝１であるため、レシピ管理サーバ１はまずステップＳ４０９で食材グループＧＰ１についてレシピ検索を行う。そしてステップＳ４１０で、検索結果として抽出された１又は複数のレシピを食材グループＧＰ１に対応するレシピとして特定する。

【0089】

ステップＳ４１１では変数ｘが変数ｎに達しているか否かを確認し、達していなければステップＳ４１２に進む。つまり全食材グループＧＰ１〜ＧＰｎについてレシピ特定の処理を終了していなければ、ステップＳ４１２で変数ｘをインクリメントしてステップＳ４０９に戻る。従って次に食材グループＧＰ２について同様に対応するレシピの特定を行う。
このような処理を全食材グループＧＰ１〜ＧＰｎについて実行することで、図８に示すように、各食材グループＧＰ１〜ＧＰｎにそれぞれ対応するレシピが特定されたことになる。

【0090】

変数ｘが変数ｎに達した時点で、食材グループＧＰ１〜ＧＰｎにそれぞれ対応するレシピが特定されたことになり、レシピ管理サーバ１はステップＳ４１１からＳ４１３に進んで数量条件チェックを行う。
数量条件チェックとは、例えば各食材グループＧＰ１〜ＧＰｎについて特定されたレシピの数または料理種別が、ある程度均等化されているか否かをチェックする処理である。或いは、毎回、ある程度十分な選択肢を確保できているか否かをチェックする処理としてもよい。

【0091】

本実施の形態では、ｎ回分のレシピ提供機会に分けて、推奨するレシピを提案するわけであるが、毎回、ユーザに多様なレシピを提案できると良い。例えば１回目は２０個のレシピを提案し、２回目は１個のレシピを提案するというような状態では、ユーザにとっての満足度が低下することが想定される。毎回ある程度多様なレシピを選ぶことができつつ、ｎ回先までの食事が在庫食材でまかなえるようにするものであることで、ユーザが本サービスを利用する満足度が上昇すると考えられる。
そこで、各食材グループＧＰ１〜ＧＰｎのそれぞれに対応するレシピの数や種類が、あまり偏っていないか、もしくは少なすぎる回がないかをチェックする。

【0092】

この数量条件チェックの処理例として、レシピ数又は料理種別の均等化を条件とする例を図１５Ａ、図１５Ｂで説明する。
まず図１５Ａはレシピ数が略均等であるか否かをチェックする処理例である。
図１５Ａの処理例では、レシピ管理サーバ１はステップＳ６００で食材グループＧＰ１〜ＧＰｎのそれぞれについて対応するものとされたレシピの数を、レシピ数ＮＲ１〜ＮＲｎとして取得する。
レシピ数ＮＲ１はステップＳ４１０で食材グループＧＰ１に対応するとされたレシピの数であり、図８の例でいえばＮＲ１＝５である。
レシピ数ＮＲ２はステップＳ４１０で食材グループＧＰ２に対応するとされたレシピの数であり、図８の例でいえばＮＲ１＝６である。

【0093】

次にステップＳ６０１でレシピ管理サーバ１は、条件判定のための閾値ｔｈＮＲの設定を行う。この閾値ｔｈＮＲは固定値とすることも考えられるが、可変値とすることも適切である。ここでは、食材グループＧＰ１〜ＧＰｎの数“ｎ”に応じた値に設定するものとする。例えば食材グループ数ｎが多いほど厳しい値（閾値ｔｈＮＲを小さい値）とし、食材グループ数ｎが小さい少ないほど緩い値（閾値ｔｈＮＲを大きい値）とすることが考えられる。

【0094】

次にステップＳ６０２でレシピ管理サーバ１は、レシピ数ＮＲ１〜ＮＲｎの内で、最大値を変数ＮＲｍａｘに代入し、最小値を変数ＮＲｍｉｎに代入する。そしてステップＳ６０３で、ＮＲｍａｘ−ＮＲｍｉｎの演算で差分値ΔＮＲを求める。
ステップＳ６０４でレシピ管理サーバ１は、差分値ΔＮＲを、所定の閾値ｔｈＮＲと比較する。そしてΔＮＲ≦ｔｈＲＮであれば、各回に提示するレシピ数が略均等であるためステップＳ６０５で数量条件ＯＫとし、ΔＮＲ≦ｔｈＲＮでなければステップＳ６０６で非均等であるため数量条件を満たしていないと判定する。
つまり差分値ΔＮＲが閾値ｔｈＮＲより大きい場合は、提案するレシピ数が一番多い回と一番少ない回の差が大きいため、望ましい状態ではないとする。そして各回のレシピ数の差がある程度小さければ、略均等であると判定するものである。
また食材グループ数ｎが多い場合ほど、食材の種類数の差が顕著になり、レシピ数のばらつきが多くなり、結果としてレシピ数が不均一になりやすいことが想定される。そこで上述のように閾値ｔｈＮＲを食材グループ数ｎに応じて設定することで、より均等な状況が維持されやすくするようにしている。

【0095】

なお閾値ｔｈＮＲは、対応するとされたレシピ数の総数に応じて可変とされるものとしてもよい。
例えば対応レシピ総数ＧＮＲ＝ＮＲ１＋ＮＲ２＋・・・＋ＮＲｎとし、閾値ｔｈＮＲは、ｔｈＮＲ＝（ＧＮＲ／ｎ）×ｋとする。ｋ＝０．３とすれば、１回に提示する平均レシピ数の３割を越える差がある場合に、略均等ではないと判定することになる。
もちろん閾値ｔｈＮＲは固定値でもよい。

【0096】

このようなレシピ数の均等をチェックする数量条件チェックの手法としては、他にも考えられる。例えば提示するレシピ数の平均値に対して所定以上の差がある回の有無を調べて、存在したら非均等であると判定しても良い。

【0097】

図１５Ｂは、各食材グループＧＰ１〜ＧＰｎに対応するレシピの料理種別の種類数が略均等化することを条件とする例である。
レシピ管理サーバ１は、ステップＳ６２０で料理種別のレベルを設定する。料理種別のレベルとは、例えば上述した大分類レベル、中分類レベル、細分類レベルの別である。
このステップＳ６２０での料理種別のレベルの設定は、固定的でもよいし、ユーザが指定したレベルでもよい。またユーザの嗜好に応じたレベル設定や、各食材グループＧＰ１〜ＧＰｎについて特定された対応レシピに応じたレベル設定でもよい。
固定的なレベル設定とは、ステップＳ６２０で設定されるレベルが「日本料理」「中華料理」というような大分類レベルに固定するとか、「カレー」「ハンバーグ」という中分類レベルに固定する例である。毎回、ランダムに大分類、中分類、細分類を選択するという例も考えられる。
ユーザに応じたレベル設定とは、当該処理対象としているユーザのレシピ閲覧履歴、レシピ投稿履歴などに基づいて、そのユーザに合わせたレベルを用いるとする例である。例えば多様な料理のレシピを使用したり、検索したり、投稿しているユーザについてステップＳ６２０で大分類レベル或いは中分類レベルを設定する。一方、常にカレーレシピの閲覧や投稿を行っているようなユーザに対しては「ビーフカレー」「チキンカレー」といったような、「カレー」の下の階層の細分類レベルを設定する。これによりユーザのレシピ検索の傾向に合わせた料理種別の数の判定が可能となる。
各食材グループＧＰ１〜ＧＰｎについて特定された対応レシピに応じたレベル設定とは、対応レシピとされた各レシピの料理種別の存在傾向に応じて種別レベルを設定する例である。例えば各食材グループＧＰ１〜ＧＰｎに対応するとされた全ての対応レシピにおいて大分類レベルで複数の料理種別が含まれていたら大分類レベルとしたり、中分類レベルが１種類しかなければ細分類レベルに設定するなどの例である。ユーザの食材購入傾向によっては、対応レシピが或る大分類レベルの料理（例えばベトナム料理）に偏る場合もあり、逆にそれは、そのユーザが、頻繁にベトナム料理を食べるため、それに合った食材を購入していると考えられるためである。そのような場合、ベトナム料理下での中分類レベルが料理種別のレベルとして好適となる。

【0098】

ステップＳ６２１でレシピ管理サーバ１は、食材グループＧＰ１〜ＧＰｎのそれぞれの対応レシピについて、料理種別の情報を取得する。この場合の料理種別の情報はステップＳ６２０で選択した種別レベルに相当する情報でよい。
そしてレシピ管理サーバ１はステップＳ６２２で、食材グループＧＰ１〜ＧＰｎのそれぞれに対応するものとされたレシピにおける料理種別の数をカウントし、料理種別数ＶＮＲ１〜ＶＮＲｎとする。
料理種別数ＶＮＲ１はステップＳ４１０で食材グループＧＰ１に対応するとされたレシピのグループ内の料理種別の数である。料理種別数ＶＮＲ２はステップＳ４１０で食材グループＧＰ２に対応するとされたレシピのグループ内の料理種別の数である。

【0099】

ステップＳ６２３でレシピ管理サーバ１は、条件判定のための閾値ｔｈＶＮＲの設定を行う。この閾値ｔｈＶＮＲは固定値とすることも考えられるが、可変値とすることも適切である。ここでは、食材グループＧＰ１〜ＧＰｎの数“ｎ”に応じた値に設定するものとする。例えば食材グループ数ｎが多いほど厳しい値（閾値ｔｈＶＮＲを小さい値）とし、食材グループ数ｎが小さい少ないほど緩い値（閾値ｔｈＶＮＲを大きい値）とすることが考えられる。

【0100】

次にステップＳ６２４でレシピ管理サーバ１は、料理種別数ＶＮＲ１〜ＶＮＲｎの内で、最大値を変数ＶＮＲｍａｘに代入し、最小値を変数ＶＮＲｍｉｎに代入する。そしてステップＳ６２５で、ＶＮＲｍａｘ−ＶＮＲｍｉｎの演算で差分値ΔＶＮＲを求める。
ステップＳ６２６でレシピ管理サーバ１は、差分値ΔＶＮＲを、所定の閾値ｔｈＶＮＲと比較する。そしてΔＶＮＲ≦ｔｈＶＲＮであれば、各回に提示するレシピの料理種別の種類数が略均等であるためステップＳ６２７で数量条件ＯＫとし、ΔＶＮＲ≦ｔｈＶＲＮでなければステップＳ６２８で非均等であるため数量条件を満たしていないと判定する。
つまり差分値ΔＶＮＲが閾値ｔｈＮＲより大きい場合は、１回の提案にかかるレシピの料理種別の数が一番多い回と一番少ない回の差が大きいため、望ましい状態ではないとする。そして各回のレシピの料理種別数の差がある程度小さければ、略均等であると判定するものである。
また食材グループ数ｎが多い場合ほど、料理種別数の偏りが不均一になりやすいことが想定されるため、上述のように閾値ｔｈＶＮＲを食材グループ数ｎに応じて設定することで、より均等な状況が維持されやすくするようにしている。

【0101】

なお閾値ｔｈＶＮＲは、対応するとされた全レシピにおける料理種別の種別数に応じて可変されるようにしてもよい。
例えば料理種別の数をＧＶＮＲとしたときに、閾値ｔｈＶＮＲは、ｔｈＶＮＲ＝（ＧＶＮＲ／ｎ）×ｋとする。ｋ＝０．３とすれば、１回に提示するレシピにおける料理種別の数の３割を越える差がある場合に、略均等ではないと判定することになる。
もちろん閾値ｔｈＶＮＲは固定値でもよい。

【0102】

このようなレシピの料理種別数の均等をチェックする数量条件チェックの手法としては、他にも考えられる。例えば提示するレシピの料理種別数の平均値に対して所定以上の差がある回の有無を調べて、存在したら非均等であると判定しても良い。

【0103】

次に図１６Ａの処理例は、毎回、少なくとも所定数以上のレシピの選択肢をユーザに提供できるようにする処理例である。
レシピ管理サーバ１はステップＳ６１０で食材グループＧＰ１〜ＧＰｎのそれぞれについて対応するものとされたレシピの数を、レシピ数ＮＲ１〜ＮＲｎとして取得する。

【0104】

ステップＳ６１１でレシピ管理サーバ１は、条件判定のための閾値ｔｈＮＲｍｉｎの設定を行う。この閾値ｔｈＮＲｍｉｎは固定値とすることも考えられるが、可変値とすることも適切である。ここでは、食材グループＧＰ１〜ＧＰｎの数“ｎ”に応じた値に設定するものとする。例えば食材グループ数ｎが多いほど厳しい値（閾値ｔｈＮＲｍｉｎを大きい値）とし、食材グループ数ｎが小さい少ないほど緩い値（閾値ｔｈＮＲｍｉｎを小さい値）とすることが考えられる。
ステップＳ６１２でレシピ管理サーバ１は、レシピ数ＮＲ１〜ＮＲｎの内で、最小値を変数ＮＲｍｉｎに代入する。
ステップＳ６１３でレシピ管理サーバ１は、最小値である変数ＮＲｍｉｎを、所定の閾値ｔｈＮＲｍｉｎと比較する。そしてＮＲｍｉｎ≧ｔｈＲＮｍｉｎであれば、ステップＳ６１４で数量条件ＯＫとし、ＮＲｍｉｎ≧ｔｈＲＮｍｉｎでなければステップＳ６１５で数量条件を満たしていないと判定する。
つまり１回に提示するレシピの最低数を閾値ｔｈＮＲｍｉｎとして設定し、少なくともその数以上あれば、数量条件を満たしているというものである。この場合、極端にレシピ数が多くなる場合があっても許容されてしまうが、ユーザに対して毎回、少なくともある程度の数の選択肢を用意できるという意味で、数量条件ＯＫとする。
また食材グループ数ｎが多い場合ほど、食材の種類数の差が顕著になり、レシピ数のばらつきが多くなり、結果としてレシピ数が不均一になりやすいことが想定される。そこで上述のように閾値ｔｈＮＲｍｉｎを食材グループ数ｎに応じて設定することで、より均等な状況が維持されやすくするようにしている。

【0105】

もちろん閾値ｔｈＮＲｍｉｎは固定値としてもよい。
また購入した食材の事情によって、食材グループＧＰ１〜ＧＰｎについて対応されるとされたレシピ数が少なくなっている場合、固定の閾値ｔｈＮＲｍｉｎであると、条件を満たすことができない事態が生ずることがある。そこで、各食材グループＧＰ１〜ＧＰｎについての対応レシピ数の平均値に基づいて閾値ｔｈＮＲｍｉｎを可変設定するとよい。
例えば対応レシピ総数ＧＮＲ＝ＮＲ１＋ＮＲ２＋・・・＋ＮＲｎとし、閾値ｔｈＮＲｍｉｎは、ｔｈＮＲｍｉｎ＝（ＧＮＲ／ｎ）×ｋとする。ｋ＝０．３とすれば、１回に提示するレシピ数が、平均レシピ数の３割以下の数となることが発生する場合に、数量条件を満たしていないと判定することになる。

【0106】

図１６Ｂは、各食材グループＧＰ１〜ＧＰｎに対応するレシピの料理種別の種類数が所定数以上あることを条件とする例である。
レシピ管理サーバ１は、ステップＳ６３０で料理種別のレベルを選択し、ステップＳ６３１で食材グループＧＰ１〜ＧＰｎのそれぞれの対応レシピについて、料理種別の情報を取得する。またレシピ管理サーバ１はステップＳ６３２で食材グループＧＰ１〜ＧＰｎのそれぞれについて、対応するレシピにおける料理種別の数をカウントし、料理種別数ＶＮＲ１〜ＶＮＲｎとして取得する。以上は図１５ＢのステップＳ６２１，Ｓ６２２，Ｓ６２３と同様である。
またレシピ管理サーバ１はステップＳ６３３で条件判定のための閾値ｔｈＶＮＲｍｉｎの設定を行う。ここでは、食材グループＧＰ１〜ＧＰｎの数“ｎ”に応じた値に設定するものとする。例えば食材グループ数ｎが多いほど厳しい値（閾値ｔｈＶＮＲｍｉｎを大きい値）とし、食材グループ数ｎが小さい少ないほど緩い値（閾値ｔｈＶＮＲｍｉｎを小さい値）とすることが考えられる。

【0107】

ステップＳ６３４でレシピ管理サーバ１は、料理種別数ＶＮＲ１〜ＶＮＲｎの内で、最小値を変数ＶＮＲｍｉｎに代入する。
ステップＳ６３５でレシピ管理サーバ１は、最小値である変数ＶＮＲｍｉｎを、所定の閾値ｔｈＶＮＲｍｉｎと比較する。そしてＶＮＲｍｉｎ≧ｔｈＶＲＮｍｉｎであれば、ステップＳ６３６で数量条件ＯＫとし、ＶＮＲｍｉｎ≧ｔｈＶＲＮｍｉｎでなければステップＳ６３７で数量条件を満たしていないと判定する。
つまり１回に提示するレシピの料理種別の最低数を閾値ｔｈＶＮＲｍｉｎとして設定し、少なくともその数以上あれば、数量条件を満たしているというものである。このため、ユーザに対して毎回、少なくともある程度の数以上の料理種別の選択肢を用意できるという意味で、数量条件ＯＫとする。
また食材グループ数ｎが多い場合ほど、料理種別数が不均一になりやすいことが想定されるため、上述のように閾値ｔｈＶＮＲを食材グループ数ｎに応じて設定することで、より均等な状況が維持されやすくするようにしている。

【0108】

この場合閾値ｔｈＮＲｍｉｎは固定値としてよい。但し、購入した食材の事情によって、食材グループＧＰ１〜ＧＰｎに対応されるレシピにおける料理種別の数が少なくなっている場合、固定の閾値ｔｈＶＮＲｍｉｎであると、条件を満たすことができない事態が生ずることがある。そこで、各食材グループＧＰ１〜ＧＰｎについての料理種別数の平均値に基づいて閾値ｔｈＶＮＲｍｉｎを可変設定するとよい。
例えば対応するレシピ全体での料理種別の数をＧＶＮＲとしたときに、閾値ｔｈＶＮＲは、ｔｈＶＮＲ＝（ＧＶＮＲ／ｎ）×ｋとする。ｋ＝０．３とすれば、１回に提示するレシピにおける料理種別の数が平均値の３割未満の回があるときに、数量条件を満たしていないと判定することになる。

【0109】

図１１に戻って、ステップＳ４１３で以上のような数量条件チェックが行われたら、レシピ管理サーバ１はステップＳ４１４で、数量条件を満足したか否かで処理を分岐する。
数量条件を満足していたら、今回の設定、つまり食材グループＧＰ１〜ＧＰｎ及びそれぞれの対応レシピの設定を確定され、ステップＳ４１６で提示設定ＤＢ５６に記憶する。つまり、或るユーザに対して、今後ｎ回の料理機会に推奨提示するレシピが決まったことになる。
ところが、数量条件が充足していないと判定されたときは、レシピ管理サーバ１はステップＳ４１４からＳ４１５に進み、振り分け条件等を変更したうえで、ステップＳ４０７からの処理をやりなおす。例えば食材グループＧＰ１〜ＧＰｎの生成のための振り分け処理のアルゴリズムを、前回使用したものとは別のアルゴリズムを選択してステップＳ４０７の処理を行う。
或いは、このステップＳ４１５の際に、振り分ける食材の最小分量、振り分け単位の選択、振り分ける順序が優先される食材の設定などを変更してもよい。特にはステップＳ４０４で行った食材の振り分け単位の設定を新たにやり直したり調整することが考えられる。例えば対応するレシピの数が少ない食材グループについて、割り当てる食材の分量を増加し、その分を他の食材グループから引くことが考えられる。もちろん減少させる食材グループは、対応するレシピ数が多かったレシピであることが望ましい。

【0110】

このような図１１の提示設定処理は、一人のユーザに対して、今後ｎ回の料理機会にそれぞれ提案する推奨レシピを設定するが、それら提示されるレシピの数や料理種別のバリエーションが、ある程度充実するように、推奨提示するレシピの設定が行われる。

【0111】

この図１１のような提示設定処理が図１０のステップＳ３０５で行われることで、現在処理対象のユーザについての推奨レシピの提示設定が完了し、提示設定ＤＢに登録される。
レシピ管理サーバ１は図１０のステップＳ３０６で未処理の残りのユーザの有無を確認し、残りのユーザが存在すればステップＳ３０１に戻って、次のユーザに対して同様の処理を行う。従って、レシピ管理サーバ１が提供する本例のサービスを受けるユーザについて、有効な提示設定が存在しなければ提示設定が行われ、サービスを受けることができるようにされる。

【0112】

以上の図１０〜図１６で説明した処理がバッチ処理で行われて、提示設定ＤＢに提示設定が登録された状態となったユーザに対しては、図７で示したユーザ端末３とレシピ管理サーバ１のやりとりで、推奨レシピ提示が行われることになる。
図７の処理を実現するためのレシピ管理サーバ１の処理を図１７に示す。レシピ管理サーバ１は主に図２に示した提示制御部１ｅ、レシピ管理部１ｆの機能により図１７の処理を実行する。

【0113】

レシピ管理サーバ１は、ステップＳ７０１，Ｓ７１１，Ｓ７２１を順に実行することにより、各種処理を継続的に行う。
具体的には、ステップＳ７０１においてログイン情報を受信したか否かを判定する処理を実行し、ステップＳ７１１においてウェブページデータの要求を受信したか否かを判定する処理を実行し、ステップＳ７２１で使用推定情報を受信したか否かを判定する処理を実行する。
なお、これら以外にもレシピ管理サーバ１では、作成レポートの投稿やレシピの投稿を受信した場合の処理、レシピ検索条件を受信したときのレシピ検索処理等も行われるが、本実施の形態に直接関係しないため、それらの処理についての記載は省略している。

【0114】

ログイン情報は、ユーザがユーザ端末３を用いてログイン操作を行った場合に、ユーザ端末３からレシピ管理サーバ１へ送信される。
ステップＳ７０１において、ログイン情報を受信したと判定した場合、レシピ管理サーバ１はステップＳ７０２において認証処理を実行し、ステップＳ７０３において認証結果をユーザ端末３に通知する処理を実行する。
認証処理においては、ユーザ端末３から送られたログイン情報とユーザＤＢ５１に記憶されたユーザ情報（例えば、ユーザＩＤとログインパスワード）を照合し、ログインの可否を決定する。

【0115】

レシピ管理サーバ１は、認証ＯＫでなければ、ステップＳ７０１，Ｄ７１１，Ｓ７２１のループに戻るが、認証ＯＫであれば、そのユーザのユーザ端末３においてレシピサイトのトップページ送信を行う。例えばこの場合に、当該ユーザに対して今回の推奨レシピ提示を行う。
まずレシピ管理サーバ１はステップＳ７０４で、ログインユーザの提示設定の情報を提示設定ＤＢ５６から取得する。そしてステップＳ７０５で、今回の提示が何回目か、もしくは現在の日時に基づいて、今回提示すべきレシピを特定する。
ステップＳ７０６でレシピ管理サーバ１は、今回推奨提示するレシピを含むトップページデータを生成し、ステップＳ７０７でそのトップページデータをユーザ端末３に送信する。これにより図７のステップＳ２０６で説明したように、ユーザ端末３において今回の推奨レシピが例えば図９Ａや図９Ｂのように提示される。

【0116】

レシピ管理サーバ１は、ステップＳ７１１においては、ウェブページデータ要求を受信したか否かを判定する処理を実行する。
ウェブページデータ要求を受信したと判定した場合、レシピ管理サーバ１はステップＳ７１２において、要求のあったウェブページデータをＤＢから取得する処理を実行する。具体的には、ユーザページのウェブページデータや、レシピ詳細ページのウェブページデータや、特集ページのウェブページデータなどを取得する。
続いて、レシピ管理サーバ１はステップＳ７１３において、当該ウェブページデータをユーザ端末３へ送信する処理を実行する。これにより、ユーザ端末３上にユーザが所望したウェブページが表示される。

【0117】

レシピ管理サーバ１はステップＳ７２１において使用推定情報を取得した場合は、ステップＳ７２３で、提示設定ＤＢ５６に推定情報又は使用レシピの記憶を行う。
上述のように、例えば詳細ページのリクエストや、プリント操作の情報、あるいは詳細ページの閲覧時間の情報などは、使用したレシピを特定するための推定情報となる。これらの情報を取得した場合、提示設定ＤＢ５６におけるログインユーザの今回のレシピ提示に対応する推定情報として記憶する。
また推定情報を取得したことに応じて、ステップＳ７２４で使用レシピの推定を行う。推定手法は上述したとおりである。そして使用レシピの推定確度が高いと判定できた場合は、そのレシピに含まれる食材の情報や使用日時を使用データとして格納履歴ＤＢ５３に記憶する。
なお、必ずしもユーザは推奨提示したレシピを使用するわけではない。推奨提示とは全く別のレシピをユーザが検索してしようする場合もある。ステップＳ７２４では、使用推定情報から、他のレシピが推定された場合も、そのレシピで用いられる食材が使用されたと推定し、食材の使用データとして格納履歴ＤＢ５３に記憶させればよい。
また、推定情報ではなく、ユーザが、自分が使用したレシピを示す情報をレシピ管理サーバ１に送信できるようにしてもよい。例えば詳細ページの閲覧時に、「このレシピで料理を始めますか？」というような質問を表示し、ユーザにイエス・ノーの回答を入力させてもよい。そのような回答情報も、推定情報と同様に扱って、推定情報の記憶や使用データの記憶を行うことが適切である。
なおレシピ管理サーバ１はステップＳ７２４の時点で、推定した使用レシピ自体を示す情報を、例えば推定情報に対応させて提示設定ＤＢ５６に記憶させるようにしてもよい。

【0118】

以上の処理によれば、ログインユーザに対して、その日時に応じて、これから開始する料理の推奨レシピが、複数、提示されることになる。それらは毎回、ユーザが購入した食材で料理可能なものとなる。

【0119】

＜６．第２の実施の形態＞
第２の実施の形態について説明する。
なお、以降第２、第３の実施の形態の説明においては、第１の実施の形態と異なる処理についてのみ説明する。言及していない処理については第１の実施の形態と同様である。

【0120】

図１８は第２の実施の形態の提示設定処理を示している。つまり図１０のステップＳ３０５で行われる処理例である。
図１１と同一処理は同一のステップ番号を付し、重複説明を避ける。図１８において図１１と異なるのは、ステップＳ４２０，Ｓ４２１の処理である。

【0121】

ステップＳ４１３での数量条件チェックにおいて数量条件を満たさないと判定された場合は、レシピ管理サーバ１はステップＳ４２０で、レシピ自体として食材の分量を変更可能なレシピが存在するか否かを判定する。例えばレシピ管理サーバ１は、レシピに含まれる或る食材の分量を多少減らしても調理可能であるレシピが存在するか否かを判定する。
レシピＤＢ５０に登録されている各レシピについては、予め、分量を変更できる食材を設定しておく。例えばレシピ作成者に依頼し、材料不足の場合の分量などとして、分量の異なる情報を送信してもらい、それを取得して登録しておくようにしてもよい。

【0122】

そしてレシピＤＢ５０に分量変更可能なレシピが存在しなければ、レシピ管理サーバ１はステップＳ４２０からＳ４１５に進む。つまり第１の実施の形態と同様に、振り分け条件を変更して食材グループＧＰ１〜ＧＰｎの再設定からやり直す。
一方、分量変更可能なレシピが存在すれば、ステップＳ４２１で、その分量変更後のレシピを対象とするようにレシピ検索設定を変更する。そしてステップＳ４０８以降の処理で、各食材グループＧＰ１〜ＧＰｎのそれぞれに対応するレシピを、分量設定を変更したレシピを対象として行う。
これにより、食材グループに対応するものとして抽出できるレシピの数を増加させることが期待できる。
従ってこの処理で対応レシピを特定したら、ステップＳ４１３の数量条件チェックでＯＫとなる可能性が得られる。

【0123】

このように第２の実施の形態では、数量条件を満たせなくなる場合に、レシピに設定されている食材の分量を変更することで、数量条件を満たすか否かを試行するものである。

【0124】

＜７．第３の実施の形態＞
第３の実施の形態のレシピ管理サーバ１の処理を図１９、図２０で説明する。なお図１９において図１０と同一の処理は同一のステップ番号を付し説明を省略する。
図１９は、図１０の処理にステップＳ３１０，Ｓ３１１を加えたものである。
図１０の例では、現在有効な提示設定が存在するユーザについては、提示設定処理をスキップしたが、図１９の例では、このようなユーザについてステップＳ３１０の確認を行う。

【0125】

即ちレシピ管理サーバはステップＳ３１０で、処理対象となっているユーザに対して、初回の推奨レシピ提示をすでに終えているか否か、又は格納履歴ＤＢ５３の情報を参照して、追加食材があるか否かを確認する。

【0126】

すでに１回以上、推奨レシピの提示を行ったユーザでは、使用レシピによっては、その食材グループのうちで使われなかった食材がある可能性がある。例えば食材グループＧＰ１に対応するレシピは、全てが食材グループＧＰ１の食材を全て使い切るレシピではなく、食材グループＧＰ１の食材で調理可能なレシピが選ばれているためである。
また、ユーザが不定期に食材を購入した場合に、追加食材の情報を取得できる場合もある。
つまり提示設定が有効な期間も、新たに使用すべき食材が発生する。そこで図１９の例では、そのような場合にステップＳ３１１で再提示設定処理を行うようにしている。
再提示設定処理とは、先にステップＳ３０５で行った提示設定処理で特定された推奨レシピの情報は有効としたまま、追加のレシピを特定する処理である。

【0127】

再提示設定処理を図２０に示す。
レシピ管理サーバ１はステップＳ８０１で、処理対象のユーザの格納履歴ＤＢ５３を参照して、追加食材の有無を判定する。即ち先にステップＳ３０５で提示設定処理を行った後の時点において購入した食材の情報である。
レシピ管理サーバ１は、そのような食材が存在する場合はステップＳ８０２で、その食材の種類や量を追加食材情報として取得する。

【0128】

ステップＳ８０３でレシピ管理サーバ１は、現時点で初回の推奨レシピの提示が終えているか、つまり食材グループＧＰ１に対応するレシピの提示は過去に行い、現在は、次に、食材グループＧＰ２〜ＧＰｎのいずれかの対応レシピを提示する時点であるか否かを判定する。
１回以上でも推奨レシピの提示が行われていたら、その提示の際の実際の使用レシピによって、その食材グループにおける余った食材が存在する可能性がある。
そこで初回提示済みであればレシピ管理サーバ１はステップＳ８０４で、まず格納履歴ＤＢ５３を参照して、それまでの使用食材を特定する。つまり食材の使用データとして該当する日時のデータを抽出する。
ステップＳ８０５でレシピ管理サーバ１は、抽出した使用データから食材毎の使用量を算出する。
そしてステップＳ８０６でレシピ管理サーバ１は、食材毎の使用量と、対応する食材グループに元々振り分けられた食材及び量の情報を用いて、対応レシピ既提示の食材グループに振り分けられた食材のうちで、余った食材の種類と量を算出する。

【0129】

ステップＳ８０７でレシピ管理サーバ１は、次回、対応レシピを提示する食材グループのナンバを変数ｘに代入する。例えば現在が、食材グループＧＰ１、ＧＰ２までの対応レシピを提示済みであって、次回は３回目の提示であるなら、ｘ＝３とする。
そしてステップＳ８０８で、食材グループＧＰ（ｘ）〜ＧＰｎ（なおｘ＝ｎの場合もある）に、残り食材や追加食材を振り分ける処理を行う。

【0130】

今後の提示にかかる食材グループＧＰ（ｘ）〜ＧＰｎに食材を追加したら、続いてレシピ管理サーバ１はステップＳ８０９〜Ｓ８１２により、各食材グループＧＰ（ｘ）〜ＧＰｎに対応するレシピを特定する処理を行う。
即ちレシピ管理サーバ１はステップＳ８０９で、食材グループＧＰ（ｘ）についてレシピ検索を行う。これは食材グループＧＰ（ｘ）に、最初の提示設定処理で割り当てられた食材と、今回追加的に割り当てられた食材を含めて検索キーとして、レシピＤＢ５０を検索し、その食材の範囲で調理が可能なレシピを抽出する処理となる。
そしてステップＳ８１０で、食材グループＧＰ（ｘ）の追加レシピを特定する。この場合、食材が増えることで、最初の提示設定の際のレシピを含んで、追加的に該当するレシピが抽出されることが予想される。従って、追加レシピとは、今回抽出されたレシピの中で、最初の提示設定時に抽出された中に含まれていないレシピとなる。

【0131】

レシピ管理サーバ１はステップＳ８１１で変数ｘ＝ｎとなるまで、ステップＳ８１２で変数ｘをインクリメントしながら、ステップＳ８０９、Ｓ８１０を行う。従って、今後の時点で対応レシピを提示する食材グループについて、対応レシピが追加されていくことになる。
食材グループＧＰｎについてまでの処理を終えたら、ステップＳ８１３に進み、提示設定ＤＢ５６の内容を更新する。つまり今後の時点で対応レシピを提示する食材グループについて、対応レシピを追加する記憶を行う。
従って上述の図１７の処理で推奨レシピの提示が行われる場合、残りの食材や追加購入した食材が考慮されて推奨レシピが提示されることになる。

【0132】

なお、この再提示設定の際には、数量条件チェックは不要としてもよいし、この場合も数量条件チェックを実行してもよい。
例えば図１６のような最低数の選択肢を提供するという考え方に則れば、すでに数量条件チェックは満たされているため、例えば図２０の処理で行う必要は無い。
一方、図１５のような均一性を考慮する場合、残りの回で、レシピ数や料理種別数の均一性を保つようにするのであれば、図１５Ａ又は図１５Ｂのような処理で数量条件チェックを行い、満たされなければステップＳ８０８からやり直すことも考えられる。
もちろん、一旦均一性が確保されていることを考えれば、追加レシピによって多少均一性が崩れてもよしとする考え方もあるため、数量条件チェックを行なわなくてもよい。
再提示設定処理の際には数量条件チェックを省くことで、レシピ管理サーバ１の処理負担を削減できる。

【0133】

＜８．まとめ＞
以上、実施の形態について説明してきたが、実施の形態では以下の効果が得られる。
第１〜第３の実施の形態のレシピ管理サーバ１（情報処理装置）は、食材の格納履歴を記憶する記憶装置（格納履歴ＤＢ５３）から少なくとも在庫情報を含む食材の情報を取得する食材情報取得部１ａ（図１１のＳ４０１参照）を備える。またレシピ管理サーバ１は、格納履歴ＤＢ５３に記憶された格納履歴に基づいて判定された食材が追加される周期に応じてレシピ提供回数を特定する提供回数特定部１ｂ（Ｓ４０２，Ｓ４０３参照）と、取得した食材の情報と特定されたレシピ提供回数に基づいて、当該食材の情報に含まれる各食材を、当該レシピ提供回数に応じた数の食材グループＧＰ１〜ＧＰｎに振り分ける食材グループ設定部１ｃ（Ｓ４０７参照）と、食材グループＧＰ１〜ＧＰｎ毎に、振り分けられた食材に基づいてレシピを特定するレシピ特定部１ｄ（Ｓ４０８〜Ｓ４１２参照）を備える。さらにレシピ管理サーバ１は、食材グループＧＰ１〜ＧＰｎ毎に特定されたレシピの提示制御を行う提示制御部１ｅ（図１７のＳ７０４〜Ｓ７０７参照）を備える。そして食材グループ設定部１ｃは、レシピ特定部１ｄが各食材グループについて特定するレシピの数または料理種別が所定の数量条件を満たすように食材の振り分けを行う（図１１のＳ４１３、Ｓ４１４、Ｓ４１５等参照）。

【0134】

例えばユーザが一週間に一度、食材をまとめて購入することなどを想定する。この購入した食材を、レシピ提供回数（例えば一週間の毎日の夕食用とすると７回）に振り分けて食材グループＧＰ１〜ＧＰｎを設定する。そして食材グループＧＰ１〜ＧＰｎ毎に、その食材グループ内の食材で調理可能なレシピを特定する。そして食材グループ毎、例えば毎日の夕食毎に、いくつかのレシピをユーザに提示する。

【0135】

これにより、食材を必要な回数に振り分けた上で、毎回の食事について適切（つまり現在ある食材で調理可能）なレシピがユーザに提供されることになる。ユーザにとっては、毎回提示されるレシピのうちで任意のレシピを選択して料理をおこなっていけば、例えば１週間分などとしてまとめて購入した食材を、うまく毎日の食事に振り分けて利用できることになる。従って、ユーザは食材の配分を気にしていなくてもよい。

【0136】

また、毎回の食事毎に予め配分された食材で提示されるレシピが特定されるため、毎回多様なレシピが提供される。特にレシピの数または種別が数量条件を満たすような食材グループ設定が行われることで、毎回提示されるレシピの数、或いは料理種別の種類の数が、適度に多く、バリエーションに富んだものにできる。このためユーザの選択肢が豊富で満足度の高いレシピ提供サービスを実現できる。
そして毎回ある程度多様なレシピを選ぶことができつつ、ｎ回先までの食事を在庫の食材でまかなえることで、ユーザが本サービスを利用する満足度が上昇する。
特にインターネット通販による定期購入、生活協同組合による一括購入、生鮮食料品配達サービスを利用した購入、週一でのマーケットでの大量購入などを実行しているユーザにとって好適である。

【0137】

またユーザが短時間で容易に望みのレシピを発見できるような使用性の良いレシピ提供システムを実現できる。現状で調理可能なレシピが充実した選択肢で提示されるためである。
またこれによって、検索のし直しなども減少することが見込まれるため、ネットワークシステムでの総通信量の削減や、それによる通信トラフィックの有効利用を促進できる。
更に、ユーザの利用するユーザ端末３における限られた（例えば、モニタなどの）提示領域において、価値のある情報（レシピ）を提示することにより、ユーザ端末３の資源を有効活用することができる。

【0138】

実施の形態では、食材グループＧＰ１〜ＧＰｎの設定に関し、取得した食材の情報に含まれる食材毎の汎用性を示す情報を取得し、取得した汎用性を示す情報で示される値が相対的に高い食材が異なる食材グループに振り分けられるように食材グループを設定する例を示した（図１３，図１４参照）。
ある食材グループに汎用性が高い食材ばかり集められると、その食材グループについては対応するレシピ数が多くなるが、他の食材グループでは対応するレシピ数が少なくなってしまうことが想定される。そこで、汎用性が高い食材があるグループに集中しないようにする。これにより、各食材グループに対応するレシピの数や種類をある程度均等化でき、毎回の提示の際のユーザの選択肢を確保しやすくなる。
またこのアルゴリズムを用いて食材グループＧＰ１〜ＧＰｎの設定を行うことで、数量条件をクリアできる可能性も高くなり、設定のやり直しが減少することが見込まれる。従ってレシピ管理サーバ１の処理負担も低減できる。

【0139】

実施の形態では、食材を分量単位で各食材グループＧＰ１〜ＧＰｎに振り分けて食材グループＧＰ１〜ＧＰｎを設定する例を述べた（図８、図１２Ｂ参照）。
これにより、各食材グループＧＰ１〜ＧＰｎにおいて共通の食材を用いたレシピも対応可能であり、各食材グループＧＰ１〜ＧＰｎに対応するレシピの数や料理種別数を確保しやすいものとすることができる。
また実施の形態としての図１１の処理では、食材を、食材毎に設定された分量単位で各食材グループに振り分けたことにより数量条件を満たせなくなる場合は、各食材グループに振り分ける食材の分量の調整を行う例を述べた（Ｓ４１５）。
これは１つの食材を特定の分量毎に振り分けると、場合によっては対応するレシピ数が極端に減少してしまうこともあるため、数量条件を満たすように振り分ける分量を調整するものである。これにより、１つの食材を柔軟に各食材グループに振り分け、もって各食材グループに対応するレシピの数や料理種別数を確保しやすいものとすることができる。

【0140】

また第２の実施の形態としての図１８の処理では、食材を分量単位で各食材グループＧＰ１〜ＧＰｎに振り分けたことにより数量条件を満たせなくなる場合において、レシピに設定されている食材の分量を変更することで、数量条件を満たすか否かを確認するようにしている（Ｓ４２０，Ｓ４２１参照）。
食材の分量が足りなくて、あるレシピがある食材グループに対応できないとされる場合がある。その場合に、そのレシピに設定されている分量を変更することで、当該レシピを食材グループに対応するレシピとすることができる。
これにより、１つの食材グループに対応するレシピの数や料理種別数を確保しやすいものとすることができる。
またこの手法で数量条件をクリアできる場合、食材グループＧＰ１〜ＧＰｎについての設定はやり直さなくてよいためレシピ管理サーバ１の処理負担が軽減される。

【0141】

実施の形態では、各食材グループに対応したレシピを特定した後において、追加可能な食材の情報を取得した場合、食材の再割り当て、再割り当ての状態での追加レシピの特定、及び追加レシピを追加した状態でのレシピの提示制御を行う例を挙げた。
即ち第３の実施の形態においては、各食材グループＧＰ１〜ＧＰｎに対応したレシピを特定した後において、２回目以降のレシピ提供の際には、前回以前のレシピ提供にかかる余剰食材の再割り当てをおこない、再割り当ての状態で追加レシピを特定する（図１９のＳ３１１参照）。そして追加レシピを追加した状態でのレシピの提示制御を行う。
例えば１回目の提示は、１回目として１回目用の食材グループＧＰ１とされた食材で調理可能なレシピが提示される。しかし、ユーザがその中でどのレシピを選択して料理を行うかに応じて余剰食材が生ずる。そこで２回目以降の提示の時点では、余剰食材を残りの各食材グループＧＰ２〜ＧＰｎに振り分けた上で、調理可能なレシピを特定し、これを追加レシピとして提示する。
これにより、２回目以降のレシピ提示の際には、それまでに余った食材が有効利用されて多様なレシピが表示できる。ユーザの選択によっては、余剰食材を有効利用できることになる。またユーザにとっては、なるべく余剰食材を生じないようなレシピ選択の機会が与えられる。
また、この第３の実施の形態においては、食材の追加情報を取得した場合も追加食材の再割り当てをおこない、再割り当ての状態で追加レシピを特定する（図１９のＳ３１１参照）。そして追加レシピを追加した状態でのレシピの提示制御を行う。
例えば１週間分の食材の割り当てとレシピの特定を行った後に、食材が追加された場合、以降のレシピ提示としては、追加食材を反映させたレシピも追加提示されるようにする。
これにより追加食材が有効利用されて多様なレシピが表示できる。

【0142】

実施の形態では、数量条件として、各食材グループＧＰ１〜ＧＰｎについて特定されたレシピ数の差、又は各食材グループＧＰ１〜ＧＰｎについて特定されたレシピにおける料理種別の数の差が所定範囲内とする例を述べた（図１５Ａ、図１５Ｂ参照）。
これにより毎回提示するレシピのうち、あるときだけ極端にレシピ数が少なくなってしまったり、あるときは過大となるような不均一な状態を避けられ、安定した数の選択肢をユーザに提供できる。
ここで、各食材グループＧＰ１〜ＧＰｎについて特定されたレシピ数又は各食材グループについて特定されたレシピにおける料理種別の数の偏りについての数量条件が、食材グループの数に応じて設定されるものとした（図１５ＡのＳ６０１，図１５ＢのＳ６２３参照）。
例えば食材グループ数が多いほど、条件を厳しくすることで、不均一な状態を避け、安定した数の選択肢をユーザに提供できる状態を維持できる。

【0143】

なお、食材が余ること自体は、本実施の形態では問題としていない。つまり余ってもよい。例えば結果的に一週間後に余った食材が存在しても、それは次の提示設定に反映させればよいためである。また余った食材はユーザが自由に使用すればよいためでもある。本実施の形態は、ある複数回の調理機会において、それぞれ食材を分配し、バリエーション豊かなレシピを提案することを主眼としている。従って、第３の実施の形態のような追加レシピ設定を行わない第１の実施の形態も十分に有効である。

【0144】

また実施の形態では、数量条件として、各食材グループＧＰ１〜ＧＰｎについて特定されたレシピの数、又は各食材グループＧＰ１〜ＧＰｎについて特定されたレシピにおける料理種別の数が、所定の最小値以上であるとする例を述べた（図１６Ａ、図１６Ｂ参照）。
これにより毎回提示するレシピのうち、あるときだけ極端に少ないレシピ数や料理種別数で提示が行われることを避けられ、毎回十分な選択肢をユーザに提供できる。
ここで、各食材グループＧＰ１〜ＧＰｎについて特定されたレシピ数又は各食材グループについて特定されたレシピにおける料理種別の数の最小値としての数量条件が、食材グループの数に応じて設定されるものとした（図１６ＡのＳ６１１，図１６ＢのＳ６２３参照）。
例えば食材グループ数が多いほど、最小値の条件を厳しくすることで、不均一な状態を避け、安定した数の選択肢をユーザに提供できる状態を維持できる。

【0145】

なお本発明の情報処理装置の構成や処理は上記実施の形態で言及した物に限定されず、さらに多様な変形例が想定される。
毎回提供する推奨レシピとしては、例えば主菜のみとしたり、或いは、主菜、副菜のセット、さらには１食分の全てのセットとして複数レシピの組で提示してもよい。例えばメインディッシュのレシピ、スープのレシピ、サラダのレシピを１組の推奨レシピとしてもよい。

【0146】

実施の形態では、毎回の提示機会にユーザに対して、その回の推奨レシピの提示を行う例としたが、例えば残りの回の全てをユーザが閲覧できるようにしてもよい。
例えばあるユーザについて１週間分の推奨レシピを特定したら、そのユーザがレシピサイトを訪問した際に、その１週間分の推奨レシピを提示する。これによってユーザは献立の計画を立てやすくなる。

【0147】

また実施の形態では言及していないが、複数人分のレシピ設定を予め入力することで、
それに応じて食材グループ設定、レシピ特定が行われることは当然に考えられる。
例えば家族４人のユーザに対しては、食材グループＧＰ１〜ＧＰｎの食材は、それぞれ４人分の食材ということで調理可能なレシピ検索が行われればよい。

【0148】

図１０〜図１６で説明した処理は、必ずしもバッチ処理でおこなわれるようにする必要は無い。上記処理が十分に高速に実現できるのであれば、ユーザがログインしたときに、そのログインユーザについて図１０の処理を行い、必要に応じて提示設定処理を行うようにすることもできる。

【0149】

推奨レシピを提示するのはレシピサイトのトップページでなくてもよい。
その場合、ユーザ端末３からの推奨レシピの提示の要求に応じてレシピ管理サーバ１は図１７のステップＳ７０４〜Ｓ７０７の処理を行えばよい。

【0150】

実施の形態では、食材情報を格納履歴ＤＢ５３で把握できる実際の追加の履歴から取得するものとしたが、食材追加の推定を行って未来の時点での追加食材情報を取得することも考えられる。
例えば過去の食材情報の格納履歴に基づいて、ある時点での追加量を推定することができる。
また食材の残余の量に基づいて追加量を推定することもできる。
またまだ購入前であるが生活協同組合やネットスーパーなどの注文情報に基づいて、未来のある時点での食材追加量を特定することもできる。
このような食材の追加の推定に基づいて、未来の時点での提示設定を行ったり、再提示設定を行って推奨レシピを追加することもできる。
また食材の追加可能性を、例えば食材の残余の量に基づいて推定したり、食材の現在価格に基づいて推定することもできる。特にユーザ毎の購入価格の相場を判定し、それを考慮して、ある食材が安くなったら、そろそろ購入しそうだという推定を行い、それを提示設定処理や再提示設定処理で反映させてもよい。

【0151】

＜９．プログラム及び記憶媒体＞
本発明の実施の形態のプログラムは、レシピ管理サーバ１における食材情報取得部１ａ、提供回数特定部１ｂ、食材グループ設定部１ｃ、レシピ特定部１ｄ、提示制御部１ｅの機能による処理を情報処理装置（ＣＰＵ等）に実行させるプログラムである。

【0152】

実施の形態のプログラムは、食材の格納履歴を記憶する記憶装置から所定の条件を満たす食材の情報を取得する食材情報取得手順（Ｓ４０１）と、記憶装置（格納履歴ＤＢ５３）に記憶された格納履歴に基づいて、食材が追加される周期を判定し、判定した周期に基づいてレシピ提供回数を特定する提供回数特定手順（Ｓ４０２，Ｓ４０３）と、食材情報取得手順で取得した食材の情報に含まれる各食材を振り分けて、レシピ提供回数に応じた数の食材グループＧＰ１〜ＧＰｎを設定する食材グループ設定手順（Ｓ４０７）と、食材グループ毎に、割り当てられた食材に基づいてレシピを特定するレシピ特定手順（Ｓ４１０）と、食材グループＧＰ１〜ＧＰｎ毎に特定されたレシピの提示制御を行う提示制御手順（Ｓ７０４〜Ｓ７０７）とを情報処理装置に実行させる。さらに、食材グループ設定手順では、レシピ特定手順で各食材グループについて特定するレシピの数または料理種別が所定の数量条件を満たすことになる食材の振り分けを情報処理装置に実行させる（Ｓ４０７〜Ｓ４１５）。

【0153】

このようなプログラムにより、上述したレシピ管理サーバ１はとしての情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置等の機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭ等に予め記憶しておくことができる。あるいはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的あるいは永続的に格納（記憶）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。

【符号の説明】

【0154】

１ レシピ管理サーバ、１ａ 食材情報取得部、１ｂ 提供回数特定部、１ｃ 食材グループ設定部、１ｄ レシピ特定部、１ｅ 提示制御部、１ｆ レシピ管理部、２ ネットワーク、３ ユーザ端末、４ ＥＣサーバ、５０ レシピＤＢ、５１ ユーザＤＢ、５２ 検索ＤＢ、５３，５３Ａ 格納履歴ＤＢ、５４ 商品ＤＢ、５５ 食材ＤＢ、５６ 提示設定ＤＢ

【要約】

食材をユーザの複数回の食事に振り分けるとともに、毎回、ユーザに対して多様なレシピの提案ができるようにする。そこで食材の格納履歴を記憶する記憶装置から所定の条件を満たす食材の情報を取得し、食材が追加される周期を判定し、判定した周期に基づいてレシピ提供回数を特定する。そして取得した食材の情報に含まれる各食材を振り分けて、レシピ提供回数に応じた数の食材グループを設定する。この食材グループ毎に、割り当てられた食材に基づいてレシピを特定し、レシピの提示制御を行う。この場合に、各食材グループについて特定されるレシピの数または料理種別が所定の数量条件を満たすことになるように食材の振り分けを行うようにする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】