WO2019097785A1 - 情報処理装置、情報処理方法、およびプログラム - Google Patents

Abstract

【課題】ユーザの状態に適したタイミングでより有益な推薦情報を提示する。 【解決手段】コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御する提示制御部、を備え、前記提示制御部は、前記コンテンツに係るコンテンツ状況と前記ユーザに係るユーザ状況とのマッチングにより算出した受容度スコアにさらに基づいて、前記推薦情報の提示を制御する、情報処理装置が提供される。また、プロセッサが、コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御すること、を含み、前記提示を制御することは、前記コンテンツに係るコンテンツ状況と前記ユーザに係るユーザ状況とのマッチングにより算出した受容度スコアに基づいて、前記推薦情報の提示を制御すること、をさらに含む、情報処理方法が提供される。

Description

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

　本開示は、情報処理装置、情報処理方法、およびプログラムに関する。

　近年、ユーザの嗜好などに基づいて、当該ユーザに対し推薦情報を提示する種々の装置が普及している。例えば、特許文献１には、サービスに対するユーザの利用履歴に基づいて、当該ユーザに対しコンテンツの推薦を行う技術が開示されている。

特開２０１５－３５１４０号公報

　ところで、上記のような推薦技術においては、ユーザに対し推薦情報を提示するタイミングが重要となる。しかし、特許文献１に記載の技術は、上記のタイミングを考慮していないため、推薦情報が十分に活用されない場合も想定される。

　そこで、本開示では、ユーザの状態に適したタイミングでより有益な推薦情報を提示することが可能な、新規かつ改良された情報処理装置、情報処理方法、およびプログラムを提案する。

　本開示によれば、コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御する提示制御部、を備え、前記提示制御部は、前記コンテンツに係るコンテンツ状況と前記ユーザに係るユーザ状況とのマッチングにより算出した受容度スコアにさらに基づいて、前記推薦情報の提示を制御する、情報処理装置が提供される。

　また、本開示によれば、プロセッサが、コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御すること、を含み、前記提示を制御することは、前記コンテンツに係るコンテンツ状況と前記ユーザに係るユーザ状況とのマッチングにより算出した受容度スコアに基づいて、前記推薦情報の提示を制御すること、をさらに含む、情報処理方法が提供される。

　また、本開示によれば、コンピュータを、コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御する提示制御部、を備え、前記提示制御部は、前記コンテンツに係るコンテンツ状況と前記ユーザに係るユーザ状況とのマッチングにより算出した受容度スコアにさらに基づいて、前記推薦情報の提示を制御する、情報処理装置、として機能させるためのプログラムが提供される。

　以上説明したように本開示によれば、ユーザの状態に適したタイミングでより有益な推薦情報を提示することが可能となる。

　なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。

本開示の一実施形態の概要について説明するための図である。 同実施形態に係る情報処理システムのシステム構成例を示すブロック図である。 同実施形態に係る情報処理端末の機能構成例を示すブロック図である。 同実施形態に係る情報処理サーバの機能構成例を示すブロック図である。 同実施形態に係る提示制御部の機能構成例を示すブロック図である。 同実施形態に係るスポット解析情報のデータ構造の一例を示す図である。 同実施形態に係るスポット解析情報のデータ構造の一例を示す図である。 同実施形態に係る状況属性ごとの受容度の計算について説明するための図である。 同実施形態に係る状況理由について説明するための図である。 同実施形態に係るユーザ履歴のデータ構造の一例を示す図である。 同実施形態に係る推薦スコアの算出の流れを示すフローチャートである。 同実施形態に係るウィッシュリストに基づく推薦結果の取得の流れを示すフローチャートである。 同実施形態に係る受容度スコアの算出の流れを示すフローチャートである。 同実施形態に係る受容度スコア算出の具体例を示す図である。 同実施形態に係る受容度スコア算出の具体例を示す図である。 同実施形態に係る推薦情報の提示と状況理由に係るユーザ履歴の取得の流れを示すフローチャートである。 同実施形態に係る推薦情報の一例である。 同実施形態に係るユーザ個人またはユーザグループに対する推薦情報の提示について説明するための図である。 本開示の一実施形態に係るハードウェア構成例を示す図である。

　以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

　なお、説明は以下の順序で行うものとする。
　１．第１の実施形態
　　１．１．概要
　　１．２．システム構成例
　　１．３．情報処理端末１０の機能構成例
　　１．４．情報処理サーバ２０の機能構成例
　　１．５．動作の流れ
　　１．６．ユーザ個人またはユーザグループへの推薦
　２．ハードウェア構成例
　３．まとめ

　＜１．第１の実施形態＞
　＜＜１．１．概要＞＞
　まず、本開示の一実施形態の概要について説明する。上述したように、近年においては、ユーザに対し推薦情報を提示する種々の装置が普及している。上記のような装置は、例えば、ユーザの嗜好などに基づいて、商品やサービス、イベント、行楽スポットなどに係る推薦を行うことができる。

　一方、推薦情報の提示においては、ユーザに対して推薦を行うタイミングが非常に重要である。例えば、ユーザに対する行楽スポットの推薦において、ユーザの旅行中または帰宅直後に別途の行楽スポットを推薦する場合、当該行楽スポットがユーザの嗜好に適合していても、直近の旅行で満足しているユーザにとっては、推薦の効果が芳しくない可能性が想定される。

　他方、例えば、長期休暇や、ユーザが毎年行っている家族旅行の時期に予約が間に合うタイミングで行楽スポットの推薦を行う場合、ユーザに対する推薦情報の訴求効果が著しく高まることが予測される。

　また、推薦情報の内容や提示タイミングを決定する際には、行楽スポットやユーザの状況、また当該状況の変化なども重要な要素となる。

　本開示に係る技術思想は、上記の点に着目して発想されたものであり、ユーザの状態に適したタイミングでより有益な推薦情報を提示することを可能とする。このために、本開示の一実施形態に係る情報処理方法を実現する情報処理装置は、コンテンツに係る推薦スコアに基づいて、ユーザに対する推薦情報の提示を制御すること、を特徴の一つとする。また、本開示の一実施形態に係る情報処理装置は、コンテンツ状況とユーザ状況とのマッチングにより算出した受容度スコアにさらに基づいて推薦情報の提示を制御すること、を特徴の一つとする。

　図１は、本開示の一実施形態の概要について説明するための図である。図１には、本実施形態に係る情報処理端末１０が情報処理サーバ２０による制御に基づいて、ユーザＵ１に対し行楽スポットに係る推薦情報を提示する場合の一例が示されている。

　上述したように、本実施形態に係る情報処理方法は、行楽スポットなどのコンテンツに係る推薦の度合いを示す指標である推薦スコアに加え、コンテンツ状況とユーザ状況とのマッチングにより算出した受容度スコアに基づいて推薦情報の提示を制御することができる。

　例えば、図１に示す一例の場合、情報処理サーバ２０は、コンテンツ状況やユーザ状況の一種である対象年齢のマッチングから算出した受容度スコアに基づいて、Ｘ遊園地に係る推薦情報を視覚情報ＶＩ１および音声発話ＳＯ１を用いて情報処理端末１０に提示させている。

　より具体的には、情報処理サーバ２０は、ユーザＵ１の子供が小学生になったこと（ユーザ状況）により、Ｘ遊園地が既定する対象年齢（コンテンツ状況）に適合する結果に至ったことに基づいて、Ｘ遊園地に係る推薦提示を情報処理端末１０に実行させている。

　また、情報処理サーバ２０は、過去にユーザＵ１が、子供が対象年齢に達していないために、Ｘ遊園地への訪問を断念していた事実に基づいて、上記の提示制御を行ってもよい。この際、本実施形態に係る情報処理サーバ２０は、例えば、音声発話ＳＯ１などにより、子供が対象年齢に達したことを強調した推薦情報の提示を情報処理端末１０に実行させることができる。

　このように、本実施形態に係る情報処理サーバ２０によれば、日々変化するユーザの状況を考慮することで、より適したタイミングでより有益な推薦情報をユーザに提供することが可能となる。

　以上、本実施形態の概要について説明した。以下、本実施形態に係る情報処理装置、情報処理方法、およびプログラムが有する特徴と、当該特徴により奏される効果について詳細に説明する。

　＜＜１．２．システム構成例＞＞
　次に、本実施形態に係る情報処理システムのシステム構成例について説明する。図２は、本実施形態に係る情報処理システムのシステム構成例を示すブロック図である。図２を参照すると、本実施形態に係る情報処理システムは、情報処理端末１０および情報処理サーバ２０を含む。また、本実施形態に係る情報処理端末１０および情報処理サーバ２０は、互いに通信が行えるようにネットワーク３０を介して接続される。

　（情報処理端末１０）
　本実施形態に係る情報処理端末１０は、情報処理サーバ２０による制御に基づいて、ユーザに対し推薦情報の提示を行う情報処理装置である。本実施形態に係る情報処理端末１０は、収集した音情報や画像情報、センサ情報を情報処理端末１０に送信し、情報処理端末１０から推薦情報の提示に係る制御信号を受信する。

　本実施形態に係る情報処理端末１０は、例えば、携帯電話、スマートフォン、タブレット、種々の家電機器、据え置き型または自律移動型の専用装置であってもよい。

　（情報処理サーバ２０）
　本実施形態に係る情報処理サーバ２０は、情報処理端末１０によるユーザへの推薦情報の提示を制御する情報処理装置である。上述したように、本実施形態に係る情報処理サーバ２０は、コンテンツに係る推薦スコアに加え、コンテンツ状況とユーザ状況とのマッチングにより算出した受容度スコアに基づいて推薦情報の提示を制御すること、を特徴の一つとする。

　（ネットワーク３０）
　ネットワーク３０は、情報処理端末１０と情報処理サーバ２０とを接続する機能を有する。ネットワーク３０は、インターネット、電話回線網、衛星通信網などの公衆回線網や、Ｅｔｈｅｒｎｅｔ（登録商標）を含む各種のＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）などを含んでもよい。また、ネットワーク３０は、ＩＰ－ＶＰＮ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ－Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）などの専用回線網を含んでもよい。また、ネットワーク３０は、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）など無線通信網を含んでもよい。

　以上、本実施形態に係る情報処理システムの構成例について説明した。なお、図２を用いて説明した上記の構成はあくまで一例であり、本実施形態に係る情報処理システムの構成は係る例に限定されない。例えば、本実施形態に係る情報処理端末１０および情報処理サーバ２０が有する機能は、単一の装置により実現されてもよい。本実施形態に係る情報処理システムの構成は、仕様や運用に応じて柔軟に変形可能である。

　＜＜１．３．情報処理端末１０の機能構成例＞＞
　次に、本実施形態に係る情報処理端末１０の機能構成例について説明する。図３は、本実施形態に係る情報処理端末１０の機能構成例を示すブロック図である。図３を参照すると、本実施形態に係る情報処理端末１０は、表示部１１０、音声出力部１２０、音声入力部１３０、撮像部１４０、センサ部１５０、制御部１６０、およびサーバ通信部１７０を備える。

　（表示部１１０）
　本実施形態に係る表示部１１０は、画像やテキストなどの視覚情報を出力する機能を有する。本実施形態に係る表示部１１０は、例えば、情報処理サーバ２０による制御に基づいて、推薦情報に対応するテキストや画像を表示する。表示部１１０は、本実施形態に係る提示部の一つといえる。

　このために、本実施形態に係る表示部１１０は、視覚情報を提示する表示デバイスなどを備える。上記の表示デバイスには、例えば、液晶ディスプレイ（ＬＣＤ：Ｌｉｑｕｉｄ　Ｃｒｙｓｔａｌ　Ｄｉｓｐｌａｙ）装置、ＯＬＥＤ（Ｏｒｇａｎｉｃ　Ｌｉｇｈｔ　Ｅｍｉｔｔｉｎｇ　Ｄｉｏｄｅ）装置、タッチパネルなどが挙げられる。また、本実施形態に係る表示部１１０は、プロジェクション機能により視覚情報を出力してもよい。

　（音声出力部１２０）
　本実施形態に係る音声出力部１２０は、音声発話を含む種々の音を出力する機能を有する。本実施形態に係る音声出力部１２０は、例えば、情報処理サーバ２０による制御に基づいて、推薦情報に対応する音声発話を出力する。このために、本実施形態に係る音声出力部１２０は、スピーカやアンプなどの音声出力装置を備える。音声出力部１２０は、本実施形態に係る提示部の一つといえる。

　（音声入力部１３０）
　本実施形態に係る音声入力部１３０は、ユーザによる発話や、情報処理端末１０の周囲で発生する周囲音などの音情報を収集する機能を有する。音声入力部１３０が収集する音情報は、情報処理サーバ２０による音声認識や状況分析などに用いられる。本実施形態に係る音声入力部１３０は、音情報を収集するためのマイクロフォンを備える。

　（撮像部１４０）
　本実施形態に係る撮像部１４０は、ユーザや周囲環境の画像を撮像する機能を有する。撮像部１４０が撮像した画像情報は、情報処理サーバ２０によるユーザの状況分析などに用いられる。本実施形態に係る撮像部１４０は、画像を撮像することが可能な撮像装置を備える。なお、上記の画像には、静止画像のほか動画像が含まれる。

　（センサ部１５０）
　本実施形態に係るセンサ部１５０は、周囲環境やユーザの行動、状態に関する種々のセンサ情報を収集する機能を有する。センサ部１５０が収集したセンサ情報は、情報処理サーバ２０によるユーザの状況解析などに用いられる。センサ部１５０は、例えば、赤外線センサを含む光センサ、加速度センサ、ジャイロセンサ、地磁気センサ、熱センサ、振動センサ、ＧＮＳＳ（Ｇｌｏｂａｌ　Ｎａｖｉｇａｔｉｏｎ　Ｓａｔｅｌｌｉｔｅ　Ｓｙｓｔｅｍ）信号受信装置などを備える。

　（制御部１６０）
　本実施形態に係る制御部１６０は、情報処理端末１０が備える各構成を制御する機能を有する。制御部１６０は、例えば、各構成の起動や停止を制御する。また、制御部１６０は、情報処理サーバ２０により生成される制御信号を表示部１１０や音声出力部１２０に入力する。また、本実施形態に係る制御部１６０は、後述する情報処理サーバ２０の提示制御部２３０と同等の機能を有してもよい。

　（サーバ通信部１７０）
　本実施形態に係るサーバ通信部１７０は、ネットワーク３０を介して情報処理サーバ２０との情報通信を行う機能を有する。具体的には、サーバ通信部１７０は、音声入力部１３０が収集した音情報や、撮像部１４０が撮像した画像情報、センサ部１５０が収集したセンサ情報を情報処理サーバ２０に送信する。また、サーバ通信部１７０は、情報処理サーバ２０から推薦情報の提示に係る制御信号などを受信する。

　以上、本実施形態に係る情報処理端末１０の機能構成例について説明した。なお、図３を用いて説明した上記の構成はあくまで一例であり、本実施形態に係る情報処理端末１０の機能構成は係る例に限定されない。例えば、本実施形態に係る情報処理端末１０は、図３に示す構成のすべてを必ずしも備えなくてもよい。例えば、情報処理端末１０は、センサ部１５０などを備えない構成をとることもできる。また、上述したように、本実施形態に係る制御部１６０は、情報処理サーバ２０の提示制御部２３０と同等の機能を有してもよい。本実施形態に係る情報処理端末１０の機能構成は、仕様や運用に応じて柔軟に変形可能である。

　＜＜１．４．情報処理サーバ２０の機能構成例＞＞
　次に、本実施形態に係る情報処理サーバ２０の機能構成例について詳細に説明する。図４は、本実施形態に係る情報処理サーバ２０の機能構成例を示すブロック図である。図４を参照すると、本実施形態に係る情報処理サーバ２０は、端末通信部２１０、記憶部２２０、および提示制御部２３０を備える。

　（端末通信部２１０）
　本実施形態に係る端末通信部２１０は、ネットワーク３０を介して情報処理端末１０との情報通信を行う機能を有する。具体的には、端末通信部２１０は、情報処理端末１０から音情報、画像情報、およびセンサ情報などを受信する。また、端末通信部２１０は、提示制御部２３０による制御に基づいて推薦情報の提示に係る制御信号を情報処理端末１０に送信する。

　（記憶部２２０）
　本実施形態に係る記憶部２２０は、提示制御部２３０の処理に用いられるプログラムや演算パラメータ等を記憶するＲＯＭ（Read　Only　Memory）、および適宜変化するパラメータ等を一時記憶するＲＡＭ（Random　Access　Memory）により実現される。

　（提示制御部２３０）
　本実施形態に係る提示制御部２３０は、コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御する機能を有する。また、本実施形態に係る提示制御部２３０は、コンテンツに係るコンテンツ状況とユーザに係るユーザ状況とのマッチングにより算出した受容度スコアにさらに基づいて、情報処理端末１０による推薦情報の提示を制御すること、を特徴の一つとする。

　本実施形態に係る提示制御部２３０が有する上記の特徴によれば、推薦時におけるユーザ状況や、時間経過に伴うユーザ状況の変化などに応じた、より適切なタイミングでより有益な推薦情報をユーザに提供することが可能となる。

　なお、本実施形態に係るコンテンツには、商品、サービス、イベント、行楽スポット、行動などが広く含まれる。以下においては、本実施形態に係るコンテンツが行楽スポットであり、提示制御部２３０が行楽スポット（以下、単に、スポット、とも称する）に係る推薦情報の提示を制御する場合の例を説明するが、本実施形態に係る提示制御部２３０は、種々のコンテンツに係る推薦情報の提示を制御することが可能である。

　続いて、本実施形態に係る提示制御部２３０の機能構成例について詳細に説明する。図５は、本実施形態に係る提示制御部２３０の機能構成例を示すブロック図である。図５を参照すると、本実施形態に係る提示制御部２３０は、情報収集部２４０、情報解析部２５０、推薦部２６０、履歴管理部２７０、反応解析部２８０、状況解析部２９０、および情報統合部３００を備える。

　（情報収集部２４０）
　本実施形態に係る情報収集部２４０は、行楽スポットなどに係るメタデータを、ネットワーク上のＷｅｂサイトや、お出かけ情報サイトなどから収集し（いわゆるＷｅｂクローリングを行い）、収集したメタデータを記憶部２２０が備えるスポット情報記憶部に蓄積する機能を有する。なお、上記のメタデータには、行楽スポットの対象年齢、住所、営業時間、料金、アクセス、駐車場情報、ジャンル、詳細メタ（情報サイト利用者が任意に付けたタグ情報など）、周辺天気予報、口コミ（体験談）などが含まれる。

　（情報解析部２５０）
　本実施形態に係る情報解析部２５０は、情報収集部２４０により収集されたメタデータの解析を行う。具体的には、情報解析部２５０は、特開２００５－１７６４０４号公報で開示される手法などを用いて、メタデータの属性値ごとにスコアを持つベクトル（コンテンツプロファイル）をスポット（コンテンツ）毎に生成する。

　ここで、図６および図７に、スポット解析情報のデータ構造の一例を示す。図６および図７に示すように、スポット解析情報のデータ構造は、「ＩＤ」、「Ｃｏｎｔｅｎｔ　Ｖｅｃｔｏｒ」、および「Ｃｏｎｔｅｎｔ　Ｉｎｆｏ」から成る。

　「Ｃｏｎｔｅｎｔ　Ｖｅｃｔｏｒ」は、スポット間の類似性や、スポットとユーザの嗜好との関連性を測る際に用いるメタデータである。「Ｃｏｎｔｅｎｔ　Ｖｅｃｔｏｒ」には、例えば、スポットの説明（紹介文クラスタ）、一般カテゴリ、サービスが提供する専門ジャンル、タグ、対象年齢、施設の有無、口コミのタイトル、口コミの内容（口コミクラスタ）が挙げられる。

　また、「Ｃｏｎｔｅｎｔ　Ｉｎｆｏ」は、スポットの詳細情報に関するメタデータである。「Ｃｏｎｔｅｎｔ　Ｉｎｆｏ」には、例えば、エリア、電話番号、営業時間、住所、料金、緯度経度、評価などが挙げられる。

　なお、「Ｃｏｎｔｅｎｔ　Ｖｅｃｔｏｒ」と「Ｃｏｎｔｅｎｔ　Ｉｎｆｏ」の区別はあくまで一例である。「Ｃｏｎｔｅｎｔ　Ｖｅｃｔｏｒ」と「Ｃｏｎｔｅｎｔ　Ｉｎｆｏ」とは、一部重複していてもよいし、用途に応じて適宜定義してもよい。また、string型のテキストは形態素解析され（対象品詞を指定可能）、キーワードのベクトル「(キーワード，頻度)」として表現される。例えば、（水族館，２）、（アトラクション，３）、（レストラン，２）、（ショッピング，１）、（ホテル，１）、（アミューズメント、１）のように変換される。

　また、紹介文や口コミに対するクラスタリングにおいては、潜在トピックモデルの手法としてテキスト分類で広く用いられるＰＬＳＡ（Probabilistic　Latent　Semantic　Analysis）やＬＤＡ（Latent　Dirichlet　Allocation）を利用してもよい。ＰＬＳＡの詳細に関しては、非特許文献１：Thomas　Hofmann,“Probabilistic　latent　semantic　indexing”，1999，Proceedings　of　the　22^nd　annual　international　ACM　SIGIR　conference　ON　Research　and　development　in　information　retrievalが参照される。また、ＬＤＡの詳細に関しては、非特許文献２：David　M．　Blei，　Andrew　Y．Ng，　Michael　I．　Jordan，　“Latent　Dirichlet　Allocation”，　2003，　Journal　of　Machine　Learning　Research，　Volume　3が参照される。

　ＰＬＳＡにおいては、例えば紹介文ｄにおける単語ｗの生起確率ｐ（ｗ｜ｄ）を潜在トピックｚを用いて下記式のように表現する。

　つまり、潜在トピックｚを紹介文および単語が生起する潜在トピックと考えて、紹介文における単語の生起確率を「潜在トピックごとの単語生起確率」と「紹介文のトピック帰属確率」に分解することができる。トピックｚの次元数を５とした場合、あるスポットの紹介に関するトピックの帰属確率は{0.4，0.1，0.7，0.2，0.5}のように表現され、これがクラスタリングの結果となる。

　また、上記メタデータのうち、「ｎｕｄｇｅ　Ｃａｔｅｇｏｒｙ　Ｉｄ」は、システムで定義した一般カテゴリであって、「ｓｅｒｖｉｃｅ　Ｃａｔｅｇｏｒｙ　Ｉｄ」は、サービスが提供する専門ジャンルである。「ｎｕｄｇｅ　Ｃａｔｅｇｏｒｙ」としては、例えば、CAMP、BBQ、GUEST　RANCH（観光牧場）、OUTDOOR　LEISURE、PARK、DOGRUN、AMUSEMENT　PARK、THEME　PARK、AQUARIUM、ZOO、FOOD　THEMEPARK、SCIENCE　MUSEUM、MUSEUM、ART　MUSEUM、SHRINE、TEMPLEなどが挙げられる。また、「ｓｅｒｖｉｃｅ　Ｃａｔｅｇｏｒｙ」としては、INDOOR　AMUSEMENT　PARK（屋内遊園地）、SAFARIPARK、BOTANICAL　GARDEN、FISHING、HIKING、FRUIT　PICKING（果物狩り）、FARMING　ACTIVITY（農業体験）、SOCIAL　STUDY（社会見学）、EXPERIENCE　FACILITY（体験施設）などが挙げられる。

　（推薦部２６０）
　本実施形態に係る推薦部２６０は、ユーザの嗜好や習慣に基づいて、コンテンツに係る推薦情報を生成する。

　まず、推薦部２６０は、ユーザの嗜好情報および情報解析部２５０が解析したスポット解析情報（ベクトル化されたコンテンツプロファイル）に基づいて、ユーザの嗜好に応じた推薦情報を生成する。具体的には、推薦部２６０は、履歴管理部２７０で管理されているユーザ履歴に含まれるユーザの行動履歴を分析して得たユーザプリファレンスと、上記のコンテンツプロファイルとをマッチングし、条件ごとの推薦情報を生成する。ユーザプリファレンスは、ユーザ履歴におけるユーザ行動のメタデータあるいはコンテンツプロファイルの重み付け和から生成されるベクトルとして表現されてもよい。

　推薦部２６０は、ユーザ履歴に基づいて属性値をベクトル化したユーザプリファレンスを生成することも可能である。この場合、推薦部２６０は、例えば特開２００５－１７６４０４号公報に記載の手法によって、ユーザプリファレンスとコンテンツプロファイルとのマッチングを行い（項目ごとにそれぞれ内積を演算）算出した推薦スコア（ベクトル間の内積の総和など）に基づいて、推薦情報の生成を行う。

　例えば、推薦部２６０は、季節別（春、夏、秋、冬）、期間別（日帰り、一泊、二泊以上）、および目的別に（家族旅行、夫婦で外食、親子でお出かけ、親子で買い物）、ユーザの嗜好に応じた行楽スポットの推薦情報を生成する。具体的には、例えば下記のように推薦条件と合わせた推薦結果が生成される。この際、推薦部２６０は、既にユーザが訪れたことのあるスポットを推薦結果に含まないなど、所定のフィルタを設定してもよい。

　（（スポット推薦結果の例））
　推薦条件ａ：春、一泊、家族で旅行
　　　第１位　ＡＢＣ旅館
　　　第２位　ＡＢＣテーマパーク
　　　第３位　ＡＢＣ牧場
　推薦ｂ：夏、二泊以上、家族で旅行
　　　第１位　ＡＢＣホテル
　　　第２位　ＡＢＣ旅館
　　　第３位　ＡＢＣ遊園地
　推薦ｃ：冬、日帰り、親子でお出かけ
　　　第１位　ＡＢＣコンサート
　　　第２位　ＡＢＣ水族館
　　　第３位　ＡＢＣ博物館

　なお、推薦部２６０は、複数のユーザプリファレンスに基づいて、同様にユーザグループ（家族、友達グループ等）に対する推薦情報の生成を行うことも可能である。

　また、推薦部２６０は、ユーザ履歴に基づいて将来発生するイベントを予測する機能を有する。具体的には、推薦部２６０は、ユーザ履歴から過去のイベントを抽出し、次に発生するタイミングを予測する。例えば、ユーザが特定の時期の連休に毎年海外旅行に行っている場合、次の同じ時期の連休にも海外旅行イベントが発生すると予測する。このように、推薦部２６０は、ユーザ履歴に基づいてユーザの習慣を把握し、イベントの発生予測を行うことができる。

　次いで、推薦部２６０は、予測したイベントを推薦条件とする推薦結果を取得し、する。なお、推薦部２６０は、予測したイベントを推薦条件とする複数の推薦結果（上位５つの行楽スポットなど）を取得してもよい。

　次に、推薦部２６０は、ユーザへの推薦情報の通知タイミングを決定する。上述したように、行動を決定するタイミングはユーザによって異なるため、推薦部２６０は、ユーザ履歴に基づいて適切な通知タイミングを決定する。具体的には、推薦部２６０は、例えば、過去の同目的のイベントの時間情報（実際にイベントが実行された日付）と、当該イベントがスケジュール情報に登録された日付との差分（または過去の複数のイベントにおける同差分の平均値）を、当該イベントの準備期間と推定し、予測したイベントの発生日時から準備期間を指し引いた日時を、当該予測したイベントのスケジュール登録を促す最適なタイミングと判断してもよい。

　ここでは一例として、イベントの準備、計画を始めた時期を、スケジュール情報への登録日時としているが、本実施形態は係る例に限定されず、例えば同目的のイベントに関する検索（Ｗｅｂの検索サイトでの検索、音声エージェントを利用した検索等）をユーザが行った日時としてもよいし、同目的のイベントに関するする会話（メールやチャットによる他ユーザとの会話や、音声エージェントとの会話等）をユーザが行った日時としてもよい。

　また、推薦部２６０は、上記準備期間を、推薦するイベントにおける行楽スポットなどのジャンルに応じて算出してもよい。例えば、ホテルであれば３０日前、テーマパークであれば３日前、牧場であれば７日前等と算出する。また、推薦部２６０は、上記準備期間を、さらに季節や時期、人気によって変化させてもよい。これにより、例えばホテルの場合は宿泊予約が必要であるが、季節や時期によっては混雑するため、満室になってしまうリスクを考慮して早めにユーザに推薦するようにすることを可能とする。

　また、本実施形態に係る推薦部２６０は、上記で説明した推薦スコアに加え、コンテンツ状況とユーザ状況とのマッチングにより算出した受容度スコアに基づいて、推薦情報の生成を行うこと、を特徴の一つとする。

　より具体的には、本実施形態に係る推薦部２６０は、コンテンツ状況およびユーザ状況が含む状況属性ごとの受容度を算出し、当該状況属性ごとの受容度に基づいて最終的な受容度スコアを算出してよい。

　図８は、本実施形態に係る状況属性ごとの受容度の計算について説明するための図である。図８に示すように、本実施形態に係る状況属性は、例えば、場所、日時、気候、年齢、費用、注目度、混雑、カテゴリ、およびキーワードなどの属性を含んでもよい。本実施形態に係る状況属性とは、行楽スポットやユーザの状況を表す属性である。

　例えば、状況属性：場所の場合、スポット状況（コンテンツ状況）には、行楽スポットの位置情報が挙げられ、ユーザ状況には、ユーザの自宅の住所や車の所有有無などが挙げられる。この際、推薦部２６０は、ユーザの自宅から行楽スポットまでの交通手段を加味した移動時間を正規化することで、状況属性：場所に係る受容度を算出してもよい。

　また、例えば、状況属性：日時の場合、スポット状況には、行楽スポットの営業時間や定休日が挙げられ、ユーザ状況には、当該行楽スポットへユーザが訪問を予定する日時が挙げられる。この際、推薦部２６０は、お出かけ日時に行楽スポットが営業しているか否かを判定し、状況属性：日時に係る受容度として１または０を設定してもよい。

　また、例えば、状況属性：気候の場合、スポット状況には、行楽スポットが屋内施設である、などの気候の影響に対する状況が挙げられ、ユーザ状況には、ユーザのお出かけ日時における当該行楽スポット周辺の天気が挙げられる。このように、本実施形態に係るユーザ状況とは、ユーザが享受し得る種々の状況が広く含まれてよい。この際、推薦部２６０は、気温や天候から屋内または屋外における行動の許容度合いを正規化することで、状況属性：気候に係る受容度を算出してもよい。

　また、例えば、状況属性：年齢の場合、スポット状況には、行楽スポットの対象年齢が挙げられ、ユーザ状況には、行楽スポットに出かける対象ユーザ（家族、同伴者を含む）の年齢が挙げられる。この際、推薦部２６０は、対象ユーザ全員の年齢が対象年齢を満たしているか否かを判定し、状況属性：年齢に係る受容度として１または０を設定してもよい。また、推薦部２６０は、対象ユーザのうち対象年齢を満たすユーザの割合に基づいて受容度を計算してもよい。

　また、例えば、状況属性：費用の場合、スポット状況には、行楽スポットの料金（入場料、宿泊料、割引などを含む）が挙げられ、ユーザ状況には、ユーザの予算が挙げられる。この際、推薦部２６０は、行楽スポットの料金がユーザの予算内に収まっているか否かを判定し、状況属性：費用に係る受容度として１または０を設定してもよい。

　また、例えば、状況属性：注目度の場合、スポット状況には、行楽スポットの人気、ランキング、新規オープンまたは新施設などの目新しさに係る状況が挙げられる。この際、推薦部２６０は、人気度やランキング順位、目新しさの度合いに係る線形和を正規化することで、状況属性：注目度に係る受容度を算出してもよい。

　また、例えば、状況属性：混雑の場合、スポット状況には、お出かけ日時における行楽スポットの混雑度が挙げられる。この際、推薦部２６０は、上記の混雑度を正規化することで、状況属性：混雑に係る受容度を算出してもよい。

　また、例えば、状況属性：カテゴリの場合、スポット状況には、行楽スポットが、海水浴場、観光農園球場など、季節に応じて注目度が変化するカテゴリであるか否かの状況が挙げられ、ユーザ状況にはお出かけ日時が挙げられる。この際、推薦部２６０は、季節に応じて注目度を正規化することで、状況属性：カテゴリに係る受容度を算出してもよい。

　また、例えば、状況属性：キーワードの場合、スポット状況には、桜、花火、紅葉、クリスマスなど、季節に応じて季節に応じて注目度が変化するキーワードに行楽スポットが関連しているか否かの状況が挙げられ、ユーザ状況にはお出かけ日時が挙げられる。この際、推薦部２６０は、季節に応じて注目度を正規化することで、状況属性：キーワードに係る受容度を算出してもよい。

　以上、本実施形態に係る状況属性について具体例を挙げて説明した。上述したように、本実施形態に係る推薦部２６０は、状況属性ごとのマッチング結果に基づく受容度に基づいて、行楽スポットに係る推薦結果を取得することが可能である。推薦部２６０が有する上記の機能によれば、行楽スポットに係る単純な推薦スコアに加え、日々変化するユーザの状況に応じたより柔軟かつ効果的な推薦情報をユーザに提示することが可能となる。

　一方、ユーザの嗜好などによっては、重視する状況属性が異なる場合も想定される。このために、本実施形態に係る推薦部２６０は、ユーザが重視する状況属性（状況理由、とも称する）に基づいて、当該状況属性に適用する重みを動的に設定することで、より精度の高い受容度スコアを算出することを可能とする。

　ここで、上記の重みとは、状況属性に対するユーザの重視度を示す値であり、受容度スコアの算出に用いられる。また、上記の状況理由とは、重みの増減に影響する理由、すなわちユーザの嗜好に該当する。

　本実施形態に係る推薦部２６０は、例えば、問い合わせに対するユーザの回答、ユーザの発話、また個人傾向などに基づいて、上記の状況理由を取得することが可能である。

　図９は、本実施形態に係る状況理由について説明するための図である。

　推薦部２６０は、例えば、ユーザに対するポジティブまたはネガティブな問い合わせに対するユーザの反応に基づいて、状況理由を取得することが可能である。具体的には、例えば、状況属性：場所に係る状況理由を取得する場合、推薦部２６０は、「車で３０分で行けますよ」（ポジティブ）や、「草津は遠いですか？」（ネガティブ）な問い合わせに対するユーザの反応結果に基づいて状況理由を取得してもよい。例えば、上記のポジティブな問い合わせに対しユーザが「いいね」と反応した場合や、上記のネガティブな問い合わせに対し、ユーザが「そうだね」と反応した場合、ユーザは状況属性：場所に係る重みに＋１．０を加算してもよい。

　また、例えば、推薦部２６０は、推薦情報を見たユーザが、「電車とバスで３時間は遠いな」とネガティブな発話を行ったことに基づいて、ユーザが状況属性：場所を重視することを把握することができる。この場合、推薦部２６０は、状況属性：場所に係る重みに＋１．０を加算してもよい。一方、ユーザが「近くていいね」などのポジティブな発話を行った場合、推薦部２６０は、状況属性：場所に係る重みに＋１．０を加算してもよい。

　また、例えば、推薦部２６０は、一般モデルとの差分に基づくユーザの個人傾向に基づいて状況理由を取得してもよい。推薦部２６０は、全ユーザの平均（一般モデル）から外れている状況属性をユーザの個人傾向とみなし、状況属性ごとに定められたルールに基づいて重みを加減算することができる。例えば、ユーザの自宅から行楽スポットまでの所要時間が一般モデルの平均より３０分以上短い場合、推薦部２６０は、状況属性：場所に係る重みに＋１．０を加算してもよい。

　以上説明したように、本実施形態に係る推薦部２６０によれば、日々変化するユーザの重視属性に基づいて重みを動的に設定することで、ユーザの状況や嗜好に応じたより精度の高い受容度スコアを算出することが可能となる。

　（履歴管理部２７０）
　本実施形態に係る履歴管理部２７０は、記憶部２２０が備えるユーザ履歴記憶部へのユーザ履歴の登録および更新などのデータ管理を行う。ユーザ履歴には、行動履歴として、スケジュール履歴情報、イベント発生履歴情報（モバイル機器と連携したユーザ行動の認識結果を反映してもよい）、操作履歴（検索履歴、閲覧履歴など）、ユーザ反応履歴などが含まれる。なお、上記のイベント発生履歴情報には、例えば、モバイル機器などと連携したユーザ行動の認識結果が反映されてもよい。例えば、モバイル機器から取得した位置情報やユーザがＳＮＳやメッセージアプリケーションで入力した文章や画像などから、スケジュールに登録した行楽スポットにユーザが実際に訪問したか否かを判定することが可能である。

　また、ユーザ反応履歴は、反応解析部２８０で解析された推薦情報に対するユーザ反応（詳細情報の閲覧、ブックマーク、予約、スケジュール登録、削除などの操作履歴、ユーザ発話）や、イベント体験に対するユーザ反応（評価など）であって、状況解析部２９０により解析されたユーザ状況やコンテンツ状況と共に蓄積されてもよい。

　ここで、図１０に、本実施形態に係るユーザ履歴（フィードバック）のデータ構造の一例を示す。図１０に示すように、ユーザ履歴は、ユーザＩＤ、フィードバックタイプ、アイテムＩＤ（行楽スポットＩＤなど）、属性ＩＤおよび属性ＩＤに対応する属性値などを含む。

　また、本実施形態に係るユーザ履歴には、上述した問い合わせや、当該問い合わせに対するユーザの回答、ユーザによる自発的な発話に対応するテキスト情報が含まれてよい。

　なお、フィードバックタイプには、図１０に示すように、お出かけ先（行楽スポット）のスケジュールへの登録（スケジュール履歴情報）、お出かけ先のウィッシュリストへの追加、お出かけ先へ実際に訪問したこと（イベント発生履歴情報）、お出かけ先の一覧画面や詳細画面の閲覧（ユーザ反応履歴）が挙げられる。

　また、本実施形態に係るフィードバックタイプには、問い合わせに対してユーザが回答したこと、状況理由に係るユーザの発話が検出されたこと、などが含まれてよい。

　（反応解析部２８０）
　反応解析部２８０は、例えば情報配信時（具体的には、例えばイベント推薦時）や行動認識時（具体的には、例えばイベント体験時）におけるユーザ反応（操作入力・選択、テキスト入力、発話、表情、生体反応など）を解析する。イベント体験時におけるユーザ反応は、例えば音声エージェント等によりユーザに評価を促す質問を行うことで取得してもよい。

　（状況解析部２９０）
　本実施形態に係る状況解析部２９０は、コンテンツ状況やユーザ状況を解析する機能を有する。上述したように、状況解析部２９０が解析する状況属性には、場所、日時、気候、年齢、費用、注目度、混雑、カテゴリ、キーワードなどが含まれてよい。一方、上記はあくまで一例であり、本実施形態に係る状況属性は係る例に限定されない。本実施形態に状況解析部２９０は、上記以外に係る状況属性を解析してもよいし、上記のすべてを解析しなくてもよい。

　（情報統合部３００）
　情報統合部３００は、各項絵師から得られる情報の受け渡しや、情報処理端末１０との情報通信を制御する。情報統合部３００は、例えば、情報収集部２４０が収集したスポット情報を情報解析部２５０に出力したり、情報解析部２５０が解析したスポット解析情報（コンテンツプロファイル）を推薦部２６０に出力する。また、情報統合部３００は、履歴管理部２７０が管理するユーザ履歴を推薦部２６０に出力する。また、情報統合部３００は、反応解析部２８０が得たユーザ反応および状況解析部２９０が得たスポット状況およびユーザ状況を、推薦部２６０に出力する。

　＜＜１．５．動作の流れ＞＞
　次に、本実施形態に係る情報処理サーバ２０の動作の流れについて詳細に説明する。

　まず、本実施形態に係る推薦スコアの算出の流れについて詳細に説明する。図１１は、本実施形態に係る推薦スコアの算出の流れを示すフローチャートである。

　図１１を参照すると、まず、情報解析部２５０が行楽スポットなどに係るスポット解析を実行するか否かを判定する（Ｓ１１０１）。

　ここで、解析を実行する場合（Ｓ１１０１：Ｙｅｓ）、情報解析部２５０は、情報収集部２４０が収集したスポットのメタデータやテキスト情報に基づいてコンテンツプロファイルを生成する（Ｓ１１０２）。

　次に、推薦部２６０が、推薦情報の提示を実行するか否かを判定する（Ｓ１１０３）。ここで、推薦情報の提示を行わない場合（Ｓ１１０３：Ｎｏ）、提示制御部２３０は、処理を終了する。

　一方、推薦情報の提示を実行する場合（Ｓ１１０３：Ｙｅｓ）、推薦部２６０は、履歴管理部２７０からユーザ履歴を取得する（Ｓ１１０４）。この際、ユーザ履歴に含まれる対象フィードバックタイプの対象スポットに係るコンテンツプロファイルが取得され、当該コンテンツプロファイルに基づいてユーザプリファレンスが取得される。なお、上記の対象フィードバックタイプは、複数選択されてもよく、また重み付けがなされてもよい。

　次に、推薦部２６０は、推薦条件の設定を行う（Ｓ１１０５）。上記の推薦条件には、例えば、上述したように、日時、期間、目的などが含まれる。

　次に、推薦部２６０は、ステップＳ１１０５において設定した推薦条件に基づいて、推薦スコアの算出を行う（Ｓ１１０６）。

　次に、推薦部２６０は、ステップＳ１１０６において算出した推薦スコア付きの推薦結果Ｒを保存する（Ｓ１１０７）。

　続いて、本実施形態に係る推薦スコアの算出について具体例を挙げて説明する。

　例えば、情報解析部２５０は、ステップＳ１１０２において下記のようなコンテンツプロファイルを生成する。
　スポット-A：
{温泉=1.0, 草津=1.0, 露天風呂=0.6, バイキング=0.4, マッサージ=0.2} [緯度=xxx, 経度=xxx, 人気=4.1, 大人料金=15,000円, 子供料金=10,000円]
　スポット-B：
{テーマパーク=1.0, 富士=1.0, サファリ=0.８, 体験=0.5, バス=0.3} [緯度=xxx, 経度=xxx, 人気=4.4, 大人料金=27,000円, 子供料金=1,500円]
　スポット-C：
{キャンプ場=1.0, 丹沢=1.0, ドッグラン=0.7, コテージ=0.5, パン=0.4} [緯度=xxx, 経度=xxx, 人気=3.6, 料金=4,000円]

　また、推薦部２６０は、ステップＳ１１０４において、下記のようなユーザ履歴を取得する。なお、ここでは、フィードバックタイプとしてスケジュール登録が行われたスポットに対する操作履歴を取得している。
　2015/05 「家族で旅行」-> 一泊, スポット-X：
{温泉=1.0, 熱海=1.0, 露天風呂=0.6, イタリアン=0.4, エステ=0.1} [緯度=xxx, 経度=xxx, 人気=3.8, 大人料金=12,000円, 子供料金=8,000]
　2016/05 「家族で旅行」-> 一泊, スポット-Y：
{温泉=1.0, 那須高原=1.0, コテージ=0.5, 和食=0.3, マッサージ=0.2} [緯度=xxx, 経度=xxx, 人気=4.2, 大人料金=16,000円, 子供料金=10,000]
　2016/11 「親子でお出かけ」-> 一泊, スポット-Z：
{キャンプ場=1.0, 南房総=1.0, 釣り=0.7, テント=0.3, ハイキング=0.2} [緯度=xxx, 経度=xxx, 人気=3.7, 料金=5,000円]

　また、推薦部２６０は、ステップＳ１１０５において、下記のような推薦条件を設定する。
　日時：2017/05/01=[春],  期間：[一泊], 目的：[家族で旅行]

　また、推薦部２６０は、ステップＳ１１０６において、下記のように推薦スコアを算出する。なお、下記におけるUPとは、ユーザプリファレンスを示す。
　UP [春] = スポット-X + スポット-Y：
{温泉=2.0, 熱海=1.0, 那須高原=1.0, 露天風呂=0.6, イタリアン=0.4, エステ=0.1, コテージ=0.5, 和食=0.3, マッサージ=0.2}
　UP[春]とスポット-A,B,C間でベクトルcos演算：
・UP-A：{1.0*2.0(温泉)+ 0.6*0.6(露天風呂)+ 0.2*0.2(マッサージ)} /{√(2.0^2+1.0^2+1.0^2+ 0.6^2+0.4^2+0.1^2+0.5^2+0.3^2+0.2^2)(UPノルム)*√(1.0^2+1.0^2+0.6^2+0.4^2+0.2^2)(Aノルム)} = 2.4 / {√6.91*√2.56} = 0.570
・UP-B：0.00 （共通メタデータなし）
・UP-C：{0.5*0.5(コテージ)/{√(2.0^2+1.0^2+1.0^2+ 0.6^2+0.4^2+0.1^2+0.5^2+0.3^2+0.2^2)(UPノルム)* √(1.0^2+1.0^2+0.7^2+0.5^2+0.4^2)(Cノルム)} = 0.25 / {√6.91*√2.9} = 0.055

　UP [一泊] = スポット-X + スポット-Y + スポットZ：
{温泉=2.0, キャンプ場=1.0, 熱海=1,0, 那須高原=1.0, 南房総=1.0, 露天風呂=0.6, イタリアン=0.4, エステ=0.1, コテージ=0.5, 和食=0.3, マッサージ=0.2, 釣り=0.7, テント=0.3, ハイキング=0.2}
UP[一泊]とスポットA,B,C間でベクトルcos演算：
・UP-A：{1.0*2.0(温泉)+ 0.6*0.6(露天風呂)+ 0.2*0.2(マッサージ)} /{√(2.0^2+1.0^2+1.0^2+1.0^2+1.0^2+
0.6^2+0.4^2+0.1^2+0.5^2+0.3^2+0.2^2+0.7^2+0.3^2+0.2^2)(UPノルム)*√(1.0^2+1.0^2+0.6^2+0.4^2+0.2^2)(Aノルム)} = 2.4 / {√9.53*√2.56} = 0.485
・UP-B：0.00 （共通メタデータなし）
・UP-C：{1.0*1.0(キャンプ場)+0.5*0.5(コテージ)/{√(2.0^2+1.0^2+1.0^2+1.0^2+1.0^2+ 0.6^2+0.4^2+0.1^2+0.5^2+0.3^2+0.2^2+0.7^2+0.3^2+0.2^2)(UPノルム)* √(1.0^2+1.0^2+0.7^2+0.5^2+0.4^2)(Cノルム)} =1.25 / {√9.53*√2.9} = 0.237

　UP [家族で旅行] = スポット-X + スポット-Y：
{温泉=2.0, 熱海=1.0, 那須高原=1.0, 露天風呂=0.6, イタリアン=0.4, エステ=0.1, コテージ=0.5, 和食=0.3, マッサージ=0.2}
UP[春]とスポットA,B,C間でベクトルcos演算：
・UP-A：{1.0*2.0(温泉)+ 0.6*0.6(露天風呂)+ 0.2*0.2(マッサージ)} /{√(2.0^2+1.0^2+1.0^2+ 0.6^2+0.4^2+0.1^2+0.5^2+0.3^2+0.2^2)(UPノルム)*√(1.0^2+1.0^2+0.6^2+0.4^2+0.2^2)(Aノルム)} = 2.4 / {√6.91*√2.56} = 0.570
・UP-B：0.00 （共通メタデータなし）
・UP-C：{0.5*0.5(コテージ)/{√(2.0^2+1.0^2+1.0^2+ 0.6^2+0.4^2+0.1^2+0.5^2+0.3^2+0.2^2)(UPノルム)* √(1.0^2+1.0^2+0.7^2+0.5^2+0.4^2)(Cノルム)} = 0.25 / {√6.91*√2.9} = 0.055

　以上の演算により、下記のような推薦スコアが算出される。
　UP-A[総合] = UP-A[春] + UP-A[一泊] + UP-A[家族で旅行] = 0.570+0.485+0.570 = 1.625
　UP-B[総合] = UP-B[春] + UP-B[一泊] + UP-B[家族で旅行] = 0.000+0.000+0.000 = 0.000
　UP-C[総合] = UP-C[春] + UP-C[一泊] + UP-C[家族で旅行] = 0.055+0.237+0.055 = 0.347

　なお、推薦部２６０は、算出した推薦スコアに基づいて対象スポットの絞り込みを行ってもよい。推薦部２６０は、例えば、人気=3.5未満のものは推薦結果から除外するなどの条件フィルタリングを行うことができる。

　次に、本実施形態に係るウィッシュリストに基づく推薦結果の取得の流れについて説明する。図１２は、本実施形態に係るウィッシュリストに基づく推薦結果の取得の流れを示すフローチャートである。

　図１２を参照すると、まず、推薦部２６０がユーザ履歴からウィッシュリストへの追加操作に係る履歴情報を取得する（Ｓ１２０１）。

　次に、推薦部２６０は、ステップＳ１２０１において取得した履歴情報に基づき、アイテムＩＤに該当するスポットを推薦結果Ｗに追加する（Ｓ１２０２）。

　次に、推薦部２６０は、ステップＳ１２０１において取得した履歴情報に基づき、カテゴリが一致するスポットを検索し、推薦結果Ｗに追加する（Ｓ１２０３）。

　次に、推薦部２６０は、ステップＳ１２０１において取得した履歴情報に基づき、キーワードが一致するスポットを検索し、推薦結果Ｗに追加する（Ｓ１２０４）。

　次に、推薦部２６０は、情報統合部３００にステップＳ１２０２～１２０４において生成した推薦結果Ｗを送信する（Ｓ１２０５）。

　続いて、本実施形態に係る受容度スコアの算出の流れについて詳細に説明する。本実施形態に係る推薦部２６０は、上述した属性状況ごとの受容度および重みを用いて、最終的な受容度スコアを算出することが可能である。

　この際、本実施形態に係る推薦部２６０は、上記受容度および重みを用いて算出した総合受容度、または過去に算出した総合受容度と新たに算出した総合受容度との差分を示す総合受容度差分のいずれかを最終的な受容度スコアとして用いてもよい。

　例えば、本実施形態に係る推薦部２６０は、受容度が変化した状況属性の数が閾値以上である場合、総合受容度差分を最終的な受容度スコアとして採用してもよい。推薦部２６０が有する上記の機能によれば、時間経過に伴い変化したユーザ状況により則した推薦情報をユーザに提示することが可能となる。

　図１３は、本実施形態に係る受容度スコアの算出の流れを示すフローチャートである。

　図１３を参照すると、まず、状況解析部２９０がユーザ状況を解析する（Ｓ１３０１）。

　次に、推薦部２６０が、上述した推薦結果ＲおよびＷを取得する（Ｓ１３０２）。

　続いて、推薦部２６０は、ユーザ履歴に基づいて状況理由を取得し、受容度スコアの算出に用いる状況属性ごとの重みを更新する（Ｓ１３０３）。上述したように、推薦部２６０は、問い合わせに対する回答、ユーザの発話、個人傾向などから状況理由を取得することが可能である。

　続いて、推薦部２６０は、状況属性ごとの受容度を算出する（Ｓ１３０４）。この際、推薦部２６０は、算出した新たな受容度の値と、前回に算出した受容度と差分の値とを保存する。

　次に、推薦部２６０は、前回と比較して受容度が変化した状況属性の数が閾値未満であるか否かを判定する（Ｓ１３０５）。なお、ユーザ状況に応じて受容度が変化する例としては、引っ越した、車を購入した、子供が産まれた、子供が対象年齢に達した、予算が増減した、などの種々の要因が想定される。

　ここで、受容度が変化した状況属性の数が閾値未満である場合（Ｓ１３０５：Ｙｅｓ）、推薦部２６０は、最終的な受容度スコアとして総合受容度を推薦結果ＲおよびＷに付与する（Ｓ１３０６）。

　一方、受容度が変化した状況属性の数が閾値以上である場合（Ｓ１３０５：Ｎｏ）、推薦部２６０は、最終的な受容度スコアとして総合受容度差分を推薦結果ＲおよびＷに付与する（Ｓ１３０７）。

　続いて、推薦部２６０は、推薦スコア、およびステップＳ１３０６またはＳ１３０７において採用した受容度スコア付きの推薦結果ＲおよびＷを情報統合部３００に送信する（１３０８）。

　以上、本実施形態に係る受容度スコアの算出の流れについて詳細に説明した。続いて、本実施形態に係る受容度スコア算出について具体例を挙げて説明する。図１４および図１５は、本実施形態に係る受容度スコア算出の具体例を示す図である。

　図１４には、前回の算出時におけるスポット状況とユーザ状況、および状況属性ごとの受容度の一例が示されている。ここで、すべての状況属性に係る重みを1.0とした場合、前回における総合受容度は、下記のように算出することができる。
　総合受容度= 0.4 * 1.0 + 1.0 * 1.0 + 1.0 * 1.0 + 0.0 * 1.0 + 1.0 * 1.0 + 0.82 *
1.0 + 0.3 * 1.0 +0.0 * 1.0 + 1.0 * 1.0 = +5.52

また、図１５には、今回の算出時におけるスポット状況とユーザ状況、および状況属性ごとの受容度の一例が示されている。ここで、すべての状況属性に係る重みを1.0とした場合、今回における総合受容度は、下記のように算出することができる。
　総合受容度 = 0.6 * 3.0 + 1.0 * 1.0 + 0.0 * 2.0 + 1.0 * 2.0 + 1.0 * 2.0 + 0.88
* 2.0 + 0.15 * 1.0 + 0.0 * 1.0 + 0.0 * 1.0 = +8.71

　ここで、図１４および図１５を比較すると、ユーザ状況における状況属性：場所および状況属性：年齢が変化したことにより、該当する受容度が変化していることがわかる。

　具体的には、ユーザＸが車を所有したことにより、状況属性：場所に係る受容度が0.6(+0.2)に変化し、また、ユーザの子供が小学生になったことにより、状況属性：年齢に係る受容度が1.0(+1.0)に変化している。

　ここで、受容度スコアの採用における変化属性数の閾値が２である場合、状況属性：場所および状況属性：年齢の２つが変化していること、すなわち変化属性数が閾値以上であることから、推薦部２６０は、最終的な受容度スコアとして総合受容度差分（8.71 - 5.52 = 3.19）を採用してよい。

　このように、本実施形態に係る推薦部２６０によれば、変化した状況属性の影響度をより反映した受容度スコアを算出することができ、ユーザの状況変化に対応した柔軟かつ効果的な推薦情報の提示を実現することが可能となる。

　次に、本実施形態に係る推薦情報の提示と状況理由に係るユーザ履歴の取得の流れについて詳細に説明する。図１６は、本実施形態に係る推薦情報の提示と状況理由に係るユーザ履歴の取得の流れを示すフローチャートである。

　図１６を参照すると、まず推薦部２６０が、推薦情報を提示するか否かを判定する（Ｓ１４０１）。この際、推薦部２６０は、例えば、ユーザセッションやシステム時間、およびユーザ状況の変化に基づいて提示要否を判定してもよい。

　ここで、上記のユーザセッションには、例えば、ユーザのシステムログイン、ユーザによるシステムへの問い合わせ、システムによるユーザの認識などが含まれる。推薦部２６０は、例えば、上記のいずれかが検出された場合、推薦情報を提示すると判定してもよい。

　また、上記のシステム時間には、定時配信やスポット情報の更新、キャンペーンの開始検出などが含まれる。

　また、上記のユーザ状況の変化には、例えば、家族の追加（出産、結婚など）、子供の成長（就学、成人、習い事の開始など）、移動手段の変化（車の所有、鉄道の開通など）、が含まれる。この際、本実施形態に係る推薦部２６０は、特に受容度スコアの低下要因である状況属性の変化に基づいて、推薦情報の提示要否を判定してよい。

　より具体的には、本実施形態に係る推薦部２６０は、低下要因であった状況属性の変化により、当該状況属性に係る受容度が改善したことに基づいて、推薦情報を提示すると判定してもよい。上記の状況には、例えば、前回は子供が対象年齢に達していなかった、前回はまだ車を所有していなかった、などの例が想定される。

　このように、本実施形態に係る推薦部２６０によれば、低下要因が解消されたタイミングでユーザに推薦情報を提示することで、より効果的な推薦を実現することが可能となる。

　ステップＳ１４０１において、推薦情報の提示を行うと判定した場合（Ｓ１４０１：Ｙｅｓ）、推薦部２６０は、推薦情報の提示に係る提示ロジックを選択する（Ｓ１４０２）。推薦部２６０は、例えば、推薦結果ＲまたはＷのいずれか、あるいは両方を提示するか、などの提示ロジックを選択してもよい。

　続いて、情報統合部３００は、ステップＳ１４０１において選択された提示ロジックに基づいて、対象スポットの上位Ｎ件を情報処理端末１０に提示させる（Ｓ１４０３）。

　続いて、システム発話による状況取得を行う場合（Ｓ１４０４：Ｙｅｓ）、推薦部２６０が提示スポットに対するユーザ履歴を取得し（Ｓ１４０５）、上述したようなユーザに対するポジティブまたはネガティブな問い合わせが実行される（Ｓ１４０６）。

　続いて、推薦部２６０が、ステップＳ１４０６において実行された問い合わせに対するユーザの回答から状況理由を取得する（Ｓ１４０７）。

　また、ユーザの発話に基づく状況理由を取得する場合（Ｓ１４０８：Ｙｅｓ）、推薦部２６０は、反応解析部２８０が行った音声認識の結果に基づいて、ユーザの発話意図から状況理由を抽出する（Ｓ１４０８）。

　以上、本実施形態に係る情報処理サーバ２０の動作の流れについて説明した。図１７は、上記の流れにより提示される推薦情報の一例である。図１７には、情報処理端末１０の表示部１１０に表示されるユーザインタフェースＵＩの一例である。

　図１７に示すように、本実施形態に係るユーザインタフェースＵＩは、推薦スコアおよびユーザ状況に係る受容度スコアに基づいて決定された推薦スポットがランキング形式で表示されてもよい。この際、情報統合部３００は、例えば、解消された低下要因である属性状況に係る情報を強調して表示部１１０に表示させてもよい。

　図１７に示す一例の場合、情報統合部３００は、「小学生もＯＫ」、「車で２時間以内」などの文言を含む視覚情報を表示部１１０に表示させている。上記の制御によれば、状況が変化したことにより、過去には採用できなかった選択肢が広がったことを明確に伝えることができ、より効果の高い推薦情報の提示を実現することが可能となる。

　＜＜１．６．ユーザ個人またはユーザグループへの推薦＞＞
　次に、本実施形態に係るユーザの定義について今一度説明する。上述したように、本実施形態に係るユーザには、ユーザ個人および当該ユーザが属するユーザグループの両方が含まれてよい。

　例えば、ユーザ個人が家庭における妻である場合、ユーザ個人が自身のために望む情報と、ユーザグループすなわち家族のために望む情報とには、差異があることが想定される。このため、本実施形態に係る推薦部２６０は、ユーザ個人またはユーザグループのいずれかを対象に受容度スコアの算出を行い推薦スポットを順位を決定してよい。

　図１８は、本実施形態に係るユーザ個人またはユーザグループに対する推薦情報の提示について説明するための図である。

　図１８の上段には、情報処理サーバ２０が情報処理端末１０を介してユーザグループＧ１に対する推薦情報の提示を行う場合の一例が示されている。図１８の上段に示す一例では、情報処理サーバ２０は、家族全体を含むユーザグループＧ１に対し、音声発話ＳＯ２によりＡＢＣモールに係る推薦情報を提示している。ここで、ユーザグループＧ１は、妻であるユーザＵ１、夫であるユーザＵ２、および子供であるユーザＵ３から構成される家族であってもよい。

　この際、本実施形態に係る推薦部２６０は、ユーザ個人と同様に、ユーザグループＧ１に対し個別のＩＤを付与し、家族単位のユーザとしてユーザプリファレンスやユーザ履歴、重みなどを管理してもよい。

　一方、本実施形態に係る推薦部２６０は、ユーザグループＧ１に係るユーザプリファレンスやユーザ履歴、重みなどをユーザグループＧ１を構成するユーザ個人（ユーザＵ１～Ｕ３）の組み合わせにより計算することも可能である。

　推薦部２６０は、例えば、ユーザＵ１～Ｕ３に係るユーザ履歴の和からユーザプリファレンスや状況属性に係る重みなどを算出し、最終的な受容度スコアや推薦スコアを算出することが可能である。

　推薦部２６０が有する上記の機能によれば、家族内においても複数のユーザグループを柔軟に定義することができ、例えば、家族全体、夫婦、母子、父子などで異なる推薦情報を提示することが可能となる。

　一方、図１８の下段には、情報処理サーバ２０が情報処理端末１０を介してユーザＵ１個人に対する推薦情報の提示を行う場合の一例が示されている。図１８の下段に示す一例では、情報処理サーバ２０は、ユーザＵ１個人に対し、音声発話ＳＯ３によりスパに係る推薦情報を提示している。

　情報処理サーバ２０は、例えば、周囲にユーザＵ１のみが存在することを認識した場合や、ユーザＵ２およびＵ３には他のスケジュールが登録されていることなどに基づいて、ユーザＵ１個人に対する推薦情報の提示を制御してもよい。

　このように、本実施形態に係る情報処理サーバ２０によれば、ユーザ個人およびユーザグループの両方に対応した多様の推薦情報の提示を実現することが可能である。

　＜２．ハードウェア構成例＞
　次に、本開示の一実施形態に係る情報処理端末１０および情報処理サーバ２０に共通するハードウェア構成例について説明する。図１９は、本開示の一実施形態に係る情報処理端末１０および情報処理サーバ２０のハードウェア構成例を示すブロック図である。図１９を参照すると、情報処理端末１０および情報処理サーバ２０は、例えば、ＣＰＵ８７１と、ＲＯＭ８７２と、ＲＡＭ８７３と、ホストバス８７４と、ブリッジ８７５と、外部バス８７６と、インターフェース８７７と、入力装置８７８と、出力装置８７９と、ストレージ８８０と、ドライブ８８１と、接続ポート８８２と、通信装置８８３と、を有する。なお、ここで示すハードウェア構成は一例であり、構成要素の一部が省略されてもよい。また、ここで示される構成要素以外の構成要素をさらに含んでもよい。

　（ＣＰＵ８７１）
　ＣＰＵ８７１は、例えば、演算処理装置又は制御装置として機能し、ＲＯＭ８７２、ＲＡＭ８７３、ストレージ８８０、又はリムーバブル記録媒体９０１に記録された各種プログラムに基づいて各構成要素の動作全般又はその一部を制御する。

　（ＲＯＭ８７２、ＲＡＭ８７３）
　ＲＯＭ８７２は、ＣＰＵ８７１に読み込まれるプログラムや演算に用いるデータ等を格納する手段である。ＲＡＭ８７３には、例えば、ＣＰＵ８７１に読み込まれるプログラムや、そのプログラムを実行する際に適宜変化する各種パラメータ等が一時的又は永続的に格納される。

　（ホストバス８７４、ブリッジ８７５、外部バス８７６、インターフェース８７７）
　ＣＰＵ８７１、ＲＯＭ８７２、ＲＡＭ８７３は、例えば、高速なデータ伝送が可能なホストバス８７４を介して相互に接続される。一方、ホストバス８７４は、例えば、ブリッジ８７５を介して比較的データ伝送速度が低速な外部バス８７６に接続される。また、外部バス８７６は、インターフェース８７７を介して種々の構成要素と接続される。

　（入力装置８７８）
　入力装置８７８には、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチ、及びレバー等が用いられる。さらに、入力装置８７８としては、赤外線やその他の電波を利用して制御信号を送信することが可能なリモートコントローラ（以下、リモコン）が用いられることもある。また、入力装置８７８には、マイクロフォンなどの音声入力装置が含まれる。

　（出力装置８７９）
　出力装置８７９は、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ　Ｒａｙ　Ｔｕｂｅ）、ＬＣＤ、又は有機ＥＬ等のディスプレイ装置、スピーカ、ヘッドホン等のオーディオ出力装置、プリンタ、携帯電話、又はファクシミリ等、取得した情報を利用者に対して視覚的又は聴覚的に通知することが可能な装置である。また、本開示に係る出力装置８７９は、触覚刺激を出力することが可能な種々の振動デバイスを含む。

　（ストレージ８８０）
　ストレージ８８０は、各種のデータを格納するための装置である。ストレージ８８０としては、例えば、ハードディスクドライブ（ＨＤＤ）等の磁気記憶デバイス、半導体記憶デバイス、光記憶デバイス、又は光磁気記憶デバイス等が用いられる。

　（ドライブ８８１）
　ドライブ８８１は、例えば、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリ等のリムーバブル記録媒体９０１に記録された情報を読み出し、又はリムーバブル記録媒体９０１に情報を書き込む装置である。

　（リムーバブル記録媒体９０１）
リムーバブル記録媒体９０１は、例えば、ＤＶＤメディア、Ｂｌｕ－ｒａｙ（登録商標）メディア、ＨＤ　ＤＶＤメディア、各種の半導体記憶メディア等である。もちろん、リムーバブル記録媒体９０１は、例えば、非接触型ＩＣチップを搭載したＩＣカード、又は電子機器等であってもよい。

　（接続ポート８８２）
　接続ポート８８２は、例えば、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）ポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ（Ｓｍａｌｌ　Ｃｏｍｐｕｔｅｒ　Ｓｙｓｔｅｍ　Ｉｎｔｅｒｆａｃｅ）、ＲＳ－２３２Ｃポート、又は光オーディオ端子等のような外部接続機器９０２を接続するためのポートである。

　（外部接続機器９０２）
　外部接続機器９０２は、例えば、プリンタ、携帯音楽プレーヤ、デジタルカメラ、デジタルビデオカメラ、又はＩＣレコーダ等である。

　（通信装置８８３）
　通信装置８８３は、ネットワークに接続するための通信デバイスであり、例えば、有線又は無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、又はＷＵＳＢ（Ｗｉｒｅｌｅｓｓ　ＵＳＢ）用の通信カード、光通信用のルータ、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ　Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ）用のルータ、又は各種通信用のモデム等である。

　＜３．まとめ＞
　以上説明したように、本開示の一実施形態に係る情報処理サーバ２０は、コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御する提示制御部２３０を備える。また、提示制御部２３０は、コンテンツに係るコンテンツ状況とユーザに係るユーザ状況とのマッチングにより算出した受容度スコアにさらに基づいて、推薦情報の提示を制御すること、を特徴の一つとする。係る構成によれば、ユーザの状態に適したタイミングでより有益な推薦情報を提示することが可能となる。

　以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

　また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

　また、本明細書の情報処理サーバ２０の処理に係る各ステップは、必ずしもフローチャートに記載された順序に沿って時系列に処理される必要はない。例えば、情報処理サーバ２０の処理に係る各ステップは、フローチャートに記載された順序と異なる順序で処理されても、並列的に処理されてもよい。

　なお、以下のような構成も本開示の技術的範囲に属する。
（１）
　コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御する提示制御部、
　を備え、
　前記提示制御部は、前記コンテンツに係るコンテンツ状況と前記ユーザに係るユーザ状況とのマッチングにより算出した受容度スコアにさらに基づいて、前記推薦情報の提示を制御する、
情報処理装置。
（２）
　前記提示制御部は、前記コンテンツ状況および前記ユーザ状況が含む状況属性ごとの受容度を算出し、前記状況属性ごとの受容度に基づいて前記受容度スコアを算出する、
前記（１）に記載の情報処理装置。
（３）
　前記提示制御部は、前記状況属性ごとの受容度、およびユーザ履歴から得た状況理由に基づいて動的に設定した重みを用いて、前記受容度スコアを算出する、
前記（２）に記載の情報処理装置。
（４）
　前記提示制御部は、前記受容度および前記重みを用いて算出した総合受容度、または過去に算出した前記総合受容度と新たに算出した前記総合受容度との差分を示す総合受容度差分のいずれかを前記受容度スコアとして用いる、
前記（３）に記載の情報処理装置。
（５）
　前記提示制御部は、前記受容度が変化した前記状況属性に基づいて、前記総合受容度または前記総合受容度差分のいずれかを前記受容度スコアとして選択する、
前記（４）に記載の情報処理装置。
（６）
　前記提示制御部は、前記受容度が変化した前記状況属性の数が閾値以上である場合、前記総合受容度差分を前記受容度スコアとして採用する、
前記（４）または（５）に記載の情報処理装置。
（７）
　前記提示制御部は、前記受容度スコアの低下要因である前記状況属性の変化に基づいて、前記推薦情報を提示させる、
前記（２）～（６）のいずれかに記載の情報処理装置。
（８）
　前記提示制御部は、前記低下要因である前記状況属性の変化により当該状況属性に係る前記受容度が改善したことに基づいて、前記推薦情報を提示させる、
前記（７）に記載の情報処理装置。
（９）
　前記提示制御部は、前記ユーザの発話に基づいて前記状況理由を取得する、
前記（３）～（６）のいずれかに記載の情報処理装置。
（１０）
　前記提示制御部は、問い合わせに対する前記ユーザの回答に基づいて前記状況理由を取得する、
前記（３）～（６）のいずれかに記載の情報処理装置。
（１１）
　前記提示制御部は、一般モデルとの差分に基づく前記ユーザの個人傾向に基づいて、前記状況理由を取得する、
前記（３）～（６）のいずれかに記載の情報処理装置。
（１２）
　前記ユーザは、ユーザ個人および当該ユーザが属するユーザグループを含み、
　前記提示制御部は、前記ユーザ個人または前記ユーザグループのいずれかを対象に前記受容度スコアを算出する、
前記（１）～（１１）のいずれかに記載の情報処理装置。
（１３）
　前記提示制御部は、前記ユーザグループを構成する前記ユーザ個人に係るユーザ履歴に基づいて、前記前記受容度スコアを算出する、
前記（１２）に記載の情報処理装置。
情報処理装置。
（１４）
　前記コンテンツは、行楽スポットを含む、
前記（１）～（１３）のいずれかに記載の情報処理装置。
（１５）
　前記提示制御部は、分析したユーザプリファレンスとコンテンツプロファイルとに基づいて、前記推薦スコアを算出する、
前記（１）～（１４）のいずれかに記載の情報処理装置。
（１６）
　前記提示制御部による制御に基づいて前記ユーザに対し前記推薦情報を提示する提示部、
　をさらに備える、
前記（１）～（１５）のいずれかに記載の情報処理装置。
（１７）
　プロセッサが、コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御すること、
　を含み、
　前記提示を制御することは、前記コンテンツに係るコンテンツ状況と前記ユーザに係るユーザ状況とのマッチングにより算出した受容度スコアに基づいて、前記推薦情報の提示を制御すること、
　をさらに含む、
情報処理方法。
（１８）
　コンピュータを、
　コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御する提示制御部、
　を備え、
　前記提示制御部は、前記コンテンツに係るコンテンツ状況と前記ユーザに係るユーザ状況とのマッチングにより算出した受容度スコアにさらに基づいて、前記推薦情報の提示を制御する、
　情報処理装置、
として機能させるためのプログラム。

　２０　　　情報処理サーバ
　２１０　　端末通信部
　２２０　　記憶部
　２３０　　提示制御部
　２４０　　情報収集部
　２５０　　情報解析部
　２６０　　推薦部
　２７０　　履歴管理部
　２８０　　反応解析部
　２９０　　状況解析部
　３００　　情報統合部

Claims (18)

1. 　コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御する提示制御部、
   　を備え、
   　前記提示制御部は、前記コンテンツに係るコンテンツ状況と前記ユーザに係るユーザ状況とのマッチングにより算出した受容度スコアにさらに基づいて、前記推薦情報の提示を制御する、
   情報処理装置。
2. 　前記提示制御部は、前記コンテンツ状況および前記ユーザ状況が含む状況属性ごとの受容度を算出し、前記状況属性ごとの受容度に基づいて前記受容度スコアを算出する、
   請求項１に記載の情報処理装置。
3. 　前記提示制御部は、前記状況属性ごとの受容度、およびユーザ履歴から得た状況理由に基づいて動的に設定した重みを用いて、前記受容度スコアを算出する、
   請求項２に記載の情報処理装置。
4. 　前記提示制御部は、前記受容度および前記重みを用いて算出した総合受容度、または過去に算出した前記総合受容度と新たに算出した前記総合受容度との差分を示す総合受容度差分のいずれかを前記受容度スコアとして用いる、
   請求項３に記載の情報処理装置。
5. 　前記提示制御部は、前記受容度が変化した前記状況属性に基づいて、前記総合受容度または前記総合受容度差分のいずれかを前記受容度スコアとして選択する、
   請求項４に記載の情報処理装置。
6. 　前記提示制御部は、前記受容度が変化した前記状況属性の数が閾値以上である場合、前記総合受容度差分を前記受容度スコアとして採用する、
   請求項４に記載の情報処理装置。
7. 　前記提示制御部は、前記受容度スコアの低下要因である前記状況属性の変化に基づいて、前記推薦情報を提示させる、
   請求項２に記載の情報処理装置。
8. 　前記提示制御部は、前記低下要因である前記状況属性の変化により当該状況属性に係る前記受容度が改善したことに基づいて、前記推薦情報を提示させる、
   請求項７に記載の情報処理装置。
9. 　前記提示制御部は、前記ユーザの発話に基づいて前記状況理由を取得する、
   請求項３に記載の情報処理装置。
10. 　前記提示制御部は、問い合わせに対する前記ユーザの回答に基づいて前記状況理由を取得する、
    請求項３に記載の情報処理装置。
11. 　前記提示制御部は、一般モデルとの差分に基づく前記ユーザの個人傾向に基づいて、前記状況理由を取得する、
    請求項３に記載の情報処理装置。
12. 　前記ユーザは、ユーザ個人および当該ユーザが属するユーザグループを含み、
    　前記提示制御部は、前記ユーザ個人または前記ユーザグループのいずれかを対象に前記受容度スコアを算出する、
    請求項１に記載の情報処理装置。
13. 　前記提示制御部は、前記ユーザグループを構成する前記ユーザ個人に係るユーザ履歴に基づいて、前記前記受容度スコアを算出する、
    請求項１２に記載の情報処理装置。
    情報処理装置。
14. 　前記コンテンツは、行楽スポットを含む、
    請求項１に記載の情報処理装置。
15. 　前記提示制御部は、分析したユーザプリファレンスとコンテンツプロファイルとに基づいて、前記推薦スコアを算出する、
    請求項１に記載の情報処理装置。
16. 　前記提示制御部による制御に基づいて前記ユーザに対し前記推薦情報を提示する提示部、
    　をさらに備える、
    請求項１に記載の情報処理装置。
17. 　プロセッサが、コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御すること、
    　を含み、
    　前記提示を制御することは、前記コンテンツに係るコンテンツ状況と前記ユーザに係るユーザ状況とのマッチングにより算出した受容度スコアに基づいて、前記推薦情報の提示を制御すること、
    　をさらに含む、
    情報処理方法。
18. 　コンピュータを、
    　コンテンツに係る推薦スコアに基づいてユーザに対する推薦情報の提示を制御する提示制御部、
    　を備え、
    　前記提示制御部は、前記コンテンツに係るコンテンツ状況と前記ユーザに係るユーザ状況とのマッチングにより算出した受容度スコアにさらに基づいて、前記推薦情報の提示を制御する、
    　情報処理装置、
    として機能させるためのプログラム。

Images