JP6275932B1 - 情報処理装置、情報処理方法、プログラム - Google Patents
情報処理装置、情報処理方法、プログラム Download PDFInfo
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information 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
Description
特許文献1には、ユーザが入力した表現から抽出されたキーワードのうち不必要に厳しい条件を課すものを削除して緩和された検索条件に基づいて検索を行う技術について記載されている。
例えば、特許文献1に記載の技術は、ユーザの入力した表現からキーワードの一部を削除するものであるため、ユーザのニーズ(具体的にはユーザが入力した全てのキーワード)に合致する情報を提供することについては考慮されていない
そこで、本発明は、推定されるユーザのニーズに対して相対的に不足しているレシピ情報を拡充するための環境を提供することを目的とする。
これにより、ユーザの潜在的なニーズが汲み取られて、相対的に不足しているレシピの特定がなされる。
これにより、被検索回数に対して複合検索条件の検索結果数の割合が所定値以下となる複合検索条件を支援対象検索条件とすることが可能となる。
これにより、検索結果に含まれる各レシピの中に、ユーザの要望を満たすレシピのの多寡に応じて閾値が特定される。
被検索回数に対して検索結果としてのレシピの被利用回数が少ない場合、検索操作を行ったにも関わらず、所望のレシピが提示されずにレシピ検索を諦めた(若しくは他の検索条件を設定したレシピ検索を再度行った)ユーザが多い可能性が高い。
このような場合に、高い閾値を特定することは、当該複合検索条件が支援対象検索条件として選択される可能性が高くなる。
例えば、被検索回数の変化が短時間に増大した場合などは、ニーズが急激に増加していることが推測される。このような状態において高い閾値を特定することは、当該複合検索条件が支援対象検索条件として選択される可能性が高くなる。
これにより、例えば、類似する複合検索条件が複数あった場合に、相対的にレシピ数の足りていない複合検索条件が支援対象検索条件とされる。
これにより、アレンジ対象レシピの候補となるレシピが多く検索される複合検索条件の優先度が高くなる。換言すれば、アレンジ対象レシピが多くなる。
これにより、優先度が相対的に高いキーワード(例えば主要食材)が既に含まれるレシピがアレンジ対象レシピとして抽出される。
この情報処理方法により、推定されるユーザのニーズに対して相対的に不足しているレシピ情報を拡充するための環境を提供する。
本発明に係るプログラムは、上記情報処理方法として実行する処理を情報処理装置に実行させるプログラムである。これらのプログラムにより上記の情報処理装置を実現する。
<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は、通信ネットワーク2を介して、ユーザ端末3,3,3,・・・と相互に通信可能な状態で接続されている。また、レシピ管理サーバ1は、ユーザに関する情報が記憶されるユーザDB(Database)50、レシピに関する情報が記憶されるレシピDB51、検索クエリや検索結果の情報が記憶される検索DB52、ユーザによる各種操作の履歴が記憶される履歴DB53、レシピサイトを構成する各種ウェブページのウェブページデータが記憶されるウェブページDB54と接続されている。
尚、以降の説明において単に「ユーザ」と記載した場合は、投稿ユーザや支援依頼対象ユーザ(後述)やその他のユーザを区別せずに全てのユーザを指すものとする。
尚、レシピ管理サーバ1は、本発明の情報処理装置の実施の形態に相当する。
また通信ネットワーク2の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばIEEE(Institute of Electrical and Electronics Engineers)1394、USB(Universal Serial Bus)、電力線搬送、電話線などの有線でも、IrDA(Infrared Data Association)のような赤外線、ブルートゥース(登録商標)、802.11無線、携帯電話網、衛星回線、地上波デジタル網などの無線でも利用可能である。
ユーザ端末3では、必要に応じて各種の送受信処理や表示処理などが実行される。また、ユーザ端末3は、例えば、通信機能を備えたPC(Personal Computer)やフィーチャーフォンやPDA(Personal Digital Assistant)、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。
特典付与の例については後述する。
尚、以下の説明では、検索クエリに含まれるキーワードを単に「キーワード」と記載する。また、「キーワード」の一例として食材(例えば「ニンジン」や「トマト」など)を挙げるが、それ以外にも料理名(「ハンバーグ」や「カレー」など)や調味料や調理方法や調理器具などが「キーワード」とされてもよい。
このような文からキーワードを抽出するために、レシピ管理サーバ1はキーワードが登録されたキーワードDBを利用してもよい。
検索部1cは、後述する各種の処理において、これらの第一部分検索条件を用いた検索処理や第二部分検索条件を用いた検索処理を実行する。
また、支援対象決定部1dは、複合検索条件に優先度を付与し、優先度の高い複合検索条件を支援対象検索条件として選択する場合がある。他にも、決定した支援対象検索条件が複数ある場合には、以降の処理の順番を決定するための優先度を付与してもよい。
アレンジ対象レシピとは、後述する処理で選択した支援依頼対象ユーザに対してレシピのアレンジを依頼する場合において、アレンジ対象とされたレシピである。
具体的に、支援対象検索条件として「K1,K2,K3」という複合検索条件が選ばれたとする。そして第一部分検索条件としての「K1,K2」を用いた検索処理によってレシピ「R1」、「R2」が抽出されたとする。レシピ「R1」及び「R2」は、例えば、キーワード「K1」及び「K2」を含むが「K3」を含まないレシピである。即ち、支援対象検索条件に基づく検索結果としては抽出されないが、第一部分検索条件に基づく検索結果としては抽出されるレシピである。
このようなレシピ「R1」、「R2」がアレンジ対象レシピとして決定される。
また、支援対象検索条件の「第二部分検索条件」を用いた検索処理によって抽出されたレシピを投稿したユーザを「支援依頼対象ユーザ」として特定するユーザ特定処理を実行する。
具体的に、支援対象検索条件として「K1,K2,K3」という複合検索条件が選ばれたとする。そして第一部分検索条件としての「K1,K2」が選択された場合、第二部分検索条件は「K3」とされ、「K3」に基づいてレシピ「R3」、「R4」が抽出されたとする。
レシピ「R3」、「R4」は、例えば、キーワード「K3」を含むが「K1」及び「K2」は含まないレシピである。
このようなレシピ「R3」を投稿したユーザや「R4」を投稿したユーザを支援依頼対象ユーザとして選択する。
レシピ「R3」や「R4」を投稿したユーザは、キーワード「K3」に関する料理が得意である可能性がある。即ち、キーワード「K3」が食材であった場合、食材「K3」を用いた料理が得意と推測されるユーザであり、キーワード「K3」が調理器具であった場合は、調理器具「K3」を用いた料理が得意と推測されるユーザである。
ユーザ特定処理は、そのようなユーザを支援依頼対象ユーザとして特定するための処理である。
支援依頼対象ユーザの選択についてのいくつかの具体的な例は後述する。
以降の説明においては、このような情報を「アレンジ依頼情報」と記載する。
先の例を用いて説明すると、支援依頼対象ユーザ(レシピ「R3」や「R4」を投稿したユーザ)に対して、レシピ「R1」,「R2」にキーワード「K3」を加えたアレンジレシピの投稿を依頼するための情報が、アレンジ依頼情報とされる。
例えば、電子メールによって、アレンジ依頼情報を支援依頼対象ユーザに通知してもよい。また、レシピサイト上にアレンジ依頼情報を通知するためのメッセージを表示してもよい。更に、レシピサイトを閲覧するための専用アプリケーションを利用しているユーザに対して、プッシュ通知による通知を行ってもよい。
図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に対する情報の書込や読出が行われる。
CPU101が各種のプログラムに基づいて処理動作を行うことで、レシピ管理サーバ1とユーザ端末3、ユーザDB50とレシピDB51と検索DB52と履歴DB53とウェブページDB54のそれぞれにおいて後述する情報処理や通信が実行される。
尚、レシピ管理サーバ1とユーザ端末3、ユーザDB50とレシピDB51と検索DB52と履歴DB53とウェブページDB54を構成するそれぞれの情報処理装置は、図3のようなコンピュータ装置が単一で構成されることに限らず、システム化された複数のコンピュータ装置によって構成されてもよい。複数のコンピュータ装置は、LANなどによりシステム化されていてもよいし、インターネットなどを利用したVPN(Virtual Private Network)などにより通信可能な状態で遠隔地に配置されたものでもよい。
また各機能をソフトウエアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。1つのプログラムにより複数の機能の処理が実行されてもよいし、1つの機能が複数のプログラムモジュールの連携で実現されてもよい。
レシピ管理サーバ1が管理する各DBの説明を行う。各DBは、レシピ管理サーバ1がアクセス可能とされていればどのような形態で実現されていてもよい。例えばレシピ管理サーバ1と同一システム内の記憶部に各DBのすべてが形成されていてもよいし、各DBの一部又は全部が別体とされていてもよいし、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん各DBが一つの装置(例えば一つのHDD等)内に形成されている必要はない。また各DBのそれぞれが、それぞれ1つのDBとして構成される必要もない。例えばユーザDB50として記憶される情報が、複数のユーザDB(例えばログイン用のユーザDBと取引用のユーザDBなど)により記憶管理されてもよい。以下説明する各DBは、実施の形態の処理に関連する情報の記憶部を、それぞれ1つのDBの形態で例示したものに過ぎない。
ユーザDB50にはレシピ管理サーバ1が提供するサービスを受けるユーザの情報が記憶される。例えば、一人のユーザを特定可能な一つのユーザID(Identification)に対して、ログインパスワード、氏名、年齢、性別、メールアドレスなどの個人的な情報が紐付けられて記憶される。また、ユーザ毎の嗜好情報が記憶されてもよい。嗜好情報は、ユーザによるレシピ情報や料理情報に関する検索や閲覧などの挙動に応じてレシピ管理サーバ1が判定したユーザの好みの食材(嗜好食材)や嫌いな食材(非嗜好食材)の情報や、ユーザに関わる投稿情報(テキスト情報やタグ情報や画像情報など)に基づいてレシピ管理サーバ1が判定したユーザの好みの食材(嗜好食材)や嫌いな食材(非嗜好食材)である。また、嗜好情報はユーザによって任意に登録された情報であってもよい。嗜好情報は、ユーザがレシピ検索を行った際に利用される。
レシピDB51は、ユーザから投稿されたレシピの情報が記憶されるDBである。具体的には、それぞれのレシピを識別可能なレシピIDに対して、レシピを投稿したユーザを特定するユーザIDと、投稿日時情報と、レシピが属するカテゴリ情報と、レシピの使用食材情報(分量などを含む)と、レシピの調理手順と、料理画像(完成した料理の画像や調理途中の料理の画像)などの画像情報と、レシピを実際に利用した(料理を作成した)他のユーザによって投稿された作成レポートを特定する作成レポートIDと、が紐付けられて記憶される。
更に、レシピDB51には、各レシピに対して投稿された作成レポートの情報が記憶される。作成レポートの情報としては、レポート内容を示すテキストデータや調理した料理の画像や投稿者を識別可能なユーザIDや投稿日時情報などが記憶される。
具体的には、レポート内容として「トマトを加えたらより一層おいしくなりました。」という一文があった場合、当該作成レポートをアレンジレシピとして扱う。即ち、第二部分検索条件として「トマト」が指定された場合に、当該アレンジレシピの投稿ユーザは、「トマト」を用いたレシピが得意なユーザ(上述した支援依頼対象ユーザ)とされてもよい。
このとき、キーワード「トマト」に関するアレンジレシピであることを記憶することにより、支援依頼対象ユーザの検索をする毎のアレンジレシピの内容の解析が不要となる。
検索DB52は、検索クエリと対応した検索結果が記憶されるDBである。具体的には、「カレーライス」や「ハンバーグ」などの料理名や「きのこ」や「トマト」などの食材名などの検索クエリに応じて、複数のレシピが検索結果として紐付けられて記憶される。
例えば、ユーザが指定した検索クエリに応じて検索処理が実行され、その結果抽出された検索結果が検索クエリに紐付けられて検索DB52に記憶される。このように紐付けが行われることで、新たな検索要求があった際に検索処理を実行せずに以前の検索結果を利用した検索結果の提示を行うことができる機会が増える。
尚、予め定期的に検索キーワードを用いた検索処理を実行しておき、その結果抽出された検索結果が検索キーワードに紐付けられて検索DB52に記憶されるようにしてもよい。
履歴DB53には、ユーザの操作に関する各種履歴が記憶される。
具体的には、ユーザが行った操作毎に、ユーザID、履歴ID、操作種別、操作対象(「レシピ閲覧操作」や「レシピ印刷操作」であれば閲覧対象となったレシピID、「ウェブページを閲覧する操作」であれば対象となったウェブページを特定する情報、「投稿操作」であれば、投稿されたレシピIDや作成レポートID、「ユーザ情報変更操作」であれば変更対象となった項目名など)、操作日時、操作結果(「ログイン操作」であればログイン可否、「ユーザ情報変更操作」であれば変更可否などが記憶される。
ウェブページDB54には、レシピ管理サーバ1がユーザに提供する各種ウェブページのデータが記憶される。具体的には、レシピ検索ページや特集ページや検索結果ページやレシピ詳細ページやユーザページなどのウェブページデータである。
ウェブページデータとしては、ウェブページのURL(Uniform Resource Locator)情報と各ウェブページ上に配置されるオブジェクト(画像やテキストやバナーなど)の配置情報が記憶される。配置情報とは、ウェブページ上における各オブジェクトの配置態様(位置や大きさ、色等)が記載された情報である。
尚、ウェブページDB54に記憶される情報は、例えば、HTML(Hyper Text Markup Language)やXHTML(Extensible HyperText Markup Language)などの構造化文書ファイルで記憶されてもよい。
レシピ管理サーバ1が実行する各種処理について説明する。
[4−1.全体の流れ]
先ずは、レシピ管理サーバ1とユーザ端末3の間で行われる各種処理や情報の送受信について、図4を参照して説明する。
具体的には、レシピ管理サーバ1が提供する各種サービスを受けるために、ユーザがユーザ端末3を用いてログイン操作を行い、レシピを検索して利用する例を説明する。
これにより、例えば、レシピ管理サーバ1から受信したレシピサイトのログイン画面情報(ウェブページデータ)に応じたウェブページがユーザ端末3上に表示される。
尚、レシピ管理サーバ1はこのとき、ログイン画面をユーザ端末3上に表示させたことを履歴(即ちログイン画面の閲覧履歴)として記憶してもよい。
具体的には、レシピ管理サーバ1は、ユーザ端末3上で入力されたユーザIDとパスワードをユーザDB50に記憶された情報と比較して当該ユーザのログイン可否を判定し、当該ログイン可否情報を履歴情報として履歴DB53に記憶し、当該ログイン可否情報を認証結果としてユーザ端末3へ通知する。尚、認証結果をユーザ端末3へ送信すると共に、レシピサイトのトップページのウェブページデータを送信してもよい。これにより、ユーザ認証がなされると共に、ユーザ端末3上にレシピサイトのトップページが表示される。
この処理では、例えば、ユーザによって指定されたレシピ名の一部や使用食材などが、検索結果を抽出するための情報として、レシピ管理サーバ1へ伝達される。
更に、レシピ管理サーバ1はステップS206において、検索履歴を履歴DB53に記憶する検索履歴記憶処理を実行する。
尚、検索クエリが検索された回数を示す被検索回数を管理している場合には、検索履歴記憶処理を実行する際に被検索回数を加算する処理を行う。
レシピ選択処理は、ユーザが選択したレシピが何れのレシピであるかを選択レシピ情報としてレシピ管理サーバ1に通知する。尚、この処理は、選択したレシピの詳細ページのウェブページデータを要求する処理である。
この処理によって、ユーザ端末3上に、ユーザが選択したレシピに関する詳細情報が提示される。詳細情報とは、例えば、レシピに使用する食材情報や調理手順、調理器具情報などの情報である。他にも、選択されたレシピに対して投稿された作成レポートの情報などを含んでいてもよい。
例えば、図4に示すように、レシピの利用が推定される操作として、レシピの詳細情報を印刷するための操作を行った場合、ユーザ端末3はステップS105において、印刷操作に関する情報をレシピ管理サーバ1に送信する処理を実行する。
印刷操作に関する情報とは、操作を行ったユーザのユーザIDと印刷対象とされたレシピのレシピIDなどである。
尚、レシピの利用が推定される操作の他の例としては、例えば、作成レポートの投稿操作や、お気に入りレシピに登録する操作や、レシピ詳細情報の所定時間(例えば、調理時間の8割の時間)以上の閲覧操作などを挙げることができる。
何れの操作も、ユーザによるレシピの利用(即ち実際に調理を行ったこと)が推測される操作である。
検索クエリに基づいて検索されるレシピの数を増加(充実)させるためにレシピ管理サーバ1が実行する処理について説明する。
尚、この処理は、ユーザ端末3から検索クエリを受信したタイミングで行ってもよいが、処理に要する時間(即ちレシピ管理サーバ1の処理能力)によっては検索結果を迅速にユーザに提示することができなくなるため、好ましくない場合がある。
ここでは、バッチ処理によって定期的に処理を実行する例を説明する。こうすることにより、レシピサイトの利用が少ない時間帯などに処理を行うことが可能となる。
レシピ管理サーバ1は、ステップS301において、複合検索条件を取得する処理を実行する。複合検索条件取得処理について、図6に示す。
図6に示すように、先ずレシピ管理サーバ1はステップS401において、所定期間内に検索に用いられた検索クエリ(複合検索条件とは限らない検索クエリ)を履歴DB53から一つ取得する処理を実行する。
取得した一つの検索クエリに対して、レシピ管理サーバ1はステップS402において、複合検索条件であるか否か(即ち二つ以上のキーワードを含んでいるか否か)を判定する処理を実行する。
検索クエリの取得が終了した場合、即ち、所定期間内に検索された全ての検索クエリに対して複合検索条件であるか否かを判定する処理を実行した場合、レシピ管理サーバ1は図6に示す一連の処理を終了する。
一方、検索クエリの取得が終了していない場合、レシピ管理サーバ1は再びステップS401の処理を実行する。
一または複数の複合検索条件(ステップS403において処理対象の複合検索条件として選択されたもの)を取得したレシピ管理サーバ1は、ステップS302において、複合検索条件毎の検索情報として被検索回数を取得する処理を実行する。被検索回数とは、前述のように、複合検索条件が検索クエリとして用いられた回数を表す。
被検索回数は、履歴DB53から取得する。また、検索DB52に検索クエリ毎の被検索回数が記憶されている場合には、検索DB52から取得してもよい。
被検索回数は、検索リクエスト毎に加算されるものであってもよい。即ち、同じユーザが同一の検索クエリを用いた複数回の検索を行った場合であっても被検索回数に全て加算される。
また、被検索回数は、単位時間(単位期間)毎のユニークユーザ(重複しないユーザであり、換言すれば、異なるユーザIDが付与されたユーザ)による検索リクエストの回数(同一ユーザによる検索リクエストは1回としてカウントした回数)であってもよい。即ち、単位時間を仮に1週間とした場合、同一ユーザが一週間に同一検索クエリを用いた検索を5回行ったとしても、被検索回数としては1回分として加算される。そして、同一検索クエリを用いた一週間に1回の検索を三週間に亘り行った場合、被検索回数としては3回分として加算される。
更に、被検索回数は、ユーザ毎に最大1回まで加算されることとしてもよい。即ち、同一ユーザによる同一検索クエリを用いた検索は、何度行っても1回とされる。換言すれば、被検索回数が100回のレシピは、これまでに100人の異なるユーザが閲覧したこととなる。
検索結果数は、検索クエリに応じて抽出されるレシピの数である。即ち、ステップS303では、複合検索条件毎に検索処理を行い、抽出された検索レシピ数を取得する処理を実行する。
尚、検索DB52に検索クエリ毎の検索結果数が記憶されている場合は、検索DB52から取得してもよい。
続いて、レシピ管理サーバ1はステップS304において、複合検索条件毎の被検索回数と検索結果数に応じて支援対象検索条件を決定する処理を実行する。
支援対象検索条件決定処理については、図7を参照して説明する。
続いて、レシピ管理サーバ1はステップS502において、選択した複合検索条件の被検索回数に対する検索結果数が所定割合(閾値)以下であるか否かを判定する。
そして、被検索回数に対する検索結果数が所定割合以下であると判定した場合、レシピ管理サーバ1はステップS503において、選択された複合検索条件を支援対象検索条件として決定する。
即ち、当該複合検索条件が検索クエリとして利用される回数に対して検索結果数が少ない複合検索条件ほど優先して支援対象検索条件として決定される。
未処理の複合検索条件が残っている場合、レシピ管理サーバ1はステップS501の処理を再度実行する。
一方、処理対象とされた複合検索条件全てに対して各処理を実行した場合、レシピ管理サーバ1は図7に示す一連の処理を終了する。
所定割合を複合検索条件に応じて変更する場合、例えば、相対的に被検索回数が多い複合検索条件ほど所定割合の閾値を緩和する(小さくする)。また、複合検索条件に対応する被検索回数に対する被利用回数の割合が少ないほど所定割合の閾値を厳しく(大きく)する構成にしてもよい。
被利用回数とは、前述した印刷操作などの利用操作の対象となった回数である。被検索回数に対する被利用回数が少ないということは、即ち検索クエリを用いた検索がされているにも関わらず抽出された何れのレシピも利用しなかったということであり、検索結果として抽出されたレシピの中にユーザを満足させるものがなかった可能性がある。そのため、そのような検索クエリ(即ち複合検索条件)が支援対象とされやすくするために、所定割合の閾値を大きくする。
単位期間あたりの被検索回数の変化が大きい複合検索条件は注目されている可能性が高い。そのような複合検索条件によって抽出されるレシピ数は多い方が好ましいため、支援対象とされやすくするために所定割合の閾値を厳しく(大きく)する。
一方、単位期間あたりの被検索回数の変化が小さい複合検索条件はユーザを満足させるレシピが抽出されないことがユーザに認知され始めていることが考えられる。ユーザがレシピサイトを利用しなくなる状況を回避するために、そのような複合検索条件によって抽出されるレシピ数を増加させることが望ましく、当該複合検索条件が支援対象とされやすいように所定割合の閾値を厳しく(大きく)する。
支援対象となる複合検索条件を決定したレシピ管理サーバ1は、ステップS305において、アレンジ対象とするレシピを決定する処理を実行する。
この処理でアレンジ対象として決定されたレシピは、現時点では先の複合検索条件を用いた検索によって抽出されないレシピであり、且つ、今後の検索によって新たに抽出対象とすることが望まれるレシピである。
アレンジ対象レシピ決定処理について、具体的に図8を参照して説明する。
具体的に説明すると、例えば、支援対象の複合検索条件としてキーワードK1,K2,K3を含む検索クエリ「K1,K2,K3」が選択されたとする。そして、キーワードK1を検索クエリとして抽出されたレシピ数(検索結果数)が100、キーワードK2を検索クエリとして抽出されたレシピ数が200、キーワードK3を検索クエリとして抽出されたレシピ数が300とする。
このとき、検索結果数の多いキーワードとしてはK3となる。
即ち、ステップS601の処理では、この3種類の第一部分検索条件から一つを選択する処理となる。以降では、この具体例を用いて説明する。
そして、レシピ管理サーバ1はステップS603において、検索結果として抽出された300個のレシピから、第一部分検索条件「K3」を満たし「K1」及び「K2」を満たさないレシピを選択して、アレンジ対象レシピとする処理を実行する。
これにより、現時点において複合検索条件を用いた検索によって抽出されてしまうレシピを除き、複合検索条件の第一部分検索条件のみを満たすレシピがアレンジ対象レシピとして抽出される。
即ち、レシピ管理サーバ1はステップS604において、検索結果数の多いキーワードを含む第一部分検索条件のうち未処理のものがあるか否かを判定し、未処理のものがある場合はステップS601の処理を再度実行する。
未処理のものが無い場合、レシピ管理サーバ1は図8に示す一連の処理を終了する。
アレンジ対象レシピを決定したレシピ管理サーバ1は、続くステップS306において、支援依頼の対象とする(即ち支援を依頼する)ユーザを特定する処理を実行する。
この処理は、アレンジ対象レシピに基づくアレンジレシピの投稿が期待されるユーザを特定する処理である。
具体的な処理例について、図9を参照して説明する。
対応する第二部分検索条件とは、選択したアレンジ対象レシピR3001の抽出に用いられた第一部分検索条件が支援対象検索条件「K1,K2,K3」の第一部分検索条件「K3」であることから、「K1,K2」が第二部分検索条件となる。
例えば、キーワード「K1,K2」(一例としてK1=「トマト」、K2=「チーズ」とする)を用いたレシピとしては、「トマトたっぷりのアラビアータ」や「トマトとチーズのオムレツ」などのように、「トマト」と「チーズ」を元から含んでいる(使用食材とされている)レシピがある。
第二部分検索条件としての「トマト」と「チーズ」をアレンジ食材として使用した投稿ユーザは、当該アレンジ食材を用いて既存の料理をアレンジする能力に長けている可能性が高い。
未処理のアレンジ対象レシピがある場合、レシピ管理サーバ1は再びステップS701乃至S704の各処理を実行する。
未処理のアレンジ対象レシピが無くなった場合、レシピ管理サーバ1は図9に示す一連の処理を終了する。
例えば、「トマト」と「チーズ」を使用するレシピ(アレンジレシピではない)を投稿した投稿ユーザを検索してもよい。そのようなユーザが「トマト」と「チーズ」を利用するレシピを得意とする可能性もあるためである。
レシピ管理サーバ1はステップS801において、アレンジ対象レシピのうちの一つを選択し、ステップS802において対応する第二部分検索条件を取得する。これらの処理は、図9のステップS701及びS702の処理と同様である。
この処理では、「トマト」と「チーズ」を用いたアレンジレシピの投稿ユーザだけでなく、「トマト」と「チーズ」を用いるレシピの投稿ユーザも抽出される。
そして、レシピ管理サーバ1は、続くステップS804において検索された投稿ユーザを支援依頼対象ユーザとして特定する処理を実行し、ステップS805において未処理のアレンジ対象レシピがあるかどうかを判定する処理を実行する。
ステップS804及びS805の処理は、図9のステップS704及びS705の処理と同様である。
具体的に図11を参照して説明する。
レシピ管理サーバ1はステップS901乃至S903の各処理を実行する。この処理は、図10のステップS801乃至S803の各処理と同様の処理である。
第二部分検索条件としてのキーワードを含むレシピの投稿ユーザを検索したレシピ管理サーバ1は、ステップS904において、当該投稿ユーザの中から実績のある投稿ユーザを支援依頼対象ユーザとして特定する処理を実行する。
そのような投稿ユーザに対してレシピのアレンジを依頼することは、質の高いレシピ投稿やアレンジレシピの投稿がなされる可能性を高めることができ、延いてはレシピサイトの利用人数の増加を図ることができる。
図9乃至図11のいずれかの処理を実行することにより、支援依頼対象ユーザを特定したレシピ管理サーバ1は、ステップS307において、アレンジ依頼情報を通知する処理を実行する。
アレンジ依頼情報には、アレンジ対象レシピの情報と、第二部分検索条件と、支援依頼対象ユーザが少なくとも含まれる。例えば、支援依頼対象ユーザに対して、「「トマト」と「チーズ」を使ってレシピR3001、R3002・・・をアレンジしませんか?」というメッセージを送る。
アレンジ依頼情報の通知は、前述のように、電子メールやレシピサイト上への表示などによって行われる。
これにより、レシピ情報の充実かが図られる。
先のバッチ処理の第1例では、複合検索条件取得処理の例として、所定期間内に検索された複合検索条件を、処理対象の複合検索条件として選択する例を示した。
ここでは、複合検索条件取得処理の第2例について、図12を参照して説明する。
続いて、レシピ管理サーバ1はステップS1002において、取得した検索クエリが複合検索条件であるか否かを判定した後、ステップS1003で被検索回数を取得し、ステップS1004で被利用回数を取得する処理を実行する。
これらの処理により、複合検索条件についての被検索回数と被利用回数を取得する。
即ち、被検索回数に対する被利用回数の割合が所定閾値以上である場合には、ユーザが検索結果にある程度満足していることが推測されるため、処理対象の複合検索条件からは外すことを意図している。
一方、検索クエリの取得が終了したと判定した場合、レシピ管理サーバ1は図12に示す一連の処理を終了する。
先のバッチ処理の第1例における支援対象検索条件決定処理では、被検索回数に対する検索結果数が所定割合以下である複合検索条件を支援対象検索条件とする例を示した。
支援対象検索条件決定処理の第2例では、類似する複合検索条件の中で被検索回数に対する検索結果数の割合が相対的に少ない複合検索条件を支援対象検索条件とする。
先ず、レシピ管理サーバ1はステップS1101において、処理対象とされた複合検索条件を選択する。この処理は、図7のステップS501の処理と同様の処理である。
続いて、レシピ管理サーバ1はステップS1102において、類似した複合検索条件を取得する。
類似した複合検索条件については、後述する。
相対的に少ないと判定した場合、レシピ管理サーバ1はステップS1104において、支援対象検索条件として決定する。換言すれば、処理対象とされた複合検索条件の被検索回数に対する検索結果数の割合が絶対的に少なかったとしても、類似する複合検索条件が同様の水準であれば、必ずしも処理対象とされた複合検索条件を支援対象とする必要がない。
ステップS1104,S1105の各処理は、図7におけるステップS503,S504の各処理と同様の処理である。
1)複合検索条件に含まれる少なくとも一部のキーワードが一致する条件
2)複合検索条件に含まれるキーワードのうち、使用頻度の高い少なくとも一部のキーワードが一致する条件
3)複合検索条件に含まれる少なくとも一部のキーワードが一致し、且つ複合検索条件に含まれるキーワード数が一致する条件
同一のキーワード「K1」を含む検索クエリは、同程度の検索結果数となることが望ましい。「トマト」と「ジャガイモ」を含むレシピとして抽出されたレシピ数が、「トマト」と「ニンジン」を含むレシピとして抽出されたレシピ数に対して著しく少ない場合、検索を行ったユーザに提示するレシピは「トマト」と「ジャガイモ」の双方を食材として使用するレシピが提示される可能性が低くなる。このような状況は好ましくない。
但し、一部のキーワードの選び方によっては、検索結果数が同程度とならないことがやむを得ない場合もある。
尚、検索クエリ「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から取得してもよいし、検索履歴から抽出(即ち検索結果数が多い組み合わせを抽出)してもよい。
また、レシピタイトルに含まれやすいキーワードを一部のキーワードとしてもよい。
一般的に、AND検索を行うためのキーワード数を増やすと、検索結果数は減る。そして、絞り込み検索を行うためにはキーワードを追加した検索を行うが、元々の検索結果数が少ないと、絞り込み検索によって抽出される検索結果数は更に少なくなり、ユーザの要望を満たすものとはなり難い。
そこで、同数のキーワードを含み且つ検索キーワードが一部同一である複合検索条件においては、同程度の検索結果数を提示することが望ましいという観点から、そのような検索条件を類似する複合検索条件とする。
アレンジ対象レシピ決定処理の第2例について、図14を参照して説明する。
そして、レシピ管理サーバ1はステップS1203において、抽出されたレシピの中から、当該第一部分検索条件がレシピの中で優先度の高いキーワード(例えば主要食材)とされたレシピを選択し、アレンジ対象レシピとして選択する。
レシピR1は、キーワード「K1」が少量使用されているレシピであるため、レシピR1におけるキーワード「K1」は低重要度とされる。
レシピR2は、キーワード「K1」がレシピタイトルに含まれているため(例えば「K1を使った○○サラダ」)、レシピR2においてキーワード「K2」は高重要度とされる。
レシピR3は、キーワード「K1」が最も使用量の多い使用食材とされているため、レシピR3におけるキーワード「K1」は高重要度とされる。
未処理のものが無い場合、レシピ管理サーバ1は図14に示す一連の処理を終了する。
バッチ処理の第2例について、図15を参照して説明する。
尚、図5に示したバッチ処理の第1例と同様の処理については、同一の符号を付し、適宜説明を省略する。
そして、レシピ管理サーバ1はステップS304において支援対象とする複合検索条件を決定し、ステップS305においてアレンジ対象レシピを決定する。
ステップS301乃至S305の各処理は、図5に示す各処理と同様である。
アレンジ対象レシピ数が多いということは、アレンジレシピが投稿される確率(或いは投稿数)が向上するということである。
即ち、効果の高い複合検索条件の優先度を高くすることによって、効率よくレシピの充実化を図ることができる。
例えば、ある支援依頼対象ユーザに対して複数のアレンジ依頼を行う場合、優先度の高い方のアレンジ対象レシピに関する依頼のみを行ってもよい。また、優先度の高い方のアレンジ対象レシピに関する依頼から順に通知してもよい。
レシピの充実化をより促進するために、アレンジレシピの投稿者に対して特典を付与する場合の処理について、図16を参照して説明する。
尚、図16に示す処理は、新しいアレンジレシピが投稿されるたびに実行(例えばバッチ処理によって実行)してもよいし、一定期間毎に定期的に実行してもよい。
尚、バッチ処理などによって実行する場合は、前回処理から今回処理までの間に投稿されたアレンジレシピが新規に投稿されたレシピとされる。
そして、当該投稿ユーザに対してアレンジ情報通知依頼を行ったか否か(即ち図5におけるステップS307の処理を投稿ユーザに対して行ったか否か)を判定する処理を実行する。
ここで、投稿ユーザに対してアレンジ情報通知依頼を行っていたとしても、投稿されたアレンジレシピと関連が無い場合(即ち依頼と異なるアレンジレシピが投稿された場合)は、依頼なしと判定する。
換言すれば、アレンジ情報通知依頼によってアレンジレシピが投稿されたとみなす事ができる場合のみ、依頼ありと判定する。
未処理の新規投稿アレンジレシピがある場合、レシピ管理サーバ1は再度ステップS1301の処理を実行する。一方、未処理の新規投稿アレンジレシピがない場合、レシピ管理サーバ1は図16に示す一連の処理を終了する。
被検索回数の変化量が大きい複合検索条件について投稿されたアレンジレシピであった場合、大きな特典(或いは優良な特典)を付与することが考えられる。
また、被検索回数に対する被利用回数が少ない(即ちユーザが検索結果に満足していないと推測される)複合検索条件について投稿されたアレンジレシピであった場合、大きな特典(或いは優良な特典)を付与することが考えられる。
更にまた、アレンジ情報通知依頼からアレンジレシピ投稿までの経過時間が短い(即ち対応が早い)ほど、大きな特典(或いは優良な特典)を付与することが考えられる。
更にまた、投稿されたアレンジレシピと他のアレンジレシピとの類似度が低い(即ち投稿されたアレンジレシピがユニークな)ほど、大きな特典(或いは優良な特典)を付与することが考えられる。
上記したレシピ管理サーバ1は、レシピに関する情報を検索するために用いられる少なくとも2以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得部1bと、取得した複合検索条件に対応する検索結果数を取得する検索部1cと、取得した被検索回数と複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定部1dと、支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定部1eと、支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理部1fと、特定された支援依頼対象ユーザに対して決定されたアレンジ対象レシピと第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御部1gと、を備えている。
これにより、ユーザの潜在的なニーズが汲み取られて、相対的に不足しているレシピの特定がなされる。
従って、ユーザの要望に沿ったレシピ情報の拡充を支援することが可能となる。
また、検索レシピ数が少ないと、ユーザが使い勝手の悪さを感じてしまい、レシピ検索サービスを利用しなくなってしまう虞がある。上記構成によれば、これらの問題を解決し、ユーザが離れてしまうことを防止することができる。
尚、検索の被検索回数と複合検索条件の検索結果数(検索結果として抽出されたレシピ数)に基づいて支援対象検索条件を決定するため、支援対象検索条件を適切に絞ることが可能となる。そのため、全ての複合検索条件を支援対象検索条件とするよりも、アレンジ対象レシピの決定などの各処理に要するレシピ管理サーバ1の処理負担が軽減される。即ち、必要な箇所(ユーザの潜在的なニーズのある箇所)に対して効率のよいレシピ情報の追加が促進される。
これにより、被検索回数に対して複合検索条件の検索結果数の割合が所定値以下となる複合検索条件を支援対象検索条件とすることが可能となる。即ち、このような複合検索条件は、ニーズがあるにも関わらず十分に満足できる検索結果が提示できていない可能性がある。このような複合検索条件が支援対象とされることにより、検索結果として抽出されるレシピ情報が拡充されて、ユーザの要望を満足させることができる。
これにより、検索結果に含まれる各レシピの中に、ユーザの要望を満たすレシピのの多寡に応じて閾値が特定される。
従って、ユーザの要望を満たすレシピが少ない複合検索条件が支援対象とされやすくなり、ユーザの要望を満足させる可能性を高めることができる。
被検索回数に対して検索結果としてのレシピの被利用回数が少ない場合、検索操作を行ったにも関わらず、所望のレシピが提示されずにレシピ検索を諦めた(若しくは他の検索条件を設定したレシピ検索を再度行った)ユーザが多い可能性が高い。
このような場合に、高い閾値を特定することは、当該複合検索条件が支援対象検索条件として選択される可能性が高くなる。
従って、ユーザの実際の行動に基づいたニーズを推測したレシピ情報の拡充が行われる可能性を高めることができる。
例えば、被検索回数の変化が短時間に増大した場合などは、ニーズが急激に増加していることが推測される。このような状態において高い閾値を特定することは、当該複合検索条件が支援対象検索条件として選択される可能性が高くなる。
即ち、ニーズの変動に即したレシピ情報の拡充が行われやすくする環境を提供することができる。
これにより、例えば、類似する複合検索条件が複数あった場合に、相対的にレシピ数の足りていない複合検索条件が支援対象検索条件とされる。
従って、他の類似する複合検索条件よりもレシピ拡充の必要性が高いと推測される複合検索条件に対して、検索結果の充実化(即ち複合検索条件の検索結果数の増加)を図ることが可能となる。
これにより、アレンジ対象レシピの候補となるレシピが多く検索される複合検索条件の優先度が高くなる。換言すれば、アレンジ対象レシピが多くなる。
アレンジ対象レシピが多いということは、アレンジ対象レシピを改良したアレンジレシピの提案数も増加する可能性が高いため、レシピ情報の充実化を効率よく図ることができる。
これにより、優先度が相対的に高いキーワード(例えば主要食材)が既に含まれるレシピがアレンジ対象レシピとして抽出される。即ち、アレンジ対象食材は主要食材以外の食材とされ、主要食材はレシピ通りに調理される。従って、主要食材を奇抜にアレンジしたアレンジレシピなどが投稿される可能性を低減させることができる。
即ち、万人に受け入れられる汎用性の高いレシピによってレシピ情報の充実化を図ることができる。
このとき、食材A,食材Bを第一部分検索条件とした場合に、食材C,食材Dの双方を第二部分検索条件とするだけでなく、そのうちの一部(即ち食材Cなど)を第二部分検索条件とすることによっても、レシピ検索結果の充実化を図ることができる。
即ち、食材A,食材Bを利用するアレンジ対象レシピに食材Cを加えたアレンジレシピの投稿がなされれば、食材A,食材B,食材C,食材Dを検索条件として抽出されるレシピの充実化が図られる。
そのため、第二部分検索条件としては、「支援対象検索条件」の中から第一部分検索条件を除いた全ての条件でなくてもよい。
以上、本発明の情報処理装置の実施の形態としてのレシピ管理サーバ1を説明してきたが、実施の形態のプログラムは、レシピ管理サーバ1における各処理を情報処理装置(CPU等)に実行させるプログラムである。
また、前記取得した複合検索条件に対応する検索結果数を取得する検索機能を情報処理装置に実行させる。
更に前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定機能を情報処理装置に実行させる。
更にまた、前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定機能を情報処理装置に実行させる。
そして、前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理機能を情報処理装置に実行させる。
加えて、前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御機能を情報処理装置に実行させる。
即ちこのプログラムは、レシピ管理サーバ1に対して図4のステップS201乃至S210の各処理、図5乃至図16の各処理を実行させるプログラムである。
そしてこのようなプログラムはコンピュータ装置などの機器に内蔵されている記憶媒体としてのHDDや、CPUを有するマイクロコンピュータ内のROMなどに予め記録しておくことができる。或いはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的或いは永続的に格納(記録)しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータなどにインストールする他、ダウンロードサイトから、LAN、インターネットなどのネットワークを介してダウンロードすることもできる。
Claims (10)
- レシピに関する情報を検索するために用いられる少なくとも2以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得部と、
前記取得した複合検索条件に対応する検索結果数を取得する検索部と、
前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定部と、
前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定部と、
前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理部と、
前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御部と、を備えた
情報処理装置。 - 前記支援対象決定部は、前記複合検索条件の前記被検索回数に対する検索結果数の割合と、前記複合検索条件の検索結果数に応じて特定された閾値と、に基づいて複合検索条件を支援対象とするか否かを決定する
請求項1に記載の情報処理装置。 - 前記支援対象決定部は、前記複合検索条件の前記被検索回数に対する検索結果数の割合と、前記複合検索条件に対応する検索結果に含まれる各レシピの被利用回数に応じて特定された閾値と、に基づいて複合検索条件を支援対象とするか否かを決定する
請求項1に記載の情報処理装置。 - 前記支援対象決定部は、前記複合検索条件に対応する検索結果に含まれる各レシピの被利用回数が前記被検索回数に対して少ないほど高い閾値を特定する
請求項2または請求項3に記載の情報処理装置。 - 前記支援対象決定部は、前記複合検索条件の所定期間における被検索回数の変化が大きいほど高い閾値を特定する
請求項2または請求項3に記載の情報処理装置。 - 前記支援対象決定部は、前記複合検索条件に対応する前記被検索回数に対する検索結果数の割合が他の前記複合検索条件に対応する検索回数に対する検索結果数の割合に対して相対的に少ない複合検索条件を前記支援対象として決定する
請求項1乃至請求項5の何れか一項に記載の情報処理装置。 - 前記支援対象決定部は、前記前記第一部分検索条件に対応する検索結果数が多い複合検索条件ほど高い優先度を付与し、
前記送信制御部は、相対的に高い優先度を付与された前記複合検索条件に基づく依頼情報が優先的に送信されるように制御する
請求項1乃至請求項6の何れか一項に記載の情報処理装置。 - 前記アレンジ対象決定部は、前記支援対象として決定された複合検索条件に含まれるキーワード毎に優先度を特定し、当該特定された優先度が相対的に高いキーワードを含む前記第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定する
請求項1乃至請求項7の何れか一項に記載の情報処理装置。 - レシピに関する情報を検索するために用いられる少なくとも2以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得ステップと、
前記取得した複合検索条件に対応する検索結果数を取得する検索ステップと、
前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定ステップと、
前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定ステップと、
前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理ステップと、
前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御ステップと、を
情報処理装置が実行する情報処理方法。 - レシピに関する情報を検索するために用いられる少なくとも2以上のキーワードを含む複合検索条件と該複合検索条件が検索された被検索回数を取得する検索情報取得機能と、
前記取得した複合検索条件に対応する検索結果数を取得する検索機能と、
前記取得した被検索回数と前記複合検索条件に対応する検索結果数に基づいて支援対象である複合検索条件を決定する支援対象決定機能と、
前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち一部のキーワードのみで構成される第一部分検索条件に対応するレシピをアレンジ対象レシピとして決定するアレンジ対象決定機能と、
前記支援対象であると決定された複合検索条件に含まれる2以上のキーワードのうち前記一部のキーワードに含まれない残りのキーワードで構成された第二部分検索条件に対応するレシピを特定し、当該特定されたレシピを投稿したユーザを支援依頼対象ユーザとして特定するユーザ管理機能と、
前記特定された支援依頼対象ユーザに対して前記決定されたアレンジ対象レシピと前記第二部分検索条件に基づくレシピの生成を依頼するための依頼情報の送信を制御する送信制御機能と、を
情報処理装置に実行させるプログラム。
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)
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 | 楽天株式会社 | 情報処理装置、情報処理方法、情報処理プログラム及び記録媒体 |
-
2016
- 2016-04-07 WO PCT/JP2016/061396 patent/WO2017175356A1/ja active Application Filing
- 2016-04-07 JP JP2017554622A patent/JP6275932B1/ja active Active
Patent Citations (3)
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 |
---|---|
JPWO2017175356A1 (ja) | 2018-04-12 |
WO2017175356A1 (ja) | 2017-10-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) | 店舗情報検索システム | |
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 | |
WO2014160236A1 (en) | Determining activities relevant to users and/or groups of individuals |
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 |