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

Abstract

推定されるユーザのニーズに対して相対的に不足しているレシピ情報を拡充するための環境を提供する。そのために情報処理装置は、レシピに関する情報を検索するために用いられる少なくとも２以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得部と、前記取得した複合検索条件に対応する検索結果数を取得する検索部と、前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定部と、前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定部と、前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理部と、前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御部と、を備える。

Description

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

　本発明は、レシピを管理する情報処理装置、情報処理方法及びプログラムについての技術分野に関する。詳しくは、ユーザにレシピを投稿させるための各種処理に関する。

特開２００２－０９２０３３号公報

　近年では、一般ユーザの投稿などによって蓄積されたレシピの情報を提供するレシピ検索サービスなどが普及している。
　特許文献１には、ユーザが入力した表現から抽出されたキーワードのうち不必要に厳しい条件を課すものを削除して緩和された検索条件に基づいて検索を行う技術について記載されている。

　しかし、ユーザから取得した検索リクエスト数などから推定されるユーザのニーズに対して十分な量の情報（即ちレシピ情報）が提供されていない場合がある。
　例えば、特許文献１に記載の技術は、ユーザの入力した表現からキーワードの一部を削除するものであるため、ユーザのニーズ（具体的にはユーザが入力した全てのキーワード）に合致する情報を提供することについては考慮されていない
　そこで、本発明は、推定されるユーザのニーズに対して相対的に不足しているレシピ情報を拡充するための環境を提供することを目的とする。

　本発明に係る情報処理装置は、レシピに関する情報を検索するために用いられる少なくとも２以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得部と、前記取得した複合検索条件に対応する検索結果数を取得する検索部と、前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定部と、前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定部と、前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理部と、前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御部と、を備えている。
　これにより、ユーザの潜在的なニーズが汲み取られて、相対的に不足しているレシピの特定がなされる。

　上記した情報処理装置の前記支援対象決定部は、前記複合検索条件の前記被検索回数に対する検索結果数の割合と、前記複合検索条件の検索結果数に応じて特定された閾値と、に基づいて複合検索条件を支援対象とするか否かを決定してもよい。
　これにより、被検索回数に対して複合検索条件の検索結果数の割合が所定値以下となる複合検索条件を支援対象検索条件とすることが可能となる。

　上記した情報処理装置の前記支援対象決定部は、前記複合検索条件の前記被検索回数に対する検索結果数の割合と、前記複合検索条件に対応する検索結果に含まれる各レシピの被利用回数に応じて特定された閾値と、に基づいて複合検索条件を支援対象とするか否かを決定してもよい。
　これにより、検索結果に含まれる各レシピの中に、ユーザの要望を満たすレシピのの多寡に応じて閾値が特定される。

　上記した情報処理装置の前記支援対象決定部は、前記複合検索条件に対応する検索結果に含まれる各レシピの被利用回数が前記被検索回数に対して少ないほど高い閾値を特定してもよい。
　被検索回数に対して検索結果としてのレシピの被利用回数が少ない場合、検索操作を行ったにも関わらず、所望のレシピが提示されずにレシピ検索を諦めた（若しくは他の検索条件を設定したレシピ検索を再度行った）ユーザが多い可能性が高い。
　このような場合に、高い閾値を特定することは、当該複合検索条件が支援対象検索条件として選択される可能性が高くなる。

　上記した情報処理装置の前記支援対象決定部は、前記複合検索条件の所定期間における被検索回数の変化が大きいほど高い閾値を特定してもよい。
　例えば、被検索回数の変化が短時間に増大した場合などは、ニーズが急激に増加していることが推測される。このような状態において高い閾値を特定することは、当該複合検索条件が支援対象検索条件として選択される可能性が高くなる。

　上記した情報処理装置の前記支援対象決定部は、前記複合検索条件に対応する前記被検索回数に対する検索結果数の割合が他の前記複合検索条件に対応する検索回数に対する検索結果数の割合に対して相対的に少ない複合検索条件を前記支援対象として決定してもよい。
　これにより、例えば、類似する複合検索条件が複数あった場合に、相対的にレシピ数の足りていない複合検索条件が支援対象検索条件とされる。

　上記した情報処理装置の前記支援対象決定部は、前記前記第一部分検索条件に対応する検索結果数が多い複合検索条件ほど高い優先度を付与し、前記送信制御部は、相対的に高い優先度を付与された前記複合検索条件に基づく依頼情報が優先的に送信されるように制御してもよい。
　これにより、アレンジ対象レシピの候補となるレシピが多く検索される複合検索条件の優先度が高くなる。換言すれば、アレンジ対象レシピが多くなる。

　上記した情報処理装置の前記アレンジ対象決定部は、前記支援対象として決定された複合検索条件に含まれるキーワード毎に優先度を特定し、当該特定された優先度が相対的に高いキーワードを含む前記第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定してもよい。
　これにより、優先度が相対的に高いキーワード（例えば主要食材）が既に含まれるレシピがアレンジ対象レシピとして抽出される。

　本発明に係る情報処理方法は、レシピに関する情報を検索するために用いられる少なくとも２以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得ステップと、前記取得した複合検索条件に対応する検索結果数を取得する検索ステップと、前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定ステップと、前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定ステップと、前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理ステップと、前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御ステップと、を備えたものである。
　この情報処理方法により、推定されるユーザのニーズに対して相対的に不足しているレシピ情報を拡充するための環境を提供する。
　本発明に係るプログラムは、上記情報処理方法として実行する処理を情報処理装置に実行させるプログラムである。これらのプログラムにより上記の情報処理装置を実現する。

　本発明によれば、推定されるユーザのニーズに対して相対的に不足しているレシピ情報を拡充するための環境を提供することができる。

本発明の実施の形態の情報処理装置を含む全体構成を示す説明図である。 レシピ管理サーバの機能構成を示す図である。 コンピュータ装置のブロック図である。 処理の流れの一例を示す図である。 バッチ処理の第１例を示すフローチャートである。 複合検索条件取得処理を示すフローチャートである。 支援対象検索条件決定処理を示すフローチャートである。 アレンジ対象レシピ決定処理を示すフローチャートである。 支援依頼対象ユーザ特定処理を示すフローチャートである。 支援依頼対象ユーザ特定処理の別の例を示すフローチャートである。 支援依頼対象ユーザ特定処理の更に別の例を示すフローチャートである。 複合検索条件取得処理の第２例を示すフローチャートである。 支援対象検索条件決定処理の第２例を示すフローチャートである。 アレンジ対象レシピ決定処理の第２例を示すフローチャートである。 バッチ処理の第２例を示すフローチャートである。 特典付与処理を示すフローチャートである。

　以下、実施の形態を次の順序で説明する。
＜１．全体構成＞
＜２．ハードウェア構成＞
＜３．ＤＢ＞
［３－１．ユーザＤＢ］
［３－２．レシピＤＢ］
［３－３．検索ＤＢ］
［３－４．履歴ＤＢ］
［３－５．ウェブページＤＢ］
＜４．処理の流れ＞
［４－１．全体の流れ］
［４－２．バッチ処理の第１例］
［４－３．複合検索条件取得処理第２例］
［４－４．支援対象検索条件決定処理第２例］
［４－５．アレンジ対象レシピ決定処理第２例］
［４－６．バッチ処理の第２例］
［４－７．特典付与処理］
＜５．まとめ＞
＜６．プログラム及び記憶媒体＞

＜１．全体構成＞

　先ず、本発明の実施の形態における全体構成を説明する。
　尚、以下の説明においては、レシピとして料理レシピ（以降では単にレシピという）を例に挙げて説明する。レシピには、調理手順や使用食材や調理器具などの情報が含まれている。
　また、検索クエリに応じたレシピの検索やレシピの投稿などが可能なサービスを提供するためのポータルサイトとして、レシピ管理サーバ１が運営するレシピサイトを例に挙げる。

　本発明の情報処理装置を含む全体構成を図１に示す。
　レシピ管理サーバ１は、通信ネットワーク２を介して、ユーザ端末３，３，３，・・・と相互に通信可能な状態で接続されている。また、レシピ管理サーバ１は、ユーザに関する情報が記憶されるユーザＤＢ（Database）５０、レシピに関する情報が記憶されるレシピＤＢ５１、検索クエリや検索結果の情報が記憶される検索ＤＢ５２、ユーザによる各種操作の履歴が記憶される履歴ＤＢ５３、レシピサイトを構成する各種ウェブページのウェブページデータが記憶されるウェブページＤＢ５４と接続されている。
　尚、以降の説明において単に「ユーザ」と記載した場合は、投稿ユーザや支援依頼対象ユーザ（後述）やその他のユーザを区別せずに全てのユーザを指すものとする。
　尚、レシピ管理サーバ１は、本発明の情報処理装置の実施の形態に相当する。

　レシピ管理サーバ１は、ユーザから投稿されるレシピを管理する処理や、検索クエリに応じたレシピを提示するための処理を行う情報処理装置である。具体的な構成に関しては後述する。

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

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

　レシピ管理サーバ１は、図２に示すように、レシピ管理部１ａ、検索情報取得部１ｂ、検索部１ｃ、支援対象決定部１ｄ、アレンジ対象決定部１ｅ、ユーザ管理部１ｆ、送信制御部１ｇを備えている。

　レシピ管理部１ａは、ユーザが投稿したレシピ情報（レシピタイトルと使用食材と調理方法とレシピが属するカテゴリ情報などがレシピ情報を投稿したユーザを識別する識別情報と紐付けられた情報）をレシピＤＢ５１に記憶することにより管理する。例えば、あるユーザが投稿した「野菜カレー」のレシピは、カテゴリ「カレーライス」に属するレシピであり、使用食材情報として、「じゃがいも」、「人参」、「タマネギ」、「ブロッコリー」、「トマト」、「ほうれん草」や、調味料（「塩」や「胡椒」など）や、それに準ずるもの（例えば「カレールー」など）が紐付けられて記憶される。

　また、レシピ管理部１ａは、投稿されたレシピに対して投稿された作成レポートをレシピ毎に管理する。作成レポートは、投稿されたレシピを利用して他のユーザが実際に料理を行った際に、当該レシピに対する感想（例えば、料理を行ったユーザが感じた料理のおいしさや調理手順の手軽さなど）を記したレポートである。作成レポートは、レシピＤＢ５１の各レシピに紐付けられて管理される。

　更にまた、レシピ管理部１ａは、レシピや作成レポートの投稿に関する処理や、レシピのアレンジを行ったユーザに対する特典付与に関する処理を実行する。
　特典付与の例については後述する。

　検索情報取得部１ｂは、検索クエリが検索に用いられた回数を取得する検索情報取得処理を実行する。

　検索部１ｃは、検索クエリに応じた検索結果を抽出する検索処理を実行する。このとき、抽出されたレシピの数を検索結果数として取得する。
　尚、以下の説明では、検索クエリに含まれるキーワードを単に「キーワード」と記載する。また、「キーワード」の一例として食材（例えば「ニンジン」や「トマト」など）を挙げるが、それ以外にも料理名（「ハンバーグ」や「カレー」など）や調味料や調理方法や調理器具などが「キーワード」とされてもよい。

　更に、複数のキーワードを含む検索クエリを「複合検索条件」とする。例えば、キーワードＫ１，Ｋ２，Ｋ３を含む検索クエリ「Ｋ１，Ｋ２，Ｋ３」は複合検索条件である。

　そして、複合検索条件の一部のキーワードのみを含む検索クエリを「第一部分検索条件」とし、残りのキーワードを「第二部分検索条件」とする。具体的には、複合検索条件「Ｋ１，Ｋ２，Ｋ３」の第一部分検索条件は、「Ｋ１」、「Ｋ２」、「Ｋ３」、「Ｋ１，Ｋ２」、「Ｋ１，Ｋ３」、「Ｋ２，Ｋ３」の６種類を挙げることができる。それぞれの第一部分検索条件に対して第二部分検索条件が存在し、例えば、第一部分検索条件としての「Ｋ１」に対する第二部分検索条件は「Ｋ２，Ｋ３」とされる。また、第一部分検索条件としての「Ｋ１，Ｋ２」に対する第二部分検索条件は「Ｋ３」とされる。

　また、キーワードを羅列した検索クエリ以外の例も考えられる。例えば、「食材Ａと食材Ｂを使った料理Ｃ」などの文である。この場合には、「食材Ａ」、「食材Ｂ」、「料理Ｃ」がキーワードとされ、第一部分検索条件としては「食材Ａ，料理Ｃ」や「食材Ａ」などとされる。そして、第一部分検索条件としての「食材Ａ，料理Ｃ」に対する第二部分検索条件は「食材Ｂ」とされる。
　このような文からキーワードを抽出するために、レシピ管理サーバ１はキーワードが登録されたキーワードＤＢを利用してもよい。
　検索部１ｃは、後述する各種の処理において、これらの第一部分検索条件を用いた検索処理や第二部分検索条件を用いた検索処理を実行する。

　支援対象決定部１ｄは、検索クエリの被検索回数と検索結果数に応じて複合検索条件のうちから支援対象とする検索条件（支援対象検索条件）を決定する。支援対象検索条件は、検索結果数を増加させるための支援の対象とされた検索クエリであり、例えば、被検索回数に対して検索結果数が少ない（即ち、ニーズがある検索クエリであるにも関わらず抽出されるレシピ数が少ない）検索クエリなどである。詳しくは後述する。
　また、支援対象決定部１ｄは、複合検索条件に優先度を付与し、優先度の高い複合検索条件を支援対象検索条件として選択する場合がある。他にも、決定した支援対象検索条件が複数ある場合には、以降の処理の順番を決定するための優先度を付与してもよい。

　アレンジ対象決定部１ｅは、支援対象検索条件（複合検索条件のうち検索結果数を増加させるための支援が必要とされたもの）の第一部分検索条件を用いた検索処理によって抽出されたレシピを「アレンジ対象レシピ」として決定する処理を実行する。
　アレンジ対象レシピとは、後述する処理で選択した支援依頼対象ユーザに対してレシピのアレンジを依頼する場合において、アレンジ対象とされたレシピである。
　具体的に、支援対象検索条件として「Ｋ１，Ｋ２，Ｋ３」という複合検索条件が選ばれたとする。そして第一部分検索条件としての「Ｋ１，Ｋ２」を用いた検索処理によってレシピ「Ｒ１」、「Ｒ２」が抽出されたとする。レシピ「Ｒ１」及び「Ｒ２」は、例えば、キーワード「Ｋ１」及び「Ｋ２」を含むが「Ｋ３」を含まないレシピである。即ち、支援対象検索条件に基づく検索結果としては抽出されないが、第一部分検索条件に基づく検索結果としては抽出されるレシピである。
　このようなレシピ「Ｒ１」、「Ｒ２」がアレンジ対象レシピとして決定される。

　ユーザ管理部１ｆは、ユーザ情報をユーザＤＢ５０に記憶することによって管理する。
　また、支援対象検索条件の「第二部分検索条件」を用いた検索処理によって抽出されたレシピを投稿したユーザを「支援依頼対象ユーザ」として特定するユーザ特定処理を実行する。
　具体的に、支援対象検索条件として「Ｋ１，Ｋ２，Ｋ３」という複合検索条件が選ばれたとする。そして第一部分検索条件としての「Ｋ１，Ｋ２」が選択された場合、第二部分検索条件は「Ｋ３」とされ、「Ｋ３」に基づいてレシピ「Ｒ３」、「Ｒ４」が抽出されたとする。
　レシピ「Ｒ３」、「Ｒ４」は、例えば、キーワード「Ｋ３」を含むが「Ｋ１」及び「Ｋ２」は含まないレシピである。
　このようなレシピ「Ｒ３」を投稿したユーザや「Ｒ４」を投稿したユーザを支援依頼対象ユーザとして選択する。
　レシピ「Ｒ３」や「Ｒ４」を投稿したユーザは、キーワード「Ｋ３」に関する料理が得意である可能性がある。即ち、キーワード「Ｋ３」が食材であった場合、食材「Ｋ３」を用いた料理が得意と推測されるユーザであり、キーワード「Ｋ３」が調理器具であった場合は、調理器具「Ｋ３」を用いた料理が得意と推測されるユーザである。
　ユーザ特定処理は、そのようなユーザを支援依頼対象ユーザとして特定するための処理である。
　支援依頼対象ユーザの選択についてのいくつかの具体的な例は後述する。

　送信制御部１ｇは、支援依頼対象ユーザに対して、第二部分検索条件によって抽出されるようなレシピの生成を依頼する情報を送信する。例えば、アレンジ対象レシピに第二部分検索条件を加えた「アレンジレシピ」の投稿を依頼するための情報である。
　以降の説明においては、このような情報を「アレンジ依頼情報」と記載する。
　先の例を用いて説明すると、支援依頼対象ユーザ（レシピ「Ｒ３」や「Ｒ４」を投稿したユーザ）に対して、レシピ「Ｒ１」，「Ｒ２」にキーワード「Ｋ３」を加えたアレンジレシピの投稿を依頼するための情報が、アレンジ依頼情報とされる。

　アレンジ依頼情報通知処理の実現手段としては、いくつかの例を挙げることができる。
　例えば、電子メールによって、アレンジ依頼情報を支援依頼対象ユーザに通知してもよい。また、レシピサイト上にアレンジ依頼情報を通知するためのメッセージを表示してもよい。更に、レシピサイトを閲覧するための専用アプリケーションを利用しているユーザに対して、プッシュ通知による通知を行ってもよい。

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

＜２．ハードウェア構成＞

　図３は、図１に示したレシピ管理サーバ１とユーザ端末３のハードウェア、及び、ユーザＤＢ５０とレシピＤＢ５１と検索ＤＢ５２と履歴ＤＢ５３とウェブページＤＢ５４のハードウェアを例示する図である。それぞれのサーバや端末、ＤＢにおけるコンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ（Read Only Memory）１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ（Random Access Memory）１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
　ＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インターフェース１０５も接続されている。
　入出力インターフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力装置１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどよりなる出力装置１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、通信ネットワーク２を介しての通信処理や機器間通信を行う通信部１０９が接続されている。
　入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

　このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
　ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、レシピ管理サーバ１とユーザ端末３、ユーザＤＢ５０とレシピＤＢ５１と検索ＤＢ５２と履歴ＤＢ５３とウェブページＤＢ５４のそれぞれにおいて後述する情報処理や通信が実行される。
　尚、レシピ管理サーバ１とユーザ端末３、ユーザＤＢ５０とレシピＤＢ５１と検索ＤＢ５２と履歴ＤＢ５３とウェブページＤＢ５４を構成するそれぞれの情報処理装置は、図３のようなコンピュータ装置が単一で構成されることに限らず、システム化された複数のコンピュータ装置によって構成されてもよい。複数のコンピュータ装置は、ＬＡＮなどによりシステム化されていてもよいし、インターネットなどを利用したＶＰＮ（Virtual Private Network）などにより通信可能な状態で遠隔地に配置されたものでもよい。

　レシピ管理サーバ１としての各機能は、情報処理装置においてＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し以下において説明する各構成の処理の全部又は一部をハードウェアにより実現してもよい。
　また各機能をソフトウエアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。１つのプログラムにより複数の機能の処理が実行されてもよいし、１つの機能が複数のプログラムモジュールの連携で実現されてもよい。

＜３．ＤＢ＞

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

［３－１．ユーザＤＢ］
　ユーザＤＢ５０にはレシピ管理サーバ１が提供するサービスを受けるユーザの情報が記憶される。例えば、一人のユーザを特定可能な一つのユーザＩＤ（Identification）に対して、ログインパスワード、氏名、年齢、性別、メールアドレスなどの個人的な情報が紐付けられて記憶される。また、ユーザ毎の嗜好情報が記憶されてもよい。嗜好情報は、ユーザによるレシピ情報や料理情報に関する検索や閲覧などの挙動に応じてレシピ管理サーバ１が判定したユーザの好みの食材（嗜好食材）や嫌いな食材（非嗜好食材）の情報や、ユーザに関わる投稿情報（テキスト情報やタグ情報や画像情報など）に基づいてレシピ管理サーバ１が判定したユーザの好みの食材（嗜好食材）や嫌いな食材（非嗜好食材）である。また、嗜好情報はユーザによって任意に登録された情報であってもよい。嗜好情報は、ユーザがレシピ検索を行った際に利用される。

［３－２．レシピＤＢ］
　レシピＤＢ５１は、ユーザから投稿されたレシピの情報が記憶されるＤＢである。具体的には、それぞれのレシピを識別可能なレシピＩＤに対して、レシピを投稿したユーザを特定するユーザＩＤと、投稿日時情報と、レシピが属するカテゴリ情報と、レシピの使用食材情報（分量などを含む）と、レシピの調理手順と、料理画像（完成した料理の画像や調理途中の料理の画像）などの画像情報と、レシピを実際に利用した（料理を作成した）他のユーザによって投稿された作成レポートを特定する作成レポートＩＤと、が紐付けられて記憶される。

　また、レシピの詳細ページのＵＲＬ（Uniform Resource Locator）情報がレシピＩＤに紐付けられて記憶されてもよい。
　更に、レシピＤＢ５１には、各レシピに対して投稿された作成レポートの情報が記憶される。作成レポートの情報としては、レポート内容を示すテキストデータや調理した料理の画像や投稿者を識別可能なユーザＩＤや投稿日時情報などが記憶される。

　尚、上述したアレンジレシピの情報は、作成レポートとは別にアレンジレシピ情報として記憶されてもよいし、作成レポートのレポート内容を解析して当該作成レポートをアレンジレシピ情報として扱ってもよい。
　具体的には、レポート内容として「トマトを加えたらより一層おいしくなりました。」という一文があった場合、当該作成レポートをアレンジレシピとして扱う。即ち、第二部分検索条件として「トマト」が指定された場合に、当該アレンジレシピの投稿ユーザは、「トマト」を用いたレシピが得意なユーザ（上述した支援依頼対象ユーザ）とされてもよい。
　このとき、キーワード「トマト」に関するアレンジレシピであることを記憶することにより、支援依頼対象ユーザの検索をする毎のアレンジレシピの内容の解析が不要となる。

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

［３－４．履歴ＤＢ］
　履歴ＤＢ５３には、ユーザの操作に関する各種履歴が記憶される。
　具体的には、ユーザが行った操作毎に、ユーザＩＤ、履歴ＩＤ、操作種別、操作対象（「レシピ閲覧操作」や「レシピ印刷操作」であれば閲覧対象となったレシピＩＤ、「ウェブページを閲覧する操作」であれば対象となったウェブページを特定する情報、「投稿操作」であれば、投稿されたレシピＩＤや作成レポートＩＤ、「ユーザ情報変更操作」であれば変更対象となった項目名など）、操作日時、操作結果（「ログイン操作」であればログイン可否、「ユーザ情報変更操作」であれば変更可否などが記憶される。

［３－５．ウェブページＤＢ］
　ウェブページＤＢ５４には、レシピ管理サーバ１がユーザに提供する各種ウェブページのデータが記憶される。具体的には、レシピ検索ページや特集ページや検索結果ページやレシピ詳細ページやユーザページなどのウェブページデータである。
　ウェブページデータとしては、ウェブページのＵＲＬ（Uniform Resource Locator）情報と各ウェブページ上に配置されるオブジェクト（画像やテキストやバナーなど）の配置情報が記憶される。配置情報とは、ウェブページ上における各オブジェクトの配置態様（位置や大きさ、色等）が記載された情報である。
　尚、ウェブページＤＢ５４に記憶される情報は、例えば、ＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible HyperText Markup Language）などの構造化文書ファイルで記憶されてもよい。

＜４．処理の流れ＞

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

［４－１．全体の流れ］
　先ずは、レシピ管理サーバ１とユーザ端末３の間で行われる各種処理や情報の送受信について、図４を参照して説明する。
　具体的には、レシピ管理サーバ１が提供する各種サービスを受けるために、ユーザがユーザ端末３を用いてログイン操作を行い、レシピを検索して利用する例を説明する。

　ユーザ端末３はステップＳ１０１において、ユーザによるログイン画面表示操作（即ちログイン画面を表示させる操作）に応じたログイン画面情報要求処理を実行する。

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

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

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

　尚、図４に示す一連の流れは、ステップＳ２０２の認証処理においてログイン可と判定された場合を示している。ステップＳ２０２においてログイン不可と判定した場合は、ユーザ端末３は再度ステップＳ１０２の処理を実行し、これに応じてレシピ管理サーバ１はステップＳ２０２の処理を実行する。

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

　検索クエリを受信したレシピ管理サーバ１は、ステップＳ２０５で検索クエリと検索ＤＢ５２に記憶された情報に基づいてレシピの検索結果を抽出（取得）する検索処理を実行する。
　更に、レシピ管理サーバ１はステップＳ２０６において、検索履歴を履歴ＤＢ５３に記憶する検索履歴記憶処理を実行する。
　尚、検索クエリが検索された回数を示す被検索回数を管理している場合には、検索履歴記憶処理を実行する際に被検索回数を加算する処理を行う。

　続いて、レシピ管理サーバ１はステップＳ２０７において、ステップＳ２０５で抽出した検索結果をユーザ端末３上に表示させるための提示処理を実行する。この処理では、例えば、提示優先度情報が含まれた検索結果をユーザ端末３へ送信する。

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

　選択レシピ情報を受信したレシピ管理サーバ１は、ステップＳ２０８において、レシピの詳細ページの閲覧履歴を履歴ＤＢ５３に記憶する処理を実行し、続くステップＳ２０９において、選択されたレシピの詳細情報が記載されたウェブページのデータを送信する詳細情報送信処理を実行する。
　この処理によって、ユーザ端末３上に、ユーザが選択したレシピに関する詳細情報が提示される。詳細情報とは、例えば、レシピに使用する食材情報や調理手順、調理器具情報などの情報である。他にも、選択されたレシピに対して投稿された作成レポートの情報などを含んでいてもよい。

　ユーザ端末３上に詳細情報が表示されたレシピに対し、ユーザが利用したことを推定可能な操作を行った場合、利用したことを推定可能な操作に関する情報がレシピ管理サーバ１に対して送信される。
　例えば、図４に示すように、レシピの利用が推定される操作として、レシピの詳細情報を印刷するための操作を行った場合、ユーザ端末３はステップＳ１０５において、印刷操作に関する情報をレシピ管理サーバ１に送信する処理を実行する。
　印刷操作に関する情報とは、操作を行ったユーザのユーザＩＤと印刷対象とされたレシピのレシピＩＤなどである。

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

［４－２．バッチ処理の第１例］
　検索クエリに基づいて検索されるレシピの数を増加（充実）させるためにレシピ管理サーバ１が実行する処理について説明する。
　尚、この処理は、ユーザ端末３から検索クエリを受信したタイミングで行ってもよいが、処理に要する時間（即ちレシピ管理サーバ１の処理能力）によっては検索結果を迅速にユーザに提示することができなくなるため、好ましくない場合がある。
　ここでは、バッチ処理によって定期的に処理を実行する例を説明する。こうすることにより、レシピサイトの利用が少ない時間帯などに処理を行うことが可能となる。

　先ず、バッチ処理の第１例について、図５乃至図１１の各図を参照して説明する。
　レシピ管理サーバ１は、ステップＳ３０１において、複合検索条件を取得する処理を実行する。複合検索条件取得処理について、図６に示す。

　複合検索条件は二つ以上のキーワードを含む検索クエリであり、前述のように「トマト、ニンジン」や「トマトを使ったハンバーグ」などの検索クエリである。
　図６に示すように、先ずレシピ管理サーバ１はステップＳ４０１において、所定期間内に検索に用いられた検索クエリ（複合検索条件とは限らない検索クエリ）を履歴ＤＢ５３から一つ取得する処理を実行する。
　取得した一つの検索クエリに対して、レシピ管理サーバ１はステップＳ４０２において、複合検索条件であるか否か（即ち二つ以上のキーワードを含んでいるか否か）を判定する処理を実行する。

　取得検索クエリが複合検索条件である場合、レシピ管理サーバ１はステップＳ４０３において、当該検索クエリを処理対象の複合検索条件として選択する。処理対象とは、図５に示す以降の各処理の対象となることを示す。

　ステップＳ４０３の処理の後、或いは、ステップＳ４０２において複合検索条件でないと判定した後、レシピ管理サーバ１はステップＳ４０４において、検索クエリの取得が終了したか（即ち所定期間内に検索された他の検索クエリはないか）を判定する処理を実行する。
　検索クエリの取得が終了した場合、即ち、所定期間内に検索された全ての検索クエリに対して複合検索条件であるか否かを判定する処理を実行した場合、レシピ管理サーバ１は図６に示す一連の処理を終了する。
　一方、検索クエリの取得が終了していない場合、レシピ管理サーバ１は再びステップＳ４０１の処理を実行する。

　図５の説明に戻る。
　一または複数の複合検索条件（ステップＳ４０３において処理対象の複合検索条件として選択されたもの）を取得したレシピ管理サーバ１は、ステップＳ３０２において、複合検索条件毎の検索情報として被検索回数を取得する処理を実行する。被検索回数とは、前述のように、複合検索条件が検索クエリとして用いられた回数を表す。
　被検索回数は、履歴ＤＢ５３から取得する。また、検索ＤＢ５２に検索クエリ毎の被検索回数が記憶されている場合には、検索ＤＢ５２から取得してもよい。

　ここで、被検索回数についていくつかの例を説明する。
　被検索回数は、検索リクエスト毎に加算されるものであってもよい。即ち、同じユーザが同一の検索クエリを用いた複数回の検索を行った場合であっても被検索回数に全て加算される。
　また、被検索回数は、単位時間（単位期間）毎のユニークユーザ（重複しないユーザであり、換言すれば、異なるユーザＩＤが付与されたユーザ）による検索リクエストの回数（同一ユーザによる検索リクエストは１回としてカウントした回数）であってもよい。即ち、単位時間を仮に１週間とした場合、同一ユーザが一週間に同一検索クエリを用いた検索を５回行ったとしても、被検索回数としては１回分として加算される。そして、同一検索クエリを用いた一週間に１回の検索を三週間に亘り行った場合、被検索回数としては３回分として加算される。
　更に、被検索回数は、ユーザ毎に最大１回まで加算されることとしてもよい。即ち、同一ユーザによる同一検索クエリを用いた検索は、何度行っても１回とされる。換言すれば、被検索回数が１００回のレシピは、これまでに１００人の異なるユーザが閲覧したこととなる。

　被検索回数を取得したレシピ管理サーバ１は、続くステップＳ３０３において、処理対象の複合検索条件毎の検索結果数を取得する処理を実行する。
　検索結果数は、検索クエリに応じて抽出されるレシピの数である。即ち、ステップＳ３０３では、複合検索条件毎に検索処理を行い、抽出された検索レシピ数を取得する処理を実行する。
　尚、検索ＤＢ５２に検索クエリ毎の検索結果数が記憶されている場合は、検索ＤＢ５２から取得してもよい。

　ステップＳ３０１乃至Ｓ３０３の各処理を実行することによって、レシピ管理サーバ１は、取得した複合検索条件毎に被検索回数と検索結果数を取得する。
　続いて、レシピ管理サーバ１はステップＳ３０４において、複合検索条件毎の被検索回数と検索結果数に応じて支援対象検索条件を決定する処理を実行する。
　支援対象検索条件決定処理については、図７を参照して説明する。

　支援対象検索条件決定処理では、レシピ管理サーバ１は先ずステップＳ５０１において、処理対象とされた複合検索条件を一つ選択する。
　続いて、レシピ管理サーバ１はステップＳ５０２において、選択した複合検索条件の被検索回数に対する検索結果数が所定割合（閾値）以下であるか否かを判定する。
　そして、被検索回数に対する検索結果数が所定割合以下であると判定した場合、レシピ管理サーバ１はステップＳ５０３において、選択された複合検索条件を支援対象検索条件として決定する。
　即ち、当該複合検索条件が検索クエリとして利用される回数に対して検索結果数が少ない複合検索条件ほど優先して支援対象検索条件として決定される。

　次に、レシピ管理サーバ１はステップＳ５０４において、処理対象とされた複合検索条件に対してステップＳ５０１乃至Ｓ５０３の各処理を実行したか否かを判定する。
　未処理の複合検索条件が残っている場合、レシピ管理サーバ１はステップＳ５０１の処理を再度実行する。
　一方、処理対象とされた複合検索条件全てに対して各処理を実行した場合、レシピ管理サーバ１は図７に示す一連の処理を終了する。

　尚、ステップＳ５０２の判定で用いる所定割合の閾値は複合検索条件によらず同一の閾値とされてもよいし、複合検索条件に応じて変更される閾値とされてもよい。
　所定割合を複合検索条件に応じて変更する場合、例えば、相対的に被検索回数が多い複合検索条件ほど所定割合の閾値を緩和する（小さくする）。また、複合検索条件に対応する被検索回数に対する被利用回数の割合が少ないほど所定割合の閾値を厳しく（大きく）する構成にしてもよい。
　被利用回数とは、前述した印刷操作などの利用操作の対象となった回数である。被検索回数に対する被利用回数が少ないということは、即ち検索クエリを用いた検索がされているにも関わらず抽出された何れのレシピも利用しなかったということであり、検索結果として抽出されたレシピの中にユーザを満足させるものがなかった可能性がある。そのため、そのような検索クエリ（即ち複合検索条件）が支援対象とされやすくするために、所定割合の閾値を大きくする。

　また、所定割合の閾値を複合検索条件に応じて変更する場合の別の例として、例えば、単位期間あたりの被検索回数の変化が大きいほど所定割合の閾値を厳しく（大きく）することが考えられる。
　単位期間あたりの被検索回数の変化が大きい複合検索条件は注目されている可能性が高い。そのような複合検索条件によって抽出されるレシピ数は多い方が好ましいため、支援対象とされやすくするために所定割合の閾値を厳しく（大きく）する。
　一方、単位期間あたりの被検索回数の変化が小さい複合検索条件はユーザを満足させるレシピが抽出されないことがユーザに認知され始めていることが考えられる。ユーザがレシピサイトを利用しなくなる状況を回避するために、そのような複合検索条件によって抽出されるレシピ数を増加させることが望ましく、当該複合検索条件が支援対象とされやすいように所定割合の閾値を厳しく（大きく）する。

　尚、支援対象検索条件決定処理の別の例については後述する。

　図５の説明に戻る。
　支援対象となる複合検索条件を決定したレシピ管理サーバ１は、ステップＳ３０５において、アレンジ対象とするレシピを決定する処理を実行する。
　この処理でアレンジ対象として決定されたレシピは、現時点では先の複合検索条件を用いた検索によって抽出されないレシピであり、且つ、今後の検索によって新たに抽出対象とすることが望まれるレシピである。
　アレンジ対象レシピ決定処理について、具体的に図８を参照して説明する。

　レシピ管理サーバ１は、先ずステップＳ６０１において、検索結果数の多いキーワードを含む第一部分検索条件のうちの一つを選択する処理を実行する。
　具体的に説明すると、例えば、支援対象の複合検索条件としてキーワードＫ１，Ｋ２，Ｋ３を含む検索クエリ「Ｋ１，Ｋ２，Ｋ３」が選択されたとする。そして、キーワードＫ１を検索クエリとして抽出されたレシピ数（検索結果数）が１００、キーワードＫ２を検索クエリとして抽出されたレシピ数が２００、キーワードＫ３を検索クエリとして抽出されたレシピ数が３００とする。
　このとき、検索結果数の多いキーワードとしてはＫ３となる。

　検索クエリ「Ｋ１，Ｋ２，Ｋ３」に対する第一部分検索条件は、前述のように「Ｋ１」、「Ｋ２」、「Ｋ３」、「Ｋ１，Ｋ２」、「Ｋ１，Ｋ３」、「Ｋ２，Ｋ３」の６種類となるが、このうち検索結果数の多いキーワードＫ３を含む第一部分検索条件としては、「Ｋ３」、「Ｋ１，Ｋ３」、「Ｋ２，Ｋ３」の３種類となる。
　即ち、ステップＳ６０１の処理では、この３種類の第一部分検索条件から一つを選択する処理となる。以降では、この具体例を用いて説明する。

　続いて、レシピ管理サーバ１はステップＳ６０２において、第一部分検索条件「Ｋ３」を用いたレシピ検索を行う。即ち、３００個のレシピが検索結果として抽出される。
　そして、レシピ管理サーバ１はステップＳ６０３において、検索結果として抽出された３００個のレシピから、第一部分検索条件「Ｋ３」を満たし「Ｋ１」及び「Ｋ２」を満たさないレシピを選択して、アレンジ対象レシピとする処理を実行する。
　これにより、現時点において複合検索条件を用いた検索によって抽出されてしまうレシピを除き、複合検索条件の第一部分検索条件のみを満たすレシピがアレンジ対象レシピとして抽出される。

　以降、検索結果数の多いキーワードを含む第一部分検索条件全て（即ち「Ｋ３」、「Ｋ１，Ｋ３」、「Ｋ２，Ｋ３」の３種類全て）に対して同様の処理を実行する。
　即ち、レシピ管理サーバ１はステップＳ６０４において、検索結果数の多いキーワードを含む第一部分検索条件のうち未処理のものがあるか否かを判定し、未処理のものがある場合はステップＳ６０１の処理を再度実行する。
　未処理のものが無い場合、レシピ管理サーバ１は図８に示す一連の処理を終了する。

　尚、支援対象検索条件が複数ある場合には、ステップＳ６０１乃至Ｓ６０４の各処理を支援対象検索条件の数だけ実行することとなる。

　図５の説明に再び戻る。
　アレンジ対象レシピを決定したレシピ管理サーバ１は、続くステップＳ３０６において、支援依頼の対象とする（即ち支援を依頼する）ユーザを特定する処理を実行する。
　この処理は、アレンジ対象レシピに基づくアレンジレシピの投稿が期待されるユーザを特定する処理である。
　具体的な処理例について、図９を参照して説明する。

　先ず、レシピ管理サーバ１はステップＳ７０１において、アレンジ対象レシピのうちの一つを選択する。例えば、先のキーワード「Ｋ３」を用いた検索処理によって抽出される３００個のレシピ（レシピＲ３００１～Ｒ３３００）がアレンジ対象レシピとされた場合、その中から一つ（例えばレシピＲ３００１）を選択する。

　続いて、レシピ管理サーバ１はステップＳ７０２において、対応する第二部分検索条件を取得する。
　対応する第二部分検索条件とは、選択したアレンジ対象レシピＲ３００１の抽出に用いられた第一部分検索条件が支援対象検索条件「Ｋ１，Ｋ２，Ｋ３」の第一部分検索条件「Ｋ３」であることから、「Ｋ１，Ｋ２」が第二部分検索条件となる。

　そして、レシピ管理サーバ１はステップＳ７０３において、第二部分検索条件としてのキーワードを使用したレシピや既存のレシピをアレンジしたアレンジレシピを投稿した投稿ユーザを検索する。
　例えば、キーワード「Ｋ１，Ｋ２」（一例としてＫ１＝「トマト」、Ｋ２＝「チーズ」とする）を用いたレシピとしては、「トマトたっぷりのアラビアータ」や「トマトとチーズのオムレツ」などのように、「トマト」と「チーズ」を元から含んでいる（使用食材とされている）レシピがある。

　そして、それ以外にも、「トマト」と「チーズ」を使用食材として用いていないレシピがキーワード「トマト、チーズ」によって抽出されることがある。例えば、「我が家のシーフードカレー」のようなレシピ（「トマト」や「チーズ」を使用していないレシピ）に対して作成レポートが投稿されており、その作成レポートに「トマトとチーズを入れてアレンジしてみました。とてもおいしかったです。」のようなレポート内容が記載されている場合などである。即ち、このレシピには元々使用食材として「トマト」や「チーズ」が含まれていないにも関わらず、そのレシピをアレンジした情報が作成レポートとして投稿されている。このような作成レポートは、ある種のレシピ情報（アレンジレシピ情報）として抽出される。

　ステップＳ７０３の処理は、このような第二部分検索条件としてのキーワード「Ｋ１」，「Ｋ２」をアレンジ食材として利用したレシピ（作成レポートも含む）を投稿した投稿ユーザを検索する処理である。
　第二部分検索条件としての「トマト」と「チーズ」をアレンジ食材として使用した投稿ユーザは、当該アレンジ食材を用いて既存の料理をアレンジする能力に長けている可能性が高い。

　レシピ管理サーバ１は、続くステップＳ７０４で、検索された投稿ユーザを支援依頼対象ユーザとして特定する処理を実行する。即ち、検索結果として抽出されたアレンジレシピ（作成レポート）を投稿した投稿ユーザを支援依頼対象ユーザとして取得する。

　支援依頼対象ユーザを取得したレシピ管理サーバ１は、続くステップＳ７０５において、未処理のアレンジ対象レシピがあるかどうかを判定する。
　未処理のアレンジ対象レシピがある場合、レシピ管理サーバ１は再びステップＳ７０１乃至Ｓ７０４の各処理を実行する。
　未処理のアレンジ対象レシピが無くなった場合、レシピ管理サーバ１は図９に示す一連の処理を終了する。

　尚、第二部分検索条件としてのキーワードをアレンジ食材として使用した投稿ユーザを検索する例を示したが、それ以外の例も考え得る。
　例えば、「トマト」と「チーズ」を使用するレシピ（アレンジレシピではない）を投稿した投稿ユーザを検索してもよい。そのようなユーザが「トマト」と「チーズ」を利用するレシピを得意とする可能性もあるためである。

　具体的に図１０を参照して説明する。
　レシピ管理サーバ１はステップＳ８０１において、アレンジ対象レシピのうちの一つを選択し、ステップＳ８０２において対応する第二部分検索条件を取得する。これらの処理は、図９のステップＳ７０１及びＳ７０２の処理と同様である。

　続いて、レシピ管理サーバ１はステップＳ８０３において、第二部分検索条件としてのキーワード「トマト」と「チーズ」を使用してレシピ検索を行い、投稿ユーザを取得する。
　この処理では、「トマト」と「チーズ」を用いたアレンジレシピの投稿ユーザだけでなく、「トマト」と「チーズ」を用いるレシピの投稿ユーザも抽出される。
　そして、レシピ管理サーバ１は、続くステップＳ８０４において検索された投稿ユーザを支援依頼対象ユーザとして特定する処理を実行し、ステップＳ８０５において未処理のアレンジ対象レシピがあるかどうかを判定する処理を実行する。
　ステップＳ８０４及びＳ８０５の処理は、図９のステップＳ７０４及びＳ７０５の処理と同様である。

　また、実績のある投稿ユーザを支援依頼対象ユーザとして優先的に選択する例もある。
　具体的に図１１を参照して説明する。
　レシピ管理サーバ１はステップＳ９０１乃至Ｓ９０３の各処理を実行する。この処理は、図１０のステップＳ８０１乃至Ｓ８０３の各処理と同様の処理である。
　第二部分検索条件としてのキーワードを含むレシピの投稿ユーザを検索したレシピ管理サーバ１は、ステップＳ９０４において、当該投稿ユーザの中から実績のある投稿ユーザを支援依頼対象ユーザとして特定する処理を実行する。

　実績のある投稿ユーザとは、レシピ投稿数や作成レポート投稿数が多い投稿ユーザや、投稿ユーザによって投稿された投稿レシピの被利用回数が多い投稿ユーザや、或いは被利用率（＝被利用回数／閲覧数）の高い投稿ユーザなどである。また、投稿ユーザに対する利用ユーザからの評価が高い投稿ユーザを実績のある投稿ユーザとするように構成してもよい。
　そのような投稿ユーザに対してレシピのアレンジを依頼することは、質の高いレシピ投稿やアレンジレシピの投稿がなされる可能性を高めることができ、延いてはレシピサイトの利用人数の増加を図ることができる。

　支援依頼対象ユーザの特定が完了したレシピ管理サーバ１は、続くステップＳ９０５において、未処理のアレンジ対象レシピがあるかどうかを判定する処理を実行する。ステップＳ９０５の処理は、ステップＳ７０５やＳ８０５と同様の処理である。

　続いて、図５の説明に戻る。
　図９乃至図１１のいずれかの処理を実行することにより、支援依頼対象ユーザを特定したレシピ管理サーバ１は、ステップＳ３０７において、アレンジ依頼情報を通知する処理を実行する。
　アレンジ依頼情報には、アレンジ対象レシピの情報と、第二部分検索条件と、支援依頼対象ユーザが少なくとも含まれる。例えば、支援依頼対象ユーザに対して、「「トマト」と「チーズ」を使ってレシピＲ３００１、Ｒ３００２・・・をアレンジしませんか？」というメッセージを送る。
　アレンジ依頼情報の通知は、前述のように、電子メールやレシピサイト上への表示などによって行われる。

　まとめると、図５のステップＳ３０１乃至Ｓ３０７の処理を実行することにより、支援対象検索条件としての検索クエリ「トマト、チーズ、ニンジン」から第一部分検索条件「ニンジン」と第二部分検索条件「トマト、チーズ」が選択され、第一部分検索条件「ニンジン」を用いた検索によって抽出された「ニンジンサラダ」がアレンジ対象レシピとして選択され、第二部分検索条件とされた「トマト」と「チーズ」を用いたアレンジレシピを得意とする支援依頼対象ユーザに対して「ニンジンサラダ」に「トマト」と「チーズ」を加えたアレンジレシピの提案を依頼する。
　これにより、レシピ情報の充実かが図られる。

［４－３．複合検索条件取得処理第２例］
　先のバッチ処理の第１例では、複合検索条件取得処理の例として、所定期間内に検索された複合検索条件を、処理対象の複合検索条件として選択する例を示した。
　ここでは、複合検索条件取得処理の第２例について、図１２を参照して説明する。

　先ず、レシピ管理サーバ１はステップＳ１００１において、検索クエリを取得する処理を実行する。
　続いて、レシピ管理サーバ１はステップＳ１００２において、取得した検索クエリが複合検索条件であるか否かを判定した後、ステップＳ１００３で被検索回数を取得し、ステップＳ１００４で被利用回数を取得する処理を実行する。
　これらの処理により、複合検索条件についての被検索回数と被利用回数を取得する。

　続いて、レシピ管理サーバ１はステップＳ１００５において、被検索回数に対する被利用回数が所定値以下であるか否かを判定する処理を実行する。
　即ち、被検索回数に対する被利用回数の割合が所定閾値以上である場合には、ユーザが検索結果にある程度満足していることが推測されるため、処理対象の複合検索条件からは外すことを意図している。

　ステップＳ１００５において、被検索回数に対する被利用回数の割合が所定閾値以下であると判定した場合、レシピ管理サーバ１はステップＳ１００６において、当該複合検索条件を処理対象として選択する処理を実行する。

　ステップＳ１００６の処理を実行した後、或いは、ステップＳ１００２において検索クエリが複合検索条件でないと判定した後、或いは、被検索回数に対する被利用回数の割合が所定閾値以下でないと判定した後、レシピ管理サーバ１はステップＳ１００７において、検索クエリの取得が終了したか否かを判定する。

　検索クエリの取得が終了していない場合、即ち、図１２に示す一連の処理の対象とされた検索クエリがまだ残っている場合、レシピ管理サーバ１は再度ステップＳ１００１の処理を実行する。
　一方、検索クエリの取得が終了したと判定した場合、レシピ管理サーバ１は図１２に示す一連の処理を終了する。

　尚、複合検索条件取得処理として図１２に示す処理を行った場合、図５のステップＳ３０２の処理は図１２のステップＳ１００３で既に実行しているため不要となる。

［４－４．支援対象検索条件決定処理第２例］
　先のバッチ処理の第１例における支援対象検索条件決定処理では、被検索回数に対する検索結果数が所定割合以下である複合検索条件を支援対象検索条件とする例を示した。
　支援対象検索条件決定処理の第２例では、類似する複合検索条件の中で被検索回数に対する検索結果数の割合が相対的に少ない複合検索条件を支援対象検索条件とする。

　具体的に、図１３を参照して説明する。
　先ず、レシピ管理サーバ１はステップＳ１１０１において、処理対象とされた複合検索条件を選択する。この処理は、図７のステップＳ５０１の処理と同様の処理である。
　続いて、レシピ管理サーバ１はステップＳ１１０２において、類似した複合検索条件を取得する。
　類似した複合検索条件については、後述する。

　次に、レシピ管理サーバ１はステップＳ１１０３において、処理対象とされた複合検索条件の被検索回数に対する検索結果数の割合が、類似した複合検索条件の被検索回数に対する検索結果数の割合と比較して相対的に少ないか否かを判定する処理を実行する。
　相対的に少ないと判定した場合、レシピ管理サーバ１はステップＳ１１０４において、支援対象検索条件として決定する。換言すれば、処理対象とされた複合検索条件の被検索回数に対する検索結果数の割合が絶対的に少なかったとしても、類似する複合検索条件が同様の水準であれば、必ずしも処理対象とされた複合検索条件を支援対象とする必要がない。

　ステップＳ１１０４を実行した後、または、ステップＳ１１０３において相対的に少なくないと判定した後、レシピ管理サーバ１はステップＳ１１０４において、処理対象とされた複合検索条件に対してステップＳ１１０１乃至Ｓ１１０４の各処理を実行したか否かを判定する。
　ステップＳ１１０４，Ｓ１１０５の各処理は、図７におけるステップＳ５０３，Ｓ５０４の各処理と同様の処理である。

　類似する複合検索条件の例を以下に示す。
１）複合検索条件に含まれる少なくとも一部のキーワードが一致する条件
２）複合検索条件に含まれるキーワードのうち、使用頻度の高い少なくとも一部のキーワードが一致する条件
３）複合検索条件に含まれる少なくとも一部のキーワードが一致し、且つ複合検索条件に含まれるキーワード数が一致する条件

　１）によれば、例えば、検索クエリ「Ｋ１，Ｋ２，Ｋ３」と検索クエリ「Ｋ１，Ｋ４，Ｋ５，Ｋ６」はそれぞれ三つのキーワードを含むため、類似する複合検索条件とされる。
　同一のキーワード「Ｋ１」を含む検索クエリは、同程度の検索結果数となることが望ましい。「トマト」と「ジャガイモ」を含むレシピとして抽出されたレシピ数が、「トマト」と「ニンジン」を含むレシピとして抽出されたレシピ数に対して著しく少ない場合、検索を行ったユーザに提示するレシピは「トマト」と「ジャガイモ」の双方を食材として使用するレシピが提示される可能性が低くなる。このような状況は好ましくない。
　但し、一部のキーワードの選び方によっては、検索結果数が同程度とならないことがやむを得ない場合もある。

　２）によれば、検索クエリ「Ｋ１，Ｋ２，Ｋ３」の中でキーワード「Ｋ１」と「Ｋ２」が使用頻度の高い（例えばレシピの使用食材として用いられる頻度の高い）食材（以降、「高頻度」と記載）であり、キーワード「Ｋ３」が使用頻度の低い食材（以降、「低頻度」と記載）である場合に、検索クエリ「Ｋ１，Ｋ２，Ｋ３」の類似する複合検索条件としては、検索クエリ「Ｋ１（高頻度），Ｋ２（高頻度），Ｋ４（高頻度）」や検索クエリ「Ｋ１（高頻度），Ｋ３（低頻度），Ｋ５（低頻度）」などが挙げられる。
　尚、検索クエリ「Ｋ１（高頻度），Ｋ２（高頻度），Ｋ４（高頻度）」の検索結果数は検索クエリ「Ｋ１（高頻度），Ｋ３（低頻度），Ｋ５（低頻度）」の検索結果数よりも多くなりやすい。即ち、検索クエリ「Ｋ１（高頻度），Ｋ３（低頻度），Ｋ５（低頻度）」は、低頻度のキーワード「Ｋ３」と「Ｋ５」を含んでいるため、検索結果数が少なかったとしても妥当である可能性がある。
　一方、検索クエリ「Ｋ１（高頻度），Ｋ２（高頻度），Ｋ４（高頻度）」は、含まれるキーワードが全て高頻度であることから、検索結果数は多いことが望ましい。
　そのため、検索クエリ「Ｋ１（高頻度），Ｋ３（低頻度），Ｋ５（低頻度）」の検索結果数が少ないことよりも、検索クエリ「Ｋ１（高頻度），Ｋ２（高頻度），Ｋ４（高頻度）」の検索結果数が少ないことの方が問題が大きい。

　従って、何れの複合検索条件の検索結果数を充実化させることが望ましいのかは、キーワードの使用頻度を鑑みることが重要である。
　例えば、検索クエリ「Ｋ１（高頻度），Ｋ２（高頻度），Ｋ３（低頻度）」と類似するものとして検索クエリ「Ｋ１（高頻度），Ｋ３（低頻度），Ｋ５（低頻度）」を取得した場合、キーワードの出現頻度が異なるため、検索結果数を同程度とするために検索結果数の充実化を図ることが妥当とは限らない。また、低頻度のキーワードを含んでいるため、検索結果数が少なかったとしても仕方が無い可能性もある。

　そこで、一部のキーワードとして高頻度となるキーワードを選択することが望ましい。
　先の検索クエリ「Ｋ１（高頻度），Ｋ２（高頻度），Ｋ３（低頻度）」においては、高頻度のキーワードとなる「Ｋ１」と「Ｋ２」が一部のキーワードとされる。
　このとき、検索クエリ「Ｋ１（高頻度），Ｋ２（高頻度），Ｋ３（低頻度）」と類似する複合検索条件としては、一部のキーワード（「Ｋ１」及び「Ｋ２」）を含む検索クエリ「Ｋ１（高頻度），Ｋ２（高頻度），Ｋ４（高頻度）」や検索クエリ「Ｋ１（高頻度），Ｋ２（高頻度），Ｋ５（低頻度）」などである。
　組み合わせられやすいキーワードは、専用のＤＢから取得してもよいし、検索履歴から抽出（即ち検索結果数が多い組み合わせを抽出）してもよい。
　また、レシピタイトルに含まれやすいキーワードを一部のキーワードとしてもよい。

　２）についてまとめると、高頻度となるキーワードを一部のキーワードとして選択することにより、検索結果数が同程度となることが望ましい複合検索条件が比較対象として選択され、比較対象に対して相対的に検索結果数が少ない場合に当該複合検索条件は充実化が必要な検索条件として決定され、以降の処理においてレシピの充実化が図られる。

　３）によれば、例えば、検索クエリ「Ｋ１，Ｋ２，Ｋ３」に対して、検索クエリ「Ｋ１，Ｋ２，Ｋ４」や検索クエリ「Ｋ１，Ｋ５，Ｋ６」などは、一部のキーワードが一致すると共に複合検索条件に含まれるキーワード数が一致するため、類似する複合検索条件とされる。
　一般的に、ＡＮＤ検索を行うためのキーワード数を増やすと、検索結果数は減る。そして、絞り込み検索を行うためにはキーワードを追加した検索を行うが、元々の検索結果数が少ないと、絞り込み検索によって抽出される検索結果数は更に少なくなり、ユーザの要望を満たすものとはなり難い。

　例えば、検索クエリ「Ｋ１，Ｋ２，Ｋ３，Ｋ４，Ｋ５」によって抽出された検索結果数が少ない場合において検索結果数を増やしたいと考えたときに、検索クエリ「Ｋ１，Ｋ２，Ｋ３，Ｋ４，Ｋ５」の検索結果数を増やせばよいのか、そもそもキーワードが一つ少ない検索クエリ「Ｋ１，Ｋ２，Ｋ３，Ｋ４」の検索結果数が少ないのか、或いは更にキーワードが少ない検索クエリ「Ｋ１，Ｋ２」の時点で検索結果数が少ないのかによって、アレンジ対象レシピの選び方が異なってくる。
　そこで、同数のキーワードを含み且つ検索キーワードが一部同一である複合検索条件においては、同程度の検索結果数を提示することが望ましいという観点から、そのような検索条件を類似する複合検索条件とする。

［４－５．アレンジ対象レシピ決定処理第２例］
　アレンジ対象レシピ決定処理の第２例について、図１４を参照して説明する。

　レシピ管理サーバ１は先ずステップＳ１２０１において、第一部分検索条件のうちの一つを選択し、続くステップＳ１２０２において、当該第一部分検索条件を用いたレシピ検索を行う。
　そして、レシピ管理サーバ１はステップＳ１２０３において、抽出されたレシピの中から、当該第一部分検索条件がレシピの中で優先度の高いキーワード（例えば主要食材）とされたレシピを選択し、アレンジ対象レシピとして選択する。

　例えば、第一部分検索条件として検索クエリ「Ｋ１（食材）」が選択され、それに応じて検索結果としてのレシピＲ１，Ｒ２，Ｒ３が検索された場合を考える。
　レシピＲ１は、キーワード「Ｋ１」が少量使用されているレシピであるため、レシピＲ１におけるキーワード「Ｋ１」は低重要度とされる。
　レシピＲ２は、キーワード「Ｋ１」がレシピタイトルに含まれているため（例えば「Ｋ１を使った○○サラダ」）、レシピＲ２においてキーワード「Ｋ２」は高重要度とされる。
　レシピＲ３は、キーワード「Ｋ１」が最も使用量の多い使用食材とされているため、レシピＲ３におけるキーワード「Ｋ１」は高重要度とされる。

　このような場合では、第一部分検索条件（上記の「Ｋ１」）がレシピの中で優先度の高いキーワードとされたレシピ（即ちレシピＲ２，Ｒ３）をアレンジ対象レシピとして選択する。

　次に、レシピ管理サーバ１はステップＳ１２０４において、未処理の第一部分検索条件があるか否かを判定し、未処理のものがある場合はステップＳ１２０１の処理を再度実行する。
　未処理のものが無い場合、レシピ管理サーバ１は図１４に示す一連の処理を終了する。

［４－６．バッチ処理の第２例］
　バッチ処理の第２例について、図１５を参照して説明する。
　尚、図５に示したバッチ処理の第１例と同様の処理については、同一の符号を付し、適宜説明を省略する。

　レシピ管理サーバ１は、ステップＳ３０１において複合検索条件を取得し、ステップＳ３０２において被検索回数を取得し、ステップＳ３０３において検索結果数を取得する。
　そして、レシピ管理サーバ１はステップＳ３０４において支援対象とする複合検索条件を決定し、ステップＳ３０５においてアレンジ対象レシピを決定する。
　ステップＳ３０１乃至Ｓ３０５の各処理は、図５に示す各処理と同様である。

　続いて、レシピ管理サーバ１はステップＳ３０８において、アレンジ対象レシピの数に応じて複合検索条件に優先度を付与する。
　アレンジ対象レシピ数が多いということは、アレンジレシピが投稿される確率（或いは投稿数）が向上するということである。
　即ち、効果の高い複合検索条件の優先度を高くすることによって、効率よくレシピの充実化を図ることができる。

　次に、レシピ管理サーバ１はステップＳ３０６において、支援依頼対象ユーザを特定し、ステップＳ３０７においてアレンジ依頼情報を通知する。

　尚、アレンジ依頼情報通知処理では、ステップＳ３０８で付与した優先度に応じた通知処理を実行してもよい。
　例えば、ある支援依頼対象ユーザに対して複数のアレンジ依頼を行う場合、優先度の高い方のアレンジ対象レシピに関する依頼のみを行ってもよい。また、優先度の高い方のアレンジ対象レシピに関する依頼から順に通知してもよい。

［４－７．特典付与処理］
　レシピの充実化をより促進するために、アレンジレシピの投稿者に対して特典を付与する場合の処理について、図１６を参照して説明する。
　尚、図１６に示す処理は、新しいアレンジレシピが投稿されるたびに実行（例えばバッチ処理によって実行）してもよいし、一定期間毎に定期的に実行してもよい。

　先ず、レシピ管理サーバ１はステップＳ１３０１において、新規に投稿されたアレンジレシピを抽出する処理を実行する。
　尚、バッチ処理などによって実行する場合は、前回処理から今回処理までの間に投稿されたアレンジレシピが新規に投稿されたレシピとされる。

　続いて、レシピ管理サーバ１はステップＳ１３０２において、当該アレンジレシピを投稿した投稿ユーザを特定する。
　そして、当該投稿ユーザに対してアレンジ情報通知依頼を行ったか否か（即ち図５におけるステップＳ３０７の処理を投稿ユーザに対して行ったか否か）を判定する処理を実行する。
　ここで、投稿ユーザに対してアレンジ情報通知依頼を行っていたとしても、投稿されたアレンジレシピと関連が無い場合（即ち依頼と異なるアレンジレシピが投稿された場合）は、依頼なしと判定する。
　換言すれば、アレンジ情報通知依頼によってアレンジレシピが投稿されたとみなす事ができる場合のみ、依頼ありと判定する。

　アレンジ情報通知依頼ありと判定した場合、レシピ管理サーバ１はステップＳ１３０４において、特典付与を行う。

　特典を付与した後、或いは、ステップＳ１３０３において依頼なしと判定した後、レシピ管理サーバ１はステップＳ１３０５において、未処理の新規投稿アレンジレシピがあるか否かを判定する処理を行う。
　未処理の新規投稿アレンジレシピがある場合、レシピ管理サーバ１は再度ステップＳ１３０１の処理を実行する。一方、未処理の新規投稿アレンジレシピがない場合、レシピ管理サーバ１は図１６に示す一連の処理を終了する。

　尚、新しいアレンジレシピが投稿されるたびに図１６の処理を実行する場合、ステップＳ１３０５の処理は不要となる。

　ここで、特典の付与例について述べる。
　被検索回数の変化量が大きい複合検索条件について投稿されたアレンジレシピであった場合、大きな特典（或いは優良な特典）を付与することが考えられる。
　また、被検索回数に対する被利用回数が少ない（即ちユーザが検索結果に満足していないと推測される）複合検索条件について投稿されたアレンジレシピであった場合、大きな特典（或いは優良な特典）を付与することが考えられる。

　更に、類似する複合検索条件の中で被検索回数に対する検索結果数が相対的に少ないものに対して投稿されたアレンジレシピであった場合、大きな特典（或いは優良な特典）を付与することが考えられる。
　更にまた、アレンジ情報通知依頼からアレンジレシピ投稿までの経過時間が短い（即ち対応が早い）ほど、大きな特典（或いは優良な特典）を付与することが考えられる。
　更にまた、投稿されたアレンジレシピと他のアレンジレシピとの類似度が低い（即ち投稿されたアレンジレシピがユニークな）ほど、大きな特典（或いは優良な特典）を付与することが考えられる。

＜５．まとめ＞

　上記したレシピ管理サーバ１は、レシピに関する情報を検索するために用いられる少なくとも２以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得部１ｂと、取得した複合検索条件に対応する検索結果数を取得する検索部１ｃと、取得した被検索回数と複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定部１ｄと、支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定部１ｅと、支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理部１ｆと、特定された支援依頼対象ユーザに対して決定されたアレンジ対象レシピと第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御部１ｇと、を備えている。
　これにより、ユーザの潜在的なニーズが汲み取られて、相対的に不足しているレシピの特定がなされる。
　従って、ユーザの要望に沿ったレシピ情報の拡充を支援することが可能となる。
　また、検索レシピ数が少ないと、ユーザが使い勝手の悪さを感じてしまい、レシピ検索サービスを利用しなくなってしまう虞がある。上記構成によれば、これらの問題を解決し、ユーザが離れてしまうことを防止することができる。
　尚、検索の被検索回数と複合検索条件の検索結果数（検索結果として抽出されたレシピ数）に基づいて支援対象検索条件を決定するため、支援対象検索条件を適切に絞ることが可能となる。そのため、全ての複合検索条件を支援対象検索条件とするよりも、アレンジ対象レシピの決定などの各処理に要するレシピ管理サーバ１の処理負担が軽減される。即ち、必要な箇所（ユーザの潜在的なニーズのある箇所）に対して効率のよいレシピ情報の追加が促進される。

　また、バッチ処理の第１例において説明したように、支援対象決定部１ｄは、複合検索条件の被検索回数に対する検索結果数の割合と、複合検索条件の検索結果数に応じて特定された閾値と、に基づいて複合検索条件を支援対象とするか否かを決定してもよい。
　これにより、被検索回数に対して複合検索条件の検索結果数の割合が所定値以下となる複合検索条件を支援対象検索条件とすることが可能となる。即ち、このような複合検索条件は、ニーズがあるにも関わらず十分に満足できる検索結果が提示できていない可能性がある。このような複合検索条件が支援対象とされることにより、検索結果として抽出されるレシピ情報が拡充されて、ユーザの要望を満足させることができる。

　更に、バッチ処理の第１例に記載で説明したように、支援対象決定部１ｄは、複合検索条件の被検索回数に対する検索結果数の割合と、複合検索条件に対応する検索結果に含まれる各レシピの被利用回数に応じて特定された閾値と、に基づいて複合検索条件を支援対象とするか否かを決定してもよい。
　これにより、検索結果に含まれる各レシピの中に、ユーザの要望を満たすレシピのの多寡に応じて閾値が特定される。
　従って、ユーザの要望を満たすレシピが少ない複合検索条件が支援対象とされやすくなり、ユーザの要望を満足させる可能性を高めることができる。

　更にまた、バッチ処理の第１例において説明したように、支援対象決定部１ｄは、複合検索条件に対応する検索結果に含まれる各レシピの被利用回数が被検索回数に対して少ないほど高い閾値を特定してもよい。
　被検索回数に対して検索結果としてのレシピの被利用回数が少ない場合、検索操作を行ったにも関わらず、所望のレシピが提示されずにレシピ検索を諦めた（若しくは他の検索条件を設定したレシピ検索を再度行った）ユーザが多い可能性が高い。
　このような場合に、高い閾値を特定することは、当該複合検索条件が支援対象検索条件として選択される可能性が高くなる。
　従って、ユーザの実際の行動に基づいたニーズを推測したレシピ情報の拡充が行われる可能性を高めることができる。

　そして、バッチ処理の第１例において説明したように、支援対象決定部１ｄは、複合検索条件の所定期間における被検索回数の変化が大きいほど高い閾値を特定してもよい。
　例えば、被検索回数の変化が短時間に増大した場合などは、ニーズが急激に増加していることが推測される。このような状態において高い閾値を特定することは、当該複合検索条件が支援対象検索条件として選択される可能性が高くなる。
　即ち、ニーズの変動に即したレシピ情報の拡充が行われやすくする環境を提供することができる。

　加えて、支援対象検索条件決定処理第２例で説明したように、支援対象決定部１ｄは、複合検索条件に対応する被検索回数に対する検索結果数の割合が他の複合検索条件に対応する検索回数に対する検索結果数の割合に対して相対的に少ない複合検索条件を対象として決定してもよい。
　これにより、例えば、類似する複合検索条件が複数あった場合に、相対的にレシピ数の足りていない複合検索条件が支援対象検索条件とされる。
　従って、他の類似する複合検索条件よりもレシピ拡充の必要性が高いと推測される複合検索条件に対して、検索結果の充実化（即ち複合検索条件の検索結果数の増加）を図ることが可能となる。

　そして、バッチ処理の第２例において説明したように、支援対象決定部１ｄは、第一部分検索条件に対応する検索結果数が多い複合検索条件ほど高い優先度を付与し、送信制御部１ｇは、相対的に高い優先度を付与された複合検索条件に基づく依頼情報が優先的に送信されるように制御してもよい。
　これにより、アレンジ対象レシピの候補となるレシピが多く検索される複合検索条件の優先度が高くなる。換言すれば、アレンジ対象レシピが多くなる。
　アレンジ対象レシピが多いということは、アレンジ対象レシピを改良したアレンジレシピの提案数も増加する可能性が高いため、レシピ情報の充実化を効率よく図ることができる。

　また、バッチ処理の第１例において説明したように、アレンジ対象決定部１ｅは、支援対象として決定された複合検索条件に含まれるキーワード毎に優先度を特定し、当該特定された優先度が相対的に高いキーワードを含む第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定してもよい。
　これにより、優先度が相対的に高いキーワード（例えば主要食材）が既に含まれるレシピがアレンジ対象レシピとして抽出される。即ち、アレンジ対象食材は主要食材以外の食材とされ、主要食材はレシピ通りに調理される。従って、主要食材を奇抜にアレンジしたアレンジレシピなどが投稿される可能性を低減させることができる。
　即ち、万人に受け入れられる汎用性の高いレシピによってレシピ情報の充実化を図ることができる。

　尚、上述したレシピ管理サーバ１では、食材Ａ，食材Ｂ，食材Ｃ，食材Ｄを検索条件とした検索を行った場合、四つの食材全てを利用するレシピが検索結果として抽出される例を挙げたが、検索結果を充実させるために、一部（例えば四つの食材のうち三つの食材）のみを利用するレシピが検索結果として更に抽出されてもよい。即ち、食材Ａ，食材Ｂ，食材Ｃを利用するが食材Ｄを利用しないレシピが検索結果として抽出されてもよい。
　このとき、食材Ａ，食材Ｂを第一部分検索条件とした場合に、食材Ｃ，食材Ｄの双方を第二部分検索条件とするだけでなく、そのうちの一部（即ち食材Ｃなど）を第二部分検索条件とすることによっても、レシピ検索結果の充実化を図ることができる。
　即ち、食材Ａ，食材Ｂを利用するアレンジ対象レシピに食材Ｃを加えたアレンジレシピの投稿がなされれば、食材Ａ，食材Ｂ，食材Ｃ，食材Ｄを検索条件として抽出されるレシピの充実化が図られる。
　そのため、第二部分検索条件としては、「支援対象検索条件」の中から第一部分検索条件を除いた全ての条件でなくてもよい。

＜６．プログラム及び記憶媒体＞

　以上、本発明の情報処理装置の実施の形態としてのレシピ管理サーバ１を説明してきたが、実施の形態のプログラムは、レシピ管理サーバ１における各処理を情報処理装置（ＣＰＵ等）に実行させるプログラムである。

　実施の形態のプログラムは、レシピに関する情報を検索するために用いられる少なくとも２以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得機能を情報処理装置に実行させる。
　また、前記取得した複合検索条件に対応する検索結果数を取得する検索機能を情報処理装置に実行させる。
　更に前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定機能を情報処理装置に実行させる。
　更にまた、前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定機能を情報処理装置に実行させる。
　そして、前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理機能を情報処理装置に実行させる。
　加えて、前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御機能を情報処理装置に実行させる。
　即ちこのプログラムは、レシピ管理サーバ１に対して図４のステップＳ２０１乃至Ｓ２１０の各処理、図５乃至図１６の各処理を実行させるプログラムである。

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

　１　レシピ管理サーバ、１ａ　レシピ管理部、１ｂ　検索情報取得部、１ｃ　検索部、１ｄ　支援対象決定部、１ｅ　アレンジ対象決定部、１ｆ　ユーザ管理部、１ｇ　送信制御部、２　通信ネットワーク、３　ユーザ端末、５０　ユーザＤＢ、５１　レシピＤＢ、５２　検索ＤＢ、５３　履歴ＤＢ、５４　ウェブページＤＢ

Claims (10)

1. 　レシピに関する情報を検索するために用いられる少なくとも２以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得部と、
   　前記取得した複合検索条件に対応する検索結果数を取得する検索部と、
   　前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定部と、
   　前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定部と、
   　前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理部と、
   　前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御部と、を備えた
   　情報処理装置。
2. 　前記支援対象決定部は、前記複合検索条件の前記被検索回数に対する検索結果数の割合と、前記複合検索条件の検索結果数に応じて特定された閾値と、に基づいて複合検索条件を支援対象とするか否かを決定する
   　請求項１に記載の情報処理装置。
3. 　前記支援対象決定部は、前記複合検索条件の前記被検索回数に対する検索結果数の割合と、前記複合検索条件に対応する検索結果に含まれる各レシピの被利用回数に応じて特定された閾値と、に基づいて複合検索条件を支援対象とするか否かを決定する
   　請求項１に記載の情報処理装置。
4. 　前記支援対象決定部は、前記複合検索条件に対応する検索結果に含まれる各レシピの被利用回数が前記被検索回数に対して少ないほど高い閾値を特定する
   　請求項２または請求項３に記載の情報処理装置。
5. 　前記支援対象決定部は、前記複合検索条件の所定期間における被検索回数の変化が大きいほど高い閾値を特定する
   　請求項２または請求項３に記載の情報処理装置。
6. 　前記支援対象決定部は、前記複合検索条件に対応する前記被検索回数に対する検索結果数の割合が他の前記複合検索条件に対応する検索回数に対する検索結果数の割合に対して相対的に少ない複合検索条件を前記支援対象として決定する
   　請求項１乃至請求項５の何れか一項に記載の情報処理装置。
7. 　前記支援対象決定部は、前記前記第一部分検索条件に対応する検索結果数が多い複合検索条件ほど高い優先度を付与し、
   　前記送信制御部は、相対的に高い優先度を付与された前記複合検索条件に基づく依頼情報が優先的に送信されるように制御する
   　請求項１乃至請求項６の何れか一項に記載の情報処理装置。
8. 　前記アレンジ対象決定部は、前記支援対象として決定された複合検索条件に含まれるキーワード毎に優先度を特定し、当該特定された優先度が相対的に高いキーワードを含む前記第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定する
   　請求項１乃至請求項７の何れか一項に記載の情報処理装置。
9. 　レシピに関する情報を検索するために用いられる少なくとも２以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得ステップと、
   　前記取得した複合検索条件に対応する検索結果数を取得する検索ステップと、
   　前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定ステップと、
   　前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定ステップと、
   　前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理ステップと、
   　前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御ステップと、を
   　情報処理装置が実行する情報処理方法。
10. 　レシピに関する情報を検索するために用いられる少なくとも２以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得機能と、
    　前記取得した複合検索条件に対応する検索結果数を取得する検索機能と、
    　前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定機能と、
    　前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定機能と、
    　前記支援対象であると決定された複合検索条件に含まれる２以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理機能と、
    　前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御機能と、を
    　情報処理装置に実行させるプログラム。

Images