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

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

Info

Publication number
JP6275932B1
JP6275932B1 JP2017554622A JP2017554622A JP6275932B1 JP 6275932 B1 JP6275932 B1 JP 6275932B1 JP 2017554622 A JP2017554622 A JP 2017554622A JP 2017554622 A JP2017554622 A JP 2017554622A JP 6275932 B1 JP6275932 B1 JP 6275932B1
Authority
JP
Japan
Prior art keywords
recipe
search condition
search
target
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017554622A
Other languages
English (en)
Other versions
JPWO2017175356A1 (ja
Inventor
有紀 内田
有紀 内田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Rakuten Group Inc
Original Assignee
Rakuten Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Rakuten Inc filed Critical Rakuten Inc
Application granted granted Critical
Publication of JP6275932B1 publication Critical patent/JP6275932B1/ja
Publication of JPWO2017175356A1 publication Critical patent/JPWO2017175356A1/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Databases & Information Systems (AREA)
  • Game Theory and Decision Science (AREA)
  • Data Mining & Analysis (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

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

Description

本発明は、レシピを管理する情報処理装置、情報処理方法及びプログラムについての技術分野に関する。詳しくは、ユーザにレシピを投稿させるための各種処理に関する。
特開2002−092033号公報
近年では、一般ユーザの投稿などによって蓄積されたレシピの情報を提供するレシピ検索サービスなどが普及している。
特許文献1には、ユーザが入力した表現から抽出されたキーワードのうち不必要に厳しい条件を課すものを削除して緩和された検索条件に基づいて検索を行う技術について記載されている。
しかし、ユーザから取得した検索リクエスト数などから推定されるユーザのニーズに対して十分な量の情報(即ちレシピ情報)が提供されていない場合がある。
例えば、特許文献1に記載の技術は、ユーザの入力した表現からキーワードの一部を削除するものであるため、ユーザのニーズ(具体的にはユーザが入力した全てのキーワード)に合致する情報を提供することについては考慮されていない
そこで、本発明は、推定されるユーザのニーズに対して相対的に不足しているレシピ情報を拡充するための環境を提供することを目的とする。
本発明に係る情報処理装置は、レシピに関する情報を検索するために用いられる少なくとも2以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得部と、前記取得した複合検索条件に対応する検索結果数を取得する検索部と、前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定部と、前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定部と、前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理部と、前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御部と、を備えている。
これにより、ユーザの潜在的なニーズが汲み取られて、相対的に不足しているレシピの特定がなされる。
上記した情報処理装置の前記支援対象決定部は、前記複合検索条件の前記被検索回数に対する検索結果数の割合と、前記複合検索条件の検索結果数に応じて特定された閾値と、に基づいて複合検索条件を支援対象とするか否かを決定してもよい。
これにより、被検索回数に対して複合検索条件の検索結果数の割合が所定値以下となる複合検索条件を支援対象検索条件とすることが可能となる。
上記した情報処理装置の前記支援対象決定部は、前記複合検索条件の前記被検索回数に対する検索結果数の割合と、前記複合検索条件に対応する検索結果に含まれる各レシピの被利用回数に応じて特定された閾値と、に基づいて複合検索条件を支援対象とするか否かを決定してもよい。
これにより、検索結果に含まれる各レシピの中に、ユーザの要望を満たすレシピのの多寡に応じて閾値が特定される。
上記した情報処理装置の前記支援対象決定部は、前記複合検索条件に対応する検索結果に含まれる各レシピの被利用回数が前記被検索回数に対して少ないほど高い閾値を特定してもよい。
被検索回数に対して検索結果としてのレシピの被利用回数が少ない場合、検索操作を行ったにも関わらず、所望のレシピが提示されずにレシピ検索を諦めた(若しくは他の検索条件を設定したレシピ検索を再度行った)ユーザが多い可能性が高い。
このような場合に、高い閾値を特定することは、当該複合検索条件が支援対象検索条件として選択される可能性が高くなる。
上記した情報処理装置の前記支援対象決定部は、前記複合検索条件の所定期間における被検索回数の変化が大きいほど高い閾値を特定してもよい。
例えば、被検索回数の変化が短時間に増大した場合などは、ニーズが急激に増加していることが推測される。このような状態において高い閾値を特定することは、当該複合検索条件が支援対象検索条件として選択される可能性が高くなる。
上記した情報処理装置の前記支援対象決定部は、前記複合検索条件に対応する前記被検索回数に対する検索結果数の割合が他の前記複合検索条件に対応する検索回数に対する検索結果数の割合に対して相対的に少ない複合検索条件を前記支援対象として決定してもよい。
これにより、例えば、類似する複合検索条件が複数あった場合に、相対的にレシピ数の足りていない複合検索条件が支援対象検索条件とされる。
上記した情報処理装置の前記支援対象決定部は、前記前記第一部分検索条件に対応する検索結果数が多い複合検索条件ほど高い優先度を付与し、前記送信制御部は、相対的に高い優先度を付与された前記複合検索条件に基づく依頼情報が優先的に送信されるように制御してもよい。
これにより、アレンジ対象レシピの候補となるレシピが多く検索される複合検索条件の優先度が高くなる。換言すれば、アレンジ対象レシピが多くなる。
上記した情報処理装置の前記アレンジ対象決定部は、前記支援対象として決定された複合検索条件に含まれるキーワード毎に優先度を特定し、当該特定された優先度が相対的に高いキーワードを含む前記第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定してもよい。
これにより、優先度が相対的に高いキーワード(例えば主要食材)が既に含まれるレシピがアレンジ対象レシピとして抽出される。
本発明に係る情報処理方法は、レシピに関する情報を検索するために用いられる少なくとも2以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得ステップと、前記取得した複合検索条件に対応する検索結果数を取得する検索ステップと、前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定ステップと、前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定ステップと、前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理ステップと、前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御ステップと、を備えたものである。
この情報処理方法により、推定されるユーザのニーズに対して相対的に不足しているレシピ情報を拡充するための環境を提供する。
本発明に係るプログラムは、上記情報処理方法として実行する処理を情報処理装置に実行させるプログラムである。これらのプログラムにより上記の情報処理装置を実現する。
本発明によれば、推定されるユーザのニーズに対して相対的に不足しているレシピ情報を拡充するための環境を提供することができる。
本発明の実施の形態の情報処理装置を含む全体構成を示す説明図である。 レシピ管理サーバの機能構成を示す図である。 コンピュータ装置のブロック図である。 処理の流れの一例を示す図である。 バッチ処理の第1例を示すフローチャートである。 複合検索条件取得処理を示すフローチャートである。 支援対象検索条件決定処理を示すフローチャートである。 アレンジ対象レシピ決定処理を示すフローチャートである。 支援依頼対象ユーザ特定処理を示すフローチャートである。 支援依頼対象ユーザ特定処理の別の例を示すフローチャートである。 支援依頼対象ユーザ特定処理の更に別の例を示すフローチャートである。 複合検索条件取得処理の第2例を示すフローチャートである。 支援対象検索条件決定処理の第2例を示すフローチャートである。 アレンジ対象レシピ決定処理の第2例を示すフローチャートである。 バッチ処理の第2例を示すフローチャートである。 特典付与処理を示すフローチャートである。
以下、実施の形態を次の順序で説明する。
<1.全体構成>
<2.ハードウェア構成>
<3.DB>
[3−1.ユーザDB]
[3−2.レシピDB]
[3−3.検索DB]
[3−4.履歴DB]
[3−5.ウェブページDB]
<4.処理の流れ>
[4−1.全体の流れ]
[4−2.バッチ処理の第1例]
[4−3.複合検索条件取得処理第2例]
[4−4.支援対象検索条件決定処理第2例]
[4−5.アレンジ対象レシピ決定処理第2例]
[4−6.バッチ処理の第2例]
[4−7.特典付与処理]
<5.まとめ>
<6.プログラム及び記憶媒体>
<1.全体構成>

先ず、本発明の実施の形態における全体構成を説明する。
尚、以下の説明においては、レシピとして料理レシピ(以降では単にレシピという)を例に挙げて説明する。レシピには、調理手順や使用食材や調理器具などの情報が含まれている。
また、検索クエリに応じたレシピの検索やレシピの投稿などが可能なサービスを提供するためのポータルサイトとして、レシピ管理サーバ1が運営するレシピサイトを例に挙げる。
本発明の情報処理装置を含む全体構成を図1に示す。
レシピ管理サーバ1は、通信ネットワーク2を介して、ユーザ端末3,3,3,・・・と相互に通信可能な状態で接続されている。また、レシピ管理サーバ1は、ユーザに関する情報が記憶されるユーザDB(Database)50、レシピに関する情報が記憶されるレシピDB51、検索クエリや検索結果の情報が記憶される検索DB52、ユーザによる各種操作の履歴が記憶される履歴DB53、レシピサイトを構成する各種ウェブページのウェブページデータが記憶されるウェブページDB54と接続されている。
尚、以降の説明において単に「ユーザ」と記載した場合は、投稿ユーザや支援依頼対象ユーザ(後述)やその他のユーザを区別せずに全てのユーザを指すものとする。
尚、レシピ管理サーバ1は、本発明の情報処理装置の実施の形態に相当する。
レシピ管理サーバ1は、ユーザから投稿されるレシピを管理する処理や、検索クエリに応じたレシピを提示するための処理を行う情報処理装置である。具体的な構成に関しては後述する。
通信ネットワーク2の構成は特に限定されるものではなく、例えば、インターネット、イントラネット、エキストラネット、LAN(Local Area Network)、CATV(Community Antenna TeleVision)通信網、仮想専用網(Virtual Private Network)、電話回線網、移動体通信網、衛星通信網などが想定される。
また通信ネットワーク2の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばIEEE(Institute of Electrical and Electronics Engineers)1394、USB(Universal Serial Bus)、電力線搬送、電話線などの有線でも、IrDA(Infrared Data Association)のような赤外線、ブルートゥース(登録商標)、802.11無線、携帯電話網、衛星回線、地上波デジタル網などの無線でも利用可能である。
ユーザ端末3は、レシピをレシピ管理サーバ1に投稿するユーザや、レシピ管理サーバ1が管理するレシピ情報の検索や閲覧を行うユーザが使用する端末である。
ユーザ端末3では、必要に応じて各種の送受信処理や表示処理などが実行される。また、ユーザ端末3は、例えば、通信機能を備えたPC(Personal Computer)やフィーチャーフォンやPDA(Personal Digital Assistant)、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。
レシピ管理サーバ1は、図2に示すように、レシピ管理部1a、検索情報取得部1b、検索部1c、支援対象決定部1d、アレンジ対象決定部1e、ユーザ管理部1f、送信制御部1gを備えている。
レシピ管理部1aは、ユーザが投稿したレシピ情報(レシピタイトルと使用食材と調理方法とレシピが属するカテゴリ情報などがレシピ情報を投稿したユーザを識別する識別情報と紐付けられた情報)をレシピDB51に記憶することにより管理する。例えば、あるユーザが投稿した「野菜カレー」のレシピは、カテゴリ「カレーライス」に属するレシピであり、使用食材情報として、「じゃがいも」、「人参」、「タマネギ」、「ブロッコリー」、「トマト」、「ほうれん草」や、調味料(「塩」や「胡椒」など)や、それに準ずるもの(例えば「カレールー」など)が紐付けられて記憶される。
また、レシピ管理部1aは、投稿されたレシピに対して投稿された作成レポートをレシピ毎に管理する。作成レポートは、投稿されたレシピを利用して他のユーザが実際に料理を行った際に、当該レシピに対する感想(例えば、料理を行ったユーザが感じた料理のおいしさや調理手順の手軽さなど)を記したレポートである。作成レポートは、レシピDB51の各レシピに紐付けられて管理される。
更にまた、レシピ管理部1aは、レシピや作成レポートの投稿に関する処理や、レシピのアレンジを行ったユーザに対する特典付与に関する処理を実行する。
特典付与の例については後述する。
検索情報取得部1bは、検索クエリが検索に用いられた回数を取得する検索情報取得処理を実行する。
検索部1cは、検索クエリに応じた検索結果を抽出する検索処理を実行する。このとき、抽出されたレシピの数を検索結果数として取得する。
尚、以下の説明では、検索クエリに含まれるキーワードを単に「キーワード」と記載する。また、「キーワード」の一例として食材(例えば「ニンジン」や「トマト」など)を挙げるが、それ以外にも料理名(「ハンバーグ」や「カレー」など)や調味料や調理方法や調理器具などが「キーワード」とされてもよい。
更に、複数のキーワードを含む検索クエリを「複合検索条件」とする。例えば、キーワードK1,K2,K3を含む検索クエリ「K1,K2,K3」は複合検索条件である。
そして、複合検索条件の一部のキーワードのみを含む検索クエリを「第一部分検索条件」とし、残りのキーワードを「第二部分検索条件」とする。具体的には、複合検索条件「K1,K2,K3」の第一部分検索条件は、「K1」、「K2」、「K3」、「K1,K2」、「K1,K3」、「K2,K3」の6種類を挙げることができる。それぞれの第一部分検索条件に対して第二部分検索条件が存在し、例えば、第一部分検索条件としての「K1」に対する第二部分検索条件は「K2,K3」とされる。また、第一部分検索条件としての「K1,K2」に対する第二部分検索条件は「K3」とされる。
また、キーワードを羅列した検索クエリ以外の例も考えられる。例えば、「食材Aと食材Bを使った料理C」などの文である。この場合には、「食材A」、「食材B」、「料理C」がキーワードとされ、第一部分検索条件としては「食材A,料理C」や「食材A」などとされる。そして、第一部分検索条件としての「食材A,料理C」に対する第二部分検索条件は「食材B」とされる。
このような文からキーワードを抽出するために、レシピ管理サーバ1はキーワードが登録されたキーワードDBを利用してもよい。
検索部1cは、後述する各種の処理において、これらの第一部分検索条件を用いた検索処理や第二部分検索条件を用いた検索処理を実行する。
支援対象決定部1dは、検索クエリの被検索回数と検索結果数に応じて複合検索条件のうちから支援対象とする検索条件(支援対象検索条件)を決定する。支援対象検索条件は、検索結果数を増加させるための支援の対象とされた検索クエリであり、例えば、被検索回数に対して検索結果数が少ない(即ち、ニーズがある検索クエリであるにも関わらず抽出されるレシピ数が少ない)検索クエリなどである。詳しくは後述する。
また、支援対象決定部1dは、複合検索条件に優先度を付与し、優先度の高い複合検索条件を支援対象検索条件として選択する場合がある。他にも、決定した支援対象検索条件が複数ある場合には、以降の処理の順番を決定するための優先度を付与してもよい。
アレンジ対象決定部1eは、支援対象検索条件(複合検索条件のうち検索結果数を増加させるための支援が必要とされたもの)の第一部分検索条件を用いた検索処理によって抽出されたレシピを「アレンジ対象レシピ」として決定する処理を実行する。
アレンジ対象レシピとは、後述する処理で選択した支援依頼対象ユーザに対してレシピのアレンジを依頼する場合において、アレンジ対象とされたレシピである。
具体的に、支援対象検索条件として「K1,K2,K3」という複合検索条件が選ばれたとする。そして第一部分検索条件としての「K1,K2」を用いた検索処理によってレシピ「R1」、「R2」が抽出されたとする。レシピ「R1」及び「R2」は、例えば、キーワード「K1」及び「K2」を含むが「K3」を含まないレシピである。即ち、支援対象検索条件に基づく検索結果としては抽出されないが、第一部分検索条件に基づく検索結果としては抽出されるレシピである。
このようなレシピ「R1」、「R2」がアレンジ対象レシピとして決定される。
ユーザ管理部1fは、ユーザ情報をユーザDB50に記憶することによって管理する。
また、支援対象検索条件の「第二部分検索条件」を用いた検索処理によって抽出されたレシピを投稿したユーザを「支援依頼対象ユーザ」として特定するユーザ特定処理を実行する。
具体的に、支援対象検索条件として「K1,K2,K3」という複合検索条件が選ばれたとする。そして第一部分検索条件としての「K1,K2」が選択された場合、第二部分検索条件は「K3」とされ、「K3」に基づいてレシピ「R3」、「R4」が抽出されたとする。
レシピ「R3」、「R4」は、例えば、キーワード「K3」を含むが「K1」及び「K2」は含まないレシピである。
このようなレシピ「R3」を投稿したユーザや「R4」を投稿したユーザを支援依頼対象ユーザとして選択する。
レシピ「R3」や「R4」を投稿したユーザは、キーワード「K3」に関する料理が得意である可能性がある。即ち、キーワード「K3」が食材であった場合、食材「K3」を用いた料理が得意と推測されるユーザであり、キーワード「K3」が調理器具であった場合は、調理器具「K3」を用いた料理が得意と推測されるユーザである。
ユーザ特定処理は、そのようなユーザを支援依頼対象ユーザとして特定するための処理である。
支援依頼対象ユーザの選択についてのいくつかの具体的な例は後述する。
送信制御部1gは、支援依頼対象ユーザに対して、第二部分検索条件によって抽出されるようなレシピの生成を依頼する情報を送信する。例えば、アレンジ対象レシピに第二部分検索条件を加えた「アレンジレシピ」の投稿を依頼するための情報である。
以降の説明においては、このような情報を「アレンジ依頼情報」と記載する。
先の例を用いて説明すると、支援依頼対象ユーザ(レシピ「R3」や「R4」を投稿したユーザ)に対して、レシピ「R1」,「R2」にキーワード「K3」を加えたアレンジレシピの投稿を依頼するための情報が、アレンジ依頼情報とされる。
アレンジ依頼情報通知処理の実現手段としては、いくつかの例を挙げることができる。
例えば、電子メールによって、アレンジ依頼情報を支援依頼対象ユーザに通知してもよい。また、レシピサイト上にアレンジ依頼情報を通知するためのメッセージを表示してもよい。更に、レシピサイトを閲覧するための専用アプリケーションを利用しているユーザに対して、プッシュ通知による通知を行ってもよい。
レシピ管理サーバ1には、他にも、各種情報を送受信する機能や、ユーザのログイン操作に対する認証処理などを実現するために必要な各部が設けられている。認証処理は、ユーザ端末3から送信されたログイン情報としてのユーザID(Identification)とパスワードを、ユーザDB50に記憶された認証情報と照合する処理である。
<2.ハードウェア構成>

図3は、図1に示したレシピ管理サーバ1とユーザ端末3のハードウェア、及び、ユーザDB50とレシピDB51と検索DB52と履歴DB53とウェブページDB54のハードウェアを例示する図である。それぞれのサーバや端末、DBにおけるコンピュータ装置のCPU(Central Processing Unit)101は、ROM(Read Only Memory)102に記憶されているプログラム、または記憶部108からRAM(Random Access Memory)103にロードされたプログラムに従って各種の処理を実行する。RAM103にはまた、CPU101が各種の処理を実行する上において必要なデータなども適宜記憶される。
CPU101、ROM102、およびRAM103は、バス104を介して相互に接続されている。このバス104には、入出力インターフェース105も接続されている。
入出力インターフェース105には、キーボード、マウス、タッチパネルなどよりなる入力装置106、LCD(Liquid Crystal Display)、CRT(Cathode Ray Tube)、有機EL(Electroluminescence)パネルなどよりなるディスプレイ、並びにスピーカなどよりなる出力装置107、HDD(Hard Disk Drive)やフラッシュメモリ装置などより構成される記憶部108、通信ネットワーク2を介しての通信処理や機器間通信を行う通信部109が接続されている。
入出力インターフェース105にはまた、必要に応じてメディアドライブ110が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア111が適宜装着され、リムーバブルメディア111に対する情報の書込や読出が行われる。
このようなコンピュータ装置では、通信部109による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア111を介したデータやプログラムの受け渡しが可能である。
CPU101が各種のプログラムに基づいて処理動作を行うことで、レシピ管理サーバ1とユーザ端末3、ユーザDB50とレシピDB51と検索DB52と履歴DB53とウェブページDB54のそれぞれにおいて後述する情報処理や通信が実行される。
尚、レシピ管理サーバ1とユーザ端末3、ユーザDB50とレシピDB51と検索DB52と履歴DB53とウェブページDB54を構成するそれぞれの情報処理装置は、図3のようなコンピュータ装置が単一で構成されることに限らず、システム化された複数のコンピュータ装置によって構成されてもよい。複数のコンピュータ装置は、LANなどによりシステム化されていてもよいし、インターネットなどを利用したVPN(Virtual Private Network)などにより通信可能な状態で遠隔地に配置されたものでもよい。
レシピ管理サーバ1としての各機能は、情報処理装置においてCPU101でプログラムに応じて実行される処理により実現される機能である。但し以下において説明する各構成の処理の全部又は一部をハードウェアにより実現してもよい。
また各機能をソフトウエアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。1つのプログラムにより複数の機能の処理が実行されてもよいし、1つの機能が複数のプログラムモジュールの連携で実現されてもよい。
<3.DB>

レシピ管理サーバ1が管理する各DBの説明を行う。各DBは、レシピ管理サーバ1がアクセス可能とされていればどのような形態で実現されていてもよい。例えばレシピ管理サーバ1と同一システム内の記憶部に各DBのすべてが形成されていてもよいし、各DBの一部又は全部が別体とされていてもよいし、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん各DBが一つの装置(例えば一つのHDD等)内に形成されている必要はない。また各DBのそれぞれが、それぞれ1つのDBとして構成される必要もない。例えばユーザDB50として記憶される情報が、複数のユーザDB(例えばログイン用のユーザDBと取引用のユーザDBなど)により記憶管理されてもよい。以下説明する各DBは、実施の形態の処理に関連する情報の記憶部を、それぞれ1つのDBの形態で例示したものに過ぎない。
[3−1.ユーザDB]
ユーザDB50にはレシピ管理サーバ1が提供するサービスを受けるユーザの情報が記憶される。例えば、一人のユーザを特定可能な一つのユーザID(Identification)に対して、ログインパスワード、氏名、年齢、性別、メールアドレスなどの個人的な情報が紐付けられて記憶される。また、ユーザ毎の嗜好情報が記憶されてもよい。嗜好情報は、ユーザによるレシピ情報や料理情報に関する検索や閲覧などの挙動に応じてレシピ管理サーバ1が判定したユーザの好みの食材(嗜好食材)や嫌いな食材(非嗜好食材)の情報や、ユーザに関わる投稿情報(テキスト情報やタグ情報や画像情報など)に基づいてレシピ管理サーバ1が判定したユーザの好みの食材(嗜好食材)や嫌いな食材(非嗜好食材)である。また、嗜好情報はユーザによって任意に登録された情報であってもよい。嗜好情報は、ユーザがレシピ検索を行った際に利用される。
[3−2.レシピDB]
レシピDB51は、ユーザから投稿されたレシピの情報が記憶されるDBである。具体的には、それぞれのレシピを識別可能なレシピIDに対して、レシピを投稿したユーザを特定するユーザIDと、投稿日時情報と、レシピが属するカテゴリ情報と、レシピの使用食材情報(分量などを含む)と、レシピの調理手順と、料理画像(完成した料理の画像や調理途中の料理の画像)などの画像情報と、レシピを実際に利用した(料理を作成した)他のユーザによって投稿された作成レポートを特定する作成レポートIDと、が紐付けられて記憶される。
また、レシピの詳細ページのURL(Uniform Resource Locator)情報がレシピIDに紐付けられて記憶されてもよい。
更に、レシピDB51には、各レシピに対して投稿された作成レポートの情報が記憶される。作成レポートの情報としては、レポート内容を示すテキストデータや調理した料理の画像や投稿者を識別可能なユーザIDや投稿日時情報などが記憶される。
尚、上述したアレンジレシピの情報は、作成レポートとは別にアレンジレシピ情報として記憶されてもよいし、作成レポートのレポート内容を解析して当該作成レポートをアレンジレシピ情報として扱ってもよい。
具体的には、レポート内容として「トマトを加えたらより一層おいしくなりました。」という一文があった場合、当該作成レポートをアレンジレシピとして扱う。即ち、第二部分検索条件として「トマト」が指定された場合に、当該アレンジレシピの投稿ユーザは、「トマト」を用いたレシピが得意なユーザ(上述した支援依頼対象ユーザ)とされてもよい。
このとき、キーワード「トマト」に関するアレンジレシピであることを記憶することにより、支援依頼対象ユーザの検索をする毎のアレンジレシピの内容の解析が不要となる。
[3−3.検索DB]
検索DB52は、検索クエリと対応した検索結果が記憶されるDBである。具体的には、「カレーライス」や「ハンバーグ」などの料理名や「きのこ」や「トマト」などの食材名などの検索クエリに応じて、複数のレシピが検索結果として紐付けられて記憶される。
例えば、ユーザが指定した検索クエリに応じて検索処理が実行され、その結果抽出された検索結果が検索クエリに紐付けられて検索DB52に記憶される。このように紐付けが行われることで、新たな検索要求があった際に検索処理を実行せずに以前の検索結果を利用した検索結果の提示を行うことができる機会が増える。
尚、予め定期的に検索キーワードを用いた検索処理を実行しておき、その結果抽出された検索結果が検索キーワードに紐付けられて検索DB52に記憶されるようにしてもよい。
[3−4.履歴DB]
履歴DB53には、ユーザの操作に関する各種履歴が記憶される。
具体的には、ユーザが行った操作毎に、ユーザID、履歴ID、操作種別、操作対象(「レシピ閲覧操作」や「レシピ印刷操作」であれば閲覧対象となったレシピID、「ウェブページを閲覧する操作」であれば対象となったウェブページを特定する情報、「投稿操作」であれば、投稿されたレシピIDや作成レポートID、「ユーザ情報変更操作」であれば変更対象となった項目名など)、操作日時、操作結果(「ログイン操作」であればログイン可否、「ユーザ情報変更操作」であれば変更可否などが記憶される。
[3−5.ウェブページDB]
ウェブページDB54には、レシピ管理サーバ1がユーザに提供する各種ウェブページのデータが記憶される。具体的には、レシピ検索ページや特集ページや検索結果ページやレシピ詳細ページやユーザページなどのウェブページデータである。
ウェブページデータとしては、ウェブページのURL(Uniform Resource Locator)情報と各ウェブページ上に配置されるオブジェクト(画像やテキストやバナーなど)の配置情報が記憶される。配置情報とは、ウェブページ上における各オブジェクトの配置態様(位置や大きさ、色等)が記載された情報である。
尚、ウェブページDB54に記憶される情報は、例えば、HTML(Hyper Text Markup Language)やXHTML(Extensible HyperText Markup Language)などの構造化文書ファイルで記憶されてもよい。
<4.処理の流れ>

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

[4−1.全体の流れ]
先ずは、レシピ管理サーバ1とユーザ端末3の間で行われる各種処理や情報の送受信について、図4を参照して説明する。
具体的には、レシピ管理サーバ1が提供する各種サービスを受けるために、ユーザがユーザ端末3を用いてログイン操作を行い、レシピを検索して利用する例を説明する。
ユーザ端末3はステップS101において、ユーザによるログイン画面表示操作(即ちログイン画面を表示させる操作)に応じたログイン画面情報要求処理を実行する。
ログイン画面情報要求処理によりユーザ端末3からレシピ管理サーバ1へログイン画面情報要求が送信されると、レシピ管理サーバ1はステップS201において、ログイン画面情報送信処理を実行する。
これにより、例えば、レシピ管理サーバ1から受信したレシピサイトのログイン画面情報(ウェブページデータ)に応じたウェブページがユーザ端末3上に表示される。
尚、レシピ管理サーバ1はこのとき、ログイン画面をユーザ端末3上に表示させたことを履歴(即ちログイン画面の閲覧履歴)として記憶してもよい。
次に、ユーザ端末3はステップS102において、ユーザの入力操作に応じたログイン情報(ユーザIDとログインパスワード)をレシピ管理サーバ1へ送信するログイン情報送信処理を実行する。
ユーザ端末3からレシピ管理サーバ1へログイン情報が送信されると、レシピ管理サーバ1はステップS202において認証処理を実行し、続くステップS203においてログイン履歴を記憶する処理を実行し、ステップS204において認証結果通知処理を実行する。
具体的には、レシピ管理サーバ1は、ユーザ端末3上で入力されたユーザIDとパスワードをユーザDB50に記憶された情報と比較して当該ユーザのログイン可否を判定し、当該ログイン可否情報を履歴情報として履歴DB53に記憶し、当該ログイン可否情報を認証結果としてユーザ端末3へ通知する。尚、認証結果をユーザ端末3へ送信すると共に、レシピサイトのトップページのウェブページデータを送信してもよい。これにより、ユーザ認証がなされると共に、ユーザ端末3上にレシピサイトのトップページが表示される。
尚、図4に示す一連の流れは、ステップS202の認証処理においてログイン可と判定された場合を示している。ステップS202においてログイン不可と判定した場合は、ユーザ端末3は再度ステップS102の処理を実行し、これに応じてレシピ管理サーバ1はステップS202の処理を実行する。
続いて、ユーザ端末3はステップS103において、ユーザが入力したレシピを検索するための検索クエリをレシピ管理サーバ1へ送信する検索クエリ送信処理を実行する。
この処理では、例えば、ユーザによって指定されたレシピ名の一部や使用食材などが、検索結果を抽出するための情報として、レシピ管理サーバ1へ伝達される。
検索クエリを受信したレシピ管理サーバ1は、ステップS205で検索クエリと検索DB52に記憶された情報に基づいてレシピの検索結果を抽出(取得)する検索処理を実行する。
更に、レシピ管理サーバ1はステップS206において、検索履歴を履歴DB53に記憶する検索履歴記憶処理を実行する。
尚、検索クエリが検索された回数を示す被検索回数を管理している場合には、検索履歴記憶処理を実行する際に被検索回数を加算する処理を行う。
続いて、レシピ管理サーバ1はステップS207において、ステップS205で抽出した検索結果をユーザ端末3上に表示させるための提示処理を実行する。この処理では、例えば、提示優先度情報が含まれた検索結果をユーザ端末3へ送信する。
提示処理が実行されると、ユーザ端末3では、レシピ管理サーバ1から受信した検索結果が提示される。ユーザが検索結果として表示された複数のレシピから一つのレシピを選択する操作を行うと、ユーザ端末3はステップS104において、レシピ選択処理を実行する。
レシピ選択処理は、ユーザが選択したレシピが何れのレシピであるかを選択レシピ情報としてレシピ管理サーバ1に通知する。尚、この処理は、選択したレシピの詳細ページのウェブページデータを要求する処理である。
選択レシピ情報を受信したレシピ管理サーバ1は、ステップS208において、レシピの詳細ページの閲覧履歴を履歴DB53に記憶する処理を実行し、続くステップS209において、選択されたレシピの詳細情報が記載されたウェブページのデータを送信する詳細情報送信処理を実行する。
この処理によって、ユーザ端末3上に、ユーザが選択したレシピに関する詳細情報が提示される。詳細情報とは、例えば、レシピに使用する食材情報や調理手順、調理器具情報などの情報である。他にも、選択されたレシピに対して投稿された作成レポートの情報などを含んでいてもよい。
ユーザ端末3上に詳細情報が表示されたレシピに対し、ユーザが利用したことを推定可能な操作を行った場合、利用したことを推定可能な操作に関する情報がレシピ管理サーバ1に対して送信される。
例えば、図4に示すように、レシピの利用が推定される操作として、レシピの詳細情報を印刷するための操作を行った場合、ユーザ端末3はステップS105において、印刷操作に関する情報をレシピ管理サーバ1に送信する処理を実行する。
印刷操作に関する情報とは、操作を行ったユーザのユーザIDと印刷対象とされたレシピのレシピIDなどである。
印刷操作情報を受信したレシピ管理サーバ1は、ステップS210において、レシピを利用したことを示す履歴を履歴DB53に記憶する利用履歴記憶処理を実行する。
尚、レシピの利用が推定される操作の他の例としては、例えば、作成レポートの投稿操作や、お気に入りレシピに登録する操作や、レシピ詳細情報の所定時間(例えば、調理時間の8割の時間)以上の閲覧操作などを挙げることができる。
何れの操作も、ユーザによるレシピの利用(即ち実際に調理を行ったこと)が推測される操作である。
[4−2.バッチ処理の第1例]
検索クエリに基づいて検索されるレシピの数を増加(充実)させるためにレシピ管理サーバ1が実行する処理について説明する。
尚、この処理は、ユーザ端末3から検索クエリを受信したタイミングで行ってもよいが、処理に要する時間(即ちレシピ管理サーバ1の処理能力)によっては検索結果を迅速にユーザに提示することができなくなるため、好ましくない場合がある。
ここでは、バッチ処理によって定期的に処理を実行する例を説明する。こうすることにより、レシピサイトの利用が少ない時間帯などに処理を行うことが可能となる。
先ず、バッチ処理の第1例について、図5乃至図11の各図を参照して説明する。
レシピ管理サーバ1は、ステップS301において、複合検索条件を取得する処理を実行する。複合検索条件取得処理について、図6に示す。
複合検索条件は二つ以上のキーワードを含む検索クエリであり、前述のように「トマト、ニンジン」や「トマトを使ったハンバーグ」などの検索クエリである。
図6に示すように、先ずレシピ管理サーバ1はステップS401において、所定期間内に検索に用いられた検索クエリ(複合検索条件とは限らない検索クエリ)を履歴DB53から一つ取得する処理を実行する。
取得した一つの検索クエリに対して、レシピ管理サーバ1はステップS402において、複合検索条件であるか否か(即ち二つ以上のキーワードを含んでいるか否か)を判定する処理を実行する。
取得検索クエリが複合検索条件である場合、レシピ管理サーバ1はステップS403において、当該検索クエリを処理対象の複合検索条件として選択する。処理対象とは、図5に示す以降の各処理の対象となることを示す。
ステップS403の処理の後、或いは、ステップS402において複合検索条件でないと判定した後、レシピ管理サーバ1はステップS404において、検索クエリの取得が終了したか(即ち所定期間内に検索された他の検索クエリはないか)を判定する処理を実行する。
検索クエリの取得が終了した場合、即ち、所定期間内に検索された全ての検索クエリに対して複合検索条件であるか否かを判定する処理を実行した場合、レシピ管理サーバ1は図6に示す一連の処理を終了する。
一方、検索クエリの取得が終了していない場合、レシピ管理サーバ1は再びステップS401の処理を実行する。
図5の説明に戻る。
一または複数の複合検索条件(ステップS403において処理対象の複合検索条件として選択されたもの)を取得したレシピ管理サーバ1は、ステップS302において、複合検索条件毎の検索情報として被検索回数を取得する処理を実行する。被検索回数とは、前述のように、複合検索条件が検索クエリとして用いられた回数を表す。
被検索回数は、履歴DB53から取得する。また、検索DB52に検索クエリ毎の被検索回数が記憶されている場合には、検索DB52から取得してもよい。
ここで、被検索回数についていくつかの例を説明する。
被検索回数は、検索リクエスト毎に加算されるものであってもよい。即ち、同じユーザが同一の検索クエリを用いた複数回の検索を行った場合であっても被検索回数に全て加算される。
また、被検索回数は、単位時間(単位期間)毎のユニークユーザ(重複しないユーザであり、換言すれば、異なるユーザIDが付与されたユーザ)による検索リクエストの回数(同一ユーザによる検索リクエストは1回としてカウントした回数)であってもよい。即ち、単位時間を仮に1週間とした場合、同一ユーザが一週間に同一検索クエリを用いた検索を5回行ったとしても、被検索回数としては1回分として加算される。そして、同一検索クエリを用いた一週間に1回の検索を三週間に亘り行った場合、被検索回数としては3回分として加算される。
更に、被検索回数は、ユーザ毎に最大1回まで加算されることとしてもよい。即ち、同一ユーザによる同一検索クエリを用いた検索は、何度行っても1回とされる。換言すれば、被検索回数が100回のレシピは、これまでに100人の異なるユーザが閲覧したこととなる。
被検索回数を取得したレシピ管理サーバ1は、続くステップS303において、処理対象の複合検索条件毎の検索結果数を取得する処理を実行する。
検索結果数は、検索クエリに応じて抽出されるレシピの数である。即ち、ステップS303では、複合検索条件毎に検索処理を行い、抽出された検索レシピ数を取得する処理を実行する。
尚、検索DB52に検索クエリ毎の検索結果数が記憶されている場合は、検索DB52から取得してもよい。
ステップS301乃至S303の各処理を実行することによって、レシピ管理サーバ1は、取得した複合検索条件毎に被検索回数と検索結果数を取得する。
続いて、レシピ管理サーバ1はステップS304において、複合検索条件毎の被検索回数と検索結果数に応じて支援対象検索条件を決定する処理を実行する。
支援対象検索条件決定処理については、図7を参照して説明する。
支援対象検索条件決定処理では、レシピ管理サーバ1は先ずステップS501において、処理対象とされた複合検索条件を一つ選択する。
続いて、レシピ管理サーバ1はステップS502において、選択した複合検索条件の被検索回数に対する検索結果数が所定割合(閾値)以下であるか否かを判定する。
そして、被検索回数に対する検索結果数が所定割合以下であると判定した場合、レシピ管理サーバ1はステップS503において、選択された複合検索条件を支援対象検索条件として決定する。
即ち、当該複合検索条件が検索クエリとして利用される回数に対して検索結果数が少ない複合検索条件ほど優先して支援対象検索条件として決定される。
次に、レシピ管理サーバ1はステップS504において、処理対象とされた複合検索条件に対してステップS501乃至S503の各処理を実行したか否かを判定する。
未処理の複合検索条件が残っている場合、レシピ管理サーバ1はステップS501の処理を再度実行する。
一方、処理対象とされた複合検索条件全てに対して各処理を実行した場合、レシピ管理サーバ1は図7に示す一連の処理を終了する。
尚、ステップS502の判定で用いる所定割合の閾値は複合検索条件によらず同一の閾値とされてもよいし、複合検索条件に応じて変更される閾値とされてもよい。
所定割合を複合検索条件に応じて変更する場合、例えば、相対的に被検索回数が多い複合検索条件ほど所定割合の閾値を緩和する(小さくする)。また、複合検索条件に対応する被検索回数に対する被利用回数の割合が少ないほど所定割合の閾値を厳しく(大きく)する構成にしてもよい。
被利用回数とは、前述した印刷操作などの利用操作の対象となった回数である。被検索回数に対する被利用回数が少ないということは、即ち検索クエリを用いた検索がされているにも関わらず抽出された何れのレシピも利用しなかったということであり、検索結果として抽出されたレシピの中にユーザを満足させるものがなかった可能性がある。そのため、そのような検索クエリ(即ち複合検索条件)が支援対象とされやすくするために、所定割合の閾値を大きくする。
また、所定割合の閾値を複合検索条件に応じて変更する場合の別の例として、例えば、単位期間あたりの被検索回数の変化が大きいほど所定割合の閾値を厳しく(大きく)することが考えられる。
単位期間あたりの被検索回数の変化が大きい複合検索条件は注目されている可能性が高い。そのような複合検索条件によって抽出されるレシピ数は多い方が好ましいため、支援対象とされやすくするために所定割合の閾値を厳しく(大きく)する。
一方、単位期間あたりの被検索回数の変化が小さい複合検索条件はユーザを満足させるレシピが抽出されないことがユーザに認知され始めていることが考えられる。ユーザがレシピサイトを利用しなくなる状況を回避するために、そのような複合検索条件によって抽出されるレシピ数を増加させることが望ましく、当該複合検索条件が支援対象とされやすいように所定割合の閾値を厳しく(大きく)する。
尚、支援対象検索条件決定処理の別の例については後述する。
図5の説明に戻る。
支援対象となる複合検索条件を決定したレシピ管理サーバ1は、ステップS305において、アレンジ対象とするレシピを決定する処理を実行する。
この処理でアレンジ対象として決定されたレシピは、現時点では先の複合検索条件を用いた検索によって抽出されないレシピであり、且つ、今後の検索によって新たに抽出対象とすることが望まれるレシピである。
アレンジ対象レシピ決定処理について、具体的に図8を参照して説明する。
レシピ管理サーバ1は、先ずステップS601において、検索結果数の多いキーワードを含む第一部分検索条件のうちの一つを選択する処理を実行する。
具体的に説明すると、例えば、支援対象の複合検索条件としてキーワードK1,K2,K3を含む検索クエリ「K1,K2,K3」が選択されたとする。そして、キーワードK1を検索クエリとして抽出されたレシピ数(検索結果数)が100、キーワードK2を検索クエリとして抽出されたレシピ数が200、キーワードK3を検索クエリとして抽出されたレシピ数が300とする。
このとき、検索結果数の多いキーワードとしてはK3となる。
検索クエリ「K1,K2,K3」に対する第一部分検索条件は、前述のように「K1」、「K2」、「K3」、「K1,K2」、「K1,K3」、「K2,K3」の6種類となるが、このうち検索結果数の多いキーワードK3を含む第一部分検索条件としては、「K3」、「K1,K3」、「K2,K3」の3種類となる。
即ち、ステップS601の処理では、この3種類の第一部分検索条件から一つを選択する処理となる。以降では、この具体例を用いて説明する。
続いて、レシピ管理サーバ1はステップS602において、第一部分検索条件「K3」を用いたレシピ検索を行う。即ち、300個のレシピが検索結果として抽出される。
そして、レシピ管理サーバ1はステップS603において、検索結果として抽出された300個のレシピから、第一部分検索条件「K3」を満たし「K1」及び「K2」を満たさないレシピを選択して、アレンジ対象レシピとする処理を実行する。
これにより、現時点において複合検索条件を用いた検索によって抽出されてしまうレシピを除き、複合検索条件の第一部分検索条件のみを満たすレシピがアレンジ対象レシピとして抽出される。
以降、検索結果数の多いキーワードを含む第一部分検索条件全て(即ち「K3」、「K1,K3」、「K2,K3」の3種類全て)に対して同様の処理を実行する。
即ち、レシピ管理サーバ1はステップS604において、検索結果数の多いキーワードを含む第一部分検索条件のうち未処理のものがあるか否かを判定し、未処理のものがある場合はステップS601の処理を再度実行する。
未処理のものが無い場合、レシピ管理サーバ1は図8に示す一連の処理を終了する。
尚、支援対象検索条件が複数ある場合には、ステップS601乃至S604の各処理を支援対象検索条件の数だけ実行することとなる。
図5の説明に再び戻る。
アレンジ対象レシピを決定したレシピ管理サーバ1は、続くステップS306において、支援依頼の対象とする(即ち支援を依頼する)ユーザを特定する処理を実行する。
この処理は、アレンジ対象レシピに基づくアレンジレシピの投稿が期待されるユーザを特定する処理である。
具体的な処理例について、図9を参照して説明する。
先ず、レシピ管理サーバ1はステップS701において、アレンジ対象レシピのうちの一つを選択する。例えば、先のキーワード「K3」を用いた検索処理によって抽出される300個のレシピ(レシピR3001〜R3300)がアレンジ対象レシピとされた場合、その中から一つ(例えばレシピR3001)を選択する。
続いて、レシピ管理サーバ1はステップS702において、対応する第二部分検索条件を取得する。
対応する第二部分検索条件とは、選択したアレンジ対象レシピR3001の抽出に用いられた第一部分検索条件が支援対象検索条件「K1,K2,K3」の第一部分検索条件「K3」であることから、「K1,K2」が第二部分検索条件となる。
そして、レシピ管理サーバ1はステップS703において、第二部分検索条件としてのキーワードを使用したレシピや既存のレシピをアレンジしたアレンジレシピを投稿した投稿ユーザを検索する。
例えば、キーワード「K1,K2」(一例としてK1=「トマト」、K2=「チーズ」とする)を用いたレシピとしては、「トマトたっぷりのアラビアータ」や「トマトとチーズのオムレツ」などのように、「トマト」と「チーズ」を元から含んでいる(使用食材とされている)レシピがある。
そして、それ以外にも、「トマト」と「チーズ」を使用食材として用いていないレシピがキーワード「トマト、チーズ」によって抽出されることがある。例えば、「我が家のシーフードカレー」のようなレシピ(「トマト」や「チーズ」を使用していないレシピ)に対して作成レポートが投稿されており、その作成レポートに「トマトとチーズを入れてアレンジしてみました。とてもおいしかったです。」のようなレポート内容が記載されている場合などである。即ち、このレシピには元々使用食材として「トマト」や「チーズ」が含まれていないにも関わらず、そのレシピをアレンジした情報が作成レポートとして投稿されている。このような作成レポートは、ある種のレシピ情報(アレンジレシピ情報)として抽出される。
ステップS703の処理は、このような第二部分検索条件としてのキーワード「K1」,「K2」をアレンジ食材として利用したレシピ(作成レポートも含む)を投稿した投稿ユーザを検索する処理である。
第二部分検索条件としての「トマト」と「チーズ」をアレンジ食材として使用した投稿ユーザは、当該アレンジ食材を用いて既存の料理をアレンジする能力に長けている可能性が高い。
レシピ管理サーバ1は、続くステップS704で、検索された投稿ユーザを支援依頼対象ユーザとして特定する処理を実行する。即ち、検索結果として抽出されたアレンジレシピ(作成レポート)を投稿した投稿ユーザを支援依頼対象ユーザとして取得する。
支援依頼対象ユーザを取得したレシピ管理サーバ1は、続くステップS705において、未処理のアレンジ対象レシピがあるかどうかを判定する。
未処理のアレンジ対象レシピがある場合、レシピ管理サーバ1は再びステップS701乃至S704の各処理を実行する。
未処理のアレンジ対象レシピが無くなった場合、レシピ管理サーバ1は図9に示す一連の処理を終了する。
尚、第二部分検索条件としてのキーワードをアレンジ食材として使用した投稿ユーザを検索する例を示したが、それ以外の例も考え得る。
例えば、「トマト」と「チーズ」を使用するレシピ(アレンジレシピではない)を投稿した投稿ユーザを検索してもよい。そのようなユーザが「トマト」と「チーズ」を利用するレシピを得意とする可能性もあるためである。
具体的に図10を参照して説明する。
レシピ管理サーバ1はステップS801において、アレンジ対象レシピのうちの一つを選択し、ステップS802において対応する第二部分検索条件を取得する。これらの処理は、図9のステップS701及びS702の処理と同様である。
続いて、レシピ管理サーバ1はステップS803において、第二部分検索条件としてのキーワード「トマト」と「チーズ」を使用してレシピ検索を行い、投稿ユーザを取得する。
この処理では、「トマト」と「チーズ」を用いたアレンジレシピの投稿ユーザだけでなく、「トマト」と「チーズ」を用いるレシピの投稿ユーザも抽出される。
そして、レシピ管理サーバ1は、続くステップS804において検索された投稿ユーザを支援依頼対象ユーザとして特定する処理を実行し、ステップS805において未処理のアレンジ対象レシピがあるかどうかを判定する処理を実行する。
ステップS804及びS805の処理は、図9のステップS704及びS705の処理と同様である。
また、実績のある投稿ユーザを支援依頼対象ユーザとして優先的に選択する例もある。
具体的に図11を参照して説明する。
レシピ管理サーバ1はステップS901乃至S903の各処理を実行する。この処理は、図10のステップS801乃至S803の各処理と同様の処理である。
第二部分検索条件としてのキーワードを含むレシピの投稿ユーザを検索したレシピ管理サーバ1は、ステップS904において、当該投稿ユーザの中から実績のある投稿ユーザを支援依頼対象ユーザとして特定する処理を実行する。
実績のある投稿ユーザとは、レシピ投稿数や作成レポート投稿数が多い投稿ユーザや、投稿ユーザによって投稿された投稿レシピの被利用回数が多い投稿ユーザや、或いは被利用率(=被利用回数/閲覧数)の高い投稿ユーザなどである。また、投稿ユーザに対する利用ユーザからの評価が高い投稿ユーザを実績のある投稿ユーザとするように構成してもよい。
そのような投稿ユーザに対してレシピのアレンジを依頼することは、質の高いレシピ投稿やアレンジレシピの投稿がなされる可能性を高めることができ、延いてはレシピサイトの利用人数の増加を図ることができる。
支援依頼対象ユーザの特定が完了したレシピ管理サーバ1は、続くステップS905において、未処理のアレンジ対象レシピがあるかどうかを判定する処理を実行する。ステップS905の処理は、ステップS705やS805と同様の処理である。
続いて、図5の説明に戻る。
図9乃至図11のいずれかの処理を実行することにより、支援依頼対象ユーザを特定したレシピ管理サーバ1は、ステップS307において、アレンジ依頼情報を通知する処理を実行する。
アレンジ依頼情報には、アレンジ対象レシピの情報と、第二部分検索条件と、支援依頼対象ユーザが少なくとも含まれる。例えば、支援依頼対象ユーザに対して、「「トマト」と「チーズ」を使ってレシピR3001、R3002・・・をアレンジしませんか?」というメッセージを送る。
アレンジ依頼情報の通知は、前述のように、電子メールやレシピサイト上への表示などによって行われる。
まとめると、図5のステップS301乃至S307の処理を実行することにより、支援対象検索条件としての検索クエリ「トマト、チーズ、ニンジン」から第一部分検索条件「ニンジン」と第二部分検索条件「トマト、チーズ」が選択され、第一部分検索条件「ニンジン」を用いた検索によって抽出された「ニンジンサラダ」がアレンジ対象レシピとして選択され、第二部分検索条件とされた「トマト」と「チーズ」を用いたアレンジレシピを得意とする支援依頼対象ユーザに対して「ニンジンサラダ」に「トマト」と「チーズ」を加えたアレンジレシピの提案を依頼する。
これにより、レシピ情報の充実かが図られる。
[4−3.複合検索条件取得処理第2例]
先のバッチ処理の第1例では、複合検索条件取得処理の例として、所定期間内に検索された複合検索条件を、処理対象の複合検索条件として選択する例を示した。
ここでは、複合検索条件取得処理の第2例について、図12を参照して説明する。
先ず、レシピ管理サーバ1はステップS1001において、検索クエリを取得する処理を実行する。
続いて、レシピ管理サーバ1はステップS1002において、取得した検索クエリが複合検索条件であるか否かを判定した後、ステップS1003で被検索回数を取得し、ステップS1004で被利用回数を取得する処理を実行する。
これらの処理により、複合検索条件についての被検索回数と被利用回数を取得する。
続いて、レシピ管理サーバ1はステップS1005において、被検索回数に対する被利用回数が所定値以下であるか否かを判定する処理を実行する。
即ち、被検索回数に対する被利用回数の割合が所定閾値以上である場合には、ユーザが検索結果にある程度満足していることが推測されるため、処理対象の複合検索条件からは外すことを意図している。
ステップS1005において、被検索回数に対する被利用回数の割合が所定閾値以下であると判定した場合、レシピ管理サーバ1はステップS1006において、当該複合検索条件を処理対象として選択する処理を実行する。
ステップS1006の処理を実行した後、或いは、ステップS1002において検索クエリが複合検索条件でないと判定した後、或いは、被検索回数に対する被利用回数の割合が所定閾値以下でないと判定した後、レシピ管理サーバ1はステップS1007において、検索クエリの取得が終了したか否かを判定する。
検索クエリの取得が終了していない場合、即ち、図12に示す一連の処理の対象とされた検索クエリがまだ残っている場合、レシピ管理サーバ1は再度ステップS1001の処理を実行する。
一方、検索クエリの取得が終了したと判定した場合、レシピ管理サーバ1は図12に示す一連の処理を終了する。
尚、複合検索条件取得処理として図12に示す処理を行った場合、図5のステップS302の処理は図12のステップS1003で既に実行しているため不要となる。
[4−4.支援対象検索条件決定処理第2例]
先のバッチ処理の第1例における支援対象検索条件決定処理では、被検索回数に対する検索結果数が所定割合以下である複合検索条件を支援対象検索条件とする例を示した。
支援対象検索条件決定処理の第2例では、類似する複合検索条件の中で被検索回数に対する検索結果数の割合が相対的に少ない複合検索条件を支援対象検索条件とする。
具体的に、図13を参照して説明する。
先ず、レシピ管理サーバ1はステップS1101において、処理対象とされた複合検索条件を選択する。この処理は、図7のステップS501の処理と同様の処理である。
続いて、レシピ管理サーバ1はステップS1102において、類似した複合検索条件を取得する。
類似した複合検索条件については、後述する。
次に、レシピ管理サーバ1はステップS1103において、処理対象とされた複合検索条件の被検索回数に対する検索結果数の割合が、類似した複合検索条件の被検索回数に対する検索結果数の割合と比較して相対的に少ないか否かを判定する処理を実行する。
相対的に少ないと判定した場合、レシピ管理サーバ1はステップS1104において、支援対象検索条件として決定する。換言すれば、処理対象とされた複合検索条件の被検索回数に対する検索結果数の割合が絶対的に少なかったとしても、類似する複合検索条件が同様の水準であれば、必ずしも処理対象とされた複合検索条件を支援対象とする必要がない。
ステップS1104を実行した後、または、ステップS1103において相対的に少なくないと判定した後、レシピ管理サーバ1はステップS1104において、処理対象とされた複合検索条件に対してステップS1101乃至S1104の各処理を実行したか否かを判定する。
ステップS1104,S1105の各処理は、図7におけるステップS503,S504の各処理と同様の処理である。
類似する複合検索条件の例を以下に示す。
1)複合検索条件に含まれる少なくとも一部のキーワードが一致する条件
2)複合検索条件に含まれるキーワードのうち、使用頻度の高い少なくとも一部のキーワードが一致する条件
3)複合検索条件に含まれる少なくとも一部のキーワードが一致し、且つ複合検索条件に含まれるキーワード数が一致する条件
1)によれば、例えば、検索クエリ「K1,K2,K3」と検索クエリ「K1,K4,K5,K6」はそれぞれ三つのキーワードを含むため、類似する複合検索条件とされる。
同一のキーワード「K1」を含む検索クエリは、同程度の検索結果数となることが望ましい。「トマト」と「ジャガイモ」を含むレシピとして抽出されたレシピ数が、「トマト」と「ニンジン」を含むレシピとして抽出されたレシピ数に対して著しく少ない場合、検索を行ったユーザに提示するレシピは「トマト」と「ジャガイモ」の双方を食材として使用するレシピが提示される可能性が低くなる。このような状況は好ましくない。
但し、一部のキーワードの選び方によっては、検索結果数が同程度とならないことがやむを得ない場合もある。
2)によれば、検索クエリ「K1,K2,K3」の中でキーワード「K1」と「K2」が使用頻度の高い(例えばレシピの使用食材として用いられる頻度の高い)食材(以降、「高頻度」と記載)であり、キーワード「K3」が使用頻度の低い食材(以降、「低頻度」と記載)である場合に、検索クエリ「K1,K2,K3」の類似する複合検索条件としては、検索クエリ「K1(高頻度),K2(高頻度),K4(高頻度)」や検索クエリ「K1(高頻度),K3(低頻度),K5(低頻度)」などが挙げられる。
尚、検索クエリ「K1(高頻度),K2(高頻度),K4(高頻度)」の検索結果数は検索クエリ「K1(高頻度),K3(低頻度),K5(低頻度)」の検索結果数よりも多くなりやすい。即ち、検索クエリ「K1(高頻度),K3(低頻度),K5(低頻度)」は、低頻度のキーワード「K3」と「K5」を含んでいるため、検索結果数が少なかったとしても妥当である可能性がある。
一方、検索クエリ「K1(高頻度),K2(高頻度),K4(高頻度)」は、含まれるキーワードが全て高頻度であることから、検索結果数は多いことが望ましい。
そのため、検索クエリ「K1(高頻度),K3(低頻度),K5(低頻度)」の検索結果数が少ないことよりも、検索クエリ「K1(高頻度),K2(高頻度),K4(高頻度)」の検索結果数が少ないことの方が問題が大きい。
従って、何れの複合検索条件の検索結果数を充実化させることが望ましいのかは、キーワードの使用頻度を鑑みることが重要である。
例えば、検索クエリ「K1(高頻度),K2(高頻度),K3(低頻度)」と類似するものとして検索クエリ「K1(高頻度),K3(低頻度),K5(低頻度)」を取得した場合、キーワードの出現頻度が異なるため、検索結果数を同程度とするために検索結果数の充実化を図ることが妥当とは限らない。また、低頻度のキーワードを含んでいるため、検索結果数が少なかったとしても仕方が無い可能性もある。
そこで、一部のキーワードとして高頻度となるキーワードを選択することが望ましい。
先の検索クエリ「K1(高頻度),K2(高頻度),K3(低頻度)」においては、高頻度のキーワードとなる「K1」と「K2」が一部のキーワードとされる。
このとき、検索クエリ「K1(高頻度),K2(高頻度),K3(低頻度)」と類似する複合検索条件としては、一部のキーワード(「K1」及び「K2」)を含む検索クエリ「K1(高頻度),K2(高頻度),K4(高頻度)」や検索クエリ「K1(高頻度),K2(高頻度),K5(低頻度)」などである。
組み合わせられやすいキーワードは、専用のDBから取得してもよいし、検索履歴から抽出(即ち検索結果数が多い組み合わせを抽出)してもよい。
また、レシピタイトルに含まれやすいキーワードを一部のキーワードとしてもよい。
2)についてまとめると、高頻度となるキーワードを一部のキーワードとして選択することにより、検索結果数が同程度となることが望ましい複合検索条件が比較対象として選択され、比較対象に対して相対的に検索結果数が少ない場合に当該複合検索条件は充実化が必要な検索条件として決定され、以降の処理においてレシピの充実化が図られる。
3)によれば、例えば、検索クエリ「K1,K2,K3」に対して、検索クエリ「K1,K2,K4」や検索クエリ「K1,K5,K6」などは、一部のキーワードが一致すると共に複合検索条件に含まれるキーワード数が一致するため、類似する複合検索条件とされる。
一般的に、AND検索を行うためのキーワード数を増やすと、検索結果数は減る。そして、絞り込み検索を行うためにはキーワードを追加した検索を行うが、元々の検索結果数が少ないと、絞り込み検索によって抽出される検索結果数は更に少なくなり、ユーザの要望を満たすものとはなり難い。
例えば、検索クエリ「K1,K2,K3,K4,K5」によって抽出された検索結果数が少ない場合において検索結果数を増やしたいと考えたときに、検索クエリ「K1,K2,K3,K4,K5」の検索結果数を増やせばよいのか、そもそもキーワードが一つ少ない検索クエリ「K1,K2,K3,K4」の検索結果数が少ないのか、或いは更にキーワードが少ない検索クエリ「K1,K2」の時点で検索結果数が少ないのかによって、アレンジ対象レシピの選び方が異なってくる。
そこで、同数のキーワードを含み且つ検索キーワードが一部同一である複合検索条件においては、同程度の検索結果数を提示することが望ましいという観点から、そのような検索条件を類似する複合検索条件とする。
[4−5.アレンジ対象レシピ決定処理第2例]
アレンジ対象レシピ決定処理の第2例について、図14を参照して説明する。
レシピ管理サーバ1は先ずステップS1201において、第一部分検索条件のうちの一つを選択し、続くステップS1202において、当該第一部分検索条件を用いたレシピ検索を行う。
そして、レシピ管理サーバ1はステップS1203において、抽出されたレシピの中から、当該第一部分検索条件がレシピの中で優先度の高いキーワード(例えば主要食材)とされたレシピを選択し、アレンジ対象レシピとして選択する。
例えば、第一部分検索条件として検索クエリ「K1(食材)」が選択され、それに応じて検索結果としてのレシピR1,R2,R3が検索された場合を考える。
レシピR1は、キーワード「K1」が少量使用されているレシピであるため、レシピR1におけるキーワード「K1」は低重要度とされる。
レシピR2は、キーワード「K1」がレシピタイトルに含まれているため(例えば「K1を使った○○サラダ」)、レシピR2においてキーワード「K2」は高重要度とされる。
レシピR3は、キーワード「K1」が最も使用量の多い使用食材とされているため、レシピR3におけるキーワード「K1」は高重要度とされる。
このような場合では、第一部分検索条件(上記の「K1」)がレシピの中で優先度の高いキーワードとされたレシピ(即ちレシピR2,R3)をアレンジ対象レシピとして選択する。
次に、レシピ管理サーバ1はステップS1204において、未処理の第一部分検索条件があるか否かを判定し、未処理のものがある場合はステップS1201の処理を再度実行する。
未処理のものが無い場合、レシピ管理サーバ1は図14に示す一連の処理を終了する。
[4−6.バッチ処理の第2例]
バッチ処理の第2例について、図15を参照して説明する。
尚、図5に示したバッチ処理の第1例と同様の処理については、同一の符号を付し、適宜説明を省略する。
レシピ管理サーバ1は、ステップS301において複合検索条件を取得し、ステップS302において被検索回数を取得し、ステップS303において検索結果数を取得する。
そして、レシピ管理サーバ1はステップS304において支援対象とする複合検索条件を決定し、ステップS305においてアレンジ対象レシピを決定する。
ステップS301乃至S305の各処理は、図5に示す各処理と同様である。
続いて、レシピ管理サーバ1はステップS308において、アレンジ対象レシピの数に応じて複合検索条件に優先度を付与する。
アレンジ対象レシピ数が多いということは、アレンジレシピが投稿される確率(或いは投稿数)が向上するということである。
即ち、効果の高い複合検索条件の優先度を高くすることによって、効率よくレシピの充実化を図ることができる。
次に、レシピ管理サーバ1はステップS306において、支援依頼対象ユーザを特定し、ステップS307においてアレンジ依頼情報を通知する。
尚、アレンジ依頼情報通知処理では、ステップS308で付与した優先度に応じた通知処理を実行してもよい。
例えば、ある支援依頼対象ユーザに対して複数のアレンジ依頼を行う場合、優先度の高い方のアレンジ対象レシピに関する依頼のみを行ってもよい。また、優先度の高い方のアレンジ対象レシピに関する依頼から順に通知してもよい。
[4−7.特典付与処理]
レシピの充実化をより促進するために、アレンジレシピの投稿者に対して特典を付与する場合の処理について、図16を参照して説明する。
尚、図16に示す処理は、新しいアレンジレシピが投稿されるたびに実行(例えばバッチ処理によって実行)してもよいし、一定期間毎に定期的に実行してもよい。
先ず、レシピ管理サーバ1はステップS1301において、新規に投稿されたアレンジレシピを抽出する処理を実行する。
尚、バッチ処理などによって実行する場合は、前回処理から今回処理までの間に投稿されたアレンジレシピが新規に投稿されたレシピとされる。
続いて、レシピ管理サーバ1はステップS1302において、当該アレンジレシピを投稿した投稿ユーザを特定する。
そして、当該投稿ユーザに対してアレンジ情報通知依頼を行ったか否か(即ち図5におけるステップS307の処理を投稿ユーザに対して行ったか否か)を判定する処理を実行する。
ここで、投稿ユーザに対してアレンジ情報通知依頼を行っていたとしても、投稿されたアレンジレシピと関連が無い場合(即ち依頼と異なるアレンジレシピが投稿された場合)は、依頼なしと判定する。
換言すれば、アレンジ情報通知依頼によってアレンジレシピが投稿されたとみなす事ができる場合のみ、依頼ありと判定する。
アレンジ情報通知依頼ありと判定した場合、レシピ管理サーバ1はステップS1304において、特典付与を行う。
特典を付与した後、或いは、ステップS1303において依頼なしと判定した後、レシピ管理サーバ1はステップS1305において、未処理の新規投稿アレンジレシピがあるか否かを判定する処理を行う。
未処理の新規投稿アレンジレシピがある場合、レシピ管理サーバ1は再度ステップS1301の処理を実行する。一方、未処理の新規投稿アレンジレシピがない場合、レシピ管理サーバ1は図16に示す一連の処理を終了する。
尚、新しいアレンジレシピが投稿されるたびに図16の処理を実行する場合、ステップS1305の処理は不要となる。
ここで、特典の付与例について述べる。
被検索回数の変化量が大きい複合検索条件について投稿されたアレンジレシピであった場合、大きな特典(或いは優良な特典)を付与することが考えられる。
また、被検索回数に対する被利用回数が少ない(即ちユーザが検索結果に満足していないと推測される)複合検索条件について投稿されたアレンジレシピであった場合、大きな特典(或いは優良な特典)を付与することが考えられる。
更に、類似する複合検索条件の中で被検索回数に対する検索結果数が相対的に少ないものに対して投稿されたアレンジレシピであった場合、大きな特典(或いは優良な特典)を付与することが考えられる。
更にまた、アレンジ情報通知依頼からアレンジレシピ投稿までの経過時間が短い(即ち対応が早い)ほど、大きな特典(或いは優良な特典)を付与することが考えられる。
更にまた、投稿されたアレンジレシピと他のアレンジレシピとの類似度が低い(即ち投稿されたアレンジレシピがユニークな)ほど、大きな特典(或いは優良な特典)を付与することが考えられる。
<5.まとめ>

上記したレシピ管理サーバ1は、レシピに関する情報を検索するために用いられる少なくとも2以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得部1bと、取得した複合検索条件に対応する検索結果数を取得する検索部1cと、取得した被検索回数と複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定部1dと、支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定部1eと、支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理部1fと、特定された支援依頼対象ユーザに対して決定されたアレンジ対象レシピと第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御部1gと、を備えている。
これにより、ユーザの潜在的なニーズが汲み取られて、相対的に不足しているレシピの特定がなされる。
従って、ユーザの要望に沿ったレシピ情報の拡充を支援することが可能となる。
また、検索レシピ数が少ないと、ユーザが使い勝手の悪さを感じてしまい、レシピ検索サービスを利用しなくなってしまう虞がある。上記構成によれば、これらの問題を解決し、ユーザが離れてしまうことを防止することができる。
尚、検索の被検索回数と複合検索条件の検索結果数(検索結果として抽出されたレシピ数)に基づいて支援対象検索条件を決定するため、支援対象検索条件を適切に絞ることが可能となる。そのため、全ての複合検索条件を支援対象検索条件とするよりも、アレンジ対象レシピの決定などの各処理に要するレシピ管理サーバ1の処理負担が軽減される。即ち、必要な箇所(ユーザの潜在的なニーズのある箇所)に対して効率のよいレシピ情報の追加が促進される。
また、バッチ処理の第1例において説明したように、支援対象決定部1dは、複合検索条件の被検索回数に対する検索結果数の割合と、複合検索条件の検索結果数に応じて特定された閾値と、に基づいて複合検索条件を支援対象とするか否かを決定してもよい。
これにより、被検索回数に対して複合検索条件の検索結果数の割合が所定値以下となる複合検索条件を支援対象検索条件とすることが可能となる。即ち、このような複合検索条件は、ニーズがあるにも関わらず十分に満足できる検索結果が提示できていない可能性がある。このような複合検索条件が支援対象とされることにより、検索結果として抽出されるレシピ情報が拡充されて、ユーザの要望を満足させることができる。
更に、バッチ処理の第1例に記載で説明したように、支援対象決定部1dは、複合検索条件の被検索回数に対する検索結果数の割合と、複合検索条件に対応する検索結果に含まれる各レシピの被利用回数に応じて特定された閾値と、に基づいて複合検索条件を支援対象とするか否かを決定してもよい。
これにより、検索結果に含まれる各レシピの中に、ユーザの要望を満たすレシピのの多寡に応じて閾値が特定される。
従って、ユーザの要望を満たすレシピが少ない複合検索条件が支援対象とされやすくなり、ユーザの要望を満足させる可能性を高めることができる。
更にまた、バッチ処理の第1例において説明したように、支援対象決定部1dは、複合検索条件に対応する検索結果に含まれる各レシピの被利用回数が被検索回数に対して少ないほど高い閾値を特定してもよい。
被検索回数に対して検索結果としてのレシピの被利用回数が少ない場合、検索操作を行ったにも関わらず、所望のレシピが提示されずにレシピ検索を諦めた(若しくは他の検索条件を設定したレシピ検索を再度行った)ユーザが多い可能性が高い。
このような場合に、高い閾値を特定することは、当該複合検索条件が支援対象検索条件として選択される可能性が高くなる。
従って、ユーザの実際の行動に基づいたニーズを推測したレシピ情報の拡充が行われる可能性を高めることができる。
そして、バッチ処理の第1例において説明したように、支援対象決定部1dは、複合検索条件の所定期間における被検索回数の変化が大きいほど高い閾値を特定してもよい。
例えば、被検索回数の変化が短時間に増大した場合などは、ニーズが急激に増加していることが推測される。このような状態において高い閾値を特定することは、当該複合検索条件が支援対象検索条件として選択される可能性が高くなる。
即ち、ニーズの変動に即したレシピ情報の拡充が行われやすくする環境を提供することができる。
加えて、支援対象検索条件決定処理第2例で説明したように、支援対象決定部1dは、複合検索条件に対応する被検索回数に対する検索結果数の割合が他の複合検索条件に対応する検索回数に対する検索結果数の割合に対して相対的に少ない複合検索条件を対象として決定してもよい。
これにより、例えば、類似する複合検索条件が複数あった場合に、相対的にレシピ数の足りていない複合検索条件が支援対象検索条件とされる。
従って、他の類似する複合検索条件よりもレシピ拡充の必要性が高いと推測される複合検索条件に対して、検索結果の充実化(即ち複合検索条件の検索結果数の増加)を図ることが可能となる。
そして、バッチ処理の第2例において説明したように、支援対象決定部1dは、第一部分検索条件に対応する検索結果数が多い複合検索条件ほど高い優先度を付与し、送信制御部1gは、相対的に高い優先度を付与された複合検索条件に基づく依頼情報が優先的に送信されるように制御してもよい。
これにより、アレンジ対象レシピの候補となるレシピが多く検索される複合検索条件の優先度が高くなる。換言すれば、アレンジ対象レシピが多くなる。
アレンジ対象レシピが多いということは、アレンジ対象レシピを改良したアレンジレシピの提案数も増加する可能性が高いため、レシピ情報の充実化を効率よく図ることができる。
また、バッチ処理の第1例において説明したように、アレンジ対象決定部1eは、支援対象として決定された複合検索条件に含まれるキーワード毎に優先度を特定し、当該特定された優先度が相対的に高いキーワードを含む第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定してもよい。
これにより、優先度が相対的に高いキーワード(例えば主要食材)が既に含まれるレシピがアレンジ対象レシピとして抽出される。即ち、アレンジ対象食材は主要食材以外の食材とされ、主要食材はレシピ通りに調理される。従って、主要食材を奇抜にアレンジしたアレンジレシピなどが投稿される可能性を低減させることができる。
即ち、万人に受け入れられる汎用性の高いレシピによってレシピ情報の充実化を図ることができる。
尚、上述したレシピ管理サーバ1では、食材A,食材B,食材C,食材Dを検索条件とした検索を行った場合、四つの食材全てを利用するレシピが検索結果として抽出される例を挙げたが、検索結果を充実させるために、一部(例えば四つの食材のうち三つの食材)のみを利用するレシピが検索結果として更に抽出されてもよい。即ち、食材A,食材B,食材Cを利用するが食材Dを利用しないレシピが検索結果として抽出されてもよい。
このとき、食材A,食材Bを第一部分検索条件とした場合に、食材C,食材Dの双方を第二部分検索条件とするだけでなく、そのうちの一部(即ち食材Cなど)を第二部分検索条件とすることによっても、レシピ検索結果の充実化を図ることができる。
即ち、食材A,食材Bを利用するアレンジ対象レシピに食材Cを加えたアレンジレシピの投稿がなされれば、食材A,食材B,食材C,食材Dを検索条件として抽出されるレシピの充実化が図られる。
そのため、第二部分検索条件としては、「支援対象検索条件」の中から第一部分検索条件を除いた全ての条件でなくてもよい。
<6.プログラム及び記憶媒体>

以上、本発明の情報処理装置の実施の形態としてのレシピ管理サーバ1を説明してきたが、実施の形態のプログラムは、レシピ管理サーバ1における各処理を情報処理装置(CPU等)に実行させるプログラムである。
実施の形態のプログラムは、レシピに関する情報を検索するために用いられる少なくとも2以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得機能を情報処理装置に実行させる。
また、前記取得した複合検索条件に対応する検索結果数を取得する検索機能を情報処理装置に実行させる。
更に前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定機能を情報処理装置に実行させる。
更にまた、前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定機能を情報処理装置に実行させる。
そして、前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理機能を情報処理装置に実行させる。
加えて、前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御機能を情報処理装置に実行させる。
即ちこのプログラムは、レシピ管理サーバ1に対して図4のステップS201乃至S210の各処理、図5乃至図16の各処理を実行させるプログラムである。
このようなプログラムにより、上述したレシピ管理サーバ1としての情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置などの機器に内蔵されている記憶媒体としてのHDDや、CPUを有するマイクロコンピュータ内のROMなどに予め記録しておくことができる。或いはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的或いは永続的に格納(記録)しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータなどにインストールする他、ダウンロードサイトから、LAN、インターネットなどのネットワークを介してダウンロードすることもできる。
1 レシピ管理サーバ、1a レシピ管理部、1b 検索情報取得部、1c 検索部、1d 支援対象決定部、1e アレンジ対象決定部、1f ユーザ管理部、1g 送信制御部、2 通信ネットワーク、3 ユーザ端末、50 ユーザDB、51 レシピDB、52 検索DB、53 履歴DB、54 ウェブページDB

Claims (10)

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

Applications Claiming Priority (1)

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

Publications (2)

Publication Number Publication Date
JP6275932B1 true JP6275932B1 (ja) 2018-02-07
JPWO2017175356A1 JPWO2017175356A1 (ja) 2018-04-12

Family

ID=60000345

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017554622A Active JP6275932B1 (ja) 2016-04-07 2016-04-07 情報処理装置、情報処理方法、プログラム

Country Status (2)

Country Link
JP (1) JP6275932B1 (ja)
WO (1) WO2017175356A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003107233A1 (ja) * 2002-06-13 2003-12-24 株式会社電通 レシピ提供システムおよびレシピ提供方法
JP2004220414A (ja) * 2003-01-16 2004-08-05 Osaka Gas Co Ltd 調理レシピ提供システム
WO2013161107A1 (ja) * 2012-04-26 2013-10-31 楽天株式会社 情報処理装置、情報処理方法、情報処理プログラム及び記録媒体

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003107233A1 (ja) * 2002-06-13 2003-12-24 株式会社電通 レシピ提供システムおよびレシピ提供方法
JP2004220414A (ja) * 2003-01-16 2004-08-05 Osaka Gas Co Ltd 調理レシピ提供システム
WO2013161107A1 (ja) * 2012-04-26 2013-10-31 楽天株式会社 情報処理装置、情報処理方法、情報処理プログラム及び記録媒体

Also Published As

Publication number Publication date
WO2017175356A1 (ja) 2017-10-12
JPWO2017175356A1 (ja) 2018-04-12

Similar Documents

Publication Publication Date Title
US10387505B2 (en) Generating advertisements using functional clusters
US10318538B2 (en) Systems, methods, and apparatuses for implementing an interface to view and explore socially relevant concepts of an entity graph
JP6291145B2 (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
US9317585B2 (en) Search query suggestions based on personal information
US20160188742A1 (en) Bookmarking Search Results
JP2015537319A (ja) モバイルアプリケーションをプッシュする方法及びシステム
US20140280575A1 (en) Determining activities relevant to users
US20120084657A1 (en) Providing content to a user from multiple sources based on interest tag(s) that are included in an interest cloud
US20210279297A1 (en) Linking to a search result
JP6641460B2 (ja) 情報処理装置、情報処理方法、プログラム
JP6279823B1 (ja) 情報処理装置、情報処理方法、プログラム
JP6275932B1 (ja) 情報処理装置、情報処理方法、プログラム
CN108259588B (zh) 一种基于大数据的文化云平台的推送方法及装置
WO2013047471A1 (ja) 店舗情報検索システム
JP6310165B1 (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
KR102195691B1 (ko) 주종 및 주량에 따른 음식점 추천 장치 및 방법
WO2017001944A1 (en) Method, system and computer readable memory for generating ranked search results incorporating suggests
JP6890747B2 (ja) 情報処理装置、情報処理方法、プログラム
JP2020024490A (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
KR20200125410A (ko) 영화 속성 언어 관리 방법 및 장치
JP6641486B2 (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
US20240073160A1 (en) Providing a system-generated response in a messaging session
JP6749984B2 (ja) 情報提供方法、情報提供プログラム、及び情報提供装置
JP6262926B1 (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
WO2022251130A1 (en) Linking to a search result

Legal Events

Date Code Title Description
A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20171201

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20171212

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180110

R150 Certificate of patent or registration of utility model

Ref document number: 6275932

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250