JP6641486B2 - 情報処理装置、情報処理方法、プログラム、記憶媒体 - Google Patents

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）、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。

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

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

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

入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、レシピ管理サーバ１、ユーザ端末３、ユーザＤＢ５０、レシピＤＢ５１、検索ＤＢ５２、ウェブページＤＢ５３のそれぞれにおいて後述する情報処理や通信が実行される。

尚、レシピ管理サーバ１、ユーザ端末３、ユーザＤＢ５０、レシピＤＢ５１、検索ＤＢ５２、ウェブページＤＢ５３を構成するそれぞれの情報処理装置は、図２のようなコンピュータ装置が単一で構成されることに限らず、システム化された複数のコンピュータ装置によって構成されてもよい。複数のコンピュータ装置は、ＬＡＮなどによりシステム化されていてもよいし、インターネットなどを利用したＶＰＮ（Virtual Private Network）などにより通信可能な状態で遠隔地に配置されたものでもよい。複数の情報処理装置には、クラウドコンピューティングサービスによって利用可能なサーバ群（クラウド）としての情報処理装置が含まれてもよい。

尚、レシピ管理サーバ１、ユーザ端末３、ユーザＤＢ５０、レシピＤＢ５１、検索ＤＢ５２、ウェブページＤＢ５３は、それぞれが上記の全ての構成（ＣＰＵ１０１など）を含んでいる必要は無い。例えば、ユーザＤＢ５０が入力装置１０６や出力装置１０７やメディアドライブ１１０などを備えていなくてもよい。

＜３．機能構成＞

レシピ管理サーバ１は、図３に示すように、レシピ管理部１ａ、ユーザ管理部１ｂ、レシピ取得部１ｃ、提示優先度設定部１ｄ、関心度算出部１ｅ、共通点抽出部１ｆ、送信制御部１ｇを備えている。

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

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

ユーザ管理部１ｂは、レシピ管理サーバ１が提供する各種のサービスを利用するユーザの情報を管理するために、種々の処理を行う。
例えば、ユーザを一意に特定可能なユーザＩＤに対して、氏名、年齢、性別、連絡先（電話番号や電子メールアドレス等）を紐付け、ユーザＤＢ５０へ記憶することにより管理を行う。また、ユーザＤＢ５０からユーザ情報を取得する処理を行う。

レシピ取得部１ｃは、検索クエリに応じた検索処理を行い、検索結果として条件適合レシピを抽出する。そして、レシピ取得部１ｃは、抽出した条件適合レシピから一部を取得する処理を実行する。具体的には、抽出した条件適合レシピから所定数（前述のように例えば２０件）のレシピを取得する。条件適合レシピから所定数のレシピを取得する処理を「第１取得処理」と記載する。第１取得処理は、ユーザ端末３でレシピの閲覧が進み、待機コンテンツの件数が追加取得閾値未満になるたびに実行される。

また、レシピ取得部１ｃは、提示したレシピに対するユーザの挙動からユーザの関心がありそうなレシピを関心レシピとして取得する処理を実行する。具体的には、ユーザの挙動から推測したレシピごとの関心度合いに基づいてレシピを検索し、抽出された検索結果を関心レシピとして取得する。以降の説明では、ユーザの挙動から推測した関心に基づいてレシピを取得する処理を「第２取得処理」と記載する。
尚、関心レシピは請求項にいう「関心コンテンツ」の一例である。
また、レシピ取得部１ｃは、請求項にいう「コンテンツ取得部」の具体例である。

提示優先度設定部１ｄは、ユーザに提示するコンテンツとしてのレシピごとに提示優先度を設定する。
条件適合レシピの提示優先度は、ユーザの指定した検索クエリに対する合致度合いやレシピの人気度合いなどによって算出される。
また、関心レシピの提示優先度は、後述する関心度やレシピの人気度合いなどによって算出される。

関心度算出部１ｅは、レシピに対するユーザの挙動に基づいてユーザの関心度合いを数値化した関心度を算出する。
関心度は、一つのレシピごとに付与してもよいし、レシピが属する料理カテゴリごとに付与してもよい。以下の説明においては、双方の例について説明する。

共通点抽出部１ｆは、レシピ間の共通点を抽出する処理を行う。具体的には、所定値以上の関心度が付与されたレシピ間の共通点を抽出する。即ち、ユーザが関心を持ちそうなレシピを検索するための前処理として、ユーザが関心を持ったレシピに共通する要素を抽出する。要素は、例えばキーワードとして抽出される。

送信制御部１ｇは、抽出したレシピ或いは取得したレシピをユーザ端末３に送信する処理を行う。
例えば、ユーザに提示するレシピ情報が含まれて生成されたウェブページデータをユーザ端末３へ送信する。また、該ウェブページデータ上に表示するレシピの追加取得要求をレシピ管理サーバ１が受信した場合には、各種処理を実行した後、追加レシピの情報をユーザ端末３へ送信する。
尚、レシピ情報の送信（或いはレシピ情報を含んだウェブページデータの送信）は、各レシピ情報に付与された提示優先度情報に基づいて行われる。

ウェブページデータとしては、ウェブページのＵＲＬ（Uniform Resource Locator）情報と各ウェブページ上に配置されるオブジェクト（画像やテキストやバナーなどの部品）の配置情報が記憶される。配置情報とは、ウェブページ上における各オブジェクトの配置態様（位置や大きさ、色等）が記載された情報である。

ユーザ端末３上に表示されるウェブページデータの一例を図４に示す。
図４は、ユーザの指定した検索クエリに応じたレシピ（条件適合レシピ）が検索結果として提示される検索結果提示ページの例である。
検索結果提示ページは、ユーザ端末３上で動作するウェブブラウザ４を用いて閲覧可能である。

ウェブブラウザ４には、ウェブページ表示欄５が設けられ、その上部や側部には各種の操作子（ボタンや入力欄）６，６，６・・・が設けられている。
検索結果提示ページが表示されるウェブページ表示欄５には、検索を行うための検索クエリ入力欄７や検索要求をレシピ管理サーバ１へ送信するための検索ボタン８と共に、検索結果としてのレシピ群が表示される。尚、ウェブページ表示欄５にレシピが一つずつ表示されるようにウェブブラウザ４が構成されていてもよい。
一つのレシピ情報は、例えば、レシピの完成図を示す画像情報や、材料及び調理手順等を示すテキスト情報などによって構成される。

ウェブページ表示欄５に表示されるレシピは、既に表示が済んだものとそうでないものがある。以降の説明においては、説明の便宜上、表示が済んだもの（即ちユーザが閲覧したと推定されるもの）を閲覧レシピ９と記載し、まだ表示が済んでいないものを待機レシピ１０と記載する。但し、閲覧レシピ９と待機レシピ１０は、説明上区別するが、実際にはステータスが変わるなどの変化はない。
図４には、検索結果として提示されるレシピのうち閲覧可能なレシピが閲覧レシピ９，９，９，・・・として表示されている。ユーザは未閲覧のレシピを閲覧するためにレシピ情報を上方へ移動させるスクロール操作（以降、送り操作と記載）を行う。また、既に閲覧してウェブページ表示欄５の上方へ消えていったレシピを再び閲覧するためにはレシピ情報を下方へ移動させるスクロール操作（以降、戻り操作と記載）を行う。
また、図５Ａ，図５Ｂに示すように、閲覧レシピ９，９，９・・・の下方にはユーザが未だ閲覧していないレシピが待機レシピ１０，１０，１０・・・として配置されている。尚、実際に閲覧レシピ９の下方に待機レシピ１０が配置されているわけではないが、見えない状態で仮想的に配置されているように捉えることができるため、このような表現を用いている。以降の説明においても同様である。

図４に示すようにウェブページ表示欄５に表示されている４件のレシピのうち、３件は全ての情報が閲覧可能な状態であり、閲覧レシピ９，９，９とされる。また、残る１件はレシピ情報の一部が閲覧可能な状態とされている。
レシピ情報の一部のみが閲覧可能なレシピに関しては、一部が閲覧可能であるため、図５Ａに示すように閲覧レシピ９とされていてもよいし、全ての情報が閲覧可能ではないため、図５Ｂに示すように待機レシピ１０とされていてもよい。レシピ情報の一部のみが閲覧可能なレシピが待機レシピ１０とされている場合には、レシピ情報の全てをユーザが閲覧可能となった時点で待機レシピ１０から閲覧レシピ９へと変わる。
また、ユーザの戻り操作によって一度閲覧したレシピ情報（即ち閲覧レシピ９）がウェブページ表示欄５の下方へ移動した場合には、位置的には待機レシピ１０の位置であっても既に閲覧済みのレシピであるため、閲覧レシピ９となる。

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

尚、レシピ管理サーバ１としての各機能は、情報処理装置におけるＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し以下説明する全部又は一部の各構成の処理をハードウェアにより実現してもよい。

また各機能をソフトウェアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。一つのプログラムにより複数の機能の処理が実行されてもよいし、一つの機能が複数のプログラムモジュールの連携で実現されてもよい。
また、各機能は複数の情報処理装置に分散されていてもよい。更に、機能の一つが複数の情報処理装置によって実現されていてもよい。

＜４．ＤＢ＞

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

［４−１．ユーザＤＢ］
ユーザＤＢ５０にはレシピ管理サーバ１が提供するサービスを受けるユーザの情報が記憶される。例えば、一人のユーザを特定可能な一つのユーザＩＤ（Identification）に対して、ログインパスワード、氏名、年齢、性別、メールアドレスなどの個人的な情報が紐付けられて記憶される。

ユーザＤＢ５０には、他にも、ユーザごとの嗜好情報が記憶されてもよい。嗜好情報は、ユーザの挙動に応じてレシピ管理サーバ１が判定したユーザの好みの食材（嗜好食材）や嫌いな食材（非嗜好食材）である。嗜好情報は、ユーザがレシピ検索を行った際に利用される。
以下で説明する各例においては、レシピに対するユーザの関心（興味）を推測するためにユーザ情報が用いられる。興味を推測するためのユーザ情報としては、ウェブページにおける閲覧速度などであり、これらの情報はユーザＤＢ５０に記憶される。
また、前述した追加取得閾値がユーザごとの閲覧速度に応じた数値とされる場合には、該閾値もユーザＤＢ５０に記憶される。

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

更に、各レシピＩＤには、該レシピの調理手順の概要を示す手順概要コンテンツの情報が紐付けられる。

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

［４−３．検索ＤＢ］
検索ＤＢ５２は、検索クエリと対応した検索結果が記憶されるＤＢである。具体的には、「カレー」や「ハンバーグ」などの料理名や「きのこ」や「トマト」などの食材名などの検索クエリに応じて、複数のレシピが検索結果として紐付けられて記憶される。
ユーザの検索操作に応じてその都度検索処理を実行せずに済むように、予め定期的に検索クエリを用いた検索処理を実行しておき、その結果抽出された検索結果が検索キーワードに紐付けられて検索ＤＢ５２に記憶される。

［４−４．ウェブページＤＢ］
ウェブページＤＢ５３には、レシピ管理サーバ１がユーザに提供する各種ウェブページのデータが記憶される。具体的には、レシピ検索ページや特集ページや検索結果提示ページやレシピ詳細ページやユーザページなどのウェブページデータである。
尚、ウェブページＤＢ５３に記憶される情報は、例えば、ＨＴＭＬ（Hyper Text Markup Language）やＸＨＴＭＬ（Extensible HyperText Markup Language）などの構造化文書ファイルで記憶されてもよい。

＜５．処理の流れ＞

［５−１．全体の流れ］
先ず、図６を参照し、ユーザ端末３とレシピ管理サーバ１の間で行われる各種処理の流れについての一例を説明する。
ユーザがユーザ端末３を用いてログイン画面を表示させる操作を行ったことに応じ、ユーザ端末３はステップＳ１０１において、ログイン画面情報（即ちログイン画面を表示させるためのウェブページデータ）の要求処理を実行する。

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

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

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

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

ログインに成功したユーザは、続いて自身が探しているレシピを検索するための検索クエリを入力する。これに応じ、ユーザ端末３はステップＳ１０３において、検索クエリ送信処理を実行する。

対するレシピ管理サーバ１は、ステップＳ２０４において、検索クエリを用いた検索処理を実行する。これにより、ユーザが指定した検索クエリに応じたレシピ群が検索結果として抽出される。一例として、検索結果として１０００件のレシピが検索された例を挙げて説明する。以降の処理では、適宜具体例を挙げて説明していく。

続いて、レシピ管理サーバ１はステップＳ２０５において、検索結果として抽出された１０００件のレシピに対して提示優先度を設定する処理を行う。提示優先度は、ユーザに対して提示することが相応しいレシピほど高い数値が付与される。例えば、ユーザが指定した検索クエリを考慮することが考えられる。具体的には、ユーザが検索クエリの一部として「鶏肉」を指定した場合、「鶏肉」を非メイン食材として使用するレシピよりもメイン食材として使用するレシピの方に高い提示優先度を設定してもよい。
また、ユーザの嗜好食材に基づくことが考えられる。ユーザの嗜好食材をより多く使用食材として使用しているレシピほど高い提示優先度を設定してもよい。尚、嗜好食材や非嗜好食材の情報は、ユーザＤＢ５０に記憶されている。
他にも、季節に応じた旬の食材を使用しているレシピほど高い提示優先度を設定してもよいし、他のユーザからの閲覧数や作成レポート投稿数が多いレシピほど高い提示優先度を設定してもよいし、直近の所定時間（所定期間）における閲覧数が多いレシピほど高い提示優先度を設定してもよい。もちろん、これらの要素を複合的に考慮して提示優先度が設定されてもよいし、他の要素によって提示優先度が設定されてもよい。ここでは、あくまで一例を述べたに過ぎない。

提示優先度をレシピごとに設定したレシピ管理サーバ１は、続くステップＳ２０６において、抽出された１０００件のレシピから提示優先度の高い順に所定数（例えば２０件）のレシピを取得し、検索結果としてユーザ端末３へ送信する処理を実行する。
これにより、ユーザ端末３に２０件のレシピ情報が送信されると共に、ウェブブラウザ４上に少なくともその中の一部（例えば３件）のレシピが提示（表示）される。換言すれば、ユーザ端末３が受信した２０件のレシピうち、３件が閲覧レシピ９とされ、１７件が待機レシピ１０とされる。尚、ユーザがスクロール操作を行い、レシピを次々と閲覧することにより、閲覧レシピ９の件数は増加すると共に待機レシピ１０の件数は減少していく。

続いて、ユーザが閲覧レシピ９のうちのいずれかのレシピに対して関心（興味）を示す操作を行ったことに応じて、ユーザ端末３はステップＳ１０４において、関心情報を送信する処理を実行する。
レシピ管理サーバ１へ送信される関心情報は、対象となるレシピを特定する情報（例えばレシピＩＤ）と操作種別（即ち関心を示す操作としてどのような操作を行ったか）を特定する情報が少なくとも含まれる。

ここで、関心を示す操作（以降、関心操作）の具体例を幾つか示す。
（１）レシピ詳細ページ閲覧操作
（２）お気に入り登録操作
（３）印刷操作
（４）ハイライト操作
（５）クリック操作
（６）所定閲覧時間経過

ユーザ端末３上に提示される検索結果としてのレシピは、図４や図５に示すようにレシピの概要が提示されている。従って、ユーザが関心を持ったレシピを実際に利用（調理）しようとした場合には、調理手順を閲覧するためにレシピ詳細ページを閲覧する場合が多い。
そこで、レシピ詳細ページを閲覧する操作は関心操作とされる。

また、後で再度閲覧しようと考えたレシピに対しては、再度検索操作を行わなくても済むようにお気に入りレシピとして登録する可能性が高い。
そこで、お気に入り登録操作に関しても関心操作とされる。

そして、レシピ詳細ページの印刷操作は、実際にレシピを利用しようと考えている場合に行われる可能性が非常に高い。印刷操作に関しても関心操作である。

更に、レシピに関するテキスト情報などをハイライトする操作（テキストの一部分を選択する操作）は、当該レシピの情報を閲覧している状態で行われる可能性が高い。テキストを閲覧することはレシピに関心を持っている状態であるといえるため、ハイライト操作は関心操作である。

ウェブブラウザ４のウェブページ表示欄５のうち、レシピ情報が表示された部分（図４の閲覧レシピ９の領域に対するクリック操作も同様に、当該レシピの情報を閲覧している状態で行われる可能性が高い。従って、クリック操作も関心操作である。
尚、ユーザのクリック操作によってページ遷移が発生するような場合だけでなく、ユーザ端末３が何も処理を行わない（即ちクリックしても何も起こらない）場合であっても、関心操作とされる。

また、レシピを閲覧している時間が所定時間（所定閲覧時間）を経過した場合には、当該レシピに対する関心が高いといえる。所定閲覧時間経過は、マウスなどの入力装置を用いた操作をユーザが行わなくても判定される場合があるが、便宜上関心操作と定義する。
尚、ユーザが閲覧レシピ９を表示させたままでユーザ端末３から離れる場合もある。この場合には、ユーザ端末３の画面に同じ閲覧レシピ９が表示され続けたまま所定閲覧時間経過してしまい、当該レシピに関心があると判定されてしまう可能性もある。これを避けるためには、ユーザがマウスやキーボードを操作しているか（例えばカーソルは動いているかなど）を判定することにより、ユーザがユーザ端末３に表示された閲覧レシピ９を閲覧できる状態にあるか否かを判定してもよい。また、ユーザ端末３上でウェブブラウザ４を含む複数のソフトウェアプログラム（但し画面上に何かしらの表示をしているもの）が動作している場合には、閲覧レシピ９が表示されたウェブブラウザ４がアクティブな状態にあるか否かによって関心操作の有無を判定してもよい。
ユーザが実際にレシピを閲覧していたかを判定することにより、適切な閲覧時間を把握することができ、延いては、関心の有無や度合いを適切に推定することができる。

上記に示す各関心操作がユーザによってなされるたびに関心情報がレシピ管理サーバ１へ送信される。
例えば、ユーザがレシピ詳細ページを閲覧して印刷操作を行った場合、レシピ詳細ページの閲覧に応じて（１）の関心操作に基づく関心情報がレシピ管理サーバ１へ送信され、続く印刷操作に応じて（３）の関心操作に基づく関心情報がレシピ管理サーバ１へ送信される。

図６の説明に戻る。
何れのレシピに対してどのような関心操作を行ったかを示す関心情報を受信したレシピ管理サーバ１は、ステップＳ２０７において、関心度を算出する処理を実行する。
関心度算出処理は、閲覧レシピ９に対する関心度を算出する処理であり、関心情報を受信するたびに実行される。具体的な例は後述する。

関心度を算出した後、レシピ管理サーバ１はステップＳ２０８において、第２取得処理を実行する。第２取得処理は前述したように、ユーザの関心が推測される関心レシピを取得する処理である。具体例は後述する。

続いて、レシピ管理サーバ１はステップＳ２０９において、取得した関心レシピに提示優先度を設定する処理を実行する。ここで設定される関心レシピの提示優先度は、既にユーザ端末３に送信済みであるレシピのうちの一部よりも高い値が設定される。
そして、レシピ管理サーバ１はステップＳ２１０において、関心レシピと提示優先度を紐付けた情報をユーザ端末３へ送信する送信制御処理を実行する。
具体的に図７を参照して説明する。
図７に示す状態は、条件適合レシピ１１，１１，・・・の一部と関心レシピ１２，１２，・・・が待機レシピ１０，１０，・・・としてウェブブラウザ４のウェブページ表示欄５の下方に配置されている。そして、待機レシピ１０，１０，・・・の中では、条件適合レシピ１１，１１，・・・よりも関心レシピ１２，１２，・・・が上方に配置されている。換言すれば、第２取得処理によって取得された関心レシピ１１，１１，・・・は、待機レシピ１０，１０，・・・の中で最も高い提示優先度を設定されている。
従って、ユーザがスクロール操作（送り操作）を行うと関心レシピ１２としての待機レシピ１０が先ず閲覧可能となる。

図６の説明に再び戻る。
ユーザは、ユーザ端末３に送信されてくる条件適合レシピや関心レシピなどを閲覧する過程で、待機レシピ１０を閲覧するためにスクロール操作を行うことがある。
ユーザ端末３はユーザのスクロール操作に応じ、ステップＳ１０５においてスクロール操作を受け付ける。例えば送り操作となるスクロール操作を受け付けることにより、ウェブブラウザ４のウェブページ表示欄５に一部の待機レシピ１０が閲覧レシピ９として提示される。
待機レシピ１０の閲覧が進行すると（即ち待機レシピ１０が閲覧レシピ９へと変わっていくと）、待機レシピ１０の件数が減少する。そして、待機レシピ１０の件数が追加取得閾値（例えば５件）未満となったことに応じて、ユーザ端末３はレシピ追加要求をレシピ管理サーバ１へ送信する処理を実行する。

レシピ追加要求を受信したレシピ管理サーバ１は、ステップＳ２１１において、未送信の条件適合レシピの有無を確認する。この例では、１０００件の条件適合レシピのうち２０件のみを送った状態であるため、９８０件の未送信レシピが存在する。
そこで、レシピ管理サーバ１はステップＳ２１２において、９８０件の未送信である条件適合レシピのうちの２０件を提示優先度に基づいて取得する。
続いて、レシピ管理サーバ１はステップＳ２１３において、取得した２０件の条件適合レシピをユーザ端末３へ送信する処理を実行する。
これにより、ユーザ端末３において、ユーザの閲覧を待機している待機レシピ１０が２０件追加される。

図６に示す一連の処理の流れはあくまで一例であり、必ずしも同じ処理の流れになるとは限らない。

［５−２．レシピ管理サーバの処理］
上記の全体の流れを実現するためにレシピ管理サーバ１が実行する処理の流れについて、図８を参照して一例を説明する。

レシピ管理サーバ１は、ユーザ端末３から各種の情報を受信して、それぞれに対応する処理を実行する。そのため、レシピ管理サーバ１は各種の情報を受信したか否かを監視する監視ループ処理を実行する。
具体的には、図８に示すようにステップＳ３０１，Ｓ３１１，Ｓ３２１，Ｓ３３１の各処理を繰り返し実行することにより、ログイン情報の受信有無、検索クエリの受信有無、レシピ追加要求の受信有無、関心情報の受信有無を監視する。そして、いずれかの情報を受信したと判定した場合には、それぞれ対応する処理を実行する。

例えば、ステップＳ３０１においてログイン情報の受信有無を確認したレシピ管理サーバ１は、受信したと判定した場合に限りステップＳ３０２，Ｓ３０３の処理を実行する。
即ち、レシピ管理サーバ１は、ステップＳ３０２において、ユーザが入力したログイン情報とユーザＤＢ５０に記憶された認証情報と照合する処理を実行し、続くステップＳ３０３において、認証結果をユーザ端末３へ通知する処理を実行する。
ステップＳ３０３の処理の後、レシピ管理サーバ１は再び監視ループ処理に戻る。

また、ステップＳ３１１において検索クエリを受信したと判定したレシピ管理サーバ１は、ステップＳ３１２で検索クエリに応じた検索処理を実行することにより検索結果としての条件適合レシピを取得し、続くステップＳ３１３において条件適合レシピごとの提示優先度を設定する処理を行う。
条件適合レシピの中には、ユーザの興味を引くレシピも含まれる一方、ユーザの興味を然程引かないレシピも含まれる。レシピ管理サーバ１は、ユーザの興味を引くレシピほど提示優先度を高く設定することが望ましい。このために、レシピ管理サーバ１はユーザ特有の情報（例えば嗜好情報や所持している調理器具情報など）を用いて提示優先度を算出してもよい。

そして、レシピ管理サーバ１はステップＳ３１４において、条件適合レシピのうちの一部（先の例では２０件）をユーザ端末３へ送信する処理を実行する。
ステップＳ３１４の処理の後、レシピ管理サーバ１は再び監視ループ処理に戻る。
尚、条件適合レシピが少ない場合は、検索結果として抽出された条件適合レシピをステップＳ３１４の処理で全て送信することも考えられる。

更に、ステップＳ３２１においてレシピ追加要求を受信したレシピ管理サーバ１は、ステップＳ３２２において、未送信の条件適合レシピがあるか否かを判定する処理を実行する。この処理は、前述のように、ユーザ端末３において待機レシピが追加取得閾値未満となったことに応じて実行される。
未送信の条件適合レシピがある場合、レシピ管理サーバ１はステップＳ３２３において未送信の条件適合レシピから所定数のレシピを取得する第１取得処理を実行する。但し、未送信の条件適合レシピが所定数に満たない場合は未送信の条件適合レシピを全て取得する。
続いて、レシピ管理サーバ１はステップＳ３２４において、所定数（或いは残りの全ての）条件適合レシピをユーザ端末３へ送信する処理を実行する。
ステップＳ３２４の処理の後、レシピ管理サーバ１は再び監視ループ処理に戻る。

また、ステップＳ３３１において関心情報を受信したレシピ管理サーバ１は、ステップＳ３３２において、関心度を算出する処理を実行する。
関心度算出処理について、二つの例を図９及び図１０に基づいて説明する。

〜５−２−１．関心度算出処理の第１例〜
関心度算出処理の第１例（図９）では、レシピ管理サーバ１は、ステップＳ４０１において関心度算出の対象となるレシピ（対象レシピ）を特定し、ステップＳ４０２において関心操作の操作種別を特定する処理を実行する。
対象レシピの情報及び関心操作の操作種別の情報は、例えば、図６のステップＳ１０４においてユーザ端末３から送信される。また、操作種別は、先に述べたように、印刷操作やハイライト操作などである。

続いて、レシピ管理サーバ１はステップＳ４０３において、関心度を算出し、対象レシピに付与する処理を実行する。関心度の付与については、算出した関心度をそのまま付与してもよいし、これまで付与された関心度に今回算出した関心度を加算したものを付与し直してもよい。
尚、ユーザが行った関心操作の種別に応じて算出される関心度が変わるようにしてもよい。例えば、レシピに対する強い関心が推測される前述の（１）のような操作（レシピ詳細ページ閲覧操作）や（２）のような操作（お気に入り登録操作）などは関心度が高く算出されるようにしてもよい。また、前述の（５）のような操作（クリック操作）などは関心度が低く算出されるようにしてもよい。

〜５−２−２．関心度算出処理の第２例〜
次に、関心度算出処理の第２例（図１０）を説明する。
レシピ管理サーバ１は、ステップＳ５０１において対象レシピを特定し、続くステップＳ５０２において対象レシピが属する料理カテゴリを対象カテゴリとして特定する。
ステップＳ５０１の処理は先のステップＳ４０１の処理と同様の処理である。

ステップＳ５０２では、一番大きな料理カテゴリを対象カテゴリとしてもよいし、一番小さな料理カテゴリを対象カテゴリとしてもよい。例えば、料理カテゴリ「カレー」には、その下位カテゴリとして料理カテゴリ「インドカレー」や料理カテゴリ「和風カレー」が属している。そして料理カテゴリ「インドカレー」の下には、料理カテゴリ「キーマカレー」や料理カテゴリ「マトンカレー」が属している。そして「我が家のキーマカレー」というレシピは、料理カテゴリ「カレー」に属するレシピであると共に、料理カテゴリ「インドカレー」に属するレシピでもあり、更に料理カテゴリ「キーマカレー」に属するレシピでもある。
従って、対象カテゴリは料理カテゴリ「カレー」であってもよいし、料理カテゴリ「インドカレー」であってもよいし、料理カテゴリ「キーマカレー」であってもよい。
尚、後述する関心レシピの取得の際に、関心レシピの数が多すぎる場合には、下位の料理カテゴリを対象カテゴリとすることが望ましく、逆に関心レシピの数が少なすぎる場合には、上位の料理カテゴリを対象カテゴリとすることが望ましい。

対象カテゴリを特定したレシピ管理サーバ１は、ステップＳ５０３において、関心操作の操作種別を特定する（ステップＳ４０２に同じ）。続いて、レシピ管理サーバ１はステップＳ５０４において、関心度を算出して対象カテゴリに付与する処理を行う。

図８の説明に戻る。
関心度を算出したレシピ管理サーバ１は、続くステップＳ３３３において、第２取得処理を実行する。
ここで、第２取得処理について三つの例を説明する。

〜５−２−３．第２取得処理の第１例〜
第２取得処理の第１例（図１１）では、関心度が所定値以上となったレシピに基づいた第２取得処理（即ち関心レシピを取得する処理）を実行する。
レシピ管理サーバ１はステップＳ６０１において、直前に行った関心度算出処理（ステップＳ３３２）で設定された関心度が新たに所定値以上となったレシピがあるか否かを判定する。

直前のステップＳ３３２において関心度が新たに所定値以上となったレシピがある場合、レシピ管理サーバ１はステップＳ６０２において、該レシピ（即ち新たに関心度が所定値以上となったレシピ）に基づく関心レシピを取得する処理を実行する。
例えば、該レシピを閲覧したユーザが閲覧しがちな他のレシピやお気に入りに登録しているレシピなどを検索して取得する。
また、該レシピに含まれる食材や調理方法や調理器具などのキーワードが共通するレシピを検索して取得する。

第２取得処理によって取得されるレシピは、ユーザの検索クエリに基づいて既に抽出済みの条件適合レシピであっても構わない。
例えば、図８のステップＳ３１２において取得した条件適合レシピには、レシピＡ及びレシピＢが含まれており、レシピＡの提示優先度は１番目、レシピＢの提示優先度が９００番目であった場合、レシピＢがユーザに提示されるのはかなり後の方であり、ユーザが実際に閲覧する可能性は低い。
しかし、図１１のステップＳ６０２においてレシピＢが関心レシピとして取得された場合、レシピＢは該ユーザが関心を持っている可能性が高いレシピとみなす事ができる。そして、レシピＢは後述する処理で９００番目よりも高い提示優先度が設定されて、ユーザに提示される。

〜５−２−４．第２取得処理の第２例〜
次に、第２取得処理の第２例（図１２）を説明する。
第２取得処理の第２例では、関心の高いレシピの共通点に基づいて関心レシピを取得する。
先ず、レシピ管理サーバ１はステップＳ７０１において、これまでに関心度が所定値以上となったレシピを取得する。尚、この処理は、ユーザが検索クエリを最後に指定した後に設定された関心度に基づいて行う処理であり、ユーザが再度別の検索クエリを指定した場合にはレシピに設定された関心度はリセットされる（即ち関心度が所定値以上のレシピは皆無となる）。
但し、検索クエリの異なる複数の検索操作が直近の時間帯に寄っている場合は、関心度をリセットしなくてもよい。

続いてレシピ管理サーバ１は、ステップＳ７０２において、レシピ間の共通点を抽出する処理を実行する。レシピ間の共通点は、例えば使用食材や使用器具や調理方法などであり、例えばレシピ情報をテキスト解析することによって得ることができる。勿論、これらの情報がキーワードとして予めレシピに紐付けられて管理されていてもよい。キーワードとして予め紐付管理する場合には、テキスト情報を解析する必要が無くなるため、処理負担の軽減を図ることができる。

次いで、レシピ管理サーバ１はステップＳ７０３において、共通点に基づくキーワードを用いて検索処理を行い、関心レシピを取得する。

〜５−２−５．第２取得処理の第３例〜
次に、第２取得処理の第３例（図１３）を説明する。
レシピ管理サーバ１はステップＳ８０１において、同一セッションにおいて算出された関心度の最大値を取得する。
ここで、同一セッションについて説明する。
ユーザがユーザ端末３を用いてレシピ管理サーバ１のサービスを利用するときに、継続的に（或いは所定時間以上の無操作時間を経ずに）何らかの操作を行っている間は同一セッションとされる。例えば、レシピを検索した後、一日後に再度レシピの検索を行う場合は、それぞれ別のセッションとされる。
或いは、一度の検索操作に応じて提示された複数のレシピを閲覧する操作を同一セッションとしてもよい。この場合には、異なるキーワードを用いてレシピ検索を行った場合に別のセッションとされる。このときの同一セッションは、一連の閲覧セッションと換言できる。

同一セッションにおける関心度の最大値を取得したレシピ管理サーバ１は、続くステップＳ８０２において、直前に行った関心度算出処理（ステップＳ３３２）で付与した関心度が最大値を更新したか否かを判定する。
関心度の最大値が更新された場合、レシピ管理サーバ１はステップＳ８０３において、更新した関心度の最大値を記憶する処理を実行する。
そして、レシピ管理サーバ１はステップＳ８０４において、更新された関心度が付与されたレシピに応じた関心レシピを取得する。
関心レシピは、第２取得処理の第１例のように最大値とされた関心度が付与されたレシピの情報に含まれる食材や調理方法や調理器具などのキーワードに基づいて取得してもよいし、第２取得処理の第２例のように複数のレシピ（例えば関心度の大きなレシピのうち上位三つなど）から抽出した共通点に基づいて取得してもよい。

再び図８の説明に戻る。
ユーザの関心操作に基づいて算出した関心度を算出し、当該関心度に基づいて関心レシピを取得したレシピ管理サーバ１は、続くステップＳ３３４において、関心レシピの優先度を設定する提示優先度設定処理を実行する。
関心レシピに対する提示優先度設定処理においては、例えば、先の図７で説明したように、待機レシピ１０，１０，・・・の中で関心レシピ１２，１２，・・・が上方に配置されるように提示優先度を設定する。
提示優先度を設定したレシピ管理サーバ１は、続くステップＳ３３５において、送信制御処理を実行する。この処理では、関心レシピの情報と付与された提示優先度の情報がユーザ端末３へ送信される。ユーザ端末３上では、提示優先度に基づいた表示がなされる。
ステップＳ３３５の処理の後、レシピ管理サーバ１は再び監視ループ処理に戻る。

尚、図８に示した監視ループ処理としてのステップＳ３０１，Ｓ３１１，Ｓ３２１，Ｓ３３１の各処理はあくまで一例であり、これ以外にもウェブページデータ要求の受信有無や、ユーザ情報の変更要求の有無などを確認する処理が監視ループ処理に含まれてもよい。

ここで、関心レシピに対する提示優先度設定処理について、図７で説明した以外の他の二つの例を説明する。

〜５−２−６．関心レシピに対する提示優先度設定処理の第１例〜
関心レシピに対する提示優先度設定処理の第１例（図１４，図１５）では、関心レシピ１２が表示中のレシピの間に表示されるように提示優先度を設定する。
図１４には、ステップＳ３３５（図８）の送信制御処理が行われる前の状態を示している。即ち、提示優先度が１２１，９２，８４，８１，７４，６７，６６，・・・とされた条件適合レシピ１１，１１，・・・が閲覧レシピ９または待機レシピ１０として提示優先度順に配置されている。尚、提示優先度の数値が高いレシピの方が優先的にユーザに提示されるものとする。

そして、図１５には、ステップＳ３３５（図８）の送信制御処理が行われた後の状態を示している。即ち、関心レシピ１２，１２，・・・に対して提示優先度＝９１，９０，８９，８８，・・・が設定されて、提示優先度＝９２とされた条件適合レシピ１１と提示優先度＝８４とされた条件適合レシピ１１の間に挿入されるように配置されている。
換言すれば、関心レシピ１２，１２，・・・の提示優先度は、ウェブページ表示欄５に表示されている提示優先度＝９２のレシピと提示優先度＝８４のレシピの間に配置されるように、提示優先度が設定される（図８のステップＳ３３４）。

〜５−２−７．関心レシピに対する提示優先度設定処理の第２例〜
次に、関心レシピに対する提示優先度設定処理の第２例（図１４，図１６）を説明する。
関心レシピに対する提示優先度設定処理の第２例では、既にユーザ端末３に送信済みのレシピについても新たな提示優先度が設定される。
ステップＳ３３５（図８）の送信制御処理が行われる前の状態（図１４）についての説明は割愛する。
ステップＳ３３５（図８）の送信制御処理が行われた後の状態を図１６に示す。図１６に示した提示優先度が８１→９０と更新された条件適合レシピ１１のように、既にユーザ端末３に送信済みのレシピについても新たな提示優先度が設定される。
そして、提示優先度が８１→９０と更新された条件適合レシピ１１は、提示優先度が８４とされた条件適合レシピ１１よりも上方に配置し直されている。即ち、既にユーザ端末３に送信済みのレシピに関しても新たな提示優先度に応じた配置換えが行われ、新たな提示優先度に基づいた順序でユーザに閲覧される。

尚、ステップＳ３３５（図８）の関心レシピに対する提示優先度設定処理においては、既にユーザが閲覧した閲覧レシピ９，９，・・・も含めて提示優先度を再設定してもよい。
また、その場合には、新たな提示優先度に基づいて閲覧レシピ９，９，・・・を配置し直してもよいし、し直さなくてもよい。
新たな提示優先度に基づいて閲覧レシピ９，９，・・・を配置し直した場合には、既にウェブページ表示欄５上に表示された閲覧レシピ９，９，・・・が再配置によって変わる場合がある。これにより、ユーザにとって有意義なレシピを目立たせ、ユーザの目を引くことがでる。
また、新たな提示優先度に基づいて閲覧レシピ９，９，・・・を配置し直さない場合には、ユーザが既に閲覧済みの閲覧レシピ９を戻り操作によって再度閲覧する場合に、探している閲覧レシピ９が再配置によってどこに配置されたか分からなくなることがない。

［５−３．閲覧時間に基づく関心情報の第１例］
ユーザ端末３は、上述したように、ユーザの操作に応じて各種の関心情報を送信する。ユーザ端末３が行う関心情報の送信処理は、例えば、レシピ管理サーバ１がユーザ端末３に送信するウェブページデータに付されたプログラムによって実行される。換言すれば、ユーザ端末３が各種の条件に基づいて関心情報を送信するようにウェブページデータにプログラムが付されている。
また、ユーザ端末３上で専用のアプリケーションソフトウェアが実行される場合には、アプリケーションソフトウェアにユーザ端末３が実行する各種処理内容を規定したプログラムが組み込まれていてもよい。

ここでは、閲覧時間に基づく関心情報（先述した（６）を満たしたときに送信される関心情報）がどのような条件を満たしたときに送信されるかについての例を説明する。
一つ目の例では、ウェブページ表示欄５内に表示されたレシピの数が複数である状態の閲覧時間は、関心情報を送信するか否かの判定に用いない。
具体的には、図７や図１４乃至図１６の各図に示したような状態でユーザの閲覧時間がどれだけ増加しても、何れのレシピを閲覧しているか不明確であるため、閲覧時間に基づく関心情報は送信されない。
一方、図１７に示すように、ウェブページ表示欄５内に一つのレシピのみ表示されている状態においては、閲覧時間を計測して必要に応じて閲覧時間に基づく関心情報を送信する。

［５−４．閲覧時間に基づく関心情報の第２例］
閲覧時間に基づく関心情報がどのような条件を満たしたときに送信されるかについての二つ目の例を説明する。
二つ目の例では、ウェブページデータに付されたプログラムによってユーザ端末３が閲覧時間に基づく関心情報を送信する場合に、レシピの情報量（分量）に基づく。
図１８は、ウェブページデータに付されたプログラムによってユーザ端末３に実行させる処理の流れを示したものである。
ユーザ端末３は、閲覧対象のレシピを特定する処理をステップＳ９０１で実行する。
続いて、ユーザ端末３はステップＳ９０２において、レシピの情報量を特定する。レシピの情報量とは、例えば、レシピ情報に含まれるテキスト情報の文字数や画像数などであり、閲覧にどの程度の時間が掛かるかを推定するために用いる情報である。

続いて、ユーザ端末３はステップＳ９０３において、所定閲覧時間を設定する処理を行う。ここで設定する所定閲覧時間は、関心情報を送信するか否かを判定するための閾値である。即ち、先の処理で取得したレシピの情報量の多寡に応じて所定閲覧時間を設定する。
所定閲覧時間を設定した後、レシピ管理サーバ１はステップＳ９０４において、対象レシピに対する閲覧時間が所定閲覧時間を超えたか否かを判定する。
所定閲覧時間を超えていた（経過していた）場合、ユーザ端末３はステップＳ９０５において、閲覧時間に基づく関心情報を送信する処理を実行する。

一方、所定閲覧時間を超えていないと判定した場合、ユーザ端末３はステップＳ９０６で閲覧対象に変化がないか（即ち、ユーザが他のレシピを閲覧し出したか）を判定する。
ユーザが他のレシピを閲覧し出した（閲覧対象レシピが変わった）と判定した場合、ユーザ端末３は再びステップＳ９０１の処理を実行する。
また、閲覧対象レシピが同じである場合、ユーザ端末３は継続的にステップＳ９０４及びＳ９０６の処理を実行する。

尚、ここでは、ユーザ端末３が図１８に示す各処理を実行する例を挙げたが、レシピ管理サーバ１が処理の一部を代わりに実行してもよい。
例えば、ユーザ端末３は、ステップＳ９０１の処理を実行した後、ステップＳ９０５の処理を定期的に実行してもよい。
一方、関心情報を受信したレシピ管理サーバ１は、ユーザ端末３から受信した閲覧対象を特定する情報から、ステップＳ９０２及びＳ９０３の処理を実行することにより閲覧対象レシピの情報量特定及び所定閲覧時間の設定を行い、続くステップＳ９０４の所定閲覧時間が経過したか否かの判定処理を実行する。
そして、所定閲覧時間が経過していた場合、レシピ管理サーバ１は、図８のステップＳ３３２乃至Ｓ３３５の処理を実行することにより、関心レシピをユーザ端末３へ送信する。

＜６．変形例＞

［６−１．第１の変形例］
レシピ管理サーバ１が実行する図８の一連の処理の変形例について、図１９を参照して説明する。
本変形例では、ユーザごとの閲覧速度に応じて第１取得処理を行う例を説明する。
レシピ管理サーバ１は、継続的に実行する監視ループ処理において、ログイン情報の受信有無と、検索クエリの受信有無と、待機レシピ数情報の受信有無と、関心情報の受信有無を確認する。

尚、図１９に示すように、ステップＳ３０１乃至Ｓ３０３、ステップＳ３１１乃至Ｓ３１４、ステップＳ３３１乃至Ｓ３３５の各処理については、図８に示す各処理と同様の処理であるため、説明を省略する。
従って、ここでは主に、ステップＳ３２１’において、レシピ管理サーバ１が待機レシピ数を受信した場合の処理について説明する。
ユーザ端末３は、待機レシピ数の情報をレシピ管理サーバ１へ送信するように構成されている。待機レシピ数情報は、待機レシピ数が変化した場合に送信するようにしてもよいし、一定時間経過ごと（例えば１秒ごと）に送信するようにしてもよい。

ステップＳ３２１’において待機レシピ数情報を受信したレシピ管理サーバ１は、ステップＳ３２５において、ユーザに応じた追加取得閾値を取得する。追加取得閾値の情報は、例えばユーザＤＢ５０に記憶されている。
追加取得閾値は、ユーザの閲覧速度に応じて設定される。即ち、閲覧速度が速いユーザに対しては追加取得閾値を高く設定し、閲覧速度の遅いユーザに対しては追加取得閾値を低く設定することが望ましい。

続いて、レシピ管理サーバ１はステップＳ２５６において、ユーザ端末３から受信した待機レシピ数が追加取得閾値未満であるか否かを判定する。追加取得閾値未満ではない場合、レシピ管理サーバ１は第１取得処理を実行せずに監視ループ処理に戻る。
一方、追加取得閾値未満である場合、レシピ管理サーバ１はステップＳ３２２で未送信の条件適合レシピがあるかどうかを確認した後、ステップＳ３２３の第１取得処理を実行する。
ステップＳ３２２乃至Ｓ３２４の各処理は、図８で説明した各処理と同様の処理であるため、詳述を省く。

［６−２．第２の変形例］
上述した各例では、図８及び図１９の各処理をレシピ管理サーバ１が実行する例を示したが、一部の処理をユーザ端末３が実行するように記述されたプログラムを付したウェブページデータをユーザ端末３に実行することによって該一部の処理をユーザ端末３が実行するようにしてもよい。

具体的に、図８を参照して説明する。
例えば、ステップＳ３３２の関心度算出処理をユーザ端末３が実行してもよい。
この場合には、レシピ管理サーバ１に対して算出した関心度情報が送信される。そして、レシピ管理サーバ１は監視ループ処理において、関心度情報の受信有無を確認する。

また、図１９に示す各処理についても説明する。
例えば、ステップＳ３２５の追加取得閾値取得処理及びステップＳ３２６の待機レシピ数が追加取得閾値未満であるか否かの判定処理をユーザ端末３が実行してもよい。
この場合には、レシピ管理サーバ１に対してレシピ追加要求が送信される。そして、レシピ管理サーバ１は監視ループ処理において、レシピ追加要求の受信有無を確認する。

また、ユーザ端末３が携帯電話などの端末であって、該端末にレシピサイトが提供する各種サービスを利用するための専用アプリケーションソフトウェアがインストールされている場合には、ウェブページデータに付したプログラムを用いずに、レシピ管理サーバ１が実行する各処理の一部を専用アプリケーションソフトウェアが実行することも考えられる。
具体的には、上記と同様に、図８のステップＳ３３２の処理や図１９のステップＳ３２５，Ｓ３２６の処理などを専用アプリケーションソフトウェアが実行してもよい。

［６−３．第３の変形例］
上記した各例では、第２取得処理で取得した関心レシピに対して提示優先度を設定してユーザ端末３に送信する例を説明したが、提示優先度を設定した関心レシピから更に一部を選択して送信してもよい。
例えば、多数（例えば１００件など）の関心レシピが取得された場合、全てをユーザ端末３へ送信（即ちユーザに提示）してしまうと、ユーザが指定した検索クエリを含むレシピ情報（条件適合レシピ）がウェブページ表示欄５に中々表示されなくなってしまう虞がある。

そこで、関心レシピの中から、提示優先度の高い所定数のレシピをユーザ端末３へ送信してもよい。
また、関心レシピの中から、提示優先度が一定値以上のレシピをユーザ端末３へ送信してもよい。
更に、関心度の高さによってユーザ端末３へ送信するレシピ数を変化させてもよい。例えば、関心度として０〜１００の数値を取り得る場合に、８０以上の関心度が付された対象レシピに基づく関心レシピの送信件数を１０件とし、５０以上の関心度が付された対象レシピに基づく関心レシピの送信件数を５件としてもよい。

［６−４．第４の変形例］
関心レシピは、条件適合レシピの中から取得してもよい。即ち、ユーザが指定した検索クエリに応じて取得された条件適合レシピの中から、ユーザ操作に応じて関心が高いと推測されるレシピを関心レシピとして取得してもよい。
これにより、ユーザが指定した検索クエリを含むレシピのみが提示されると共に、ユーザの操作に応じて条件適合レシピの提示優先度が都度変更されて提示される。即ちレシピ管理サーバ１は、関心情報の受信に応じて、条件適合レシピとして既に抽出済みの各レシピの提示優先度を再設定する。

＜７．まとめ＞

各実施の形態や変形例で説明したように、所定条件（例えば検索クエリ）に基づいて複数のレシピ（コンテンツ）を条件適合レシピ（条件適合コンテンツ）として取得するコンテンツ取得部としての、レシピ取得部１ｃと、条件適合レシピに提示優先度を設定する提示優先度設定部１ｄと、レシピの閲覧に応じてユーザの関心を数値化した関心度を算出する関心度算出部１ｅと、を備え、レシピ取得部１ｃは、条件適合レシピを追加で取得する第１取得処理と、関心度に応じて条件適合レシピとは異なる関心レシピ（関心コンテンツ）を取得する第２取得処理と、を実行し、提示優先度設定部１ｄは、条件適合レシピの少なくとも一部よりも関心レシピが早く提示されるように提示優先度を再設定する。
第１取得処理は、例えば、送信されたレシピのうち未閲覧のレシピである待機レシピの数が閾値（追加取得閾値）未満となったことに応じて実行される。
複数のレシピを順に提示する場合、レシピの提示優先度を一度決定してしまった後は、該決定済みの提示優先度を変えることはあまりない。従って、取得済みのレシピを提示優先度に従って提示していく過程でユーザの興味（関心）が変わった場合やユーザの興味（関心）を新たに把握できた場合であっても、決定済みの提示優先度を最適化（再設定）することはなく、ユーザにとって利便性の高いレシピ提示がなされているとは言い難い。
そこで、レシピを提示する過程でユーザの関心（興味）を計測し、関心度として数値化する。
提示過程において関心度を計測（算出）することにより、レシピの提示優先度を適宜変えるための情報を得ることができる。また、関心度を計測することにより、ユーザの興味が高そうな関心レシピを新たに取得することができる。
そして、関心度に基づいて新たに取得した関心レシピは、条件適合レシピの少なくとも一部よりも高い提示優先度となるように（例えば、待機中の条件適合レシピの前に挿入されるように）提示優先度が再設定される。即ち、ユーザの興味の変化に追随することが可能な提示優先度が適宜設定される。
従って、ユーザは自身の興味のある関心レシピが次々と自動的に提示されるため、新たな検索を行うための追加の操作などを行う必要が少ない。そして、待機中のレシピよりも前に関心レシピが提示されることから、ユーザの興味を速やかに反映したレシピ提示を行うことができる。そして、条件適合レシピの全てがユーザ端末３に送信される前にユーザが所望すると考えられる関心レシピが提示されるため、条件適合レシピを全てユーザ端末３へ送信するよりも通信量の削減及び情報処理装置（レシピ管理サーバ１やユーザ端末３）の処理負担の軽減を図ることができる。
また、待機レシピが全て閲覧されてしまう前に関心レシピや条件適合レシピが追加で取得されるため、レシピの閲覧が終了してしまい次のレシピが提示されるまで待ち時間が発生してしまうことを抑制することができる。
尚、ユーザ端末３へ送信される関心レシピは、多数ある待機レシピのうちの少なくとも一つよりも前に提示されることにより、ユーザは全ての待機レシピを閲覧する前に関心レシピを閲覧することができるという効果が得られる。例えば、待機レシピが９００件ある場合には、該９００件のうちの９００番目に関心レシピが提示され、９０１番目に残りの待機レシピが提示されてもよい。
但し、更に効果を高めるためには、関心レシピは、少なくとも待機レシピの半数よりも高い提示優先度が設定されることが望ましい。勿論、一番効果を高めるためには、全ての待機レシピよりも高い提示優先度を設定することが望ましい。
このとき、一部が閲覧可能とされたレシピ（即ちウェブページ表示欄５に一部が表示されたレシピ）を閲覧レシピとした場合には、送り操作によって当該一部閲覧可能なレシピが完全に表示された後に関心レシピが表示される。一部閲覧可能なレシピの次に関心レシピの提示（表示）が始まることで、ユーザにとって自然にレシピ群を閲覧することができる。
一方、一部閲覧可能なレシピを待機レシピとした場合には、一部閲覧可能なレシピが下方へ移動しつつ、間に関心レシピが提示されることにより、関心レシピをユーザにアピールすることができる。

尚、上記した各種の処理のうちの多くをユーザ端末３側で実行する場合も考えられる。
例えば、ユーザ端末３は、ユーザが指定した検索クエリ等に基づいて複数のレシピの取得要求をレシピ管理サーバ１に送信する。そして、レシピ管理サーバ１から受信したレシピを条件適合レシピとして取得する。
そしてユーザ端末３は、条件適合レシピに提示優先度を付与し、ユーザ端末３の画面上などに提示する制御を行う。
ユーザがユーザ端末３上に表示されたレシピを閲覧する操作を行った場合に、ユーザ端末３はレシピごとに操作に応じた関心度を算出する。
ユーザ端末３は、未閲覧の待機レシピの数が少なくなってきたら条件適合レシピをレシピ管理サーバ１から追加取得する。即ち、第１取得処理を実行する。
また、ユーザ端末３は、レシピの関心度に応じて関心レシピをレシピ管理サーバ１から取得する。即ち、第２取得処理を実行する。
ユーザ端末３は、条件適合レシピと関心レシピに対して再度提示優先度を付与し、ユーザ端末３の画面上などに表示する。
このようにユーザ端末３で多くの処理を行った場合であっても、上述した各種の効果を奏することが可能である。

また、関心度算出処理の第２例で説明したように、関心度はレシピが属するカテゴリ（料理カテゴリ）に対して算出されてもよい。
これにより、ユーザが一つのレシピに対して関心を示した場合には、当該レシピが属する料理カテゴリに対する関心度が高く算出される。
従って、ユーザの興味を引く料理カテゴリ（分野）が特定されやすくできると共に、少しのレシピに対する興味を把握するだけでユーザの他のレシピに対する興味を掴むことができる。
また、ユーザが興味を持ったレシピに応じて同じ料理カテゴリに属する関心レシピが提示されていく過程で、同料理カテゴリに属する関心レシピの中で何れのレシピにユーザが興味を示すかを更に測る（即ち関心度を算出する）場合に、関心レシピ間の公平性を保ったまま関心度を算出することができる。
具体的には、例えば、レシピＡに対する関心度（即ちレシピＡが属する料理カテゴリＸに対する関心度）が５０点とされた場合に、料理カテゴリＸに属する他のレシピＢ，Ｃ，Ｄの関心度も５０点とされる。従って、レシピＡ，Ｂ，Ｃ，Ｄ（何れも料理カテゴリＸに属するレシピ）の中で何れのレシピの関心度が高いかを算出する場合に、ユーザが関心を示したレシピＡだけ関心度が高い状態で再算出が開始されるのではなく、レシピＡ，Ｂ，Ｃ，Ｄの何れも同じ５０点の状態で再算出が開始されるため、レシピＡ，Ｂ，Ｃ，Ｄ間の公平性が保たれたまま関連度の算出を行うことができる。

更に、関心度算出処理の第１例で説明したように、関心度はレシピに対して算出されてもよい。
これにより、レシピ特有の情報に応じた関心レシピが抽出されてユーザに提示される。
従って、料理カテゴリにとらわれずにレシピごとの特徴に応じた関心レシピをユーザに提示することができる。
特に、料理カテゴリを横断した複数の関心レシピの提示することができるため、予め決められたカテゴリ（料理カテゴリだけでなく調理方法などによって分けられたカテゴリなども含む）に因らず、柔軟な関心レシピの提示を行うことが可能となる。
従って、ユーザの関心が高いレシピを適切に提示することが可能となる。

更にまた、レシピ管理サーバの処理で説明したように、関心度算出部１ｅは、関心レシピの閲覧に応じた関心度を算出してもよい。
これにより、条件適合レシピに対するユーザの関心の度合いに応じて抽出された関心レシピに対して、更に関心度が算出される。そして、関心レシピに対する関心度に基づいて、更に関心レシピが取得されて提示される。
例えば、「カレー」に関するレシピに対しての関心が高いと判定されたユーザに対しては、関心レシピとして「キーマカレー」や「マトンカレー」や「欧風カレー」などに関するレシピが提示される。そして当該関心レシピ（「キーマカレー」や「マトンカレー」に関するレシピなど）に対する関心度が再び算出され、例えば「キーマカレー」に対する関心度が高いと判定された場合には、「キーマカレー」に関するレシピとして、「茄子のキーマカレー」や「トマトのキーマカレー」などのレシピが関心レシピとして抽出される。
即ち、ユーザの関心が推測されていくに従って、関心レシピとして取得されるレシピの範囲が狭く且つ深化される。換言すれば、ユーザが知りたいと考えているレシピの分野（料理カテゴリ）が自動的に特定されていく。
これにより、ユーザが求めていた情報（レシピ）を適切に提示でき、且つ特化した内容の情報（レシピ）を提示できる。

そして、第２取得処理の第２例で説明したように、算出された関心度が高いレシピの共通点を抽出する共通点抽出部１ｆを更に備え、レシピ取得部１ｃは第２取得処理において、共通点に基づいて関心レシピを取得してもよい。
ユーザは、一つのレシピ（或いは一つの料理カテゴリ）に対してのみ関心を示すだけでなく、複数のレシピ（或いは複数の料理カテゴリ）に対して関心を示すことが多々ある。このような場合に、一つのレシピＡに対する関心を鑑みて、レシピＡに関連した関心レシピＡ１，Ａ２，・・・を提示し、次にユーザが関心を示したレシピＢに対する関心を鑑みて、今度はレシピＢに関連した関心レシピＢ１，Ｂ２，・・・を提示しても、ユーザをある程度満足させることはできても、満足度の高い関心レシピを提示することは難しい場合がある。
そこで、それまで算出された関心度が高いレシピの共通点を抽出し、該共通点に基づいて関心レシピを取得し、ユーザに提示する。
具体的には、ユーザが「秋茄子のカレー」と「秋茄子のグラタン」に高い関心を示した場合には、「カレー」カテゴリや「グラタン」カテゴリに捕らわれることなく、共通点である「秋茄子」に注目することができる。この場合には、「秋茄子」をキーワードとして検索処理などが行われて「秋茄子」に関連したレシピが関心レシピとして取得される。換言すれば、ユーザの関心が高いレシピを適切に提示することが可能となる。
これにより、ユーザの関心が高いキーワード（食材等）を含んだレシピ（換言すればユーザを非常に満足させるレシピ）がユーザに提示される可能性を高めることができる。

加えて、全体の流れ（特に図７）で説明したように、提示優先度設定部１ｄは、ユーザが閲覧しているレシピの直後に関心レシピが提示されるように提示優先度の再設定を行ってもよい。
これにより、次のレシピを表示させる操作をユーザが行った場合、閲覧中のレシピの直後に関心レシピが提示される。換言すれば、条件適合レシピの中で待機中のものを提示する前に追加された関心レシピが最優先で提示される。
従って、ユーザの興味を汲み取った結果取得された関心レシピをすぐにユーザは閲覧することができる。また、閲覧中のレシピの直後に関心レシピが表示されることにより、前に戻る操作などを行わずに関心レシピを閲覧することができる。

また、第２取得処理の第３例で説明したように、レシピ取得部１ｃは、一連の閲覧セッションにおいて算出された関心度の最大値よりも大きい関心度が算出された場合に第２取得処理を行ってもよい。
一連の閲覧セッション（同一セッション）とは、例えばレシピを閲覧するためにサーバに接続してから接続が解除されるまでのような一連の期間でやり取りされる種々の処理（通信）である。
関心レシピが待機レシピとして増え続けることは、ユーザの通信量の増加を来すため、好ましくない場合がある。そのような場合に、本構成であれば、最大値よりも大きい関心度が算出された場合にのみ関心レシピを取得するための第２取得処理を実行するため、第２取得処理を実行する機会が抑制される。
従って、無闇に関心レシピの取得処理が実行されないため、通信量の削減が図られる。また、各情報処理装置において、通信や取得処理のための処理負担の軽減を図ることができる。

更に、閲覧時間に基づく関心情報の第１例で説明したように、関心度算出部１ｅは、レシピの閲覧時間に基づいて関心度を算出する場合に、ユーザに複数のレシピを提示している状態における閲覧時間は用いなくてもよい。
これにより、閲覧時間を測定するという比較的軽い処理で関心度を算出することができる。
従って、後続する処理である関心レシピの取得も速やかに行うことが可能となる。
また、複数のレシピを提示している時間帯は、関心度の算出に用いないことにより、ユーザが興味を抱いたレシピをより確実に判定することが可能となる。

更にまた、閲覧時間に基づく関心情報の第２例で説明したように、関心度算出部１ｅは、レシピの情報量に対する閲覧時間に基づいて関心度を算出してもよい。
情報量が多いレシピと情報量の少ないレシピが混在する場合、情報量の多いレシピの閲覧時間が長くなることは必然である。従って、レシピの情報量を考慮した閲覧時間に基づいて関心度を算出する。
従って、レシピの情報量の多寡によらず、関心度を適切に算出することができる。

そして、第１の変形例で説明したように、第１取得処理は、取得済みであって且つ未閲覧のレシピの数が追加取得閾値未満となったことに応じて実行され、追加取得閾値は、レシピの閲覧速度に応じてユーザごとに設定されてもよい。
閲覧速度はユーザごとに異なるものである。また、追加取得閾値は、ユーザがレシピの取得待ちをしなくても済むように次の条件適合レシピの取得を開始するタイミングを指定するために設けられるものである。
従って、ユーザごとに異なる閲覧速度を考慮して追加取得閾値は設けるべきものと考えられる。
本構成によれば、ユーザの閲覧速度に応じて追加取得閾値が設定されるため、ユーザがレシピの取得待ちをする可能性を減少させることができる。
即ち、閲覧速度が早いユーザに対して追加取得閾値は大きめに設定されるため、当該ユーザにとって十分な量のレシピが未閲覧の状態（待機レシピ）となり、レシピの取得待ちとなる時間が生じてしまうことを抑制できる。
一方、閲覧速度が遅いユーザに対して不必要に大きな追加取得閾値を設定しなくて済むため、当該ユーザにとって待機レシピが過剰となる通信を行う必要がなく、通信量を抑制することができる。

更に、関心レシピに対する提示優先度設定処理の第１例（図１５）や第２例（図１６）で説明したように、一度に複数のレシピを閲覧できるような提示が可能である場合に、提示優先度設定部１ｄは、再設定において、提示中のレシピの間に提示されるように関心レシピに対する提示優先度を設定してもよい。
つまり、ユーザの興味を汲み取って取得された関心レシピが閲覧中の複数のレシピの間に提示される。
従って、ユーザの興味の変化等を反映した提示が即座に行われる。また、ユーザがスクロール操作などを行うことなく、次々とユーザの関心が高そうなレシピが画面上に提示される。

上記の各例においては、ユーザに提示するコンテンツの例としてレシピを挙げ、ユーザに情報を提供する装置の例としてレシピ管理サーバ１を挙げたが、これらはほんの一例にすぎない。
例えば、各種ウェブページがコンテンツとされ、各種ウェブページを検索するための検索エンジンサーバが情報を提供する装置であってもよい。
また、複数のユーザが情報を発信するソーシャルネットワークにおける書き込み一つ一つがコンテンツとされ、該書き込みを検索する機能を提供するサーバ装置が情報を提供する装置であってもよい。
他にも、様々な形態のコンテンツ及び情報提供装置（情報処理装置）の例が考えられる。

尚、未閲覧のコンテンツの数が閾値未満となったことを条件として、条件適合コンテンツを追加で取得する（第１取得処理を実行する）例を説明したが、他の条件によって追加取得してもよい。
例えば、前回の条件適合コンテンツ取得（或いは追加取得）から所定時間経過後に、ユーザがそれらのコンテンツの閲覧を続けていることを条件に次の第１取得処理を実行してもよい。

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

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

実施の形態のプログラムは、
所定条件に基づいて複数のコンテンツを条件適合コンテンツとして取得するコンテンツ取得機能を情報処理装置に実行させる。
また、条件適合コンテンツに提示優先度を設定する提示優先度設定機能を情報処理装置に実行させる。
更に、コンテンツの閲覧に応じてユーザの関心を数値化した関心度を算出する関心度算出機能を情報処理装置に実行させる。
コンテンツ取得機能としては、条件適合コンテンツを追加で取得する機能や関心度に応じて条件適合コンテンツとは異なる関心コンテンツを取得する機能を情報処理装置に実行させる。
提示優先度設定機能としては、取得済みの条件適合コンテンツの少なくとも一部よりも関心コンテンツが早く提示されるように提示優先度を再設定する機能を情報処理装置に実行させる。
即ちこのプログラムは、レシピ管理サーバ１に対して、図６のステップＳ２０１乃至Ｓ２１３の各処理、図８乃至図１３の各処理、図１９の各処理を実行させるプログラムである。

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

１ レシピ管理サーバ、１ａ レシピ管理部、１ｂ ユーザ管理部、１ｃ レシピ取得部、１ｄ 提示優先度設定部、１ｅ 関心度算出部、１ｆ 共通点抽出部、１ｇ 送信制御部、２ 通信ネットワーク、３ ユーザ端末、９ 閲覧レシピ、１０ 待機レシピ、１１ 条件適合レシピ、１２ 関心レシピ、５０ ユーザＤＢ、５１ レシピＤＢ、５２ 検索ＤＢ、５３ ウェブページＤＢ

Claims (13)

1. 所定条件に基づいて複数のコンテンツを条件適合コンテンツとして取得するコンテンツ取得部と、
   前記条件適合コンテンツに提示優先度を設定する提示優先度設定部と、
   コンテンツの閲覧に応じてユーザの関心を数値化した関心度を算出する関心度算出部と、を備え、
   前記コンテンツ取得部は、
   取得済みであって且つ未閲覧のコンテンツの数が閾値未満となったことに応じて前記条件適合コンテンツを追加で取得する第１取得処理と、
   前記関心度に応じて前記条件適合コンテンツとは異なる関心コンテンツを取得する第２取得処理と、を実行し、
   前記提示優先度設定部は、
   取得済みの前記条件適合コンテンツの少なくとも一部よりも前記関心コンテンツが早く提示されるように前記提示優先度を再設定し、
   前記閾値は、コンテンツの閲覧速度に応じてユーザごとに設定される
   情報処理装置。
2. 前記関心度はコンテンツが属するカテゴリに対して算出される
   請求項１に記載の情報処理装置。
3. 前記関心度はコンテンツに対して算出される
   請求項１に記載の情報処理装置。
4. 前記関心度算出部は、前記関心コンテンツの閲覧に応じた関心度を算出する
   請求項１に記載の情報処理装置。
5. 算出された関心度が高いコンテンツの共通点を抽出する共通点抽出部を更に備え、
   前記コンテンツ取得部は前記第２取得処理において、前記共通点に基づいて前記関心コンテンツを取得する
   請求項１に記載の情報処理装置。
6. 前記提示優先度設定部は、ユーザが閲覧しているコンテンツの直後に前記関心コンテンツが提示されるように前記再設定を行う
   請求項１に記載の情報処理装置。
7. 前記コンテンツ取得部は、一連の閲覧セッションにおいて算出された関心度の最大値よりも大きい関心度が算出された場合に前記第２取得処理を行う
   請求項１に記載の情報処理装置。
8. 前記関心度算出部は、コンテンツの閲覧時間に基づいて前記関心度を算出する場合に、ユーザに複数のコンテンツを提示している状態における閲覧時間は用いない
   請求項１に記載の情報処理装置。
9. 前記関心度算出部は、コンテンツの情報量に対する閲覧時間に基づいて前記関心度を算出する
   請求項１に記載の情報処理装置。
10. 一度に複数のコンテンツを閲覧できるような提示が可能である場合に、
    前記提示優先度設定部は、前記再設定において、提示中のコンテンツの間に提示されるように前記関心コンテンツに対する前記提示優先度を設定する
    請求項１に記載の情報処理装置。
11. 所定条件に基づいて複数のコンテンツを条件適合コンテンツとして取得するコンテンツ取得ステップと、
    前記条件適合コンテンツに提示優先度を設定する提示優先度設定ステップと、
    取得済みであって且つ未閲覧のコンテンツの数がコンテンツの閲覧速度に応じてユーザごとに設定される閾値未満となったことに応じて前記条件適合コンテンツを追加で取得する第１取得ステップと、
    コンテンツの閲覧に応じてユーザの関心を数値化した関心度を算出する関心度算出ステップと、
    前記関心度に応じて前記条件適合コンテンツとは異なる関心コンテンツを取得する第２取得ステップと、
    取得済みの前記条件適合コンテンツの少なくとも一部よりも前記関心コンテンツが早く提示されるように前記提示優先度を再設定するステップと、を
    情報処理装置が実行する情報処理方法。
12. 所定条件に基づいて複数のコンテンツを条件適合コンテンツとして取得するコンテンツ取得機能と、
    前記条件適合コンテンツに提示優先度を設定する提示優先度設定機能と、
    取得済みであって且つ未閲覧のコンテンツの数がコンテンツの閲覧速度に応じてユーザごとに設定される閾値未満となったことに応じて前記条件適合コンテンツを追加で取得する第１取得機能と、
    コンテンツの閲覧に応じてユーザの関心を数値化した関心度を算出する関心度算出機能と、
    前記関心度に応じて前記条件適合コンテンツとは異なる関心コンテンツを取得する第２取得機能と、
    取得済みの前記条件適合コンテンツの少なくとも一部よりも前記関心コンテンツが早く提示されるように前記提示優先度を再設定する機能と、を
    情報処理装置に実行させるプログラム。
13. 所定条件に基づいて複数のコンテンツを条件適合コンテンツとして取得するコンテンツ取得機能と、
    前記条件適合コンテンツに提示優先度を設定する提示優先度設定機能と、
    取得済みであって且つ未閲覧のコンテンツの数がコンテンツの閲覧速度に応じてユーザごとに設定される閾値未満となったことに応じて前記条件適合コンテンツを追加で取得する第１取得機能と、
    コンテンツの閲覧に応じてユーザの関心を数値化した関心度を算出する関心度算出機能と、
    前記関心度に応じて前記条件適合コンテンツとは異なる関心コンテンツを取得する第２取得機能と、
    取得済みの前記条件適合コンテンツの少なくとも一部よりも前記関心コンテンツが早く提示されるように前記提示優先度を再設定する機能と、を
    情報処理装置に実行させるプログラムを記憶した記憶媒体。

Images