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

Abstract

ユーザに対して充実したレシピ提示を行いたい。このために選択された食材を示す食材情報を取得し、取得した食材情報で示される食材により作成可能なレシピを第１レシピとして抽出する。また取得した食材情報で示される食材と追加食材により作成可能なレシピを第２レシピとして抽出する。そして第２レシピのうちで、少なくとも第１レシピに含まれないという条件を含む選定条件に合致するレシピを第３レシピとして選定する。第１レシピと第３レシピとについて提示制御を行う。

Description

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

特開２００６−２７７４１０号公報 特開２０１０−２１１７４７号公報

一般のユーザ（レシピ提供者）の投稿などによって蓄積された料理のレシピを提供するサービスが知られている。
特許文献１には、ユーザが入力した手元にある食材に基づいてレシピで使用する一部の食材を代替食材に置換して作成可能なレシピを提供する技術について記載されている。
特許文献２には、ユーザに対して先に提案したメイン料理のレシピにおけるメイン食材と被らない食材を利用したサブ料理のレシピを提供する技術について記載されている。

ところでレシピ提供サービスでは、レシピ閲覧を求めるユーザ（レシピ利用者）に対して提供されるレシピ、つまりユーザが作る料理を選ぼうとしている際に選択可能なレシピとして、十分な数の選択肢を提供できていない場合がある。
また、該ユーザが入力していない食材をあまり多く使うレシピはユーザにとって参考とならない蓋然性が高い。

特許文献１に記載の技術は「ユーザが入力した食材のみで作成可能なレシピを提供する」ものであり、提示されるレシピは入力した食材の範囲に比例するため提供されるレシピの種類は限定的となる。また提供されるレシピの種類を増やすためには多数の食材を入力する必要がありユーザ（レシピ利用者）にとって煩雑である。
特許文献２に記載の技術は「レシピを再検索する際に先に入力した食材から選択されたメイン料理と同種の料理が提案されないために、メイン料理におけるメイン食材を特定して当該メイン食材とかぶらない食材を利用したサブ料理のレシピを提供する」ものであり、提示されるメイン料理のレシピとサブ料理のレシピの組み合わせが同系統の料理のレシピとなることは避けられる。しかし特許文献１と同様に提示されるレシピは入力した食材の範囲に比例するため、提供されるレシピの種類は限定的となる。

そこで本発明は、レシピ閲覧を求めるユーザ（レシピ利用者）に対して追加となる食材を抑制しつつ十分な数量のレシピの選択肢を提供可能とするサービスを実現することを目的とする。

本発明に係る情報処理装置は、選択された食材を示す食材情報を取得する食材情報取得部と、前記食材情報取得部が取得した食材情報に基づいて提示レシピを選択する提示レシピ選択部と、前記提示レシピ選択部が選択した提示レシピについて提示制御を行う提示制御部と、を備える。前記提示レシピ選択部は、前記食材情報取得部が取得した食材情報で示される食材により作成可能なレシピを第１レシピとして抽出する第１レシピ抽出処理と、前記食材情報取得部が取得した食材情報で示される食材と追加食材により作成可能なレシピを第２レシピとして抽出する第２レシピ抽出処理と、前記第２レシピのうちで、少なくとも前記第１レシピに含まれないという条件を含む選定条件に合致するレシピを第３レシピとして選定する第３レシピ選定処理と、前記第１レシピと前記第３レシピを前記提示レシピとする選択処理を行う。
この場合、例えばレシピ閲覧を求めるレシピ利用者によるユーザ操作などにより選択された食材により作成可能な料理のレシピ（第１レシピ）が提示されるが、さらに追加する食材を想定した場合に作成可能なレシピのうちで選定されたレシピ（第３レシピ）も、ユーザ端末等において提示される。つまり第１レシピよりもバリエーションが豊かな状態で各種レシピを提示する。
なお「選択された食材」は、例えばユーザ操作により検索のために入力された食材、自動処理で選択された食材、ランダム選択されたものなどが想定される。
また食材情報が示す「食材」とは食材の種類や食材の量が想定される。

上記した情報処理装置においては、前記提示レシピ選択部は、前記第１レシピ抽出処理で抽出された第１レシピを提示レシピとして、前記提示制御部によって端末装置で提示させた場合において、所定の条件に基づいて前記第２レシピ抽出処理及び前記第３レシピ選定処理を行って、前記第３レシピを提示レシピとし、前記提示制御部によって端末装置で提示させることが考えられる。
つまり一旦はレシピ利用者に対して第１レシピとして抽出されたレシピを提示するが、第１レシピの提示のみでそのレシピ利用者が満足しているか否か（例えば好ましいレシピがなくて作る料理を決められないでいるか否か）を所定の条件、例えば経過時間の条件や、提示したうちの個別のレシピの詳細情報のリクエスト数などの条件により推定する。そして提示に満足していない（例えば料理を決められていない）と推定したときに第３レシピを提示する。

上記した情報処理装置においては、前記提示レシピ選択部は、前記第１レシピ抽出処理で抽出された第１レシピについて、料理種別の偏り傾向の判定を行い、偏り傾向に応じて設定された条件に基づいて前記第２レシピ抽出処理及び前記第３レシピ選定処理を行うことが考えられる。
つまり第１レシピとして抽出されたレシピについて、例えば料理ジャンルや料理名の種類が少ない場合に、所定の条件に応じて、第３レシピも提示するようにする。

上記した情報処理装置においては、前記提示レシピ選択部は、前記第３レシピ選定処理において、前記第１レシピに含まれず、かつ前記第１レシピと異なる属性を有するという選定条件に合致するレシピを第３レシピとして選定することが考えられる。
異なる属性であることを第３レシピの選定条件とすることで、第１レシピに対して料理のバリエーションを増やす方向で第３レシピを選定する。
ここでいう属性とは、例えば料理種別の属性、又は調理工程の属性、又は味覚属性であることが考えられる。
料理種別の属性とは、例えば日本料理、中華料理、フランス料理等のジャンルや、ハンバーグステーキ、カレー、ラーメン等の料理名種別の属性などである。
調理工程の属性とは、例えば「焼く」「煮る」「蒸す」「揚げる」など調理作業にかかる属性である。
味覚属性とは、例えば「辛い」「甘い」「すっぱい」「甘辛」「味噌味」「醤油味」「塩味」などの味に関する情報の属性である。

上記した情報処理装置においては、前記提示レシピ選択部は、前記追加食材として、前記食材情報取得部が取得した食材情報で示される食材と組み合わされやすい食材を選択して前記第２レシピ抽出処理を行うことが考えられる。
追加食材として、例えばレシピ利用者が選択した食材との組み合わせを考慮して選択し、第２レシピ抽出処理として第２レシピを抽出する。

上記した情報処理装置においては、前記提示レシピ選択部は、前記追加食材として、前記第１レシピが該当しない料理種別において利用されやすい食材を選択して前記第２レシピ抽出処理を行うことが考えられる。
追加食材は、第２レシピ抽出のために選択するのであるが、レシピ利用者が選択できるレシピ（料理）の幅を広げるためには、多様な料理種別のレシピが抽出できるとよい。そこで、第１レシピにおいて存在しない料理種別で利用されやすい食材を用いることで、第１レシピには含まれていないジャンルのレシピが抽出できる可能性を高めるようにする。

上記した情報処理装置においては、前記提示レシピ選択部は、端末装置を用いて食材を選択してレシピ提示要求を行ったユーザ（レシピ利用者）の購入履歴情報から、現在が購入時期にあたる食材を推定する処理を行い、推定された食材を前記追加食材として前記第２レシピ抽出処理を行うことが考えられる。
追加食材を用いた第２レシピ（第３レシピ）は、ユーザ（レシピ利用者）が食材を用意しやすいなどの点で作りやすいものが望ましい。但し追加食材は、そのレシピ利用者がストックしているか否かは不明である。ただし該レシピ利用者がストックしていなくても、該レシピ利用者がそろそろ購入すると推定される食材であれば、そのレシピ利用者にとっても都合がよいことが想定される。そこで、ユーザの意思に基づかない追加食材として、ユーザが時期的に買いやすい食材を選択する。

上記した情報処理装置においては、前記提示レシピ選択部は、端末装置を用いて食材を選択してレシピ提示要求を行ったユーザ（レシピ利用者）の購入履歴情報に基づいて、各食材についての当該ユーザの購入価格上限を設定し、現在の価格が当該ユーザの購入価格上限以下である食材を前記追加食材として前記第２レシピ抽出処理を行うことが考えられる。
追加食材を用いた第２レシピ（第３レシピ）は、ユーザ（レシピ利用者）がその追加食材を買いに行かなければ作れないレシピである可能性がある。一方で食材は時期によって価格が変動するが、一般にユーザは常に食材の価格を許容することはなく、各種食材について購入価格範囲（上限）を持っている。例えば「キャベツは２５０円以上となったら買わない」などである。そこで現在の価格が、ユーザ（レシピ利用者）の購入履歴における購入価格上限以下にある食材を追加食材として選択する。

本発明に係る情報処理方法は、選択された食材を示す食材情報を取得する食材情報取得ステップと、前記食材情報取得ステップで取得した食材情報で示される食材により作成可能なレシピを第１レシピとして抽出する第１レシピ抽出ステップと、前記食材情報取得ステップで取得した食材情報で示される食材と追加食材により作成可能なレシピを第２レシピとして抽出する第２レシピ抽出ステップと、前記第２レシピのうちで、少なくとも前記第１レシピに含まれないという条件を含む選定条件に合致するレシピを第３レシピとして選定する第３レシピ選定ステップと、前記第１レシピ抽出ステップで抽出した第１レシピと、前記第３レシピ選定ステップで選定した第３レシピとについて提示制御を行う提示制御ステップとを行う。
この情報処理方法により、情報処理装置によって充実したレシピ提供が可能となる。
本発明に係るプログラムは、上記各ステップに相当する手順を情報処理装置に実行させるプログラムである。これにより上述の情報処理装置の処理を実現する。

本発明によれば、レシピ利用者たるユーザに対して、追加となる食材の数や種類を抑制しつつ、十分な数量のレシピの選択肢を提示でき、レシピ提供サービスの使用性を向上させることができる。

本発明の実施の形態のシステム構成の説明図である。 実施の形態のレシピ管理サーバの機能構成の説明図である。 実施の形態の情報処理装置のブロック図である。 実施の形態のレシピデータベースの説明図である。 実施の形態の食材データベースの説明図である。 実施の形態のレシピ提供に関する処理のフローチャートである。 第１，第２の実施の形態のレシピ管理サーバの処理のフローチャートである。 第１の実施の形態のレシピ選択処理のフローチャートである。 実施の形態の追加食材設定処理のフローチャートである。 実施の形態の追加食材設定処理のフローチャートである。 実施の形態の第３レシピ選定処理のフローチャートである。 第２の実施の形態のレシピ選択処理のフローチャートである。 第２の実施の形態のレシピ追加判定処理のフローチャートである。 第３の実施の形態のレシピ管理サーバの処理のフローチャートである。 第３の実施の形態の閾値時間設定処理のフローチャートである。 第４の実施の形態のレシピ管理サーバの処理のフローチャートである。

以下、実施の形態を次の順序で説明する。
＜１．全体構成＞
＜２．ハードウエア構成＞
＜３．ＤＢ＞
＜４．端末とサーバ間の処理の流れ＞
＜５．第１の実施の形態＞
［５−１：レシピ管理サーバの処理］
［５−２：レシピ選択処理］
［５−３：追加食材設定処理］
［５−４：第３レシピ選定処理］
＜６．第２の実施の形態＞
＜７．第３の実施の形態＞
＜８．第４の実施の形態＞
＜９．まとめ＞
＜１０．プログラム及び記憶媒体＞

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

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

通信ネットワーク２の構成は特に限定されるものではなく、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（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）、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。

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

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

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

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

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

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

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

食材情報取得部１ａは、選択された食材を示す食材情報を例えばユーザ端末３から取得する処理を行う。食材情報とは、食材の種別又は量の少なくとも一方を示す情報である。この食材情報はレシピ検索のためのキーとなる情報である。
レシピ利用者は、レシピを探したいときにはユーザ端末３を用いてレシピ管理サーバ１が提供するウェブページを閲覧し、レシピ検索を行う。そのときに料理の種別（カテゴリ）や食材を入力して検索要求を行う。食材情報取得部１ａは、そのようなレシピ利用者の操作により検索要求とともに送信されてきた食材情報を取得する。
なお、実施の形態の処理では、主に食材を検索キーとしてレシピを抽出し、レシピ利用者に提示する処理に特徴を有するものであるため、カテゴリを指定しての検索要求については言及しない。以下では、食材が指定された場合の検索要求に関して述べていく。
また、必ずしも食材情報はレシピ利用者の指定入力によるものとは限らない。例えばユーザ端末３におけるアプリケーションプログラム等により、ランダムに食材を選択したり、あるいは自動的に現在レシピ利用者がストックしている食材を指定したりして、レシピ検索要求を送信してくるようなことも考えられる。そのような場合も送信されてきた食材情報に基づいてレシピ管理サーバ１が後述する処理を行うことができる。

提示レシピ選択部１ｂは、食材情報取得部１ａが取得した食材情報に基づいて提示レシピを選択する処理を行う。
即ち提示レシピ選択部１ｂは、レシピ利用者が指定した検索条件（食材情報）に応じて、レシピＤＢ５０に記憶されたレシピからレシピ利用者に提示するレシピを検索する検索処理を実行する。そしてユーザ端末３において提示するレシピを決定する。
詳しくは後述するが、この提示レシピ選択の処理において提示レシピ選択部１ｂは、食材情報取得部が取得した食材情報で示される食材により作成可能なレシピを第１レシピとして抽出する第１レシピ抽出処理を行う。
また提示レシピ選択部１ｂは食材情報取得部１ａが取得した食材情報で示される食材と追加食材により作成可能なレシピを第２レシピとして抽出する第２レシピ抽出処理を行う。
また提示レシピ選択部１ｂは第２レシピのうちで、少なくとも第１レシピに含まれないという条件を含む選定条件に合致するレシピを第３レシピとして選定する第３レシピ選定処理を行う。そして提示レシピ選択部１ｂは第１レシピ抽出処理で抽出した第１レシピと、第３レシピ選定処理で選定した第３レシピを提示レシピとする選択処理を行う。

提示制御部１ｃは、提示レシピ選択部１ｂが選択した提示レシピについてユーザ端末３において提示されるようにする提示制御を行う。具体的には、レシピ利用者の指定した検索条件（食材情報）に応じて検索等の処理により抽出されたレシピを一覧表示するウェブページデータを生成し、ユーザ端末３に送信して、一覧提示されるようにする。
また、提示制御部１ｃは、レシピ利用者の操作に応じた種々のウェブページデータを送信する処理を実行する。種々のウェブページデータとしては、例えばログイン画面のウェブページデータやレシピ詳細ページのウェブページデータや作成レポート投稿ページのウェブページデータなどである。
これらのウェブページのデータは、例えば、ＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible Hyper Text Markup Language）などの構造化文書ファイルである。構造化文書ファイルには、レシピ名や使用食材、或いは調理手順としてのテキストデータや料理画像等の画像データと、それらの配置や表示態様（文字色やフォントや大きさや装飾など）が記述されている。

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

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

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

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

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

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

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

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

食材ＤＢ５３は食材に関する情報が記憶されるＤＢである。
図５に例を示すが、食材ＤＢ５３は、組み合わせられやすい食材の情報や、各種の料理種別毎に使用されやすい食材の情報が取得できる構成とされている。
例えば図示のように、「じゃがいも」「にんじん」「キャベツ」等の対象食材毎に、組み合わせられやすい食材の情報が登録されている。例えば「じゃがいも」に対しての「タマネギ」「にんじん」等である。
「組み合わせられやすい」とは、１つの料理に使用されることが多いという意味であり、この「組み合わせられやすい」食材の情報は、レシピＤＢ５０に登録されているレシピに基づいて生成すればよい。例えば「じゃがいも」を対象とした場合に、登録されているレシピの中で、じゃがいもとともに使われている食材のうちで、該当レシピ数が上位となる食材を「組み合わせられやすい食材」と判定して登録すればよい。
もちろん登録されているレシピに限らず、一般的な認識に基づいてこのような情報を生成し、登録しておくものでも良い。
また、検索時に同時に指定される頻度が高い食材を、組み合わせられやすい食材とすることも考えられる。

また食材ＤＢ５３における料理種別毎の使用食材の情報としても、図示のように対象の料理種別毎に、使用されやすい食材が登録される。料理種別としては前述したように各種のレベル（例えば大分類レベル〜細分類レベル）があるため、各レベルについて登録されれば良い。例えば「日本料理」「中華料理」という大分類レベルでそれぞれ使用されやすい食材、「カレー」「ラーメン」等の中分類レベルでそれぞれ使用されやすい食材などが登録される。
使用されやすい食材の情報は、例えばレシピＤＢ５０に登録されているレシピに基づいて生成すればよい。例えば「カレー」については、料理種別（中分類レベル）が「カレー」とされているレシピを収集し、それらの中で各食材の使用頻度（使用しているレシピ数）を確認し、上位となる食材を「使用されやすい食材」と判定して登録すればよい。
もちろん登録されているレシピに限らず、一般的な認識に基づいてこのような情報を生成し、登録しておくものでも良い。

商品ＤＢ５４は、ＥＣサーバ４が電子商取引において扱う各種商品の情報が記憶されている。例えば各仮想店舗の商品についての価格、在庫、商品画像等の各種情報が登録されている。
本実施の形態に関しては、レシピ管理サーバ１はＥＣサーバ４を介して商品ＤＢ５４の情報を参照することで、例えば現在の食材の価格を把握することができる。

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

＜４．端末とサーバ間の処理の流れ＞
レシピ管理サーバ１とユーザ端末３が実行する処理の流れの一例について、図６を参照して説明する。
ここでは、レシピ管理サーバ１が提供する各種サービスを受けるために、レシピ利用者がユーザ端末３を用いてログイン操作を行い、レシピを検索する例を説明する。

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

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

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

続いて、ユーザ端末３はステップＳ１０３において、レシピを検索するためにレシピ利用者が入力したレシピ検索条件をレシピ管理サーバ１へ送信する検索条件送信処理を実行する。
この処理では、例えば、レシピ利用者によって指定された使用食材などが、検索結果を抽出するための情報（食材情報）として、レシピ管理サーバ１へ伝達される。

レシピ検索条件を受信したレシピ管理サーバ１は、ステップＳ２０４で検索条件としての食材情報を取得する。
そしてレシピ管理サーバ１はステップＳ２０５で提示レシピ選択処理を行う。詳しくは後述するが、この提示レシピ選択処理では、取得した食材情報を検索キーとし、検索ＤＢ５２に記憶された情報に基づいてレシピの検索を行い、結果を抽出する検索処理を含む。そして検索により抽出されたレシピの全部又は一部を提示すべきレシピとして選択する。

続いて、レシピ管理サーバ１はステップＳ２０６において、ステップＳ２０５で選択した提示レシピの一覧をユーザ端末３上に表示させるための提示制御処理を実行する。この処理では、レシピ検索結果一覧としてのウェブページデータを生成してユーザ端末３へ送信することになる。

ユーザ端末３では、レシピ管理サーバ１から受信したレシピ検索結果一覧のウェブページが提示される。これによりレシピ利用者は望みのレシピを探すことができる。
レシピ利用者が検索結果として表示された複数のレシピから一つのレシピを選択する操作を行うと、ユーザ端末３はステップＳ１０４において、レシピ選択処理を実行する。
レシピ選択処理は、レシピ利用者が選択したレシピが何れのレシピであるかを選択レシピ情報としてレシピ管理サーバ１に通知する。尚、この処理は、選択したレシピの詳細情報ページのウェブページデータを要求する処理である。

選択レシピ情報を受信したレシピ管理サーバ１は、ステップＳ２０７において、選択されたレシピの詳細情報が記載されたウェブページのデータを送信する詳細情報送信処理を実行する。
この処理によって、ユーザ端末３上に、レシピ利用者が選択したレシピに関する詳細情報が提示される。詳細情報とは、例えば、レシピに使用する食材情報や調理手順、調理器具情報などである。

＜５．第１の実施の形態＞
［５−１：レシピ管理サーバの処理］
図６で説明した処理の流れを実現するためにレシピ管理サーバ１が実行する処理例について、図７を参照して説明する。特にこの図７は、第１の実施の形態として、レシピ管理サーバ１が、食材情報に基づくレシピ一覧として、より数量の充実したレシピ一覧をレシピ利用者に提示できるようにする例である。レシピ管理サーバ１は図２で説明した機能により図７の処理を実行する。

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

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

レシピ管理サーバ１はステップＳ３１１においては、ユーザ端末３から検索条件を受信したか否かを判定する処理を実行する。
検索条件は、レシピ利用者がユーザ端末３を用いて所望のレシピを検索する場合に指定した検索キーワードや除外キーワードなどであり、ユーザ端末３からレシピ管理サーバ１へ送信される。上述のように本実施の形態では食材を検索キーとするため、検索条件に少なくとも食材情報が含まれる場合を想定して説明する。

ステップＳ３１１において検索条件を受信したと判定した場合、レシピ管理サーバ１はステップＳ３１２において検索のための食材情報を取得し、ステップＳ３１３において提示レシピ選択処理を実行し、ステップＳ３１４において提示制御処理を実行する。即ち図６でステップＳ２０４，Ｓ２０５，Ｓ２０６として述べた処理である。

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

ステップＳ３３３のウェブページデータ送信処理の後、或いは、ステップＳ３３１においてウェブページデータ要求を受信していないと判定した後、レシピ管理サーバ１は再びステップＳ３０１の処理を実行する。

［５−２：レシピ選択処理］
本実施の形態では、ステップＳ３１２、Ｓ３１３、Ｓ３１４の処理によりユーザ端末３において提示される検索結果レシピの一覧が、レシピ数として充実するようにしている。このためレシピ管理サーバ１は、ステップＳ３１３のレシピ選択処理を図８のように行う。

図７のステップＳ３１２で食材情報を取得したらステップＳ３１３のレシピ選択処理として、まず図８のステップＳ４０１でレシピ検索を行って第１レシピを抽出する。
この場合、取得した食材情報で示される１又は複数の食材をキーとしてレシピ検索を行う。例えばレシピ利用者が「タマネギ」「じゃがいも」を選択して検索要求した場合であれば、このステップＳ４０１では食材としてタマネギとじゃがいものみを使って料理ができるレシピの検索が行われることになる。
なお、この場合の「のみ」とは、主たる食材が「タマネギ」「じゃがいも」のみという意味で、他に調味料、ソース、水等を使用するレシピであってもよいことは当然である。また主たる食材の全てを使用するレシピに限らない。つまり例えば「タマネギ」と「じゃがいも」のストックがある場合に可能なレシピという考え方で良い。従って例えばオニオンスライスのようにタマネギのみを使用する（ジャガイモを使用しない）レシピも抽出されるようにしてもよい。
このような検索によって抽出された１又は複数のレシピを、説明上「第１レシピ」とする。

続いてレシピ管理サーバ１はステップＳ４０２で追加食材設定を行う。これは検索条件における食材情報で示された１又は複数の食材に、さらに追加する１又は複数の食材を決める処理である。この処理の具体例は各種考えられるため後述する。
例えば上記のように食材情報で「タマネギ」「じゃがいも」が指定されている状況で、「豚肉」など、プラスする食材を自動的に選んで、追加食材として設定する。

そしてレシピ管理サーバ１はステップＳ４０３で、レシピ検索を行って第２レシピを抽出する。この処理は、食材情報で指定される食材に、追加食材を加え、これらの食材を用いて料理可能なレシピを検索する処理となる。例えば「タマネギ」「じゃがいも」「豚肉」を検索キーとし、これらのみで料理可能なレシピを抽出する。そしてレシピ管理サーバ１は抽出された１又は複数のレシピを第２レシピとする。この場合、第１レシピ抽出時よりも食材の種類が増えることになるため、第１レシピと同じレシピを含んで、より多数のレシピが第２レシピとして抽出されることが想定される。

レシピ管理サーバ１はステップＳ４０４で第３レシピ選定を行う。第３レシピとは、第２レシピとして抽出された１又は複数のレシピのうちで、所定の条件に従って選択した１又は複数のレシピである。
所定の条件とは各種考えられるが、少なくとも第２レシピの内で第１レシピに含まれないという条件がある。従って第１レシピと第３レシピに重複して該当するレシピは無い。 第３レシピ選定処理例については後述する。

そしてレシピ管理サーバ１はステップＳ４０５で提示レシピを選択する。ここでは第１レシピとして抽出された１又は複数のレシピと、第３レシピとされた１又は複数のレシピを、提示レシピとする。
このように選択された提示レシピが、図７のステップＳ３１４で検索結果一覧に載せられ、ユーザ端末３に送信される。つまり第１レシピと第３レシピとされたレシピが、レシピ利用者にとっては検索結果として認識するレシピとなる。
この検索結果としては、レシピ利用者が指定した食材のみで料理可能なレシピだけでなく、レシピ利用者が指定していない追加食材を加えて抽出したレシピも含まれていることになる。従って、レシピ利用者が指定した食材のみでは少数のレシピしか抽出されないような場合でも、より多数のレシピが検索結果として提示される。

［５−３：追加食材設定処理］
ステップＳ４０２の追加食材設定処理の各種の例を説明する。
図９Ａはレシピ管理サーバ１が追加食材をランダムに選択する例である。
レシピ管理サーバ１はステップＳ５００で、多数の食材の中から１つの食材をランダムに選択する。
そしてレシピ管理サーバ１はステップＳ５０１で、その選択した食材が、取得した食材情報に含まれているか否かを確認する。つまり第１レシピ抽出の際の検索キーとなった食材であるか否かである。選択した食材が、取得した食材情報に含まれていなければ、ステップＳ５０２に進んで、その選択した食材を追加食材に設定する。
一方、選択した食材が、取得した食材情報に含まれていれば、それを追加食材とはせずステップＳ５００に戻ってランダム選択をやり直す。

このような処理により、レシピ利用者が指定していない食材がランダムに選ばれて追加食材とされる。このためレシピ利用者が指定した食材情報で示される食材と、ランダムに選ばれた追加食材が検索キーとされて第２レシピ抽出処理が行われることになる。このため第２レシピとして多様なレシピが抽出される可能性が高まる。
なお追加食材を複数とする場合、当該処理を複数回行えば良い。

図９Ｂは、レシピ利用者が指定した食材と組み合わせられやすい食材を追加食材とする例である。
レシピ管理サーバ１はステップＳ５１０で、ユーザ端末３から受信した食材情報、つまりレシピ利用者が指定した食材情報で示される食材のうちの１つを対象食材として取得する。
そしてステップＳ５１１でレシピ管理サーバ１は、当該対象食材に対して組み合わせられやすい食材を判定する。例えば対象食材をキーとして図５で説明した食材ＤＢを検索し、その対象食材と組み合わせられやすい食材の情報を取得する。そして取得した食材のうちで、食材情報（レシピ利用者が指定した食材）に含まれない食材を判定する。
例えばレシピ利用者が指定した食材（食材情報で示される食材）が「じゃがいも」「タマネギ」の場合において、「じゃがいも」を対象食材とした場合、図５の食材ＤＢ５３から組み合わせられやすい食材として「タマネギ」「にんじん」が取得される。「タマネギ」は食材情報に含まれているため「にんじん」を組み合わせられやすい食材と判定することになる。

ステップＳ５１２でレシピ管理サーバ１は、判定した食材を追加食材に設定する。
このような処理により、レシピ利用者が指定していない食材であるが、指定した食材と組み合わせられやすい食材が選ばれて追加食材とされる。このため第２レシピとして、より多様なレシピが抽出される可能性が高まる。組み合わせられやすい食材の組で検索することで、該当するレシピ数が多くなると想定されるためである。

なおレシピ利用者が指定した食材情報に含まれる食材が複数の場合に、それぞれについて組み合わせられやすい食材を抽出して複数の追加食材を設定しても良いし、一部の食材のみについて組み合わせられやすい食材を追加食材としてもよい。さらに、食材情報に含まれる複数の食材に共通して組み合わせられやすい食材を選択することも考えられる。

図９Ｃは、なるべく第１レシピとは異なる料理種別のレシピを第２レシピとして抽出できるようにする例である。
レシピ管理サーバ１はステップＳ５２０において、第１レシピの料理種別に存在しない料理種別を判定する。即ち図８のステップＳ４０１で抽出された第１レシピのそれぞれの料理種別を確認する。そしてそれらに該当しない料理種別を探す。
例えば第１レシピとなった複数のレシピが「中華料理」か「スペイン料理」のいずれかに該当するものであったときに、「日本料理」「ベトナム料理」などを、第１レシピに存在しない料理種別とする。
次にステップＳ５２１でレシピ管理サーバ１は、第１レシピに存在しない料理種別において使われやすい食材を判定する。複数の料理種別が、第１レシピに存在しない料理種別に該当した場合、その中で１つの料理種別を選択すれば良い。
そして例えば「日本料理」を第１レシピに存在しない料理種別と判別した場合、レシピ管理サーバ１は図５の食材ＤＢ５３を検索して、日本料理で使われやすい食材の情報を得る。例えば「豆腐」「ネギ」等の情報を取得する。そしてこれら取得した食材のうちで食材情報（レシピ利用者が指定した食材）に含まれていない食材を選択する。

ステップＳ５２２でレシピ管理サーバ１は、判定した料理種別で使われやすい食材（かつレシピ利用者が指定した食材情報に含まれていない食材）を追加食材に設定する。
このような処理により、レシピ利用者が指定していない食材であり、かつ第１レシピとは傾向の違った料理でよく使用される食材が追加食材とされ、第２レシピの抽出が行われる。このため第２レシピとして、第１レシピとは異なる料理種別のレシピが抽出される可能性が高まる。

なお第１レシピに存在しない料理種別が複数の場合、それぞれの料理種別で使用されやすい食材を、それぞれ追加食材としてもよい。
またこの場合の料理種別のレベルは、固定的でもよいし、レシピ利用者に応じたレベル設定、或いは第１レシピに応じたレベル設定などが考えられる。
固定的なレベル設定とは、料理種別とは「日本料理」「中華料理」というような大分類レベルに固定して、ステップＳ５２０の処理を行うとか、「カレー」「ハンバーグ」という中分類レベルに固定してステップＳ５２０の処理を行うとする例である。
レシピ利用者に応じたレベル設定とは、レシピ利用者のレシピ閲覧履歴、レシピ投稿履歴などに基づいて、そのレシピ利用者に合わせたレベルを用いるとする例である。例えば多様な料理のレシピを使用したり、検索したり、投稿しているレシピ利用者には、大分類レベル或いは中分類レベルの料理種別でステップＳ５２０の処理を行う。一方、常にカレーレシピの閲覧や投稿を行っているようなレシピ利用者に対しては「ビーフカレー」「チキンカレー」といったような、「カレー」の下の階層の細分類レベルの料理種別でステップＳ５２０の処理を行う。これによりレシピ利用者のレシピ検索の傾向に応じて、適応的に第２レシピ抽出を行うことができ、そのレシピ利用者にとって満足度の高い第３レシピ選定が可能となる。
第１レシピに応じたレベル設定とは、第１レシピに含まれる各レシピの料理種別の存在傾向に応じて種別レベルを設定する例である。例えば第１レシピにおいて大分類レベルで複数の料理種別が含まれていたら大分類レベルとしたり、第１レシピにおいて中分類レベルが１種類しかなければ細分類レベルに設定するなどの例である。

図１０Ａは、レシピ利用者がストックしていそうな、或いは購入するとしても支障がなさそうな食材を追加食材とする例である。
なお、この例はレシピ管理サーバ１が、レシピ利用者についての食材の在庫を精緻に管理できていない場合に適用することが考えられる処理である。

レシピ管理サーバ１はステップＳ５３０において、レシピ利用者の購入履歴情報を例えばユーザＤＢ５１から取得する。
そしてステップＳ５３１でレシピ管理サーバ１は、そのレシピ利用者が購入したことのある食材毎の平均的な購入スパンを算出する。例えば「じゃがいも」「タマネギ」・・・などの各食材について、どの程度の時間間隔で購入しているかを算出する。そして例えば「じゃがいも」については１ヶ月間隔、「タマネギ」については２週間間隔などとして購入スパンを求める。
なおこのような算出は、予めバッチ処理で各ユーザに対して行って、ユーザＤＢ５１に登録しておくとよい。

ステップＳ５３２でレシピ管理サーバ１は、現在、そのレシピ利用者がストックしている可能性が高いと推定される食材や、現在がそのレシピ利用者（検索要求を行っているユーザ）の購入タイミングに近い食材を判定する。
例えば検索時点から過去の所定期間に購入された食材は、現在ストックしている可能性が高いと推定できる。
また、現在が購入タイミングに近い食材を判定するためには、各食材について、現在より上記の購入スパンだけ過去の時点付近で、その食材を購入しているか否かを判別する。求めた購入スパンだけ溯った過去の時点付近でその食材を購入していれば、その食材が当該レシピ利用者にとってそろそろ購入時期であり、検索時点から所定期間内に購入されると食材であると推定できる。
なお、このような「そろそろ購入タイミング」であるか否かの判定を行う食材としては、レシピ利用者が検索条件で指定した食材情報に含まれていない食材を対象とすれば良い。

このような処理により、当該レシピ利用者がストックしていると推定されるか、もしくはそろそろ購入する時期であると推定される食材を判定したら、ステップＳ５３３で、その判定した食材の全部又は一部を追加食材とする。

例えばこの処理により、レシピ利用者が指定していない食材であるが、レシピ利用者がストックしていそうな、或いはそろそろ購入すると推定される食材が追加食材とされ、第２レシピの抽出が行われる。このため第２レシピとしては、追加食材を必要とするが、レシピ利用者にとって料理を行うことに支障が無いレシピが抽出される可能性が高まる。追加食材はレシピ利用者にとっては購入しやすく、もしくは既に購入しているかもしれない食材である可能性も高いためである。

なお追加食材を１つとする場合において、購入タイミングに近い食材が複数存在する場合、例えば最も現在に近い購入タイミングが推定される食材を選ぶことなどが考えられる。或いは既に直近で購入実績がある食材を選択するようにしてもよい。
またＥＣサーバ４からより詳細な購入情報を取得し、例えば現在そのレシピ利用者に対して配送中の食材を選択するようにしてもよい。

図１０Ｂは、レシピ利用者が購入するとしても価格的に支障がなさそうな食材を追加食材とする例である。
レシピ管理サーバ１はステップＳ５４０において、各食材の現在の価格情報を取得する。例えばＥＣサーバ４を介して商品ＤＢ５４における現在の電子商取引市場での価格情報を取得する。
またステップＳ５４１でレシピ管理サーバ１は、レシピ利用者の購入履歴情報を例えばユーザＤＢ５１から取得する。

ステップＳ５４２でレシピ管理サーバ１は、レシピ利用者の購入履歴情報から、そのレシピ利用者が購入したことのある食材毎の購入価格の情報を取得し、最も高い価格を判定する。そしてその価格を、当該レシピ利用者にとっての、その食材の上限金額と設定する。例えば「じゃがいも」の購入履歴として過去に「１２０円」「１８０円」「１３５円」・・・などがあった場合、「１８０円」を、そのレシピ利用者にとってのジャガイモの上限金額とする。
なおこのような算出は、予めバッチ処理で各ユーザに対して行って、ユーザＤＢ５１に登録しておいてもよい。

ステップＳ５４３でレシピ管理サーバ１は、現在価格がそのレシピ利用者の上限金額以下の食材を選択する。そしてステップＳ５４４で、その食材を追加食材とする。
なお、現在価格でレシピ利用者の上限金額以下となっている食材が複数ある場合、それらの全部又は一部を選択して追加食材としてもよいし、例えば上限金額からの現在価格の低下率が高い順など、所定の条件で優先順位をつけて、１又は所定数の食材を選択してもよい。もちろん追加食材とするものとしては、レシピ利用者が指定した食材情報に含まれている食材を除く。

このような処理により、レシピ利用者が指定していない食材であるが、レシピ利用者が購入することに支障がない食材が追加食材とされ、第２レシピの抽出が行われる。このため第２レシピとしては、追加食材を必要とするが、その食材はレシピ利用者にとって料理を行うために購入しても良いと考える価格内のものであるため、レシピ利用者が選択する可能性があるレシピとなる。つまりレシピ利用者に「食材が高いからやめておこう」という思いをおこさせるレシピは第２レシピに含まれないことになる。

なお、上限金額は過去に購入した価格のうちの最高額としたが、例えば最高購入額の１割増しの値段にするなど、購入履歴に基づいて所定の計算式で求められる他の価格に設定してもよい。
また上限金額は、例えば食材の過去の購入金額の平均価格として求めてもよい。
また上限金額として、検索時と同時期（時期とは、季節単位や月単位が想定される）の購入履歴に基づく最も高い価格や、或いは平均価格を用いてもよい。
また上限金額として、食材の流通量が略同一の期間の購入履歴に基づく最も高い価格や平均価格を用いてもよい。

以上、追加食材設定処理例を説明したが、追加食材設定処理例は、これ以外にも各種考えられる。
例えば当該レシピ利用者がよく購入する食材（購入頻度が高い食材）を購入履歴情報から判別し、それを追加食材としてもよい。そのような食材は、レシピ利用者が指定しなかったとしてもストックしている可能性が高く、或いは購入に支障がない食材のため、レシピ利用者にとって有効な選択肢として考えやすいレシピが抽出できることになる。
また投稿されているレシピ全体の中で、使用食材のランキング等を行っておき、ランキング上位の食材を追加食材とすることも考えられる。この場合、第２レシピとして抽出されるレシピ数を多くできることになり、レシピ利用者に多様なレシピ提示の可能性を高めることができる。

また図９Ａ、図９Ｂ、図９Ｃ、図１０Ａ、図１０Ｂの各例は単独では無く、複合的に用いて追加食材設定処理を行うことも考えられる。
例えば図９Ｂ、図９Ｃ、図１０Ａ、図１０Ｂの各処理では、追加すべき食材が該当無しということになる可能性もある。そこで、該当無しの場合には図９Ａの処理を行って追加食材を設定するなどである。

［５−４：第３レシピ選定処理］
続いて図８のステップＳ４０４の第３レシピ選定処理の例を説明する。
上述したように抽出された第２レシピのうちから、レシピ利用者に提示するレシピとなる第３レシピを選定するわけであるが、第３レシピは少なくとも第１レシピに含まれないレシピとする。これは、第１レシピもレシピ利用者に提示するレシピとなるため、同じレシピを重複して提示してしまうことを避けるためである。
単に、このように第２レシピのうちで第１レシピに含まれないレシピを第３レシピとする例も考えられるが、以下ではレシピ利用者に対してより多様なレシピ提示を実現する第３レシピ選定手法を説明する。

図１１Ａは料理種別を考慮した選定処理である。
レシピ管理サーバ１はステップＳ６００で、第１レシピとされた各レシピの属性を取得する。ここでは各レシピの料理種別の情報を例えばレシピＤＢ５０から取得する。
ステップＳ６０１でレシピ管理サーバ１は、第２レシピとされた各レシピの属性として料理種別の情報を例えばレシピＤＢ５０から取得する。
ステップＳ６０２でレシピ管理サーバ１は、第２レシピの中で、第１レシピに存在しない料理種別のレシピを第３レシピに選定する。

例えば第１レシピには、スペイン料理、イタリア料理が存在したとする。また第２レシピには、スペイン料理、イタリア料理、ベトナム料理、日本料理が存在したとする。この場合、第２レシピにおけるベトナム料理のレシピと日本料理のレシピを、第３レシピとすることになる。

なおステップＳ６００、Ｓ６０１で判別する属性としての料理種別のレベルは、固定的なレベル設定でもよいし、レシピ利用者に応じたレベル設定、或いは第１レシピに応じたレベル設定などが考えられる。例えばステップＳ６００、Ｓ６０１の処理を「日本料理」「中華料理」というような大分類レベルに固定して行うとか、「カレー」「ハンバーグ」という中分類レベルに固定して行うとする例である。
レシピ利用者に応じた設定とは、上述したように、レシピ利用者のレシピ閲覧履歴、レシピ投稿履歴などに基づいて、そのレシピ利用者に合わせた料理種別のレベルを用いるとする例である
第１レシピに応じたレベル設定とは、上述したように、第１レシピにおける料理種別の存在傾向に応じた料理種別のレベルを用いる例である。

図１１Ｂは調理工程を考慮した選定処理である。
レシピ管理サーバ１はステップＳ６１０で、第１レシピとされた各レシピの属性として調理工程の情報を例えばレシピＤＢ５０から取得する。
ステップＳ６１１でレシピ管理サーバ１は、第２レシピとされた各レシピの属性として調理工程の情報を例えばレシピＤＢ５０から取得する。
ステップＳ６１２でレシピ管理サーバ１は、第２レシピの中で、第１レシピに存在しない調理工程を有するレシピを第３レシピに選定する。

調理工程とは、例えば「焼く」「煮る」「揚げる」「蒸す」「こねる」などの別であったり、或いは特定の調理器具の使用などである。
例えば第１レシピには、「焼く」工程を主とする料理ばかりが存在し、第２レシピには、「焼く」レシピ、「煮る」レシピ、「揚げる」レシピが存在したとする。この場合、第２レシピにおける「煮る」レシピ、「揚げる」レシピを第３レシピとする。
これにより多様な調理工程を有するレシピをレシピ利用者に提示できる可能性を高めることができる。

図１１Ｃは味覚属性を考慮した選定処理である。
レシピ管理サーバ１はステップＳ６１０で、第１レシピとされた各レシピの味覚属性の情報を例えばレシピＤＢ５０から取得する。
ステップＳ６１１でレシピ管理サーバ１は、第２レシピとされた各レシピの味覚属性の情報を例えばレシピＤＢ５０から取得する。
ステップＳ６１２でレシピ管理サーバ１は、第２レシピの中で、第１レシピに存在しない味覚属性を有するレシピを第３レシピに選定する。

味覚属性とは、例えば「甘い」「辛い」「甘辛い」「酸っぱい」「味噌味」「醤油味」「塩味」などの別である。
例えば第１レシピには、「甘い」料理ばかりが存在し、第２レシピには、「甘い」料理のレシピと「辛い」料理のレシピが存在したとする。この場合、第２レシピにおける「辛い」料理のレシピを第３レシピとする。
これにより多様な味覚属性のレシピをレシピ利用者に提示できる可能性を高めることができる。

なお以上は第３レシピ選定処理としての一例である。
各処理では、第３レシピが該当無しとなる可能性もあるため、図１１Ａ、図１１Ｂ、図１１Ｃの処理のうちで、１つでも該当したレシピを第３レシピとすることも考えられる。
また図１１Ａ、図１１Ｂ、図１１Ｃのいずれの処理でも該当するレシピがない場合には、第２レシピのうちで第１レシピに含まれないレシピを第３レシピとするようにしてもよい。
逆に管理しているレシピ数が多くなると、いずれの処理でも該当するレシピが多数になりすぎる場合も考えられる。その場合は、図１１Ａ、図１１Ｂ、図１１Ｃの処理の全てに該当するレシピを第３レシピとするようにしてもよい。
またこれらの各処理の適用や組み合わせ、オア条件、アンド条件を、第１レシピ数や第２レシピ数に応じて適応的に変更してもよい。

＜６．第２の実施の形態＞
第２の実施の形態について説明する。
なお、以降第２、第３、第４の実施の形態において、追加食材設定処理や第３レシピ選定処理については詳述を避けるが、上述のような多様な処理が適用できるものである。
上述の第１の実施の形態では、無条件に第３レシピ選定を行って第１レシピと共にユーザ端末３において提示させる例としたが、第２の実施の形態は、条件に応じて第３レシピ選定及び提示を行うようにする例である。

図１２に第２の実施の形態のレシピ管理サーバ１の処理を示す。なお、図１２は図７のステップＳ３１３としてのレシピ選択処理の例を示している。図１２において図８と同様の処理は同一のステップ番号を付し、重複説明を避ける。

レシピ管理サーバ１は、図７のステップＳ３１２で食材情報を取得したらステップＳ３１３のレシピ選択処理として、まず図１２のステップＳ４０１でレシピ検索を行って第１レシピを抽出する。
そして第１レシピ抽出が行われた時点でレシピ管理サーバ１はステップＳ４１０で、レシピ追加判定を行う。
このレシピ追加判定によってレシピ追加が必要と判定した場合に、レシピ管理サーバ１はステップＳ４１１からＳ４０２、Ｓ４０３、Ｓ４０４の処理に進み、第３レシピを選定する。そしてステップＳ４０５でレシピ管理サーバ１は提示レシピを選択する。この場合は第１レシピとして抽出された１又は複数のレシピと、第３レシピとされた１又は複数のレシピを、提示レシピとする。以上は、結果として第１の実施の形態と同様となる。
一方、レシピ追加判定によってレシピ追加が不要と判定した場合には、レシピ管理サーバ１はステップＳ４１１からＳ４０５に進み、提示レシピを選択する。この場合は第１レシピとして抽出された１又は複数のレシピを提示レシピとする。つまり第３レシピの選定及び提示は行われない。

従って第２の実施の形態では、レシピ利用者に対しては第１レシピのみの提示で十分と判定されるような場合はステップＳ４０２、Ｓ４０３、Ｓ４０４は行われないことで処理負担を低減する。一方、第１レシピの提示のみでは十分でないと判定されるときに、第３レシピを加えた提示を行うものである。

ステップＳ４１０のレシピ追加判定の処理例を説明する。
図１３Ａはレシピ数に基づいて追加するか否かを判定する例である。
ステップＳ７００でレシピ管理サーバ１は、変数ＲＮにステップＳ４０１で抽出された第１レシピの数を代入する。
ステップＳ７０１でレシピ管理サーバ１は、変数ＲＮと予め設定された判定閾値ｔｈＲＮを比較する。そしてレシピ管理サーバ１は、ＲＮ≦ｔｈＲＮであればステップＳ７０２でレシピ追加要と判定し、ＲＮ≦ｔｈＲＮでなければ、ステップＳ７０３でレシピ追加不要と判定する。
この判定の結果に応じて図１２のステップＳ４１１での処理の分岐が行われる。

従って、第１レシピの数が、閾値ｔｈＲＮとしての所定のレシピ数以上であれば、第１レシピのみが提示され、所定のレシピ数未満であれば、第３レシピが追加されて提示されることになる。これによって、第１レシピ該当数が少ないときであっても、追加食材を用いたレシピが共に提示され、提示レシピ数がレシピ利用者にとって充実したものとなる。

図１３Ｂは第１レシピの料理種別のバリエーションに基づいて追加判定を行う例である。
ステップＳ７１０でレシピ管理サーバ１は、判定のための料理種別レベルを設定する。例えば上述の大分類レベル〜細分類レベルのいずれかを選択する。この場合、固定的に或るレベルを選択しても良いし、レシピ利用者に応じて、或いは第１レシピに応じて、上述した考え方で大分類レベル〜細分類レベルのいずれかを選択するようにしてもよい。

ステップＳ７１１でレシピ管理サーバ１は、ステップＳ４０１で抽出された第１レシピについて、料理種別毎の数をカウントする。例えば第１レシピが６個抽出されているとし、大分類レベルの料理種別が用いられるとしたら、第１レシピのうちで、日本料理が３つ、中華料理が２つ、イタリア料理が１つなどというようにカウントする。

ステップＳ７１２でレシピ管理サーバ１は、料理種別の偏り傾向を判定し、判定結果によりステップＳ７１３で処理を分岐する。
偏り傾向の判定手法は多様に考えられる。例えば偏り傾向であると判定する基準として、
・１つの料理種別が全体の２／３以上の数を占めるか否か
・カウント値が１位の料理種別と２位の料理種別のカウント値の差が所定値以上か否か
・（第１レシピ数）／（料理種別数）の値が所定値未満か否か
などが考えられる。もちろんこれらに限られるものではない。例えば料理種別を数値化し、標準偏差或いは分散の値を基準値と比較することなどで判定しても良い。

偏っていると判定した場合は、レシピ管理サーバ１はステップ７１４でレシピ追加要と判定し、偏っていなければステップＳ７１５でレシピ追加不要と判定する。
この判定の結果に応じて図１２のステップＳ４１１での処理の分岐が行われる。

従って、第１レシピにおいて料理種別が偏っていると判定された場合に第３レシピが追加されて提示される。これによって、第１レシピが、料理種別としてバリエーションが少ないときに、追加食材を用いた第３レシピが共に提示され、提示レシピの料理種別を多様化できる。
なお、この図１３Ｂの処理でレシピ追加を行うと判定した場合、ステップＳ４０２の追加食材設定として図９Ｃの処理を適用したり、ステップＳ４０４の第３レシピ選定では図１１Ａの処理を適用すると、提示するレシピの料理種別を増やすという意味で好適である。
またレシピ追加判定として、図１３Ａ、図１３Ｂの両方を用い、そのＯＲ条件、又はＡＮＤ条件でレシピ追加を行うか否かを判定しても良い。

＜７．第３の実施の形態＞
第３の実施の形態のレシピ管理サーバ１の処理を図１４で説明する。なお図１４において図７と同一の処理は同一のステップ番号を付し説明を省略する。
この第３の実施の形態は、一旦、第１レシピをレシピ利用者に提示するが、その後の状況に応じて第３レシピを追加的に提示するか否かを決める例である。

図１４の処理においてレシピ管理サーバ１は、ステップＳ３０１，Ｓ３１１，Ｓ３２１，Ｓ３３１を順に実行することにより、各種処理を継続的に行う。
ユーザ端末３からの検索条件を受信してステップＳ３１１からＳ３１２に進んで食材情報を取得したら、ステップＳ３１３ａで第１レシピ抽出のためのレシピ検索処理を行う。この場合レシピ管理サーバ１は、取得した食材情報に基づいてレシピＤＢ５０の検索を行って１又は複数のレシピを抽出し、第１レシピとする。
続いてレシピ管理サーバ１はステップＳ３１３ｂで提示レシピの選択を行うが、ここでは、抽出した１又は複数の第１レシピを全て提示レシピとする。そしてステップＳ３１４において提示制御処理を実行する。即ち第１レシピとして抽出された１又は複数のレシピの一覧として、レシピ検索結果一覧のウェブページデータを生成してユーザ端末３へ送信する。

レシピ管理サーバ１はステップＳ３１５でタイムカウントを開始する。説明上、タイムカウント値を「ＴＭ」とする。
またステップＳ３１６でレシピ管理サーバ１は、タイムカウント値ＴＭを比較することで所定時間経過したか否かを判定するための閾値時間ｔｈＴＭを設定する。閾値時間ｔｈＴＭの設定処理については後述する。

レシピ管理サーバ１は、ステップＳ３２１では、タイムカウント値ＴＭが閾値時間ｔｈＴＭ以上となっているか否かを確認する。
なお、タイムカウント値ＴＭの初期値（リセット値）は“０”であり、タイムカウント中以外は、ステップＳ３２１からＳ３３１に進む。
またタイムカウント開始後でも、タイムカウント値ＴＭが閾値時間ｔｈＴＭ以上となるまでは、ステップＳ３２１からＳ３３１に進む。

ステップＳ３２１からＳ３２２に進むのは、第１レシピをユーザ端末３に提示させてから、ステップＳ３３５でタイムカウントが終了される前に、閾値時間ｔｈＴＭとしての所定時間を経過した場合となる。
この場合レシピ管理サーバ１はステップＳ３２２で追加食材設定処理を行う（例えば図９Ａ、図９Ｂ、図９Ｃ、図１０Ａ、図１０Ｂ参照）。そしてレシピ管理サーバ１はステップＳ３２３で追加食材を加えた検索を行って第２レシピを抽出し、ステップＳ３２４で第２レシピのうちで第３レシピを選定する（例えば図１１Ａ、図１１Ｂ参照）。
その後レシピ管理サーバ１はステップＳ３２５で追加提示レシピを選択する。つまり第３レシピを提示レシピと追加的に設定する。そしてステップＳ３２６で提示制御処理を行う。例えばそれまで提示していた第１レシピに第３レシピを追加したレシピ検索結果一覧のウェブページデータを生成してユーザ端末３へ送信する。これによりユーザ端末３では第３レシピも含めたレシピ一覧が提示される。
なおこの場合、第１レシピを含まない第３レシピのみの一覧とする例も考えられる。
そしてレシピ管理サーバ１はステップＳ３２７でタイムカウントを終了しタイムカウント値ＴＭをリセットする。

レシピ管理サーバ１は、ウェブページデータの受信要求を認識した場合は、ステップＳ３３１からＳ３３２，Ｓ３３３の処理に進むことは図７と同様である。
但しこの図１４の例では、レシピ管理サーバ１はステップＳ３３４で、今回要求されたウェブページが、検索結果として一覧表示させたレシピのうちの、特定のレシピの詳細ページであったか否かを確認する。
そしてレシピの詳細ページであった場合は、レシピ管理サーバ１はステップＳ３３５に進んでタイムカウントを終了し、タイムカウント値ＴＭをリセットする。

この図１４の処理によっては、まずレシピ利用者が食材を指定して検索要求を行った場合には、レシピ利用者には、指定した食材により料理が可能な第１レシピの一覧が提示される。しかし、所定時間以上、レシピ利用者が詳細ページの要求を行わないでいると、レシピ利用者にとって望ましいレシピが存在しないとして選択に迷っているとレシピ管理サーバ１が推定して、第３レシピを追加したレシピ一覧を提示するものとなる。
もし第１レシピのみの一覧提示の際に、所定時間以内にレシピ利用者が或るレシピを選択して詳細ページ要求操作を行った場合は、ステップＳ３３５でタイムカウントが終了されるので、ステップＳ３２２〜Ｓ３２６は行われず、第３レシピの追加提示は行われない。これはレシピ利用者が第１レシピのみの提示で、作る料理を決めたと推定される場合である。
一方、第１レシピのみの一覧では、レシピ利用者にとって作りたいと思うレシピが挙げられておらず、レシピ利用者がどうしようか決めかねている状況を、詳細ページのリクエストが一定時間以上検知されないという観点で推定して、第３レシピを提示する。従ってレシピ利用者に対して第３レシピを新たな選択肢として有効に提示できる。

ところで、レシピ利用者にとって作りたいレシピがないという推定を行うための一定時間経過について閾値時間ｔｈＴＭを用いている。この閾値時間ｔｈＴＭのステップＳ３１６での設定例を図１５Ａ、図１５Ｂに示す。
図１５Ａは閾値時間ｔｈＴＭとして固定値を用いる場合である。レシピ管理サーバ１はステップＳ８００として閾値時間ｔｈＴＭとして予め記憶されている固定値を取得する。

図１５Ｂは閾値時間ｔｈＴＭを料理種別のバリエーションに応じて決める例である。
ステップＳ８１０でレシピ管理サーバ１は、閾値時間判定のための料理種別レベルを設定する。例えば上述の大分類レベル〜細分類レベルのいずれかを選択する。この場合、固定的に或るレベルを選択しても良いし、上述の考え方で、レシピ利用者に応じて、或いは第１レシピに応じて大分類レベル〜細分類レベルのいずれかを選択するようにしてもよい。

ステップＳ８１１でレシピ管理サーバ１は、図１４のステップＳ３１３ａで抽出された第１レシピについて、料理種別毎の数をカウントする。例えば第２レベルの料理種別が用いられるとしたら、第１レシピとしては日本料理が１つ、中華料理が５つ、スペイン料理が７つなどというようにカウントする。

ステップＳ８１２でレシピ管理サーバ１は、料理種別の偏り傾向を判定する。例えば偏り傾向について、大、中、小の３段階に判定するなど、複数段階を判定する。例えば標準偏差や分散の値により複数段階に分けても良いし、上述した偏り傾向の条件を設定して複数段階に分けても良い。
そしてステップＳ８１３で、偏り傾向の段階に応じて閾値時間ｔｈＴＭの値を設定する。この場合、偏り傾向が大きいほど閾値時間ｔｈＴＭの値を短い値にする。

このように閾値時間ｔｈＴＭの値を設定すると、第１レシピの料理種別のバリエーションに応じて、レシピ利用者の考えを適切に推定しやすくなる。
例えば第１レシピが同じような料理のレシピばかり（偏り傾向が高い）の場合、あまり時間をかけずとも、レシピ利用者は目的のレシピがないと判断しやすい。その場合、閾値時間ｔｈＴＭを短くすることで、早めにレシピ利用者に追加レシピを提示できる。
一方、第１レシピとしてバリエーション豊かなレシピが含まれている場合は、レシピ利用者はどのレシピを詳しく見ようか迷っていることも考えられるため、長めの時間を待機することが好適となる。

なお図１４の例では経過時間の開始タイミングは、ステップＳ３１５、つまり第１レシピの一覧提示のための送信をユーザ端末３に対して行った時点としているが、これ以外の例も考えられる。
例えば第１レシピ一覧のうちの個別のレシピの詳細情報の取得要求時点や詳細情報の送信時点からタイムカウントを開始し、その後、所定時間経過によりステップＳ３２２〜Ｓ３２７が行われるような例も考えられる。
また第１レシピ一覧を表示させ、ステップＳ３１５や、検索条件受信時などをタイムカウントの開始タイミングとし、その後、特に条件付けを行わず、所定時間（例えば閾値時間ｔｈＴＭ）経過したら、必ずステップＳ３２２〜Ｓ３２６を行うようにする例も考えられる。例えばレシピ利用者が詳細情報のリクエストを行うか行わないかに関わらず、一覧提示されるレシピ数が時間経過により増加するような処理例である。
さらに時間経過により段階的にレシピ数が追加していくような処理例もあり得る。例えば１０秒経過時点でステップＳ３２２〜Ｓ３２６を行って提示レシピ数を追加し、さらに２０秒経過時点で再びステップＳ３２２〜Ｓ３２６を行って提示レシピ数を追加するような処理である。２回目以降のステップＳ３２２では、前回と異なる追加食材を設定することで、提示レシピを段階的に増やしていくことができる。

＜８．第４の実施の形態＞
第４の実施の形態のレシピ管理サーバ１の処理を図１６で説明する。なお図１６において図７、図１４と同一の処理は同一のステップ番号を付し説明を省略する。
この第４の実施の形態も、一旦、第１レシピをレシピ利用者に提示するが、その後の状況に応じて第３レシピを追加的に提示するか否かを決める例である。

図１６の処理においてレシピ管理サーバ１は、ユーザ端末３からの検索条件を受信してステップＳ３１１からＳ３１２に進んで食材情報を取得したら、ステップＳ３１３ａ、Ｓ３１３ｂ、Ｓ３１４を図１４と同様に行う。つまり第１レシピとして抽出された１又は複数のレシピによるレシピ検索結果一覧のウェブページデータを生成してユーザ端末３へ送信する。

レシピ管理サーバ１はステップＳ３１７でカウント値Ｃｒｑを０にリセットし、またステップＳ３１８で閾値ｔｈＣを設定する。カウント値Ｃｒｑはユーザ端末３からの詳細ページ要求の回数を計数した値であり、閾値ｔｈＣはカウント値Ｃｒｑと比較する値である。

レシピ管理サーバ１は、ウェブページデータの受信要求を認識した場合は、ステップＳ３３１からＳ３３２，Ｓ３３３の処理に進むことは図７、図１４と同様である。
但しこの図１６の例では、レシピ管理サーバ１はステップＳ３３４で、今回要求されたウェブページが一覧提示したレシピのうちの特定のレシピの詳細ページであったか否かを確認する。
そしてレシピの詳細ページであった場合は、ステップＳ３３６に進んで、カウント値Ｃｒｑをインクリメントする。
従って、第１レシピの一覧がユーザ端末３において提示された後、レシピ利用者が特定のレシピを選択して詳細ページ要求の操作を行う毎にカウント値Ｃｒｑが加算されていく。カウント値Ｃｒｑは、詳細ページのリクエスト回数を示したものとなる。

レシピ管理サーバ１は、ステップＳ３２１Ａでは、カウント値Ｃｒｑが閾値ｔｈＣ以上となっているか否かを確認する。
ステップＳ３２１ＡからＳ３２２に進むのは、第１レシピをユーザ端末３に提示させてから、詳細ページのリクエスト回数が閾値ｔｈＣとして設定した回数を超えた場合である。
この場合レシピ管理サーバ１はステップＳ３２２で追加食材設定処理を行う（例えば図９Ａ、図９Ｂ、図９Ｃ、図１０Ａ、図１０Ｂ参照）。そしてレシピ管理サーバ１はステップＳ３２３で追加食材を加えた検索を行って第２レシピを抽出し、ステップＳ３２４で第２レシピのうちで第３レシピを選定する（例えば図１１Ａ、図１１Ｂ参照）。
その後レシピ管理サーバ１はステップＳ３２５で追加提示レシピを選択する。つまり第３レシピを提示レシピと追加的に設定する。そしてステップＳ３２６で提示制御処理を行う。例えばそれまで提示していた第１レシピに第３レシピを追加したレシピ検索結果一覧のウェブページデータを生成してユーザ端末３へ送信する。これによりユーザ端末３では第３レシピも含めたレシピ一覧が提示される。
なおこの場合、第１レシピを含まない第３レシピのみの一覧とする例も考えられる。
そしてレシピ管理サーバ１はステップＳ３２８でカウント値Ｃｒｑをリセットする。

この図１６の処理によっては、まずレシピ利用者が食材を指定して検索要求を行った場合には、レシピ利用者には、指定した食材により料理が可能な第１レシピの一覧が提示される。しかし、その第１レシピの一覧からレシピ利用者が何度も詳細ページの要求を行なっている状況は、レシピ利用者がレシピの選択に迷っている状況であると推定する。そしてそのような場合に、第３レシピを追加したレシピ一覧を提示するものとなる。従ってレシピ利用者に対して第３レシピを新たな選択肢として有効に提示できる。

なお、ステップＳ３２１Ａでは、第１レシピの提示から一定時間内という条件も加えることも考えられる。つまり一定時間以内に所定回数以上、詳細ページのリクエストを行った場合に、ステップＳ３２２以降に進むとする例である。このようにすると、短時間に何度もリクエストしていることでレシピ利用者が迷っていると推定する確度が高くなる。

ところで、ステップＳ３１８での閾値ｔｈＣの設定については、閾値時間ｔｈＴＭの設定として図１５で説明したような例が考えられる。
即ち図１５Ａの閾値時間ｔｈＴＭのように、閾値ｔｈＣとして固定値を用いることが考えられる。

また図１５Ｂと同様に、閾値ｔｈＣを料理種別のバリエーションに応じて決めることも考えられる。即ちステップＳ８１０、Ｓ８１１、Ｓ８１２を同様に行い、その後、レシピ管理サーバ１は料理種別の偏り傾向に応じて閾値ｔｈＣの値を設定する。この場合、偏り傾向が大きいほど閾値ｔｈＣの値を小さい値にする。これは、提示されたレシピにおいて料理種別が多い場合は、詳細ページのリクエスト回数は多くなることが想定されるが、偏り傾向が高い場合は、詳細ページのリクエスト回数が少なめでも、レシピ利用者が迷っていることが想定されるためである。
このように閾値ｔｈＣの値を設定すると、第１レシピの料理種別のバリエーションに応じて、レシピ利用者の状況を適切に推定しやすくなる。
例えば第１レシピが同じような料理のレシピばかり（偏り傾向が高い）の場合、早めにレシピ利用者が迷っていると判定して、早めに追加レシピを提示できる。
一方、第１レシピとしてバリエーション豊かなレシピが含まれている場合は、レシピ利用者は多数のレシピについて詳しく見ようとすることが考えられるため、回数の閾値ｔｈＣを高くすることが好適となる。

＜９．まとめ＞
以上、実施の形態について説明してきたが、実施の形態では以下の効果が得られる。
第１〜第４の実施の形態のレシピ管理サーバ１（情報処理装置）は、選択された食材を示す食材情報を取得する食材情報取得部１ａと、食材情報取得部１ａが取得した食材情報に基づいて提示レシピを選択する提示レシピ選択部１ｂと、提示レシピ選択部１ｂが選択した提示レシピについて提示制御を行う提示制御部１ｃとを備えている。
そして提示レシピ選択部１ｂは、食材情報取得部１ａが取得した食材情報で示される食材により作成可能なレシピを第１レシピとして抽出する第１レシピ抽出処理（Ｓ４０１、Ｓ３１３ａ）を行う。また提示レシピ選択部１ｂは、食材情報取得部１ａが取得した食材情報で示される食材と追加食材により作成可能なレシピを第２レシピとして抽出する第２レシピ抽出処理（Ｓ４０３、Ｓ３２３）を行う。また提示レシピ選択部１ｂは、第２レシピのうちで、少なくとも第１レシピに含まれないという条件を含む選定条件に合致するレシピを第３レシピとして選定する第３レシピ選定処理（Ｓ４０４、Ｓ３２４）と、第１レシピと第３レシピを提示レシピとする選択処理（Ｓ４０５、Ｓ３２５）を行う。

この場合、例えばユーザ操作などにより選択された食材により作成可能な料理のレシピ（第１レシピ）が提示されるが、さらに追加する食材を想定した場合に作成可能なレシピのうちで選定されたレシピ（第３レシピ）も、ユーザ端末３において提示される。つまり第１レシピよりもバリエーションが豊かな状態で各種レシピを提示することになる。
例えばレシピ利用者が選択した食材の条件のみで抽出した第１レシピの提示を行うのみであると、食材情報によっては、非常に少数のレシピしか提示できない場合も生ずる。するとレシピ利用者にとっては満足のいくレシピ探しが行えない場合もある。そこで例えばレシピ利用者が選択した食材の情報にある程度対応した第３レシピを選定して、これも提示できるようにすることで、検索時にレシピ利用者に提示できるレシピ数を多くすることができる。
これにより例えばレシピ利用者による検索時などに多様なレシピを紹介できる。即ち、追加となる食材の数や種類を抑制しつつ、十分な数量のレシピの選択肢を提示でき、レシピ提供サービスの使用性を向上させることができる。
しかも提示されるレシピ（第１レシピ、第３レシピ）はレシピ利用者の選択等による食材情報に基づくため、レシピ利用者にとって現状で作りやすい料理のレシピとなる。
また第３レシピはレシピ利用者が指定した食材と追加食材で調理可能なレシピであるが、このようなレシピを提示させるためにレシピ利用者が追加で食材を指定する操作を行う必要はない。これによりレシピ利用者の操作負担を減少できていることになる。
従ってレシピ利用者によるレシピ選択時の充実感を向上させるとともに、短時間で容易に望みのレシピを発見できるような使用性の良いレシピ提供システムを実現できる。
またこれによって、検索のし直しなども減少することが見込まれるため、通信量の削減や、それによる通信トラフィックの有効利用を促進できる。
更に、レシピ利用者の利用するユーザ端末における限られた（例えば、モニタなどの）提示領域において、価値のある情報（レシピ）を提示することにより、ユーザ端末の資源を有効活用することができる。

実施の形態では、第１レシピ抽出処理で抽出された第１レシピを提示させた場合において、所定の条件に基づいて第２レシピ抽出処理及び第３レシピ選定処理を行って、第３レシピを提示レシピとし端末装置で提示させる例を説明した。
例えば第３の実施の形態では、レシピ管理サーバ１は、第１レシピ抽出処理で抽出された第１レシピを提示レシピとしてユーザ端末３で提示させた場合において、経過時間（タイムカウント値ＴＭ）が所定の閾値時間ｔｈＴＭを越えることを条件の１つとして、第２レシピ抽出処理及び第３レシピ選定処理を行って、第３レシピを提示レシピとし、ユーザ端末３で提示させる（図１４のＳ３２１〜Ｓ３２６）。つまり一旦はレシピ利用者に対して第１レシピとして抽出されたレシピを提示するが、第１レシピの提示のみでレシピ利用者が満足しているか否か（レシピ利用者にとって作りたいと思える料理が提示されているか否か）を経過時間により推定する。そしてレシピ利用者にとって十分なレシピ提示が行われていないと推定したときに第３レシピを追加提示する。
これによりレシピ利用者にとってのレシピ選択の幅を広げ、レシピ利用者の満足度を高めることが期待できる。またサーバとしての処理負担やトラフィック負担をむやみに増大させないことにもなる。
また例えば第４の実施の形態では、レシピ管理サーバ１は、第１レシピ抽出処理で抽出された第１レシピを提示レシピとしてユーザ端末３で提示させた場合において、提示したレシピについての個別詳細情報のリクエスト数（カウント値Ｃｒｑ）が所定の閾値ｔｈＣを越えることを条件の１つとして、第２レシピ抽出処理及び第３レシピ選定処理を行って、第３レシピを提示レシピとし、ユーザ端末３で提示させる（図１６のＳ３２１Ａ〜Ｓ３２６）。
つまり一旦はレシピ利用者に対して第１レシピとして抽出されたレシピを提示するが、第１レシピの提示のみでレシピ利用者が満足しているか否か（作る料理を決められないでいるか否か）を、提示したうちの個別のレシピの詳細情報のリクエスト数により推定する。そして料理を決められていないと推定したときに第３レシピを提示する。
例えば第１レシピを提示した場合に、提示した第１レシピのうちの多数について個別詳細情報がリクエストされる場合は、レシピ利用者が、料理を決めかねて、各レシピを詳しく確認していることが推定される。このようにレシピ利用者が迷っていると推定されるときに、追加的に第３レシピを提示できる。これによりレシピ利用者にとってのレシピ選択の幅を広げ、レシピ利用者の満足度を高めることが期待できる。またサーバとしての処理負担やトラフィック負担をむやみに増大させない利点もある。

第２の実施の形態において図１３Ｂのレシピ追加判定を行う例では、レシピ管理サーバ１は、第１レシピ抽出処理で抽出された第１レシピについて、料理種別の偏り傾向の判定を行い、偏りがあると判定した場合に、第２レシピ抽出処理及び第３レシピ選定処理を行うようにしている。
つまり第１レシピとして抽出されたレシピについて、例えば料理ジャンルや料理名の種類が少ない場合に、第３レシピも提示する。
例えば第１レシピのみで、多様な料理種別のレシピが抽出された場合は、第１レシピのみの提示でもレシピ利用者は多様な料理のレシピを選ぶことができ、十分にレシピ利用者に満足を与えることが期待できる。そこで第３レシピを提示するのは、第１レシピとして抽出された１又は複数のレシピの料理種別に偏りがある場合、つまり第１レシピのみの提示では、多様な料理種別をレシピ利用者に提案できない場合とする。
これにより常に満足度の高いレシピ提示を実現しつつ、第１レシピのみで十分な選択肢が提供できている場合には追加の処理や情報転送を行う必要は無いため、処理負担をむやみに増大させないようにすることができ、ネットワークを介して多数のレシピ利用者にレシピ提供サービスを行うサーバとして好適である。もちろんデータ通信のためのトラフィックをむやみに増大させないという点でも望ましい。

実施の形態では、第１レシピ抽出処理で抽出された第１レシピについて、料理種別の偏り傾向の判定を行い、偏り傾向に応じて設定された条件に基づいて第２レシピ抽出処理及び第３レシピ選定処理を行う例を説明した。
例えば第３の実施の形態において図１５Ｂの処理を適用する場合、第１レシピについて料理種別の偏り傾向の判定を行い、判定結果に応じて閾値時間ｔｈＴＭを設定する。つまり第１レシピとして抽出されたレシピについて、料理の種類が多いか少ないかにより閾値時間ｔｈＴＭを可変設定する。
第１レシピとして料理種別が少ない場合、レシピ利用者がどのレシピも用いないと判断するまでの時間は短くなることが通常考えられる。一方、第１レシピとして料理種別が多い場合は、レシピ利用者が選択に迷う時間が長くなることが通常考えられる。つまり第１レシピのみを提示した状態において、レシピ利用者にとって望ましいレシピが提示されていないと推定するための時間は提示された料理種別の多寡に応じたものとなりやすい。これを考慮すると、閾値時間を料理種別の偏り傾向に応じて可変設定することで、第３レシピを提示するか否かの判定を、より的確に行うようことができる。これによってレシピ利用者の満足度の高いレシピ提示を促進できる。
また第４の実施の形態においても、図１５Ｂのような処理、即ち第１レシピについて、料理種別の偏り傾向の判定を行い、判定結果に応じて閾値ｔｈＣを設定することができる。つまり第１レシピとして抽出されたレシピについて、料理の種類が多いか少ないかにより閾値時間ｔｈＴＭを可変設定する。
例えば第１レシピとして料理種別が少ない場合、レシピ利用者が個別詳細情報をリクエストする回数は、料理種別が多い場合に比べて少なくなると想定される。例えば料理種別が多ければ、各料理種別について詳細情報を確認することでリクエスト回数が増える傾向となる。このため、レシピ利用者が迷っているか否かを推定する基準は、提示したレシピの料理種別に応じて可変設定する。これにより、レシピ利用者が迷っている状況をより正確に推定し、より適切に第３レシピの提示を行うことができ、満足度の高いレシピ提示を促進できる。

第１〜第４の実施の形態に適用できる第３レシピ選定処理として、第１レシピに含まれず、かつ第１レシピと異なる属性を有するという選定条件に合致するレシピを第３レシピとして選定することを述べた（図１１Ａ、図１１Ｂ、図１１Ｃ）。
異なる属性であることを第３レシピの選定条件とすることで、第１レシピに対して料理のバリエーションを増やす方向で第３レシピを選定することができ、これにより第１及び第３レシピとして多様な料理のレシピをレシピ利用者に提示できる。
特に、図１１Ａ、図１１Ｂ、図１１Ｃで例示した属性とは、料理種別の属性、調理工程の属性、味覚属性である。このような各種属性の異なるものを第３レシピとすることで、多様な料理のレシピをレシピ利用者に提示できる。

第１〜第４の実施の形態に適用できる追加食材設定処理として、レシピ管理サーバ１が、追加食材として、取得した食材情報で示される食材と組み合わされやすい食材を選択して第２レシピ抽出処理を行う例を述べた（図９Ｂ参照）。
即ち追加食材として、例えばレシピ利用者が選択した食材との組み合わせを考慮して設定する。これによりレシピ利用者にとって作りやすい料理のレシピが第３レシピとして選定される可能性を高めることができる。

第１〜第４の実施の形態に適用できる追加食材設定処理として、レシピ管理サーバ１が、追加食材として、第１レシピが該当しない料理種別において利用されやすい食材を選択して第２レシピ抽出処理を行う例を述べた（図９Ｃ参照）。
追加食材は、第２レシピ抽出のために選択するのであるが、レシピ利用者が選択できるレシピ（料理）の幅を広げるためには、多様な料理種別のレシピが抽出できるとよい。そこで、第１レシピにおいて存在しない料理種別で利用されやすい食材を用いることで、第１レシピには含まれていないジャンルのレシピが抽出できる可能性を高めるようにする。
これにより第３レシピ提示によりレシピ利用者の料理の選択の幅を広げることができる。例えば第１レシピとされたレシピが日本料理に偏っていた場合、中華料理やイタリア料理などで用いられやすい食材を追加食材として第２レシピ抽出を行う。すると第３レシピを提示した際に多様な料理ジャンルのレシピをレシピ利用者に紹介できる。従って満足度の高いレシピ提示を促進できる。

第１〜第４の実施の形態に適用できる追加食材設定処理として、レシピ管理サーバ１が、ユーザ端末３を用いて食材を選択してレシピ提示要求を行ったレシピ利用者の購入履歴情報から、現在、そのレシピ利用者がストックしている可能性が高いと推定される食材や、現在が購入時期にあたる食材を推定する処理を行い、推定された食材を追加食材として第２レシピ抽出処理を行う例を述べた（図１０Ａ参照）
追加食材を用いた第２レシピ（第３レシピ）は、レシピ利用者が食材を用意しやすいなどの点で作りやすいものが望ましい。但し追加食材は、レシピ利用者がストックしているか否かは不明である。そこでレシピ利用者の意思に基づかない追加食材として、ストックしていると推定される食材を選択することが好適となる。
またレシピ利用者がストックしていなくても、レシピ利用者がそろそろ購入すると推定される食材であれば、レシピ利用者にとって都合がよい。追加食材はレシピ利用者にとっては購入しやすく、もしくは既に購入しているかもしれない食材である可能性も高いためである。そこで、レシピ利用者の意思に基づかない追加食材として、レシピ利用者が時期的に買いやすい食材を選択する。
これにより第３レシピ提示によりレシピ利用者が作りやすい料理のレシピを加えて提示する可能性を高めることができる。

第１〜第４の実施の形態に適用できる追加食材設定処理として、レシピ管理サーバ１が、ユーザ端末３を用いて食材を選択してレシピ提示要求を行ったレシピ利用者の購入履歴情報に基づいて、各食材についての当該レシピ利用者の購入価格上限を設定し、現在の価格が当該レシピ利用者の購入価格上限以下である食材を追加食材として第２レシピ抽出処理を行う例を述べた（図１０Ｂ参照）。
追加食材を用いた第２レシピ（第３レシピ）は、レシピ利用者がその追加食材を買いに行かなければ作れないレシピである可能性がある。一方で食材は時期によって価格が変動するが、レシピ利用者は常に食材の価格を許容することはなく、各種食材について購入価格範囲（上限）を持っている。例えば「キャベツは２５０円以上となったら買わない」などである。そこで現在の価格が、レシピ利用者の購入履歴における購入価格上限以下にある食材を追加食材として選択する。
これにより第３レシピは、レシピ利用者が購入してもよいと考える食材を用いたレシピ、つまりレシピ利用者が作りやすい料理のレシピとなる可能性を高めることができる。

なお本発明の情報処理装置の構成や処理は上記実施の形態で言及した物に限定されず、さらに多様な変形例が想定される。

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

実施の形態のプログラムは、選択された食材を示す食材情報を取得する食材情報取得手順（Ｓ３１２）と、食材情報取得手順で取得した食材情報で示される食材により作成可能なレシピを第１レシピとして抽出する第１レシピ抽出手順（Ｓ４０１、Ｓ３１３ａ）と、食材情報取得手順で取得した食材情報で示される食材と追加候補食材により作成可能なレシピを第２レシピとして抽出する第２レシピ抽出手順（Ｓ４０３、Ｓ３２３）と、第２レシピのうちで、少なくとも前記第１レシピに含まれないという条件を含む選定条件に合致するレシピを第３レシピとして選定する第３レシピ選定手順（Ｓ４０４、Ｓ３２４）と、第１レシピ抽出手順で抽出した第１レシピと第３レシピ選定手順で選定した第３レシピとについて提示制御を行う提示制御手順（Ｓ３１４、Ｓ３２６）と、を情報処理装置に実行させる。
即ちこのプログラムは、情報処理装置に対して図７〜図１６で説明した各実施の形態の処理を実行させるプログラムである。

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

１ レシピ管理サーバ、１ａ 食材情報取得部、１ｂ 提示レシピ選択部、１ｃ 提示制御部、１ｄ レシピ管理部、２ ネットワーク、３ ユーザ端末、４ ＥＣサーバ、５０ レシピＤＢ、５１ ユーザＤＢ、５２ 検索ＤＢ、５３ 食材ＤＢ、５４ 商品ＤＢ

Claims (10)

1. 選択された食材を示す食材情報を取得する食材情報取得部と、
   前記食材情報取得部が取得した食材情報に基づいて提示レシピを選択する提示レシピ選択部と、
   前記提示レシピ選択部が選択した提示レシピについて提示制御を行う提示制御部と、
   を備え、
   前記提示レシピ選択部は、
   前記食材情報取得部が取得した食材情報で示される食材により作成可能なレシピを第１レシピとして抽出する第１レシピ抽出処理と、
   前記食材情報取得部が取得した食材情報で示される食材と追加食材により作成可能なレシピを第２レシピとして抽出する第２レシピ抽出処理と、
   前記第２レシピのうちで、少なくとも前記第１レシピに含まれないという条件を含む選定条件に合致するレシピを第３レシピとして選定する第３レシピ選定処理と、
   前記第１レシピと前記第３レシピを前記提示レシピとする選択処理を行う
   情報処理装置。
2. 前記提示レシピ選択部は、
   前記第１レシピ抽出処理で抽出された第１レシピを提示レシピとして、前記提示制御部によって端末装置で提示させた場合において、所定の条件に基づいて前記第２レシピ抽出処理及び前記第３レシピ選定処理を行って、前記第３レシピを提示レシピとし、前記提示制御部によって端末装置で提示させる
   請求項１に記載の情報処理装置。
3. 前記提示レシピ選択部は、
   前記第１レシピ抽出処理で抽出された第１レシピについて、料理種別の偏り傾向の判定を行い、偏り傾向に応じて設定された条件に基づいて前記第２レシピ抽出処理及び前記第３レシピ選定処理を行う
   請求項１又は請求項２に記載の情報処理装置。
4. 前記提示レシピ選択部は、
   前記第３レシピ選定処理において、前記第１レシピに含まれず、かつ前記第１レシピと異なる属性を有するという選定条件に合致するレシピを第３レシピとして選定する
   請求項１乃至請求項３のいずれかに記載の情報処理装置。
5. 前記提示レシピ選択部は、
   前記追加食材として、前記食材情報取得部が取得した食材情報で示される食材と組み合わされやすい食材を選択して前記第２レシピ抽出処理を行う
   請求項１乃至請求項４のいずれかに記載の情報処理装置。
6. 前記提示レシピ選択部は、
   前記追加食材として、前記第１レシピが該当しない料理種別において利用されやすい食材を選択して前記第２レシピ抽出処理を行う
   請求項１乃至請求項４のいずれかに記載の情報処理装置。
7. 前記提示レシピ選択部は、
   端末装置を用いて食材を選択してレシピ提示要求を行ったユーザの購入履歴情報から、現在が購入時期にあたる食材を推定する処理を行い、推定された食材を前記追加食材として前記第２レシピ抽出処理を行う
   請求項１乃至請求項４のいずれかに記載の情報処理装置。
8. 前記提示レシピ選択部は、
   端末装置を用いて食材を選択してレシピ提示要求を行ったユーザの購入履歴情報に基づいて、各食材についての当該ユーザの購入価格上限を設定し、現在の価格が当該ユーザの購入価格上限以下である食材を前記追加食材として前記第２レシピ抽出処理を行う
   請求項１乃至請求項４のいずれかに記載の情報処理装置。
9. 情報処理装置が実行する情報処理方法として、
   選択された食材を示す食材情報を取得する食材情報取得ステップと、
   前記食材情報取得ステップで取得した食材情報で示される食材により作成可能なレシピを第１レシピとして抽出する第１レシピ抽出ステップと、
   前記食材情報取得ステップで取得した食材情報で示される食材と追加食材により作成可能なレシピを第２レシピとして抽出する第２レシピ抽出ステップと、
   前記第２レシピのうちで、少なくとも前記第１レシピに含まれないという条件を含む選定条件に合致するレシピを第３レシピとして選定する第３レシピ選定ステップと、
   前記第１レシピ抽出ステップで抽出した第１レシピと、前記第３レシピ選定ステップで選定した第３レシピとについて提示制御を行う提示制御ステップと、
   を行う
   情報処理方法。
10. 選択された食材を示す食材情報を取得する食材情報取得手順と、
    前記食材情報取得手順で取得した食材情報で示される食材により作成可能なレシピを第１レシピとして抽出する第１レシピ抽出手順と、
    前記食材情報取得手順で取得した食材情報で示される食材と追加食材により作成可能なレシピを第２レシピとして抽出する第２レシピ抽出手順と、
    前記第２レシピのうちで、少なくとも前記第１レシピに含まれないという条件を含む選定条件に合致するレシピを第３レシピとして選定する第３レシピ選定手順と、
    前記第１レシピ抽出手順で抽出した第１レシピと、前記第３レシピ選定手順で選定した第３レシピとについて提示制御を行う提示制御手順と、
    を情報処理装置に実行させるプログラム。

Images