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

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6947191

(24)【登録日】2021年9月21日

(45)【発行日】2021年10月13日

(54)【発明の名称】情報処理装置、情報処理方法、およびプログラム

(51)【国際特許分類】

   G06Q 10/10 20120101AFI20210930BHJP

   G06F 16/9035 20190101ALI20210930BHJP

【ＦＩ】

   G06Q10/10 340

   G06F16/9035

【請求項の数】12

【全頁数】23

(21)【出願番号】特願2018-565930(P2018-565930)

(86)(22)【出願日】2017年10月19日

(86)【国際出願番号】JP2017037874

(87)【国際公開番号】WO2018142685

(87)【国際公開日】20180809

【審査請求日】2020年7月13日

(31)【優先権主張番号】特願2017-15709(P2017-15709)

(32)【優先日】2017年1月31日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】000002185

【氏名又は名称】ソニーグループ株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】宮嵜 充弘

(72)【発明者】

【氏名】八重田 寿理

(72)【発明者】

【氏名】斎藤 真里

(72)【発明者】

【氏名】桐原 麗子

【審査官】 牧 裕子

(56)【参考文献】

【文献】 特開２０１１−１４１８４０（ＪＰ，Ａ）

【文献】 特開２０１５−０６６０２９（ＪＰ，Ａ）

【文献】 特開２０１２−１６８６１４（ＪＰ，Ａ）

【文献】 特開２０１５−０１１４３１（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

Ｇ１６Ｈ １０／００ − ８０／００

Ｇ０６Ｆ １６／９０３５

(57)【特許請求の範囲】

【請求項1】

ユーザの行動履歴に基づいて、将来発生するイベントを予測し、
前記ユーザの行動履歴に基づいて、前記予測したイベントの目的に応じて前記ユーザの準備期間を算出し、前記予測したイベントの発生時期から前記準備期間を差し引いて、当該予測したイベントのスケジュール登録を促す通知のタイミングを決定するイベント推薦制御部を備え、
前記ユーザの行動履歴には、イベント発生履歴とスケジュール履歴が含まれ、
前記イベント推薦制御部は、
前記イベント発生履歴に基づく過去のイベントの発生日と、それぞれに対応するスケジュール登録日との差分に基づいて、イベントの目的に応じた準備期間を算出する、
情報処理装置。

【請求項2】

前記ユーザの行動履歴には、ユーザによるイベントに関する情報の検索履歴が含まれ、
前記イベント推薦制御部は、
前記イベント発生履歴に基づく過去のイベントの発生日と、それぞれに対応する検索日との差分をさらに考慮して、前記イベントの目的別の準備期間を算出する、請求項１に記載の情報処理装置。

【請求項3】

前記イベント推薦制御部は、
前記予測したイベントにおけるスポットのジャンルに応じて前記準備期間を算出する、請求項１に記載の情報処理装置。

【請求項4】

前記イベント推薦制御部は、前記予測したイベントにおけるスポットの人気をさらに考慮して前記準備期間を算出する、請求項３に記載の情報処理装置。

【請求項5】

前記イベント推薦制御部は、前記予測したイベントが発生する時期または季節をさらに考慮して前記準備期間を算出する、請求項３に記載の情報処理装置。

【請求項6】

前記イベント推薦制御部は、
前記ユーザの行動履歴に基づく前記ユーザの習慣に応じて、将来発生するイベントを予測する、請求項１に記載の情報処理装置。

【請求項7】

前記イベント推薦制御部は、
前記ユーザの好みに応じて、前記予測したイベントにおけるスポットの候補を選定する、請求項６に記載の情報処理装置。

【請求項8】

前記イベント推薦制御部は、
さらに前記ユーザの家族構成に応じて、前記スポットの候補を選定する、請求項７に記載の情報処理装置。

【請求項9】

前記情報処理装置は、
前記決定した通知タイミングで、前記予測したイベントのスケジュール登録を促す通知をユーザに行う通知制御部をさらに備える、請求項１に記載の情報処理装置。

【請求項10】

前記通知制御部は、
前記ユーザに通知したイベントにおけるスポットの状況が変化した場合、前記ユーザに再度通知を行うよう制御する、請求項９に記載の情報処理装置。

【請求項11】

プロセッサが、
ユーザの行動履歴に基づいて、将来発生するイベントを予測することと、
前記ユーザの行動履歴に基づいて、前記予測したイベントの目的に応じて前記ユーザの準備期間を算出し、前記予測したイベントの発生時期から前記準備期間を差し引いて、当該予測したイベントのスケジュール登録を促す通知のタイミングを決定することと、を含み、
前記ユーザの行動履歴には、イベント発生履歴とスケジュール履歴が含まれ、
前記イベント発生履歴に基づく過去のイベントの発生日と、それぞれに対応するスケジュール登録日との差分に基づいて、イベントの目的に応じた準備期間を算出することと、
を含む、情報処理方法。

【請求項12】

コンピュータを、
ユーザの行動履歴に基づいて、将来発生するイベントを予測し、
前記ユーザの行動履歴に基づいて、前記予測したイベントの目的に応じて前記ユーザの準備期間を算出し、前記予測したイベントの発生時期から前記準備期間を差し引いて、当該予測したイベントのスケジュール登録を促す通知のタイミングを決定するイベント推薦制御部として機能させるためのプログラムであって、
前記ユーザの行動履歴には、イベント発生履歴とスケジュール履歴が含まれ、
前記イベント推薦制御部は、
前記イベント発生履歴に基づく過去のイベントの発生日と、それぞれに対応するスケジュール登録日との差分に基づいて、イベントの目的に応じた準備期間を算出する、
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

従来、ユーザの嗜好に応じた情報提示、推薦技術が提案されている。

【0003】

例えば下記特許文献１では、ユーザのアクティビティ（Ｗｅｂブラウジングやネットワーク経由でのコンテンツの利用、放送番組の視聴、録画等）から非明示的嗜好情報を登録し、非明示的嗜好情報に基づいてユーザに質問を音声出力し、得た回答から明示的嗜好情報を登録することが開示されている。また、特許文献１には、このように取得した明示的嗜好情報を用いて番組推薦を行うことが記載されている。番組推薦の方法は、推薦する番組に自動的にチャンネルを設定させる方法か、現在時刻よりも所定の時間以内に放送される番組の推薦情報を表示する方法が挙げられ、ユーザの設定によって決定される。

【0004】

また、近年実用化されているパーソナルアシストは、端末内のカレンダー情報、スケジュール情報、および現在位置情報といった複数の情報に基づいて、ユーザの現在の行動に応じて必要な情報（今日のスケジュール、目的地までの移動時間、周辺スポット、次の便の出発時刻等）を提示することが可能である。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０１５−３５１４０号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかしながら、予定を立てるタイミングは個人によって異なるものであるため、ユーザの嗜好に応じたスポット情報を推薦しても、推薦したタイミングがユーザの行動決定タイミングに合わない場合は推薦情報が十分に活用されないという状況が生じていた。

【0007】

そこで、本開示では、ユーザに適したタイミングでスケジュール登録を促す通知を行うことが可能な情報処理装置、情報処理方法、およびプログラムを提案する。

【課題を解決するための手段】

【0008】

本開示によれば、ユーザの行動履歴に基づいて、将来発生するイベントを予測し、前記予測したイベントのユーザの準備期間を考慮し、当該予測したイベントのスケジュール登録を促す通知のタイミングを決定するイベント推薦制御部を備える、情報処理装置を提案する。

【0009】

本開示によれば、プロセッサが、ユーザの行動履歴に基づいて、将来発生するイベントを予測することと、前記予測したイベントのユーザの準備期間を考慮し、当該予測したイベントのスケジュール登録を促す通知のタイミングを決定することと、を含む、情報処理方法を提案する。

【0010】

本開示によれば、コンピュータを、ユーザの行動履歴に基づいて、将来発生するイベントを予測し、前記予測したイベントのユーザの準備期間を考慮し、当該予測したイベントのスケジュール登録を促す通知のタイミングを決定するイベント推薦制御部として機能させるための、プログラムを提案する。

【発明の効果】

【0011】

以上説明したように本開示によれば、ユーザに適したタイミングでスケジュール登録を促す通知を行うことが可能となる。

【0012】

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

【図面の簡単な説明】

【0013】

【図1】本開示の一実施形態による情報処理システムの概要について説明する図である。

【図2】本実施形態による情報配信端末の構成の一例を示すブロック図である。

【図3】本実施形態によるサーバのハードウェア構成の一例を示すブロック図である。

【図4】本実施形態によるサーバの制御部および記憶部の機能構成の一例を示すブロック図である。

【図5】本実施形態によるスポットのデータ構造の一例を示す図である。

【図6】本実施形態によるスポットのデータ構造の一例を示す図である。

【図7】本実施形態によるユーザ履歴記憶部に記憶されるユーザ履歴（フィードバック）のデータ構造の一例を示す図である。

【図8】本実施形態によるイベント通知の一例について説明する図である。

【図9】本実施形態によるイベント推薦通知の表示画面例を示す図である。

【図10】本実施形態によるイベントにおけるスポット推薦情報の生成処理を示すフローチャートである。

【図11】本実施形態によるイベント推薦通知処理を示すフローチャートである。

【発明を実施するための形態】

【0014】

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

【0015】

また、説明は以下の順序で行うものとする。
１．本開示の一実施形態による情報処理システムの概要
２．構成
２−１．情報配信端末の構成
２−２．サーバの構成
３．動作処理
３−１．スポット推薦処理
３−２．推薦イベント通知処理
４．補足
５．まとめ

【0016】

＜＜１．本開示の一実施形態による情報処理システムの概要＞＞
図１は、本開示の一実施形態による情報処理システムの概要について説明する図である。図１に示すように、本実施形態による情報処理システムは、ユーザに推薦情報を提示する情報配信端末１と、スポット情報の解析やイベント推薦制御を行うサーバ２とを含む。情報配信端末１とサーバ２は、ネットワーク３を介して接続され、データの送受信が行われ得る。なお、ここでは一例としてクライアントサーバシステムを用いているが、本実施形態はこれに限定されない。

【0017】

情報配信端末１は、ユーザがスポット、イベント、およびスケジュールに関する情報を閲覧、操作することのできる情報処理端末であって、ＣＥ機器（Ｃｏｎｓｕｍｅｒ Ｅｌｅｃｔｒｏｎｉｃｓ機器）や、スマートフォン、タブレット端末、携帯電話端末、ウェアラブル端末、音声エージェント装置等が想定される。音声エージェント装置としては、例えばホームエージェント等、家族（特定のユーザグループ）により利用されるものが想定される。音声エージェント装置は、家族のスケジュール管理や、ニュースや天気予報の提供、情報検索等の機能を有する。

【0018】

サーバ２は、ユーザの行動履歴や行楽スポットの解析情報を参照し、ユーザの嗜好や習慣に基づいて家族旅行等のイベントの推薦を行い、ユーザに適したタイミングで情報配信端末１からユーザに通知（イベントの準備を行うことを促す通知）するよう制御することが可能である。

【0019】

このような本実施形態による情報処理システムに含まれる各装置の構成について、以下図面を参照して具体的に説明する。

【0020】

＜＜２．構成＞＞
＜２−１．情報配信端末１の構成＞
図２は、本実施形態による情報配信端末１の構成の一例を示すブロック図である。図２に示すように、情報配信端末１は、制御部１０、通信部１１、入力部１２、出力部１３、および記憶部１４を有する。

【0021】

制御部１０は、演算処理装置および制御装置として機能し、各種プログラムに従って情報配信端末１内の動作全般を制御する。制御部１０は、例えばＣＰＵ（Central Processing Unit）、マイクロプロセッサ等の電子回路によって実現される。また、制御部１０は、使用するプログラムや演算パラメータ等を記憶するＲＯＭ（Read Only Memory）、及び適宜変化するパラメータ等を一時記憶するＲＡＭ（Random Access Memory）を含んでいてもよい。

【0022】

本実施形態による制御部１０は、通信部１１を介してサーバ２から受信した通知情報を出力部１３からユーザに提示するよう制御する。また、制御部１０は、入力部１２により入力された入力情報を、記憶部１４に記憶したり、通信部１１を介してサーバ２に送信したりするよう制御する。

【0023】

通信部１１は、有線または無線によりネットワーク３と接続し、サーバ２とデータの送受信を行う。通信部１１は、例えば有線／無線ＬＡＮ（Local Area Network）、またはＷｉ−Ｆｉ（登録商標）、携帯通信網（ＬＴＥ（Long Term Evolution）、３Ｇ（第３世代の移動体通信方式））等によりネットワーク３と通信接続する。

【0024】

入力部１２は、情報配信端末１への入力情報を検知し、制御部１０へ出力するインタフェースである。例えば入力部１２は、操作入力部、音声入力部（マイクロホン）、またはカメラであってもよい。操作入力部としては、情報配信端末１の表示画面（出力部１３の一例）と一体的に設けられるタッチセンサ、圧力センサ、若しくは近接センサであってもよい。或いは、操作入力部は、ボタン、スイッチ、およびレバーなどの物理的構成であってもよい。また、入力部１２は、ユーザの行動を検知するセンサ（加速度センサ、ジャイロセンサ、地磁気センサ、生体センサ、環境センサ等）や、位置測位部であってもよい。位置測位部は、外部からの取得信号に基づいて情報配信端末１の現在位置を検知する機能を有する。具体的には、例えば位置測位部は、ＧＰＳ（Global Positioning System）測位部により実現され、ＧＰＳ衛星からの電波を受信して、情報配信端末１が存在している位置を検知し、検知した位置情報を制御部１０に出力する。また、位置測位部は、ＧＰＳの他、例えばＷｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、携帯電話・ＰＨＳ・スマートフォン等との送受信、または近距離通信等により位置を検知するものであってもよい。

【0025】

出力部１３は、画像やテキストを出力する表示部、または音声を出力する音声出力部（スピーカ）により実現され得る。表示部は、例えば、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、有機ＥＬ（Electroluminescence）ディスプレイなどの表示装置であってもよい。

【0026】

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

【0027】

以上、本実施形態による情報配信端末１の構成について具体的に説明した。なお上述した情報配信端末１の構成は一例であって、本実施形態はこれに限定されない。

【0028】

＜２−２．サーバ２の構成＞
（２−２−１．ハードウェア構成）
図３は、本実施形態によるサーバ２のハードウェア構成の一例を示すブロック図である。図３に示すように、サーバ２（情報処理装置）は、制御部２０、通信部２１、および記憶部２２を有する。

【0029】

（制御部２０）
制御部２０は、演算処理装置および制御装置として機能し、各種プログラムに従ってサーバ２内の動作全般を制御する。制御部２０は、例えばＣＰＵ（Central Processing Unit）、マイクロプロセッサ等の電子回路によって実現される。また、制御部２０は、使用するプログラムや演算パラメータ等を記憶するＲＯＭ（Read Only Memory）、及び適宜変化するパラメータ等を一時記憶するＲＡＭ（Random Access Memory）を含んでいてもよい。

【0030】

（通信部２１）
通信部２１は、有線または無線によりネットワーク３と接続し、多数の情報配信端末１とデータの送受信を行う。また、通信部２１は、例えば有線／無線ＬＡＮ（Local Area Network）、またはＷｉ−Ｆｉ（Wireless Fidelity、登録商標）等によりネットワーク３と通信接続する。

【0031】

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

【0032】

（２−２−２．機能構成）
続いて、サーバ２の制御部２０および記憶部２２の機能構成について図４を参照して説明する。図４は、本実施形態によるサーバ２の制御部２０および記憶部２２の機能構成の一例を示すブロック図である。

【0033】

図４に示すように、サーバ２は、スポット情報収集モジュール２００、スポット情報解析モジュール２１０、イベント推薦モジュール２２０、ユーザ履歴管理モジュール２３０、反応解析モジュール２４０、環境解析モジュール２５０、および情報統合モジュール２６０として機能する。

【0034】

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

【0035】

（スポット情報解析）
スポット情報解析モジュール２１０は、スポット情報解析部２０ｂおよびスポット解析情報記憶部２２ｂを含む。スポット情報解析部２０ｂは、スポット情報収集モジュール２００により収集されたメタデータの解析を行う。具体的には、例えばスポット情報解析部２０ｂは、特開２００５−１７６４０４号公報で開示される手法によって、メタデータの属性値ごとにスコアを持つベクトル（コンテンツプロファイル）をスポット（コンテンツ）毎に生成する。ここで、図５および図６に、スポットのデータ構造の一例を示す。図５および図６に示すように、スポット（コンテンツ）のデータ構造は、「ＩＤ」、「Ｃｏｎｔｅｎｔ Ｖｅｃｔｏｒ」、および「Ｃｏｎｔｅｎｔ Ｉｎｆｏ」から成る。「Ｃｏｎｔｅｎｔ Ｖｅｃｔｏｒ」は、スポット間の類似性や、スポットとユーザの嗜好との関連性を測る際に用いるメタデータであって、例えば、スポットの説明（紹介文クラスタ）、一般カテゴリ、サービスが提供する専門ジャンル、タグ、対象年齢、施設の有無、口コミのタイトル、口コミの内容（口コミクラスタ）が挙げられる。また、「Ｃｏｎｔｅｎｔ Ｉｎｆｏ」は、スポットの詳細情報に関するメタデータであって、例えば、エリア、電話番号、営業時間、住所、料金、緯度経度、評価等が挙げられる。「Ｃｏｎｔｅｎｔ Ｖｅｃｔｏｒ」と「Ｃｏｎｔｅｎｔ Ｉｎｆｏ」の区別は一例であって、一部重複していてもよいし、用途に応じて適宜定義してもよい。また、string型のテキストは形態素解析され（対象品詞を指定可能）、キーワードのベクトル「(キーワード，頻度)」として表現される。例えば、（水族館，２）、（アトラクション，３）、（レストラン，２）、（ショッピング，１）、（ホテル，１）、（アミューズメント、１）等に変換される。

【0036】

また、紹介文や口コミに対するクラスタリングにおいては、潜在トピックモデルの手法としてテキスト分類で広く用いられるＰＬＳＡ（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が参照される。

【0037】

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

【0038】

【数1】

【0039】

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

【0040】

また、上記メタデータのうち、「ｎｕｄｇｅ Ｃａｔｅｇｏｒｙ Ｉｄ」は、システムで定義した一般カテゴリであって、「ｓｅｒｖｉｃｅ Ｃａｔｅｇｏｒｙ Ｉｄ」は、サービスが提供する専門ジャンルである。「ｎｕｄｇｅ Ｃａｔｅｇｏｒｙ」としては、例えば、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（体験施設）等が挙げられる。

【0041】

（イベント推薦）
イベント推薦モジュール２２０は、イベント推薦制御部２０ｃおよび推薦情報記憶部２２ｃを含む。イベント推薦制御部２０ｃは、ユーザの嗜好や習慣に基づいて、イベントの推薦および通知制御を行う。

【0042】

・イベントにおけるスポット推薦情報の生成
まず、イベント推薦モジュール２２０は、ユーザの嗜好情報およびスポット情報解析部２０ｂにより解析したスポット情報（ベクトル化されたコンテンツプロファイル）に基づいて、イベントにおけるユーザの嗜好に応じたスポット推薦情報を生成する。具体的には、イベント推薦制御部２０ｃは、ユーザ履歴管理モジュール２３０で管理されているユーザ履歴に含まれるユーザの行動履歴（さらに家族構成等のユーザ情報を含めてもよい）を分析して得たユーザプリファレンスと、スポット情報とをマッチングし、イベント条件毎のスポット推薦情報を生成する。ユーザプリファレンスは、ユーザ履歴におけるユーザ行動のメタデータあるいはコンテンツプロファイルの重み付け和から生成されるベクトルとして表現されてもよい。イベント推薦制御部２０ｃは、ユーザ履歴に基づいて属性値をベクトル化したユーザプリファレンスを生成することも可能である。この場合、イベント推薦制御部２０ｃは、例えば特開２００５−１７６４０４号公報に記載の手法によって、ユーザプリファレンスとコンテンツプロファイル（スポット情報解析部２０ｂによるスポット情報の解析結果）とのマッチングを行い（項目ごとにそれぞれ内積を演算）、マッチングスコア（ベクトル間の内積の総和など）に基づいて、スポット推薦を行う。

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

・イベント推薦
次いで、イベント推薦制御部２０ｃは、予測したイベントを推薦条件とするスポット推薦情報を上記スポット推薦結果から取得し、イベント推薦情報とする。なおイベント推薦制御部２０ｃは、予測したイベントを推薦条件とする複数のスポット推薦結果（上位５つのスポット等）を取得してもよい。

【0048】

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

【0049】

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

【0050】

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

【0051】

以上説明した推薦制御については、後述するフローチャートにおいてさらに具体的に説明する。

【0052】

（ユーザ履歴管理）
ユーザ履歴管理モジュール２３０は、ユーザ履歴管理部２０ｄおよびユーザ履歴記憶部２２ｄを含む。ユーザ履歴管理部２０ｄは、ユーザ履歴記憶部２２ｄへのユーザ履歴の登録および更新等のデータ管理を行う。ユーザ履歴には、行動履歴として、スケジュール履歴情報、イベント発生履歴情報（モバイル機器と連携したユーザ行動の認識結果を反映してもよい）、操作履歴（検索履歴、閲覧履歴等）、ユーザ反応履歴等が含まれる。ユーザ反応履歴は、反応解析モジュール２４０で解析されたイベント推薦に対するユーザ反応（詳細情報の閲覧、ブックマーク、予約、スケジュール登録、削除などの操作履歴）や、イベント体験に対するユーザ反応（評価等）であって、環境解析モジュール２５０により解析された環境情報（時間、場所、行動、状況）と共に蓄積されてもよい。

【0053】

ここで、図７に、ユーザ履歴記憶部２２ｄに記憶されるユーザ履歴（フィードバック）のデータ構造の一例を示す。図７に示すように、ユーザ履歴（フィードバック）は、ユーザＩＤ、フィードバックタイプ、アイテムＩＤ（スポットＩＤ等）、およびタイムスタンプ（登録日時）を含む。フィードバックタイプには、図７に示すように、お出掛け先（予定、イベント）のスケジュールへの登録（スケジュール履歴情報）、お出掛け先のウィッシュリストへの追加、お出掛け先へ出掛けたこと（イベント発生履歴情報）、お出掛け先の一覧画面や詳細画面の閲覧（ユーザ反応履歴）が挙げられる。

【0054】

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

【0055】

（環境解析）
環境解析モジュール２５０は、環境解析部２０ｆおよび環境解析情報記憶部２２ｆを含む。環境解析部２０ｆは、例えば情報配信時（具体的には、例えばイベント推薦時）や行動認識時（具体的には、例えばイベント体験時）におけるユーザの環境（時間、場所、行動、状況等）などを解析する。

【0056】

（情報統合）
情報統合モジュール２６０は、情報統合制御部２０ｇおよび統合情報記憶部２２ｇを含む。情報統合制御部２０ｇは、各モジュールから得られる情報の受け渡しや、情報配信端末１とのデータの送受信を制御する。例えば情報統合制御部２０ｇは、スポット情報収集モジュール２００から得られるスポット情報をスポット情報解析モジュール２１０に出力したり、スポット情報解析モジュール２１０から得られるスポット解析情報（コンテンツプロファイル）をイベント推薦モジュール２２０に出力する。また、情報統合制御部２０ｇは、ユーザ履歴管理モジュール２３０から得られるユーザ履歴をイベント推薦モジュール２２０に出力する。また、情報統合制御部２０ｇは、反応解析モジュール２４０から得られるユーザ反応および環境解析モジュール２５０から得られるユーザ反応時のユーザ環境を、イベント推薦モジュール２２０に出力する。

【0057】

また、情報統合制御部２０ｇは、イベント推薦モジュール２２０から出力されたイベント推薦情報を、所定の決定されたタイミングで情報配信端末１からユーザに通知するよう制御する。また、情報統合制御部２０ｇは、イベント発生時にイベント評価をユーザに促す質問を情報配信端末１から通知するよう制御することも可能である。ここで、図８を参照して本実施形態によるイベント通知の一例について説明する。

【0058】

図８に示すように、例えば２０１５年３月２９日に、ユーザにより同年４月３０日から２泊３日の家族旅行がスケジュール登録された場合、サーバ２は、イベント発生日になるとイベント内容について評価を促す質問を行う。例えば、図８に示すように、「□□の料理は美味しかったですか？」、「○○ホテルは満足できましたか？」、「車で快適に移動できましたか？」といった質問を行い（音声エージェントによる質問であってもよいし、テキストでの質問であってもよい）、ユーザの回答から評価を得る。これらの質問は、ユーザが登録したスケジュール情報（□□で昼食、○○ホテルに宿泊、ドライブ等）に基づいて生成されてもよいし、さらにサーバ２がユーザのモバイル機器（情報配信端末１）と連動し、ユーザの行動認識結果に基づいて生成されてもよい。ユーザから得た評価は、反応解析モジュール２４０により解析され、ユーザ嗜好としてユーザ履歴管理モジュール２３０で管理される。

【0059】

続いて、図８に示すように、２０１６年４月４日に、ユーザにより同年５月２日から２泊３日の家族旅行がスケジュール登録された場合も同様に、サーバ２は、イベント発生日になるとイベント内容について評価を促す質問を行う。

【0060】

そして、サーバ２のイベント推薦モジュール２２０は、上記スケジュール登録（ユーザ履歴）に基づいて、毎年５月頭頃に家族旅行に出掛けるというユーザの習慣を把握し、イベントの発生予測を行うことができる。また、イベント推薦モジュール２２０は、当該イベントのスケジュール登録が、平均してイベントの３０日前に行われることから、イベントが２０１７年５月１日に発生すると予測した場合にはその３０日前の同年４月１日を最適な通知タイミングに決定する。また、推薦イベントで提案するスポットは、ユーザ履歴に基づいてユーザの嗜好（例えば、温泉によく行く、家族旅行は車で移動する等）や家族構成等のユーザプリファレンスとイベント条件（時期：５月、期間：２泊以上、目的：家族旅行、など）に応じて選定される。これによりサーバ２は、図８に示すように、最適な行動決定タイミングである２０１７年４月１日に、「ＧＷ（ゴールデンウィーク）の家族旅行、そろそろ計画しませんか。車で１時間で行ける温泉はいかがですか？」等のイベント推薦通知を情報配信端末１によりユーザに行う。イベント推薦通知は、音声通知であってもよいし、画面上での通知であってもよい。この際、サーバ２は、推薦するスポットを複数提示してもよい。

【0061】

また、サーバ２のイベント推薦モジュール２２０は、推薦したスポットの状況に変化があった場合、再度イベント推薦通知を行うようにしてもよい。例えば図８に示すように、お勧めした○○ホテルの予約が埋まって来た場合、「おすすめの□□温泉○○ホテルの残室があとわずかになっています。予約はお早めに」といった通知を行う。○○ホテルの予約状況については、スポット情報解析モジュール２１０により解析され、変化があった場合に、情報統合モジュール２６０を介してイベント推薦モジュール２２０に通知され得る。これにより、時々刻々と変化するイベントのコスト（予約時期によってホテルの宿泊料金等に変動がある場合）やリスク（予約状況、混雑具合等）を鑑みたタイミングで通知が行われるため、ユーザの機会損失を防ぎ、また、リーズナブルな条件で施設の予約を行うことができる。

【0062】

ここで、イベント推薦通知の表示画面例を図９に示す。図９に示すように、推薦情報提示画面１３０には、「ＧＷの家族旅行、そろそろ計画しませんか？子持ち世帯（小学生）にオススメ、車で１時間程で行ける○○海岸周辺の行楽地です」といった推薦理由と、お薦めのスポットが表示されている。推薦理由は、スポット選定時に利用したユーザの嗜好情報やイベント条件に基づいてイベント推薦モジュール２２０により生成され得る。このように推薦理由も提示されることで、ユーザのシステムの提案に対する納得性が高まる。

【0063】

ユーザは、気になったスポットを選択して詳細情報を閲覧することができる。例えば図９に示す例では、第４のオススメスポット１３１を選択すると、詳細画面１３２が表示される。なおこのようなユーザの操作履歴（どのスポットの詳細情報を閲覧したか等）は、イベント推薦時のユーザ反応として反応解析モジュール２４０により解析される。

【0064】

以上、本実施形態によるサーバ２の構成について具体的に説明した。

【0065】

なお、本実施形態では一例としてサーバ２が図４に示す機能構成を有するが、本実施形態はこれに限定されず、図４に示す機能構成が複数の装置によりネットワーク上で構築される構成であってもよい。

【0066】

＜＜３．動作処理＞＞
続いて、本実施形態による情報処理システムの動作処理について図面を用いて具体的に説明する。

【0067】

＜３−１．スポット推薦処理＞
まず、図１０を参照して、イベントにおけるスポット推薦情報の生成処理について説明する。図１０は、本実施形態によるイベントにおけるスポット推薦情報の生成処理を示すシーケンス図である。

【0068】

図１０に示すように、まず、サーバ２は、スポット解析を行う場合（ステップＳ１０３／Ｙｅｓ）、スポット情報解析モジュール２１０により、スポット情報収集モジュール２００により収集されたスポット情報の解析を行う（ステップＳ１０６）。スポット解析は、例えば隔週や月に１回等、定期的に行うようにしてもよいし、更新があった場合に行うようにしてもよい。また、スポット情報解析モジュール２１０は、新規追加あるいはデータ更新されたスポット情報の解析を行うようにしてもよい。

【0069】

スポット解析は、上述したように、スポット情報として得られたメタデータを、属性値毎にベクトル化したものであってもよい。ここで、スポット解析結果解析“｛Ｃｏｎｔｅｎｔ Ｖｅｃｔｏｒ｝［Ｃｏｎｔｅｎｔ Ｉｎｆｏ］”の一例を示す。

【0070】

・スポットＡ：｛温泉=1.0，□□地方=1.0，露天風呂=0.6，バイキング=0.4，マッサージ=0.2｝［緯度=xxx，経度=xxx，人気=4.1，大人料金=15,000円，子供料金=10,000円］
・スポットＢ：｛テーマパーク=1.0，○△市=1.0，サファリ=0.8，体験=0.5，バス=0.3｝［緯度=xxx，経度=xxx，人気=4.4，大人料金=27,000円，子供料金=1,500円］
・スポットＣ：｛キャンプ場=1.0，△△山地=1.0，ドッグラン=0.7，コテージ=0.5，パン=0.4｝［緯度=xxx，経度=xxx，人気=3.6，料金=4,000円］

【0071】

次に、イベント推薦を行う場合（ステップＳ１０９／Ｙｅｓ）、イベント推薦モジュール２２０は、ユーザ履歴管理モジュール２３０からユーザ履歴（スケジュール情報など）を取得する（ステップＳ１１２）。イベント推薦は、毎日または１週間に１回等、定期的に行うようにしてもよい。また、全てのユーザに対して実行してもよいし、アクティブユーザにだけ実行するようにしてもよい。アクティブユーザの判断は、例えばユーザ履歴管理モジュール２３０で管理されるユーザ履歴において、直近ｎ時間に履歴の更新（操作履歴の更新など）があったか否かに基づいて行ってもよい。

【0072】

また、イベント推薦モジュール２２０は、ユーザ履歴を属性値毎にベクトル化したユーザプリファレンスを取得するようにしてもよい。なおユーザ履歴が図７に示すようにフィードバック履歴として管理されている場合、履歴の対象となるスポット（スケジュール登録したスポット（すなわちスケジュール履歴の対象）、ウィッシュリストに追加したスポット（すなわちウィッシュ履歴の対象）、出掛けたスポット（すなわち行動履歴の対象）、閲覧した対象（すなわち操作履歴の対象）など）のコンテンツプロファイルを取得して足し合わせたものをユーザプリファレンスに含めてもよい。ここで、取得したユーザプリファレンス“｛Ｃｏｎｔｅｎｔ Ｖｅｃｔｏｒ｝［Ｃｏｎｔｅｎｔ Ｉｎｆｏ］”の一例を示す。

【0073】

・２０１５年５月、イベント；「家族で旅行」、一泊、スポットＸ：
｛温泉=1.0，△□地方=1.0，露天風呂=0.6，イタリアン=0.4，エステ=0.1｝［緯度=xxx，経度=xxx，人気=3.8，大人料金=12,000円，子供料金=8,000］
・２０１６年５月、イベント；「家族で旅行」、一泊、スポットＹ：
｛温泉=1.0，○○高原=1.0，コテージ=0.5，和食=0.3，マッサージ=0.2｝［緯度=xxx，経度=xxx，人気=4.2，大人料金=16,000円，子供料金=10,000］
・２０１６年１１月、イベント；「親子でお出かけ」、一泊、スポットＺ：
｛キャンプ場=1.0，○□半島=1.0，釣り=0.7，テント=0.3，ハイキング=0.2｝［緯度=xxx，経度=xxx，人気=3.7，料金=5,000円］

【0074】

なお、上記ユーザプリファレンスの一例は、Feedback Typeのうち「REGISTER_SCHEDULE」（スケジュールに登録したもの）を対象として足し合わせているが、本実施形態はこれに限定されず、他のFeedback Typeも対象にすることが可能である。例えば、REGISTER_SCHEDULE＝2.0、ADD_WISHLIST＝1.0、CHECK_IN＝3.0のように重みを付けて足し合わせてもよい。

【0075】

また、ユーザグループに対してイベント推薦を実行する場合は、対象となる複数ユーザのユーザプリファレンスを足し合わせてグループのユーザプリファレンスを生成し、グループ向けの推薦を行うことも可能である（各ユーザの推薦結果を足し合わせてもよい）。

【0076】

次に、イベント推薦モジュール２２０は、推薦条件（イベント条件）の設定を行う（ステップＳ１１５）。推薦条件は、日時、期間、および目的等が想定される。例えば、時期（季節、月、曜日など）、期間（日帰り／一泊／二泊以上）、目的（家族で旅行／夫婦で外食／親子でお出かけ／親子で買い物など）が想定される。一通りの条件を設定して各イベント条件における推薦スポットを選定してもよいし、後述するイベント予測処理により予測されたイベントの条件を設定してもよい。

【0077】

次いで、イベント推薦モジュール２２０は、スポットの推薦処理を行う（ステップＳ１１８）。具体的には、例えばイベント推薦モジュール２２０は、設定した推薦条件（日時、期間、および目的）におけるユーザプリファレンスを用いて、コンテンツプロファイル（スポット解析結果）とのマッチングスコアを算出し、各推薦条件におけるマッチングスコアを足し合わせて最終スコアとし、スコア上位ｎ件のスポットを推薦条件と合わせて推薦結果とする。

【0078】

ここで、スポット推薦処理について具体的な算出例を示して説明する。ここでは、一例として後述するイベント予測処理により将来発生すると予測されたイベントの条件を設定する。例えば、２０１７年５月１日に一泊の家族旅行イベントが予測された場合、イベント推薦モジュール２２０は、「日時：２０１７年５月１日＝春、期間：一泊、目的：家族旅行」を推薦条件に設定する。

【0079】

次いで、イベント推薦モジュール２２０は、ユーザ履歴に基づいて、各推薦条件「春」「一泊」「家族旅行」のユーザプリファレンスをそれぞれ生成する。例えば上述したユーザ履歴からは、春（２０１５年５月イベント、２０１６年５月イベント）に訪れたことのあるスポットＸおよびスポットＹのコンテンツプロファイルを足し合わせて、下記のように推薦条件「春」のユーザプリファレンスが生成される。

【0080】

ＵＰ（春）＝スポットＸ＋スポットＹ：
｛温泉=2.0，△□地方=1.0，○○高原=1.0，露天風呂=0.6，イタリアン=0.4，エステ=0.1，コテージ=0.5，和食=0.3，マッサージ=0.2｝

【0081】

また、上述したユーザ履歴からは、一泊（２０１５年５月イベント、２０１６年５月イベント、２０１６年１１月イベント）で訪れたことのあるスポットＸ、スポットＹ、およびスポットＺのコンテンツプロファイルを足し合わせて、下記のように推薦条件「一泊」のユーザプリファレンスが生成される。

【0082】

ＵＰ（一泊）＝スポットＸ＋スポットＹ＋スポットＺ：
｛温泉=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｝

【0083】

また、上述したユーザ履歴からは、家族旅行（２０１５年５月イベント、２０１６年５月イベント）で訪れたことのあるスポットＸおよびスポットＹのコンテンツプロファイルを足し合わせて、下記のように推薦条件「家族旅行」のユーザプリファレンスが生成される。

【0084】

ＵＰ（家族旅行）＝スポットＸ＋スポットＹ：
｛温泉=2.0，△□地方=1.0，○○高原=1.0，露天風呂=0.6，イタリアン=0.4，エステ=0.1，コテージ=0.5，和食=0.3，マッサージ=0.2｝

【0085】

次いで、イベント推薦モジュール２２０は、ＵＰ（春）と、スポットＡ、スポットＢ、およびスポットＣとのコンテンツプロファイルとを、それぞれマッチング（例えばベクトルｃｏｓ演算）する。

【0086】

・ＵＰ（春）とスポットＡ：
{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)(ＵＰノルム)*√(1.0^2+1.0^2+0.6^2+0．4^2+0.2^2)(Ａノルム)｝=2.4/｛√6.91*√2.56｝=0.570
・ＵＰ（春）とスポットＢ：0.00（共通メタデータなし）
・ＵＰ（春）とスポットＣ：
｛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)(ＵＰノルム)*√(1.0^2+1.0^2+0.7^2+0.5^2+0.4^2)(Ｃノルム)｝=0.25/｛√6.91＊√2.9｝=0.055

【0087】

次に、イベント推薦モジュール２２０は、ＵＰ（一泊）と、スポットＡ、スポットＢ、およびスポットＣとのコンテンツプロファイルとを、それぞれマッチング（例えばベクトルｃｏｓ演算）する。

【0088】

・ＵＰ（一泊）とスポットＡ：｛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)(ＵＰノルム)*√（1.0^2+1.0^2+0.6^2+0.4^2+0.2^2)(Ａノルム)}=2.4/{√9.53*√2.56}=0.485
・ＵＰ（一泊）とスポットＢ：0.00（共通メタデータなし）
・ＵＰ（一泊）とスポットＣ：
{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)(ＵＰノルム)*√（1.0^2+1.0^2+0.7^2+0.5^2+0.4^2)(Ｃノルム)｝=1.25/{√9.53*√2.9}=0.237

【0089】

次に、イベント推薦モジュール２２０は、ＵＰ（家族旅行）と、スポットＡ、スポットＢ、およびスポットＣとのコンテンツプロファイルとを、それぞれマッチング（例えばベクトルｃｏｓ演算）する。

【0090】

・ＵＰ（家族旅行）とスポットＡ：｛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）(ＵＰノルム)*√(1.0^2+1.0^2+0.6^2+0.4^2+0．2^2）（Ａノルム）｝=2.4/｛√6.91*√2.56｝=0.570
・ＵＰ（家族旅行）とスポットＢ：0.00（共通メタデータなし）
・ＵＰ（家族旅行）とスポットＣ：｛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）（ＵＰノルム）＊√（1.0^2＋1.0^2＋0.7^2＋0．5^2＋0.4^2）(Ｃノルム）｝＝0.25／｛√6.91＊√2.9｝＝0.055

【0091】

そして、イベント推薦モジュール２２０は、スポットＡ、スポットＢ、スポットＣに対する各ＵＰとのマッチングスコアを足し合わせて下記のように最終スコアを算出する。

【0092】

・スポットＡ総合＝“ＵＰ（春）とスポットＡ”＋“ＵＰ（一泊）とスポットＡ”＋“ＵＰ（家族旅行）とスポットＡ”=0.570+0.485+0.570=1.625
・スポットＢ総合＝“ＵＰ（春）とスポットＢ”＋“ＵＰ（一泊）とスポットＢ”＋“ＵＰ（家族旅行）とスポットＢ”=0.000+0.000+0.000=0.000
・スポットＣ総合＝“ＵＰ（春）とスポットＣ”＋“ＵＰ（一泊）とスポットＣ”＋“ＵＰ（家族旅行）とスポットＣ”=0.055+0.237+0.055=0.347

【0093】

なおイベント推薦モジュール２２０は、条件フィルタを設定して対象スポット（スポットＡ〜Ｃ）を絞り込むことも可能である。例えば人気（Ｃｏｎｔｅｎｔ Ｉｎｆｏの一例）による絞り込みを行ってもよい。具体的には、例えば対象スポットのメタデータに基づいて、「人気」が3.5未満のスポットは推薦結果から除外するようにしてもよい。若しくは、ＵＰとのマッチングスコアと人気度を重み付けて（例えば２:１で足し合わせて）総合スコアを算出してもよい。また、例えば対象スポットに対してユーザの自宅からの所要時間（緯度・経度から算出可能）による絞り込みも可能である。具体的には、例えば電車で１時間以上かかるスポットは推薦結果から除外するようにしてもよい。

【0094】

続いて、イベント推薦モジュール２２０は、情報統合モジュール２６０に、スポット推薦結果を出力する(ステップＳ１２１)。この際、イベント推薦モジュール２２０は、算出した総合スコアが閾値に満たないものや、ユーザが推薦画面で閲覧してから一定時間（例えば１日）経過していないスポットを除外するようにしてもよい。そして、イベント推薦モジュール２２０は、残ったスポットを総合スコア上位順にスポット推薦結果として情報統合モジュール２６０に出力する。

【0095】

例えば上記算出した具体例の場合、条件フィルタで除外されるスポットがなく、総合スコアの閾値が0.3であって、また、一定時間（例えば１日）経過していないスポットがない場合、イベント推薦モジュール２２０は、イベント推薦条件「春、一泊、家族旅行」におけるスポット推薦結果「１位 スポットＡ（=1.625）、２位 スポットＣ（=0.347）」を情報統合モジュール２６０に出力する。

【0096】

以上、本実施形態によるイベントにおけるスポット推薦処理について具体的に説明した。続いて、本実施形態による推薦イベント通知処理について図１１を参照して具体的に説明する。

【0097】

＜３−２．推薦イベント通知処理＞
図１１は、本実施形態によるイベント推薦通知処理を示すフローチャートである。

【0098】

図１１に示すように、まず、イベント予測を行う場合（ステップＳ２０３／Ｙｅｓ）、イベント推薦モジュール２２０は、イベント予測を行う（ステップＳ２０６）。イベント予測は、例えば毎日（１日１回）または１週間に１回など、定期的に行われ得る。また、イベント推薦モジュール２２０は、具体的には、ユーザ履歴管理モジュール２３０からユーザの過去のイベントを抽出し、所定の条件を満たす場合（習慣を把握できた場合）には、次に当該イベントがいつ発生するかを予測する。例えば、イベント推薦モジュール２２０は、ある目的（例えば「家族で旅行」）のイベントの発生日時から、ある日付（例えば「５月１日」）の前後ｋ日（例えばｋ＝５日）を含む２ｋ＋１日間（例えば４月２６日〜５月６日）でｎ年以上（例えばｎ＝２年）続けて発生している場合（つまり「習慣」となっていることを把握）、次の発生タイミング（すなわち、イベント発生時期）を予測する。例えば２０１７年４月現在において、当該イベントが２０１５年と２０１６年に続けて２年以上発生している場合、イベント推薦モジュール２２０は、当該イベントの次の発生は２０１７年５月１日と予測できる。イベント発生時期は、年単位、月単位、または週単位等で予測可能である。イベント推薦モジュール２２０は、予測イベント（例えば、目的：家族旅行、日付：２０１７年５月１日）を推薦情報記憶部２２ｃに登録する。なおかかる予測イベントにおけるスポットは、予測したイベントを条件として、図１０を参照して説明したスポット推薦処理により取得され得る。イベント推薦モジュール２２０は、予測したイベントを、対応するスポット推薦結果と共に推薦情報記憶部２２ｃに登録しておいてもよい。

【0099】

次いで、登録または予測したイベントが存在する場合（ステップＳ２０９／Ｙｅｓ）、イベント推薦モジュール２２０は、予測イベントの登録タイミングに達したか否かを判断する（ステップＳ２１２）。すなわち、イベント推薦モジュール２２０は、予測したイベントをスケジュールに登録する（若しくは少なくとも準備を開始する）タイミングに達したか否かを判断する。具体的には、例えばイベント推薦モジュール２２０は、予測イベントにおけるスポット推薦情報から、スポットのメタデータを抽出し、スポットのジャンルに応じて通知タイミング（ＴＧ）を決定してもよい。例えば、イベント発生日から、ホテルであれば３０日前、テーマパークであれば３日前、牧場であれば７日前を通知タイミングとしてもよい。また、さらに季節や時期によって変化させてもよい。若しくは、イベント推薦モジュール２２０は、ユーザ履歴に基づいて、イベントの目的別のユーザのスケジュール登録タイミングＴＵの平均日数を算出し、予測イベント発生時期から当該平均日数を差し引いた日時を通知タイミングとしてもよい。例えば、家族旅行であれば３０日前、親子でお出掛けであれば７日前、夫婦で外食であれば３日前を通知タイミングとすることが可能となる。なお、スケジュール登録日に限定されず、例えばイベントに関する情報の検索日や、イベントに関する情報をメールやＳＮＳ等のソーシャルメディアでやり取りし出した日など、イベントの準備を何らかの形で開始した時期に基づいてユーザの準備期間を把握し、通知タイミングを決定してもよい。

【0100】

次に、通知タイミングに達している（通知タイミングが現在の日時に該当する）場合（ステップＳ２１２／Ｙｅｓ）、イベント推薦モジュール２２０は、通知対象に、対応する予測イベントと質問を追加する（ステップＳ２１５）。質問は、例えば予測イベントにおける推薦スポットのメタデータから生成してもよい（例えば、「車で１時間で行ける温泉はいかがですか？」など）。

【0101】

次いで、登録または予測イベントの状況が変化していた場合（ステップＳ２１８／Ｙｅｓ）、イベント推薦モジュール２２０は、通知対象に、状況変化イベントと質問を追加する（ステップＳ２２１）。具体的には、イベント推薦モジュール２２０は、登録／予測イベントにおける推薦スポットの（最新の）メタデータを取得し、予約状況や利用料金、営業時間等の変化（更新）がないかを確認し、変化があった場合には、当該登録／予測イベントを状況変化イベントに決定し、質問を生成する。例えば、家族旅行イベントを予測していた際に、当該イベントにおける推薦スポット「□□温泉○○ホテル」の予約状況を確認し、残室が僅かになっていた場合には、当該家族旅行イベントを状況変化イベントに決定すると共に、「□□温泉○○ホテルが残室僅かになっていますよ！予約はお早めに」等の質問（予約を促す通知）を生成する。

【0102】

続いて、イベントが発生している場合（ステップＳ２２４／Ｙｅｓ）、イベント推薦モジュール２２０は、通知対象に、発生イベントと質問を追加する（ステップＳ２２７）。現在発生しているイベントの検知は、ユーザのスケジュール情報に登録されているイベントの時間情報を取得して判断されてもよいし、さらにユーザのモバイル機器（情報配信端末１）と連動してユーザの行動を認識して（位置情報、加速度情報等）検知されてもよい。また、イベント推薦モジュール２２０は、例えば家族旅行イベントが発生している場合、当該イベントの詳細情報からスポットのメタデータを抽出し、質問を生成する（「□□温泉○○ホテル」は満足できましたか？」「車で快適に行けましたか？」「料理は美味しかったですか？」など）。また、サーバ２の反応解析モジュール２４０は、イベントの発生が確認された際（例えばモバイル機器から取得した緯度・経度情報から、あるスポットに滞在していることが分かった場合など）、CHECK_INとしてユーザ履歴を保存するようにしてもよい。

【0103】

次いで、イベント推薦モジュール２２０は、通知対象を情報統合モジュールに出力する（ステップＳ２３０）。

【0104】

そして、情報統合モジュールは、情報配信端末１からユーザへの通知処理を行う（ステップＳ２３３）。通知や質問に対するユーザの反応（操作や応答）は、情報配信端末１からサーバ２へ送信され、反応解析モジュール２４０により解析され、その内容に応じて、REGSITER_SCHEDULE、ADD_WISHLIST、SHOW_LIST、SHOW_DETAILといったユーザ履歴として保存される（図７参照）。

【0105】

以上、本実施形態による推薦イベントの通知処理について具体的に説明した。

【0106】

＜＜４．補足＞＞
なおサーバ２のイベント推薦モジュール２２０は、広告としてのイベントやスポットを併せて推薦することも可能である。

【0107】

サーバ２は、広告としてのイベントやスポットを提示する場合、広告であることをユーザが直感的に把握できるよう、音声エージェントの声色を変えたり、表示態様を変えたり（背景色、文字色、「広告」の表示等）するようにしてもよい。また、広告による推薦イベントやスポットの提示と、上述した推薦処理による推薦イベントやスポットの提示を両方行う場合に、内容の違いを説明するようにしてもよい。

【0108】

＜＜５．まとめ＞＞
上述したように、本開示の実施形態による情報処理システムでは、ユーザに適したタイミングでスケジュール登録を促す通知を行うことが可能となる。

【0109】

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

【0110】

例えば、上述した情報配信端末１、またはサーバ２に内蔵されるＣＰＵ、ＲＯＭ、およびＲＡＭ等のハードウェアに、情報配信端末１、またはサーバ２の機能を発揮させるためのコンピュータプログラムも作成可能である。また、当該コンピュータプログラムを記憶させたコンピュータ読み取り可能な記憶媒体も提供される。

【0111】

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

【0112】

なお、本技術は以下のような構成も取ることができる。
（１）
ユーザの行動履歴に基づいて、将来発生するイベントを予測し；
前記予測したイベントのユーザの準備期間を考慮し、当該予測したイベントのスケジュール登録を促す通知のタイミングを決定するイベント推薦制御部を備える、情報処理装置。
（２）
前記イベント推薦制御部は、
前記ユーザの行動履歴に基づいて、前記予測したイベントの目的に応じて準備期間を算出し、前記予測したイベントの発生時期から前記準備期間を差し引いて前記通知のタイミングを決定する、前記（１）に記載の情報処理装置。
（３）
前記ユーザの行動履歴には、イベント発生履歴とスケジュール履歴が含まれ、
前記イベント推薦制御部は、
前記イベント発生履歴に基づく過去のイベントの発生日と、それぞれに対応するスケジュール登録日との差分に基づいて、イベントの目的に応じた準備期間を算出する、前記（２）に記載の情報処理装置。
（４）
前記ユーザの行動履歴には、ユーザによるイベントに関する情報の検索履歴が含まれ、
前記イベント推薦制御部は、
前記イベント発生履歴に基づく過去のイベントの発生日と、それぞれに対応する検索日との差分をさらに考慮して、前記イベントの目的別の準備期間を算出する、前記（３）に記載の情報処理装置。
（５）
前記イベント推薦制御部は、
前記予測したイベントにおけるスポットのジャンルに応じて前記準備期間を算出する、前記（１）〜（４）のいずれか１項に記載の情報処理装置。
（６）
前記イベント推薦制御部は、前記予測したイベントにおけるスポットの人気をさらに考慮して前記準備期間を算出する、前記（５）に記載の情報処理装置。
（７）
前記イベント推薦制御部は、前記予測したイベントが発生する時期または季節をさらに考慮して前記準備期間を算出する、前記（５）または（６）に記載の情報処理装置。
（８）
前記ユーザの行動履歴は、イベント発生履歴およびスケジュール履歴を含む、前記（１）〜（７）のいずれか１項に記載の情報処理装置。
（９）
前記イベント推薦制御部は、
前記ユーザの行動履歴に基づく前記ユーザの習慣に応じて、将来発生するイベントを予測する、前記（１）〜（８）のいずれか１項に記載の情報処理装置。
（１０）
前記イベント推薦制御部は、
前記ユーザの好みに応じて、前記予測したイベントにおけるスポットの候補を選定する、前記（９）に記載の情報処理装置。
（１１）
前記イベント推薦制御部は、
さらに前記ユーザの家族構成に応じて、前記スポットの候補を選定する、前記（１０）に記載の情報処理装置。
（１２）
前記情報処理装置は、
前記決定した通知タイミングで、前記予測したイベントのスケジュール登録を促す通知をユーザに行う通知制御部をさらに備える、前記（１）〜（１１）のいずれか１項に記載の情報処理装置。
（１３）
前記通知制御部は、
前記ユーザに通知したイベントにおけるスポットの状況が変化した場合、前記ユーザに再度通知を行うよう制御する、前記（１２）に記載の情報処理装置。
（１４）
プロセッサが、
ユーザの行動履歴に基づいて、将来発生するイベントを予測することと、
前記予測したイベントのユーザの準備期間を考慮し、当該予測したイベントのスケジュール登録を促す通知のタイミングを決定することと、
を含む、情報処理方法。
（１５）
コンピュータを、
ユーザの行動履歴に基づいて、将来発生するイベントを予測し；
前記予測したイベントのユーザの準備期間を考慮し、当該予測したイベントのスケジュール登録を促す通知のタイミングを決定するイベント推薦制御部として機能させるための、プログラム。

【符号の説明】

【0113】

１ 情報配信端末
２ サーバ
３ ネットワーク
１０ 制御部
１１ 通信部
１２ 入力部
１３ 出力部
１４ 記憶部
２０ 制御部
２０ａ スポット情報収集部
２０ｂ スポット情報解析部
２０ｃ イベント推薦制御部
２０ｄ ユーザ履歴管理部
２０ｅ 反応解析部
２０ｆ 環境解析部
２０ｇ 情報統合制御部
２１ 通信部
２２ 記憶部
２２ａ スポット情報記憶部
２２ｂ スポット解析情報記憶部
２２ｃ 推薦情報記憶部
２２ｄ ユーザ履歴記憶部
２２ｅ 反応解析情報記憶部
２２ｆ 環境解析情報記憶部
２２ｇ 統合情報記憶部
２００ スポット情報収集モジュール
２１０ スポット情報解析モジュール
２２０ イベント推薦モジュール
２３０ ユーザ履歴管理モジュール
２４０ 反応解析モジュール
２５０ 環境解析モジュール
２６０ 情報統合モジュール

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】